Improvements:

• Increased power efficiency to extend battery life
• Performance improvements in Windows 8 applications and Start screen
• Improved audio and video playback in many scenarios
• Improved application and driver compatibility with Windows 8

Known issues:

• When you turn a Windows feature on or off, the computer may require a restart. For example, this action may be necessary when you turn Remote Access on or off.

We’re super excited to be approaching general availability (GA) of Windows 8 and Windows RT. With thousands of new apps in the Store, there are a lot to choose from and tens of thousands of developers have been very busy around the world creating new apps. Across Microsoft we’ve been busy since August adding new features and improving the apps that come with Windows and will be updating these apps before GA. We’ll introduce new features, improve performance, and increase reliability. This post is authored by Gabriel Aul on our program management team and details some of the updates you will see starting in the next day or so as the updates enter the Store.
--Steven

As we get close to the general availability (GA) of Windows 8, there are many things that the Windows team and other teams at Microsoft have been doing to get ready. Of course, the most important thing has been working with PC makers to help them ready the wave of amazing Windows 8 PCs that will soon be available. Some of these have been announced already and more announcements are to come. With Windows 8, we also introduced a new Store for Windows 8 apps, as well as a number of new apps that are included with Windows. We already have thousands of apps in the Windows Store, even before GA, and we’re working with developers from around the world to bring more in every day. The Windows Store represents an unprecedented opportunity for developers to reach hundreds of millions of customers, and we’re very pleased to see the exciting things that are showing up every day.

Of course, we are also taking advantage of the integrated way that we can deliver updates to apps through the Windows Store. Leading up to GA for Windows 8, we will be releasing updates for many of the apps that were included with the release to manufacturing (RTM) build of Windows 8 that was delivered to PC makers and to MSDN and TechNet subscribers in August. Naturally, these app updates will also be available to PC makers to include by default with their PCs shipping in the future, but for those of you who have already installed Windows 8 RTM, it is super easy to get the updates from the Store app. The Store tile will notify you when updates are available, and you can open it and click the updates link in the top right corner to see the list and install the ones you want.

The Bing app will be the first one out, available tomorrow, and more updates will roll out up until Oct 26^th. You will be notified of Windows Store updates just as you have come to expect, with a count of available updates on the Store tile. You can easily choose to install the updates at a convenient time:

Across the board, you’ll see performance and reliability improvements in the apps, but there are some great new capabilities as well. Here are some highlights of the changes you’ll see:

We are excited to get these updated apps out to all of the people who have been using Windows 8 so far, and to have them ready for the Windows 8 launch for people buying new PCs or upgrading their existing PCs.

-- Gabriel Aul

Since RTM on August 1, PC manufacturers have been using the released software to ready new PCs designed for Windows 8. Collectively, we are all very excited by the innovation and creativity that will arrive in market this October. Our engineering collaboration has been better than ever as we work to bring better performance, reliability, and battery life to new PCs designed for Windows 8. We also know many are interested in how we extended this process to a new generation of PCs built on the ARM platform. This post details how we have collaborated on the development of Windows RT and new PCs designed for the operating system. Mike Angiulo, the vice president of our Ecosystem and Planning team, authored this post.
–Steven

Windows 8 and Windows RT each reached the RTM milestone, and we are hard at work in collaboration with ecosystem partners, including PC manufacturers, Silicon partners, and other component suppliers, to complete high quality Windows RT and Windows 8 PCs that we think you’ll love. We’re very excited about the designs PC manufacturing partners have built on the foundation of Windows 8 and Windows RT.

The breadth of Windows 8 Intel- and AMD-based designs from our PC manufacturing partners will continue to push the envelope with powerful computing and innovative design. You can expect to see everything from ultra-thin sleek designs with stunning high-resolution displays, to beautifully designed All-In-One PCs with large immersive displays complete with touch, to high-power towers rocking multiple graphics cards and high-performance storage arrays. In addition, this broad range of PCs will provide price and feature combinations that allow every customer to find a PC that fits their needs and lifestyle perfectly.

We are particularly excited about the new low power x86 Windows 8 PCs that will take advantage of Intel’s SoC platform innovations to provide an always on and always connected experience (known as connected standby). Just recently, Lenovo announced the ThinkPad Tablet 2, which offers an outstanding combination of new features built on the latest Intel ATOM® processor. We’ll cover the benefits of this scenario later in the post.

Microsoft has worked very hard with this release to provide the tools and support to contribute to new PCs that are more reliable, faster, use fewer system resources, and have improved software loads than comparable Windows 7 PCs. From the newest Ultrabook™ to the most powerful and extensible workstations, Windows 8 PCs are on the way.

Windows RT begins a new era of ARM-based PCs, where we are working with our Silicon and PC manufacturing partners to bring a whole new set of innovations to market. In an earlier post, Building Windows for the ARM processor architecture, we focused on the detailed engineering work required to create Windows RT. In the remainder of this blog I would like to provide an update on our efforts to collaborate across the ecosystem in bringing new Windows RT PCs to market. But first, let’s briefly recap the key points from the previous post: 

• Windows RT shares significant code with Windows 8 and has been developed for and will be sold and supported as a part of the largest computing ecosystem in the world.
• We have achieved our goal of one Windows binary for all Windows RT SoC platforms from NVIDIA, Qualcomm, and Texas Instruments, each of which has developed innovative ARM CPUs that form the basis of a complete system.
• Delivering Windows RT PCs has been about building out a new system for the first time—a completely new ecosystem of PCs providing opportunities for PC makers to bring to life a new generation of PCs with new capabilities, starting with ARM-based processors.
• Windows RT PCs are thin and light in industrial design, and have long battery life and integrated quality. These PCs have all been designed and manufactured expressly for Windows RT.
• PC makers will provide Windows RT PCs as integrated, end-to-end products that include hardware, firmware, and Windows RT software. Windows RT software will not be sold or distributed independent of a new Windows RT PC, just as you would expect from a consumer electronics device that relies on unique and integrated pairings of hardware and software. Over the useful lifetime of the PC, the provided software will be serviced and improved.

If you are following Windows RT, perhaps you have taken note of the Asus Tablet 600 (Windows RT) announcement or Microsoft’s own Surface RT™ news. Along with Asus, we are excited to share that there will be ARM-based PC designs from Dell, Lenovo, and Samsung running Windows RT.

You will need to stay tuned for more details; PC manufacturers will be unveiling their products as we approach the Windows 8 and Windows RT launch. What I can say is the spectrum of form factors and peripherals being developed to meet each unique customer’s computing needs is unique in the industry.

“Dell’s tablet for Windows RT is going to take advantage of the capabilities the new ecosystem offers to help customers do more at work and home. We’re excited to be Microsoft’s strategic partner, and look forward to sharing more soon.”

- Sam Burd, Vice President, Dell PC Product Group

The uniqueness of our approach starts with a new way of working across partners to engineer a PC—a collaboration that brings the best of all parties together to deliver end-to-end experiences that are integrated and optimized from the chipset to the experience.

It’s also worth taking a moment to describe how our collaboration on these PC efforts has been different than in any other Windows release. Our engineering collaboration on these Windows RT PCs has been strong, collaborating with the PC manufacturers, Silicon partners, and Operators to focus on hardware, software and services integration. Each respective partner was committed to sharing early iterations of their products, whether it was a SoC bring-up board, early builds of Windows RT, firmware and drivers, or hundreds of pre-release PC hardware samples (such as the ones featured in earlier demonstrations and videos). Product designs were informed and revised by our collective efforts through development and testing. As a result, all of these Windows RT PCs will have consistent fast and fluid touch interactions, long battery life, connected standby, and are beautiful, thin, and light designs. All of these are designed to make the most of the capabilities of Windows RT.

This is a snapshot of an actual pre-release Windows RT PC, showing a very early engineering prototype and the evolution to its current form.

Windows helped achieve these goals by focusing on optimizing key scenarios. Taken together, these scenarios drive a new level of mobile experience and performance not possible without new technology and engineering collaboration. So let’s dig into to some of the specifics.

Connected standby is the scenario of having your PC be always on and always connected in the new connected standby state without excessively draining your battery, so that you have access to your important and up-to-date information whenever you need it. When your Windows RT PC is not in use, it will move into a new low-power mode that allows it to keep your data fresh and current while also not requiring a battery charge for days. And when you need your system, it will turn on in less than a second at the touch of a button, which is a mobile phone experience but in a full PC. Additionally, we focused on an aggressive whole system power modeling scenario that has allowed us to better inform battery capacities to deliver all-day battery life with days of connected standby in thin and light designs.

The following chart shows some of the measurement ranges we are seeing as we test early production PCs for the connected standby and power scenarios.

The measurements are based on firmware still undergoing final optimizations, and the just released Windows RT RTM code, and will only improve as the PCs move towards manufacture. To provide context on the significance of the measurement, it is important to understand how the scenario was measured. In this case, the PC was playing back in full screen a local HD video at full resolution with a screen brightness of 200 nits. It was also configured for one email account using the Microsoft network. Finally, these numbers are also influenced by the different PC form factors themselves, which include both tablets and laptops, screen sizes that vary from 10.1” to 11.6”, and battery sizes spanning 25 Whr to 42 Whr.

During development, further power modeling analysis at the component level allowed us to better understand where we needed to invest in design optimizations. For example, typical touch controller solutions were based on multi-chip solutions. By reducing those solutions to single-chip designs, we achieved lower power usage and reduced thermals, which translated to smaller battery sizes and thinner and lighter designs. The table below provides an overview of the typical weight and thicknesses we have been able to achieve with our partners across the different models representing different form factors based on ARM SoCs.

These single-chip solutions not only reduce power requirements, but they also provide performance optimizations that result in fast and fluid touch usage. The Windows RT PCs that our partners will be delivering for the upcoming launch provide sampling rates of 100Hz per finger. This not only allows for fast and fluid response, but also incredible industry-leading accuracy.

Our graphics core has also gone through extensive optimization. Besides the optimizations around power-efficient HD video playback, the core Windows RT UI animations achieve 60fps, which was our design goal.

We didn’t stop at optimizing power, thickness, and weight. We also focused on enabling exciting new scenarios in these Windows RT PCs, such as sharing information intuitively and easily. You will see NFC integration in some of our Windows RT launch PCs that open up fun and interesting things like tap to share. By simply tapping two NFC-enabled Windows RT PCs together, users can easily share photos, URLs, map directions, and anything else that our software partners have designed into their Windows apps. And of course Windows RT natively supports a broad range of device scenarios such as USB mass storage, printing, audio/video peripherals, and more, along with connectivity through WWAN, Wi-Fi, Bluetooth, and USB. These build on the common foundation of Windows 8 and Windows RT, and were previously shown as early as the //BUILD/ conference.

Windows RT is not just for tablet form factors. Some of our Windows RT PCs come with full keyboard and touchpad solutions, whether removable/dockable or a traditional clamshell. Not only do these solutions provide additional battery capacity, but they also provide a new touchpad experience that incorporates intuitive Windows 8 gestures. By working closely with our touchpad component vendors, we have incorporated native support in firmware to deliver incredibly fast gesture recognition that makes interacting with Windows a breeze. The touch gestures that will be natively supported are described in these two tables:

Single-finger slide	Single/two-finger tap, double tap	Two-finger slide
Mouse cursor manipulation	Primary/secondary button click, double-click at cursor location	Horizontal or vertical scroll (mouse wheel)

Two-finger pinch	Swipe in from the right edge	Swipe down from the top edge	Swipe in from the left edge
Zoom (Ctrl + mouse wheel)	Toggle the charms (Windows logo key + C)	Toggle the app commands (Windows logo key + Z)	Switch to last app (Windows logo key + Ctrl + Backspace)

Finally, the wealth of hardware components and optimizations is only as rich as the applications that take advantage of them. As an ecosystem, Windows, the PC manufacturers, and the Silicon partners have been engaged with developers around the world to design application experiences that will light up the capabilities of this new PC hardware. We’ve purposely built thousands of reference design hardware systems to develop and test the OS and apps, collectively seeding over 1500 Windows RT reference systems to ISV and IHV companies in preparation for launch. The results are starting to show, as we’ve seen over 90% of the RTM applications in the Windows Store support Windows RT, as well as the Windows Hardware Certification requirements working to ensure every Windows RT PC is indeed compatible with a broad set of peripheral devices such as printers, webcams, and mobile broadband modules.

