The Design of the MSDN Hub Pages
This is a behind the scenes look at my involvement in the creation of the MSDN Hub pages.
The MSDN Hub pages you get to from the main “buttons” on the MSN home (pictured above.) Specifically, these are the actual pages:
The intent of the MSDN Hub pages to create some simple starting points for some of our stories on the Microsoft developer platform. For example, you might want to learn the Microsoft cloud story, but you might not know the “building blocks” that make up the story (Windows Azure, SQL Azure, and Windows Azure platform AppFabric.) A Hub page would be a way to share a simple overview of the story, a way to get started with the technology, common application paths and roadmaps, and where to go for more (usually the specific Developer Centers that would be a drill down for a specific technology.)
Why Was I Involved?
If you’re used to seeing me produce Microsoft Blue Books for patterns & practices, and focusing on architecture and design, security, and performance, it might seem odd that I was part of the team to create the MSDN Hub pages. Actually, it makes perfect sense, and here’s why -- They needed somebody who had looked across the platform and technology stacks and could help put the story together. Additionally:
- The purpose of the MSDN Hubs was to tell our platform story and put the platform leggos together in a meaningful way. This is a theme I’ve had lots of practice with over the years on each of my patterns & practices projects.
- I was already working on the Windows Developer Center and the Windows IA (Information Architecture), and the .NET IA, so I was part of the right v-teams and regularly interacting with the key people making this happen.
- I shipped our platform playbook for the Microsoft Platform – the patterns & practices Application Architecture Guide, second edition.
- I had put together a map of our Microsoft application platform story, as well as created maps, matrixes, and drill downs on our stories for key clusters of our Microsoft technologies including the presentation technology stack, the data access technology stack, the workflow technology stack, and the integration technology stack, etc.
- I had previously worked on specific projects to create a catalog to organize and share the patterns & practices catalog of assets. (Internally we called this the “the Catalog Project”.)
- I had worked on an extensive catalog of app types, which served as the backbone for some downstream patterns & practices projects while influencing others, including factories, early attempts at MSF “app templates”, our patterns & practices catalog (so we could enable browsing our catalog by application type), and then of course, the Microsoft Application Architecture Guide.
- I teamed across product teams, support, field, industry experts, and customers to create a canonical set of app types for the App Arch Guide. Here’s what Grady Booch, IBM tech fellow, had to say about the App Types work -- “an interesting language for describing a large class of applications.” Naturally, this work fed into the MSDN Hub pages since we need to map out the most common application patterns, paths, and combos.
My Approach
My approach was pretty simple. I worked closely with a variety of team members including Kerby Kuykendall, Howard Wooten, Chris Dahl, John Boylan, Cyra Richardson, Pete M Brown, and Tim Teebken. I started off working mostly with Kerby, but eventually I ended up working closest with Tim because he became my main point of contact for influencing and shaping the work. That said, it was still a lot of mock ups, ad-hoc meetings, whiteboard discussions, and group meetings to shape the overall result. Tim did a stellar job of integrating my feedback and recommendations, as well as sanity checking group decisions with me.
I also sanity checked things with customers, and I worked closely with folks on the Microsoft Developer Platform Evangelism team including Tim Sneath and Jaime Rodriguez. They were passionate about having a way to tell our platform story, show common app pathy, and how to put our leggos together, and make technology choices. I tried to surface this in the design and information model for the Hub pages.
The Hubs
For the Hubs, at one of our early meeting in November of 2009, I recommended a we use “deployment targets” as a way to help slice things up and keep it simple. Specifically:
- Cloud
- Desktop
- Games
- Mobile
- Server
- Web
As you can see, it maps very well to the App Types set I created circa 2004, but I evolved it to account for a few things. First, I included learnings from working on the App Arch guide (such as moving away from Rich Client to just “desktop.”) Second, I tried to pin it more directly to physical deployment targets to keep it simple. As a developer, you can write apps to target the Web (a “Web” browser app), a desktop (such as a Windows client, or Silverlight, or WPF, etc.), a game (game console), etc. Third, I aligned with marketing efforts, such as recommending we use the “deployment target” metaphor and I renamed the “Mobile” bucket to “Phone” (which worked, because it extended the “deployment target” metaphor, was still easy to follow, and kept things simple.
I also kept the physical aspect of the “deployment target” metaphor loose. For example, “Web” could run on server, or “desktop”, etc. Instead, I wanted to bubble up interesting intersections of application types plus common deployment targets, and keep it simple.
The Server Hub
For the server hub, I recommended addressing our story from a few lenses. First, we have server-side products that can be extended, such as SharePoint, Exchange, SQL Server, etc. That lens is pretty straightforward. Second, I recommended focusing on “Service.” Here’s where it’s hard for folks to follow if they aren’t familiar with server-side development. While you can lump “service” under “Cloud” (as a cloud developer, I can write a Web app, a service, etc.), the “service” story is a very special one. It’s the evolution of our “middleware developers” and our “server-side developers.” It’s the path that the COM builders and server-side component builders shifted to … a more message-based architecture over an object-based one, as well as a shift to replacing DCOM with HTTP.
So if we had a Server Hub, it realistically should address building on our server-side products/technologies (SharePoint, Exchange, SQL Server, AppFabric, etc.) and it should address “Services.” Sure you could also lump SharePoint under Web or Services under Cloud, but you can also bubble up and give focus to some of the fundamental parts of our Microsoft application developer platform.
To be fair, a lot of folks moved around during the MSDN Hub page project, and as new folks came on board, the history, insights, and some of the work may have gotten lost.
How To Solve the Issue of Too Many Hubs
This was my suggestion for dealing with too many Hubs:
“I think one thing that helps to keep in mind is that different people will want different views – but I think it’s simpler to choose the most useful one across the broadest set of scenarios. That’s why Burger King and McDonald’s have a quick simple visual menu of the most common options … then you can drill in for more with their detailed menu if needed. I like that metaphor because it addresses the “simple” + “complete” Platform is a pretty solid bet – with an orientation around “tribes” (I’ll walk you through when we sync live) – after all, we do competitive assessments against platforms and that’s where we need to win.”
I also made a few additional recommendations to deal with the problem of “simple” + “complete”:
- Add an “Office/SharePoint”, and a “Server” (SQL Server, Windows Server, Exchange) – the Office/SharePoint platform tends to have a tribe of customers that speak the same language and share the same context … different than your everyday .NET dev. It’s like BizTalk in that it’s a specialized space.
- Use a carousel approach to feature the main 4, then a “view more…” pattern so show the full 6 or so top level – and leave breathing room. I would go to a page that shows the full set at the top, but then shows the full set of products against a durable backdrop. This would address the “AND” solution of both “Simple” and “Complete”
This would provide a “durable” + “expandable” … AND… “simple” + “complete” … and in the end, a “platform guidance” approach.
While I’m not a graphic artist, I had done some mockups to help illustrate the point …
Home with “View More >>”
View More … (full dev center against a durable backdrop, full tech stack, Roadmaps)
This is blowing up a section of the “Microsoft Developer Products and Technologies” map above that I had created to illustrate the point:
… etc. and the map of course, continued with the technology stack, but used a robust backdrop. The map would need to be vetted across product teams but that’s just the point … have a common map that shows our “catalog” of technologies that customers could easily browse, and that product teams stand behind, while providing simple jump points to either MSDN Developer Centers or Product Team sites.
The Information Model for the Hub Pages
I tried to be inclusive in the information model and I wanted to address and integrate customer pain points I’ve heard about how we tell our story over the years, as well as keep the pages simple and useful, based on what I know about customer usage patterns. These are the main sections I recommended:
- Key Technologies
- Overview
- Common Paths
- Download and Install
- Build Your First Apps
- Arch / Design
- Roadmaps
- Developer Centers and Home Pages
A picture is worth a 1000 words (note this is a picture of the “Information Model” – NOT the page mockups):
My key customer scenarios and questions I used for test cases were:
- Can I quickly make sense of the particular story? (cloud, web, etc.)
- Can I figure out what technologies are relevant?
- Can I figure out how to choose which technology combination to use?
- Can I quickly install whatever I need to get up and running?
- Can I build a quick Hello World app to get my feet wet and some quick confidence?
- Can I figure out the roadmap for the technology or technologies?
- Can I get a quick sense of the most common application patterns, app types, and design patterns?
- Can I figure out my key architecture and design issues if necessary?
- Can I figure out where to go for more? (which Dev Centers, which landing pages, which resources, etc.)
My key recommendations included:
- Provide the most common application paths for the given stories (based on the App Arch guide and DPE feedback.)
- Start with text-based articles and if feasible, add video.
- If we have video overviews, then have the PG teams create them so that they stand behind them and connect with customers
- Keep the areas repeatable across the Hub pages
- For a metaphor, think of the Hubs as the centralizing story for our “building blocks” … and think of our building blocks as the technologies and the “Developer Centers”
- Name the articles “How To –“ and make them actionable and step-by-step
- Name the videos “Explained” if they explain a concept and “How To” if they provide a set of steps.
- Eventually create “Getting Started Guides” for each of the Hubs.
Tim Teebken and I had many late night discussions and drill-downs, which made the work interesting and exciting. It’s always great to work with smart people. We pushed each other, challenged each other, and ultimately we stayed on the same page on the journey.
Well, that’s the story in a nutshell. That’s a behind the scenes look at the making of The Design of the MSDN Hubs and the role that I played.
If you have feedback on the information model, please feel fee to send my way. You can use the contact form on my blog.