Could jimu be the Missing Link in Android App Design Process?
On Android designers and developers often run into issues when designers create their designs to pixel perfection and developers try to make that design to scale to all possible screen sizes. Static drawings on Photoshop can give a good understanding of the app visuals and wireframes an understanding of the app structure but neither allow developers and designers to work in an iterative manner to produce something that scales nicely and looks great on every Android device.
Could jimu be the tool that we're missing? To me it looks like it could very well be. I, as a developer, could create an app structure following an information architecture diagram given to me by designers in a very short time (half a day or so). I could then use that app on multiple devices and together with the designers we could explore where we need to improve the structure, where the design does work and where it doesn't. To me this would be extremely valuable. The fact that the project is in proper Android code should allow me to use it either a frame to build the proper projet or at least as a code design aid.
That all said, I want to make it clear that I'm not part of the jimu team and I have no connection to them. I am, however, a backer of the project on Kickstarter and I'd like to see the project succeed.
I recently had a short email exchange with Linton Ye from the jimu team and asked him specifically about the prototyping and UI point of view. This is what Linton wrote back to me (shared with his permission):
With jimu, everyone can create native Android apps by dragging and dropping building blocks. For app designers, it opens the door for rapid, realistic prototyping, a promising complement (or even alternative) for common practices in UI design such as wireframing. Designers could create working prototypes, apps that run on the actual devices, almost as quickly as they draw wireframe or mockups.
Wireframes and mockup images are the state-of-the-art tool for designers to communicate with clients and reason about different design ideas. In an iterative UI design process, they are particularly useful because they are easy to create, fast to evolve and intuitive to use. However, we have observed two gaps that limit the effectiveness of this tool. First, there is a gap between the information presented in wireframes and the designers’ intended designs. Clients have to rely on their past experience and the designer’s verbal description to imagine how an interface should work. This is a problem especially for mobile development if the clients cannot see the wireframes/mockups on the actual devices. The other gap is between design ideas and their implementations due to technical limitations. Designers often are not familiar with these technical details and hence need help from developers to create implementable designs. For example, an issue that's often omitted in design is GPS latency.
We think a rapid, realistic prototyping tool as jimu can bridge these gaps. With the prototype apps created with jimu, designer and clients are able to not only see the interfaces on the actual devices, but also touch and interact with the design with their own fingers. We believe this increases designers’ awareness of technical limitations, enables very fluid communication between designers and their clients, and presents new opportunities for enhancing the design process, for example, we can imagine a useful add-on in user testing that collects how much time is spent on a specific screen or how many taps a user has done.
Currently, only a basic set of components are implemented in jimu, such as simple actions on the action bar, Button, TextView, ListView, GridView, Swipe (ViewPager) and LinearLayout. But our goal is to include the full set of UI components, templates of standard UI patterns, as well as designer-friendly features such as importing images (or even PSD files).
See more about the project at the kickstarter page!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)