hot adsense trick: March 2012

Thursday, 29 March 2012

How Do You Manage The Overwhelming Pace of Web Design? | Van SEO Design

How Do You Manage The Overwhelming Pace of Web Design?

Posted: 29 Mar 2012 05:30 AM PDT

I can still remember the first month of one of the last jobs I ever held. I was new and trying my best to learn everything that was thrown at me. The job was a complete 180 from what I’d been doing the previous few years and there was a lot to learn and adjust to. I remember the overwhelming feeling of so many new things coming at me.

I enjoyed every minute of it. There was never a dull moment and after those early weeks I could look back at how much more I knew about my job and the jobs of the people around me. A promotion soon followed along with a new set of challenges and confusions to master.

All the things that had overwhelmed me in those early days became the stable platform on which I built the next set of learning.

How Can We Keep Up?

Being a freelance web designer feels a lot like that job. There’s always more than a few things to learn and the pace at which they come at you can often be overwhelming. We do our best to take it all in and try to learn as much as we can. We feel confused as we try to implement in practice everything we’re reading about. We wonder how we’ll ever understand all the new. Then we take a deep breath and jump right in.

A few days, weeks, or months later an entirely new set of information, challenges, and technology is thrown our way and we start all over again. Taking a step back we realize how what seemed confusing is now clear and has become a stable base for the next set of challenges and it continues on and on.

Earlier this week I realized how many things I’ve been trying to take on this year and I ask myself how? How will I ever get through it all? How will I learn all the new in front of me? How will I keep up?

At the same time I know I will and I’ll be asking myself the same questions about an entirely new set of challenges and technologies next year.

So Much to Learn

On the client front I’m currently working on 3 site redesigns, one of which is for this site. At the same time I’m trying my best to keep up with this blog as well as my small business forum. And of course there are the smaller projects that keep popping up that I somehow manage to fit in to my schedule.

While I’m doing all this I realize I’m trying to completely overhaul my entire design and development process. Last year I moved toward responsive design, which upended my entire process. Responsive practices continue to evolve every day as the community is still sorting them out.

Just to give you an idea I have files set up to collect information about the following for future blog posts.

responsive content
responsive text
responsive layout patterns
responsive navigation
responsive experience
responsive images
responsive workflow

These last few weeks you can see I’ve been rethinking css practices as I try to move from a style of css that favored descendent selectors to a new more modular approach, one that will lead toward using a css preprocessor and compiling css instead of writing it on the fly.

It also seems like a good time to leave the cowboy coding behind and stop editing live files on the server. Time to get on boards with version control, likely using Git and Beanstalk.

Did I also mention that while I’m undergoing this complete change in workflow I thought it would be a good time to really learn jQuery so I can better enhance things progressively from a mobile first mindset and while I’m at it why not give a new code editor a try as well as giving Zen Coding a look.

Additionally I’ve noticed how I’ve let some of my WordPress skills slip while I worked to improve my design skills so those need a new round of learning, including both BuddyPress and probably bbPress.

Here on the blog I want to give screen casting a try if only I could find some time to practice a few to build up some confidence. Oh and I really would like to rework my business model from more of a service based model to a product based one. I think there are a few other things I’m trying to do, if only I could remember where I put the list.

So Much to Enjoy

It feels overwhelming just thinking about it and writing it down…It also sounds great. It’s why I became a web designer and developer in the first place.

There’s always something to learn. There’s always a new challenge to overcome and master. Boring it ain’t. There’s always something to keep you excited. Why would anyone want it any other way?

The trick, if there is one, is to just keep at it and not think about how much you’re trying to do. Focus on each small task one at a time. Spend an hour today writing some jQuery code and spend a few hours tomorrow playing with flexible layouts and media queries. The forest is huge, the trees are manageable.

I’m sure I won’t get to all the things I want to do this year. I never do. I’ll get to more than I think I can right now. I usually do. And the moment I think these new things are become a bit too routine I’ll look for a while new set of confusions to keep me busy.

How about you? What are you trying to tackle this year? Does it feel like more than you can handle or do you simply dive right in?

Tuesday, 27 March 2012

Google TV Will Offer 3D Blu-ray and More

Posted: 27 Mar 2012 12:18 AM PDT

For the TV watcher in all of us, Google introduced their own version of TV viewing when they released Google TV. The small device that connects to your TV allowed you to surf your channels based on...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

No Thanks, I’ll Pass

