Realigning the Azimuth

Twitter’s recent acquisition of leading iPhone client Tweetie (along with hiring its developer for their mobile team) was certainly a minor surprise for those users who follow the behind the scenes events in the industry.

For those users who aren’t so involved with the behind the scenes machinations, the first they would have heard about it was upon installing Tweetie’s 2.1.2 update. Besides a small collection of bug fixes, the main focus was on a so-called surprise – which turned out to be a little heads-up to users notifying them of the impending rebranding of Tweetie as the Twitter for iPhone application.

As I see it, this is where things didn’t go as smooth – sometime after the release, I started to see a number of users on my timeline complain about not being able to deactivate it. At this point, I hadn’t given a thought to disabling it either (having worked out what to do to avoid activating it) until this started happening. A quick cursory glance through its Settings screen was enough to find the necessary option to disable it from appearing.

This is where I happened to get a little grumpy.

Not because of the Easter Egg, but rather for the fact that why didn’t any of the complaining users dive into the settings before complaining? Is this simply an artefact of settings for iPhone applications being stored in an external application (though, the number of new applications doing this is somewhat decreasing)? Or is this down to users not being interested in customising the application?

The other question which was floating around my head was what about the Easter Egg upon discovery? Unlike other Easter Eggs (for example the hidden games inside earlier versions of Microsoft Excel & Word), this Easter Egg was really only meant to be seen the once. Thus, I would have believed that upon discovery, the most logical thing to do would be to automatically disable this.

The fact that it’s disabled via a simple UI switch would suggest that it’s the best option, but sadly this wasn’t the case.

What lessons can a developer take away from this? First & foremost would be the value in not pissing off your end users. The fact that the Easter Egg didn’t switch off upon being discovered was a serious lack of foresight, only compounded by the lack of discovery being performed by the user.

The second thing to take away would be considering a better way to managed any such notifications. Had I been implementing such a feature, I probably would have gone & presented it as a simple banner when the application had been started up for the first time. That way, I would have been able to have it appear on screen for a short period of time, before disappearing.

Regardless of how it was put in, I personally liked the feature & felt that it was a great way to notify users of the impending rebranding. I guess I just believe that in this case, it could have been executed in a way which didn’t annoy the end user.

I’ve been spending a bit of time as of late doing some specification work for a potential project.

One of the things which happened to be an interesting point of contention during some of this was the complexity of some of the options present in the UI. The front-end of the application was originally specced out to be a native iPhone application, but was re-scoped into being an mobile-optimised web site instead.

Regardless of what platform I was meant to implement it with, the application was reliant upon the user creating an order – with each order allowing multiple items. Each of the items in the order was made up of 6 fields.

This should be logic enough to build a UI for, right?

In most cases, I believe it would be. In the case of this application, each of the fields was to be populated from a list of allowed values. If the range of values was within a reasonable range, I’d have no problem with this. But, in a number of cases, this was not to be.

This, to me, is a sign of a larger problem when it comes to applications like this. A good application should be designed to be quick to use, and only through a careful evaluation of the workflow for the user, can an interface which makes some task easier to be achieved.

In this case? If I had full control over this application, the first thing I would have fought for is a reduced set of values for each of the options. Reducing that level of complexity would give some room to be able to play with alternatives to the traditional UI form factor.

Beyond that? It also reminds me of the need to be prepared to put the resources into a project. Whether it’s on the web, on the desktop, or on a mobile device, as a developer, you need to be prepared to put the effort into it, and as a client, you need to be prepared to finance it.

In this day & age, users need to be the end goal… to provide an experience which makes their task easier & faster. You cannot treat application design as a simply stick-it-into-a-big-form approach. This does nothing but show a lack of care on your part, which leads to poor reviews, and less returning clients.