At a recent defense industry conference, Roundarch unveiled a prototype designed to help soldiers collaborate to defeat IEDs.  We set out to feature rich web and mobile applications and apply user-centered design methodologies to solve a very real, very large problem.

Considering the goals of the business and needs of its users, we imagined how technology could support both.  The Joint Forces community is building capabilities that integrate multiple services and agencies.  Meanwhile, video games, iPhones, and the Internet have become second nature to soldiers who have come to expect edgy, simple, and sophisticated digital experiences.  These resulting designs work in a service oriented architecture (SOA), accessing and updating data across multiple existing systems while providing a seamless, world-class experience:
A squad on patrol in Iraq comes across a suspicious device.  A mobile application aids them in reporting rich details about the situation while executing quickly and without diverting attention from their surroundings.  The Operations Center, explosives team, and other subject matter experts operate in different contexts.  They are geographically dispersed and have different hardware yet collaborate in real-time.  Tools support situational awareness, decision-making, communication, and task completion.  IED lexicons baked into the system drive classification of data and algorithms for predictive analysis.  Robust visualizations turn data into knowledge for novice users, decision-makers, and technical experts.
Given that the data and technologies driving this vision all exist today, the end result is both forward-thinking and completely realistic.

The goal was not to prove the technologies themselves.  We are already delivering rich Web applications to thousands of Air Force and Army users.  Our goal was to explore new concepts for delivering information to users where and when they need it, showing what is possible with these technologies.  Prototypes are an ideal tool for exploring new concepts.  They can be very practical used early on in a project to drive out requirements, identify issues, adjust course, and iterate quickly. Prototypes can also be visionary, allowing the team to explore the “art of the possible” and releasing us from the constraints of everyday to see what could be.

Most importantly - as we learned with a similar demo based on an Air Force scenario - prototypes facilitate communication.  You can talk on and on about delivering a rich application to a browser or mobile device.  You can wax poetic about the ability of web services to unleash data to do great things, or you can show people what you mean. If a picture is worth a thousand words, an interactive prototype is invaluable.   They inspire discussion and find solutions to real human problems that get lost in information technology rhetoric.

Build it and they will come? Build it and they will use it? How often do you go to a website and say I can’t figure out this thing or I can’t find what I need? Whether you are building a consumer or enterprise web application, you need it to be user friendly. In reality user friendliness is thought of as “pretty-ing it up”, something done after an application is already coded up. A wireframe or application skeleton gets thrown over to a graphic designer in hopes that they application will just work. However usability goes to the core of the product. It is how your users interact with your product.

The reason I love usability improvement is that often times a small change can have a tremendous impact on the bottom line. Often times, you do not even have to change the core features of your product to make something more usable. Something as trivial as color, size, position or verbage can often change and affect user behavior. As designers and developers of a product, we are often too close and too attached to what we make to see how something may not be obvious to an uninformed user.

“If only the user would do this.” “The user is doing it wrong.” “Why can’t they just see the button.” “It’s right in front of them.” These are the excuses we make to ourselves when first presented with the evidence that our product might not be all that user friendly. We write it off as the user’s fault. However the user is not at fault. Users are users. They will do what they do and you have no control over that. If users never read the directions and always start clicking around, then get rid of the directions and start offering in context help as they click around.

What happens when clients say I can’t afford usability design or research. I say you can’t afford not to have good usability on your website. What’s the point of having a nice looking website or application if people can’t figure it out and leave. The thing is, usability testing can be done on the cheap nowadays. If you have the stomach for it, just go to a coffee shop and ask people to try your software. You’ll be amazed and depressed to see all your design assumptions fall down like a house of straw. Very inexpensive software like Silverback lets you do usability testing on a budget. If you feel like outsourcing, check out UserTesting. You tell them what site to check out, pick out the number of testers, pick the demographics and they send you back a video file of the users screen as they go through your application, complete with a train of thought voice over from the user. Alternatively you can just try something like Amazon Mechanical Turk.

Taking a real world analogy, I often frequent this restaurant in downtown Chicago that has a great salad bar. The only problem is that they put the dressing in front of the actual salad. If you are in a line, you come to the salad bar and get your greens. Then you have to awkwardly ask the stranger behind you to move because you have to reach back to the dressing. I pointed this out to the manager that the flow of this was all wrong and it was a major inconvenience to his patrons. He looked at me as if I was some sort of crackhead telling him how to do his job. Now I like the place enough to come back, but this decision to place the salad dressing in front of the salad inconveniences all the patrons that go to the salad bar. People move forward and invariably all have to cut backwards in line. Now I’m sure many websites, including my own have problems very similar to these, but without usability studies or testing, we’d never uncover them. This is why I think Usability is important.