Windows RT represents a significant re-imagining of not only Windows, but Windows PCs and how we partner together to engineer them. The deep engineering collaborations from the Silicon and component manufacturers through to our PC partners and Windows engineering team have provided a compelling suite of exciting new Windows PCs that deliver on the promise of fast and fluid, always on and always connected, thin and light, and all-day battery life. We are looking forward to the exciting announcements ahead from Dell, Lenovo, and Samsung.

--Mike

--The Windows 8 team

Printing is one of the most common things we do with our PCs even as we read and work with more online resources.  We set out to simplify and improve this common operation--working with partners across the ecosystem to deliver these improvements in Windows 8.  This blog post was authored by Adrian Lannin, a lead program manager on the Printing team. 

--Steven

Of all the peripheral devices that you can connect to your Windows PC, printers are one of the most popular, and have been supported for the longest time. In fact, Windows 1.0 (shipped in 1985) supported “a number of printers and plotters” and included a “Print Spooler [which] allows the user to work on one file while printing on another” according to the Windows 1.0 Press Kit. The screenshot of Windows 1.0 below shows the files included with that version of Windows – Epson.drv, lots of font files, and the print spooler process. Some parts of the print system are older than the people who work on it. :-)

Over the years, the print system has evolved into a complex architecture that supports printing to a huge variety of printers, and can scale from a simple $50 inkjet at home to a high-availability print server hosting thousands of print queues for hundreds of thousands of users, driving printers that cost tens of thousands of dollars each.

The print system touches many layers and facets of Windows. It shows UI, and it hosts drivers that also show UI. It performs intensive graphics operations, since printing is essentially re-drawing your on-screen content onto paper. It encompasses lower-level communications, mainly USB or network (the majority of printers bought in the US today are network-capable, but our telemetry data tells us that over 75% of the printers installed with the Windows 8 Consumer Preview are plugged into a USB port). The print system needs to scale to very large, mission-critical deployments in large businesses but also run efficiently on small systems.

In this blog post I’m going to talk about the work that we've done in Windows 8 to re-imagine how the print system can best provide good device support to our customers. I'll show you how it works on ARM-based PCs and in Metro style apps. And I'll talk about what we've done to ensure that the maximum number of existing printers "just work"—whether you're accessing them from the desktop, from a Metro style app, or on a device running Windows RT.

Reimagining the print system for Windows 8

In Windows 8 we've introduced a new printer driver architecture, which we call version 4, or v4. The v4 architecture produces smaller, faster printer drivers, and it supports the idea of a print class driver framework--a system that allows people to install their printers without having to locate a driver for that device, in many cases.

As you've probably guessed, V4 is the fourth iteration of the printer driver architecture in Windows. V3 was the architecture used from Windows 2000 to Windows 7, and it’s actually still fully supported in Windows 8 for device compatibility reasons. So if you only have an existing driver available for your current printer, then it should still work in Windows 8. Versions 1 and 2 were the driver architectures for Windows 1.0 through Windows ME.

Before I explain how the print system works, I’d like to talk about some of the requirements that we worked to address with the Windows 8 print system.

Printing from Metro style apps

One of the things that we needed to figure out was how to give Metro app developers the ability to print. Printing from win32 applications requires knowledge of graphics programming, either GDI (Graphics Device Interface) or XPS (XML Paper Specification). When we looked at how we could make printing possible from Windows 8 apps, we completely reinvented how we enable printing from the Windows Runtime, and we made printing very easy to use from HTML5/JavaScript and XAML/C# apps.

Integrating printing into Metro style apps

Printing from a Metro style app should naturally be a Metro style experience. I’m sure that when most of you have printed something, you've seen a little applet pop up to tell you that the printer is out of paper, or to offer you the opportunity to purchase ink.

These pop-ups are very common with inkjet printers. Some pop up only when relevant (you have low ink), while others pop up every time you print. These pop-ups come from the printer driver software itself, and they are all desktop UI, of course. But when printing from the Metro style Photos app, for example, we don’t want you to have to switch over to the desktop just to see UI that tells you that printing is in progress.

Printing in Windows RT

Printer drivers have evolved over time to include a lot of functionality— some install services, some install numerous little applications, and many are now quite large. The v3 printer driver model in use since Windows 2000 evolved into a highly complex and highly extensible model, which allowed printer manufacturers a lot of freedom in what is installed with their driver software. When we thought about how this would work on some of the devices that are going to run Windows RT, we knew that we had to make some significant architectural changes. We really wanted to ensure that we didn’t negatively impact ARM systems by running unnecessary services, and we wanted to reduce system resource usage, while still providing support for as many devices as possible.

Lots of printers supported, far fewer drivers

There's a huge diversity in printer capabilities, and Windows supports a vast range of printers. In Windows 7 and earlier versions of Windows, each of these printers required a specific driver in order to work (there are some exceptions, such as universal printer drivers, but these tend to be large and resource hungry). This meant that the number of drivers that we included with Windows (we call these in-box drivers) was very large so as to provide good support. Of course, we have many more drivers on Windows Update, but we believe that it’s important to have a core set of in-box drivers that support popular devices, so we can still provide a good printing experience for people who can’t or won’t download a driver from Windows Update. In-box drivers are essential for Windows RT—in fact, it uses only in-box printer drivers. The challenge here is to get a relevant set of printers supported, but to also reduce the resources required to accomplish this.

Another interesting challenge in supporting lots of printers is that the support gets stale over time. The set of drivers included in Windows 7, for example, provided excellent support for devices released in 2008 and 2009, but as new devices were released over the years, and time went by, the set of drivers in Windows 7 became less relevant. One big challenge in Windows 8 then, is to ensure that Windows provides a high level of support for lots of printers, including ones that haven’t even been released yet.

Printer sharing

Anyone who has administered a print server can tell you that getting the correct drivers installed to support sharing is the most time-consuming part of managing a print server. Some of these difficulties you might encounter when you're trying to share a printer at home too, especially if you have both 32-bit and 64-bit versions of Windows. This becomes tricky because the print “server” (which just means the PC that the printer is connected to – not actually Windows Server) has to provide the drivers to the clients that want to print to the shared printer. In Windows 7, we used HomeGroup to address this problem, and it works well much of the time. However, the requirement to load drivers for each Windows architecture becomes more problematic when you think about printing from Windows RT.

Although we expect that most people who print from Windows RT devices are likely to print to wireless printers, we didn’t want to totally exclude the possibility of printing to a USB printer. On the other hand, we didn’t want to increase the complexity of printer sharing by requiring people to add drivers for 32-bit clients, 64-bit clients, and Windows RT clients! So, with the v4 model in Windows 8, we developed a new way to share printers that doesn't rely on putting client drivers onto the print server.

The print system in Windows 8

Applications enable you to create and view content. The purpose of the print system is to provide these apps with the means to print your content to any installed printer without having to worry about what particular device is installed. I’m going to talk a little about how the app prints, and go into more detail about how we get the content onto a printed page.

Creating printable content

For apps, adding printing support is quite straightforward. The content that you want to print from an app is in a format that the app specifies. For Metro style apps, this will often be HTML5 or XAML, but for Win32 apps such as Word or Photoshop, the content is in a format specific to each particular app.

So when you want to print from an app to your printer, one of the things that the print system needs to do is to translate the content from the app's format to the format that the printer understands. Unfortunately, printers don’t all understand the same formats (not even close!) so this turns into quite a bit of work.

To give a real example, an app such as Word uses the GDI graphics system to draw the content both to the screen and to the printer. When possible, the print system uses a high quality intermediate format called XPS (XML Paper Specification) as its internal content format; we convert the content from Word into XPS. We chose to use XPS as the foundation of our print system because it is a very flexible format and is just like electronic paper. It supports high-fidelity color, and since it’s an XML-based description with no executable code embedded, it’s great for archival purposes and it is secure compared to other options. In addition, Microsoft has worked with ECMA International (European Computer Manufacturers Association) to make it an open standard (ECMA standard TC46, OpenXPS). Both the desktop viewer and the Reader app can display OpenXPS. I “print” all my receipts from online purchases as XPS files.

Once the content is being managed by the print system, it is then converted to the format that the printer understands (if necessary; there are lots of printers that understand XPS directly) and the print system sends this to the printer with the correct options set, and the job prints.

In Windows 8, we have a distinct improvement to this story because all Metro style apps use Direct2D as their basic drawing format, and Direct2D and XPS share the same XML-based graphics “language.” So in another real-world example, the Reader app uses Direct2D to render its content onto the screen. It also uses Direct2D to render the same content to the print system. Reader’s content can easily be submitted to the print system as XPS, without any costly conversion from GDI.

If the app requires a print layout that is different from the screen layout, then it can do this using style sheets or XAML. This means that you don’t have to “click here for a printer-friendly version of this page.” If you have a printer that supports XPS, then the path from the app to the printer involves no conversions at all, and printing is extremely fast!

Now that you understand in broad terms how an app sends print information to the print system, I’m going to talk about what the system does with that, the services it provides, and what else has changed in Windows 8.

Supporting lots of printers

One of the big benefits that Windows provides to apps is that it abstracts the specific printer from the app, so that the app's programmer doesn’t have to worry about what printer you've installed. Windows supports tens of thousands of printer models in total, including printers that are supported by drivers available via Windows Update or the manufacturer’s website. When we see printers that don’t work, this is often because the manufacturer has chosen to block the installation if they don’t recognize the version of Windows that their software is being installed on. We work with printer manufacturers to get these packages updated, but this does take some time.

Ideally, when you plug a new printer into Windows, it just works, without your needing to go off and find drivers.

So how do we make that happen? In the past we've shipped a lot of printer drivers in Windows. Vista contained about 4500 drivers, and Windows 7 contained about 2100 drivers. Even though Windows 7 had half as many drivers as Vista, it provided better market coverage, by which I mean that there was a better chance that it had a driver for the more popular printers. Why is this? There is an incredible diversity of printers in use. In Vista, we supported a lot of devices that were old and no longer in popular use, and so the relevance of the set of devices supported was not as good as in Windows 7.

As an aside, the other thing we do when we release a new version of Windows is to take the drivers that were in the previous version and post them to Windows Update, so that even though these devices may be dropping in popularity, it’s still possible for people to automatically get the device working by just plugging it in.

Here's a photo I took of one of the benches in one of the printer labs (we have several) where we test that this all works. You can see several small inkjets and laser printers from different manufacturers. Luckily for my ears, we don’t test with dot matrix printers very often these days.

People tend to keep printers for 5-7 years on average, so when we want to add support, we have to think "what devices are people using? Which were the most popular devices over the past several years, and what will be the most popular in the future?" This last part is tricky because, pretty soon after we release Windows, the printer manufacturers will release devices that we didn’t know anything about. This means that over time, the set of devices that we support in any particular version of Windows becomes stale.

We know that at any given moment, about 100 specific printer models make up about 50% of the installed base. If we want to support 75% of the models being used today, then we need to support about 300 models. The diagram below illustrates this.

To get to 95%, we need over 1000 models supported. But the problem is even harder because the printers that make up this set of 100, or 300, or 1000 changes all the time. The 100 printers that represent 50% of the market today are not the same 100 printers that will represent 50% next week, or next month, and especially not next year. Every day, many people buy and install new printers.

As I mentioned above, we basically took a brute-force approach to solving this in the past. We have representatives from the major printer manufacturers working directly with Microsoft, sitting in offices in Redmond, working to check their source code into Windows. They would create a completely new set of in-box drivers for each new release of Windows. This just isn’t very efficient.

In Windows 8, we took a radically different approach, and have stopped shipping lots of printer drivers with Windows. Instead, we built a print class driver framework. This framework is extensible, as it supports printing to existing devices, but it also allows manufacturers to include support for new devices, even those that have not yet been designed.

With a print class driver framework, we can get closer to giving you an experience like driverless printing, where you don't have to actually go and find a driver, but instead the printer just works with the Windows printing system. A true driverless printing experience requires changes to how most printers are designed, and the print class driver framework provides support for this idea, but we also feel that it’s very important to provide as much support for existing devices as possible.

With the ability to support new and planned printers, the number of printers that are supported by the Windows 8 print class driver framework will actually increase over time.

Besides the great progress in increasing the number of devices covered, we have also been able to reduce the resources that we use to achieve this coverage.

First, we reduced the amount of disk space needed to support printers and imaging devices from 768MB in Windows Vista, to about 184MB in Windows 8. This number is an average across different editions and architectures of Windows 8. The following graphic illustrates the reduction in space used since Windows Vista.

Comparison of disk space needed to support printers and imaging devices in Windows 8, Windows 7, and Windows Vista

In addition, the reduction in disk space used has been accompanied by an increase in the relevance of the devices supported directly by Windows. The following table summarizes how the relevance of the inbox coverage has increased, while disk use has decreased.

