StandardPixel.com

I love the idea of progressive enhancement. If kept in mind throughout design and development, the product will be more accessible to those with disabilities and most of the awkward challenges that the Internet drag in. The fact is that what little work I have done to make a site progressively enhance, has turned out to save me lots of time down the road. You will just have to take my word on the last one.

So how does this relate to some of the fat client style applications that I have been working with lately? If you don’t know, a fat client, in the javascript world, refers to an app that relies mostly on client side code to run and communicates with the back-end  through asynchronous data exchanges. These apps are able to use client side technologies to give a similar experience to a desktop application. Lack of proper “low-fi” states, where the app can be useful without javascript enabled, are not generally considered when building fat clients with client side libraries like YUI and SproutCore. The makers of these libraries obviously try to keep their products accessible but it is difficult to keep maintain this accessibility as the fat client features are added. I could not reconcile that I could Both be making progress and ignoring progressive enhancement when working on these types of applications. The truth is that we can’t make an application that can both contain all of the interface convenience features that modern browser users expect and have a low-fi case to fall back on for accessibility.

The best way I have found to get around the gap between accessibility comes in the form of a compromise. There are sites that will redirect a user to a low-fi version, if a browser does not meet the minimum requirements of the fat client. The same approach is often taken to redirect mobile users to mobile versions of an interface. This allows every user to get an ideal experience for their client type as long as their client type matches the requirements. It is very important that if the client does not meet the minimum requirements, is of unknown type, or an error occurs preventing client detection, the page is served in simple HTML, with no JavaScript enhancement.

I do understand that most of us do not have the time to build two or more versions of an application. There are clever ways to organize an app to minimize the amount of duplicate work that needs to be done when building both a low-fi and fat client version of your interface. Ruby on Rails particularly comes to mind so it will be my example. First, you want to create a simple Rails application. This would not need to be much more then a scaffold. Apply some style though the site should be readable without CSS, even if it is not pretty. Make sure that your controllers are set up to return a JSON representation of the rendered data if requested. This JSON output will be the rest service that your fat client will use to communicate with the back-end along with the necessary ability to accept AJAX form posts. This seems to be the least evil way to provide functionality for specific clients.

–EG–

PHOTO CREDIT: Uploaded to Flickr on December 20, 2007 by Paul.c.Redmond

In web app development, as in anything else you have to have a balanced set of requirements. As the business folk have always said: “Cost, Quality, and Speed - You only get two”. It just seems to work out that way. Now for us in web development we have a different three to choose from: Speed of development, speed of served product, and flexibility of design. Each needs attention, but too much attention too one will deplete the others and lead to a poor product. Lets inspect each:

Speed of development

An app can not be built in a day, but it should be built in a few months. By the time an app gets through design, development, and testing a lot of things can change. I don’t know anybody who has worked on a long or short term project that did not have one or two requirement changes after development had begun. This is why we use Scrum right? Obviously if the reality is that requirements will be added during development, it makes a lot of sense that the longer you are developing, the more last minute changes you will do. However, if you are able to cut the development time, it is easier to convince the business that their super important icon color change can go out in the next sprint.

Speed of served product

Does it scale they will all say. Will your app be fast enough and your servers be strong enough to handle a lot of users and / or slow clients. Some argue that Frameworks that make development easier are less flexible and harder to scale. To be completely honest they are right but it is important to measure each and decide if some sort of balance could benefit you more or at least break even.

Flexibility of design

It is important for the app to be flexible enough to meet user needs and have an enticing interface. This one is interesting because not too long ago I would have counted this as one of the two most important along with speed to develop. That is until just before I started to get inspired to write my post “SproutCore is a chainsaw and YUI is a paring knife“. That is when I realized that a Web App is quite different from a web site and really should follow more closely the rules of a desktop app. In desktop apps we are better off using common OS interface elements that people have grown accustomed too.

Which two do I choose

As you may conclude from the last paragraph, it depends on wether it is a web app or a web site. For a web app, I would choose speed of development and speed of served product as these tend to have a need to make it too market as a complete finished product in a short time-frame and rely on the back-end heavily to process data. Also, consider this quote from UPA – ”Consistency is one of the most important aspects of a repeatable user experience. If users know what to expect, it will be easier for them to build a conceptual map of what should happen next“. On the other hand a web site has a different purpose and I would trade speed of served product for flexibility of design as the idea is to entice users to enter and look around.

I was asked to list some qualities that one should look for in a good front-end engineer. Here is my list:

• A strong understanding of Object Oriented JavaScript.
• Experience writing unobtrusive code.
• Experience leveraging modern javascript frameworks like YUI. 
• Experience working with browser based debugging tools like Firebug for Firefox.
• A good understanding of W3C standards and how to code consistent behavior for all a-grade browsers.

I have been playing with SproutCore a bit lately. So many great features and so very very simple. At first, I was expecting to either dismiss it as another library or love it so much that I replace my current favorite. Neither turned out to be the case, I love when a new solution can come along to solve a problem that I had already accepted would never be solved. In fact, SproutCore solves the same need for web client interfaces that Ruby on Rails solves for server web applications. 

The JavaScript fat client is here to stay.

