Tools and Workflows

We all love talking about the way we do things. Finding common ground within a workflow or over a chosen tool is an instant bond between two of us. It’s more often than not unspoken, but when it comes up that a complete stranger chose the same text editor as you (and stuck with it through years upon years of vaporware rumors) there’s a quick common ground for discussion. Beyond that, we like talking about how we do things because we like to share our successes as well as our failures. If at one point we had a major frustration, and through time and trial we were able to overcome it, it’s rare that the victory is boxed up and locked away for Me, Myself, and I. That is of course unless the victory quickly lead to a business plan with potential to transform itself into your retirement fund; completely understandable in that case. In the end though, even those ideas are revealed, albeit on a much more grand scale when compared to a blog post and a comment thread. We love talking shop. We’re also stubborn though, but in this case, I don’t think it’s such a bad thing.

Habits can be supremely productive

I catch myself telling those just getting into the industry that of course the tools don’t matter, the work does, and I fully stand behind that. I have noticed though, that once you’ve crossed the line and have some work under your belt, there is a very limited time during which significant decisions are made that can have a big effect on how you do things. After all, if it weren’t about the tools, each of us would be able to sit down at a different work station this morning and get to work in a completely new environment without issue. Imagine this:

• Photoshop user? Here’s Fireworks.
• At home in TextMate? This machine only has vim.
• Working on a logo today? Illustrator? We only have Inkscape.
• We’re not using ExpressionEngine this time around, we’re going with WordPress.
• As of today we’ll be moving from SVN to git, thanks.

Changing tools after deciding what works for you and becoming (extremely) comfortable with it is a big deal. With our tools comes a very specific workflow, something that makes or breaks our process. We’re either optimized or we’re bottlenecked, and it all comes down to the habits we execute as we work. There are definitely as many good habits as there are bad when it comes to Web design and development as far as I can see.

The other side though, it’s greener! I think…

I have a problem accepting that the tools I’ve chosen are the right ones. I know I can get the job done, but something in my head tells me that there’s a better way, a faster way, a more precise way. Am I the only one cursed with constantly thinking everyone else is doing it more quickly with higher quality and better deliverables? I often take the time to explore other tools at my disposal, usually the ones that others rant and rave about all the time. Ruby on Rails, ExpressionEngine, Photoshop, vim, emacs, git, Ubuntu, Basecamp, the list goes on for a long time. My big question though, is how we’re able to tell that the tool we’re using is the wrong one. Do we sit back and wait until our closest colleagues have made the jump and it takes an intervention for me to get on board? Should I be an early adopter in an effort to be ahead of the game once things change over en masse? What happens if I make this switch and the project ceases? Would I have been better off focusing on what works for me and trying to get better at it? The biggest question for me though is:

Does any of that really matter? Should I just be getting work done in the meantime?

Evaluation of potential tools is not something I take lightly. It takes a decent amount of time that I could otherwise be using familiar tools to get work done on my usual schedule. Is that time devoted to possibly unused knowledge a complete waste? Is it worth something to not have to wonder if Tool X is ‘better’ than Tool Y for me?

How can we be sure that the tools we’ve chosen allow us to refine and optimize for an extended amount of time? Theoretically we should be getting better at what we do with every project that gets completed. The great thing is, though, that very often our tools will update as we do. That is of course the author(s) of your chosen tool abandon the project leaving you out to dry.

It’s not about the tools, but then it is

I do stand behind my advice to new designers and developers. I don’t think a tool should influence the technologies or techniques you’re just becoming familiar with. It’s likely that whatever you sit down with first will be your tool of choice for a long time, and it will eventually take a whole lot of convincing to tell you otherwise. In the beginning, the big deal is making sure you’re understanding concepts and ideas. Without that understanding, your decision as to which tool to use has little to no merit beyond hearsay from some people you looked up to at the time.

When you’ve progressed to becoming more professional, you’ll be able to much better analyze your toolset, with actual experience and fact to back up your opinions. At that point, tools become an important choice. Or do they?

Advertise here with BSA

The thought behind it

There was a time where I nearly obsessed over this subject. I was just getting into client work and I was like a sponge when it came specifically to presenting comps to clients. As it stood, the process revolved around showing the client a ‘first round’ comp. It was a home page a designer had been focusing on some time and there was always a bit of holding our breath when it came to the client’s initial reaction. More often than not it was a very positive experience and the client gave the go ahead on interior pages. I’d speak with the designer at that point a number of times because it was usually a “Phew! Now what…” kind of moment where we’d sit and brainstorm where to go next.

The first few times I was involved with the process was exciting, it was my first professional opinion and I was eager to learn from those around me with infinite more knowledge. At the same time though, I couldn’t help but think that there was something awry with having a “Now what?” moment after designs had been client approved.

As time went on I thought more and more about the subject, I thought about the bigger picture of designing websites and began to theorize about consistency as well as detail in the design of a website. While the home page is usually thought of as the first (and possibly last) page anybody will ever see, I feel strongly that there should be a correlation between every page throughout the site. At that point in time, the sites I was working on didn’t have a level of cohesiveness I was truly happy with. Interior pages were an afterthought and at times it showed.

