I’m really thrilled to be able to announce the soft launch of SuggestRSS v1.0! If you happened to check out the site in its first incarnation, you may have thought it was neat, but you also must have thought id had a ways to go; it did.

Due to scalability issues, I was forced to take the site offline nearly eight months ago. I wish I could say that I’ve been working on it consistently since then, but that’s not the case. Instead, I took the experience for what it was worth in an educational sense, and let it sit for a short while. The project was always on my mind, but the limiting factor was actually limited experience.

I’ve worked with MySQL before. I’d be willing to wager that it would be quite uncommon to find a Web designer who hasn’t at least toyed around with the basics. When so much of our world revolves around a technology, it’s hard to keep your hands off.

What better way to learn?

Before writing the original release of SuggestRSS, my experience with MySQL was fairly limited. I understood the concepts for the most part, but advanced queries were out of my league. I wrote the first version by the seat of my pants and quickly realized the site wasn’t ready for prime time when it couldn’t scale past the initial user push.

I’ve heard a few designers mention it before, and I’m glad I’m not the only one who feels that sometimes the best way to learn something is to commit to a project outside your comfort zone. The first version of SuggestRSS was definitely outside my comfort zone, and I loved every minute of it.

It was really thrilling to me to have something I spent a significant amount of time on come crashing down within 72 hours of use. The knowledge I gained while writing the application the first time allowed me to instantly identify the multiple bottlenecks in the system. The downside, however, was my not having the knowledge to resolve the issues at hand.

Hit the books

I now had a detrimentally resource hogging application with what I see as quite a bit of potential, so I started researching how the heck I could make it work. I had a number of chats with my Overit Media cronies (lookin’ at you JR, Scott) and they offered some really useful suggestions that definitely got me thinking about what changes should be made, and fast.

With that jumpstart, a number of epiphanies quickly followed. You know, the ones that should have been in place from the get-go. Once the major bottleneck had been overcome, I instantly became determined to relaunch SuggestRSS. My only regret is it taking over six months for that inspiration to strike.

The latest SuggestRSS

The SuggestRSS you see today is a product of a couple moths work (I really wish I kept track of the hours, personal curiosity) and lots of reading. The underlying concept is the same: find some new feeds based on the feeds you currently subscribe to.

The biggest difference by far with version 1.0, besides the design, is that you now have the ability to ignore any suggestion you’d like. Many users the first time around said that while the suggestions made sense, they were mostly sites purposely ignored due to lack of interest or personal preference. You can now bring that omission to your SuggestRSS results.

Future plans

I’d really like to first see how this version scales. Pending any major disasters, I’ve got a boatload of small features and changes I’d like to make over time, but the biggest effort will be put into the suggestion algorithm itself. I’d really like to take as many factors into account as possible in an effort to focus on what I like to call targeted outliers, just so the site can point you in some directions that might otherwise go unnoticed.

I hope you take a minute to check out the new and (vastly) improved SuggestRSS! For the time being, I’ll be making any announcements or answering questions primarily through @SuggestRSS so certainly give a quick follow if you’re interested in any further updates coming down the pipe!

As a side note, with this soft launch I’ll again be able to focus on finishing a few of these articles and getting back on a more strict Monday By Noon schedule. Thanks so much for bearing with me while it’s been slightly quiet around here, I appreciate it.

Advertise here with BSA

WordPress has had security breaches in the past, and there will be more in the future. That’s just the way it is. Attempting to classify any piece of software as completely void of security holes is a lost cause, and no software should be held to that standard. It’s up to the end user to take it upon himself to analyze the software and make an educated decision to use it. While it doesn’t remove responsibility completely, to WordPress’ credit, this most recent issue took hold only on outdated versions of WordPress. If you have been keeping your WordPress install(s) up to date, you were already covered when the incident first became widespread.

To me, the issue here lies with end users. WordPress is an extremely popular content platform. Millions of users happily publish their content to the world using the system, and that’s the extent to which they know about it. If I had to venture a guess, I would speculate that the majority of WordPress users have never actually installed the system, or are even aware if their version is the most current. Therein lies the problem, but that problem is in no way limited to WordPress itself. That is an issue with any piece of self-hosted software; there is an issue of responsibility on the owner himself.

There’s always a tradeoff

