Windows Phone METRO DESIGN LANGUAGE

Before getting much further into the ins and outs of Windows Phone, it’s worth taking a step backward and looking at the approach that Microsoft took in designing the user experience. Rather than simply refining what they already had, it was time to make a clean break and come up with a revolutionary design. The outcome of this process was not only a unique mobile interface but also a design language that you can, and should, adopt as part of building your application.

As part of going forward, it’s important to look back, even if only for a moment to wave as it disappears into the sunset. In the case of Windows Phone, the legacy of Windows Mobile from Pocket PC 2003 SE, through Windows Mobile 5.0, 6.1.4, and finally 6.5.3. As you can see, each has been an incremental approach with little to excite the user, save the more touch - friendly home screen and controls in Windows Mobile 6.5.3.

What’s important to recognize is that although the Windows Mobile user interface appears somewhat dated now, there are some important concepts embraced within the layouts — for example how relevant information could easily be accessed right from the home screen, and that applications were only a click or two away via the Start menu.

The user interface on nearly all the current- generation Smartphone is geared around applications. The underlying operating system typically handles standard information types such as e - mail, calendar, and contacts, but it is left to individual applications to handle other types of data (e.g., updates from your favorite social networking site need to have an application running on the device). Unfortunately, these applications are often built in isolation and don’t interact with each other or even integrate into the phone experience. In building Windows Phone, it was important for Microsoft to build an immersive user experience, rather than a set of disjointed applications. This needed to encompass all the features that make up Windows Phone, as well as the ability for third - party applications to be built to integrate into the same experience.

It was decided that Windows Phone should have a fresh start and not just the new Start that you see when you first unlock a Windows Phone. This should not just be about an ad hoc change to the way applications look, but a new language for communicating with users. What Microsoft came up with is what they refer to as the Metro design language, based on generations of refinement that have gone into the use of signposting, signaling, iconography, fonts, and layout in the transportation industry. The name Metro was chosen to reflect its heritage in the language used to efficiently guide people to their destinations.

If you examine signs used around and on buses, trains, and other forms of transportation, and at stations, airports, and other transportation hubs, you can clearly see a set of principles that govern them. Most of them have graphics that are instructional, yet minimal in design. Furthermore, the signs are typically universal and feature simple icons. The use of color is significant and plays an important role alongside weight and style when applied to text. Unlike in a lot of software systems, where it is almost an afterthought, the use of different typography in signs can dramatically affect the readability and thus the effectiveness of those signs.

Using transportation signage as a base, the Windows Phone team collaborated with other teams within Microsoft in order to fl esh out the design language. For example, the use of motion and animation in the Xbox, the use of navigation via content on the Zune and Media Center, and the intimacy of the ZuneHD interface were all sources of inspiration for Metro.

The resulting Metro design language is about being modern with a clean and fast user experience. It’s about delivering an experience that is in motion and all about the content. Being authentically digital in design and using clear typography are also important throughout the Windows Phone experience.

Source of Information : Wiley-Professiona Windows Phone 7 Application Development 2010

read more...

Windows Phone Screen Resolution

Dealing with differing hardware was just one of the challenges faced by developers working with the Windows Mobile platform. In seeking to be a platform that could be tailored to a wide variety of user scenarios, Windows Mobile 6.5 supported six touch - screen and five non - touch – screen resolutions. As you have already learned, there won ’t be support for non - touch screen in Windows Phone, but what ’ s even more exciting for developers is that with Windows Phone there will only be two different screen resolutions that you need to accommodate.

The initial platform will be released with WVGA (480 _ 800) resolution. A second resolution, HVGA (320 _ 480), will follow sometime in the future.

Whenever you see a Windows Phone being demonstrated, it is likely that it will be in Portrait mode. In fact, if you look at some of the core areas of Windows Phone, such as Start, they only support being displayed in Portrait mode. However, this doesn’t prevent you from taking advantage of running in Landscape if that ’ s more suitable for your application. In fact, the best applications are those that allow either orientation, reorganizing the layout in order to make best use of the available screen real estate. Windows Phone also provides the necessary extension points for your application to handle the change in device orientation during operation, such as sliding out a physical keyboard on a device that has one.