It made sense though, why the designers would begin with the home page. It’s the most fun to work with. You have the most creative liberty when it comes to the home page and with that you have the most elaborate design elements. It made sense from a self-satisfactory angle, but I couldn’t help but think about the interior pages. While the home page is probably the most trafficked page of your site, there is a good chance that it’s one of many entry pages.

If you’re doing things right, lots of visitors will be arriving via search engine results page. Unless they know of your company and are searching for your website, they’re probably searching for something in particular and your company happens to specialize in that area. With an interior page being the entry for an already engaged visitor, I’d conclude that it’s important for a lot of thought put into it. Sure it’s hopeful that the visitor will then move on to the home page and continue from there, but that’s not to say that the home page can’t be equally as impressive when navigating there second.

If a visitor hasn’t bounced away and decides to head to your home page to find out more about you, the experience of the interior page has prepped the stage for an unveiling of the home page, there’s still plenty Wow® to dish out. I quickly realized that it’s important to think about and design every page of a website, but further I began to realize that starting with the interior page will afford you the focus of the more generic elements, giving them the subtle attention they deserve to be impressive in their own right.

The same goes for development

These ideas quickly transferred over to my development process. I was brought on as a developer and that was my prime responsibility. I couldn’t help but be enamored with the design aspect, however. The same faults I saw in designing the home page first instantly clicked with the issue I have with developing the home page first. Home pages are (usually) the most intricate page; they’re going to have the most unique elements by far and with that comes unique markup and style.

I constantly analyze how efficiently I’m writing my style and over time have corrected a number of bad habits I picked up over time. I’m completely self taught in every aspect of development so of course I picked up some really nasty habits along the way, one of which was copying and pasting. When I first began teaching myself CSS I was a legendary Copy-and-Paster; everything is there for the taking and I used it. That’s not staying I would improperly use the work of others, but instead work from it in an effort to get my job done. With that came immense style bloat and way too many !important declarations. It didn’t take long for me to realize that something was very wrong.

One of the best features of CSS, to me, is the reusability factor. If you have a plan for your CSS from the starting line, you’re amazed at how adaptable it can be. Tie that in with an object-oriented state of mind and your CSS will always be all that it can be.

When you start marking up and styling the most generic page of a site, the structure, classes, ids, and selectors are very likely to be reusable a number of times throughout the project. They’re setting the groundwork for all of the detail layers that need to be added with each unique page.

It all comes to a head when you’re building out the home page, though. You’ll have the most unique markup and style combination of any page on the site, but the benefit comes with having to do the least amount of thinking and the most amount of specificity to get the job done. You’ll rarely find yourself backtracking because the foundation you laid will be that much stronger.

This change in thinking wasn’t all that apparent to me in the beginning. I realized that nothing clicked because there isn’t a single point in time where you realize the mistake(s) you’re making. Instead it’s a viral problem that lasts the entire span of the project and adds bloat or instability bit by bit. You (more often than not) will make a change either by being a bit more specific or using an !important declaration and move on; you’re on a budget after all. At the end, the job may be done, but you could have done it better. The stylesheet could be a percentage of what it is, your classes and ids could be that much more useful (and sparse) and your overall document structure could be more sound.

From the inside out

Building websites is a craft; it’s a craft that can be optimized in many ways, with the benefits being amazingly apparent. Do you design/develop from the inside out? Why or why not? Do you find yourself limited creatively when designing a generic copy page first, only arriving at the (more fun) home page last? If so, do the pros outweigh the cons? Have you never felt yourself limited after setting the ball in motion with the home page and having to strip things away to arrive at the lowest common denominator that is a copy-heavy page?

Advertise here with BSA

Advertise here with BSA

This was before the days of the Gedit implementation of snippets so I did my best to replicate TextMate in SciTE. It was awesome. Incorporating snippets changed the way I worked by orders of magnitude, and the implementation found in TextMate is the bar to which I compare every other editor I’ve tried.

What’s great is that snippets seem to have hit the mainstream. Besides OS X specific editors such as Panic’s Coda and MacRabbit’s Espresso, platform independent editors and IDEs have their own implementations as well. Apart from E TextEditor on Windows, however, I haven’t seen an editor implement snippets to the full effect of TextMate.

The big deal about snippets

The deciding factor for me is the ability to have multiple stops per snippet. This gives you the ability to not only share snippets (through Bundles or otherwise) but also very easily write your own. Every designer/developer has his or her own set of tricks, and a generic bundle isn’t going to cover you 100%. The great thing about a solid implementation of snippets puts the power in your hand to finish the job and add the final touch of customization you need.

I’m always on the hunt for a newer, better editor. It’s a curse I’ve had for years and one that will never go away. To be brutally honest, snippets are the only thing holding me to TextMate at this point, as there are a number of strong contenders on the market now, targeted specifically toward Web developers. They’re also gorgeous to boot.

I was to the point where I was simply waiting for the various editors to publish a few dot releases including a solid snippets implementation a la TextMate. That is until I discovered zen-coding. My mind was blown all over again.

