I know it _just_ launched but oh my god how do you launch such a slow site. I'm trying to load the "System.Drawing" API docs and Chrome inspector just shows a GET pending alongside a _lot_ of analytics and marketing calls being made. I waited to see how long it'd take, 30s to load the page: http://i.imgur.com/Z6y1ulSr.png
Anyway, ignoring the launch issues: My #1 annoyance with MSFT documentation is sub-classes being on a different page. If you want to call a DirectX method which takes 4 inputs, you need to open up a new tab for each of those inputs to see the possible values / etc. I hate it, very very much. I hope their new documentation doesn't have this issue, I'll check back again in a few weeks to see if I can actually load pages on this site.
Generally speaking, as I posted in another child comment in the same thread, this is the biggest let down of MS redesign of the last year and led to a huge backlash in a HN article that escapes me.
If your JS hangs my browser for static content, I avoid your page and recommend others do too. I doubt I am the only one!
As someone who works in IT and generally does not like opening pages with JS full on (yes, I am one of those NoScript uBlock elitists), it is insulting that almost no KB article or other main page will load without throwing an enable JS blanket.
It has been discussed here before. As an IT professional, the only system that upsets me more than Microsoft on this point is Symantec. I expect clean minimalist doc pages from system dev and anti-virus companies. I do not need fancy MVVM pages and tracking JS to know what you fixed in your latest bug release, thank you!
We don't have any announcement for this yet, but stay tuned on our blog and Twitter (@docsmsft). Feel free to also submit this piece of feedback here: https://msdocs.uservoice.com
A couple suggestions here... embed them in the docs on the site, I can't access gist, for example at work, so often have to reread, or use my phone to see them when referenced in blog posts, for example.
The second suggestion, would be to show (maybe under a tab/collapse) what imports one needs... I specifically remember learning C# when it first came out between books and using the cli compiler without benefit of VS, and had a beast of a time figuring out that an example with StringBuilder required System.Text, or some such be imported into my class file. It's something that always bugs me when I see snippets without a reference to the namespaces that are needed.
20 comments
[ 800 ms ] story [ 1533 ms ] threadAnyway, ignoring the launch issues: My #1 annoyance with MSFT documentation is sub-classes being on a different page. If you want to call a DirectX method which takes 4 inputs, you need to open up a new tab for each of those inputs to see the possible values / etc. I hate it, very very much. I hope their new documentation doesn't have this issue, I'll check back again in a few weeks to see if I can actually load pages on this site.
Generally speaking, as I posted in another child comment in the same thread, this is the biggest let down of MS redesign of the last year and led to a huge backlash in a HN article that escapes me.
If your JS hangs my browser for static content, I avoid your page and recommend others do too. I doubt I am the only one!
It has been discussed here before. As an IT professional, the only system that upsets me more than Microsoft on this point is Symantec. I expect clean minimalist doc pages from system dev and anti-virus companies. I do not need fancy MVVM pages and tracking JS to know what you fixed in your latest bug release, thank you!
I expect clean minimalist doc pages from system dev
You're in luck. The documents that are being discussed work without javascript enabled.
https://docs.microsoft.com/en-us/dotnet/core/api/index
Click on "System"
https://docs.microsoft.com/en-us/dotnet/core/api/System
Scroll down and click on "Array"
https://docs.microsoft.com/en-us/dotnet/core/api/system.arra...
Scroll down and click on "OverflowException"
https://docs.microsoft.com/en-us/dotnet/core/api/system.over...
etc... all without javascript.
Is there any change this will be available as an option for local documentation from VS? Sandcastle is a little dated.
The second suggestion, would be to show (maybe under a tab/collapse) what imports one needs... I specifically remember learning C# when it first came out between books and using the cli compiler without benefit of VS, and had a beast of a time figuring out that an example with StringBuilder required System.Text, or some such be imported into my class file. It's something that always bugs me when I see snippets without a reference to the namespaces that are needed.