Rob Caron

Developer-related topics and other stuff.

Managing Complexity

Managing Complexity

  • Comments 14

As noted in posts I made back in March (Groundhog Day at MSDN) and in April (Déjà Vu All Over Again), I'm trying to tackle the unenviable task of addressing the growing complexity of content on MSDN. To get a glimpse of what MSDN used to be like when I first got to Microsoft, I used the Internet Archive's Wayback Machine. MSDN Online in April 1999 was a bit simpler than it is today. The Visual Studio site in 1999 had content for Y2K, boasted integration with Rational Suite, and linked to the new Visual Studio Solutions Center containing Windows DNA sample applications.

In the intervening years, MSDN's rapid growth mirrored the increasing complexity of developer tools, platforms, and technologies that lead us to where we are today. Through a combination of innovation, acquisition and evolution, Visual Studio expanded to the broader software development team, new platforms emerged (.NET, Dynamics, XNA, Windows Embedded, and numerous server products), languages were created (C#, J#, etc.), and technologies were added to the developers arsenal (WPF, WF, WCF, etc.). For those developers who were along for the ride, you're probably still waiting to catch your breath.

At times I think the "Curse of Knowledge" (originally described in The Curse of Knowledge in Economic Settings: An Experimental Analysis, but recently made popular by the Heath brothers in Made to Stick: Why Some Ideas Survive and Others Die - which is an awesome read) has kept us from doing a better job of managing the complexity of it all and making the Microsoft developer story accessible to more people. Outside of sites on MSDN like the Beginner Developer Learning Center, do we really know what it's like to be a beginning developer these days?

In The Laws of Simplicity (Simplicity: Design, Technology, Business, Life) (another excellent read), John Maeda writes Zen-like (at times I caught my mental voice sounding like I was speaking to a young Kwai Chang Caine) about the 10 Laws for achieving simplicity. Reflecting on MSDN, I can see various ways of applying many of these laws to simplify the MSDN experience. Maeda structured the Laws such that "the successive set of three Laws (1 to 3, 4 to 6, and 7 to 9) correspond to increasingly complicated conditions of simplicity."

  1. Reduce - the simplest method whereby you thoughtfully eliminate what's not needed. I know a lot of people would argue that this is sorely needed on MSDN.
  2. Organize - develop a system that makes more look like less. The new MSDN UI helps here, and I have a specific idea to organize MSDN to help reduce complexity.
  3. Time - anytime you make something faster, it feels simpler. Search is probably the easiest answer here.
  4. Learn - knowledge makes stuff seem simpler, which can lead to the Curse of Knowledge. Learning to use MSDN is probably the most we should ask.
  5. Differences - simplicity and complexity are somewhat relative; without one, the other is less obvious. I think the complexity of the developer landscape is sufficient enough that we need not mirror it with MSDN.
  6. Context - to understand where you are in the larger scheme of things. The idea I hinted at in Law 2 addresses this, too.
  7. Emotion - when emotion matters, add complexity if needed to achieve it; if form follows function, emotion follows form.
  8. Trust - the more the system thinks for you, trust it so you need to think less. To me, the notion of personalization tries to achieve complexity by letting the system manage complexity for you, but leapfrogs some of the simpler means of achieving simplicity.
  9. Failure - the one I fear with this endeavor: that some things just can't be made simpler.
  10. The One - subtracting the obvious and adding the meaningful. Of course, the Curse of Knowledge can derail this; what's obvious to the expert, or seemingly meaningful, may not be to the novice.