zen-coding takes snippets to a new level

zen-coding touts itself as a “set of plugins for HTML and CSS hi-speed coding” and my gosh it lives up to the name. The snippets implementation provided by zen-coding are based on specification drafts, and a heck of a lot has been included by default.

• HTML elements (based on the HTML5 draft spec)
• HTML selectors
• CSS properties (based on the CSS3 draft spec)

Instead of going over the documentation here, I’d just like to call a bit of attention to the HTML selectors linked above. This is truly what made my jaw drop.

The biggest calling point for zen-coding for me is its implementation of HTML selectors as snippet triggers. zen-coding includes an entirely new angle to writing markup, and it facilitates the feature by letting you write HTML based on CSS selectors. It’s so simple it’s confusing at first. I think it’s best explained by doing a quick before and after. If you were to type:

div#name.one.two

and follow that with the zen-coding plugin keystroke (CMD+E in TextMate), the plugin will reformat the line as:

<div id="name" class="one two"></div>

Let’s get a bit more advanced, typing:

ul#name>li.item

will result in:

<ul id="name">
    <li class="item"></li>
</ul>

Last, but not least:

p.one+p.two

will result in:

<p class="one"></p>
<p class="two"></p>

It doesn’t stop there. zen-coding has included an even more elaborate set of possibilities on top of valid CSS selectors.

Element multiplication and variables

A really fascinating feature of the CSS selector abilities comes from element multiplication. Perhaps one of the most tedious things to mark up (when not working from existing copy) is a list (or eight). zen-coding does its part to lighten the load, quite a bit:

ul#name>li.item*3

provides:

<ul id="name">
    <li class="item"></li>
    <li class="item"></li>
    <li class="item"></li>
</ul>

By including a multiplication modifier, you can control how many child elements are included in the snippet!

The other really interesting implementation deals with variables in snippet output, which is neat:

select>option#item-$*3

gives you:

<select>
    <option id="item-1"></option>
    <option id="item-2"></option>
    <option id="item-3"></option>
</select>

By including the dollar sign, you can include a reference to the index of the element you’re multiplying. Although really specific, it could (and probably will) come in very handy from time to time.

I mean if you’re not impressed yet, I just give up!

See it in action

There are a few screencasts referenced on the Google Code page for zen-coding which illustrate the above really well:

• Zen HTML features, 1.х branch, screencast
• Zen CSS features, 1.х branch, screencast
• Aptana Zen HTML features, 2.х branch, screencast

Definitely check them out if my explanation is still a bit foggy, as the screencast really helps display what this plugin is capable of.

Compatibility

One of the finer points of zen-coding is the fact that the developer(s) are taking the time and effort to publish this genius for multiple editors both for OS X and cross-platform. Currently, according to the Google Code page, the plugin has versions for:

• TextMate
• Aptana
• Coda
• NetBeans
• Espresso

Unfortunately, I didn’t find a download link to the Espresso Sugar, but I will keep my eyes open for that as well. Update: the lead developer, in his comment below, let us know that the Sugar is included by default in Espresso releases. I’ve checked out the plugin both in TextMate and Coda and I can say that this plugin alone makes Coda a true contender for more advanced developers looking for a better implementation of Clips (until Coda natively supports snippets (fingers crossed for 2.0 bigtime)).

Note: to fully install in TextMate, you’ll need to download three bundles. At the time of this writing, the three download links are titled as:

• Zen.Coding-TextMate.v0.3.zip (implements zen-coding)
• TextMate.Zen.HTML.1.3.zip (implements HTML functionality)
• TextMate.Zen.CSS.1.3.zip (implements CSS functionality)

Be sure to install each bundle you need!

Non OS X users may find a bit of luck in that the plugin is released for both Aptana and NetBeans, two very popular IDEs as of late. Windows users should be able to use the TextMate bundles in E as you’re accustomed. While there is definitely activity on the Google Code page, I’m not positive that other editors will be supported in future releases.

I love Web design.

This is the line of thinking that really gets me excited about what I do. zen-coding has again completely changed the way I approach writing code, and has raised the bar to a new height. What else is great is that this functionality was provided out of someone else’s love for the industry as well. Their great idea is now making my life even easier, and that cycle will definitely continue in the Web design community.

Advertise here with BSA

Two types of images

As designers, we realize that there are two ‘types’ of images. Those which we reference in our style sheets which in turn inject imagery into a document, and those referenced within the markup itself.

Each type of image carries with it a specific purpose and value. At the most basic level, the fundamental difference between the two types of images is meaning. Images referenced in markup should contribute to that document in some meaningful way. Images included via stylesheets, however, should not carry with them any informational value.

I think it’s sometimes easy to forget that, even as you become a seasoned developer. The biggest issue I’ve noticed with myself, which in turn sparked my recent focus on the subject, was the arbitrary inclusion of image replacement when it wasn’t completely necessary.

Images versus image replacement

Image replacement is a technique near and dear to the hearts of many. Countless articles have been published on the subject, and it seems to be an applicable conversation to have on a fairly consistent basis. I myself have tried to add some value to the conversation by publishing a few pieces on the subject over the past couple years. Some of which include:

