The arguments for Linux on the consumer desktop were not working:

• The main argument of Linux was that it’s a free alternative, however most people get PC’s with an OS pre-installed. From this perspective ‘free’ doesn’t matter because it’s built into the price.
• The second argument of Linux is ‘it’s open source.’ This argument carries some weight with businesses but a typical consumer doesn’t understand or care about open source.
• The third argument is speed. Not a bad argument but when most people only care about web-browsing and email the bottleneck is usually the dial-up connection, not the x86.
• Beyond that the argument isn’t very compelling. Linux provides the same abilities to launch basic apps, configure settings and has the same or often times worse compatibility issues with drivers.

Over the last five years we’ve seen a shift in mobile applications.  For about 30 years people thought of mobile phones as an extension of traditional phones. They would make calls and that was the primary use. Over the last 10 years we’ve added features like voice mail, texting and even basic web browsing. It wasn’t until just the last 4-5 years that the next wave of mobile has taken off.

Mobile today

Mobile phones today are dominated by three classes of devices, 16 button, 60 button keyboard and new touch devices. There are about 1Billion 16 button phones, 50-100 million keyboard phones and about 20-40 million touchscreen phones. I’m mostly talking about this last category of emerging phones though some principals apply to both keyboard phones and 16 button phones.

The key difference between the phones of yesterday and the phones of today are a combined set of capabilities and technologies that fundamentally change the user experience. These include:

• Always connected - email/web/etc
• Adaptive input screen (control every pixel)
• Geo-location
• Touch/Gesture interface
• Accelerometer
• Apps you can download

A lot of these technologies existed either in isolation or in awkward implementations. Together they allow for a much richer application experience. This has become a platform that is fun, exciting and profitable for application developers.

Design for existing behaviors

When designing an application it’s key to keep scenarios in mind. A scenario is the basic story of how a person may use the application. The important thing when thinking about scenarios is that actions tend to stay the same but the way you complete those actions changes.  Behavioral changes are difficult and rare. It’s much easier to design tools that encourage and support existing behaviors. Similarly it’s much easier for end-users to adopt your application or tool into their existing behaviors rather then changing established patterns.

Designing for Mobile

When designing for mobile remember that people are out in the real world. Your application needs to be a good alternative to the desktop/laptop. The factors for this type of design should include:

• Input methods - make it easy and minimal to get information into the device.
• Form Factor - Design for a smaller screen size and make it easy to read and get information back out of the device.
• Location - Take location into account
• Efficiency - A mobile application should be quick and efficient

From the end-user perspective the iPhone adds a number of features:

1. Cut, copy, paste
2. Photo/text message (MMS)
3. Landscape use of email, notes and other applications
4. System wide search
5. Voice recording

Among a long list of many other new features.  These make the iPhone a much more powerful device and narrow the gap between what was traditionally seen as a laptop function and what was considered possible for a phone.  Most of these features were changes to the core built-in tools and could only have been done by Apple.  I suspect the timing of the summer release will be such as to poison the well for the much anticipated Palm Pre device.

The three things that users want and are still missing were:

• Flash support
  Was omitted probably for as much political as technical reasons.  Apple likes new developers coming to the platform and wants unique native applications, not Flash ports.  I expect they will hold off on this as long as they possibly can.
• Background applications
  Were omitted for performance reasons.  While I may not like it I agree with the trade-off.  If background applications were allowed Facebook, Twitter, ESPN and everything else would try to run in the background killing the battery.  A server based push model while not as flexible is a good way to address this pain point.
• Video Recording
  A core function seen in many lower end phones. It’s possible the new API’s will allow developers to do this but given everything else Apple did add I was surprised this was not done.

Developer Features

Much of the recent success of the platform has been in large part to developer written applications and the App Store. Apple announced that over 800,000 downloads of the SDK. Wow!  Apple has taken the original iPhone that wasn’t a platform at all and over the last year has turned it into a mobile computer.

We’ve been designing and developing applications for the iPhone since it was released and while the iPhone is a very powerful platform there were a number of rough spots that Apple has been fixed with this new release.