The entire “Web 2.0″ movement has proven that users love a solid fat client. I use gMail and Flickr every day as do hundreds of others and I know none of us miss waiting for a page load every time we click on a message or save a caption. Building these fat clients can be tedious with all of the state changes that need to be carefully choreographed. As an example, when you delete an email message, you might want to update a total message count. Was that the last unread message? well then you will also have to change the unread count to zero and change the folder style from bold to normal weight. Luckily, these are all pretty common needs and the SproutCore framework exists to provide this functionality to us allowing us to focus on other things.

This does not replace the need for traditional libraries.

Indeed we are becoming more and more aware that there are two different categories of web project, Web Apps and Web Sites. Web Apps are a lot like a desktop client. Users expect to have a single interface and be able to get to everything they need in few clicks. Web Sites, on the other hand are more like a news paper and people expect to enter through a front page of some kind and explore in to get more detailed information on a subject. For me, I have settled on creating one Web App project with a Ruby on Rails back-end mixed with a client written in SproutCore. Another project however, is a simple information site which will use PHP, along with a little interface help from YUI. I think it this is an important distinction to make as I can see these two areas branching off more and more as time goes on.

Over the past few years we have seen people do some remarkable things with Javascript. This is almost like the age of enlightenment for Front-End developers. In a short amount of time we have gone from a majority of hobbyists and hackers to a group with a fair amount of true engineers. In some cases we are even gaining respect from back-end coders. We have done well for ourselves. 

I want to share a pretty cool pattern for collaborating on JavaScript files.A little backgroundIn the application I am working on, we have a need to keep all of our JS in one file that is committed to subversion and included in the application. This one file is updated multiple times by members of our team and as a result needs to be frequently merged. Sure we could use includes of some sort to simplify this process but that has overhead of it’s own. I am sure that a lot of teams have more then one hand in the Java Script cookie jar at a time.The pattern

<script>

//Promoted Code

(function(){

	//Stuff

}())

//John's Code

(function(){

	//Stuff

}())

//Paul's Code

(function(){

	//Stuff

}())

</script>

What does this format offer?

1. Each developer (John and Paul), will have their own closure to keep their development code. This will give them the freedom to create variables without worry of collision with other developer’s code. This also will do garbage collection before running the next developer’s closure.
2. A “Promoted Code” closure exists to hold code that is production ready. This code will be moved from the specific developer’s closure when it’s development is over.
3. Merging is way easier when you know where your code is in the file.
4. Development code is placed after production ready code. This will allow the developers to rewrite objects in the production ready code if needed.
5. Most text editors will let you collapse code blocks in a closure. This will clean up your work area and allow you to better concentrate on your code.

This pattern may seem simple but those are sometimes the best kind. I have noticed a dramatic improvement in my ability to work on these files in collaboration with other developers.

Just about everybody is using a framework or library for something these days. It is the logical next step. When everybody that matters and their mother has weighed in and IT is done as ITs going to be, it is time to lock what ever IT is down. This allows us a foundation to start building a greater ITs, you know? In my newest role, I have formed a bias towards YUI for layouts and javascript though I am fond of a few other frameworks too. Working with these libraries hopefully will inspire developers to start thinking of their work as something that could be re-used. Ideally everybody will see each html document as an API that could be used in a limitless amount of future applications. Even if you are just building a simple page for a one-off project that may never see the light of day, it is still important to think your conventions through.

Javascript conventions

Well thought-out javascript does not stop at the framework level. Creating a huge blob of overly specialized functions that leverage a flexible framework seems wasteful to me. There is so much extra energy that can be harnessed from all of those development hours that you spent toggling the visibility of that light box effect (or whatever). Learn to step back from your specific implementation and write a reusable control. This control would be a simple object-oriented chunk of behavior with a clear set of descriptively named methods and properties. I like to spend a little time brainstorming other use-cases before I begin creating any control. Once your inventory grows a bit you can start promoting your controls to a larger library that can be used for multiple applications. I find that this model, at first seems redundant, but in reality reduces the over-all code on your properties. If you are a freelancer, I imagine that this sub-library can be something that you package and sell to your clients to add value to your product offering.

Markup conventions

Hopefully you are already separating your behavior and style from your markup. If not, read this. One thing that will help you to build reusable javascript controls is a good Markup convention. Every control that manipulates what the user sees will need to work with the markup layer in some way. A little time spent deciding on some adaptable code standards will save you tons of time. Most of this is done for you in the W3C spec. They have worked hard to come up with flexible ways to represent things like numbered lists and definition lists and you owe it to yourself to leverage them. Sometimes however, you will need markup for a more specific implementation that does not match a W3C spec. When that happens try to stay shallow and make sure it works constantly in all browsers. If possible it would be smart to document this convention so that your peers and successors can easily pick up where you left off. I like to think that most conventions can be positioned so that a javascript control will bind to a specific container on a page using a className, then gain access to child nodes of the container relying on your pre-defined markup convention as an API. I suggest using a class because it is possible that your control will be used more then once on one loaded document.

And a little about style

I like to think that this can all be done without applying styles such as font types, images, and colors. With a few exceptions this can all be done through CSS which by now should go without saying.This pattern is one that I have been perfecting over that last couple of years. I am a huge fan of using conventions where possible because, I hate doing the same thing twice. I am sure most of you can agree with that and a lot of you are already applying this in some way.