• Typography in Headings: sIFR? Image Replacement?
• My Latest Take on Image Replacement

Looking back on those articles, I realize that I was still a bit overzealous when writing them. I think it’s part of every developers growing process to take new techniques under his or her wing after it is first learned, and run for the end zone with it. Image replacement is one of those techniques. When we first learn that our style is completely separate from our structure, every image becomes stylistic. We want to remove everything from the document and focus on keeping our markup and lean as possible. It turns out that for many, we optimize to a fault.

As of late, I’ve been questioning image replacement itself. By definition, when we use image replacement, we’re effectively injecting a meaningful image into the style layer of a document, all the while using various techniques to ensure the original content provided from markup is hidden from view. Through this process, we make it very difficult for assistive technologies to properly recognize the content as valuable.

Looking at Monday By Noon today, we can see that not only was I overzealous with image replacement, but also itching to use an image sprite as well. I can add those two items to the list of reasons I’d like to redesign!

Taking a step back and looking at the big picture, we can see that:

1. Our markup is (mostly) solid, as we often need to include a possibly unnecessary class/id to act as a hook for our CSS
2. We’re abstracting a meaningful image
3. We’re attempting to inject that meaningful image through CSS
4. We force our original content out of sight by way of properties designed to obscure existing data

We do all of this, yet HTML has provided us with an element dedicated to taking care of everything in one fell swoop. I’ve come to realize that img is an underused, undervalued element by many developers.

Remembering to use img properly

HTML provides us with the img element. Not only can we include our meaningful images (i.e. headings) within the markup as intended, we can provide directly applicable alternate content (alt attribute and longdesc attribute) directly within the original document. It is by far the best way to gracefully degrade for imageless browsing, and abundantly more straightforward than any of the various image replacement techniques available to us.

We can’t forget the reasons we’ve tried and tested image replacement techniques, however. Modern Web design is far and beyond more complicated than HTML and CSS can support alone. We’re using the tools to their fullest potential, and then some. We have to get creative sometimes, and image replacement originated from a need.

My personal focus for the past few projects has been to get back to basics and use images in their original intention, and I must say that documents feel more stable, more structured. I like that I’m not obscuring information in any way, instead using the gifts HTML gave us to provide a seamless experience.

This approach has really only come into play for me when it comes to headings, more specifically static headings. Dynamic headings are a different subject entirely, something that deserves an entire article. The biggest hurdle with headings, however, is to make sure they blend with the surrounding environment. Make sure you’re using the Matte when saving a transparent GIF for Web, it will make your life that much easier:

Setting the matte on a transparent GIF will help you to match the edges of text to the background over which you’re laying the image. You’re probably wondering why we don’t use PNGs instead. I won’t get in to details but it starts with an I, ends with a 6, and has an E in there somewhere. Enough said on that topic.

Using images directly within headings can be an effective way to retain document structure for assistive technologies and search engine friendliness. Your heading markup can look something like:

<h1><img src="images/companyname.gif" alt="Company Name" /></h1>

Google should much prefer something like the above as opposed to an obscure image replacement technique. The information is blatantly available, and there is no overlapping meaning when it comes to the separation of structure and style, right?

In conclusion

I hope this throwback topic helps you to analyze how you’ve been using images in your designs as of late. Perhaps you, as I did, needed a quick refresher on the overall document as opposed to overusing a particular technique when it may not be needed.

Advertise here with BSA

It’s been a long time coming

The debate has raged for quite some time, and many people have taken a stand on the matter, including myself. From the people I talked to, most had taken a stance on one side of the line, and been comfortable in doing so. Each camp had good reason behind its decision, but HTML 5 is now the official victor.

The response to the announcement has been very… interesting. There is quite a bit more misinformation out there than I had originally expected. I realize that not every developer writing markup is going to know the defining characteristics of such emerging technologies, but there are some misconceptions out there that just don’t fit. If you’re at all confused behind either technology, there is a ton of information out there, and I highly recommend you bookmark a few articles to read at your leisure over the coming weeks.

• A List Apart: A Preview of HTML 5
• A List Apart: Semantics in HTML 5
• XHTML 1.0 vs. HTML 4.01 (or HTML 5)?
• X/HTML 5 Versus XHTML 2
• Setting the Standards: HTML 5 vs. XHTML 2

Reading a few of those articles should really help you to begin to understand the fundamental differences between HTML 5 and XHTML 2. They will also help you to recognize the similarities as well.

What it means to you

One of the most interesting pieces of commentary I’ve come across to date on the subject is the reactions posted to Mr. Zeldman’s XHTML DOA WTF. It’s obvious from that comment thread alone that there is far too much confusion surrounding this decision that has been made by the W3C. Many people don’t understand the true effect this has on our future work, and fail to see the benefit of such a decision being made. Also a very interesting read, specifically as a follow-up to Mr. Zeldman’s comment thread, is Comments on Comments on Zeldman’s XHTML [DOA] WTF.