• More complete set of API’s.
  The original release of the iPhone SDK was limited in that a lot of the API’s were not documented or makred as off limits. With this new release Apple promises 1000 new API’s hopefully opening up more flexibility in what applications are allowed to do and the types of tools that can be built.
• Easier wireless networking.
  This new functionality allows users to play/chat/interact and otherwise communicate with other local users. This opens up a number of possibilities for social games, information exchange, syncronization and interactions.
• Built-in maps.
  Google has allowed their map component to be used in other applications. It’s still not entirely clear how this will work but this adds a nice component that was previously unavailable.
• Push Notifications.
  Many applications need the ability to alert you to new things, events, alarms, messages, etc.  Push notifications provides a solution for this but unfortunately it won’t work for some types of notifications.  You can’t build a “Where is my child application.” or “tell me when I’m near so and so.” you can however build many other applications that were previously not possible.
• Interaction with hardware.
  This is a big one. Expect to see custom iPhone apps for many of the speaker systems and audio docks Bose, Griffin, Altec, etc. Expect to see custom iPhone apps for BMW, Volkswagon and Audi to allow you to control various car features from your phone or Ipod Touch.  This will lock in the iPhone to a lot of new hardware devices (good for Apple, bad for other competing devices.)
• Interaction with the music library
  This will allow applications to play music from your own music library. So you can pick a playlist in a game and listen to your own music without having to exit out and go start your iPod.
• UpSell and Subscriptions
  This is a big one for developers. The business of application building has some problems in it’s current form. Any established software company knows you need the ability to upsell.  The ability to upsell and sell subscriptions allows developers to build deeper and richer applications, create new content and new features that can be sold.  This enabled a whole new breed of applications that could previously not have been done.  Apple still seems to be missing the ability for developers to charge for software upgrades (upgrade from version 1 to version 2 for just $0.99) but hopefully this is will be possible.

What we’re personally most excited about:

1. Wireless networking - We have a game that we would like to enable with Wireless Networking. We’re also thinking about a business card exchange program that could do the same.
2. Hardware Support - We have a fitness application that could take advantage of hardware support
3. We have a music application in development that we would like to be able to play your own library

Bring your iPhone and join us for a beer. We hope you can make it.

Additional details, directions and free tickets while they last are here:
http://bostoniphonedevs.eventbrite.com/

- Greg

The core scenario is reading content and the design doesn’t reflect this. The design has too many bells and whistles and not enough elegance to be a truly great device.

• A keyboard has no business being in a book. It clutters the hardware and it takes away space from your content.  It’s about consuming content not creating it.
• The device needs to be touchable.  If you’re going to offer any type of interaction with the pages and content you need to be able to touch the screen to turn the page and tap menus.
• The design should be more anthropomorphic (human-like) both in look and interaction. It needs to feel less mechanical and more natural.
• It needs to properly render the design intentions of the typographers and publishers that created physical books. Things like hyphenation aren’t just pretty, they help readability. The book content comes first.
• Black and grey, really?  This is an example of a compromise in the design.  The readability, functionality and user experience suffers because someone decided that it needed to use e-ink. This technology is cool but it’s performance and color contrast is still not as good overall as a color screen. Yes you can use it outside but a design that sucks inside still sucks outside.  Plus you can’t read it at night without a secondary light.

My proposed design:

• Three buttons, on/off, next page, previous page. Everything else is touch screen (including a touch keyboard when needed)
• Color screen design allows for better web and book reading
• Screen takes up 80%
• Typography and graphics are rendered as the author intended
• No menu/wifi/battery indicator. It’s a book. Tap the screen to see menu/status info/options.

For this application we really wanted to do a scenario based design.  We had three core scenarios in mind:

1) I go to lunch or dinner and figure out a tip

2) I go to dinner with friends and split the check with a tip

3) I go to dinner with friends and one person just gets a salad and everyone else gets a full meal with drink.

Most tip calculators get you to Scenario 1 or 2. Scenario 1 is pretty easy we need the bill total and the tip percentage and we can quickly compute the tip amount.

