UPDATE 7/12: This post is part of a broad series helping to simplify the development experience of Windows Phone apps. The beginning of the series can be found here.
In architecture a blueprint must exist before a house or office complex can be built. Without the blueprint there would be mass confusion and little if anything would ever happen. The final product would be disaster. The same concept applies to software especially on the phone. If you just start coding the resulting app would struggle to be coherent or usable to the consumer. In order to prevent this we need some kind of software blueprint to help the developer stay focused and deliver what is desired and intended. Over the last 3 years here at InterKnowlogy I’ve come across a variety of ways to represent the flow and design of an application. I have gone from paper to whiteboards to Visio to combinations of all of the above and more. What I’ve discovered is the digital formats take too long to accomplish anything so they are more of a final design asset rather than the means to get to the desired result. Whiteboards are my preferred medium for sketching wireframes and information flow. Microsoft has one of the coolest examples of wireframes participating in the flow of information called an Information Map. The example image on the aforementioned site is not the highest quality, but it demonstrates the intended purpose.
As I mentioned earlier I don’t like going to a digital medium because I feel it takes too long to make it worth while. But I am a huge fan of the whiteboard so I’m including am image of the information map of LionHeart that I created on a whiteboard. Thus, digitizing my whiteboard information map. It’s not beautiful but it conveys the idea clear enough that I feel little to no need to rework it using Visio or some other pretty digital designer.
There are just a few important items to mention here. First, the Windows Phone platform has some strict navigation rules namely the back button always goes back to the previous page. There are times this rule can be ignored such as when going to a settings screen and selecting save. Hitting the back button after selecting save should not return to the settings screen in most cases. Essentially any screen that is treated more like a modal dialog should not be returned to via the back button. These cases should be called out in the information map. Second, certain UI aspects should be called out such as multi-select lists, pivot or panorama control, or other controls using none intuitive interactions (based on a static drawing). Finally, remember that these information maps only take the UI aspect of the application into account. Do show the layout to some of your colleges or potential consumers and make sure the flow of the app cuts down on as many touches as possible to accomplish what is important. Once the information map is complete then it’s time to move on to the project structure and start coding!
This is an entire different beast. I will not be covering this topic now. Perhaps at a future time. Admittedly, code architecture is one of those religious wars that I absolutely LOVE to discuss. For now I will only say that after you have an information map completed decide on what models exist and what VMs exist. Remember if commands will be used for buttons such as with the BindableApplicationBar that VMs should be used. Also, take into account if you will be using IsolatedStorage or the local application database. LionHeart is designed around IsolatedStorage for purpose of its demo.