Posted: 27 Mar 2012 12:08 AM PDT

The phrase, “No Thanks, I’ll Pass, is something that is not always a bad thing in the online business world. "No thanks, I'll pass" is a phrase that we have all heard during our careers...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

A Short Introduction to SEO

Posted: 27 Mar 2012 12:03 AM PDT

Basic Pillars of SEO If you have built a website that you are looking to promote and bring visitors to, then SEO should be something that interests you greatly. SEO stands for 'Search Engine...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

5 Ways to Design a Website in a Rush

Posted: 26 Mar 2012 11:52 PM PDT

What do you do when someone needed a website yesterday? Follow these 5 tips to help you build a quality site in a hurry. Although most of us would like to think that we put as much care, forethought,...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Linux and iPhone? Match!

Posted: 26 Mar 2012 05:57 AM PDT

You know how it goes, you love your iPhone, and you love your Linux machine. Too bad, your two loves don’t really mix and match… Your iPhone needs iTunes, and unfortunately, iTunes is...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Monday, 26 March 2012

How Should You Format Your CSS? | Van SEO Design

How Should You Format Your CSS?

Posted: 26 Mar 2012 05:30 AM PDT

Does it matter how you format and organize your css? Are there compelling reasons to writing single line css as opposed to multi-line css? Or in the end is it all a matter of personal choice?

Last week while putting together my post on SMACSS guidelines, I noticed that in the appendix, Jonathan had some thoughts about css formatting. I thought it was a conversation worthy of a post and also fit with the recent talk here about different ways to write css.

Why CSS Formatting is Important

If the only reader of our css was a browser, then how the code was formatted wouldn’t matter. We’d all minify our css and be done with it. You and I might not be able to read the minified code, but browsers would be fine with it. In fact we probably should be minifying our production code at this point.

However, we do need to read our css and likely have others read it as well. Given that human beings will be reading your css the basic goals of formatting should be.

Readability
Maintainability

While we should write code that we can both read and maintain first and foremost, we can’t ignore that other people will likely read our code at some point. We should also think of our future selves. I’m sure you’ve written css that seemed clear when you wrote, but not so much several months later when you needed to modify it. I know I have.

Different Styles of CSS Formatting

There are a variety of ways to format css, each with some pros and cons. Ultimately I don’t think there’s a single way css needs to be formatted as we all have different preferences. Still we should be aware of the pros and cons of the choices we make.

One of the first formatting choices you’ll make is to write single line or multi-line css.

Single line css — makes it easier to find selectors across a document, however it’s usually harder to find a specific property within a selector. This wasn’t so much an issue in the past when we didn’t use too many properties, but as css has given us more to play with and vendor prefixes have entered the picture, our list of properties has grown.

 #globalnav { } #globalnav a { } #globalnav a:hover { } #globalnav li ul { } #globalnav li ul a { }

Having all your selectors grouped together like above, each on a single line makes it easy to scan a file and find blocks of code that style a particular design element, in this case a global navigation bar. It would be quick to zero in on #globalnav a for example, even in a large document.

However once you start adding in some properties it’s not so clean and nice.

 #globalnav {list-style: none; font-family: 'Helvetica'; border-radius: 7px; background: #777; overflow: hidden; -webkit-box-shadow: 2px 2px 10px #ccc; box-shadow: 2px 2px 10px #ccc; -moz-box-shadow: 2px 2px 10px #ccc; -o-box-shadow: 2px 2px 10px #ccc; padding: 0; background-image: -webkit-linear-gradient(#777, #555); background-image: -moz-linear-gradient(#777, #555); background-image: -o-linear-gradient(#777, #555); }

That’s one long line of css. Not too hard to find the #globalnav selector, but not too easy to find specific properties within.

Multiple line css — is the opposite. It’s easier to find properties within a selector, since each get’s it’s own line, however it’s usually harder to find a specific selector as more scrolling up and down is needed.

 #globalnav {   list-style: none;   font-family: 'Helvetica';   border-radius: 7px;   background: #777;   overflow: hidden;   box-shadow: 2px 2px 10px #ccc;   -webkit-box-shadow: 2px 2px 10px #ccc;   -moz-box-shadow: 2px 2px 10px #ccc;   -o-box-shadow: 2px 2px 10px #ccc;   padding: 0;   background-image: -webkit-linear-gradient(#777, #555);   background-image: -moz-linear-gradient(#777, #555);   background-image: -o-linear-gradient(#777, #555); }

