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.
Designing Apps With Metro Principles and Windows Personality
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.
An examples illustrates this. If you ask a typical group of users to draw a Windows 7 application most or them will draw a start button and some kind of chrome with the typical Windows buttons. Ask them to draw a Windows 8 app and they will suddenly draw the content, not the chrome. And that’s the most important thing in a Windows 8 app: the content.
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.
A Modern Architecture Review: Using the New Code Review Tools
This was a great session and I would really advise you to watch it. It gave some tips on doing a complete review of a project. From the process all the way to the code.
One thing that was a pity however, was that the speaker lost a lot of time on showing some videos on how great Australia is and telling some fun facts about the Netherlands. Skipping those would have made the session even better.
I just want to share some notes I toke during this session.
Do you evaluate the whole processes?
What things do you start looking for:
- Dependencies
- Commented out code
- No tests
- Duplication
- Long methods
- Standards
- Bad naming
- God objects
- No exception handling
- No comments
- No code reviews
- No build process
- No design docs
- Defensive coding
Are the developers getting bogged down in doing user interface work? If so, they won’t have enough time to focus on good code and you will get problems.
So split User Interface and development work from each other.
Do you have a Scrum master?
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.
Then you start looking at the code. Is there a consistent way of naming the solution and projects?
Is there any documentation?
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:
- Business
- Compile
- Deploy
- Technologies
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.
Setup a process of code analysis where you encourage the devs to improve each class, each time they tough it. Don’t let them fix everything in one big run. That’s way to hard. Doing it incrementally and setting clear goals for each sprint will be a much better goal.
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.
Building Your First Windows 8 Metro Style App
So, that’s it for the sessions. At the end of the Friday I did one workshop on building my first Windows 8 Metro style app.
Microsoft setup a workshop room with a couple of pcs that had a touch monitor! Really cool stuff to play with. In the workshop a Contoso Cookbook application was build that got some data from a webservice and then used a grid layout to let the user navigate it.
We also integrated with both the share and search contract. The helper applications in the SDK are really nice for testing your contracts!
It’s a nice introduction and Microsoft told us that they will release this workshop as a hands on lab.
And that was TechEd! I will go into more detail on some specific things I learned in my next blogs. If there is something you want to know more about, feel free to leave a comment or send me an email and I will write a blog about it.