The elephant in the room for all RIA development teams is the lack of a proper process/workflow to go from idea to sketch/wireframe to prototype/alpha. We all know it. How do you start? In a tool like Visio or OmniGraffle, doing wireframes? In Photoshop doing straight up mockups? In HTML/CSS building prototypes? Building a rough in Flex or VisualStudio right away? All of these tools or steps have advantages and pitfalls. Let’s tackle a few of them here.
OmniGraffle and Visio are great because they are fast and don’t necessarily tie you to a specific technology. They can offer a lot of flexibility in styles, too, through the use of downloadable templates and stencils. I visit GraffleTopia.com regularly to see what’s new for my tool of choice, OmniGraffle. The wireframe shapes tend to be vague enough that clients, with a little coaching, won’t get too hung up on the details, color, typography, etc. You can just focus on functional areas and UI design patterns. However, these tools do have a significant disadvantage in that they don’t produce any assets you will be able to actually use in your finished product. No graphics can be prepped out of them for use in your UI. No markup can be backwards engineered out of them to help you with your app’s layout or views. The widgets in your layout are for looking only, not touching. These documents are not typically interactive when viewed onscreen. One thing that’s great about them though, is that they tend to print very well, so if paper prototyping is part of your desired process, you’re covered here. I typically count on a wireframe process step taking a handful of hours per screen before all approvals and required buy-in for the wireframe is acheived. On a big project, this can be well worth it. On a small project you might just be burning too many hours.
Jumping straight from cocktail napkin to Photoshop/Illustrator mockup is a path taken by some, and if it works for you, great. I have found it not so successful for me in the past, so we have all but abandoned this sort of workflow. Perhaps this will change once Adobe releases Thermo, making porting from design to MXML a more fluid/roundtrip type of experience. This would cut down on what I see as wasted hours on the “Photoshop Mockup Death Spiral” ‚Äì pushing pixels in a round of revisions after a round of revisions. Reading Getting Real pretty much cured me of this. See the following:
Writing the app right away in HTML/CSS may be an option for you. If you have strength in the two technologies and can employ a JS framework like JQuery you may just be able to crank out something pretty quickly that looks good. However, you are indeed showing your hand, if you will. You have chosen a delivery technology. You have delivered what could be seen by the client as something close to being done. You may be limiting yourself to common UI design patterns as dictated by what’s available in HTML/CSS. All that said, you have produced something that can be used by the back end developer or integrator to produce something real. You are a bit further down that road. That said, not many small teams may have a person with the skills to produce something using standards that looks good, plays well with your middleware and doesn’t take weeks to produce. 37signals wrote about this workflow last week, but I’m not sure many houses can execute at this level.
That leads us to building a prototype in a dedicated IDE. Since I like the Flash platform, and our company is pretty comfortable developing in it, this means Flex Builder for me. The component based approach and rapid results make this almost like a living wireframe. I have had pitch meetings where, a day or two before the meeting, I’m put on the spot to mock something up. This would have caused an aneurysm for me a couple years ago as a I stressed over putting together a Photoshop mockup, but now, with MXML and the CSS support, with just a tiny bit of research, I can whip together a theme that emulates the company’s branding and covers all the needed bases for displaying a hypothetical user flow. Click-through mockups are indeed a reality. When put into a more relaxed or planned process, you can actually use states and transitions to begin the XD during the earliest stages of a design. This has some drawbacks. Ted Patrick mentions it in his post, Managing UI Development Expectations with Flex .By giving a client such a polished refined UI so early in the process you are again, tipping your hand to the client. You don’t want to give up all of your goodies too early, now do you? He offers a pretty nice “plain” skin for use in your projects to help turn down the gloss. Additionally, if you start down this path, obviously, you have committed yourself to producing a Flash platform deliverable, so it may not work for everyone.
It’s obvious there is a hole here. Microsoft’s Expression Blend attempts to fill it, and it’s a valiant attempt for a new product. Google is investigating this space for the AppEngine. Adobe has a tool coming out that everyone is anxious to get their hands on, Thermo. Lots of people are writing about this perceived lack of toolset or process in RIA/Site development. A List Apart blogged it this week, focusing on the production of HTML/CSS. I highly recommend reading the comments section there. Some great tools and suggestions to check out. Delores Joya Moore blogged it. She mentions how she is currently employing Flex as a tool to produce UI prototypes that eventually end up being used as the views for a properly architectured RIA. Not a bad thing to try out, IMHO.
How about you? How is your team overcoming this hurdle right now? Any tools, plugins or processes that are working for you? I’m interested in learning more from other design/development teams about this topic.
My del.icio.us