Scenario 2 was a little more complex but not much. We perform the original calculation and then just divide the total bill and the tip line up between the number of people.

Scenario 3 was when it got a little more interesting and I think this is a unique feature I haven’t seen anywhere else.  We allow the user to go into the details of the bill and manually adjust each dinners check.

If one person had an extra drink you use the slider or plus/minus arrows to adjust their price and everyone price adjusts automatically.  This can also be used as people are putting money into a pile. You can quickly see who has put in how much and what amount is left.  If you adjust a slider it stays fixed allowing you to move to the next diner.

Our calculator allows you to see if you have an underpayment or an overpayment. This makes it easier to ask everyone to chip in another buck or two as needed.

The visual design of the application is styled to look like a restaurant napkin. While this doesn’t impact the functionality it makes for a fun and attractive design that we hope people will enjoy sharing and using with their friends.

We learned an interesting usability lesson in building this applicatoin. It turns out that it’s critical to test on actual hardware and not just on a simulator. For most of our basic development we built the application and tested it in the iPhone simulator software. It was only when we got it on an actual device that we discovered that the slider bars can be a little tricky to adjust at a fine granularity.  If you had a $90 bill the slider can go from 0 to 90 and making fine level adjustments with your finger can be quite difficult. After usability testing this we decided to add the plus and minus icons to make fine grain control a little easier.  We also made it possible to just hold down the plus/minus and allow the button to repeat as an added way to help peeople get the price right.

There’s a lot of subteltly in building applications for mobile devices. We hope you like this one.

Download our new tip calculator from the App Store for $0.99

In the process we developed some tools to help other designers. Make sure to check out our iPhone wireframe toolkit.

RunKeeper

This was our first large application, we were approached by a new Boston start up looking to enter the fitness space. We discussed a number of ideas including a web-dashboard, GPS integration and other technologies. We hit upon the idea of creating a mobile version of a GPS watch.

This was before the iPhone 3G was announced so we were taking a risk that the upcoming phone would in fact have GPS capabilities. The value proposition was simple, why buy an expensive GPS running watch when you can get a low cost iPhone application to do the same thing.

The user scenario oriented around a runner who would start their music and start a run.  The display had to be easy to read while running and provide easy to read and easy to understand information.

Through several iterations we discovered how many customers are actually bikers, hikers and the various ways that GPS data and accuracy can vary based on where you are and what you’re doing.

The application has won many awards and has been featured in a number of newspapers, blogs and other publications.  RunKeeper continues to evolve as we disect deeper interaction problems and continue to refine the end user experience.

You can download RunKeeper and get additional information here

Loan Lite Mortgage Calculator

Loan Lite started off as an exploration by our summer intern, Justin. The goal was to develop an application that had one user interface page, was meant to be used in a mobile scenario, could be developed in about a week and sold for at least $0.99.

We explored a number of ideas and decided that a mortgage calculator could solve a problem for house-hunters or real-estate agents on the go. Figuring out mortgage calculations isn’t rocket science but it’s also something that people tend to need while away from their PC’s.  We also felt that the utility of the application far outweighed the .99 cent cost, especially considering the typical price of a home.

We did a competitive analysis of existing calculators and found that many didn’t offer adjustments for home owner fees, insurance and similar considerations when trying to determine a monthly payment.

The application was put together over the course of a couple weeks and served as a good foundation for learning objective C.

This mortgage calculator is available from the iTunes app store.

A note to comp-sci students in the Boston area. We’re always looking for talented and driven people for summer internships.

Word Popper

Word Popper is our first design exploration into mobile games. We wanted to design a simple game that could be played solo while waiting for the bus or train but also incorporated an online multi-player component.

We wanted to create a fast moving game so unlike Boggle or Wurdle where you have to string nearby letters together to form a word we allow the user to pop letters anywhere to create words as fast as they can.

This creates a fast moving casual game that can be played by crossword junkies, scrabble and boggle lovers and casual users alike.  The online component allows users to play the same board as other users and compete for high-scores.