This is a huge improvement in Windows 8, and this reduction in space used directly translates into more available storage space for users of hardware with limited storage capacity, which we expect will be a characteristic of some Windows RT computers.

The Windows 8 printer driver model also allows us to focus our manufacturing partners on a set of code that will not change as much from one version of Windows to the next, so we will be able to more usefully spend those resources on improving quality and performance, instead of constantly repopulating the driver set.

Print class driver architecture

Besides wanting to create an architecture that supports the needs of Windows RT and Metro style apps, we wanted to make sure the model would also work with existing devices, and would utilize technologies that were familiar to printer manufacturers, so that it would be easier for them to implement the new driver technology.

A printer driver does several key things:

• Configuration allows the user to change settings, translating the intent to turn on double-sided printing (for example) into the specific command that the printer needs for this. Configuration is presented to the user through the user interface.
• Rendering translates the printed content from the format that Windows print system uses into the format that the printer understands. In some cases, the printer may directly understand the native Windows print format (XPS), so for those devices, there is no work to do here, unless they want to do extra rendering (doing multiple pages per physical sheet of paper is an example of this case). The part of the driver that does rendering is called the render filter.
• Events allow the printer to inform the user that something has happened – a job has completed, there has been a paper jam, or the printer is out of ink.

Configuration UI

One big change between the old driver model and the Windows 8 driver model is in how the UI is provided. In the old printer driver model, the configuration UI was built into the driver. Here's an example of some typical printer UI (taken from the Epson NX430 that is currently on my desk).

As I mentioned earlier, we needed to find a way to enable the display of Metro style UI when people wanted to change printer settings.

In the Windows 8 driver model, the manufacturer’s UI is completely separate from their driver. This is a much better architectural decision for many reasons: The UI to control the printer is now an app that can be invoked when printing from Metro style apps or desktop apps. This allows printer manufacturers to present you with a much richer experience – imagine access to video showing you how to set up your printer or install an ink cartridge.

Here is an example of a Metro style app that Epson has developed for the Epson NX430:

You can see that this UI has all the hallmarks of a Metro style app, but for your printer. It includes an attractive view of the ink levels of the printer, and is much easier to use, especially on touch-screen devices.

Windows will automatically show you the correct type of UI – desktop printer UI when you're printing from desktop apps, and Metro style UI when you're printing from Metro style apps.

If the manufacturer hasn't provided any configuration UI for their device, then Windows provides some standard UI that you can use with any printer. However, when the printer manufacturer has decided to invest in providing a customized experience for their device, they can provide an app that replaces the standard Windows UI. Then, when you decide to alter the configuration of the device, or when the device configuration changes during printing (e.g. paper jam), then Windows will display the manufacturer’s customized app to you instead.

Rendering

One of the most important functions of a printer driver is to take the content that the app produces when you ask it to print, and convert that into something that the printer can understand. This was one of the most challenging areas of building the Windows 8 print class driver, so let’s look at it in a bit more detail.

As described above, desktop apps like Word or Photoshop use graphics commands to draw their content onto the screen or the printer. When they do this, the print system receives the content, converts it into XPS if necessary, and then calls the printer's driver (or more specifically, the render filter part of the driver) to convert the content into the right format. This is sent to the printer and your file is printed out.

Probably one of the largest challenges in supporting a very wide range of printers is in dealing with the rendering portion of the problem. Some of the more expensive printers support standard “page description languages” or PDLs, such as PostScript, PCL, and XPS. However, less expensive, consumer-focused devices are manufactured with cost savings in mind, and many of these support proprietary methods of sending the page information to the printer. Some manufacturers may have only a few languages that they use across their product line, but others may tweak the language from one model to the next, trying to get the most out of their printer hardware.

This leads to a 1:1 mapping between printer driver and printer hardware.

Imagine each PDL as being a complete printer driver and it’s easy to see that increasing support involves a steadily increasing number of drivers. Of course, this is a bit of a simplification and it is possible to create a driver that supports a number of devices, and we have often seen drivers that support a series of printers. But the key point here is that Windows 7 and earlier versions of Windows didn’t do anything to support this design approach.

The printer driver model in Windows 8 supports the idea that a PDL (or driver) can be associated with multiple devices.

We've been working with our printer manufacturer partners to have them include an identifier in their device that describes how they are supported more generically. We call this a compatible ID. So for example, if a device has a compatible ID that says that the device supports XPS, then the print system knows that it doesn’t need to find a model-specific driver for that device, it can just install a generic XPS driver for the device. Windows understands that the device is a generic XPS printer and can treat it that way. Of course, Windows also understands that this is a Fabrikam 1000 printer (or whatever), so if there is a model-specific driver, then Windows will install it. But if there is no driver available, then Windows can still print to the printer using the class driver.

So in this example, we have a set of render filters in-box as part of the class driver model, and these can be installed for any device that implements a matching compatible ID. The logical extension of this idea is that it’s quite possible for future devices, devices not yet designed or built, to be compatible with the print class driver in Windows 8. We’ve been working with the printer manufacturers and they all plan to implement compatible IDs in their devices (many already do). Because of this capability, the number of printers that are supported in Windows 8 will increase over time, rather than decrease, and more and more people will get the experience of being able to use their printers instantaneously from Windows 8 without the need to go and find a driver.

But what about all the devices that have proprietary rendering languages? The print class driver supports that model too, but with the disadvantage that we do need to have a separate rendering filter for each small set of models that speak each unique language. There is no way around this, and in Windows 8 we've taken a number of filters that address a set of popular models. However, once again, we've been working with the printer manufacturers to improve this position, and we expect to see manufacturers produce printers that can more easily utilize the class driver in the future.

Printing from Windows RT

The reduction in the resources used by the print class driver contributes directly to a smaller footprint for Windows, which is especially valuable on Windows RT. In addition, the V3 printer driver architecture was highly extensible and had evolved over many years into a model that encouraged the development of large, complex printer drivers. Some drivers install services that run all the time, exhausting battery power and using processor time. I've seen some drivers that support only one device but that are larger than the complete printer driver set in Windows 8!

The need to support printing in Windows RT, and a general desire to make printing more efficient, led us to develop an architecture that more tightly controls what the driver can do. I’ve already mentioned that the UI portion of the print experience is now a completely separate component, an app instead of being part of the driver. This means that it’s also optional, and drivers will work well with the standard Microsoft printing UI. We’ve also simplified the driver architecture to be more power-efficient, by removing service dependencies and reducing the likelihood that additional software will be included with the driver.

With the Windows 8 driver model, we also made significant changes to how printer drivers are installed. In Windows 7 and earlier versions of Windows, all printer drivers are stored in the “Driver Store,”—sort of like a database for all types of drivers. When you plugged in a printer, we would find the correct driver in the driver store, and copy it to a special location where the spooler could use it with your printer. In Windows 8, we have eliminated this extra copying, which removed quite a bit of disk I/O. The print spooler now just knows how to find the driver in the driver store.

For a real world example, we compared the installation times for an Epson Artisan on Windows 7 versus Windows 8 (using a relatively small driver on Windows 7): the install time on Windows 7 was 14 seconds, compared to under 2 seconds on Windows 8.

Final thoughts

As you can see, the Windows 8 printer driver architecture is big step forward. It provides good support for a lot of the printers that people already own, and supports future devices with a small, fast, built-in class driver framework. The performance is great and the disk footprint is small.

We’re look forward to your feedback!

-- Adrian Lannin

With Windows 8 we set out to enable all applications to have the beautiful and high-performance graphics enabled by modern graphics hardware.  This work builds on the well-established foundations of DirectX graphics, which have been providing an increasing breadth of APIs and capabilities. In Windows 7, we expanded the capabilities of DirectX to provide a common hardware-accelerated graphics platform for a broader range of applications. Whereas previously, DirectX mainly provided 3-D graphics, we added functionality for what we call “mainstream” graphics. Mainstream uses center on the typical desktop applications most people find themselves using every day, including web browsers, email, calendars, and productivity applications.  Windows 7 added two new components to DirectX: Direct2D for two-dimensional graphics (shapes, bitmaps, etc.) and DirectWrite for handling text. Both of these additions not only focused on performance but also on delivering high-quality 2-D rendering. With these additions, DirectX became a hardware-accelerated graphics platform for all types of applications. Indeed, we showed what a typical application could achieve by using DirectX when Internet Explorer 9 brought hardware-accelerated graphics to the web.  WinRT bring these capabilities to the full range of new Windows 8 applications.  In this post, authored by Rob Copeland the group program manager on our Graphics team, we look at the details behind the scenes in enabling this new class of graphical application.  --Steven

In computer graphics, high performance is a guiding principle. In the early days of personal computing, discrete, add-on graphics cards were mostly focused on specialized applications such as CAD/CAM and gaming. Even early on, there was a view that all of this graphics horsepower could be used for more: notably a better user interface and experience. One of the first graphics cards for a PC was called a “Windows Accelerator” from S3 Graphics, which focused on the user experience by moving windows around the screen faster. As graphics hardware evolved, so, too, did the methods that developers use to interact with that hardware.

DirectX is the part of Windows that provides a common application programming interface, or API, that allows developers to use the graphics hardware in the PC to draw text, shapes, and three-dimensional scenes, and display them on the screen. DirectX has also evolved over time in both capabilities and performance characteristics. In the early years, DirectX was focused mainly on games. As applications evolved to provide richer and more graphically-intense user experiences, many of them started to use DirectX as a way to get better performance and richer visuals.

Enter Windows 8

When we started to plan the work we’d undertake for graphics in Windows 8, we knew that we would be creating a new, visually rich way for users to interact with apps and with Windows itself. We also knew that we’d be building a new platform for creating Metro style apps, and that we’d be targeting a more diverse set of hardware than ever before. While we had a great graphics platform to start with, there was more work to do in order to support those efforts. We came up with four main goals:

1. Ensure that all Metro style experiences are rendered smoothly and quickly.
2. Provide a hardware-accelerated platform for all Metro style apps.
3. Add new capabilities to DirectX to enable stunning visual experiences.
4. Support the widest diversity of graphics hardware ever.

While each of these focus on different aspects of building Windows 8, they all depend on great performance and capabilities from the graphics platform.

Planning for performance

Graphics performance on Windows depends on both the operating system and the hardware system, comprised of the CPU, the GPU (graphics processing unit), and the associated display driver. To ensure that we could deliver a great experience for new Metro style apps, we needed to make sure that both the software platform and the hardware system would deliver great performance.

In the past we’ve used many different benchmarks and apps to measure the performance of DirectX. These have been largely focused on 3D games. While games are still very important, we knew that many of these existing ways to measure graphics performance did not tell us everything we needed to know for graphics-intensive, 2D, mainstream apps.

So we created new scenario-focused tests and metrics to track our progress. The metrics we use are as follows:

1.  Frame rate

We express frame rate in frames per second (FPS). This metric is widely reported for gaming benchmarks, and is equally important for video content and other apps. When something is animating on the screen, a rate of 60 FPS makes the animation appear smooth. We target that rate because most computer screens refresh at 60 hertz. With that frame rate, Windows can provide very smooth animations with “stick to your finger” touch interactions.

2.  Glitch count

While frame rate is an important metric, it doesn't tell the whole story. For example, running a benchmark for 10 minutes and getting 60 FPS on average sounds perfect. But, it doesn’t tell us how low the frame rate might have dropped during the test. For example, if the frame rate dips down to 10 FPS momentarily during demanding parts, the animations will stutter. The glitch count metric looks for the total number of times that rendering took more than 1/60 of a second, thus resulting in a reduced frame rate. It also looks at the number of concurrent frames missed. The goal here is to have no missed frames during animations.

3.   Time to first frame

Most people expect their apps to launch quickly, so initializing DirectX needs to be fast. “Time to first frame” tells us how much time it takes from the moment you tap or click to launch an app until you see the first frame of the app on the screen. To measure this, we created simple apps to help analyze and optimize the graphics system for the time it takes to initialize a graphics device, allocate the required memory, and so on. This helps us ensure that the work to set up DirectX takes very little time.

4.  Memory utilization

The more memory our graphics components use, the less memory is available for apps. By ensuring that most of the system’s memory is available for apps, you get the best app performance, and more apps can run at the same time. Apps use a mix of system memory and GPU memory. GPU memory is mostly used for rendering operations such as drawing images, geometric shapes, and text. Additionally there are graphics operations that use the CPU and therefore use system memory.

In order to characterize memory utilization, we measure the memory used by the system for the following scenarios:

• The app is idle. That is, it is not doing any work and is not rendering or displaying new information to the screen.
• The app is displaying information to the screen. This represents the base memory cost of a simple drawing.
• Texture creation. This represents the memory used for creating a large number of image objects on the GPU.
• Vertex buffer creation. This represents the memory overhead of creating geometric shapes.
• GPU data upload. This measures memory overhead involved in uploading data to the GPU.

Measuring memory usage across many types of apps and these various scenarios has helped us further optimize DirectX and the display drivers.

5.  CPU utilization

Most graphics operations utilize the CPU in addition to the GPU. For example, when an app is figuring out what it’s going to draw, it typically does these calculations on the CPU. CPU utilization is important to understand because the higher the percentage of the CPU used by a task, the fewer cycles the CPU can devote to other tasks. For good graphics performance and overall system responsiveness, it is important to effectively balance work between the CPU and the GPU.

These benchmarks and metrics help us ensure that the experiences and apps are smooth and have great performance. They play a big role in our understanding of mainstream apps. Of course, we still utilize industry benchmarks, games, and other ways to measure our overall performance.

Hardware accelerating mainstream graphics

There are many ways to look at mainstream graphics. To ensure that our work would give users the right performance and the right experiences we studied many examples of both Metro style and desktop apps to understand how they used the graphics hardware. In particular, Internet Explorer 9, Windows Live Mail, and Windows Live Messenger make excellent use of DirectX. Because these apps have done great work utilizing DirectX, they're good examples of what other apps might do. This led to a number of investments to ensure mainstream apps were fast and looked great.

Improving text performance

Text is by far the most frequently used graphical element in Windows, so improving text rendering performance goes a long way towards creating a better experience. Web pages, email programs, instant messaging, and other reading apps all benefit from high-quality and high-performance text display.

The Metro style design language is typographically rich and a number of Metro style experiences are focused on providing an excellent reading experience. DirectWrite enables great typographic quality, super-fast processing of font data for rendering, and provides industry-leading global text support. We’ve continued to improve text performance in Windows 8 by optimizing our default text rendering in Metro style apps to deliver better performance and efficiency, while maintaining typographic quality and global text support.

The bar chart below illustrates the performance improvements that result from this work. It includes measurements for the following text scenarios:

• Rendering a screen full of reading-size text formatted as paragraphs as you would find in a web page or Word document
• Rendering a screen full of small chunks of text at reading sizes as you would find in user interface controls such as button labels or menus
• Rendering a screen full of small chunks of heading-sized text as you would see in titles & headings in Metro style apps and as headlines on blog posts and news articles on the web.

The most noticeable performance improvement can be seen when scrolling through a long document on a touch screen. The reduction in time required to render the characters frees up CPU cycles to handle other tasks like processing high-frequency touch input, or displaying more complex document layouts.

Improving geometry rendering performance

Along with text, we also made dramatic performance improvements for 2D geometry rendering. Geometry rendering is the core graphics technology that is used to create things like tables, charts, graphs, diagrams, and user interface elements, as shown in the example below. For Windows 8, our improvements in this area have primarily focused on delivering high-performance implementations of HTML5 Canvas and SVG technologies for use in Metro style apps, and webpages viewed with Internet Explorer 10.

The Weather app in Windows 8 uses geometry to display a graph of historical temperature and precipitation data

When Direct2D draws geometry, it takes instructions from the app about what to draw in the form of 2D figures (e.g. rectangles, ellipses, and paths), the size and location of the figures, and specifics about the style of rendering, including brush color and stroke style. Then it converts those instructions into a set of triangles and commands that it sends to Direct3D to generate the desired output. We call this conversion process tessellation.

To improve geometry rendering performance in Windows 8, we focused on reducing the CPU cost associated with tessellation in two ways.

First, we optimized our implementation of tessellation when rendering simple geometries like rectangles, lines, rounded rectangles, and ellipses. Below is a chart showing the impact of these improvements.

Second, to improve performance when rendering irregular geometry (e.g. geographical borders on a map), we use a new graphics hardware feature called Target Independent Rasterization, or TIR.

TIR enables Direct2D to spend fewer CPU cycles on tessellation, so it can give drawing instructions to the GPU more quickly and efficiently, without sacrificing visual quality. TIR is available in new GPU hardware designed for Windows 8 that supports DirectX 11.1.

Below is a chart showing the performance improvement for rendering anti-aliased geometry from a variety of SVG files on a DirectX 11.1 GPU supporting TIR:

We worked closely with our graphics hardware partners to design TIR. Dramatic improvements were made possible because of that partnership. DirectX 11.1 hardware is already on the market today and we’re working with our partners to make sure more TIR-capable products will be broadly available.

Rendering images

Images are widely used in a variety of scenarios including displaying user interfaces, webpages, and other app content. Websites commonly use JPEGs for pictures and PNG and GIF files to efficiently store user interface elements such as button graphics.

Working with digital photographs is also a very common activity on Windows. The number of digital photographs that Windows customers view and manipulate on their PCs continues to grow at an incredible rate.

We’ve made several performance improvements for working with images and photographs using the JPEG, GIF, and PNG formats.

For JPEG, improvements include:

• Faster image decoding by expanding SIMD usage on all CPU architectures
• Faster Huffman decoding and encoding

For PNG, improvements include:

• Faster image decoding by expanding SIMD usage on all CPU architectures
• Faster image encoding and decoding by optimizing our zlib implementation

In addition, we’ve improved pixel format conversion as well as image scaling. This results in faster decoding and rendering of images for all apps.

The video below uses a test app to measure the decoding and rendering time for a set of images. Windows 8 takes 40% less time than Windows 7 to render 64images (4.38 seconds vs. 7.28 seconds)

Rendering and displaying

As we evolve DirectX to support more mainstream scenarios, another area we we’ve invested in is optimizing how apps render and display their content. There are some big differences in how a 3D game draws its content and how a mainstream app such as Internet Explorer draws its content. For example, consider the video of the game below. In games like this, the entire scene changes rapidly. As the “camera” moves around the vehicle, the clouds move across the sky, and smoke billows up from the engine, the app must redraw the entire scene in each frame in order to achieve a life-like and engaging experience.

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

Now consider the webpage below. It has both a text article and a video. While the video plays, the browser must update the portion of the window containing the video but not the text. Additionally, if the user scrolls the page up, then we only need to render the new text at the bottom of the page. The rest of the text has already been rendered and simply needs to be moved.

To improve apps that don’t need to redraw the entire screen for each frame, we optimized how DirectX deals with redrawing just portions of the screen and how it scrolls. This work not only improves app efficiency and performance, but since it reduces redundant drawing and reduces the number of times graphics data needs to be copied in memory, it also reduces power consumption, thus increasing battery life.

Making the entire platform great

All of these changes help Windows render experiences very quickly and smoothly. While we’ve talked mostly about features in DirectX, the great thing is that all of this work contributes to making our entire platform hardware-accelerated by default. Since we built the Metro style platform on top of DirectX, all apps take full advantage of the graphics hardware on the system, regardless of the programming language and framework the developer chooses.

Creating stunning visual experiences with Direct2D and Direct3D

Direct2D Effects

Stylistic effects applied to images are becoming more common in modern user experiences. They can help highlight an area of an app, draw your attention to a specific part of the screen, or just make things look better. As we planned the graphics capabilities for Windows 8, we wanted to make it really easy for developers to apply these types of effects in their apps. We looked at two main areas where image processing would be useful:

• User interface images
  The Metro style experience uses dynamic visuals. We wanted to enable Metro style apps to do image processing in real-time. This can range from 3D transition effects to perspective transforms, blurs, and highlights on user interface elements.
• Photos
  Apps that deal with photographs often want a rich set of image processing features. Effects such as adjusting exposure, brightness, and contrast, applying vibrancy and clarity, working with advanced curves, and applying lens corrections all allow these apps to enhance your digital memories.

To enable these types of experiences, we added “Direct2D Effects,” a new set of APIs that enable high-quality, hardware-accelerated effects to be applied to any image. Direct2D Effects have the following benefits:

• They provide optimal-quality renderings of image effects to suit the needs of wide variety of apps.
• The effects are hardware-accelerated and work on a wide variety of graphics hardware.
• A simple API enables great effects with minimal programming.
• They provide many built-in effects.
• They support large image sizes and up to 32 bits per channel.
• Custom effects can be combined with built-in effects or other custom effects.

Direct2D Effects power some of the new user experiences in Windows 8. For example, when tapping on a tile on the Start screen, the tile uses the 3D perspective transform effect to “tilt” in the right direction. They also power the rest of our platform. For example, SVG filter effects and CSS 3D transforms are implemented using Direct2D Effects.

Direct3D 11.1 as a common foundation

While adding new features like Direct2D Effects is a great way to help developers deliver new experiences, we also looked at ways to make it easier to use existing DirectX features.

Over years of development, we've added various different features to DirectX. Hardware acceleration of video decoding came alongside programmable shaders in Direct3D 9. In Windows 7, we added Direct2D and built it on top of Direct3D 10. At that time, we also created DirectCompute, a new system for high-performance computation on the GPU that became part of Direct3D 11. One result of all these updates is that DirectX has a very comprehensive set of features around graphics and GPU computation, but as a side effect, it has also become increasingly difficult to create an app that uses video, 2D graphics, 3D graphics, text, and DirectCompute together.

In Windows 8, the new Direct3D 11.1 API is the foundation for hardware acceleration of 2D graphics and text, image processing, 3D graphics and computation, and video. The new API makes it much simpler to mix different types of content in a single scene because that single API now manages all of the GPU resources associated with rendering. This also reduces memory usage by eliminating the redundancy involved in creating multiple graphics device-management objects in app code. In addition, Direct3D 11.1 provides a uniform way for apps to access the various capabilities of different graphics hardware. It provides mechanisms for the app to determine what features are available, and then only uses those capabilities. This enables apps to make maximum use of the GPU’s capabilities, whether the GPU was designed for long battery life on a tablet, or high-end gaming on a desktop PC.

Diverse graphics hardware

Historically, the expectations for each successive release of Windows have been that both the graphics platform and the graphics hardware capabilities will become richer and higher in performance. This is still true, as the graphics hardware industry continues to develop faster, more powerful GPUs. But in Windows 7, we started to see an inflection point in these assumptions, as the diversity of the hardware broadened with the introduction of mobile, low-power devices.

With Windows 8, this trend towards diverse hardware types is continuing and accelerating, both with new, high-performance graphics cards, and with an increasingly wide range of low-power mobile devices. The diversity of the hardware for Windows 8 will span a broader range than ever before; from graphics hardware that consumes on the order of 1 watt in always-connected tablets all the way up to high-end systems with multiple graphics cards that use a total of 1,000 watts or more. This broadening diversity brings with it new design considerations.

Our goal remains to provide visually compelling, high-performance experiences. With highly mobile devices, the primary power source is a battery, so we also need to maximize battery life. To meet both the performance and power consumption requirements of these new form factors, many of our graphics hardware partners have employed new GPU architectures.

Low-power systems

One of the graphics architectures commonly used in low-power system designs to achieve performance along with great battery life is called “tile-based rendering.” The general concept of a tile-based rendering approach is to have a very high performance (but small) memory cache that the graphics engine uses for rendering. The GPU then renders the screen in sections (or tiles) by repeatedly processing the same set of commands on each tile, rather than the whole screen at once. The intent is to minimize operations that use memory off-chip, therefore keeping power consumption low and performance high. Repeatedly accessing memory off-chip is expensive both in terms of time and power consumption.

To increase the efficiency of these tile-based architectures, we added a number of flags, hints, and new APIs that can minimize the number of times the tiles are rendered. We have incorporated the use of these into the Metro style app development platform to ensure greater efficiency in apps running on graphics hardware that uses a tile-based rendering architecture.

Another way for graphics hardware to reduce power consumption while still achieving great performance is to perform graphics rendering calculations using fewer bits of precision. This allows the GPU to more efficiently structure its data so that it can process more data simultaneously, thus reducing the power needed. For Windows 8, we added new mechanisms for apps to specify the amount of precision needed in their graphical calculations. For example, when doing custom blending of multiple images where the image data is 8 bits per component, the blending computations could be done with 10 bits of precision rather than the default of 32 bits. The reduced precision doesn’t impact image quality, but does reduce power consumption.

Great performance, smoothly rendered

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

As you can see, we’ve done a lot of work to enable a very fast and smoothly animated user experience in Windows 8. From new ways to measure our progress, to optimizations for mainstream uses of our graphics platform, and new hardware features, we’ve created the best Windows graphics platform yet. And of course, we continue to push the envelope on immersive, three-dimensional gaming, with great performance and new features such as stereoscopic 3D.