A great way to continue the streak of knowledge is to check out a great resource that has bubbled up recently: An Unnofficial Q&A about the Discontinuation of the XHTML2 WG. Although unofficial, it is by far the most targeted Q&A I’ve seen so far. A big take home message in the Q&A is this:

Did the W3C kill XHTML2?

No, XHTML2 was already dead for all practical purposes due to its failure to be backwards compatible and its failure to deliver compelling new features. The W3C just announced they will take it off life support.

XHTML2 has indeed been dead for some time, the announcement only makes it as official as it could ever be.

It’s a great move for everybody

I’m a huge fan of HTML 5, and I was pleasantly surprised to see the announcement from the W3C last week. I’ll also go on record saying that although it was beyond the scope I had imagined, the reaction of many developers is completely expected. Unfortunately that’s a result of not enough self-education, and will eventually sort itself out. I will continue to prefer HTML as opposed to XHTML simply because I will continue to enforce the aspects of XHTML I really enjoyed in the HTML I’ve been writing and will continue writing. Another piece to take home from An Unnofficial Q&A about the Discontinuation of the XHTML2 WG is:

If I upgrade from XHTML-served-as-text/html to HTML5, do I need to revise all my empty tags?

No. HTML5 permits both the XHTML-style syntax (<br/>) and the HTML 4-style syntax (<br>) for void elements (elements that never take any content).

The syntax rules seem to be the most common denominator when it comes to XHTML fans. You can still write markup in a very strict way, but you’ll need to enforce it yourself as the rules themselves are more lenient.

Last, but absolutely not least, how can you not like this:

What’s the doctype for HTML5 documents?

Simply: <!DOCTYPE html>

There is quite a bit of great information in An Unnofficial Q&A about the Discontinuation of the XHTML2 WG and you should assign it to yourself as required reading this week, along with a number of other articles on HTML 5 and what it means to everyone, not just us writing the markup.

Advertise here with BSA

What you can learn

By far the largest resource available on Let’s Make the Web Faster is the collection of articles available. The articles are put together quite well, involving a good blend of video and supporting imagery. You’ll be able to quickly learn the background behind some of the jargon used in document optimization.

Articles aren’t limited to front end development, because there’s more to writing markup and style if you’re a Web designer. Google takes the time to discuss other relevant areas such as the optimization of Web graphics for faster download times without losing quality. There are also articles on optimizing your JavaScript and even some PHP performance tips. One of the headlines that first caught my attention was UI Messaging and Perceived Latency — what a great topic. Google also includes a number of links to various Tech Talks @ Google, which are always a good watch.

Let’s Make the Web Faster launched as a very information-rich resource, and I imagine Google will be adding new articles fairly consistently from here on out. What’s great is that Google has done its part in retaining the community value of Web developers by devoting a section of Let’s Make the Web Faster to the community, opening doors for your input.

As with everything, be wary

Just because you read it on the Internet, the information you got may not be bulletproof, even if Google wrote it. Articles attempting to Debunk Google’s Internet Optimization Tips are beginning to crop up, and I think it’s great. Google suggests a number of techniques, actively put in practice on many Google products, that I will personally never employ just because it skirts around a rule or two. Saving a few bytes by writing sloppy code just isn’t something I’m interested in doing.

Like every Web designer, I’ve worked in PHP. I tend to really like PHP, but I don’t know PHP on the intimate level that programmers know PHP. I’m still learning about how the language itself actually works. I’m specifically interested in what PHP does differently than other languages which causes it to be huffed and puffed upon by so many.

It’s very interesting to read that some of the PHP optimizations suggested by Google may not be entirely accurate. I always enjoy reading technical pieces written by programmers who will always know more than me about programming. The existence of such a thread shows the nature of the PHP community, and it’s good to see that even Google might not know everything after all.

The important thing to keep in mind when reading Let’s Make the Web Faster, as with reading every article on the topic of Web development, is to take everything with a grain of salt, and to not follow the advice blindly.

Page Speed for Firebug

Everyone knows about Firebug. It’s arguable the most widespread, actively used tool by the majority of developers and designers, and for good reason. The tool changed the way many people approach front end development, and it was a true game changer.

Some time ago, Yahoo! released an add-on for Firebug called YSlow. The tool aimed to help developers analyze documents and suggest optimizations not only for speed, but rules for optimization. YSlow proved to be very helpful for many people, and I know I learned a thing or two about some of the techniques I had been using for quite some time.

As part of Google’s initiative, they have released Page Speed, also a Firebug add-on aimed at page performance analysis. After installing the Page Speed add-on, you’ll notice a new tab within Firebug:

As with YSlow, you need to invoke the analysis by clicking a button quickly after navigating to the document you’d like to test. After completion, you’re provided with a very detailed report containing a breakdown of the criteria against which your document was run:

Additionally, Page Speed takes another step forward in offering to apply a number of optimizations to your document immediately. For instance, if deemed necessary, Page Speed will go ahead and minimize your JavaScript on the fly, as the browser downloads the JavaScript, having an optimized version ready at any time:

The last feature within Page Speed I’d like to tout is the CSS analysis. Beyond suggesting the combination of CSS files to reduce the number of HTTP requests, Page Speed will examine your style sheet on a per-line basis, letting you know what could be written better:

