The Process:

It turns out you don’t need to be the Tom Hanks of programming to build a decent mobile application so long as you use the right tools. It also helps to work with a team of people eager to learn about application development who fearless tackle encountered problems. Given a list of prototyping options ranging from Axure to Andriod’s SDK kit, we chose to useGoogle/MIT’s application development tool “App Inventor.” With very limited experience our team set out to learn the tool with tutorials and followed with building the application. Using the design spec as a guideline we setup the screen flow and then built out the interactivity. To our relief, using AppInventor was at first difficult, but soon after learning the nuances we were able to add features such as GPS and Twitter integration without pulling out too much hair. Whereas most projects in this studio begin with a significant research and analysis effect this week was all about brute force, and learning on the fly. The design spec was not without flaws but the team was quick to determine the critical path for a functional application based on our ability, time, and available resources.

With four people working to create the application we could spare some time to iterate upon the design spec. Evaluation, role-playing and discussion led to an agreement on simplifying the workflow, updating the visual design (but not to Android design guidelines), and clarifying the content/copy. The original workflow seemed confusing and the numerous steps required to post a tweet was unnecessarily difficult. This is what happens when you give four UX-inclined students a spec to build.

The Prototype:

The mobile application prototype is available via dropbox or by scanning the q-code below.

Analysis

Unlike most ensemble movies, and there are too many bad ones many to name, this project received positive reviews without a true leading role. I’ve probably gone too far with the acting metaphor but, true to form, in this case I believe the whole was in fact greater than the sum of the parts. We figured out a tool, split responsibility, helped each other, and in the end built a pretty darn good application.

Now cue the 80's montage music….

I learned:

1. Using app inventor made building a mobile application easy without knowing programming language. It wasn’t easy and often it was very frustrating but the online support community and vast array of documentation made solving an issue reasonably manageable. All tools will have pros/cons, knowing what they are ahead of time alleviates tension of a learning and using a new tool.
2. Keep the purpose of the prototype on hand at all times. It’s really easy to get carried away and expect everything to work all the time, at speed, and look great. A prototype is for evaluation and needs to built to a fidelity that assists in answering the questions for which you seek answers. Often, we found ourselves frustrated that GPS didn’t load fast enough, or the twitter login acted wonky, but it still worked!
3. Prototyping using a tool with a large online community is amazingly helpful. Open source has it’s pros/cons, but when I was stuck for hours trying to get GPS to run, I published a note on a forum and within ten minutes received an extremely detailed response. It sounds like this is commonplace amoungst the development community, and it’s amazing.