StandardPixel.com

For a year, I have been reading conflicting opinions about the “edge” option in the “X-UA-Compatible” meta tag that Microsoft introduced. Now, with first hand experience with the released IE8 browser, I have formed my own opinions. This tag will force IE to render a page in the latest standards mode. To me this sounds like a tag that is making IE behave like all other browsers. If Firefox, Safari, Opera, or Chrome release a new version, there is no tag needed in order to make use of the latest features. My understanding is that the meta tag is a response to the fact that Microsoft needs to support all of the pages that were coded for the versions before IE8. The tags are in place to support developers who used hacks that will be incompatible with the newly supported standards. This part of Microsoft’s meta tag approach makes sense to me and it is a clever way to deal with a messy situation.

The “X-UA-Compatible” tag will allow developers to target any specific version of IE that they feel will properly render their code. I think the “edge” option makes sense if you know that you will always be coding to proper standards and are prepared to test your site as new versions of IE are released. However, Aaron Gustafson, of A-List-Apart, made a good opposing point in his article that was later reinforced by Chris Wilson in the IEBlog. They suggest that it would be better form to always target a specific browser version so that you are not left scrambling to fix bugs every time a new version is released. Though I agree that this makes sense, why only one browser? I would feel a lot better if this was a more global option that was bound to a spec instead of a specific browser version. I would love for all  the browser manufacturers to extend Microsoft’s tag to be a more global tag, anything is possible right? Without a standardized tag, I fear we will have tags for every different a-grade browser and they will probably have their own conventions. I will just be an optimist on this one and hope our standards organizations have this one covered. Robert O’Callahan of mozillazine called Microsoft’s approach a “Maintenance burden” and I have to say that I agree that it will be a burden in it’s current form.

Finally, the two articles above that oppose using the “edge” option suggest that it will make code vulnerable to any new feature that is released by browser manufacturers. This has always been the case and it has bit me once or twice but I would hate to think that this approach will give the IE team license to release code that may not be ready for the wild. I would hope that the burden of quality testing is not being shifted from one development team to many developers and users.

It’s 5:51 pm (PST) and I am in the PHX Airport waiting for my connecting flight home. The last 6 days have taken a lot out of me and I am frankly tired of not being in Los Angeles right now. Odd though, I can’t wait to hop on a plane and head to SXSW next year. I had a heavy set of expectations and I think the SXSW Interactive Festival delivered beyond my expectations.

It all started a year ago while I was in a period of high-stress and low-inspiration. In a desperate effort to be inspired, I was listening to a harrowing amount of web related podcasts, favoring The Rissington podcast and Boagworld. This was in addition to my eye-numbing list of RSS feeds in Google Reader. Over a weekend I followed the progress of some of the most influential bloggers and podcasters through SXSW 2008, and wished I was there in the panels and parties. The conversations that came out of that week in Austin seemed to generate a year of inspiration for me and I vowed that I would not be a spectator in 2009.

In the following months I convinced myself that this was something that I needed to sell to my employer. I knew the company would benefit as much as I would; but I was just not sure I could sell a 6 day conference in a time when we were, as a company, considering layoffs for the first time in many years. I am glad that I was willing to, and did, pay my own way. I then proceeded to convince my girlfriend (a fellow geek), that since we would be traveling together we would be saving a fortune. In fact, we can’t afford NOT to go. I am assuming by the easy sell that she really wanted to go herself but I sort of like to let myself think that she was fooled by my clever sales tactic. So it was decided; in the summer of 2008, we made arrangements to go.

Before arriving in Austin, I had decided that the price of the ticket would be justified if I could meet and make contact with some clever and cool people in the industry and feel inspired to pick up at least one skill that I did not have when I arrived. We set out from Burbank last Thursday, and embarked on one of the most irritating Southwest Airlines experiences of my life. The trip to Austin could be a post in itself so I will just wait to embellish on that here in the future or over a drink (you’re buying).

On my first day, I missed most of the sessions and wandered into a book reading that really didn’t hit home. At about 6:00 pm, I figured I should at least salvage the party part of the day and get a head start into the line for the Tap Room party. On arrival in the line I immediately made friends. The people there were excited to engage in conversations about things I rarely get to talk about in a party atmosphere. In most cases, you can hang with geeks or you can go out to a club and have some fun. SXSW is a rare place where the two merge and it was a lot of fun.

We drank and talked shop as well as a few almost religious debates about the cloud and Agile before we decided to leave and get some Pizza. That is where I ran into Andy Budd and Remy Sharp. These are indeed well known people to me though there was an silly moment where I asked Andy if he would be attending the Great British Booze up, not yet recognizing who he was. He responded with “I am the Great British Booze up” which I think was the best possible answer to be honest.

Later in the week, I attended a panel where ARIA was explained with detail and passion by Becky Gibson from IBM and Dojo. Before this I had not completely understood what ARIA was, though Becky really brought it to life. I did some more reading and realized that ARIA can be described as CSS for the visually impaired. This perspective on the subject of ARIA really made the subject interesting to me. You will continue to write semantic markup in the same way. ARIA is simply a layer that will be added to your markup, much like your CSS style-sheet. This is a simple way to enable everybody to use your site to its fullest. I am positive that I will bring this back to my team and challenge them to work this into our framework.