Page Speed will separate your ‘very inefficient’ and ‘inefficient’ rules and let you know what makes each less than ideal.

As with YSlow, Page Speed has links throughout the panel directing you to the information backing up the suggestion, found on Google’s Let’s Make the Web Faster. I would suggest that everyone have Page Speed at the ready during a testing phase of a Web project. It will make sure your documents are top notch concerning performance, and you’ll become a better developer because of it.

There is an abundance of information available if you’d like to read a bit more before installing Page Speed. Even if you’re not a Firefox user, I absolutely suggest keeping it on hand not only for render tests, but optimization tests using Page Speed as well.

Overall impression

There is a lot to learn as far as Web page optimization goes. As new technology appears, you’ll have to learn even more, but it’s an important aspect of Web design and a valuable part of the medium. It’s important for you as a professional to know how to produce work of the highest caliber, and optimizations can do a great deal to make your work feel that much more polished. Google’s “Let’s Make the Web Faster” is a great platform that should help spread the word very quickly to a large audience.

I hope to see Google continue developing content for the recent project, and I hope to see a decent community response, especially debunking any poor advice Google may be giving by offering detailed responses. While certain practices may achieve the most desirable result, it will be up to the community to ensure that the actions aren’t welcoming detrimental side effects causing more problems than before.

Advertise here with BSA

That said, depending on your billing structure, you’ll be able to optimize your workflow in such a way that not only reduces your stress level, but will make your clients happy to boot. I mention a dependence on your billing structure simply because sometimes getting a project done well under a time-based budget can result in trouble for you financially. The important thing to realize, however, is that with newfound extra time comes extra polish. If you come in a few hours under budget, you now have the time to try that element you were toying with in design. Does it work now? How about the leading in that area? Would it look better if it were bumped up, just a bit?

Reducing the time you spend on front end development can lead to more experimentation and a better end product should you have extra time to play with late in a project. Personally, I like to keep front end development estimates to a minimum, allowing the budget to focus on design. I work with a team of designers, so the better we plan from the start, the better a project will go.

Have a plan, start with a static file

By far the most effective way to cut down on front end development time is to be involved in the design process. You don’t even have to be the designer, but you should periodically review any design for a basic feasibility assessment. That’s not to say that you should be prototyping designs to make sure something is going to work, but you should be able to process a design to a level that will let you be comfortable with it.

As you examine a design, try to abstract your brain from admiring the aesthetics of the design. Try to visualize how you will approach the front end for this document. Take a look at a comp for another page, can you determine how much markup and style you’ll be able to reuse from the first page to this one? Are there any modifications that should be made to the design to establish some consistency on a more technical level? Take a second look at the design, take a third look. Has someone added a gradient or texture that physically can’t translate to the Web?

Once you’ve signed off on approval for a design and it comes time to begin work, I can’t emphasize enough how much it will help you to start with a static HTML document. Stay away from your server side technology, no matter what it is, and instead use a static file that takes advantage of any dynamic resources you’ve set up.

For example, at my company we’ve established a site framework that we use to begin each project. In this site framework is your usual array of template-supported, server-side powered files that tie in directly with our CMS, and the like. Alongside this set of files are two static files: home.html and secondary.html. These are the first two files I’ll open and work with on a project.

The files are prepped in such a way that the path to the CSS directory is hard coded, removing the need to copy and paste once our original documents have been written. I’ll work my way through a secondary page, then the home page, and once that’s done, I’ll integrate.

Write your markup first, all of it

Nearly two years ago, I wrote about my development and design process. Much of my strategy remains the same to this day, specifically the first steps I take. The initial markup process ties in heavily with the original review of a site design. From the first time I open a PSD or PNG my mind begins working, breaking down the design into markup and markup alone.

I’ll break apart the design into sections, until I’ve found myself at the lowest common denominator, whether it be an h3 or an li. Once I’ve got a general idea of the overall structure, I’ll write it. All of it, from #header to #footer. I’ll switch to and from Fireworks (or Photoshop) and my editor, making sure all of my elements are in place.

Writing the initial markup for a document doesn’t take very long, an hour if you take your time. There really isn’t that much to it, especially if you’ve had a look at the design as it was being put together. You already know what to expect, and you can hit the ground running.

The important thing to keep in mind at this step is optimization. Don’t move on to CSS until every bit of markup is in place to support the design. Sure, you’re probably going to have to add an element or two as you continue development, but getting the initial structure entirely in place will be super helpful when it comes to the style layer.

Use a reset stylesheet

I can’t stress enough how helpful a reset stylesheet is when it comes to optimizing your front end development. It doesn’t have to be Eric Meyer’s reset stylesheet, but working from a consistent base is extremely helpful when it comes to building out your CSS, even more-so when it comes to The Browser Gauntlet.

Write CSS in blocks

I can remember my first few weeks with CSS; I’ve never been so excited to refresh a browser, and I never will be again. With each refresh came a new and exciting change that I was struggling to understand. Learning about CSS was very exciting for me, but it forced me to implement designs slower than ever. As with everything, the more you do, the better you get. As your skill with CSS grows, force restraint on yourself when you think you need to refresh the browser.