Much easier to read the properties of #globalnav when written on multiple lines, isn’t it? Of course the other selectors around it have probably been pushed off the screen and so finding #globalnav a might not be as quick and easy.

Organizing and Improving CSS Formatting

You probably have a strong preference for one of the two styles of formatting above. In either case there are things you can do to improve readability and maintainability.

Ordering css properties — With either single or multiple lines we can be consistent with the order we write properties. Jonathon Snook suggested an order of:

box properties
border properties
background properties
text properties
other properties

Seems like a good idea even if you prefer a different order of property groups. In the multi-line case we could leave a blank line between groups and in the single line case we might compromise and start each group on a new line.

Tabs between properties — With single line css some people have attempted to use whitespace through tabs to improve readability.

Unfortunately properties don’t necessarily line up in columns well since they aren’t the same from one selector to the next. I’ve tried this a few times and outside of special cases have never found it to work well.

Indentation of nested selectors — WIth multi-line css some will use indentation to show selector relationships and structure. The selectors aren’t technically nested, but use whitespace to make them appear that way.

 #globalnav {   property: value;   property: value; }   #globalnav a {     property: value;     property: value;   }     #globalnav a:hover {       property: value;       property: value;     }

While showing the relationships is appealing, I haven’t had much luck with this style of formatting either as I find the “nested” selectors get lost and appear to be properties of the main selector at first glance. It might just be case of needing to get used to it, though.

Higher Level Improvements

There are some things we can do at a higher level to improve css readability and maintainability regardless of your choices with anything above.

Sectioning and organizing files — At the very least we should be organizing our css files in some way. All your global navigation styles in one section and your footer styles in another. Perhaps you’d prefer all typographic styles in one location and all color styles in another.

It’s not always clear how best to organize sections though, which is what led me into this recent look at css.

Taking things a little further you might choose to use a single css file or multiple css files. Multiple files might be cleaner, but require additional http requests.

Comments — You certainly want to use comments for for major sections and probably for specific properties to remind yourself why you chose a particular value. If you still use the occasional hack for one browser or another a comment is likely necessary.

Comments need to strike a balance. Commenting everything is just as bad as commenting nothing,

Better naming of classes and ids — This is always a good idea. Good names need little explanation, though it’s not always obvious how to best name classes and ids.

My CSS Formatting Practice

You might be curious about my formatting practices. I’m ashamed to admit they haven’t changed much over the years. I still format based on habits established long ago.

Early on I made the decision to write single line css for a couple of reasons.

Less whitespace to keep file sizes smaller. This is in the days before minification.
Ease of finding selectors. I used less properties in the past

Since then I’ve experimented here and there with refining things, but nothing has stuck. When presenting examples here I do write multi-line css, since I agree it’s much easier to read for short blocks of css.

I’d like to tell you I’ve been good at commenting my code, but I can only say I’ve been good on an inconsistent level. I generally keep files organized, but the comments don’t always find their way in. I’m happy to say I’m getting better at being more consistent.

I’ve typically organized css styles in a top down approach to mimic how the html is structured, as I suspect most of you do. There are sections for base styles and common classes, but otherwise my css is typically organized as follows:

 #header { } blocks of styles relating to the header #main-content { } blocks of styles relating to the main content #sidebar { } blocks of styles relating to the sidebar #footer { } blocks of styles relating to the footer

I’m been consistent in regards to naming classes and ids, though I’ve changed my convention over the years.

Closing Thoughts

I think how you format your css is mostly a matter of personal choice. If you’re working in a team it makes sense to agree upon a consistent system, but when working for yourself it’s hard to argue against writing it your own way. You aren’t going to know the preferences of those who later read your code so why try to predict it.

Your main choice will be single or multiple lines. After that you should try to refine your approach to make things more readable and maintainable. You can organize files and properties, try tabbed or nested indentation, or anything else you think will make your css clearer.

I have a feeling my current preference is going to change once I explore css preprocessors. I think it’ll be enough of a difference to shake me out of long ingrained habits. I assume at that point I’ll write multi-line and nested preprocessed css and output minified css for production.

However, viewing source code was and is a great way to learn to code and I want to provide that resource here. Whether that means not minifying or whether it means providing a non-minified version for download is something I’ll decide when I get there.

How about you. Do you have a formatting preference? Do you write single line or multi-line css? What additional refinements do you make to improve readability and maintenance?