As updates are published to the Manager Guide(s); it would be helpful to have a synopsis showing where those updates have been made in the document. There are multiple ways to accomplish that!
guides are updated when there are major changes or new features added. the changes or addition is notified in the Releases page.
Iām aware of that; but Iām suggesting a description of the document change be identified in the document itself. In October, there were 9 or so updates, and it would be helpful to have all of that contained in the document itself; otherwise, the reader is going back and forth from release page to the PDF document to understand the updates.
More so, that link in the āreleaseā notification just āboomerangsā the reader back to the forum thread, where the reader has to sort through the message replies. IMO of courseā¦ā¦.
a guide is just like a user manual you get with other products. seldom do you find features and how to operate instructions about an older version of the product in the user manual. it will only confuse new users and is totally unnecessary for them.
1 Like
@anon5385611, this would be less practical and useful than you may think. Many Guides have been modified dozens of times, one over 130. Admittedly, the links on the Releases page typically take you to a former bug report or idea. But the intent is not that you bounce back and forth between those and a Guide that may be affected. Nor is there always just one Guide affected. According to the newsletter, there was a single change last year that affected 75 or so Guides.
In my opinion, the more useful links are the Learn how toā¦ links at the bottom of virtually every screen in the program. They list contextually relevant Guides. It matters little what a Guide used to say for a different version of the program.
1 Like
@sharpdrivetek Seldom do we see a program with this magnitude of continuous change updates as Manager.
Addressing the comprehensive master user guide (PDF). Not recommending āwhat a guide used to say for a different version of the programā vs. āhas to say for the current version of the programā. IMO veteran users would benefit greatly by understanding specifically where in the program/guide the changes were made in the current program/guide. New users, on the other hand are unaffected by voluminous prior changes; as their focus is on the current program.
Using September as an example, I doubt seriously most that users updated their program 18 times during September(some of which are de-minimis to specific users, and others major); but as some point the user does need to catch up with a cumulative download update, and thatās one more example of where a āstreamlined approachā to understanding the cumulative program changes is most beneficial.
It is not clear what you mean by this, @anon5385611. If you are referring to updates of the program, all updates are cumulative. Every new version changes only a relatively small portion of the code. There are never total redesigns of the program. If you are referring to updates of the Guides, there is also never a complete rewrite of some master book. The Guides are designed and written as standalone articles. The PDF version of the Guides only compiles all those individual articles into a single file. It was added because some users around the world have unreliable internet access and had trouble accessing the Guides from links in the program. The idea was to allow them to download a reference they could use when offline.
I doubt this. In the majority of cases, annotating the most recent change would be irrelevant, as the user probably would not have looked at the previous version. Nor, in many cases, would they have looked at any of the prior versions, of which there could be dozens.
Iāll stick with my earlier comment. Knowing what changed in a Guide is not very useful. What matters is what the Guide tells you about how to use the current version of the program. When a user has a question about whatever portion of the program they are using, the concept is that they can link directly to Guides that are relevant and have all necessary instruction right there. They need not know whether that Guide was revised three times over the course of a day as aspects of a new feature were worked out in response to feedback from early adopters. Nor would they care if a Guide had remained unchanged for years (as a few have).
I think you are looking at this from the wrong end of the situation. The real question to ask is why you expect any change to a Guide at all just because a new version of the program was released. Those links on the Releases page are not meant to point to definitive explanations of anything. Thatās what the Guides are for. Those links on the Releases page mostly draw attention to relevant discussion topics for those that participated in them. Often, there is no such link related to a Guide change.
In most cases, bug fixes do not result in Guide changes, because the Guide already explains how the program was supposed to work. (Most bugs are revealed by unusual circumstances not revealed in initial testing.) New features usually generate brand new Guides, not changes to old ones, so there would be no annotations. The truth is, most Guide changes result from perceived confusion, as revealed by usersā questions on the forum. There is no expectation that users will flock to them to see what is new. Rather, the hope is that the next time someone comes looking for information, the presentation will be a little more effective.
1 Like
@Tut Thank you for the time you spent in very lengthy reply; however, WADR you are quoting out of context and missing the point entirely.
VR
Please enlighten me. What am I missing? What value would you derive from annotations of changes to Guides? What benefits would you get from tracing obsolete instructions that you would miss by reading up to date ones? Why consider instructions for features no longer in the program?