Recently, I joined efforts with two of my good friends and fellow Telerik Evangelists Michael Crump and Jesse Liberty to jointly build an application that would run on Windows 8 and Windows Phone. Michael will do the Windows Phone development, Jesse Windows 8 with C# and XAML, and I will tackle the WinJS version.
Jesse did a great job of outlining the goals of the application and the initial wireframes of the application in his post on the project kick off. I want to focus on the value of using Wireframes in application design.
A friend of mine, Mike, spent a great deal of time putting together a PowerPoint presentation that represented what the application they were building was going to look like. Not a single line of code had been written yet – in fact, they didn’t even have funding for the project.
The slides looked amazingly realistic. The transitions were built so that when Mike “clicked” on an image of a button, the slide transitions looked like there really was a program responding to his input.
The presentation went great, and all of the senior management who had to decide on funding were very impressed. The project was a go! The executive vice president who chaired the committee pulled Mike aside as the others were leaving, and asked him to stay behind. When everyone else had left, the EVP asked Mike to install the software on his computer so he could play with it. Without flinching, Mike responded the only way he knew how – “Sir, I can’t because my PowerPoint compiler isn’t working right now. This only works on my machine.”
That is a perfect illustration of one of the dangers of making awesome looking graphics to demonstrate what you are going to be building. People will assume that it’s done. And then they can’t figure out why it’s taking so long to get it deployed!
The corollary to wanting the “software” installed is creating the perception that it is too late to change anything. Since the User Interface appears to be complete, we often don’t get the feedback that we need, and we end up designing a less than optimal experience. Not because we didn’t try, but because we inadvertently closed down the feedback loop.
When we have a nice picture to look at, we are often drawn to the visual features instead of the content that is being displayed. I once showed a Photoshop representation of a not yet developed web page to the group, and we practically spent the entire time discussing (some would say arguing over) the colors of the links and the font on the buttons. What I was trying to discern was if we were displaying the correct information for the page, but I struggled to bring them back to those items since the chrome was so dominant in the image.
Have you ever been out to lunch with coworkers and you start talking about a great idea? What do you do, but grab a napkin and start taking notes! Some of the best designs were inked on paper napkins.
Napkin designs focus on the content. Nothing more, nothing less. There aren’t any perceptions that anything is completed, so everything is fair game for discussion. Since most of us don’t carry a set of colored pens, the drawings are black and white, simple, and concise.
However, napkin designs are hard to work on with distributed teams, they can’t be emailed, and I have yet to successfully fax a napkin!
A few years ago, a friend of mine introduced me to MockUpScreens, a low cost wireframe tool that allows for a variety of looks, including napkin designs! Using Mockup Screens, Michael, Jesse and I completed the initial layout for our application over Skype. (For reference, the first screen is shown in Figure 1.)
Now that we laid out what fields we felt were important to capture, we shared our wire frames with the rest of the team. The discussions focused on what data we were capturing, the type of controls for the data, and which fields should be required. No discussion on button color or fonts!
Once the team approved the content, we then sent our wire frames to the design team to make them interesting and compelling as well as to take into consideration human factors and user experience.
I can only imaging the time that we would have spent trying to document the screens with words. It would have taken much longer, and the end result would have been much less clear.
The concept of content over chrome is also a huge focus for Windows 8 Applications. Microsoft ran some focus groups where the attendees were asked to draw their impressions of Windows. What they drew were menus, windows, and buttons. Chrome.
The groups were then allowed to play with Windows 8 for a while, then asked the same question. What they drew the second time was content. They almost completely forgot about any chrome.
Understanding this is a significant part of learning Windows 8 Application Development. We need to unlearn all of the habits like adding buttons and menus all over our applications, since they detract from what we are trying to show, and that’s the content.
Wire framing forces teams to focusing on the content of their application, and not get distracted by the chrome and window dressings. It’s an important skill that can greatly reduce thrashing while designing applications.
And it’s a requirement for Windows 8 Applications!
This article is cross posted from Skimedic.com
Philip Japikse is an international speaker, a Microsoft MVP, ASPInsider, INETA Community Champion, MCSD, CSM/ CSP, and a passionate member of the developer community. Phil has been working with .Net since the first betas, developing software for over 20 years, and heavily involved in the agile community since 2005. Phil also hosts the Hallway Conversations podcast (www.hallwayconversations.com) and serves as the Lead Director for the Cincinnati .Net User’s Group (http://www.cinnug.org). You can follow Phil on twitter via www.twitter.com/skimedic, or read his personal blog at www.skimedic.com/blog.