Friday, September 5, 2008

Ubiquity - Extending web applications

I've recently begun using the new FireFox extension ubiquity ( ) on both the Mac and PC and find it a real pleasure and useful plug-in. It's already proved invaluable on numerous occasions during my everyday web browsing and development. However, today I started thinking about ways in which ubiquity could be used to not only extend the web, but more precisely, used as a way for SAAS providers to extend their offerings without actually modifying their code bases.

I've always been a firm believer in tailoring web applications based on web personas, experience, frequent use-case or at the very least provide Power User features for those who know how to navigate the web. For example, I consult at a company that has an application that is used by Doctors, Nurses and Customer Service people. The Customer Service people seem to navigate the web incredibly well and have devised all kinds of tricks in order to facilitate their work in the web application. On the other side of the spectrum, Doctors aren't very familiar with the web and it's awfully painful to even watch them use our application. Nurses are somewhere in the middle. Unfortunately, our application has been built with the lowest common denominator in mind. While this isn't a bad thing in principal, it does hinder the productivity of those more experienced users. Which brings me back to ubiquity. I've already found several places where we can utilize ubiquity to improve productivity and usability. One place is filling out forms. Using natural language, you can quickly automate the population of a webform. This is especially useful in cases where the user has to take their hands off the keyboard in order to select an item from the dropdown. Another scenario is templated notes. Our users have tend to have secondary windows open to programs like notepad where they keep their frequently used snippets of notes handy. They then copy this text out of notepad, paste it into the notes section of our application and replace the marker values. Using ubiquity, it would be easy to build a command that stored the companies frequent note templates and share them across the user base. They could then tab through the markers to replace the values, or perhaps the command would be smart enough to pull the values off the form directly (in certain sceranios).

The nice thing about this approach is that users who don't want to use the extensions, don't have to. They can continue using the application as they always have.

I may try and build some prototypes of these ideas and post them on my blog. My feeling is that SAAS providers and large applications will be moving in the direction to provide ubiquity commands for their users, and leave some of the advanced features out of the UI itself. The advantage of this is that it leaves the UI less cluttered and more focused on that data, instead of buttons, options and features that scare users away.

Wednesday, August 6, 2008

Why pay full price for an IPhone 3G? Just open a new line!!

I'm not quite sure why people would decide to fork up retail $600 for the new IPhone 3G (when they don't meet AT&T's eligibility requirements). In my opinion, you're better off giving your original line to somebody else and opening a second line. Furthermore, you can put it all on a family plan and share some of the costs. There's an endless number of people in my family who would jump at the opportunity to join in on my plan. A month ago, my girlfriend was using a windows mobile device on T-Mobile, I was using a blackberrry on a seperate T-Mobile account, and my daughter was hassling me about buying her first phone. Well today, all three of us have IPhone 3G's, we are on the same family plan, we are much happier with the phone experience, and........ we are saving money!

As far as I understand, any new lines added to your plan are eligible for the special IPhone pricing. A no-brainer in my case.

Traded my 1st Generation IPhone for a 3G

I happened to be one of those people who purchased a first gen IPhone from AT&T within 14 days of Apple announching the 3G (May 28, 2008 to be exact). Needless to say, I was bummed when I heard the 3G announcement, knowing I wouldn't be able to upgrade for an entire year, yet I had paid twice as much. Lucky for me, AT&T actually made a customer friendly decision. I stumbled across this post on Gizmodo and hoped it was legitimate since I wasn't able to find any supporting documentation on the AT&T site. Since I didn't wait in line at AT&T during launch, I missed the opportunity to purchase an early IPhone and see if this was in fact true. AT&T was only doing direct fulfillment, so I decided not to bother. Instead, I waited outside an Apple store a few weeks and purchased two 3G IPhones, with two new lines lines. This meant that I still had my original IPhone which I thought I would sell on CraigsList or giveaway to a family member.

I later changed my mind and decided to walk into an AT&T store and test my luck hoping that the Gizmodo article was in fact true. To my surprise, it was, and they refunded my entire purchase price (minus the 10% restocking fee). In the end I exchanged a 1st gen IPhone to a 3G IPhone and walked out with $200 in my pocket. To top it all off, my direct fullment took two days!

Tuesday, August 5, 2008

IPhone 3G still having trouble with many YouTube videos

One of the things I love doing is watching videos on my train ride to work everyday, however there is one really annoying issue that keeps popping up on my IPhone 3G. The infamous "This movie could not be played." issue.

A few quick google searches seems to indicate that the problem is with the encoding of the video. I have noticed that the videos that fail seem to be in higher resolution (not scientific, just an observation). My main gripe with the issue is that videos fail even though they come up in the built in YouTube IPhone App search. You would think that Apple/YouTube would at least filter out these videos that are not compatible with the IPhone yet. For all the great usability products being released at Apple and Google, this is definitely a major blunder.

Friday, July 11, 2008

OpenID - Great in theory, but there's a big problem.

I have to admit, the first time I heard about OpenID I was pretty excited. The promise of being able to use one user account to logon to new websites was pretty cool. The benefits of avoiding a lengthy registration process, the ensuing email confirmation step and remembering yet another user name and password was great. However, as a web developer working on a couple new sites, I soon realized that OpenID wasn't going to work for everything.

I soon realized that OpenID is a great approach for Power Users and web savvy folks. However, OpenID is not for John and Suzy Smith living in middle America. If all web users consisted of developers, designers, IT Professionals, bloggers and silicon valley entrepreneurs, OpenID would be the silver bullet we've been looking for. Unfortunately, we are only a small, influential and very vocal minority of the overall web population.

There are two primary reasons why I believe OpenID works for us savvy folks but falls short for everyone else.

  1. Usability – Learning the OpenID process goes against what users have become accustomed to on the web. The idea of using a URI as your universal id is a concept that the average user will never fully grasp (or it will take some serious education). The abundance of OpenID provider choices will probably seem daunting initially. The average user will feel intimidated. They'll wonder if they made the right choice, if there's an “undo” feature if they change their mind. The major players haven't embraced OpenID, and that will definitely hurt its adoption. If OpenID was being promoted from the likes of Google, MySpace, FaceBook and Apple it would be easier to educate these users and see adoption grow.
  2. Security - The fact that a security conscious user won't be able to tell the difference between a phishing attack and valid OpenID redirection will probably deter them from even trying. The web has become a scary place and there are enough malicious people out there who will use every conceivable trick in the book to con these people into unknowingly expose their credentials. It will only take one high-profile phishing attack to shine a negative light on the OpenID approach.

So where does that leave me? Well, I came to the conclusion that I'll have to support my own registration process because I can't rely on my users to ever understand OpenID. The user-base for one of my sites looks like the following:
  • Uses Hotmail as a primary email account
  • Does their web searches on
  • Hasn't changed the default homepage from the one that was configured on their new PC.

I can't reasonably expect to see any benefit from the extra effort of supporting OpenID. So why did I decide to still support it? I still think OpenID will have its place on the web. Being the active web developer that I am, I want to learn as much about it as I possibly can so that my future sites can take full advantage of it. Who knows, maybe my users will surprise me! Supporting OpenID probably won't hurt you. It's really a business decision on spending the extra development time and effort to support it. My suggestion would be to support it, but have low expectations that it will succeed (unless you have a site frequented by tech savvy people).

If you decide to support it – READ THIS
If there is one recommendation that I'd make, it's to provide users with a link to a video of “how to login using OpenID”. Take a look at this video to get an idea It's important that you record the video showing the login process to YOUR site with a couple of the current primary providers (,,, This should give them some comfort and familiarity if they do decide to take the plunge.