Big Enterprise is traditionally known for creating development environments that foster a “get it done” mentality, often rewarding results over correctness (mileage, of course, may vary).

My company uses IE6, and the application works in IE6, so it’s done!

This little quagmire is amplified by the fact that when using Open Web technology, there are many ways to get things done, and most of them are incorrect. But those mistakes don’t manifest themselves until the project is in the hands of the end user, whom we often punish for our oversight.

But there is hope. Using the power of web standards and Open Web best practices, we can achieve something panoramically, not microscopically, beautiful.

The secret sauce of building for the Web isn’t its distribution model, in which updates are managed on the web server without the need to update software on the client (although the Anti-IE6 vigilantes would tell you differently). It most certainly isn’t development efficiency, as most people new to the game will so readily inform you of. Cross browser quirks due to non-standard browser implementations of CSS and JavaScript, or vague standards specifications have seen to that.

When I was writing Visual Basic, I got my job done so much quicker and easier!

The power of the Open Web is Device Independence.

Visitors to our sites shouldn’t be met with warnings about what device they’ve chosen to use.

This site viewable only in IE7+, Firefox, Chrome, or Safari, and at minimum 1024×768 resolution.

This site requires Flash or Silverlight

I realize that this is a controversial stance, especially given that most sites are dropping support for IE6, and more are relying on Flash and Silverlight plugins. Architect applications to your client device usage statistics, and don’t let your tools shape the statistics for you. Using techniques like progressive enhancement, we can ensure that our sites degrade gracefully to the capabilities of the client device. At it’s truest form, this is basic accessibility. But, Device Independence might be a more accurate term, since accessibility is unfortunately an overloaded term scoped solely with devices tied to disabilities (screen readers, for example). While screen readers are a very important piece, there is a bigger picture.

When the iPhone came out, there was an uproar because it didn’t support Flash, for battery life and other reasons. But the uproar was from developers who had designed applications specifically for Flash! Would you say that those Flash applications were designed with device independence in mind? YouTube got around this by encoding their videos in MP4 format, which arguably has a higher device independence rating than the Flash format.

Keep in mind that we’re not attempting to handle every permutation of end user browser settings, since most don’t change the defaults. Instead we are trying to scoop up the largest base of supported devices with the least amount of effort! Who cares if an end user disabled JavaScript in their preferences? I’m more worried about the mobile browser that doesn’t even support JavaScript at all. But when you use Open Web properly, you get support for both!

Output Device Independence

• Full Web Browsers: Does your site work in Opera? Don’t worry about pixel perfection, that’s something completely different — does it work?
• Web Browsers on Mobiles
• Search Engine Spiders and other Screen Scrapers
• Screen Readers
• Printers: Ever had to make an entirely separate page for print-friendly version of your application? Flash/Silverlight do not print well
• Televisions: Xbox 360, Wii, and Other Media Center Devices
• Projectors
• and more…

Take a look at the CSS specification for media types. The standards are there! Support for CSS media types isn’t fool proof by any means, but the end goal is clearly visible.

Input Device Independence

But I’m not just talking about output device independence either. User interfaces should be adaptable to different input devices as well.

• Mouse
• Keyboard (often overlooked in web applications)
• Touch Screens (Single and Multi-touch)
• Voice, Motion Capture, and Facial Recognition (the standards and technology aren’t quite there yet, but progress is being made)
• and more…

The world is developing the Open Web, and it isn’t limited by a single company’s goals and timelines. At times, Open Web may seem like it’s a very slow moving glacier headed our way, but what else can you do but laugh when companies try to power their Titanic right through it?

Article originally inspired by Yahoo’s Graded Browser Support.

So, some sites have gone two ways, allowing OpenID, but also a proprietary registration system. This too, is problematic. It would seem that given a choice, the John Doe the Plumber style user will choose a proprietary account over the confusing user experience presented to them through OpenID.

But the annoyance doesn’t just lie with account registration for web applications. Typing your personal information on every blog you comment at is also repetitive and unnecessary. Some sites even require account registration for something so minor and transient as a blog comment.

Unfortunately, for the time being, it looks like registration forms are here to stay. So, what can we do to make those registration forms more usable, more efficient, and ultimately downright friendly? I know that you’re ahead of me on this one: Let’s auto-complete information for the user.

Please keep in mind that this power can be used for both good and evil. Essentially what we’re discussing here is data mining available information from various social networking sites on the internet, trying to glean personal information about an end user that has volunteered a piece of their data already. What can we get from what we already have?

Once a user has typed in their e-mail address, we can:

• Retrieve Twitter profile information (example shown on Chris Heilmann’s blog):
  • Full Name
  • Short Personal Description
  • Location
  • Web site URL
  • Time Zone
  • Favorite Colors (used on their profile)
• Retrieve an avatar if they’ve registered for the Gravatar web service (See my earlier post discussing this).
• Get their upcoming calendar events from a public Google Calendar. (Perhaps not as useful for autocompleting forms, but interesting)
• Find their UID on Flickr, which gives you a source for:
  • Full Name
  • Location
  • Flickr Avatar

If you know any of their social networking usernames, you can:

• find their MyBlogLog profile, if they’ve linked the service to their account (Sample query, I added my twitter). Now we have:
  • MyBlogLog Screen Name and ID, from which you get their MyBlogLog profile:
    • Nickname
    • Picture
    • Age
    • Sex
    • Location
    • A list of tags they use to describe themselves.
  • MyBlogLog Avatar

Those are only some of the proof of concept API’s that I’ve listed here. The interesting piece of this, is that once you have a small piece of information, it opens up the door to other searches.

One can only imagine how many leaves are in this tree. For example:

• Facebook’s Users.getInfo (in JavaScript)
• Yahoo’s Social Tools, get an end user’s GUID and go to town on their profile.
• Google Contacts, I didn’t even start to look through their API’s.

Before you start jumping the privacy fence to a self induced heart attack, remember that all this information has been volunteered by each individual participating in each of these services. Remember, with great power comes great responsibility.

What do you think? Scary or useful?

Own your Identity had a great post today detailing a great feature on the signup form of the Get Satisfaction site.

They rely on the fact that sites like Twitter and Flickr publish an hCard microformat for all of their users publicly on their website. If you go to my twitter page and view the source, you’ll find the following code available to anyone (without authentication):

<address>
   <ul class="about vcard entry-author">
      <li><span class="label">Name</span> <span class="fn">Zach Leatherman</span></li>
      <li><span class="label">Location</span> <span class="adr">Omaha, NE USA</span></li>
      <li><span class="label">Web</span> <a href="http://www.zachleat.com/" class="url" rel="me">http://www.zachle...</a></li>
      <li id="bio"><span class="label">Bio</span> <span class="bio">UI Programmer, JavaScript Enthusiast, Soccer Hooligan</span></li>
   </ul>
</address>

The premise here is that hCard tells you how to parse this markup to get usable information. The adr CSS class tells you what my address is. The fn CSS class tells you what my name is, and so on. So, Get Satisfaction goes and spiders this page behind the scenes and autopopulates your profile with what it can find. Pretty sweet.

Now, they don’t limit you to the services they provide, which are: Flickr, Technorati, Twitter, Upcoming, and last.fm. They provide an Other category for any hCard enabled URL (your personal homepage or perhaps an hResume you have posted on the web).

Integrate with OpenID

However, why not take it to the next level? Why not integrate this microformat functionality WITH an openid login system? You’d be able to kill two birds (not a twitter joke) with one stone in some cases, since both Twitter and Technorati are also OpenID producers (re-echo: We need more consumers).

So, not only do you get the benefits of having OpenID authentication on your website, but you’d be able to prepopulate a certain amount of profile data with an hCard parser. And the best part is, if you already have a nice clean user interface set up to handle different OpenID producers, there wouldn’t be any additional clutter on the interface to get this benefit. It’d be transparent to the user when it works, and fall back to a normal empty profile form when it doesn’t.

What I’d like to see, is more sites that are OpenID producers, also serve hCard microformats as well. If we can get all the major producers on board, we’d have a nice tidy little system going.

• Automatic Print Styling: Is the page going to be able to be printed properly without a “Printer friendly” link? CSS style sheets can be used to modify the output of the page using the @media print declaration. Are the widget components you’re using in your JavaScript library able to support easy printing?
• Browser History Management: Will your application support the back button, especially with the increased usage of AJAX interactions on a full page application. Don’t use XMLHTTPRequest’s to fetch the entire content of a page. Just redirect them to a new page when you are only saving the header and the footer.
• Graded Browser Support: support of the web browsers with a large percentage of market share using the ideas put forth by Nate Koechley in his Graded Browser Support descriptions.
• Bookmark and Permanent Linking: is the behavior of your JavaScript application changing how data is being displayed? You’d better modify the URL to allow the user to bookmark link straight to the same view.
• File Compression: Minimize your CSS and JavaScript for delivery. GZip your CSS and JavaScript for browsers that support it (most all modern browsers do).
• Efficient Caching Mechanisms: server side caching of data is necessary for high volume traffic.
• Internationalization (i18n): will your application be viewed in other countries by non-English speakers? Are your dates in an international format? How about 24 hour time formats? Time zones? Do they observe Daylight Saving Time?
• Error Logging: Both server side and client side (using AJAX to log JavaScript errors can be very helpful)

Recommended Luxury Items

• Support mobile devices: How will your application look on a Blackberry? How does it render in Opera Mini?
• Offline Mode: Add and modify data offline, with the ability to automatically synchronize changes when an internet connection becomes available.
• Exportable data: PDF, Excel, RSS, even offline static HTML. JavaScript can sometimes give unknown results when using the browser to save the page locally. Make sure this is supported. Don’t force your users to save screenshots.

Enterprise Client Side Widgets

• Data Grid: businesses just love data grids. Nothing like a nice standard set of cookie cutter constraints to force upon your data.
• Charts and Graphs: metrics are important. Existing client side JavaScript charting packages can be limited when it comes to printing, or even saving the chart as an image file. These are important.

There are many facets that a developer must consider when designing a new application. I hope this list will at least make you think about some things that you may not have considered before. Thanks for reading.