Read next

5 comments

• Michael Taylor

  September 23, 2021 9:19 am

  Sorry but this is a step backwards in my opinion. Imagine that you have just arrived in a foreign country and are trying to find your way around. There is a sign with a large set of options on it. The first option is about getting directions. The rest of the options are related to checking your travel account, reading about recent updates to the station, privacy policies and the weather outside. All useful information unto themselves but to someone just needing help it is completely overwhelming.

  In my opinion the goal of the help menu should be to be as small as possible so the focus is on exactly what the help menu is for – help. Anything that you might want to add to that menu should at best be a submenu. For example My Subscription and Register Visual Studio are competing to me. If I have a subscription I don’t need to register. If I register I might or might not have a subscription. Wouldn’t a simple submenu that combines them be better?

  Same with all that new stuff in the middle – check for updates, release notes. If I just installed VS for the very first time I have the latest version and if I’ve never used VS before I don’t care about the release notes either. Why is this taking up 3+ menu items rather than just being consolidated or in a submenu?

  So I believe this is a radical step backwards as someone who teaches people new to VS. It is overwhelming to someone who just needs help.

  Log in to Reply

• Joe Woodbury

  September 23, 2021 12:10 pm

  Why does a one-time action–“Register Visual Studio”–take up residence in a menu?

  Log in to Reply

• cs

  September 23, 2021 10:30 pm

  More focus should be on making it easier to acquire and consume help.

  Offline help needs improvement for these obvious reasons.

  * lack of access to the internet
  * to reduce bandwidth usage
  * to stop wasted developer time acquiring/organizing offline help (often repeated by different developers)
  * to allow “reading” off device (i.e. printed)

  But docs.microsoft.com makes that difficult:

  * only “pdf” versions of a “docset” that docs have chosen to be “Download PDF” are able to be quickly downloaded for offline
  – for anything else you have to manually go through each node and “print” that nodes page…a time consuming process

  * it’s not possible to go to any “folder/group” in the tree and print or download its children
  e.g. If I want to read up on the “NET CLI” (https://docs.microsoft.com/en-gb/dotnet/core/tools/) and get ALL the collection of “pages” related to that section I can’t quickly

  * it would be nice if a “download” of a “set of pages” could be done as separate entities i.e. 1 file per “page” rather than one big PDF – i.e. use the “filename/filesystem” as a “cheap” way to index pages

  * provide the ability to “download” topics/pages as .MD files instead (after all that’s the source of the help in github after all) – so that someone can use an .MD viewer to read it instead.

  * the formatting of the pdf is suboptimal i.e.
  – you get a huge “Contents” preamble, but no page numbers/references are used…thus a physically printed copy is impossible to navigate
  – the formatting makes paper printing wasteful e.g. lots of wasted space, and “section titles” are to big, and also use a “filled blue background”…which means lots of wasted ink / paper
  – it assumes/relies on being a digital pdf for navigation (i.e. click on item in contents to navigate to it)….there is no “index” at the bottom like a “book”.

  Acquiring help:

  * reduce developer time wasted (in various ways) i.e.
  – multiple developers downloading the same help all the time
  * provide the ability to snapshot offline sets of help documentation in an efficient/repeatable way e.g. via scripting
  “historical/stable”
  * “Download PDF” assigns a “guid” as the filename….so the first thing one has to do is choose one’s own scheme / way of naming the help that has just been downloaded……causes inconsistency and possible duplication of download

  Formatting/Indexing/Search:

  * needs improvement….relies too much on “the web” as the indexer……..it’s too noisey, and not focussed enough…..and as PDF’s relies on the PDF viewer…..which is too basic
  * if one has installed certain Workloads in Visual Studio then ALL searching should be specific to only those workloads and/or temporarily focus to specific workloads.

  The problem with docs.microsoft.com is that it can change at any time, it’s possible to for links to die, that entire doc sets are “archived” or not even be archived – people like stability. Look back at what happened with the old MSDN docs sites and the old Microsoft Blogs sites – whole “important” articles lost or hard to find/discover now, and “comments” lost, and whole sections “archived” off.

  Log in to Reply

  • Ian Marteens

    September 24, 2021 2:38 am

    I totally agree.

    Log in to Reply

• Larry Smith

  September 25, 2021 7:17 am

  For me, I would like to see better integration of the code analysis “Errors, Warnings, Messages” codes. All to often they are not linked to any actual Help content, but take you to a web search result of the code. I’m now forced to read various (contrary, incorrect, or speculation on what caused the analyzer to produce the code) old and out of date responses.

  If it was deemed important enough for a rule to be created for an analyzer then the code rule author (team) should also be required to produce the companion help artifact that should be delivered along with the rule.

  This is important for two reasons. First it shows that you have concrete evidence and a solution for the rule. Secondly its provides a quick intentional response to a developer to keep them on track.

  Can’t say how may times these search results have wasted 20-30 minutes and did not provide a adequate resolution. (Not to mention that brilliant glimpse of an idea I did have 30 minutes ago has now completly vanished.)

  Log in to Reply