A larger segment of backlash directed toward WordPress revolves around the fact that it’s self hosted, that most of the end users wouldn’t know how to upgrade or even that it were possible. That’s not WordPress’ fault. That’s the fault of either the site owner, or the Web firm who set up his website. Someone needs to retain the responsibility of maintaining the install, it can’t be left to rust. If you’re handing over the keys to a client, you need to make him aware of the ramifications of your decision to use a self-hosted application. You’ll need to explain that the software will need to be maintained and kept up to date, if for nothing else, to avoid security issues. That puts the pressure on him. The other option is to make sure your client WordPress installs are kept up to date. That puts the pressure on you. One way or another, that decision needs to be made along with the original analysis regarding whether or not WordPress will effectively facilitate the project.

I use WordPress for the majority of my work. I know WordPress inside and out, I love the system, and I love the community. I know and expect there to be issues from time to time, and I take the time to make sure my WordPress installs are kept up to date. Not to toot a horn or anything, but I’ve never had a security issue with WordPress, and if that’s simply from keeping my installs up to date in reasonable intervals, I believe that’s a tribute to the WordPress team and community.

I realize that I’m running a risk by self-hosting my platform of choice, but there is no way I’ll ever return to a hosted solution simply because there are too many hoops to jump through. I prefer to hit the ground running, know what I’m doing, and get the job done in the fastest (most custom) way possible. Hosted solutions simply aren’t my choice solution, and as far as I can tell, it’s going to be some time before that’s the case (if ever). That’s a super opinionated statement, but I feel it’s important to convey that I do keep up to date on hosted solutions and consider each in comparison to WordPress as updates are rolled out.

Don’t be lazy

It’s tough to hear the integrity of WordPress be put in question because of lazy admins. To me, that’s what it comes down to after all. I’ve heard excuses left and right about why people don’t upgrade, right down to it being too time consuming, but it all comes down to laziness. The WordPress team has made the upgrade process a literal “click of a button” in the past year. It doesn’t get much easier than that. If your theme might break with a plugin upgrade or an upgrade to WordPress itself, write better themes. Your code should revolve around the fact that WordPress (and her plugins) are going to update, and it’s going to happen often. To moan about maintenance work is just a lazy excuse in my opinion.

I understand that there are other systems out there that don’t demand such care-taking, but I’m the type of person that wouldn’t simply let a version of software sit simply because I don’t take the few minutes to perform some maintenance. I would wonder why anyone would take such a stance to be honest with you, at least anyone in this industry for that matter. Why would you want to knowingly settle down with an expired piece of software?

Taking it for what it is

We know the issue of ‘Windows syndrome’. Crackers will spend most of their time and effort on the most popular system; you get the most bang for your buck. Not only is the software everywhere you look, it’s maintained by an exorbitant number of under qualified people. Unfortunately, WordPress fits quite snug in this classification, and that’s a major reason you’re seeing security issues get so much attention.

On top of that, WordPress is open source. Crackers have been given potential security issues arranged beautifully on a silver platter. More often than not, that works for the benefit of the community, and security issues are squashed before so much as a photon of light can provide exposure. In the eyes of security, this could be looked at as a con in comparison to a hosted solution. Without direct access to source code, malicious intent is much more difficult to bring to fruition. That’s why you aren’t seeing these security announcements from other self-hosted or hosted solutions, the access and desire just isn’t there.

I’m not trying to make excuses

Of course I would prefer to not read these security bulletins about WordPress, but I take the responsibility associated with my decision to use WordPress and this comes with the territory. If you’re a WordPress user, just make sure you understand that this is part of the job, and if it’s not something you’re interested in, you should start examining other solutions. If you’re not a WordPress user, take the experience for what it’s worth, and give your application of choice another rundown solidifying your decision to use it.

I’m also not trying to start a flame war here, it’s just disconcerting to hear the instant dogging of a system that many of the nay-sayers aren’t even using. I suppose that’s the way of the Internet and will always be the case, I just hope that many people take the high ground and realize this, like everything else, is both a learning experience as well as a reminder.

Remain educated. Don’t take software for granted. Make sure your scheduled backup systems are in place, make sure your software is up to date, and don’t be a lazy Web designer.

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

The way you write your CSS today depends heavily on what you were initially taught (self or otherwise) in conjunction with other things such as what you’ve read that counteracts your teachings, as well as the level of desire to improve your craft. I like finding out the lessons learned behind your reasons (or lack thereof) for writing CSS the way you do.

I really enjoy writing about CSS, and if you’re a fairly recent subscriber, here’s a quick breakdown of my tips, tricks, and suggestions from the past:

Write Better CSS

One of the earliest articles I had written for Monday By Noon, but I still practice much of what was written over three years ago.

Improving Your Process: CSS Techniques Part 1

