Hacker News new | ask | show | jobs
by danfernandez 3703 days ago
[Disclosure: I work for the team that built docs.microsoft.com]

Thanks for the feedback, and we went through a lot of customer feedback already on this. I'll try to be brief in a response

- A good example on why - For our documentation we clearly saw customers jumping around content trying to find the part of the article that helps them. Depending on the article (see point #2) very few people read from beginning to end. A good example here is that instead of having separate articles on how to setup iOS, Android and Windows phone devices with Intune, the previous articles had that as part of a much later article. If an admin who's company has standardized on Android, they want just the Android content, they don't want to have to sift through iOS/Windows troubleshooting to get to the Android setup content. For SEO, it's also much more likely that they'll find the solution by Googling (with or without Bing) to something like "Setup Intune Android" and go directly to the page that takes care of just that task. For developers, we face the same problem where some articles include multiple langauges and code samples are duplicated. Instead of doing that, we would break the article into pieces by language.

- Another key reason is not all content is built the same. We'd get feedback that many of our competitors have a much simpler "Getting Started" tutorial, while ours would be much longer and we'd get feedback that it seems more complex or overwhelming. When you are just starting off, "Hello World" is a lot better than War & Peace. It's about thinking about the right level of content for the task our customers are going through. In some cases, it's fine to have one long article.

- We will also provide the option for customers to have all content together versus having content broken into separate pieces and made available for offline. Customers want both.

- The reason we called this out is that the previous architecture doesn't not even have this as a capability.

I hope this helps give some context on the decision and thanks for the feedback.

3 comments

One thing I beg of you:

Don't break links to old versions of documents!

(I realise this requires building a redirect forest. But we're talking 20 years of MS documentation.)

[Also MS employee that works on the docs.microsoft.com team]

No, we will not break links. We are doing graceful redirects from MSDN/TechNet to the new site.

Thanks for that. I have come to expect all MSDN links to rot almost immediately, and it'll be nice to see that stop happening.
How about building in a direct way to report errors and issues with the docs that actually is fixed and checked? You can't even get a working MIM 2016 AD sync setup right now with the numerous errors in your docs (https://docs.microsoft.com/en-us/microsoft-identity-manager/...).

It's frustrating to say the least and I'd prefer we not even deploy the product.

> For our documentation we clearly saw customers jumping around content trying to find the part of the article that helps them.

Isn't that what anchor tags are for? You can share them in URLs...