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):

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.