The first Google Technology User Group meeting in Chicago kicked off on Friday July 10 at Google offices on 20 W Kinzie, Chicago. Although it was sponsored by Google, the meeting talks and discussions were not restricted to Google technologies. Everything from Google AppEngine, iPhone development, and Twitter apps were fair game. That said, Google technologies were definitely the main focus. Many talks showcased how easy it was to get a web app up and running using Google technology. A ragtag group of developers, students, entrepreneurs, and business folks totaling around 80 showed up. The event was organized by Uki Lucas from the Revere Group (right across Roundarch offices) and consisted of 9 talks. Here were the topics:

• GData, Guice, Google collections
  Gregory Kick (Google.com)
• Project hosting on Google Code
  Nathan Ingersoll (Google.com)
• GWT and Google AppEngine, Photo Carousel example Widget
  Jordan Beck (Revere Group)
• Facebook for Google Web Toolkit
  David Wolverton (Revere Group)
• Maven2 dependencies with Google Web Toolkit
  Trevor Skaife (Revere Group)
• Google Friend Connect for Google Web Toolkit
  David Wolverton (Revere Group)
• Building mobile applications with Android
  David Lo (Revere Group)
• Building application with iPhone
  Phil Wodarczyk (Revere Group)
• How to Build a Viral Twitter Application
  Pek Pongpaet (Roundarch)

All in all, I thought it went really well. People were really engaged and I’m already looking forward to the next one. No plans have been made as to when it will be but consensus was that it will probably be a quarterly event. It’s great to see a strong developer community interested in cloud services and sharing knowledge in general.

…and it’s name is Palm.

To be more specific, the iPhone (Canon 50D) now has it’s Nikon D90, and it’s the Pre.

This idea comes from one of John Gruber’s posts on Daring Fireball back in 2007 titled, ‘Apple Needs a Nikon‘:

The point being that much of what gets chalked up as devotion to/obsession with Apple is, in fact, devotion to/obsession with great design, and there’s an utter dearth of rival PC or handheld gadget makers that value design as Apple does.

And:

Canon’s cameras are better because there’s Nikon — and vice-versa. Canon-vs.-Nikon arguments can get ugly, but in the end, they’re arguments about two companies that make great cameras and great lenses. Apple has no such rival.

Like tech columnist Stephen Fry that Gruber quotes, I don’t have sole allegiance to Apple. The fact that Palm was able to get their business back on track and launch the Pre in the short time they did is remarkable and I’m excited that the iPhone is not in this game alone.

It’s easy to compare the iPhone and the Pre on pixel-level similarities - and blast Palm for copying elements from the iPhone, but the fact remains that both phones have very different priorities and Apple does not hold the rights for using glossy buttons or reflections in a GUI.

Ars Technica did a thorough review (as usual) of the Pre, and made it a point to emphasis how the 2 smartphones differ.

iPhone’s starting point:

In the iPhone’s case, whatever Apple’s mobile may have evolved into, its origins are very straightforward: in the keynote that introduced the iPhone to the world, Jobs described the device as a fusion of three products: a “widescreen iPod with touch controls,” a phone, and an “Internet communications device”. And thus it remains; the iPhone is a widescreen, networked media player that also does a bunch of other stuff, telephony and Internet included.

And the Pre’s starting point:

The Pre, in contrast, was introduced by Rubenstein as a cloud messaging device that also does a bunch of other stuff, media playback included. And this primary messaging orientation has had as deep an impact on every aspect of webOS as the iPhone’s media orientation has had on the iPhone OS.

What’s great is there’s already a handful of Pre owners at Roundarch now (and growing), where there used to only be a sea of iPhones - and yes, some of these Pre owners are iPhone defectors. I know what you’re saying, impossible!

Yes, it’s true, and I think it can only help us keep a better pulse on the ever-evolving mobile market. We’ve already produced iPhone applications for clients like Avis and the band Wilco, and that’s great, but we’re much more than one-trick ponies. Understanding multiple systems can only strengthen our understanding of the broader canopies of interactive and application design under which the iPhone OS and webOS live.

FULL DISCLOSURE: The author owns an iPhone, Canon Rebel and a small handful of AAPL shares.