In the first part of the Techniques series, I mentioned a few ways that I tried to be more organized with my CSS writing, especially when working with a team. I have made some revisions since the publication of that article, specifically in dealing with browser defaults. Apart from that, I still stand by the advice offered in that piece.

Improving Your Process: CSS Techniques Part 2

In this article I made public my switch to using a reset stylesheet. I also tried to put into words some of the thought process behind my front end development process. You won’t find many code samples in that article.

CSS Organization Methods and Writing Style

This article was all about writing style. Style as far as comment blocks, overall stylesheet organization, right down to single line versus multiline. I touched on the idea of using flags as a hook for searching to quickly find various sections of your stylesheet, but that didn’t catch on with me.

With that reviewed, I’ve got a few other things I’d like to share as far as my CSS writing style is concerned.

It’s about patterns

One of the best habits I’ve found for myself is the desire to find patterns in designs. Patterns go a long way in design, and every good design inherits a certain level of pattern. Whether it be in organization, texture, or otherwise, a pattern provides consistency, and you’ll see patterns everywhere on the Web.

It will be in your absolute best interest to discover these patterns prior to writing a single line of markup or style. You want to use patterns to your benefit. Not only will finding patterns reduce your workload, it will make maintenance that much easier.

Jeff Croft recently posted an insightful article on finding patterns in CSS, but instead compared it to applying OOP concepts to CSS. I’m a big fan of Jeff, and much of my fandom comes from a similarity not only in workflow, but also opinion and thought process when it comes to Web design. In that article, Jeff puts into words something I’ve tried to verbalize in the past, and I’m thrilled to have it as a reference now.

I can see how using OOP methods in your CSS can be an eye-opening discovery, but it’s very important that you don’t become overzealous with it. As with many aspects of Web design, there is a fine line to walk when it comes to finding a happy medium with something like this. You’ll need to take a step back and really think about your implementation before taking action, else you’ll find yourself fighting an uphill battle when it comes to troubleshooting and maintenance. Using too many classes in a widespread way is going to cause trouble when you need to make a sitewide change and need to edit nearly every file on the site because you used a combination of classes in too many places.

Before I begin writing a line of markup, I take enough time to look at every comp for a website. I’ll look to see which elements, both structural and stylistic, have a repetitious property to them. I’ll keep these repetitions in mind as I write my initial markup, and then again when I’m later starting to write my CSS, and use the patterns to my advantage. Experience will help you better recognize and use patterns as you design and build more websites, but it will be a great skill to focus on throughout your career.

It’s also about structure

One of my biggest peeves when maintaining CSS is poor stylesheet structure. That is to say, when a production stylesheet has been in place for a decent amount of time, and the website has undergone some revisions, the edits were not properly put in place. Instead, declarations are sometimes simply appended to the end of the file to ensure their application, instead of finding the proper place in the file in which to make a change. I can recognize the desire to do such a thing, especially if you’re doing maintenance yourself, and the original file structure is so unkempt it would take hours to sift and organize it yourself. While the fault lies with the original author, it’s something that should be entirely avoided from the start.

I don’t mean to say that the way I write my CSS is a superior way to do so, my point is that you need to have some structure to your stylesheets. The technique I use for structuring my stylesheets is roughly the following:

1. Global styles such as ‘main’ copy properties (size, color, font) at the top
2. Global structure definition (main (secondary) page structure)
3. Header styles
4. Content area styles
5. Sidebar styles
6. Footer styles
7. Per-page specific styles

My basic reasoning is to work top down as far as specificity is concerned. I’ll work from the most global properties down to the most detailed as I work through a stylesheet. I try to keep things organized with how I think in a way. I’ll start with the main structure of the document, and then continue to style the header, content area, sidebar, and footer, respectively.

Once the more generic, consistent styles are taken care of, I’ll set up sections of the stylesheet specifically for one-off pages in the site should the design require it. Proper attention is given to these groups of styles via comments outlining which page is associated with a set of selectors.

Working in such a way will help you abstract which edits will affect the site in its entirety as opposed to the single instance you’re trying to modify. When working on a site you didn’t originally style, it’s very easy to make an edit that may in fact destroy a significant portion of the site you’re not even aware of.

Do you consitently keep your CSS in check?

Is it strange that I still put this much emphasis on the quality of my stylesheets? Are you at all interested in how other people write CSS or do you prefer to work in the way you’re comfortable? What techniques do you use when organizing your stylesheets from a more global perspective, as opposed to writing comments here and there for reference?

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