Today, MSDN is largely a collection of sibling developer centers that sprung up over the years as new products, technologies, and platforms were added to the Microsoft developer story. One fundamental idea I have to simplify MSDN is to Organize these developer centers in such a way that it also provides Context based on the type of software development. In addition, I think there are some areas of MSDN that are core to all (well, almost all) software development. Conceptually, here's the layer of organization I'd like to insert between the MSDN home page and the vast collection of developer centers and other resources on MSDN (yes, I know this needs more explanation - I'm afflicted by the Curse of Knowledge, too):

MSDevStoryStructure

Interestingly enough, the Beginner Developer Learning Center does this on a smaller scale with entry points for Web, Windows, and Game Development. Something you may have noticed as missing from this illustration is .NET. To me, .NET is increasingly ubiquitous in the Microsoft developer story, which is why I'd place it in the category of Core Development Technologies.

Thoughts? 

1303

  • Sounds to me like you are heading in a positive direction.  Lets face it, the fact that someone is trying to join these various threads togther and that thought is going into the information architecture of MSDN as a whole is a good thing in itself.

    I am (by no means) an expert in information architectures but IMHO the current MSDN organization seems to reflect the internal structure of Microsoft DevDiv - which doesn't really sit with the 99% of the Microsoft Developer Community that don't even know what DevDiv is - never mind the internal bits inside DevDiv...

    Personally, I have an issue with the whole split between MSDN and TechNet - when I think Microsoft I think of one company, but that is probably a whole area I shouldn't waste my time on.

    So - here is some feedback on the specifics like you actually asked for ;-)

    I was confused that "Dynamics" shared the same level with Web, Office, Servers, Database, Game.  I guess that this is says more about either the lack of penetration of Dynamics or my lack of familiarity with it.

    Also "Servers" is a bit vague.  Do you mean "developing for a server?", which server?  Sharepoint (or is that office), TFS, Windows Server, SQL Server etc etc.

    In your diagram you have several things charted with the same size (such as Windows Client and Windows Embedded).  Obviously, the odds of my being interested in one is greater than the other which should probably be reflected in any navigation UI.

    Why is "Device Drivers" listed in OS platforms?  Isn't that a subset of most of the seperate platforms?

    When I come to MSDN, I'm usually looking for the stuff in Green.  How to some something with a particular language, which technology is the correct choice for something.  Some pointers for how do I sell that technology to the people who sign the cheques are good, but I'd expect a lot of the marketing type content to be on Microsoft.com which is where CIO's etc would go look.  MSDN is for developers allready commited to a platform trying to make best use of it.

    Either that, or I'm looking for some information from my MSDN Subscription (like a product key or an ISO to download)

    Being outside of the US, the MSDN magazine content does not have much impact for me - but I am frequently impressed by the quality of it when I do stumble across it as a code example or something.

    But that's me - I dare say I have totally different interests and usage of MSDN than most folks.

    Couple of things I want to credit MSDN with.  I like the F1 help integration in Visual Studio with the online content - and that this content is being continuously improved.  I like the fact that it is pretty easy to search so that when I use my favourite search engine, results come up.  I like that fact that URL references to MSDN seem to stay valid.  These are things that you do well and I want them to continue this way.

    For what it is worth, while the content organization in MSDN could do with improvement, it is better than many of your competitors.  I have to research stuff on the IBM, SAP, Oracle, BEA and Eclipse "developer networks" and yours is by far the easiest and most up to date.

    Hope that helps - looking forward to seeing the results.

    Martin.

  • I agree with you that search is a big component of the answer (#3), but it's also much of the problem. The number of times I've browsed through the tree for what I want on MSDN is probably two orders of magnitude less than the number of times I search for what I want.  However, search is painful for API details (among other things).  Thus, since it is often how I hurt, I'll talk about the developer level searching for direct information about an element of the library.

    Current, real-world instance: I go to MSDN and type "FileInfo" into the search box. (I tried doing this with "file", but it was much much worse).

    My first fifty results are 47 different properties/methods/overview pages on System.IO.FileInfo (four of which are foreign language versions of methods already listed above), two entries on the C++ _fileinfo global, and one on using the FileInfo class in Powershell.  This takes four screens of scrolling to look through on a full-screen browser with Medium text. Going through the local help browser gives me similar results, only split into four high-level categories with more noise.

    Digging deeper, I try to choose between ".Net Development", ".NET Framework SDK library", ".NET Framework Base Class Library".  Guessing the last, I get FileInfo class, FileInfo.Name property, and Directory Class... .Net Framework SDK gives me the FileInfo class and three properties (spanning three languages), and then... you get the point?

    Ideas:

    I'd be nice if an API element's results were returned in the form (all appropriate elements as hyperlinks, of course, and probably more inline than I structured it here):

    FileInfo Class (System.IO):

    * Members

    * Constructor

    * Methods

    * Properties

    * Events

    Classes Referencing FileInfo:

    * DirectoryInfo

    * DriveInfo

    Classes Referenced by FileInfo:

    * FileMode

    * FileShare

    * FileAccess

    MSDN Resources for using FileInfo:

    * File and Stream I/O (article)

    * Reading text from a file (HOWTO)

    Community Resources for using FileInfo:

    * Blah blog

    * other blog

    * etc

    Now, I understand this is only for the API (and maybe only .NET at that), but domain-specific search would help a LOT in getting to what people want.

  • This makes me think of problems that exist when designing taxonomies in MOSS 2007.  Very similar problems exist.  The key that we've found in this area is "know thy audience!"  The great thing about SharePoint is that you have a concept of "audience types" - making it easier for a designer to get specific fast.  This is also similar to BI based taxonomy design - and the concepts of allowing navigation and discovery across many dimensions.  Some lessons learned from my perspective regarding the organization of information in SharePoint is that some forms of data are naturally hierarchical – and in those cases should be represented in a hierarchy – and some are better organized using multiple classifications so that they can be easily pivoted and cross referenced.  Classification systems are among the most powerful for many reasons – allowing you to represent unstructured information in much the same way you can represent related data in databases.

    What are the usage patterns of the current site?  How do people “actually” consume the information?  Why do they consume it?  I can tell you how I get to the information in MSDN – it’s through a search engine – from there I get placed in a reference hierarchy that I then navigate for more information.  So, what are people looking for when they get to your content?

    Here’s a concept that is way out there – what about using a data mining mindset.  Given a sample of information – data mining can derive patterns and predictions.  Can you make the site “learn” from the behavior of consumers – self adapt based on usage patterns, search strings, reference links, etc.    Perhaps trying to conceive structure isn’t what’s important here – its building an adaptive system.  Consider Google News (yup, sorry I said the word Google).  When I log into Google News (which I do all of the time because I get to see the news I want to see all of the time!!!) I get a “recommended” section – and Google does a great job at recommending articles that reflect my interest as a reader.  It does this, of course, by tracking what I read.  I also think about Amazon.com – I totally appreciate the “other books you might be interested in” section – this is totally done through data mining.  It didn’t do this by forcing me to subscribe to pre-canned categories.

    If it were up to me – I would take the Google News paradigm very seriously.  It works very well – its provides a bit of order over chaos – being Chaordic which is much more natural with regards to consumption.  Yet, it’s quite discrete and almost real-time.

  • Good changes so far, all in the right direction.

    Recomendation #1: The graphic is excellent, it should be part of the UI. Part of what made the MSF Agile UI engaging was the feeling (through the main sections anyway)  that you were navigating through something physical. And that's where I'd argue that a simulation _is_ what you should be aiming for. Only when you simulate the structure of the "true nature" of the corpus  can you really allow people to move through with least resistance and naturally satisfy the goals of developers who visit MSDN.  

    Your comment that the structure simulates the structure of DevDiv is bang-on and indicates a problem - that the structure best serves people who understand Microsoft's org chart. DevDiv product centers are responsible for creating much of MSDN's content, so it makes sense to create content according to those buckets. However when published in these buckets the structure creaks as new development evolves towards mash-ups.

    If I want to write a SharePoint-Silverlight-ASP.NET mash-up, I'd enter through the SharePoint door. The next guy might enter through the ASP.NET door. It should be easy for each of us to arrive at the same destination, and not require either of us to understand that someone from the SP&T Product Team is most likely to write such a thing (unless ScottGu had a spare evening last week, he's both nuts and great like that).

    Recommendation #2: Build the products (MSDN content) in spaces that can simulate both the org chart and cross-chart teams. Then publish the product into locations that make knowledge easy for people to navigate. This structure is usually a simulation of a mind map plus a few links at the surface to provide access to the frequently accessed links (FALs).

    Back to that graphic. How about building a mind map (either like your diagram, or a conventional mind map) as a CAD object with different views, and generate images representing (and placed on) each natural landing page on MSDN? Then I see my topic in the context of others, and I'm free to move to a different context. Or with Silverlight, let me manipulate that object to select a new context. When a new product ships, add it to it's natural space in the model and give it a color cue.

    Recommendation #3: Market without marketing. Heresy I know. But when I visit the Virtual Labs page, I don't see SharePoint anywhere. The next thing I look for is the non-branded translation that makes sense to me (Portals and Collaboration) but that's not there either. I do see two Microsoft headings and something called Office. What I really want to see is a taxonomy in plain English, even if this means there is more than one path to my content (workflow, reporting & analysis, portals & collaboration).

    When I actually click through to Office, I see end-user, administrator, and developer labs. The home page said I'd only find developer labs. So maybe the home page should have role-based headings too.

    How to implement? Taxonomy-based tags should work. Write once, publish to many. The underlying article or download ID doesn't change, but the content is accessible from many directions. Encoding metadata in the path is so 2002 and most of your assets have evolved accordingly, but I still see a few resources in the /sharepoint path. The problem is simply that the entry points and navigation still reflect either org chart or marketing channels.

    To drive that last point home. If I want to learn MOSS-specific development (e.g. workflow with InfoPath browser forms), I can go to msdn.com/sharepoint, and not see a recognizable link to either OSS, or to a parent node other than the top-level MSDN icon. Where will I go next? I'll visit a search engine (guess which one's still my default).

    Recommendation #4: Most people would rather navigate than search. I'm glad to see that MSFT search is improving. I still don't see a way to search community content from within MSDN, or to add an MSDN search provider to MSIE or Firefox (there is a 3rd party one for Firefox). Other search providers I'd like to see: MVP, Microsoft developer blogs. And though it's more a search team suggestion, let me mash up my search results by picking both MVP and MSDN search providers at once.

    And for a really cool useful twist, let people include graphics or simple diagrams in (moderated) comments and community content. Now there's a mash-up I'd love to see.

    -e.

  • Hi Rob,

    If I'm interpreting your graphic correctly, it does a nice job of capturing the major subject areas in a product-centric view of MSDN.

    Now that I've been a Microsoft customer instead of an employee for a couple of years, I'd also like to see a view that focuses on "Developer Needs" first and views everything else within that context.

    I love the idea of providing more context as a way to help navigate through the vast sea of MSDN content. Unfortunately, context changes rapidly. The things I care about on one search may be entirely differnt on the next search. It would be great to see your thoughts on what context information is needed, how to make it as easy as possible to capture and apply that context, and how to retrieve and re-use a set of context information later, once it's been captured.

    Dave Quick

  • Rob,

    I do like the way you are thinking.  The Begining Developer Learning Center do an excellent job of organizing the content.

    I am an old foggy, but I remember pre-Visual Studio 6, that the help was well organized and easily searchable.  If I had my preference, I would rather have things indexed so that I can quickly find what I need even if I don't know the exact name of what I am looking for.

    That being said, I do work often train our college grads who are overwhelmed with the content on MDSDN.  More sites like the last one in your post will help me immensely.

    :)  

  • There's a book by Christopher Alexander that talks about the concept of "centers." For example, a pond is a pond by the characteristics of its "center" not its edges. The edges between a pond and a plain, or a pond and woods is blurry. It's the centers of things that provide their nature.

    What that tells me about organization of entities is that you can have both major centers and minor centers. "Minor centers" is just another way to say that some concepts belong on the fuzzy edges, and if the manifestation is a web page, then you need a minor center to reflect that.

    Since there isn't a way to show the paths between the major centers in a web page, some other visual cue is necessary. That's where i think that a diagram (but not just a tree view, it's really a web view) could help navigation.

  • Rob,

    I think you are on the right track too.

    I use Google to search for stuff and have learned to tweak the search strings so they work better. This gets me to MSDN a ton of the time.

    Its hard to wade thru MSDN to find stuff. Specially when whoever builds it messes up the architecture.

    Today i find myself using codeplex or the google search mentioned to find stuff. Then if it gets me to MSDN, great.

    As for MSDN, i think a simpler architecture would be better. When i go there, i already know i want to find say VSTS. So give me one place to start and make it simple to navigate from there to the next.

    Ken

  • For dealing with complexity of a different sort - enterprise architectures - see Roger Sessions' new

  • Hi Rob,

    If you enjoyed the book 'The Laws of Simplicity (Simplicity: Design, Technology, Business, Life)' you love my book 'Hyperinnovation: Multidimensional Enterprise in the Connected Economy,' which concentrates on similar issues, and builds a new and ‘holistic’ management model for managing complex ‘multidimensional’ systems innovations at a faster pace.

    A review, the table of contents, and excerpt of Hyperinnovation can be found via my blog: www.chrisharrisfutures.blogspot.com.

    I hope that you find this of interest and assistance.

    Best regards,

    Chris Harris.

  • While reading the comments on Sam Gentile 's post, What's Great about Being a Microsoft Developer , I

  • PingBack from http://msdnrss.thecoderblogs.com/2007/06/12/the-greatest-story-never-told/

  • Earlier this year ( Managing Complexity ) I blogged about John Maeda's book, The Laws of Simplicity (Simplicity:

  • Earlier this year ( Managing Complexity ) I blogged about John Maeda's book, The Laws of Simplicity

Page 1 of 1 (14 items)
Leave a Comment
  • Please add 8 and 3 and type the answer here:
  • Post