Chances are, that property:value; you just set is going to work out just fine. Move on to the next, and the next. Finish setting all the properties you want for that selector and then switch over to refresh. Once you’ve become comfortable with that, style an entire div before refreshing. Once you’ve become comfortable with that, structure your entire document before refreshing, and the move on to styling each div you just positioned.

The more CSS you can write in a single thought, the better and faster you’ll be. The important thing to keep in mind, though, is not to write too much at once. As you’re forcing yourself not to refresh, you may make a significant mistake that wreaks havoc on a few dozen lines of later CSS. Push yourself, but don’t push yourself too far too fast.

Save JavaScript until last

Exciting as it may be to implement, make sure you’re postponing all JavaScript development until last. Integrating JavaScript too early is going to destroy the integrity of both your markup and style, and will cause more trouble than it’s worth.

Instead, take the time to develop the markup and style for any states you may be integrating with JavaScript, and make sure they’re ready to be toggled (or otherwise) via JavaScript. Abstracting markup and style from JavaScript can help you to focus and optimize as you put together a design.

Take advantage of helpful tools

My last tip is something I depend very heavily on; finding the right tools for the job. If there are any applications under consistent development and refinement, it’s Web development applications and tools. Even browser makers are now giving us gold platters with which to work through built in developer tools.

First, find yourself a great text editor. Who cares what everyone else is using, find something that you enjoy working with, and most important: something stable that saves you time. I can definitively say that TextMate (Windows users: e text editor) has had significant impact on my development time.

There are plenty of fancy tools out there, but I can’t stress enough the importance of your editor.

Along with your editor, another integral part of your workflow is your browser of choice. Your browser should support your efforts, providing the tools you need to get the job done. Toolsets for browsers have been talked to death, but a favorite tool of mine has never received much press, and I’d like to heavily suggest your adoption of it.

ReCSS is a bookmarklet that comes from dojo and it’s something I use on a very consistent basis with every project. The sole purpose of the bookmarklet is to force a reload of CSS used on the current document. This helps you to avoid reloading the entire page (including server processing and other latency) and instead request only the latest stylesheets. It’s such a simple idea, but I’ll use the bookmarklet at least a few dozen times per-project to ensure that I’m not dealing with any caching issues.

Let’s have it

Do everyone a favor and post your favorite time saving front end development tip or trick.

Advertise here with BSA

When it comes to websites though, seeing a website built in Flash is a near guaranteed turn off personally. To me, a website built in Flash forks away from the inherent purpose of a website, and turns into a novelty. From the most generic standpoint, my opinion doesn’t even generate from the accessibility and performance concerns that come from a website built in Flash. It’s the usability of the website, the fact that it’s just, different.

However, many clients are attracted to websites built entirely in Flash. To me that comes from an interest rooted in everyone: motion. Things that move are, by default, more interesting to look at. I think I’ve discovered that my distaste for such things comes from a personal appreciation that has evolved as a Web designer. To me, a website with a solid design, solid information architecture, is extensively more pleasing than something that glows and animates left to right simply for the sake of visual stimulus. Information architecture, to me, is that visual stimulus, and making it move around completely detracts from my experience.

I don’t mean to say that a Flash site, by default, lacks anything from an information architecture point of view. In fact I’ve seen many Flash based websites that were designed terrifically, I simply would have preferred to view it as markup and style. I have the upmost respect for Flash designers & developers, as some of the work is simply stunning. I’m speaking from an abstract personal preference here, full of my own bias. I don’t mean to offend and I hope this isn’t coming off with any sort of attitude.

Working with Flash as a front end developer

I think my opinion of Flash based sites comes from my position as a Web designer. Specifically I’m a Web designer with a focus on front end architecture, quite different from a Flash designer. I’m a big believer in great teams working very well together, and my company has some terrifically talented Flash developers that I work with every day to create stunning pieces that please our clients. I need to put my opinions aside and make sure that the client gets what he wants, all the while making sure the website has an equally effective and useful alternate site to use. That involves a revised design to accommodate the variation in medium, as well as the development and deployment of that website for use.

One of the greatest things to ever happen to Flash, in my opinion, is SWFAddress by Asual. SWFAddress is:

SWFAddress is a small, but powerful library that provides deep linking for Flash and Ajax. It’s a developer tool, allowing creation of unique virtual URLs that can point to a website section or an application state. SWFAddress enables a number of important capabilities which are missing in today’s rich web technologies including:

• Bookmarking in a browser or social website
• Sending links via email or instant messenger
• Finding specific content with the major search engines
• Utilizing browser history and reload buttons

Basically, what SWFAddress does is give Flash the ability to behave that much more like a regular website by enabling the built in functionality of the browser within the Flash movie itself.

Using SWFAddress is necessary when working with a Flash website, not only for the inherent functionality improvements, but also to the benefits of your alternate site. The Asual team has included many examples of SWFAddress as well as documentation for each, the one to focus on is the SEO Example. This sample demonstrates what SWFAddress can do to integrate your Flash site with your alternate site seamlessly, allowing for effective search engine indexing, as well as equivalent access to your alt site.