I work primarily in jQuery when I write JavaScript. I’ve become very comfortable with the library, as it meets my needs on a very consistent basis. I’m not biased, however. With each project, I evaluate whether there’s a need for a full library such as jQuery. There have been many projects which simply didn’t need the full functionality of a library as feature-rich, and therefore bigger in file size, as jQuery. Many times I’ll use a more lightweight library such as DOMAssistant which lets you build your own library with modules you’ll be working with. There have been many times where dLite (DOMAssistant Lite) has been more than enough to work with, this site for example.

You should evaluate which library you’re using on a case-by-case basis as well, as it seems that with jQuery being so popular, many designers simply default to using it with every project, even if they’re only binding a click event in one area of a website.

As I’ve been writing more elaborate pieces of JavaScript, I’ve picked up a bit more knowledge in optimizations. It’s become my focus lately; trying to write cleaner JavaScript resulting in faster processing and therefore a better experience for the user. I’d like to quickly discuss a couple things I’ve started doing to ease the load of JavaScript on the browser and therefore the user.

Creating reference variables

Traversing the DOM is sometimes expensive, depending on your selector. Keeping node selection to a minimum will help speed up your scripts quite a bit. If you’re working with a specific node repeatedly, it will probably be in your best judgement to define a variable with that node, instead of traversing for it repeatedly.

For example, if you need to manipulate multiple children of a parent element, it is probably in your best interest to define the parent element as a variable, and work with the children from there.

While not a gigantic enhancement, we can project the benefits on a larger scale, especially when working with a classed element as opposed to one which has an id. This comes in especially handy if you’re nesting animations, and you need to work with the initial element throughout the process. You can simply reference the variable you’ve defined instead of possibly having to hunt for a parent() or two.

While libraries such as Sizzle are dramatically enhancing node selection, it’s always good practice to write inexpensive code, and sometimes selector abstraction is the way to go.

Avoiding iterative DOM manipulation

Perhaps the biggest change to embrace was to avoid manipulating the DOM iteratively. That is to say, making a change to the DOM each time you run through a loop. This practice is definitely not limited to jQuery, but I’ll be using jQuery syntax in code samples throughout this article.

Keeping this in mind came in very handy as I was working with creating custom selects via jQuery. Essentially what I needed to do was loop through an existing select and duplicate each option value as a list item in a newly created list. At first you may write your snippet like so:

// parse all options within the select and set indices
var i = 0;
targetselect.find('option').each(function()
{
  // add the option
  target.find('.options ul').append('<li><a href="#"><span class="value">' + $(this).text() + '</span><span class="hidden index">' + i + '</span></a></li>');

  // check to see if this is what the default should be
  if($(this).attr('selected') == true)
  {
    targetselect.parent().find('a.dropdown_toggle').append('<span></span>').find('span').text($(this).text());
  }
  i++;
});

You’ll notice that with each iteration of the loop, we’re appending a list element to our unordered list. If you’re running this function on a document with quite a few selects (especially with many options), you’ll notice quite a bit of lag.

This code can be better optimized by abstracting the injection until after processing the select in its entirety by concatenating the list items to a string, and then appending that string a single time:

// parse all options within the select and set indices
var i = 0;
var options = '';
targetselect.find('option').each(function()
{
  // add the option
  options += '<li><a href="#"><span class="value">' + $(this).text() + '</span><span class="hidden index">' + i + '</span></a></li>';

  // check to see if this is what the default should be
  if($(this).attr('selected') == true)
  {
    targetselect.parent().find('a.dropdown_toggle').append('<span></span>').find('span').text($(this).text());
  }
  i++;
});
target.find('.options ul').append(options);

Instead of appending the list item with each iteration, which becomes very expensive very quickly, we simply build a string and work with it once the heavy lifting has been done.

Do you have any tips?

I know these tips are nothing extraordinary, but I hope they may help you enhance the performance of your future scripts. I realize that my code examples use jQuery syntax, the tips themselves can be applied to any implementation of JavaScript.

Do you have any techniques you’re using consistently in the interest of both code organization as well as optimization?

Advertise here with BSA

Advertise here with BSA

One inescapable limitation from which we’ll never be able to escape is that of color contrast. While it’s only obvious to ensure you’re working within acceptable limitations of color contrast in the general sense of design, we have even more to contend with. Our designs must be equally readable in a myriad of situations.

Sure, print designers need to worry about what their piece is going to look like in various lighting conditions, or how a digital file will translate to something physical. There is a lot to consider as far as the method of printing as well as the material itself. Web design brings something completely new to the table; monitors.

The trouble with contrast: monitors

Even if you’re new to Web design, it won’t take long to realize that contrast is something that never goes away. Even when you’ve got a solid grasp on limitations, and you piece together a design specifically surrounding color contrast on the Web, your client will request the type be a bit darker & bold. Unfortunately, client intervention doesn’t tie directly to this issue, so we’ll move on.