Over the next few days I attended some amazing interviews, panels, parties, and learned the right way to give a presentation. I also met Paul Boag, John Resig, and had an conversation with Daniel Burka about Agile. As our conversation progressed, he challenged a lot of career limitations that I did not even know that I had. Yes I am completely exhausted and eager to go home but it is with a year of inspiration and new friends that I go. See you next year SXSW!

SXSW begins tomorrow and my calendar is full. I spent 2 hours going through the events and deciding which ones I will attend and there are a lot. I feel like the next 5 days are going to be intense. Exciting!

I have had my hands on the release candidate of IE8 for a couple weeks. One thing that will become obvious is that their are three distinct modes for rendering. Like other modern browsers there is a Quirks and Standards mode. Microsoft also added a compatibility mode which is intended to emulate the IE7 engine. Since IE7 is a lot more like IE6, I.T. departments will be a bit more likely to upgrade their clients. These I.T. Departments are the strongest force holding back the deprecation of IE6 since a lot of them are using internal web apps that were not coded with standards in mind and will break on a modern browser. A developer of a website can add a meta tag to their page that will instruct IE8 to run in compatibility mode for the version that a page was designed. Since it may not be practical to update every site to have this meta tag in the head, a configuration is available in the IE8 browser to enable compatibility mode on all web sites or on site specifically added to a list in the preferences. All of these are commendable steps that Microsoft has taken to move their browser and users to the world of open standards without breaking the IE6 hold-out-internet.

Here is where the headaches begin: Microsoft has even gone as far as letting users opt in to compatibility mode during the install process of the IE8 browser. The choice is presented to the end user and is worded in such a way that the user would feel scared to not choose compatibility mode. Since this choice is presented as a simple radio option, there is no opportunity to restrict compatibility mode to a list of domains, like in the preferences. The compatibility mode will be used for all pages. This means that potentially most of those that go through the upgrade process from IE 6 or 7 to 8 will end up rendering in an IE7-like state, and unless your browser checks the user agent string for the mode, your hacks for IE7 will not exist. I am not proud to say that I have a few IE7 hacks though I have restricted them to IE7, so that any other browser will use a standards compliant default CSS set.

I have discovered one work-around. Microsoft does provide a meta tag that will instruct IE to always render in the latest standards mode. Using this should force your browser to behave. It would also be smart to ensure all hacks for IE6 and 7 are restricted to the intended version only with selector specific hacks or conditional comments. I do this by writing the user agent version as a class in the body tag and writing my selectors against that. Also remember to check your page using the IE8 developer tools, as they will show you if your site is rendering in the proper mode.

On our framework team, we are looking into ways to encourage contributions from our users. Often our users will all need to solve the same problem and if we can work with the users to package their solution in a flexible way, other users can benifit. This means that we will need to set some code standards and work closely with the user to make sure that the code is of high quality and follows conventions of the framework. 

A member of our team came across an internal article from a developer who needed to solve the same problem and had an interesting proposal. This proposal suggested that these contributions could be solicited easier if there was a community established that works to spread the word about contributing and provides incentives for the user’s effort. The user would be rewarded with some sort of a paper certificate at a public ceremony. After giving this some thought, I think this article makes some good points about community management, but falls short in the incentive. Awards programs seem to always be the default incentive idea in proposals to motivate communities but with so many out there, so few chances to win, the (lets be honest) low value of the prize, and the time that would need to be put into selecting a winner. Not to mention that this takes peoples focus off of the passion for their craft and puts it on a pointless contest. I don’t think it is a good option. 

I think we should take the advice about community management and look at other successful community managers around us. One that comes to mind is Yelp. They were able to get real hipsters in real cities to write reviews for them; FOR FREE. These are quality reviews. Their success can be attributed to their Elite Member program. If you write enough highly rated reviews to where the community manager takes notice, you get to be part of an exclusive club. This club has a special mail list and events at posh lounges and restaurants. 

If I were to translate this model too our contribution cause, I would recommend that we start a program where a user could get the prestigious designation of a Framework contributer. They would have to have proven their skill by contributed one piece of code and shown an ability to support their code in the community. Call me optimistic but I think there are a lot of people that are passionate about what they do and we could use that passion as an incentive.

I have been using a new pattern for managing instances of JavaScript widgets in applications. I define a widget as any component in an app that is JavaScript enhanced. This could be anything from a DataTable to a button.

In the YUI 2X idiom of interface development, you would create a namespace for a section of your application. All of your instances, constructors, and various other junk would live in the scope of this namespace. My instance manager pattern would slightly change this in that constructed instances of widgets would be stored in a Instance Manager object. This object would be constructed as a member of any namespace that would be home to an instance of a widget. All of these instances would be kept in a sub-object of the Instance Manager which would be known as the “map” object.

The Instance Manager object would have 3 more methods:

• get
• set
• delete

“set” method
The “set” method that can be used to add an instance to the “map” object. Passing the constructor as an argument instead of passing an instance will delay the instantiation until the first time the instance id is called from the “get” method this is known as lazy loading.

“get” method
The “get” method that can be used to return an instance from the map object by passing its key as an argument.

“delete” method
The “delete” method will remove the instance from the map object by passing its key as an argument.

The point of this pattern is to create a consistent way to create and get instances of widgets. This is especially useful for use with the Unobtrusive JavaScript pattern because code written to look for special markup conventions on page load can be generalized

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.