Mobisnap — Development Notes
The Mobisnap developer discusses ideas and revelations discovered during the design process.
So far, in developing the Mobisnap iPhone application, I've been focussing on features — what to include, what not to include etc. This has been leading me in ever-decreasing circles, discussing the merits of including a touch-up feature, having a clone-stamp etc. But in the interest of progress, and the final product, I've started work on a high-definition prototype.
By playing around with various ideas on paper, drawing them up in Photoshop with my tablet and using my iPhone mockup, I've sketched out a good idea of what Mobisnap could be like — subject to some more user evaluation.
This has got me thinking a bit more about how the application will actually be used. So I've been thinking about the HCI studies I did back at TAFE and I've realized that I've been focussing in the wrong area for the past few weeks — although I know about the importance of a good UI, it's easier to focus on features. So I'm trying to shift my focus back to my original goal of creating a simple, effective application for the iPhone.
To quote the Apple Human Interface Guidelines: The best products aren’t the ones with the most features. The best products are those whose features are tightly integrated with the solutions they provide, making them the most usable.
A great example of why focusing on features results in disaster is Microsoft Office, that massive monolithic office suite with menus galore. During its development cycle, Microsoft would ask users to nominate new features for possible inclusion in the next release. Unfortunately, they were too good at adding new features and by Office 12 (the current version), 90% of the feature requests were already included in Office. In Office 2007, the developers have radically revamped the UI to contextually expose more features directly to the user.
So, regarding features in Mobisnap, I'm basically assuming only 5 core features, with some additional advanced options if you need them (rotate, scale, colour adjust, red eye reduction, fill light). These features are found in both Apple iPhoto and Google Picasa, and they are placed to be easily and quickly access.
Back to the UI, my job is made easier by being able to reference existing iPhone applications, mainly the official apps Photos and iTunes. By staying with the convention set by these applications, I can reduce the learning-curve for Mobisnap — users are already familiar with the interface. It also helps with the graphic-design as well, as I can follow a consistent visual style. In a few areas, mainly the actual editing application I'm on my own though — and desktop concepts don't transfer well to small-screen, touch-interface devices.
I've read sections of both the Apple Human Interface Guidelines and the Microsoft Windows Vista User Experience Guide to follow their design patterns for various UI elements. Again, by following a standard, I can make the application behave as users think it should, not as I think it should.
Finally, Apple have a bunch of HD tour videos for both iPhone and iPod Touch on their website, these have actually been very useful — since they show the applications actually being used. This helps with getting small, subtle details such as the colour scheme, animations and layout to better fit in the limited screen of the iPhone.
More insights can be found /dev/blog