Designing for a game is very different from designing a typical website in that you’re more free to explore effects such as animations, buzzers and sounds.  The most interesting thing about game design is usability. The main purpose isn’t to accomplish a specific task but to have fun.

You can download Word Popper from the store here.

JetSetter App

JetSetter is a experiment in psychology and economics of high-end products. The majority of iPhone application are currently targeted at the low-cost or free side of the market.  The assumption is that to generate the greatest profit you need to generate a ton of demand. To generate a ton of demand you need to have a low price point.  For this reason you see many low cost apps.

Unfortunately for application developers having a low price point no-longer guarantees high demand.  We wanted to try something different.

JetSetter was designed as a high-end game. In fact we plan to make it the most expensive game that Apple will allow at $999.  While some may view this as outrageous this is intentional because we want the game to be more exclusive. A limited audience may garner a premium price.

The object of the game is to travel around the world on your private jet and accumulate points for the distance you travel.  What’s that?  You don’t have a private jet?  Well then you probably can’t afford this game either.

The game explores the high-end of the iPhone application market a section of the mobile space that has been mostly ignored.

In the $0.99 cent world we need to sell over 14,000 copies to make 10K.  While in the $999 world we only need to sell about 14. This means that smaller more specialized high-end apps can in theory be very profitable.

Weather or not this model for applications will work is yet to be seen. The application includes some interesting social features to make it appealing to an exclusive crowd.  The application isn’t yet available but keep an eye out on JetSetterApp.com if you have a Jet or fancy yourself as a JetSetter and think you can afford it.

Now every web site that’s developing software has their own API to allow developers to code to their website. Let’s take a simple example of 10 more popular sites for photos: Flickr, Facebook, Picassa, SmugMug, Kodak, Snapfish, Shutterfly, Photobucket, MobileMe and Phanfare.  Each one has it’s own API and each one has it’s own authentication layer, it’s own way to send, enumerate and thumbnail files. It’s stupid and broken.

It’s broken because anyone who wants to support multiple partners needs to code at least 10 different tools to support each one.  This is perhaps great for Flickr since they are high on the list but generally bad for everyone else.

Consider instead how standards work. What if each one of these sites supported a simple standard such as FTP.  In a manner of minutes you could add support for 10-20 or even 100 different photo sites.  Sure FTP’s not perfect, nor is it optimized for photos but standards rule and we as a web-community need push, evangelize and encourage sites to move back to standards and away from API’s. 

Myabe I’m being extreme. After all, API’s are a good way for two systems to talk to one another.  Especially when those systems are proprietary.  Oh and what if the existing standards are poorly written or poorly designed?  Sure API’s have thier place but it shouldn’t be the tool of choice. 

If you’re a developer trying to connect to a popular site it may not matter. You code with what you have. If there’s an API you use it, if there is a standard you use that. If that fails perhaps a little reverse engineering.  

But if you’re in that same developer on the other side of the fence trying to decide how others may interact with your service ask yourself if it wouldn’t be better to use conform to a standard rather then write a whole new API? If a standard doesn’t exist take the extra effort to build a community and evangalize one.

Often when I work on projects with CEO’s and high-level executives there is a problem communicating design, concepts and intent. People may cite the lack of design or drawing skills. A wireframe levels the playing field allowing anyone with even basic Powerpoint skills to create basic screen designs.  I posted my original wireframe for web-applications here.  I’m now back with an iPhone based version. 

Why iPhone? Well first off I’ve been doing a number of iPhone related projects including Runkeeper and GPSTwit among others. Secondly the iPhone provides a unique interface language and set of reusable design patterns that can be easily incorporated into new applications. While the basic wireframe components can be used to conceptualize any mobile device the iPhone interface makes it uniquly different. 

The primary design pattern used on the phone is the list pattern. There are many examples of the list pattern but the basic idea is that it allows you to add/edit/remove/view sets of items.  The second design pattern is the table pattern usually used for forms, input and settings. Combined these two elements form the foundation of the platform. 

The wireframe provides a number of examples of how these patterns can be used, modified or altered.