From high-end gaming rigs to light-weight, always-connected tablets, Windows 8 supports the broadest range of graphics hardware ever in a single operating system. We hope this post has helped explain some ways in which this work enables a whole new set of rich experiences.

- Rob Copeland

P.S. Thanks to Sriram Subramanian, Dan McLachlan, Kam VedBrat, Steve Lim, and Jianye Lu, for their substantial contributions to this blog post.

Shortly before we released the Windows 8 Consumer Preview in February, we blogged about our work to make Windows 8 more accessible to people with disabilities. This included our work on Narrator to enable customers who are blind to use Windows 8 on touch screens. This work has continued to evolve in the Release Preview, and will also improve as we move toward the final release of Windows 8. This post details some of the work we have done to improve Narrator when using a touch-enabled PC. This post was authored by Doug Kirschner on our Accessibility team.  –Steven

First off, we would like to thank all the people who have given us feedback; there has been a lot of positive reaction—people are excited that Windows 8 touch screens will include basic screen reading support by default. We've gotten a tremendous amount of constructive feedback on things we could do to make Narrator work better on touch screens and easier to use on the web. We’ve listened. Your suggestions, combined with suggestions from usability testing on visually impaired users here at Microsoft, have resulted in some important changes that we think you'll really like.

Listening to the accessibility community

When the Developer Preview build was released, we took the opportunity to reach out and gather feedback on Narrator from as many people who require visual assistance tools as we could. To start with, we worked with the community of folks inside Microsoft (we are fortunate to have a significant and organized community that is engaged in the accessibility of all Microsoft products) to install Windows 8 and send us their impressions, and we held internal accessibility events where people could come and try it out in person. We also held usability studies where we invited people to Microsoft’s campus to experience Narrator on a touch screen and walk through common tasks to see where we could improve. Millions of you downloaded the Developer and Consumer Previews, and many of you tried out Narrator and sent us some great feedback. We followed up with a number of people who contacted us via @BuildWindows8. Lastly, we attended the CSUN conference for Technology and Persons with Disabilities, where we were lucky to have the chance to sit down with people one-on-one as they tried out the Windows 8 Consumer Preview for the first time on touch screens.

There were a couple of key scenarios we wanted to validate. In particular, we wanted to make sure touch users could get up and running using Narrator on a new PC, right out of the box. That includes finding and installing accessible apps from the Store, and accomplishing basic everyday tasks like sending email, reading webpages, and listening to music. The excitement around the work we'd done so far was overwhelming and gratifying, but it was clear that we still had more work to do to make touch Narrator even better.

Thanks to all of your constructive feedback, we identified key areas that we've improved for the Release Preview:

• Responsiveness: We heard that Narrator on touch screens didn’t feel responsive enough.
• Gestures: Some people had difficulty with Narrator gestures, particularly some of the more complicated multi-finger gestures.
• App exploration: Finding particular elements on the screen (e.g. finding tiles on the Start screen) could be hard for people not already familiar with the particular app or UI.
• Web navigation: The commands available in the Consumer Preview were not extensive enough for some webpages.

We worked heavily on each of these areas for the Release Preview, and we're still working in some areas for the final release of Windows 8. We wanted to share with you some of the improvements you can already experience in the Release Preview today.

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

Making Narrator feel more responsive to touch

Some people we heard from felt that Narrator touch was not very responsive. We heard various versions of this feedback–that Narrator was slow, that Narrator sometimes didn’t respond, or that people just felt disconnected or disoriented—but the root cause of the issue was the same. When you touch the screen, you expect a timely response. We found two common scenarios where this problem occurred:

• Single-finger exploration: When people had to find an item on the screen by dragging a finger around, we observed that they would often skip right over the item they were searching for, as they moved their fingers too quickly, generally before Narrator had a chance to start reading the item.
• Gesture response: Some people were confused as to whether their gesture had succeeded, and would attempt to repeat the gesture several times, even though the first attempt was already successful. The problem was that there was a delay between the time Narrator recognized the gesture, and when it provided the speech response. Sometimes it was also unclear from the response whether Narrator had done what the user wanted, or was just reading something similar but unrelated.

In each case, the blue, visual highlight rectangle that moves to whatever Narrator is currently reading was quick to jump to the appropriate item, indicating that Narrator had registered the user’s movement and was responding appropriately. However, the problem was in the actual speech process. The text-to-speech (TTS) synthesis is fast, but even at high speeds, it takes a while for the system to read the response back; moreover it took additional cognitive time to process the language and to understand what they were hearing. To complicate matters, the speech response time varied widely, depending on context, which made it hard for the user to discern whether the intended gesture was the one that Narrator had recognized. Each of these minor delays added up; people would skip over items altogether or repeat successful gestures, thinking that their first attempt was not successful.

Audio cues

For users with full vision, even if an action takes a few more milliseconds to complete, visual feedback such as highlighting a button or animating a flyout help indicate immediately that the system is responding. These cues are not only aesthetically pleasing, but also functionally important to understand how your touches are influencing the system in real-time.

As we dug into some of the feedback around responsiveness, we realized that Narrator could make more effective use of audio cues. In the Release Preview, we have started to add audible cues; each gesture now has an associated sound that plays when the gesture is performed. These cues were designed to be quick, short and easily distinguishable, allowing you to instantly recognize whether your gesture is successful and if your action has been taken. Here are some examples:

• Moving to the next item plays a “tick.”
• Activating plays a “click.”
• Scrolling plays a sliding sound.
• Selecting plays a “thud.”
• Narrator errors play a “bloop” sound that is easily distinguishable from the system error "ding."
• Explore the screen with a single finger, and Narrator makes a tick with each new item that you touch, so you know if you passed over an item too quickly to hear what it was.

We had a lot of fun designing and implementing these sounds!

Making interactions easier

The next step was to tune Narrator's touch interaction model. Some people told us they found it difficult to use multi-finger gestures. In particular, we saw people struggle with the two-finger swipe for next and previous item, and even more so with the four-finger swipe to scroll. We also observed people accidentally triggering the commands lists (available item commands, search window, etc.), which consequently caused them to lose their context in an app.

In response, we've made it easier to interact with touch Narrator. The system is now more forgiving, with a simpler gesture model that is easier to remember. Single-finger taps and flicks now carry out a majority of the common tasks in Narrator. The revised interaction model is easier to perform, and it groups gestures more logically, so that command lists and windows don’t pop up when you’re trying to perform an unrelated gesture.

The table below outlines the new interaction model:

Improving Narrator’s exploration model

As we collected feedback from people who were using the Developer Preview, we reviewed the exploration model in Narrator. One of the things we heard clearly was that people wanted an easy way to find all of the controls on the screen like buttons, labels, text fields, list items, etc. without having to manually touch around the whole screen. One user who was blind gave the analogy that when he enters a hotel room, his first task is always to walk around the room and locate the door, dresser, beds, and bathroom in order to understand the layout of the room before doing anything else. Similarly, when exploring a new app, users want to know what's on the screen before deciding what to do next.

One of the ways we made all elements on the screen accessible in Developer Preview was to use horizontal swipe gestures to move between items in a container, and vertical swipe gestures to move into and out of containers. This was a powerful model —you could find all accessible items on the screen—and it was a true representation of how graphical UI is constructed. However, it wasn't intuitive. Having to navigate into and out of containers made it difficult to discover all of the interesting elements on the screen.

Changing our default cursor mode

In response to the feedback, we made some changes to the way navigation works by default in Release Preview. The navigation gestures, which are now all single-finger flicks left and right, move you through all of the items on the screen. You no longer need to know how the UI is constructed in order to navigate it; all you need to do is flick to get to the next and previous items, and Narrator presents you with a linear ordering of the important items on the screen.

This allows you to learn about all of the interesting items in an app in an easy step-by-step manner, and interact with any item as you go. If you just want to hear all of the items in an app without flicking each time, you can swipe up with three fingers and Narrator will read through all of them in order, without stopping.

(Note: This is the new default mode of navigation, which allows you to explore apps by flicking left and right to find all of the interesting items. If you prefer the old way of moving through the multiple layers of UI manually, you can change the Narrator cursor movement mode to “Advanced” in the Narrator settings).

Improving web navigation

In Windows 8, Narrator has made reading the web much easier. It has various features that are optimized for web reading, such as the “start reading” command, which reads out continuous sections of webpages without stopping, and search mode, which provides a list of various types of controls on a page. After we released the Developer and Consumer Preview builds, we heard from users that although these features were helpful, they did not enable them to accomplish some common tasks on the web, such as quickly scanning news headlines, doing a quick search, or checking stock quotes.

So we revisited this feature, and as we dug further and gained a better understanding of these scenarios, we found ways to improve them in the Release Preview. For news reading in particular, we heard people saying they wanted to jump to various points in the page (e.g. headings, links), and then subsequently to be able to read line-by-line and even letter-by-letter. Many users wanted Narrator to provide these commands for them to navigate the web with more precision.

In response, we added the concept of views to Narrator’s navigation commands. The new views are available in default navigation mode whenever you are on a webpage or other accessible text area, such as in the Mail app. The default Item view moves through the items on the page, and works the same way as item navigation throughout the system. But for accessible text areas such as webpages or Mail, Narrator now supports seven additional views:

• Headings
• Links
• Tables
• Paragraphs
• Lines
• Words
• Characters

You can easily change the view by flicking up or down, and then flick left or right to move through the items in that view. These commands are also available with a keyboard by using Caps Lock + Arrow keys.

With the new views, web reading is more powerful in the Release Preview. The views work with other Narrator reading commands as well. For example, if you find an interesting news headline and want to hear more, you can swipe down with three fingers and Narrator will start reading all of the page content until you tell it to stop.

Finishing the job

These examples represent some of the major work we’ve done in response to feedback from people who tried Narrator touch in the Developer Preview and Consumer Preview. We’ve made many more improvements based on your feedback—including reading out touch hints that teach you how to activate items, improving the Narrator settings UI to be easier to use with touch, and adding a new setting that makes it easier to type on the touch keyboard. While we believe Narrator is feature complete at this point, we’re still fixing bugs and fine-tuning it before Windows 8 is complete.

It’s been fantastic and humbling to hear from so many of you who have had the chance to try out Narrator. We’ve thoroughly enjoyed working one-on-one with users through our usability studies, at the CSUN conference, and within the Microsoft community. Thanks to all of the great constructive feedback we’ve received, we’ve made these important changes to Narrator for the Release Preview to make it a much better feature.

While we work towards shipping this product soon, we’d love for you to download and install the Release Preview for yourself, and try out Narrator.

Note: The touch features described in this blog require touch screens supporting at least four contact points. Windows 8 certified touch hardware will universally meet this requirement, but some current Windows 7 hardware may not (see this post for more info). If you do not have a touch screen supporting four contact points, you can still run Narrator using the keyboard.

Thanks!

-Doug Kirschner

Starting with the earliest TabletPC enhancements to Windows, we have been working on “on-screen keyboards.” With Windows 8, we started fresh and took a "first principles" approach to developing the touch keyboard. Given the amount of experience many of us have with touch keyboards for phones, and the myriad of touch devices we interact with these days, we set a very high bar for the quality of the experience and effectiveness of input with the new Windows 8 touch keyboard. In this post, Kip Knox, a member of the Windows User Experience program management team, details this work. --Steven

When we began planning how touch and new types of PCs might work on Windows 8, we recognized the need to provide an effective method for text entry on tablets and other touch screen PCs. Since Windows XP SP1, which had Tablet PC features built in, Windows has included a touchable on-screen keyboard. But those features were designed as extensions to the desktop experience. For Windows 8, we set out to improve on that model and introduce text input support that meets people’s needs, matches our design principles, and works well with the form factors we see today and expect to see in the future.

I’m writing this blog post on our Windows 8 touch keyboard using the standard QWERTY layout in English. As I look at it, the keyboard seems very simple and sort of obvious. This comes partly from having worked on it for a while, but also because keyboards are familiar to us. But there is more here than meets the eye (or, fingertips).

We started planning this feature area with no preconceived notions. As we do with all our features, we began the text input design project with a set of principles or goals. On a Windows 8 PC using touch, we want people to be able to:

• Enter text quickly, reasonably close to the speed with which they type on a physical keyboard
• Avoid errors, and be able to easily correct mistakes
• Enter text comfortably, in terms of posture, interaction with the device, and social setting

