Software Engineering, Project Management, and Effectiveness
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:
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:
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”:
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:
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:
My key recommendations included:
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.
Big fan of your blog, but this MSDN design is does not go well.
Many usability Issues and information architecture issues, the ones which strike most are wasted space, unnecessary white space, the buttons are highlighted by default ete etc
Hope you appreciate the feedback
I'm afraid I have to agree with Don. I really dislike the new MSDN home page and the hub pages. The primary impact of the change for me, a many-times-daily user of MSDN, is to make things I use frequently one click farther away, while wasting screen real estate on big buttons that take me to silly pages full of fluff.
@ Don -- Thank you. We're on the same page. There's a gap between the model and the instance (I didn't get to influence the layout, graphic design, or navigation, and it's not the info model I recommended.)
Flipping through history, here are a few of my favorite MSDN instances:
* Circa 2005 - web.archive.org/.../msdn.microsoft.com
* Circa 2006 - web.archive.org/.../msdn.microsoft.com
@ Carl -- We all agree (see my response to Don.)
However, I think there's a mixup of the MSDN home page vs. the MSDN "hub" pages, which are completely separate issues. I'll post my thoughts on the MSDN Home in the future.