This is part of a transcription of my notes from Microsoft’s recent BUILD conference in Anaheim, CA, minus anything that might be considered Red Gate confidential. Thus, they’re somewhat unstructured, sometimes ramble off-topic, and often contain dodgy grammar. My own commentary and observations will generally be italicised so you can easily distinguish it from the reporting on what actually happened. Much has already been said about this conference, and about Windows 8, but I hope you find these useful. Please feel free to comment or ask questions and I’ll be happy to answer them as best I can.
Jensen Harris is Director of Program Management, Windows User Experience, Microsoft Corporation. He hasn’t blogged much since he worked on Office, but I imagine that’s because Windows 8 has until fairly recently been TOP SECRET.
Started off by introducing the Windows 8 lock screen, which contains a summary of “the things you care about” – number of emails received, etc.
The start screen can be customised in terms of apps and tiles displayed and he used the phrase “in the gap is opportunity”, meaning in this chunk of screen real estate is where you can persuade users to have your app tile, if you do it right.
He also showed the Windows Store (i.e., the app store), which isn’t currently available in the Preview build.
What distinguishes Metro apps that succeed?
Metro style design
Apps should follow the Metro silhouette in terms of title, fonts, typography and so forth. MS have provided the templates to allow developers to do this in VS 11.
Content before Chrome
Said there’s nothing wrong with chrome in a rich desktop application but that it shouldn’t be the focus, and should be minimised or eliminated in a Metro-style app.
To this end the whole content area of the screen is for your app (no title bar, or other widgets). It’s immersive, and it can be beautiful.
The edge of the screen is important:
- You switch between apps by swiping in from the left
- The left and right edges are for system UI
- Left is semantically equivalent to Back, hence the app switching
- Right brings up “charms”
- The top and bottom edges are for your app
- But both should do the same thing
- You should only put very commonly used controls on the main canvas – the rest should go on the “app bar” at the bottom of the screen, although note that IE10 also uses the top of the screen for a second bar allowing you access to the different tabs containing each web page you have loaded
- ALL apps should work this way because it means that people will know how to use every app in Metro once they’ve learned these simple gestures
- The touch interface provides a more natural and direct way to interact with the computer than, for example, a mouse – e.g., children tend to naturally want to poke the screen to interact and are less prone to think of picking up the mouse.
- Showed some heat maps overlaid on the metro UI illustrating the zones that people can comfortably reach on the screen of their tablet when it’s held in two hands
- Most heat concentrated in the bottom left and right corners. Had zones people can reach without stretching, those they can reach with a bit of a stretch, and those areas which require a change of position to reach.
- Shows that app developers need to position controls near the edges of the screen.
- And is why app bar buttons are placed at the ends of the app bar, rather than centred by default.
- Also, hence the split keyboard option.
Used an RSS feed reader as an example of how to transform a desktop app into a Metro app:
- Firstly, remove links, boxes, blurs and gradients
- Then remove everything else, except the content
- Add typography
- Align content with grid
Now have RSS reader re-imagined as a Metro app.
Re-imagining apps is important. They should be:
- Touch first
- Content lead
- Great at doing one thing, not mediocre at doing lots
Goal is “Fast & Fluid”
Fast & Fluid
- Speed and responsiveness are incredibly important due to the directness of touch – it feels horrible to press a button, or whatever, on a touchscreen and get no reaction from the interface.
- Fluid animations – things come from somewhere and go somewhere, they don’t just abruptly appear.
- A language for touch – e.g., when re-arranging tiles can use first finger to pick up and second finger to pan underneath more quickly than just dragging the icon to the edge of the screen and waiting for it to pan as far as you need.
Goals of the touch language:
- Simple & consistent
- Fast & fluid
- Limited gesture set
- Direct manipulation
- Reversible actions
- Limit use of timed gestures, which can be accidently triggered by novices, and frustrate advanced users
- Swipe to select – slide finger down to select an item, and if you pull further you start to move it.
- Semantic zoom
- Display information relevant to zoom level
- Can get from one end of long list to other quickly with single gesture
Designing Touch First
Mouse and keyboard should work well without extra work – don’t bifurcate your interface to suit each interaction mechanism because you don’t need to do this. If you do you’ve obviously gone wrong somewhere along the way.
In summary, goal is fast and fluid. To get there:
- Measure responsiveness
- Use the animations library – this will give you most of what you need
- Embrace the touch language, and don’t deviate from it
How to Scale Beautifully Across Form Factors
Screen sizes: 27″
HD (200dpi) and Ultra HD (250dpi) displays are coming soon.
Supporting the maximum number of form factors means you can maximise your potential market.
The built-in templates and controls already work across form factors. However, you must provide 3 asset sizes: 100%, 140%, and 180%. They don’t anticipate that anyone will ever need to provide more since these will enable them to hit the limits of resolution of the human eye. Alternatively you can supply vectors as SVG, CSS primitives, or XAML.
Interface wise you must support:
- The minimum resolution of 1024 x 768
- Widescreen: 1366 x 768+
- The snap view (your app is docked in a narrow pane on the left of the screen) – this is required
- Optionally, a portrait view
More on the snapped state:
- You must provide this view
- Invites users to keep your app on screen
- Preserves context for users
- Is NOT a gadget – should be a fully functional view of your app
- 320ish pixels wide
- Allows people to do two things at once, which we often do, and which people seem wired to do today
- Provide the three required asset sizes
- Provide the required snap view
- Optionally, provide a portrait view
Use the Right Contracts
Contracts bind apps together and bind apps to the system UI. Examples of contracts are share, search, and picker.
If two apps implement the same contract they can interact.
Note that contracts are only for Metro apps so it’s not possible to use them to communicate between Metro and Win32 apps, or between Win32 apps. This is perhaps a shame, although understandable. The phrase that came up a few times on the subject of contracts is that they provide a “semantically rich clipboard”, which makes a lot of sense when you see the current contract examples. I’m still not clear on whether or not it’s possible to specify and implement your own contracts, although obviously even if it is I’d hold to the line that you should still use standard system contracts except where these really don’t make sense – and if that’s the case, you might just be able to reframe the problem so they do.
Contract Example – Share
The share contract is for sharing data. It sounds like it’s really two sub-contracts: source, and target.
The sharing pane contains a list of apps that have identified themselves as targets. Sharing is asynchronous (or should be).
Every app should implement source, and in the broadest range of formats possible. Not every app needs to be a target though.
This isn’t just about publishing to social media – it’s about sharing between apps.
Contract Example – Search
This is a killer contract. Apps show results in their own UI in whatever format makes the most sense for those results.
- You should implement Search for apps that browse or create dynamic content, reference apps, or apps that otherwise have a searchable content index (and/or would have their own search UI if they didn’t implement the contract).
- You should not implement search for games, novelty apps, and utilities.
Contract Example – Picker
When should I use this?
- If my app accesses or stores files that are useful elsewhere.
- If data is kept in a service, and where it makes sense it’s good to do this, rather than have little turds of data (Jensen’s term) spat all over the hard disk.
Doing this can make your app more valuable because it will provide easy access to content.
These are not interesting in terms of being mere program launchers, like icons, which he described as “antiquated”. They should be the front door to your application. They are connected and alive with activity, thus they draw you back to the app, or even make it so you don’t need to open it at all because the important information is displayed as part of the tile.
They are also an extension of your app. They make apps feel like they’re always running, even when they’re not. They have a single hit target (i.e. no sub-widgets).
They are templated, so all you have to do is provide the text and images and Metro will do the rest.
They also allow people to pin key areas and content from within your app to the start screen. For example, you might pin the people you care about most in Socialite to your start screen. You can pin tiles from the app bar, and these pinned tiles have the same capabilities as other tiles (animation, etc.). You can also use Peek to add content and visual interest. Pinned tiles make your app more sticky and allow people to quickly get to the content they really care about.
Windows is Alive with Activity
Live tiles and notifications keep people connected to and draw them into your app. This makes it more likely that your app gets put on page one of the start screen by users.
The start screen doesn’t have folders (c.f. current Start menu) but does have groups. Folders are bad because they put items down a level, make things feel less alive, and are hard to name. On the other hand people love to create groups (based on their observations), and they can name them or not, as they choose.
Peek functionality allows for multiple states in a tile. You don’t need to worry about manually scheduling your tile to update – you just tell Windows that there’s an update to the content and it will schedule when the update occurs.
Live tiles can be large or small. They can function like badges, containing some sort of count or overview stats. They should allow your app’s personality to shine through.
There is also a Notification mechanism:
- Briefly bring up a popup message anywhere in Windows
- But there’s no junk draw for them – critical notifications should also update the corresponding app tiles because they’re shown once, and then they can’t be retrieved if users miss them.
- Most apps should be silent, and notifications are opt-in
- Should only be used for information that must be interruptive
Live tiles and notifications use the same infrastructure, and there are three update mechanisms:
- Local (not entirely sure what this means)
- Scheduled (exactly what you’d expect)
- Push (Windows Notification Service – WNS), which will work even when your app isn’t running.
Roam to the Cloud
Apps only run when on screen but should feel always alive. For example, if you finish a level on a game you should never have to do it again when you play the game on another device. Likewise, when you change an app or system setting, that change should be reflected across all your devices. E.g., Â°C vs. Â°F in your weather app, your RSS feeds, cities you’re interested in, etc.
This is made possible by the cloud, and your settings information is tied to your Windows Live ID. Every app gets an allotment of content, which isn’t gigs, but it’s enough to store basic state information.
Should use the settings charm for settings rather than build your own UI.
You can imagine that this would also come in really useful for Win32 apps for storing settings, projects, and so forth but, of course, it’s only available for Metro apps.
Great Metro apps preserve state as they go and don’t have an explicit save. This is important because when your app is swiped off screen you have about 5 seconds to save state before it’s suspended.
The kind of state you might save is, e.g., the furthest position I’ve read in an eBook, the last checkpoint I reached in a game, the last track I listened to in a media player.
Embrace Metro Principles
- Take pride in craftsmanship
- Make your apps Fast & Fluid
- Make the experience authentically digital
- Do more with less
- ? – didn’t get this one down – TODO: watch end again