You might note that none of those goals explicitly assumes a keyboard. And when we started the project, we cast a broad net across possible approaches to text input. We found that of all the methods of text input we considered, none met the goals above as well as a keyboard. The majority of people are simply faster, more accurate, and more comfortable typing than they are writing any other way. Windows has highly accurate handwriting recognition in several languages, as well as advanced speech recognition, for example. But without a great touch keyboard, we were not going to be able to fulfill people’s needs and expectations for touch-screen devices running Windows. So we set out to create the best touch keyboard on any device.

Optimizing for comfort and posture

There are many ways to imagine touch keyboards on a tablet, and we sketched a lot of them—large keyboards, tiny keyboards, floating keyboards, circular keyboards, swipe keyboards. But our initial design process was grounded in research we did into the ways that people interact with tablets. Our researchers conducted an in-depth study in which they observed people “living with” tablets over a period of time. Through these observations and interviews, we saw a set of three postures that are most common among people using tablets:

1. One hand holding the device, with one hand interacting with the user interface
2. Two hands holding the device, with thumbs interacting
3. Resting the device on table, lap, or stand, and interacting with both hands

Research into people “living with” tablets revealed three common postures.

In these postures, people felt most natural and most likely to use the tablet for longer periods of time. We’ve made many design decisions in Windows 8 to optimize for these postures, and that includes how people intuitively input text. When typing on a tablet, most people either set it on their lap or a table and multi-finger type, or hold it in their hands and type with their thumbs, or hold it with one hand and “hunt and peck.”

Our standard touch keyboard layout is optimized for laying the tablet down and multi-finger typing, and also works well for typing with one hand. We also introduced a new layout we call the thumb keyboard (which we showed for the first time at our very first preview of Windows 8 about a year ago), which is designed for holding the tablet with two hands and typing with your thumbs. This keyboard is adjustable in size, to accommodate different hand sizes. An interesting observation from our posture research is that people frequently switch postures, and that posture switch is often seen as a positive thing, as we move about to remain comfortable. So in our keyboard layouts we also considered what it would be like to type for a period of time—say, an email to your mom—and switch postures while you do it. You might start by typing with the tablet lying on the coffee table, for example, but then you might tire of that posture and pick up the tablet, lie back on the couch, and interact with two thumbs.

Further research into posture and comfort helped us to understand how people hold tablets, and how far our thumbs typically reach. In a follow-up study, we had a wide selection of people with different hand sizes use a tablet with sensors that would indicate where their thumbs could reach most comfortably, where they could extend to, and where reach was just uncomfortable. These results helped us optimize the use of the system with thumbs, and helped shape the thumb keyboard layout.

This heat map illustrates the typical reach of people’s thumbs, overlaid on the thumb keyboard layout. Green is very comfortable, yellow can be reached, and red is typically uncomfortable.

Typing on glass

The next challenge we considered was the experience of typing on the glass display of a tablet. At least one of the key postures—laying the tablet down—is analogous to typing on a physical keyboard. So unlike typing text on a phone, we were faced with direct comparisons with the physical keyboard experience. When you type on your laptop or desktop, you enjoy some real benefits. You get a lot of sensory feedback as you type. First, you can position your hands quickly on your home keys, and most keyboards have small bumps on the J and F keys (in English QWERTY keyboards) to confirm that position. Then, as you type, the shape of the keys reinforces where your fingers are as they move about. The keys have “travel,” or small up-and-down movement, which confirms that you struck them. And because the keyboard is mechanical, there is a tapping sound that confirms your key strikes (perhaps to your chagrin, if your colleagues are checking email during meetings J).

If you lay down a piece of glass and type on it, you get no feedback; there is no indication for where to position your hands, and there is no indication of whether you’ve hit a target or not. Recognizing this, we made a few decisions. We needed to provide some type of feedback, and we needed to recognize that people will be more “sloppy” when typing on a touch keyboard. But we also observed that a touch keyboard can do things that a physical keyboard can’t, and we should bring those functions out.

The feedback you see in the touch keyboard comes in two forms—the keys change color when you touch them, and they trigger a subtle sound. This is similar to what you see on most phone touch keyboards. We considered other forms of feedback, but ruled them out as too disruptive or unnatural. For example, we explored haptic feedback (a vibration of the device based on input) which you also find on many phones. But most people find the current state-of-the-art haptics somewhat irritating when typing pieces of any length and a buzz can feel as much like a punishment as a reassurance.

Our two forms of feedback—visual key changes and sounds—are not without controversy either. Visual key changes are not always ideal when you are entering a password, for example, and for that reason we enable you to suppress feedback in these cases. Some people have argued that key press sounds are irritating and artificial. But user testing confirmed our assumption that people clearly find the sounds reassuring and confidence-inspiring when typing on glass. The specific sounds we use (which are very similar to those on the Windows Phone) are designed to be “residual,” where you quickly forget that they are there, but would notice if they were turned off.

Both forms of feedback may be used more when people are first getting used to the experience. We have done eye-tracking studies in the lab, which showed that as people become more proficient with the touch keyboard, they spend more time looking at the input field, and less time looking at the keyboard itself. So the appearance of each character becomes the best feedback when you are typing efficiently. I’ll tell you a little more about these eye-tracking studies later in this post.

As people spend time with the touch keyboard, their focus moves more consistently to the input field, as this heat map from an eye-tracking study shows.

But even when you “get good” at typing on a touch keyboard on glass, you will still be sloppier and slower than you would be with a physical keyboard. The Windows 8 touch keyboard has some special accommodations to address this reality. The most interesting one is what we call the “touch model.”

When you tap a key on the touch keyboard, we detect the coordinates of your touch, and we can map it to the geometry of the keys. But as your fingers move about across the glass, your press is likely to migrate outside the boundaries of the key you intended to touch. If we relied simply on the geometry mapping of the keys, you would see a lot of errors. To account for this, the key press is first compared against a model that assesses the likelihood that you intended to strike that key or a key near it. This processing is informed by two things. First, we use data from many people’s typing pangrams, or phrases that use every letter of the alphabet, recording trends where peoples bias their touch away from the intended target. For example, they might intend to type a p, but often strike the o, because most people’s fingers curve inward. Based on a set of characteristics, including typing speed, the model weights the likelihood that you intended to type one key over another. Secondly, we use lexical data representing letters and words that are likely to be strung together in writing. This is the same system that enables spelling correction—the system “knows” what you probably intended to type even if you made a mistake.

Based on the touch model, the keyboard is often able to quietly correct cases where you intended to type a p for example, but inadvertently struck the o, on a QWERTY layout. Or consider the example where you are typing the word “the.” If you type t then h and then touch between the e and w but slightly more on the w, the touch model adjudicates this, knows that t-h-e is the common character combination in English rather than t-h-w, and appropriately outputs the e. But if you touch the w fully, the keyboard respects that input and assumes you know best. This all happens while you are typing, so the right character goes into the input field and doesn’t require further correction. When this works best, you don’t realize it’s even happening, increasing your confidence in typing on glass.

This map from a report on touch model data illustrates biases that people show toward certain keys when typing on a touch keyboard.

Great for typing

Once we accounted for feedback and provided “guard rails” for inevitable mistakes, we still had to determine the specific keyboard layouts—what keys go where. Key positions have a big influence over typing speed and accuracy, and people have very strong—and often conflicting—opinions about keys. But the design problem broke down logically, based on our observations of interaction and some physical realities. For example, we confirmed our assumptions that:

1. Most people have developed very strong habits based on the conventions of physical keyboards. When you break these conventions, it slows their typing down appreciably. This even applies to very young folks or dedicated T9 typists, for example, as most of us learn to touch-type in some form at a young age.
2. There are optimal targetable sizes of keys. The extensive research Microsoft has done into physical keyboards applied here too. For example, the letter keys on our touch keyboard are 19mm wide, the same as on most physical keyboards, because people showed faster typing speeds with targets of that size (rather than smaller or larger).
3. The more keys you include, the more likely people are to make mistakes. This is partly because more keys mean the keys need to be smaller and there’s a greater likelihood of hitting a key you didn’t intend. More keys also create visual clutter and distraction and slow your ability to scan and find a key.
4. You don’t want to obscure more than half the display with a keyboard. A too-large keyboard creates a claustrophobic experience and you lose context. However, there is a counter rule that says obscuring about half the display works fine. This is because entering text is most often a “modal” activity, where your focus is very much on typing something and not on the periphery. Your area of focus outside the keyboard is relatively small, and directed toward the characters you’re typing. Our eye-tracking studies, illustrated in this post, demonstrate this.
5. People use some keys more than others. We deduce this from analyzing passages of text written in real-world circumstances. There are clear patterns of frequency in the use of letters and symbols.
6. People will learn to do new things—and learn quickly—if they don’t interfere with habits.

So in the end, the layout of a touch keyboard in any language becomes a balancing act of the different factors. You want to reduce the number of keys in the default layout, for example, but if you remove a key people rely on in typing every day, you will frustrate them. The layout needs to be big enough to support accuracy, but not so big it obscures the application.

There was one more overall rule or principle that we applied to the keyboard layouts specifically: They must be great for typing. That seems obvious but it’s clarifying when you recognize that keyboards are used for a lot of things other than writing words—shortcuts to UI, for example, or sending commands, or entering codes. Our keyboard is optimized for typing, because that is its primary purpose and it must do it well above all other things. Let’s take a look at a few of the decisions we made that fit within these parameters.

Numbers

We get a lot of questions about why we don’t include a number row in the default keyboard layout. We use numbers frequently in our jobs, and we’re used to finding number keys on the top of our physical keyboard. The Windows 7 on-screen keyboard has a number row, for example. This is consistent with the overall design of that keyboard—it is essentially a software emulation of a physical keyboard. It has not been optimized for a world of touch.

The Windows 7 on-screen keyboard emulates a physical keyboard and isn’t optimized for touch or typing.

Some of our early designs and prototypes had a number row too. But when we brought these designs in front of people, the feedback was strong that the keyboard felt “cramped” compared to what they were used to. We observed frequent errors and accidental invocation of keys, especially around the perimeter of the layout. This resulted in a number of changes, and it confirmed the decision to not include a number row. Here’s why: Including a number row meant adding a fourth row of character keys. When we optimize for keys with a targetable size, that means the keyboard must be that much higher. On a typical tablet device (say with a screen size of 10.6 inches) adding a number row would mean that more than half of the display would be covered by the keyboard. When we combined this with the observation that numbers are typed less frequently than most letters and common symbols, and you recognize that the extra keys are causing accidental key presses, we settled on including numbers on the separate number and symbol view.

That settled, we still had debates about whether to display numbers as a row across the top of the numbers and symbols view, or to display it as a numeric pad. We chose the numeric pad for a few reasons:

1. People often enter multiple numbers at once.
2. It’s easier to scan an organized group than a long row.
3. People type number sequences much faster when the numbers are clustered.

We also decided to include the numbers in 1,2,3 order from the top, rather than 7,8,9, as it appears on many extended computer keyboards or cash registers. This is an interesting case where the physical keyboard convention didn’t matter as much, because people have become familiar and very comfortable with the order of number pads on phones, ATMs, remote controls, and other modern devices. 1,2,3 order is simply easier for the eyes to scan and the brain to process than any other order.

The number and symbol view includes a numeric pad that reflects modern layouts we find on phones, ATMs, and remote controls.

Tab key

The tab key has a similar story. It’s a key we use a lot—for formatting documents, but also for things like navigating input fields on a webpage. For that reason, we included it in one of our early touch-optimized layouts, after we had removed a lot of other keys typically found on physical keyboards. It looked like this.

An early layout of the keyboard had extra keys that interfered with accuracy and speed.

You might observe that on the right and the left, there are borders of keys that aren’t letters or symbols. This layout yielded the results described above—people experienced a cramped feeling. And worse than that, they frequently missed character keys and inadvertently touched one of the border keys. When we removed them, people raved about the openness and comfort of the layout, their errors went down, and their speed went up. With the Tab key on the numbers and symbols view, it was harder to reach—but the keyboard was better for typing, and so the Tab key’s peregrinations were over.

Downshift: a mistake to learn from

The last example we’ll share involves a feature we had in the product and have subsequently cut. This is a feature inspired by our desire to make punctuation easier to get to, without a complete view switch. In this design, the left shift key acted as the shift key does today—it enabled capital letters and access to alternate symbols from the default view. We used the right shift key differently—it provided a “peek” into frequently-used symbols or punctuation. The idea was that you would “downshift” briefly to select punctuation, for example, but not lose the context of the main view, and thus be faster. We theorized that this was a place where we could deviate from convention and provide value you could only get with software. Here’s a picture of the “downshift” keyboard.

The downshift design was intended to provide fast way to access symbols, but interfered with expectations for shift behavior.

