The White House published The Open Government Directive (PDF) “to direct executive departments and agencies to take specific actions to implement the principles of transparency, participation, and collaboration” in order to respect “the presumption of openness.”

The memo asserts these principles “form the cornerstone of an open government” and elaborates on the value of each:

Transparency

“promotes accountability by providing the public with information about what the Government is doing.”

Participation

“allows members of the public to contribute ideas and expertise so that their government can make policies with the benefit of information that is widely dispersed in society.”

Collaboration

“improves the effectiveness of Government by encouraging partnerships and cooperation within the Federal Government, across levels of government, and between the Government and private institutions.”

The Directive provides a clear timeline with deadlines for action to be taken by each agency. Key milestones include, but are not limited to, the following:

45 days

identify and publish online in an open format at least three high-value data sets … and register those data sets via Data.gov. These must be data sets not previously available online or in a downloadable format.

60 days

create an Open Government Webpage located at http://www.[agency].gov/open to serve as the gateway for agency activities related to the Open Government Directive and maintain and update that webpage in a timely fashion.

120 days

publish an agency-wide open government plan that will describe and enforce transparency initiatives and will improve public participation and accountability.

The section headings of the Directive provide a clear outline of the document:

1. Publish Government Information Online
2. Improve the Quality of Government Information
3. Create and Institutionalize a Culture of Open Government
4. Create an Enabling Policy Framework

Each section is increasingly inspiring. The first is a given. The second, in addition to being the goal of this blog, speaks to the ever-present need for government to strive to improve its level of service. The third section is novel and lofty as it strives to effect sweeping change across the Federal government in a qualitative way, calling for “lasting change in the way that Government works.” The fourth section provides the structure necessary for success in any large enterprise. To achieve these goals, the six-page memo is followed by a five-page Open Government Plan containing strategies to implement the Directive.

Norm Eisen and Beth Noveck elaborated on the importance of the Open Government Initiative in a blog post titled “Why an Open Government Matters”:

This new degree of openness is enabled in part by 21st century technology, which makes it possible for government to open its doors and databases more than ever before. From online listening tours and chats to web-based brainstorming by government officials with the American public, the White House and federal agencies are opening up the way they work to improve accountability in government and deepen our democracy.

But creating an open government – one that is committed to transparency and civic engagement – does more than promote accountability. Working in the open fosters collaboration between government, private industry, and the public to improve the lives of Americans in their communities.

Right in line with the principle of transparency is the Milestones page of the Open Government Initiative section of the White House site that highlights progress made by various agencies.

While I’m sure we all agree with the spirit of the Initiative, what challenges do you see in implementing this plan?

If you come to Washington D.C. right now, chances are you will see big poster ads by Adobe. This is because Adobe recently launched their Open Government initiative. As stated on their web site:

As Washington takes steps to become more transparent, government departments and agencies are more openly collaborating with each other as well as the public. See examples of how Adobe technology and software are empowering the Open Government movement.

As a web designer and front-end developer working in government IT, I love the Adobe products that I use daily. However, I was surprised that Adobe built their Open Gov site entirely in Flash. Flash sites are not accessible or section 508 compliant. The best use of Flash for government web use now is to stream videos. Chris Foresman summed up the problem with Flash in his article on Ars Technica:

After just a cursory browsing, here are some of the usability and data accessibility issues we observed. You can’t select, copy, or paste any text. Your browser’s font override features won’t work, so you can’t adjust the font or its size to be more readable. Your browser’s built-in in-page search won’t work, and you can’t use the keyboard to scroll through the text. You can’t parse or scrape the data in any way; the design is fixed-width, so it’s not going to work well on different screen sizes; and browser plugins, like Greasemonkey, can’t adjust anything. Basically when it comes to text at all, if you don’t like the style or are visually impaired, you’re screwed.

Personally, I’m not anti-Flash. I believe in using the right tool for the job and Flash has its place. Rich media sites such as TV, movies, and gaming sites use it to offer their tech savvy audiences the best interactive experience. However for government sites, we need to make sure our sites are as accessible as possible to everyone out there. With the advancement in front-end development, many interactive elements can be done in pure HTML, CSS and unobtrusive JavaScript today.