Computer hardware has a tendency of following the adage “you get what you pay for.” Unfortunately, when it comes to many people and computers; the cheaper the better. Bargain equipment is very attractive for a number of reasons, none of which we’ll need to explore at this time. What does matter to us, is that many of the monitors on which your design will be displayed are of much less quality than yours. Your gradients will be less noticeable, your drop shadows nearly nonexistent, and your type more difficult to read.

It seems dismal, but Web designers need to account for the worst case scenario, or very close to it. We have the responsibility of producing work which is not only usable, versatile, aesthetically pleasing, standardized, valid, and optimized, but also beautiful on substandard equipment.

Keeping your contrast in check

There are quite a few tools available for testing your color contrast. There have been many articles written on the subject as well. Some fantastic research has been performed, allowing us to easily observe our color contrast and measure it against accepted values.

I have a tool that I’ve come to know and love in testing color contrast. Color Contrast Check by everyone’s favorite, Jonathan Snook, has come out on top for me. His tool conforms to accepted standards, and allows designers to very easily check to see how the contrast measures up.

There are many other tools available for checking color contrast, which do you use?

Advertise here with BSA

It’s also widely known that many people have a hard time standing behind Web standards. I’m not speaking about those that simply plead ignorance when it comes to the subject, no. I’m writing about the respected designers and developers who in recent months (years?) have been very outspoken toward the lack of advancement we’ve been suffering with.

There is quite a large group who feel the powers that be are not advancing technology to the best of their ability. Who can blame them for feeling like that? A quick mention of CSS3 will put that into perspective. I do need to be clear: I am the last person to discount the efforts of anyone. I’m so very thankful for all the hard work that’s gone into the technology so far, but I need to be honest in saying that I’m equally as frustrated as many.

I’d love to be able to write CSS3 without a care in the world. On the same page, I’d love to not have to worry about cross browser consistencies as well. I’d love to drop support for IE6 like so many others. There are countless reasons why IE6 shouldn’t be a concern, but the trouble of the matter is this: my clients are using it. Sure, we all try to educate our clients, but I’ve had limited (if any) success in trying to produce a browser convert. The support of IE6 seems to be, in part, backed by knowledgeable designers. All I can do at this point is sit back and be jealous of their success. For the time being, it’s not in the cards for me (yet), but I anxiously await the day.

2022

The latest strike against Web standards wasn’t a strike at all, it was a gut-wrenching twist from within. In a recent interview, well known and respected HTML5 editor [WHATWG] Ian Hickson, provided a timetable outlining the progress of HTML5. To get to the most interesting part: HTML5 will reach ‘Proposed Recommendation’ in the year 2022. It feels strange for me to type a year representing that long down the line, but it’s accurate.

It’s difficult for me to imagine a proposed timeline including milestones that far into the future. To me, in Internet years, 2022 feels like the year 4000. I think this timeline accurately represents the frustration held by many designers. I’d like to reference a quote from Jeff Croft. In his most recent article, Two Thousand Twenty Two he readily describes his frustration:

I’ve got work to do, here. I don’t have time to sit around reading specs and interviews by spec editors detailing what is going to happen in 13 years. God knows where I’ll be in 13 years. Quite frankly, I’ll be pretty [...] disappointed in myself (and our entire industry) if I’m writing HTML in 13 years. Hell, if I’m still alive in 2022, I’ll think I haven’t been playing hard enough.

I care about right [...] now. My clients care about right [...] now. Our users care about right [...] now…

I will admit, I’ve gone ahead and removed a few choice words, but I completely sympathize with Jeff. I’m as excited about the evolution of HTML as the next guy, but 2022? I, like Jeff, don’t have time for that right now. I’ve got more work to do than I can shake a stick at, and trying to keep up with a spec that won’t be ready for 13 years is not in my best interest at this point. It’s depressing to say it, but I’ve got to focus on worrying about things today. My company does client work, and they’re not going to care one bit about any of this; they care about their budget, their timeline, and their website working in their browser.

Again, I cannot stress enough how appreciative I am of the geniuses behind this evolution. I respect everything being done to advance the Web, but I think at this point, things are shifting. Instead of proposed specifications and the like, we’re going to see the browser makers themselves take control of the reigns and begin implementation sooner than later. That’s what I’m excited about.

Of course, I will continue to keep an open mind about HTML5, but until it reaches a level of applicable usage, I plan on sticking with the toolset I’m given.

Advertise here with BSA