Suffice to say this prototype did not succeed in the lab. Participants continually struck the right shift key for the usual reasons you’d use a shift key. And when the keyboard showed the “peek” to symbols, they were confused and their typing came to a halt. So this was a case where we had to stick with the convention of a physical keyboard.

There is an interesting counter example in press-and-hold behavior. On a physical keyboard, when you press and hold a character, it repeats. On our touch keyboard when you press and hold, we show alternate characters or symbols. This is something a touch keyboard can do well and a physical keyboard can’t. If you don’t know the specific key combination to show ñ or é or š, for example, it’s painful to type on a physical keyboard. It’s easy to find on the touch keyboard. Practically no one has complained about this departure from convention. We built on it, in fact. You might discover that you can simply swipe from a key in the direction of the secondary key, and that character will be entered, without an explicit selection from the menu. So if you use accented characters a lot, you can get pretty fast with this. Try it out!

When you press and hold a key, it reveals related keys. If you swipe quickly toward the secondary key you want, you can select it quickly.

Testing and validating

We’ve been conducting a series of eye-tracking studies, where cameras record the direction of the participants’ gaze as they are interacting with the system. These studies help us determine a few things: Where do people look when typing on a touch keyboard? Does visual gaze change over time? Are these patterns consistent across different views or layouts? And is visual gaze correlated to speed of typing?

An eye-tracking study participant begins the session.

We’ve found very consistently that people primarily look at the text field where their characters appear, and they look at the keyboard. This is so consistent that we designed our text suggestion experience to optimize for this tendency. Text suggestions (words that are predicted as you type) appear right by the cursor in the text field, and you insert them by touching the “Insert” key on the touch keyboard. This is optimized for where we saw people putting their attention as they typed. It is notably different, for example, from text suggestion UI you see on many phones, where there is a band of possible words that run across the top of the keyboard. On a PC with a full-sized keyboard, people just don’t look there, and they don’t want to stop typing and change their posture to select these words.

Individual fixations, or recordings of a stabilized retina, show that people look either at the keyboard or at the text field. We do not typically look in between the two. Our text prediction UI appears near the caret for this reason.

We also found that our gaze does change over time, and as the gaze changes, we type faster. You can see this very clearly in the gaze plots of the eye-tracking studies. A full range of people show this tendency—from slow typists unfamiliar with tablets to skilled typists who spend a lot of time with tablets. In all cases, at first, there is more attention on the keyboard, and the speed is slower. Over time—say, about 90 minutes over a few days—there is markedly less attention paid to the keyboard, more to the text field, and words per minute go up significantly.

We can see in lab studies that the focus of our gaze changes over time. The left hand image shows a typist after just a few minutes. The right image shows the gaze plots after about 90 minutes. You can see that focus moves to the text field. This typist doubled her speed during the session.

Continued refinement

Lastly, below is a picture of the current English QWERTY layout, which we have in the Windows 8 Release Preview. It is intentionally spare and open, and the keys that remain are there for explicit reasons. Each of these has its own story, but we can call out a few highlights:

• The backspace key is there because it’s used very frequently on physical keyboards and touch keyboards. If we removed it, you would find your finger groping for it repeatedly.
• The mode switch key is essential to moving between views and languages and for hiding the keyboard. IME users will find that this is how you switch to Windows IMEs, which also feature touch-optimized keyboard layouts.
• The CTRL key and the right and left arrow keys are intended for text editing operations. You can move your input cursor and cut, copy, and paste without moving your hands from the keyboard. (Note that the CTRL key works just as it does on a physical keyboard—so any supported combination will work. We include labels for things like cut, copy, paste, and bold, because they are related to text editing. The touch keyboard is not intended for “commanding,” which is why you don’t see things like the Windows key or function keys. That is a deliberate decision to stay focused on the goal of being really great for typing.
• The space bar is centered and wide. Physical keyboard research shows that about 80% of strikes on the space bar occur on the right (if you look at older keyboards, you will notice the wear on that side). This holds for touch keyboards too, where people will miss the spacebar if it’s not ample-sized, and this creates errors that are hard to recover from.
• The “emoji” or emoticon key switches you to emoji view, where we support a full set of Unicode-based emoji characters. The use of emoji continues to grow worldwide, and has become a part of how people write and express themselves.
• We also include an option for a standard keyboard layout, which can be useful on a PC without a keyboard when using desktop software that requires function keys or other extended keys. This is easily enabled from the settings Charm, in the General Settings section of PC Settings.

As you use the keyboard, we hope you also discover some extra features we’ve added to make things easier. For example, if you hold down the &123 key, you can select symbols or numbers with your other hand, and when you release, you return to your original view. The team calls this “multi-touch view peek.”

The current touch-optimized layout reflects decisions about each of the keys based on a series of studies.

These optimizations apply across the input languages we have in Windows, as we support a touch-optimized typing experience worldwide. We expect to make a few more improvements to the typing experience, and we are really grateful and delighted by the feedback we’ve received so far. Thanks!

Kip Knox

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

Backing up your critical files is something we all know we should do. Even with everything in SkyDrive, it is still something we need to do. With Windows 8, we took a new look at the way backup can work and set out to solve the perennial problem of not just restoring all your files but restoring a previous version of a critical file you have been editing through the course of a day. To achieve this, we're introducing a new feature in Windows 8, File History. Bohdan Raciborski, a program manager on the Storage team authored this post. --Steven

Note: Comments have been off topic.  Please maintain community standards and focus on the topic at hand.

What is File History?

File History is a backup application that continuously protects your personal files stored in Libraries, Desktop, Favorites, and Contacts folders. It periodically (by default every hour) scans the file system for changes and copies changed files to another location. Every time any of your personal files has changed, its copy will be stored on a dedicated, external storage device selected by you. Over time, File History builds a complete history of changes made to any personal file.

It’s a feature introduced in Windows 8 that offers a new way to protect files for consumers. It supersedes the existing Windows Backup and Restore features of Windows 7.

What is unique about this approach compared to a more traditional backup and restore?

Regretfully, backup is not a very popular application. Our telemetry shows that less than 5% of consumer PCs use Windows Backup and even adding up all the third party tools in use, it is clear nowhere near half of consumer PCs are backed up. This leaves user’s personal data and digital memories quite vulnerable as any accident can lead to data loss. In Windows 8 Microsoft is actively trying to accomplish the following:

1. Make data protection so easy that any Windows user can turn it on and feel confident that their personal files are protected.
2. Eliminate the complexity of setting up and using backup.
3. Turn backup into an automatic, silent service that does the hard work of protecting user files in the background without any user interaction.
4. Offer a very simple, engaging restore experience that makes finding, previewing and restoring versions of personal files much easier.

While designing File History we used learnings from the past and added requirements to address the changing needs of PC users.

• PC users are more mobile than ever. To address that, we optimized File History to better support laptops that constantly transition through power states or are being connected and disconnected from networks and devices.
• PC users create more data and are more dependent on it than ever before. So we do not only protect what’s currently on the system drive but also any work they have done and data they have created in the past.

When a specific point in time (PiT) version of a file or even an entire folder is needed, you can quickly find it and restore it. The restore application was designed to offer engaging experience optimized for browsing, searching, previewing and restoring files.

Setting it up

Before you start using File History to back up your files, you'll need to set up a drive to save files to. We recommend that you use an external drive or network location to help protect your files against a crash or other PC problem.

File History only saves copies of files that are in your libraries, contacts, favorites, and on your desktop. If you have folders elsewhere that you want backed up, you can add them to one of your existing libraries or create a new library.

To set up File History

1. Open File History control panel applet.
2. Connect an external drive, refresh the page, and then tap or click Turn on.

You can also set up a drive in AutoPlay by connecting the drive to your PC, tapping or clicking the notification that appears…

… and then tapping or clicking Configure this drive for backup.

That’s it. From that moment, every hour, File History will check your libraries, desktop, favorites and contacts for any changes. If it finds changed files, it will automatically copy them to the File History drive.

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

Restoring files

When something bad happens and one or more personal files are lost, the restore application makes it very easy to:

• Browse personal libraries, folders and files in a way very similar to Windows Explorer.
• Search for specific versions using keywords, file names and date ranges.
• Preview versions of a selected file.
• Restore a file or a selection of files with one tap or a click of a mouse.

We designed the restore application for wide screen displays and to offer a unique, engaging and convenient way of finding a specific version of a file by looking at its preview.

With other backup applications you would have to select a backup set that was created on a specific date. Then you would have to browse to find a specific folder, and then find the one file you need. However at this point it is impossible to open the file or preview its content in order to determine if it is the right one. You would have to restore the file. If it is not the right version, you’d have to start over.

With File History, the search starts right in Windows Explorer. You can browse to a specific location and click or tap on the History button in the explorer ribbon in order to see all versions of the selected library, folder or an individual file.

For example, when you select a Pictures library and click or tap on the History button…

… you will see the entire history of this library.

When you click on a specific file, you can see the entire history of the selected picture.

In this example, the selected picture has 4 versions. You can easily navigate to the desired version by clicking on the Previous/Next buttons or by swiping the screen. Once you have found the version you were looking for, you can click the Restore button to bring it back. The selected version will be restored to its original location.

Continuous, reliable protection

File History, instead of using the old backup model, takes a different approach to data protection.

Protect only what is most important

Instead of protecting the entire system (operating system, applications, settings and user files) File History focuses only on user personal files. That’s what is most precious and hardest to recreate in case of an accident.

Optimized for performance

In the past, most backup applications used brute force method of checking for changes in directories or files by scanning the entire volume. This approach could significantly affect the system performance and requires an extended period of time to complete. File History, on the other hand, takes advantage of the NTFS change journal. The NTFS change journal records any changes made to any files stored on an NTFS volume. Instead of scanning the volume, which involves opening and reading directories, File History opens the NTFS change journal and quickly scans it for any changes. Based on this information it creates a list of files that have changed and need to be copied. The process is very quick and efficient.

File History was designed to be easily interrupted and to quickly resume. This way, File History can resume its operation, without the need to start over when a system goes into sleep mode, a user logs off, the system gets too busy and needs more CPU cycles to complete foreground operations, or the network connection is lost or saturated.

File History was designed to work well on any PC including small form factor PCs with limited resources and tablets. It uses system resources in a way to minimize the impact on system performance, battery life and overall experience.

1. File History process runs at low priority, uses low priority IO and low priority memory.

Figure 1: File History reaction to an increasing workload.

Figure 2: File History disk utilization in presence of other processes with normal priority I/Os.

1. When File History service is idle, it uses an average of 10 MB of working set. When it runs, it uses little memory and only for a short period of time. The chart below shows the working set histogram collected using a simulated workload over a period of 4 hours with File History cycle frequency set to one hour.

Figure 3 Working set size per backup cycle, sampling every 3 min.

1. The amount of data being backed up in one cycle is throttled.
2. Any activity is suspended when the machine is sleeping.

File History takes into account:

• If the user is present, i.e. logged on and actively using the system.
• If the machine is on AC or battery power.
• When the last backup cycle was completed.
• How many changes have been made since the last cycle.
• Activity of foreground processes.

Based on all of these factors, which are re-checked every 10 seconds, it determines the optimal way to back up your data. If any of those conditions change, the service makes a decision to reduce/increase quota or suspend/terminate the backup cycle.

Optimized for mobile users

When File History is running, it gracefully handles state transitions. For example, when you close the lid of your laptop, disconnect an external drive or leave home and take your laptop out of the range of the home wireless network, File History takes the right action:

• Lid closed - When a PC goes into sleep mode, File History detects the power mode transition and suspends its operation.
• Lid opened – File History resumes its operation at a priority that makes sure files are protected without impacting overall system performance, even for gamers. It also waits for all post “lid open” activities to complete so that we do not affect the system while it is coming back out of sleep.
• Dedicated storage device disconnected – File History detects that the storage device is not present and starts caching versions of changed files on a system drive.
• Dedicated storage device re-connected – in the next cycle, File History detects that the storage device was reconnected, flushes all versions from the local cache to the external drive and resumes normal operation.

Simplicity and peace of mind

We designed File History with two objectives in mind; 1) offer best possible protection of user personal files and 2) offer ease, simplicity and peace of mind.

If you want to take advantage of File History, you have to make only few, simple decisions. In most cases it will be limited to only one – which external drive to use. The rest is taken care of by Windows. The operation of File History is transparent and doesn’t affect the user experience, reliability or performance of Windows in any way.

Full control