The second issue is Adobe’s push for PDF format. Just about all government agencies use Adobe Acrobat to publish documents in PDF format. I have no problem with PDF for short documents. They’re printer friendly and accessible if done correctly. However, long reports can be a nightmare for both developers and the public who attempt to read them.

Clay Johnson from Sunlight Labs recently wrote a blog post titled “Adobe is Bad for Open Government.”

Take, for instance, H.R. 3200– otherwise known as “America’s Affordable Health Choices Act of 2009″, a 1017 page healthcare bill from congress. Because it is primarily published in PDF, we’ve got to build a special parser for it– that bill– in order to represent it programatically. Or Carl Malamud’s IRS filings for 527 (stealth PAC) organizations: gigabytes of PDF files, all released by government. Government releasing data in PDF tends to be catastrophic for Open Government advocates, journalists and our readers because of the amount of overhead it takes to get data out of it. When a government agency publishes its data and documents as PDFs, it makes us Open Government advocates and developers cringe, tear our hair out, and swear a little (just a little).

Clay suggests instead of PDF we should use other formats such as HTML or XML. I prefer XML since many PDFs already are built off XML format. As for HTML, I can see several issues:

• Writing valid HTML code. Unless the people who create the files are up to date with W3C standards, we’ll end up with tons of poorly written HTML files. Many government sites are plagued with poor HTML already.
• XML offers a structured format that can be transformed using XSL into other, more specific formats such as HTML or PDF.

I recommend reading Clay’s article in its entirety, including its comment section. Recently, Clay and Rob Pinkerton, the Director of Adobe Government Solutions, appeared on the Kojo Nnamdi Show. They offered their views in-depth on Adobe’s involvement in the Open Government movement. The audio and transcript are available on Kojo’s site.

I am happy that Adobe wants to get involved with pushing government IT forward. However, they should study the constraints government agencies face. Document format and accessibility are two important issues given the amount of data to be presented to the public.

“Accessibility” is a big word. Everyone who develops Web sites – coders and content creators alike – should aim for full compliance, but the reality is that only the criteria in Section 508 are legally binding to government. For Web-based intranet and internet information and applications (§ 1194.22 ), this means sixteen criteria and the Adobe Open Government site does not meet them. Paragraph (l) states “When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.” Unfortunately, there is text content in the HTML source of the page, but CSS is used to hide that content in such a way that it is not announced by screen readers (using “display: none“).

Adobe missed a valuable opportunity to demonstrate how Flash can be used in an unobtrusive and/or accessible way; if Adobe can’t make a Flash-based, 508-compliant site, why should we expect government developers – or any developers – to do so?

Update (12/3/2009): The Adobe Open Government site has been updated! The site still uses Flash to provide some background animations, but the content is marked up using HTML, CSS and JavaScript.

HTML4 provides limited ways to give meaning to content through markup alone. In this post, we examine Microformats that provide real-world design principles, RDFa which enables extensible vocabularies and the new Microdata features of HTML5. All three seek to combine machine-readable data with human-readable content.

This past weekend, the White House switched their web site to Drupal. In addition to making news because it is using an open source stack (Linux, Apache, MySQL, PHP and Apache Solr for search) it is noteworthy because it makes use of the XHTML+RDFa doctype. This little-known spec is a W3C Recommendation (a “standard”) that enables authors to add semantic metadata – RDF, which is usually contained in a separate document – to their markup using attributes that are both machine-readable and human-friendly.

You Mean Like Microformats?

Microformats work as design patterns within the confines of HTML4 – using features such as the class attribute – but they rely on a pre-existing agreement between you (the author) and the author of the parser that consumes the markup. This agreement is in the form of a vocabulary for a particular type of information such as hCard for contact information: this is the name, this is the phone number and so on. But what if you want to include a piece of information that isn’t part of the microformat, like a TTY number? You’re stuck.

