An MSDN Library for the Windows Dev Center

This week at Microsoft’s BUILD conference, we unveiled the new Windows Dev Center with four focused sub-centers: Windows Store apps, Internet Explorer, Desktop apps and Hardware:

Windows Dev Center

Windows Store apps Windows Store apps Internet Explorer Internet Explorer Desktop apps Desktop apps Hardware Hardware

As you click through the options in the Center navigation menus, you’ll see familiar MSDN pages (Samples, Downloads, Community, etc.) but with a twist. They’ve been integrated into the Windows Centers so that their branding and navigation is consistent with that of the product.

Library content (under the ‘Learn’ tab instead of the ‘Library’ tab) is also tightly integrated with the Windows Dev Centers and represents a significant departure from the standard MSDN Library.

Why did we create a new, integrated library experience?

The Windows 8 Learn tab provides a specialized version of the MSDN Library devoted to Windows 8 development. It delivers a targeted subset of the content in MSDN and a library search feature that’s constrained to Windows 8 Development topics.

We created this experience to address feedback we’ve received from developers about the challenges they face when using the online MSDN Library.

“It’s great that the MSDN Library has everything, but it’s too hard to find exactly what I’m looking for. It’s like looking for a needle in a haystack.”

There are over 3 million topics in the English language MSDN Library. And, mathematically speaking, about 3 million of those topics are irrelevant to you at any given moment. The Windows 8 Library lets you quickly move a large number of irrelevant topics out of your way so you have a better view of the content that you really need. The Windows Dev Center, at the time of BUILD, reduces the number of topics to about 15,000! Search queries performed inside the Windows 8 libraries will be constrained to those 15,000 topics.

Let’s look at an example of how integrated libraries move unneeded content out of your way. If you’re on the Windows Store apps Learn tab and you search for a Win32 API like “CreateWindow” (used by Desktop apps but not by Windows Store apps), you’ll get a “No Results Found” notification:

image

It’s just not there cluttering your life. However, if you truly need to find out more about the CreateWindow API, it’s trivial to remove the Windows Store apps refinement and automatically re-issue your query against the entire MSDN Library.

image

“The table of contents looks too much like a Microsoft org chart. As a result, the information I need is often scattered across the MSDN Library.”

Integrated libraries let us pull relevant content that’s scattered around the MSDN Library into a single experience. For example, we can take patterns & practices phone development guidance and consolidate it with Windows Phone Development content.

“It’s hard to tell one part of the MSDN Library from another and to know which section I’m in, especially when I drop in from a web search.”

Each of the Windows Centers has a unique and easily identifiable URL. Before you’ve even entered a library, you can use the URL listed in search engine results to help determine which result is most relevant. For example:

Library URL Examples

Once you’re in the library you’ll note that product-specific branding helps you quickly determine where you’ve landed.

Scoped Library Design Principles

Ready for a look under the hood? The integrated Windows 8 Library experience is based on a new capability of MTPS called scoped libraries. A scoped library is a subset of the online MSDN Library with four main components: a reduced set of topics, a search mechanism constrained to those topics, an easily recognized identity (e.g. Windows 8 Development) and a unique, readily identifiable URL path. We’re piloting the Windows scoped libraries and an Azure scoped library to validate that they meet developer needs before adopting them elsewhere in MSDN and TechNet.

I’ve already discussed the benefits of scoped libraries; now let’s review some of the assumptions and principles that governed their design.

1) Every topic in a scoped library is also in the main library

Every topic in a scoped library is also present in the MSDN library. If a developer needs to work with multiple platforms or technologies at the same time, all of that information is available in the master MSDN Library without having to hop around between scoped libraries. The MSDN Library is still your one-stop shop for developer content.

2) As a rule, topics should not appear in more than one scoped library

Since each scoped library topic also appears in the master library, it follows that each scoped library topic can be found at two different URLs: the scoped URL and the master URL. For example, these are the URLs for the “Make great Windows Store apps” topic:

Scoped URL: http://msdn.microsoft.com/en-us/library/windows/apps/hh464920.aspx
Master URL:  http://msdn.microsoft.com/en-us/library/hh464920.aspx

Which of these topics is the preferred version? In this case the scoped library topic will be the canonical or preferred version and its URL will receive priority in search engine results.

image

However, if the same topic is repeated in multiple scoped libraries, we start creating confusion for the user: Why are there so many versions? Are there any differences between versions? If so, which version is the definitive version? Consequently, if a topic must appear in more than one scoped library, the topic in the master MSDN Library will be the canonical URL.

Finally, we provide a way for Microsoft content authors to override the default canonical URL when necessary.

3) Fewer libraries is better

More isn’t necessarily better when it comes to scoped libraries. We don’t want to replace the “needle in the haystack” problem with the “infinite haystacks” problem. Current thinking is that we’ll limit them to our core development platforms (Win8, Azure, Phone, SharePoint, etc.) As we introduce more scoped libraries, we’ll also need to make it possible to discover and navigate between them.

4) Scoped libraries don’t live forever

We expect a typical scoped library to have a lifetime of about three to five years. When a scoped library disappears, the MTPS platform will automatically redirect topic requests to the equivalent topic in the master MSDN Library. Long after attention has moved on to newer platforms, you can still get to the content you need.

This entry was posted in MSDN Library and tagged , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

One Trackback

  • By September 19, 2011 – Learn TFS Daily | Learn TFS on September 20, 2011 at 5:03 am

    […] An MSDN Library for the Windows Dev Center from Jeff Braaten Jeff highlights the new Windows Dev Center and its four sub-centers: Windows Store apps, Internet Explorer, Desktop apps, and Hardware. He answers why the new, integrated library experience was created and explains the scoped library design principles. […]

%d bloggers like this: