One of the things I hadn’t done any sessions on where the design principles behind Windows 8 Metro applications. So today I started with a sessions from one of Microsoft Tehcnical Evangelists to get up to speed on it.
The session started with a set of core principles of Metro:
- Do more with less
- Pride in craftmanship
- Fast and fluid
- Authentical Digital
- Win as One
What does this mean? Well, a few basic things you need to consider when designing your app.
First, make sure you have a clear goal with your app. You should aim to make your app excel at one specific thing and then design your app in such a away that everything supports that. This means leaving out all the ‘not essential’ things like chrome and navigation.
Doing more with less means that you should remove all chrome and let your app focus on the content. So, for example, a news reader should focus on news items, not on a navigation chrome.
Take pride in your app! Focus on the details and make sure that what you do is excellent, if something can’t be done perfect or doesn’t support your ultimate goal, then leave it out.
Fast and fluid has to do with how your app responses and supports the touch language. One thing I noticed last week is that Microsoft is calling touch a language. You should design your app touch first and then you will automatically support mouse and keyboard.
Embrace the fact that you are on a digital platform. Don’t try to mimic the real world. Users are used to being in a digital world and we can take advantages of that. The semantic zoom is a nice example of that. In the real world, zooming only changes the size of an object, in a digital world we can show a whole different perspective on our data. Show how popular items are by using different sizes for example.
Winning as one is all about integrating with the Windows ecosystem and making sure that the whole is greater than the sum of the parts. We can use contracts for that such as the search and share contract.
Other design elements are for example animations (that are part of the WinRT library so all apps get a consistent feel) to a clear use of typography that will let users automatically focus on what is most important.
Do you evaluate the whole processes?
- Commented out code
- No tests
- Long methods
- Bad naming
- God objects
- No exception handling
- No comments
- No code reviews
- No build process
- No design docs
- Defensive coding
Do you have Continues integration?
Do you have continues deployment?
Do you have a Schema master?
Do you have a TFS master? Does he check policies, comments and builds?
Are you on the latest version of all tools?
Can you do a get latest and compile on a fresh machine? If not then create a instructions to compile document.
Can you run all unit tests? In this phase, all unit tests should succeed and all integration tests should fail.
Can you create the database easily? Do all integration tests succeed now?
Even better is if all this can be setup with a powershell script.
Make sure that your definition of done is reflected in your docs. This way your documentation will stay up to date when running all the SCRUM sprints.
In the new school your documentation should consist of 4 documents:
Other documentation will consist of your unit tests and work items.
Then you can use Visual Studio Ultimate (or any 3rd party tools) to analyze the architecture. Create dependency graphs and discuss them together with the development team. Analyse those graphs to make sure everything is OK. If not, create a work item for it.
At the end of the presentation a link to Rules To Better Architecture and Code Review was mentioned. I just read it and I can recommend it to anyone who’s interested in the subject.
Or if you don’t like reading, there is also a video which describes this process.