Unfortunately, that wasn’t part of the original vCard spec (upon which hCard was based) and while there is a “flexible method” to add custom types to vCard, you’re at the mercy of each parser whether it will detect your TTY number because you’re restricted to the vocabulary that has been determined by the hCard microformat. However, microformats are easy to use and provide a compact syntax if you’re publishing information that is covered by one of the many vocabularies provided. (Check out the great Getting Semantic With Microformats series by Emily Lewis to learn more about microformats.)

So What Is RDFa?

“One motivation for RDFa has been to devise a means by which documents can be augmented with metadata in a general rather than hard-wired manner. This has been achieved by creating a fixed set of attributes and parsing rules, but allowing those attributes to contain properties from any of a number of the growing range of available RDF vocabularies.”

RDFa (Resource Description Framework in Attributes), like microformats, enables you to add structured meaning to your markup. Unlike microformats, RDFa allows you to specify the vocabulary used to describe the data. The quotation above comes from the XHTML+RDFa Recommendation RDFa in XHTML: Syntax and Processing, which is a very technical document, so start with the RDFa Primer. It provides clear examples of how you can “express simple and more complex datasets using RDFa, and in particular how to turn the existing human-visible text and links into machine-readable data without repeating content.” Emphasis mine, for this is the key.

With the push for government to publish more data, why should the data have to live in separate formats for human and machine audiences? There is certainly a lot of information that is published in HTML (and XHTML served as HTML) that could benefit from structured markup to open it up to the web of Linked Data. In September, the W3C eGovernment Interest
Group examined these benefits in the Working Draft document Publishing Open Government Data.