Most backup applications, including the Windows Backup and Restore that shipped in Windows 7 require administrator privileges to set up and use. This means that standard users have to ask the administrator to set it up and every time they need to restore a file, or to grant them administrative privileges. Not so with File History. File History offers full control to each individual user. Now users can decide if and when to turn File History on and which external drive to use. In fact, each user can select a different location to store their file history. And they do not have to ask for the administrator’s help to restore a file.

Enthusiasts and experienced PC users can use advanced File History features to control many aspects of its operation, like:

• How often you want to save copies of your files: The frequency of backups can be changed from 10 minutes to 24 hours. Higher frequency offers better protection but consumes more disk space.

• How long you want to keep saved versions: Versions can be stored forever or as little as one month. This setting is useful when the File History drive fills up to fast. You can slow down this rate by reducing the time versions are stored.

• Changing the size of the local cache: File History uses a small amount of space on the local drive to store versions of files while the File History target drive is not available. If you create a lot of versions of files while disconnected or stay disconnected for longer periods of time, you may need to reserve more space on the local drive to keep all versions. Note that the versions stored in the local cache are flushed to the external drive when it becomes available again.

• Excluding folders that you do not want to back up: Some folders may contain very large files that do not have to be protected because they can be easily recreated (like downloaded high definition movies or podcasts). These files would quickly consume all of the File History drive capacity. This setting allows you to exclude such folders.

• Recommend a drive to other HomeGroup members on your home network: This setting is covered in more detail in the File History and HomeGroup section below.

• Accessing the File History event log: The event log contains records of events that may be useful while troubleshooting File History. It may be particularly useful if you want to identify files that File History could not access for any reason.

Advanced settings can be accessed from the File History control panel applet.

To exclude a folder, select Exclude folders. Next, click on the Add button, browse to the folder you want to exclude and select it. Files in this folder will not be backed up starting with the next backup cycle. To start backing it up again, simply remove the folder from the list.

Other advanced settings are available on the Advanced Settings page.

File History also supports new storage features introduced in Windows 8. Users who have lots of data to back up can use Storage Spaces to create a resilient storage pool using off-the-shelf USB drives. When the pool fills up, they can easily add more drives and extra storage capacity to the pool. You can find more about Storage Spaces in this blog post.

Users who use BitLocker to protect the content of their personal files can also use File History as it seamlessly supports BitLocker on both source and destination drives.

File History was designed for consumers but could also be used by enterprise customers. In some cases, File History may conflict with the enterprise policies (like retention policy). To prevent such conflicts, we added a group policy that gives enterprise IT administrators the ability to turn off File History on managed client PCs.

You will find the File History policy setting in the Group Policy Object Editor under Computer Configuration, Administrative Templates, Windows Components, File History.

Minimal setup

File History is part of Windows so you don’t need to install any additional software. However, File History has to be turned on, which typically requires only one click.

As described above, to start protecting your libraries, you need to attach an external drive or select a network location. File History will store versions of your files on this device.

File History automatically selects an external drive if one is available. If more than one drive is available, one with the most free storage capacity is selected.

No schedule

File History wakes up once an hour and looks for personal files that have changed. Versions of all files that have changed are replicated to a dedicated storage device. This approach eliminates the need to set up a schedule and leave a computer idle for an extended period of time. One hour frequency offers a good balance between the level of protection and amount of storage space consumed by file versions. Enthusiasts can change the frequency from 10 min to 1 day in order to increase the level of protection or reduce storage consumption.

No maintenance

File History runs silently in the background and doesn’t require any ongoing maintenance. The only time when it will ask you to intervene is when the external drive is full. At this point you will be asked to either replace the drive with a bigger one or change a setting that tells File History how long to keep file versions around. By default, we keep versions of user personal files forever, but if storage is an issue, it can be reduced to a period of time that best suits your needs.

File History and HomeGroup

File History was also integrated with HomeGroup to make it easier for someone to set up backup for all members of a home network. Here is how it works.

1. Jane wants her entire family to have their personal data automatically protected. She knows she can do this with File History. 
2. Jane creates a HomeGroup on the family’s home network.
3. Jane turns on File History on a computer that has a large external drive.
4. File History control panel detects the HomeGroup and asks if Jane wants to recommend this backup destination to other HomeGroup members.
5. Jane selects this option and File History uses HomeGroup to broadcast the recommendation to all HomeGroup members.
6. Each HomeGroup member can now accept the recommendation. If they do, their libraries, desktop, favorites and contacts are automatically backed up to a network share on Jane’s computer.

File History and SkyDrive

File History doesn’t back up your files to the cloud. While the cloud is great for storing files you’d like to access on-the-go, or for sharing files with others, backing up terabytes of data to the cloud requires a specialized service. Many cloud services today support local synchronization, where the data in the cloud is mirrored in your local file system. Sync solutions by their very nature copy changes immediately to all locations, which means accidental deletes or inadvertent changes or corruption to files will be synchronized as well. The best way to address this problem is to couple your sync service with a point-in-time backup solution like File History.

In the blog post, Connecting your apps, files, PCs and devices to the cloud with SkyDrive and Windows 8 we discussed how SkyDrive will integrate with Windows Explorer and the file system. File History takes advantage of that integration. If your SkyDrive is synced to your file system, File History will automatically start protecting the files stored in your local SkyDrive folder. This is a great example of local backup plus reliable anytime, anywhere access. You can access your files in SkyDrive through your PC, your phone, or the web and you’ll also know that File History is providing fast local backup and instantaneous access to all versions of those files.

Full system backup

Usually a full system backup is used to protect your PC against complete system loss, for example when a PC was stolen or lost or the internal hard drive stopped working. Our research showed that only a small number of users are concerned about losing the operating system, applications or settings. They are by far more concerned about losing their personal files. For these reasons, File History was designed specifically to protect user personal files.

File History doesn’t offer the ability to do a full system backup but for those users who may need a full system backup it offers a good compromise. Together with other features introduced in Windows 8 it provides protection against such disasters.

If you want to prepare for a disaster, we recommend a following strategy:

1. Create a recovery drive to be used when you need to refresh or restore your PC. You can find more about it in this blog post.
2. Connect to your Microsoft account
3. Configure your PC to sync your settings
4. Load apps from the Store
5. Turn on File History

When your PC is replaced or needs to be reinstalled:

1. Use the recovery drive to restore the operating system
2. Connect to your Microsoft account
3. Configure your PC to sync your settings – this will bring your settings back
4. Go to the Store and reinstall your modern apps
5. Reinstall legacy apps
6. Connect your old File History drive and restore everything – this will restore your personal files

It may require more steps than a file or image restore but has some clear benefits:

• You do not restore any “no more desired” software or settings that were on your system
• You do not restore sources of some problems that you might have (or create new problems if you restore to different hardware)
• You do not restore settings that may cause your system to perform badly or fail

Those who need a full system backup can still use Windows Backup to create a system image.

Requirements

File History requires:

• Windows 8 Client operating system
• An external storage device with enough storage capacity to store a copy of all user libraries, such as a USB drive, Network Attached Storage device, or share on another PC in the home network.

FAQ

What happens when you upgrade to Windows 8 from Windows 7?
If Windows 7 Backup was active, i.e. it was scheduled and the schedule was active, then it will continue running as scheduled after the upgrade. File History will be disabled by default and users will not be able to turn it on as long as the Windows 7 Backup schedule is active. To turn it you will have to first disable the Windows 7 Backup schedule.

Can Windows 7 users use File History?
Windows 7 users cannot use File History. However, they can restore files from a drive used by File History by browsing the volume in the Windows Explorer and selecting a specific file. Files on the File History drive are stored in the same relative location, and use the same name. The specific version can be identified by the time stamp appended to the file name.

Does File History protect the operating system and applications?
File History only protects user libraries, desktop, favorites and contacts. Other files, such as operating system files, applications, and settings, are not backed up.

Can File History be used with cloud storage?
No. File History is designed specifically for consumers and does not support cloud storage in this release. Windows 8 Server offers a backup feature that can back up files to a cloud. This feature is available on the Server version of Windows and is designed for small and medium businesses.

Can File History be used by enterprise customers?
Yes. However, enterprise customers should be aware that File History may not comply with their company security, access, and retention policies. For that reason, we offer a group policy setting that allows enterprise administrators to disable the feature for an entire organization.

Will File History protect files stored on a file share?
No. File History only protects file stored on a local drive.

• If you use offline folders and folder redirection, your folders (like My Documents or My Pictures) are redirected to a network share and will not be protected.
• If you add a network location to any of your libraries, this location will not be protected.

In closing

File History silently protects all of your important files stored in Libraries, Desktop, Favorites and Contacts. Once turned on, it requires no effort at all to protect your data. When you lose a file or just need to find an original version of a picture or a specific version of a resume, all versions of your files are available. With the File History restore application you can find it quickly and effortlessly.

--Bohdan Raciborski

This post explains the work we’ve been doing since September to keep developers updated with APIs and tools so that apps can stay up to date. We’re doing this even after the Release Preview, just to make sure new apps are ready to go once we get to broad availability. This post was authored by Dennis Flanagan, who leads our ecosystem outreach team.  --Steven

As we approach the release of Windows 8, the catalog of Metro style apps continues to grow. To date, people have experienced apps that Microsoft has included with the downloaded build, and those that are offered in the Store in both the Consumer Preview and Release Preview timeframe. Many of those apps are great examples of immersive, touch-first Metro style experiences. However, like the Windows releases they run on, these apps are preview versions of the apps to come. The final versions of all Metro style apps will be available when Windows 8 becomes generally available. Last year, we began working closely with the developer community by releasing early versions of the Windows 8 platform and tools. We decided to engage developers earlier in the engineering process so we could help them build skills in Metro style app development and give them the opportunity to influence the platform through feedback. Since September of 2011 we have released 8 developer preview versions. Some of these versions have been available to a limited developer audience. Some have been distributed broadly. All of these releases had similar goals:

• Deliver new capabilities and APIs
• Update tools to simplify Metro style app development
• Enhance performance and reliability
• Respond to developer feedback

We released our first Developer Preview version at the //build conference in Anaheim. This version introduced developers to the Windows 8 platform, tools and programming models. The WinRT platform included new APIs, and we used the conference to present literally hundreds of technical sessions and samples to give developers a basic understanding of the platform. . Many developers got right to work building Metro style apps, produced some impressive early results, and provided us with useful feedback and recommendations about how to improve the platform and tools. We made it clear that the first Developer Preview ("DP1") was an early version of the code, and we had a lot of work to complete Windows 8. DP4 and DP5, released in January and February of this year, were targeted at developers who wanted to be the first to publish applications in the Windows Store. By the time we released the Consumer Preview in February of 2012, we had added almost a thousand new WinRT APIs, and had modified hundreds of other APIs based on developer feedback. For a detailed description of the changes that happened between //build and Consumer Preview, check out these posts on our App Developer blog:

• What’s changed for app developers since //build/ (part 1)
• What’s changed for app developers since //build/ (part 2)

In April and May of this year, we released DP6 and DP7, which allowed developers to prepare their apps for the Release Preview. However, in close collaboration with the development community, we've continued to evolve the platform in response to their feedback. By the time we delivered the Release Preview, we had added 334 more APIs and continued to change existing APIs to address feedback. One example of a change we made in Release Preview (RP) based on developer feedback is the HTML ListView control (in WinJS). This was an area where lots of developers had difficulties, so we overhauled it to make it easier to work with and to allow a much more extensive degree of performance tuning. We also made lots of improvements to developer resources, such as templates in Visual Studio. We even added a new template that makes it easier for developers to start a new project and get a great app up and running in very little time. Design tools were another focus area for improvements. Metro is a design-forward experience, which means the app’s user interface is one of the key ways developers get their apps noticed and differentiate them. We did a lot of work to make it as easy as possible for developers to integrate all the new Metro style design concepts into their apps. For a complete overview of the changes between CP and RP, see What's changed for app developers since the Consumer Preview. Our next major milestone is the release to manufacturing (RTM). When the code reaches this milestone, the platform is complete for general availability (GA), and so we won’t have interim updates for developers. When Developers get the RTM version, they will continue enhancing the features, capabilities and performance of their apps. Some of the apps you’ve already seen will look and perform differently when you download the final released version. There are also many more apps in development that haven’t been released to the Store yet. Many of those developers are waiting for RTM to put the finishing touches on their apps. The release of Windows 8 will be a great milestone for app developers, but it is really just the beginning. A great benefit of the built-in Windows Store and update mechanism is that they provide developers with the opportunity to gain wide distribution for new apps and continuously improve apps that they've already released. As the app developer community evolves, we expect app developers to take advantage of this and provide regular updates to apps.

--Dennis