The demo provided gives you access to a bit of PHP that handles quite a bit of redirection when it comes to processing a URL request. The script will help to determine if the visitor does indeed have Flash/JavaScript and in turn provide the proper “enhanced” URL, while passing site content to a user without the ability to view the Flash site. Clean URLs are retained and it’s actually a very effective solution.

Making an effective alt site

Building a Flash site is quite a bit of work, not only on the Flash side of things, but the development and maintenance of the alternate site as well. SWFAddress will route your traffic effectively, but you’ll need to manually distinguish which pages should serve which content and make sure equivalent content is represented in both websites.

With a content management system, you’ll be able to pull the same data per page via XML or otherwise, allowing both the Flash version of the site as well as the alt site, to pull from the same data source which will remove any discrepancy when it comes to content.

The inclusion of SWFAddress helps to tackle many of the baggage of Flash, and allows Web designers to create a very effective alt site both for the sake of search engine saturation, but even more importantly the benefit of accessibility.

What do you think?

What’s your opinion on Flash? Has that boat sailed when it comes to full websites? Will we see Flash only used when really necessary, for rich site widgets, video (until HTML5 becomes available), or other implementations limited to Flash? Does it bother you when you find yourself at a website built entirely in Flash? Does SWFAddress help with any issues you’ve got with Flash? With the advancements in front end technologies such as CSS3, CSS animations, canvas support, and O3D, do you think Flash is steadily taking a back seat for things to come? I’m just not sure if I’m alone here, and would love to hear some other opinions.

Advertise here with BSA

Of course I still support IE, and I don’t want to bring that up for debate at this time. That poor horse has been long gone for quite a while, so we can all put our sticks down for a bit. I have, however, taken a more aggressive personal stance in my lack of attention to detail when it comes to that browser family.

A tweet by Jeffrey Zeldman really got me hooked to the prospect of further adoption of CSS3:

When all browsers except IE support CSS3, it will test the limits of progressive enhancement as a design philosophy.

With my further embrace of and focus on CSS3 came an increased interest in other bleeding edge techniques in Web design, primarily CSS animation.

Does CSS animation belong?

One of the ways in which I’ve been trying to raise the overall comprehensiveness of my projects is incorporating CSS animation where it may enhance the experience of a particular design. Animation in CSS has, from time to time, been a hot topic in Web design. Does animation belong in CSS? Does it constitute behavioral modification to the document, and therefore find its proper place through JavaScript? Is animation technically behavior?

Trying to classify the true placement of animation has proven to be a personal challenge to me. I can see both sides of the argument. I agree that animation can be correctly implemented through JavaScript, as has been done for some time. On the other side of my personal coin, I see that animation is more of a visual stimulus as opposed to direct behavioral change (e.g. updating the DOM with data received via AJAX).

The basics of CSS animation

As with all new technologies, you should take a minute to familiarize yourself with implementation as well as implication to make a more educated (and therefore accurate) decision to (not) use it.

The WebKit team provided a very nice write up upon the release of a nightly build that supports CSS animation. In the post, an overview of animation with CSS is provided, as well as a bit of documentation and example.

The WebKit implementation of CSS animation has a bit of a learning curve, but once you decipher how it works, it’s quite elegant (in my opinion). Applying a CSS animation comes in two steps. You’ll first designate your style as you would normally, defining any properties you’d like, with the addition of something new: -webkit-transition.

-webkit-transition is actually shorthand for three transition properties:

• transition-property: The property to which the animation will be applied
• transition-duration: The length of time the transition will last
• transition-timing-function: Possibly better explained as the easing method you’d like to use

With these three properties, you’re provided a set of tools that can directly affect the richness of your designs, bringing the level of interaction up a notch or two. To make things even more elaborate, the WebKit team has also included support for comma delimited transition declarations, allowing you to animate multiple values using a single property declaration.

A finished implementation of WebKit CSS animation may look something like this:

div.message a.dismiss {
  opacity:0.2;
  -webkit-transition:opacity 0.3s ease-in-out;
}

div.message a.dismiss:hover {
  opacity:1;
}

If you’re using a recent build of WebKit that supports CSS animation, check out the example.

CSS animation can have dramatic affect on your designs, especially in Web application enahcements. Jonathan Snook recently published a screencast outlining his use of CSS animations while playing with Titanium, a platform I’m actively researching as well.

Jonathan’s use of CSS animation in his screencast really brings its potential to the surface. With animations such as the combination of scale and opacity to achieve stellar effects really helps to make CSS animations shine.

What should control animation?

Truly classifying CSS animation has been a personal challenge for me as a designer; what are your thoughts? Do you feel that animation belongs in the realm of style or behavior? Do you feel animation is something else entirely? Now that an option beyond JavaScript has surfaced, did that change your opinion? Do you see animation in CSS being continually adopted on a more consistent level when it comes to adding ‘that little something extra’ for those using an applicable browser?

Advertise here with BSA