Metro Style apps vs desktop applications
Microsoft’s new Visual Studio 11 controls have animation turned on by default – no additional coding is required of the developers to make Metro Style apps animate beautifully. For instance, when you add an item to a list, all the existing items slide down to make room for it, and it fades into place.
The user sees this action happen, even though it takes only half a second, and there’s no cost in CPU cycles because the graphics adapter handles the animation. In his talk, Jensen Harris showed a demonstration app without and with animation, and the improvement was very apparent.
The phrase “fast and fluid” won the Buzzword Bingo stakes in the opening keynote session of the Build conference, and for good reason
The phrase “fast and fluid” won the Buzzword Bingo stakes in the opening keynote session of the Build conference, and for good reason.
Quite unlike a command line interface, and more so than with any previous mouse-driven graphical user interface, a touch interface needs to feel like you’re intimately connected to the computer and that any lag in response is intolerable. Programmers will have to up their game when programming Metro Style apps, to ensure that nothing blocks the UI thread, and every touch is responded to instantly.
Metro Style apps will also have to scale well, to cope with different form factors, resolutions and display densities. Screens may vary in size from less than 10in to bigger than 27in, and new displays are arriving with pixel densities of more than 200dpi compared to the standard 96dpi in use today.
Apps may be snapped to the side of the screen (where they get only 320 horizontal pixels) to share with another app. On handheld devices, the screens may be rotated to portrait and back to landscape in a couple of seconds. The good news is that the minimum screen size for Windows 8 is 1,024 x 768 pixels, so developers no longer need to worry about 640 x 480 or 800 x 600, which are consigned to history.
Metro Style apps will interact with each other without having to explicitly know each other’s capabilities via “contracts” – defined interfaces for operations such as Search, Share, Settings or Picker. Any app that implements one of these interfaces can integrate with all other apps that also implement that interface.
For instance, the Share contract comes in two parts: Source and Target. If an app has files or resources to share, it implements the Share Source contract, stating what it has to share. If an app allows things to be shared through it, it implements the Share Target contract saying what it will accept.
If you find something in an application that you’d like to share, select the item, swipe in from the right of the screen to show the Charms and press the Share Charm, which brings up a list of all the apps through which you can share the type of item selected (URL, text, picture or whatever).
Pick the app you want to use, and that app’s sharing UI appears on the right-hand side of the screen. Add whatever information is required by the second app (email address, extra notes and the like) and the job is done.
The Search contract is used to search for content in any application and is implemented in a similar way to the Share contract. Developers are encouraged to use this standard UI to search for content items containing particular strings of text, but it isn’t suitable for finding text within a particular document – for that you’d have to implement your own UI inside your app.
The Picker contract allows apps to get files from the PC’s file system, the network or from online services. Apps that implement the Picker contract show up whenever you go browsing for a file, and present it just as if it were on the local machine.