In an interesting twist, the White House site previously used RDFa on their Copyright Policy page to markup Creative Commons license information, but now those attributes are no longer present, even though the page is using the XHTML+RDFa doctype. If you look at the root HTML element, you can see the following vocabularies being referenced using the “xmlns:” prefix (though unused): Dublin Core (http://purl.org/dc/elements/1.1/) and Common Tag RDF Vocabulary (http://commontag.org/ns#). Multiple vocabularies can be used on a given RDFa-enabled page and it is recommended to use a pre-existing vocabulary before you define your own.

What About HTML5?

Good question. As I mentioned before, XHTML+RDFa is a W3C Recommendation and RDFa is implemented in Drupal – a major CMS – and supported by both Google and Yahoo! to enhance search results. Just a few weeks ago, the HTML Working Group published a Working Draft of HTML+RDFa but there are still some big issues to sort out, due to the way XHTML+RDFa made use of the extensible nature of XHTML (remember the X?), particularly its use of XML namespaces and custom attributes; the goal is to add these attributes to HTML5. The Working Draft makes clear that it applies not only “to HTML5 documents in non-XML and XML mode [a.k.a. XHTML5], but also to HTML4 documents interpreted through the HTML5 parsing rules.”

But HTML5 Has Microdata

Currently, the HTML5 Working Draft contains a section called Microdata, which resembles microformats but uses newly-created attributes to embed “machine-readable labels” and “nested groups of name-value pairs” called “items.” HTML5 also defines a DOM API to extract an item’s properties. The current spec, which was published today, states that “using microdata means using a vocabulary” and even goes so far as to encourage authors to “to re-use existing vocabularies, as this makes content re-use easier” which sounds similar to RDFa. Yet the WHATWG chose not to re-use the syntax and grammar of RDFa. Jeni Tennison dove into the differences between the two in HTML5/RDFa Arguments and a commenter claiming to be Tantek Çelik (co-creator of Microformats) noted that Ian Hickson chose to model microdata on microformats instead.

The debate between microdata and RDFa continues now, even as Ian Hickson announced today that HTML5 is at Last Call, Last Call status only applies to the path of HTML5 within the WHATWG, not its path through the W3C HTML Working Group. Issue 76 in the HTML WG Tracker is still open regarding “Concerns about Microdata section and inclusion/exclusion of RDFa.”

Although the issue of microdata and/or RDFa continues, it is clear that HTML5 will provide a mechanism(s) for publishing structured, semantic data that is both machine-readable and human-readable. The White House site has the capability right now to publish such information. Which existing or future information do you expect to see?

Do you see yourself taking the extra steps to give structure to your data?

One of the challenges when building government web sites is that the targeted audience range is diverse. This means we must ensure that our sites are accessible to everyone. In 1998, Congress introduced the Section 508 of the Rehabilitation Act. Therefore, implementation of accessibility measures for government sites is not just a “nice to have,” but required by law.

Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals.

This past Saturday we attended the Accessibility Camp DC, organized by John F. Croston III. John is a web developer and accessibility advocate working with the United States Army.

The event had a great turn out of a diverse group of users, administrators, developers and accessibility consultants – many of whom rely on assistive technology – who were more than willing to share their insights. Organized in a bar camp/unconference fashion, the first activity of the event was creating a schedule of presentations and discussions from the list of suggested talks and topics on the event web site and from attendees volunteering to present or moderate. Special mention must be made of Patrick Timony the Adaptive Services Division team at the MLK Library in D.C. who generously opened their facilities to us including standard convention amenities such as chairs, gathering spaces, Wifi and power outlets but also a CART system and sign language interpreters. The CART system offered real-time captioning (provided by 2020 Captioning) projected onto a dedicated screen (the screen on the right side of the image, above) which not only increased the accessibility of the sessions (in that space) to attendees with a hearing impairment, but it also was a great tool for those of us taking notes and a perfect example of how accessible, inclusive design can increase overall usability.

Unfortunately, we couldn’t attend all of the sessions. Here are some sessions we attended:

• Web Accessibility Initative, WCAG and 508 – Shawn Lawton Henry, W3C-WAI
• Testing Techniques – Sam Johel, SSB Bart Group
• Government Project Management – Fred Simonton and James Chandler
• JAWS Screen Reader Demonstration – Jennison Asuncion
• Is Your Website Accessible? Practical Ways to Make It So – John F Croston III

W3C WAI, Section 508, WCAG 2.0 and the Differences Between Them — Shawn Lawton Henry

Shawn Henry leads worldwide education and outreach promoting web accessibility for people with disabilities at the W3C Web Accessibility Initiative (WAI). Shawn focuses her personal passion for accessibility on bringing together the needs of individuals and the goals of organizations in designing human-computer interfaces. Her recent book, Just Ask: Integrating Accessibility Throughout Design, which is available free online, offers an approach for developing products that are more usable for everyone.

Shawn’s presentation covered the history of various recommendations (standards) and policies including the Web Content Accessibility Guidelines (WCAG) 1.0, Section 508, WCAG 2.0, Authoring Tool Accessibility Guidelines (ATAG) and the differences between them. She described the process leading up to WCAG 2.0 and the “grumbling“ that followed. The community at large felt it was too full of technical jargon and didn’t contain enough real-world language. However, Shawn explained this criticism was a result of misunderstanding as this version of the Guidelines is written in technology-neutral language to better accommodate future technologies.

WCAG 1.0 focused specifically on HTML, CSS, JavaScript, PDF and Flash. In addition to the detailed Guidelines, the WCAG 2.0 document suite includes supporting materials that describe how to apply the Guidelines in technology-specific ways, such as in HTML documents. In her words, the technical standard is short – to facilitate stability – while the best practices are lengthy to be more specific.

Of particular interest to us was the discussion of the Section 508 Refresh currently being undertaken by the United States Access Board, which began in March, 2009. An audience member stated that Timothy Creagan at the Access Board said that advance notice of a public proposed rulemaking will be published later this year. When I asked Shawn how members of the community can provide feedback, she answered that there will be a window for public comment. This led to a larger discussion of how we as a community must raise issues to vendors, site owners, et al, in order to give them reasons to get accessibility prioritized within their organization.

A noteworthy takeaway from the discussion is that a stack of email messages complaining of issues sends a strong message and/or provides concrete evidence for site owners and project managers to prioritize accessibility. I added that this is especially important with the rise of purely community-based projects such as JavaScript frameworks (which are authoring tools themselves). Fortunately, the WAI is working on a document “How to report inaccessible web sites.”

Testing Techniques — Sam Johel, SSB Bart Group

Sam Johel is an accessibility consultant at the SSB BART Group in northern Virginia. His presentation described the process developed by SSB BART to quantify and qualify the accessibility of a site and the options available for testing. We hastily took down these notes during Sam’s presentation:

Automated tools

• fast, but notoriously prone to inaccurate results
• Limited to HTML/CSS pages: cannot access non-HTML media
• Unable to test the functional standards

Manual Review

• Is a code-level review
• Provides a much higher level of accuracy than automated tools
• But, it must be done by humans, so it relies on extensive knowledge on the part of the tester and potential for error
• Reviewing large volumes of code is far too time intensive

Use Case Testing

• Common to quality assurance and accessibility testing
• Involves specific tasks to be completed
• (At this point, Sam clarified that the true measure of a system’s level of accessibility is whether or not disabled users can use the system, not only complete a specific task)
• Just because a site is accessible does not mean it is compliant
• Very AT-dependent; a site may be usable with JAWS, but not ZoomText

Sam added that with the increased use of rich Internet applications, there is more need to run automated tests first (to catch the 20-25% of issues that can be identified by automated testing), then do manual testing to verify issues raised by automated tests and to find other issues. Finally, perform use-case testing (design workflows for disabled users to complete, go through system, note issues) to catch any other issues.

“We want our testing to be accurate and consistent.” SSB BART have broken down different standards (e.g., 508, WCAG) to create a checklist of criteria – to test against – and best practices to produce consistent, repeatable results and defensible criteria. “The standards will change, so we create the best practices and map those to standards.”

Government Project Management — Fred Simonton and James Chandler

Fred Simonton is an information technology specialist working at the Library of Congress and James Chandler (@uxprinciples) is a consultant working with various agencies to ensure compliance. Together, they presented accessibility from the angle of management.

Fred spoke of the issue of 508 compliance within an agency and James continued the discussion with a very thought-provoking series of questions when he asked us these questions:

1. Are you familiar with Section 508
2. If so, have you read the Federal Acquisition Regulation (FAR) rules covering 508 – where it applies, to whom and so forth?
3. According to the FAR who is responsible for specifying 508 compliance?

Fortunately for us, James laid out the responsibilities in detail – it is the role of the agency to specify the required compliance – and the risks that can be incurred if another party such as a contractor takes on that task. There was mention that it is a known issue within the federal government that 508 compliance is too-often part of acquisition document templates, even when it does not apply.

James pointed out that by not thinking about accessibility from the very beginning of project development it will end up being very costly. He stressed that it is up to the management and the developers to be aware of ensuring web sites are accessible. Otherwise, future fixes will take much more resource and time.

JAWS Screen Reader Demonstration by Jennison Asuncion

Jennison Asuncion is an accessibility consultant and a JAWS user and he gave a demonstration of some typical browsing scenarios for blind users. Fortunately for us, he slowed down the rate at which the words were read so we could follow along. He pointed out some tips, too, including (but not limited to):

• The title attribute is not read by default
• All pages are linear to a screen reader user
• Screen readers read from left to right, top to bottom

Is Your Website Accessible? by John F. Croston III

John’s presentation provided a great check list for making a website accessible and best practices. You can read his presentation in its entirety on his site. Here are some of items to check for if your site is accessible or not:

Text and Fonts

Use proper size, leading, kerning and measure.

Color and Contrast

Text less than 18pt should have a color contrast of 4.5:1, and 3:1 for bigger text. Color Contrast Checker is a great tool for checking color contrast.

Skip Nav

Skip Nav is a link (sometimes hidden) within the page that allows screen reader users to skip to main content quickly, so they’re not forced to tab through all the top links.

Tables

HTML tables should written in semantic code. The “Summary” attribute is useful to tell the screen reader what the table is about.

Forms

An accessible form should use fieldset(s), legends(s), labels on input fields, and tab indexes.

Screen Readers

There are several popular screen readers. JAWS, Window-Eyes, and the free open source Fire Vox (a Firefox extension)

Accessibility Resources

• W3C – Web Accessibility Initiative
• W3C WAI – WCAG 2.0
• Section 508
• Aaron Gustafson – http://easy-reader.net/ – blog
• Aaron Gustafson – Web Visions 07 Forms Presentation
• Derek Featherstone- http://www.furtherahead.com/
• Ian Lloyd – http://lloydi.com/
• Ian Lloyd – http://www.accessify.com
• Joe Clark – http://joeclark.org/
• Joe Clark – http://fawny.org/ – blog
• Patrick Lauke – http://www.splintered.co.uk/

Photos

We Had a Great Time!

All in all, it was a long day but we left inspired and energized. While we couldn’t take part in the after-camp festivities at the bar, we met many new people during the events and feel more connected to the community both personally and professionally. We’d like to thank John and other organizers for hosting the event, and speakers who shared their insights. We look forward to the next event!

P.S. If you attended the sessions we weren’t able to make, please share their information and materials. John has started collecting Accessibility Camp DC slides, blog posts and other links and #accesscampdc is still going strong. Let’s keep the discussion going!

Thank you.

Test early, test often. Web development demands persistent testing throughout the entire process to identify issues early and deal with them before they require a large-scale overhaul. Internet Explorer (IE) usage is diminishing, yet it remains the predominant browser for most sites. In addition, users of IE do not always upgrade immediately, even when there is a new version with clear benefits over the old. Many IT departments prevent users from upgrading due to a dependence on or a lack of resources to roll-out a new browser and many users simply don’t see a reason to upgrade. Plus, with the recent announcement that Microsoft plans to support Windows XP until 2014, IE6 – the default browser in XP -  will be with us for some time. Even the promise of Google Chrome Frame doesn’t let us off the hook because we can assume it won’t be installed for similar reasons. That leaves us with the burden of testing in multiple versions of IE.

In this article, I’ll show you how to install multiple, legitimate versions of IE to speed up testing by taking advantage of two no-cost products available from Microsoft: Virtual PC (VPC) and Internet Explorer Application Compatibility VPC Images. When we’re done, you’ll be able to confidently test in IE6, IE7 and IE8.

While there are various “stand-alone” versions of Internet Explorer available, none are officially supported and I always question their accuracy, especially for anything involving cookies, JavaScript or sessions, so I don’t use them. Fortunately, Microsoft provides free (as in beer) versions of IE in the form of Virtual PC images. You can choose IE 7 or 8 on Vista or XP SP3, or IE 6 on XP SP3. The limitations – such as their limited lifetime – the current images expire January 1, 2010, but new images should be released before then – and additional time to launch are far outweighed by the assurance gained by using the genuine article of an installed version of IE. Plus, you have the option to save or roll-back the state of the machine so it’s a breeze to quickly try out new things such as Google Chrome Frame.

What’s a Virtual Machine?

Good question. Simply put, a system Virtual Machine (VM) is an operating system running within a window on your computer. When launched, a window appears that resembles another computer running on your desktop, taskbar and all. You can resize the window or switch to fullscreen mode and feel like you’re using a different machine. In fact, you don’t have to stop at just using a different browser. A major advantage provided by a virtual machine is the fact that the entire system is sandboxed. Take advantage of that by installing and testing screen reader software or other assistive technology that you may not want to use all the time on your host computer.

The Strategy: Upgrade to IE8, Install IE6 as a VPC

IE8 is a major step forward from IE7 in terms of performance, standards support and development tools. The IE Developer Toolbar add-on for IE6 and IE7 has been renamed Developer Tools and greatly expanded to include a JavaScript debugger and console (similar to the Firebug add-on for Firefox). Plus, the Developer Tools feature is now bundled with the browser by default – this is great news for developers who are not allowed to install add-ons. Like Firebug, you can open the Developer Tools by pressing F12 on the keyboard, or you can select it from the Tools Menu in either the Menu Bar or Command Bar. Personally, I add it directly to the Command Bar by right-clicking an empty area of the toolbar area, selecting “Customize” and then “Add or Remove Commands.”

So go ahead and upgrade to IE8 because of the reasons stated earlier. In fact, IE8 includes a robust IE7 mode called Compatibility View which you can use for testing – it’s accessed by the Developer Tools. So installing IE8 means you have IE7 built-in, which means you just need to install IE6 in a Virtual PC image. Of course, you may want to install a VPC with IE7 just to be sure, but the switching within IE8 is much faster than waiting for the VM to load and allocating space for another VPC (about 1.5GB).

Logistics

Here’s how we’ll do it: we’ll install Virtual PC first and then set up individual virtual machines (VMs). When we’re finished, you’ll be able to fire up a window with an instance of XP or Vista with a “real” (installed) version of IE and test with confidence. Let’s begin.

Here are 3 steps to get your virtual machines set-up:

1. Download and install Microsoft VirtualPC
2. Download licensed disk image from Microsoft of Windows with IE
3. Create a virtual machine inside VirtualPC using the disk image

Here they are again, in detail:

1. Download VirtualPC
   1. install VirtualPC
2. Download IE Application Compatibility VPC Images
   1. Double-click the “.exe” file to expand the image (VHD file, or virtual hard disk) to the location of your choice. Note: these files will be greater than 1GB in size, so choose wisely.
3. Create Virtual Machine Configuration (VMC) files
   1. In the Virtual PC console, click the “New…” button to launch the New Virtual Machine Wizard. The option “Create a virtual machine” should be selected. Click “Next” to continue:

      

   2. Choose where to create the VMC file, which will contain the settings of the VM that loads the VHD. Personally, I prefer to keep it in the same location as the VHD. Click “Next”.
   3. Now, we’ll choose the operating system (it should be pre-selected) and review the default hardware selection. Note the low amount of RAM memory (128MB) – we’ll adjust this in the next step. Click “Next”:

      

   4. “Memory” – In this step, I recommend increasing the RAM from the recommended 128MB, so select “Adjusting the RAM” to reveal additional fields to “Set the RAM for this virtual machine.” This virtual RAM will use the physical RAM available on your host machine, so choose a level that you’ll be comfortable with. I recommend at least 512MB RAM if you can spare it and click “Next” to continue:

      

   5. “Virtual Hard Disk Options” use the default selection to use “An existing virtual hard disk” – we’ll use the VHD we expanded in step 2.
   6. “Virtual Hard Disk Location” Browse to the location of the VHD file we expanded in step 2. If you choose to “Enable Undo Disks” there will be an additional file created that is about the same size as the VHD file (>1GB) so bear that in mind. Personally, I use my VMs only for testing pages, not storing data, so I do not use this because the VM can save its state when you close it and it takes additional time to commit the changes to the Undo Disk on close.
   7. Finally, review your settings in the “Completing the New Virtual Machine Wizard” pane and click “Finish”. Congratulations, now you’re on your way to using your shiny new VM! Once the wizard closes, you’ll see the newly-created VM listed in the Virtual PC Console. You can select it and click “Start” to launch it.

Now we’re ready to launch our new VM. You can launch it in various ways:

• Opening VirtualPC, selecting the VM and launching it
• Launching the VM directly by opening the VMC file (which will launch VirtualPC and then automatically launch the VM)
• Protip: create a shortcut to the VMC file and put it in your Start menu, Quick Tasks toolbar or right on your desktop for easy access.

So go ahead and launch it. Once Windows has booted up, we can start to finalize the setup.

Using Your New VM

Alright, your new VM is ready to use, so let’s set it up. Here are some notes to bear in mind:

• Adjust the network settings: You probably need to adjust these settings by going to the Edit menu of the VM window, selecting “Settings” and then “Networking.” If you’re using a laptop, you’ll need to set this each time you switch between wired and wireless networking.
• Flash is not installed by default, so you’ll need to install it manually.
• On the desktop inside the VM window, you’ll see icons to install the IE Developer Toolbar and the MS Script Debugger. These add-ons have been replaced in IE8 by the much-improved Developer Tools which are included with the browser. You can also install IE7 Readiness Toolkit.
• Get the full effect by switching the VM to fullscreen mode in the menu or press Right Alt+Enter.
• Copy and paste works only for text between the host computer and the VM,  such as copying URLs and such.
• The VM acts like a separate machine on your network, so if you want to test pages from your local server (localhost) you’ll need to use your IP address instead.
• Got more? Please share them with us in the comments!

Congratulations! You’re all set to test using legitimate, full versions of Internet Explorer on Windows thanks to Microsoft. What are your tips and tricks for using virtual machines and what do you use them for?