This week our design challenge involved developing a medium to high fidelity prototype of a mobile application for an existing design spec for an application called a Tweak the Tweet (TtT).
TtT is a system designed to allow digital volunteers to provide information in a form that is more easily and reliably processed and analyzed. It uses Twitter, in a form of “digital volunteerism,” to gather and direct information during crises to people who can act on it to the benefit of affected people and communities, and is part of HCDE Professor Kate Starbird’s work in crisis research.
We were strongly encouraged to explore using App Inventor to expand our prototyping tool kit, rather than using more familiar tools such as Axure or Balsamic.
We began this assignment as an individual project, but quickly realized that creating a functional prototype using App Inventor, would require a team effort, especially with a one week turn around time. We pulled together a team that each focused on researching and implementing a certain part of the apps functionality or design. We had one member working on the apps integration with Twitter, one working on integration of Google Maps and location, and another one working on getting a real time character count going. I focused on the design and content strategy.
We began by reviewing the design specs and quickly noticed a couple of major usability issues. First, that there were a number of screens that could be combined to streamline the process. Second, the visual design assets we were given didn’t quite match the seriousness and utility of the app. The target users, those reporting on the ground in a crisis situation, would likely care less about the “cuteness” of the app, and be more focused on getting the most accurate information sent out as quickly as possible with as few screens and as little typing as possible.
While we wanted to stay true the the design spec that we were given, we also felt it was important to take the liberty to address the usability issue that may have been overlooked by those that created the design spec.
Once we revised the specs to capture the intent of the original specs, while streamlining the user flow, we began working on our respective parts - location integration, twitter integration, visual design, etc, testing the functionality of the application on one another along the way.
What I learned:
Surprisingly, what I learned most about this week was regarding teamwork and collaboration. It was particularly challenging for me to use App Inventor because it requires a decent understanding on programming fundamentals, which I had not been exposed to prior to this. Even though it uses drag and drop blocks to “code” the application, which in theory should allow non-programmers to use, the blocks are written using programming vocabulary and required a deeper understanding of programing logic for more complicated functionality. Because of this, I had to rely heavily on my team to figure out the more technical functionality. However, I was able to contribute in areas that fit my strengths, such as the visual design and content strategy as well as to be a positive motivating factor, when we were losing steam.
I also learned that App Inventor may not be the best tool for prototyping linear flows as there are many other web and mobile prototyping tools out there that require less time and effort.
Pros & Cons of Mobile Prototyping with App Inventor
- Ability to create a high fidelity fully functional prototype for Android devices
- Allows you to learn about programming logic in a less intimidating environment
- Takes away the need for perfect syntax and troubleshooting for missing curly braces, colons, and semicolons.
- Working with emulators or connected devices for viewing updates can be time consuming, especially with inconsistent reliability. App Inventor’s emulator crashed often and it was difficult sometimes to determine if things weren’t working because of the code or because the emulator wasn’t working properly.
- A limitation of using a visual interface (dragging and dropping code blocks) resulted in having to do many repetitive tasks.
- App Inventor is more of an individual tool. The current version doesn’t provide a good way for sharing or saving various iterations, or working in conjunction with others.
Post Critique Reflections:
In most cases, you wouldn't be given a design spec with little or no access to the team members who created the spec. I imagine, if we had access to the team, we'd be able to further iterate on the design of TtT.
It was reinforced again that there are always tradeoffs in choosing tools for prototyping. You must be clear on what you are testing App Inventor, in my opinion, doesn't seem quite as valuable as a prototyping tool as it seems to fall right in between levels you might want to test with users. For simple and common interactions, you can create prototypes of equal or higher fidelity using other more intuitive prototyping tools to get the same time of information from users. When it's time to start investing in creating more complex functionality, it might be worthwhile bypassing App Inventor since it has limited functionality and requires repetitive actions for implementing simple things across pages. Although I'm happy that I have been exposed to the tool, I probably won't choose to use it again.