Source of Information : Wiley-Professiona Windows Phone 7 Application Development 2010

read more...

Windows Phone Chassis Design

So far you know that hardware manufacturers can optionally include a keyboard, but what else can they modify? In the past this was quite an open - ended discussion as manufacturers could build a device to meet a certain price point. For example, for high - end devices, they could include GPS, an accelerometer, and a high - resolution camera; a low - end device may only have a T9 keypad and no camera at all. Even the number and layout of physical hardware buttons could change between devices. Of course, all these options come at a cost, and the first place this took hold was with developers. When building applications, developers were seldom able to rely on a particular hardware feature being present. Instead, you would typically either query an API to determine if hardware existed, or simply attempt to address the hardware. Failure or an exception would indicate the lack of supported hardware.

After the application had been developed, the problem was transposed to the end users. They would see a product advertised as being compatible with Windows Mobile and purchase it, only to discover that it required hardware that they didn’t have. No two Windows Mobile devices were alike. When it came to Marketplace for Windows Mobile, Microsoft acknowledged this issue, and as part of application submission, developers had to indicate what device capabilities their application required. The Marketplace client running on the device would then restrict the list of applications to only those that matched the device capabilities.

For Windows Phone, Microsoft has taken the proactive position of enforcing a set of requirements around device capabilities. This has been achieved by taking the traditional minimum hardware specifications and turning them into what Microsoft calls a chassis design . This specifies the external buttons, and in some cases their location, and the inclusion of particular hardware features such as Wi-Fi, GPS, accelerometer, compass, camera, light and proximity sensors, and the ability to vibrate. A device that doesn ’ t include all of the features dictated by a chassis design cannot be called a Windows Phone.

On the front- facing side of a Windows Phone there will be three buttons: Back, Start, and Search. There will also be dedicated camera, power, and volume controls.

It’ s important to note that these hardware buttons have a dedicated purpose. Unlike in Windows Mobile, where the buttons could be assigned by the user to different functions, and then applications could elect to override all or some of the buttons, on a Windows Phone the buttons have a sole purpose. This reinforces the overall user experience through a consistent interface. The one exception to this rule is the Back button. Within your application you are able to control the navigation sequence. This means that you are able to intercept and handle the Back button. However, it is important to remember that the purpose of this button is to navigate back to whence the user came. For example, if they click to delete an item from a list and the application displays a confirmation prompt, the Back button should dismiss this prompt without deleting the item. Similarly, if the user has clicked an item in a list and gone through to a Details view, the Back button should navigate the user back to the list of items.

If you ensure that you correctly handle the Back button, there should be little need for your application to include navigation controls within the context of your application. Forward navigation is typically done through interaction with content; Back navigation is instigated from the Back button, and exiting your application is little more than pressing the Back button when on the first page of the application.

You can think of every application you open as being placed on a stack. When you hit the Back button and have not purposely handled it within your application, the application is popped off the stack and the previous one is displayed. This analogy works well as Windows Phone will automatically close your application when it goes out of focus by being popped off the application stack.

Similar to other mobile platforms, Windows Phone has a dedicated“ I ’m lost, take me to a known location ” button. As it ’ s a Microsoft platform, this button is logically called the Start button and takes the user back to the Start experience. As you will learn, the Start is an area on the device that contains a personalized set of tiles that reflect what’s important to the user. It also acts as a launching point for accessing areas of the device and applications that the user may have installed. The last of the buttons on the front of the device is the Search button, also known as the Bing button . Pressing the Search button launches a context- sensitive search. For example, if you are looking through your contacts, pressing the Search button will filter your contacts based on the search criteria. If there is no appropriate search context, pressing the Search button will launch Bing Search, allowing you to search over Web content, images, and maps. At this stage it is not possible to integrate the Search button into your application, so tapping it within any third – party application will launch Bing Search.

