I remember B.i. (before iPhone) when applications on mobile devices were something only hardcore travelers, geeks, and gamers had tried. But now, you say mobile, and the nearest marketing person responds with “So when can I get my app”? For the first time, it’s easy, and really fun to download an app. I currently have 253 apps on my iPhone – I don’t think even Apple saw this coming.

We had Forrester come out to our $largecompany about a year or so before the iPhone, even then – people were trying to make the decision on what to do in mobile. This was before apps were easy to download and mobile browsers were converging on a standard. Forrester at the time said what pretty much everyone was saying, if you don’t REALLY need an app, STAY AWAY! It’s amazing how quickly things change in the mobile space.

With Apple’s desire to own the entire experience it’s no wonder they got it right. You can’t string together a series of unrelated things and expect them to work together. It takes owning the experience, which is something Apple excels at. But even with the success of the iTunes music store, when the first release of the iPhone OS – apps were nowhere in sight. The web app was enough. But when they finally opened up that SDK to create apps, wow did the iPhone get way more useful.

Again, I think Apple surprised themselves this time – and the interactions used to access these apps on the iPhone home screen show they didn’t think people would have more than 15-20 apps, if that. Someone like me with my 200+ apps, loose apps, forget about apps, and have a hard time finding some apps. And my 5 year old, once he fills his screens, he can’t really spell yet, so searching is out for him. It’s time to fix this, and I hope with iPhone OS 4 they will. But let’s think about how they could fix this problem… How do you make it easy to sift through 250+ apps?

Via: Fast Company

For me it’s GAMES. I’m amazed the quality of games coming to the iPhone, they keep getting better and better – and both me and my 5 year old are big fans. In fact, when I asked my five year old if he was interested in a Nintendo DS or an iPod, he went with the (what he calls) “phone”. I’ve had gameboys, PSP, and other handhelds, but combine the fit and finish of Apple, with some really creative game designers, and you have the ultimate gaming device.

I also have a lot of useful apps that I’d say I use daily to weekly, and a large set for when I travel. Apple needs to devise a way for our pages to reflect the different contexts we’re in on a mobile device. When I’m around town, one screen set – when out of town a different set – and how bout a “lounging around” context? Maybe we need “sets” that we can flick up and down? Or use voice command to put the iPhone in a home/work mode? How about a category switcher using a little page curl at the bottom of the screen? I’m sure Apple will figure this out, but they need to do it soon… I can’t find my Plants vs. Zombies ;-)

I personally think prototyping is the way to go when creating a new software product (or any product really). You get to “blueprint” out how something is going to work, how the pieces fit together, and how it will really work once launched. I think most people are sold on the concept, so it’s a matter of how to build this close-to-real product that you can test with your user base. Do you use paper? Mock-ups? Tools like iRise and Axure, or get real and build a non-functioning ready to reuse front-end?

The first step is defining what you’re going to use this prototype for. Is it to drum out business requirements? Demo to clients before they write the big check? Or get something as close as possible to the real thing, so you can start the User Centered Design process and test your ideas on actual people that will be using your product.

Obviously I enjoy prototyping for the latter, getting real feedback that our team’s ideas were dead on, or widely off-base (never!). To do this, you really want to build the prototype in the technology you’re going to create the finished product in (usually HTML or Flex for web based software). This solves two problems: one, this truly is as close to the real thing as you can get. By using the actual UI technology you’ll be creating the final product in, you’ll know what can and can’t be done, users will get a real feeling for the responsiveness, animations, and interactions. It’s real, sans the months of backend development needed to power this prototype. And two, you can pass this finished front-end code off to the development team, taking pressure off backend developers who may not be well versed in front-end development.

Microsoft when working on Office 2007 did this very thing:

“if you’re trying to build a prototype that you want use as a blueprint, it should exist in the same medium as the final product.”

In the past when I’ve run prototyping projects, the teams usually consist of just one designer/IA, one developer, and a small amount of a backend developers time (to get some fake system data up and running). Depending on the maturity of your front-end development group, you may have sets of UI widgets and code ready to go, this will help speed up the overall process.

Dave Cronin from Cooper recently wrote an article titled “Industry trends in prototyping” – which I agree with about everything in the article – he lists out four reasons for creating prototypes: prototypes make your designs better, help facilitate communication, enable user input and usability assessment, and help assess technical feasibility and reduce development time. He’s also a fan of creating “real” prototypes where it makes sense.

I love this comment from Philip Fierlinger:

Prototypes, on the other hand, let people feel the flow and experience the relationships. Building prototypes allows architects and interaction designers to quickly identify broken pathways and iterate quickly to find better flows – by feeling the experience, rather than thinking about it in the abstract. Developers, designers and clients also get a much more tangible sense of what the end product will be.

Again, I can’t stress enough how a “real” prototype will give you the best feedback for the effort. We’ve also used these prototypes to help sell ideas to business groups. Imagine trying to sell an idea for a mobile app by letting your VP access it directly on their phone. This will beat out any PowerPoint presentation.

Garrett wrote on this topic years ago, and the technology is now easier to use than ever before. There are frameworks, open source systems, and reusable icon sets ready to be molded into your own prototype.

Using wireframes or paper for low-fedility prototyping is not necessarily a bad thing. Maybe your just testing internally, or you’re limited with your technology skills. There are discussions about what fidelity wireframes should be (both form and function). There are many tools at your disposal for creating wireframes and prototypes, and they’ve really just recently gotten easy to use. No longer are you stuck with Visio – here’s a list of some tools, ranging from very expensive to free with varying sets of features:

• Axure
• Pencil Project
• Balsamiq Mockups
• Adobe Flash Catalyst
• iRise
• OmniGraffle
• Lovely Charts
• Rapidrabb.it
• iplotz.com
• Prototype Composer
• fluidIA
• WireframeSketcher
• MockupScreens

Boxes and Arrows has an article from 2006 written by Scott McDowell, that goes over some of these options, but what’s really interesting are the comments below the article where designers talk from real world experience. And Russell Wilson from Dexo Design compares 16 prototyping tools (2008) and again, the comments are interesting.

I tend to use wireframes to quickly get across ideas and interactions. Something that could possibly be thrown away, or will be changed a number of times. Once the idea seems to stick, I move to high fidelity mock-ups, sometimes merging the mock-ups together in a slide-by-slide presentation showing the page flow with faked interactions.

GUUUI posted some links to videos showing lo-fidelity prototypes in action. Again, this can work to help guide overall concepts, but to get true feedback – you really need to have a higher level of fidelity.

If you’re in a good situation where you’re ahead of the product timeline, prototyping is your next step. Just like how a architect moves to a model, build out your prototype and test, iterate, improve, and in the end launch a successful product!

(additions)
Great post over at Adaptive Path: Rapid Prototyping Tools

As a Designer, I sometimes need to evaluate different technologies and platforms from a Designer’s perspective. Why is it important to get a Designer’s view? As Designers we can quickly be boxed in with inflexible UI layers, unusable sets of standard patterns, and the inability to create a great experience. By reviewing and testing, we can determine the pros and cons of a given technology solution. In honor of Eclipsecon 2008 ;-) I’ve put together a presentation on a popular application platform – the Eclipse RCP.

Eclipse has it’s roots as a development IDE, and while that’s very efficient for developers, for non-developers it’s not very user-friendly. For this particular technology I broke up the potential problems into four groups: Visual Style, Structure, Usability, and Focus. These were four areas where Eclipse had problems, when looking across a large number of Eclipse based applications.

The Designers View of Eclipse:

| View | Upload your own

To be fair, they are trying to fix these issues, and some very smart developer/designers are creating good applications using Eclipse. But, projects without proper UI layer specialists (Designers and Developers) will default to the problems listed out above. From a Designer’s view, it’s not easy to get a great application out of Eclipse.

One great presentation out of Eclipsecon 2008 is from Morten Moeller, titled: “Designing Business and Technical User Interfaces in Eclipse RCP Applications” which basically states current Eclipse User Interfaces could use some work, and how to made them better – with technical examples of how the presentation layer works.

This is not to say that Eclipse, as a platform is not capable of great things, but just that current popular Eclipse patterns that seem to be prevalent across most Eclipse based applications are not great from a Design/usability perspective

Remember, while the Designer’s view is very important (after all I’m a Designer ;-) there are other business needs that weigh the overall solution. Such as: development time, current skill set, scalability, etc…

With experience becoming an important factor in differentiating products, having a flexible UI layer is becoming a major factor when choosing a technology to base your product on, so if you’re part of a team evaluating different technologies, make sure your team takes into account the Designer’s view.

If you’re an Interaction Designer, I’m sure you’ve noticed a new design pattern in the past year – one that doesn’t really seem to have a proper name yet. In fact, you’re probably already incorporating this pattern into your designs. It seems like almost every major redesign is leveraging this pattern to help hide complexity: Amazon, Linkedin, TripAdvisor – and sites like Target, Google, and Yahoo have been using it for awhile. It’s a design pattern I’m calling “Revealing Interfaces”.

| View | Upload your own

I have a habit of taking screenshots of interesting UIs. I have a large collection that I browse through for inspiration when creating something new. I started the above presentation to help provide some context for what I was trying to do with some of my own Designs. I’d been interested in reveling interfaces and recently I came across a couple of pieces that when put together gave me the idea to help better explain this pattern.

The first was when John Maeda came to my work to give a talk. While reading “The laws of Simplicity” I came across this quote:

“Hiding complexity through ingenious mechanical doors or tiny display screens is an overt form of deception. If the deceit feels less like malevolence, more like magic, then hidden complexities become more of a treat than a nuisance.”

I like the fact that while a revealing interface could harm traditional usability heuristics by “hiding” away functionality, once someone actually uses the interface, they could be delighted by the options revealed to them.

The second was when around the same time I saw a post “Hiding Complexity” over at one of my favorite blogs (future perfect by: Jan Chipchase). These two photos so elegantly demonstrate what the purpose of a revealing interface is: removing initial complexity.

At it’s most basic, it’s really something as simple as a drop down menu on a website. But in the last year or so, with more highly skilled people at the helm, pushing the limits of XHTML/CSS/JavaScript/AJAX it’s becoming much more.

No longer are the days of waiting for a full page load just to update your status. With a single click you have access to power user features that used to be buried three pages deep. An entire site can be navigated from the main page, without overloading the front page with tabs or links.

The interface becomes more fluid, interactive, and more like a conversation. In some places it can even read your mind ;-) “Yes, Netflix I was wondering what the plot of “reign over me” was, thanks!”

Along with these new reveling interface patterns comes a new budding visual language to denote when something can reveal more information – and when does it just take you to a new page? I’m sure there are a new pile of accessibility concerns with the extra levels of DHTML and JavaScript – and how does usability change, when you can’t really ask the question “where would you click…” or “what do you expect…”?

Please take a look at the embedded presentation, hopefully this post can help start defining this pattern and get the conversation going – and feel free to start that conversation below in the comments :-)