The inclusion of Wi-Fi seems like an obvious requirement, but with the advent of 3G+ networks that are continuing to get cheaper, it would have been an easy cost saving for manufacturers to omit the Wi-Fi stack. In the early days of Windows Mobile, before Microsoft tightened security, it used to be possible to synchronize your contracts, calendar, and e - mail with Outlook by connecting to ActiveSync through a Wi-Fi network. This capability is returning with the ability to synchronize across your home Wi-Fi network to your Zune desktop experience.

Location is definitely one of the hip new fads being talked about across the software development community. Software that is aware of the user’s location means that it can locate information and people nearby. Of course, there are all manner of privacy issues to navigate, but it is important that Windows Phone can provide location information. This topic will be covered in detail in the context of the location services offered by the platform, but it ’ s enough to say that having a GPS is essential in order to accurately geolocate the user.

One thing that you will notice about Windows Phone is that it is the first mobile offering from Microsoft that has been designed with a consumer rather than enterprise or business user focus.
Previously, Windows Mobile was more tailored for the mobile worker, with support for enterprise features such as device deployment and management at the expense of a consistent set of hardware capabilities. As a consumer device Windows Phone will offer a minimum of a 5 - megapixel camera with integrated fl ash. Windows Phones will also include light and proximity sensors that will be used to enhance the user experience.

In building your application, you need to be very aware of the experience you are constructing for the user. Where you would have once provided simple on - screen feedback, you can now use more complex animation and sounds and even have the device vibrate. You should use all visual and hardware effects sparingly as it is easy to overwhelm the user and drain the phone’s battery in the process.

Source of Information : Wiley-Professiona Windows Phone 7 Application Development 2010

read more...

Windows Phone MINIMUM SPECIFICATIONS

Traditionally, Windows Mobile has had the stigma attached to it that it is slow and unreliable. This had little to do with the underlying operating system, but rather the other stakeholders involved in getting a device into market. Manufacturers, telecommunication companies, application developers, and other third parties all contribute to what comes prepackaged on a device. Each one of these parties builds or adds features that they think will benefit the user. Unfortunately, quite often these features either degrade the overall experience — for example, hogging precious device resources — or don ’ t play well with other aspects of the phone. This has led to an overall negative impression of the Windows Mobile platform as a whole.

Microsoft took the opportunity with Windows Phone to restructure the ecosystem in which devices operate. Although they haven ’ t been so arrogant as to come out with the Microsoft Phone , which many were anticipating, they have put some checks and balances in place to ensure that users receive an amazing experience, and, furthermore, that this experience is uniform throughout the phone and for the duration of the phone ’ s life.

It all starts with the hardware. Previously Microsoft has been overly optimistic in specifying the minimum specifications for Windows Mobile. This resulted in many devices that were woefully underpowered, and although this kept the price point low, the devices were frustratingly slow and unresponsive to use. Going forward, Microsoft has defined a much higher set of minimum hardware requirements for Windows Phone, which includes a 1 - GHz processor and support for graphics hardware acceleration. When you look at the frameworks that are to be used to develop applications and games for this platform, it is very evident why such high hardware specifications are required.

In addition to having graphics acceleration, Windows Phone devices will appear to be highly responsive because of the use of capacitance screens. This, in turn, lends itself to supporting multi - touch. The net effect is that users will interact with a Windows Phone device using gestures such as tap, pinch, and swipe with their fingers, rather than the more traditional mechanism of using a stylus.

There is currently no intention to support a non- touch- screen Windows Phone device. However, device manufacturers will still be able to differentiate their devices through different device ergonomics and the optional inclusion of a hardware keyboard. A hardware keyboard will complement the Windows Phone experience, making it easier to enter text rapidly. This is particularly useful for e - mail, messaging, and annotating documents on the road.

Source of Information : Wiley-Professiona Windows Phone 7 Application Development 2010

read more...