Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements in 9.3. Add-ons Manager documentation #4540

Closed
nvaccessAuto opened this issue Oct 10, 2014 · 3 comments
Closed

Improvements in 9.3. Add-ons Manager documentation #4540

nvaccessAuto opened this issue Oct 10, 2014 · 3 comments

Comments

@nvaccessAuto
Copy link

Reported by blindbhavya on 2014-10-10 16:53
Following are suggestions for the 9.3. Add-ons Manager section of the User Guide
1 The Add-ons Manager, accessed by selecting Manage add-ons under Tools in the NVDA menu, allows you
A Perhaps, you could add the string of text ‘which can be’ and remove the comma before ‘accessed’ and perhaps replace ‘accessed’ with ‘launched’. (completely optional)
B You may want to add ‘...’ after ‘Manage Addons’
C You may want to add ‘the’ before ‘Tools’ and ‘submenu’ after ‘Tools’
2 even provide support for extra Braille displays or speech synthesizers.
AIf you think ‘even’ is not required you may remove it. (optional)
bSomething like ‘add or enhance support for applications that are otherwise inaccessible’ should be added.
C Perhaps, ‘extra’ may be replaced by ‘third party’ or ‘additional’ (completely optional)
3 A package name, version and author are shown
A ‘A’ should be replaced with ‘The’
B It should be stated that the author’s e-mail address is also present.
C If I am not wrong, then to be grammatically correct, ‘are’ should be replaced with ‘is’
4 Somewhere in the documentation it should be stated that to install add-ons successfully, NVDA must be running.
5 It should be documented that if a version of the add-on the user is attempting to install is already installed, NVDA will ask the user whether they want to update that version with the add-on currently being installed.
Hope I was clear and detailed enough
P.S. I filed another documentation related ticket, since I have quite a few suggestions for this section (out of which some definitely are completely optional).

@nvaccessAuto
Copy link
Author

Comment 1 by nvdakor (in reply to comment description) on 2014-10-10 17:24
Replying to blindbhavya:

1 The Add-ons Manager, accessed by selecting Manage add-ons under Tools in the NVDA menu, allows you

A Perhaps, you could add the string of text ‘which can be’ and remove the comma before ‘accessed’ and perhaps replace ‘accessed’ with ‘launched’. (completely optional)

In the context of this chapter, I think "accessed" is more appropriate, because launched may mean "open a new program or a module". In a way, Add-ons Manager opens a new window, but it is still part of nvda.exe.

B You may want to add ‘...’ after ‘Manage Addons’

That also would raise an issue about various preferences dialogs in chapter 8, so I think it's fine to leave it as is.

C You may want to add ‘the’ before ‘Tools’ and ‘submenu’ after ‘Tools’

Actually, the original text is correct (grammatically). Just because you have a menu item (or any noun) that indicates a singular doesn't mean the word "the" should be included, and in the context of this paragraph, it's fine (I believe).

2 even provide support for extra Braille displays or speech synthesizers.

AIf you think ‘even’ is not required you may remove it. (optional)

Not many users may realize that older braille display and synthesizer drivers were bundled as add-on packages, which some were integrated into NVDA core, so this wording shows that the user may wish to be informed about this fact.

bSomething like ‘add or enhance support for applications that are otherwise inaccessible’ should be added.

I agree - I'd reword it as:
... and even provides support for inaccessible parts of applications, braille displasy and synthesizers. ...

C Perhaps, ‘extra’ may be replaced by ‘third party’ or ‘additional’ (completely optional)

In my opinion, the original wording is fine and is better (I think) for translators.

3 A package name, version and author are shown

A ‘A’ should be replaced with ‘The’

I think a better wording might be:
... For each add-on, the name ...

B It should be stated that the author’s e-mail address is also present.

That's because of the way add-ons system looks up manifest information.

C If I am not wrong, then to be grammatically correct, ‘are’ should be replaced with ‘is’

Actually, "are" is correct, as it talks about multiple attributes of an add-on.

4 Somewhere in the documentation it should be stated that to install add-ons successfully, NVDA must be running.

Understand - it can be added in the paragraph about installation procedure.

5 It should be documented that if a version of the add-on the user is attempting to install is already installed, NVDA will ask the user whether they want to update that version with the add-on currently being installed.

That's a side note that might be useful.

Hope I was clear and detailed enough.

Yes.
One small suggestion if I may: in the world of technical writing such as writing user guides, people would be looking for conciseness of a document, not a masterpiece essay which obeys grammar rules. Thus it is fine to see some grammatical errors and word choice issues in technical documents such as user guide, as the aim of the document is to let the author take the back seat and bring the product to the center stage. In my opinion, it is okay to discuss suggestions for user guide changes, but we must remember that technical documentation, such as the matter discussed here and in other tickets should be examined from users' perspective (if users doesn't understand a product, then we didn't do a good job with writing). Another viewpoint is in terms of localization: there are features in English grammar and certain technical terms that might be hard for a Chinese user to understand, and there are settings in NVDA that needs to be explained differently to someone speaking Arabic such as right-to-left texts. In many cases (documentation, user interface and what not), someone speaking English fluently may notice something odd, but when viewed from someone speaking another language, it may make perfect sense (see tickets on word choice with user interface elements, as we had a thorough debate over there regarding this issue). Overall, we should not forget that NVDA documentation and other materials are used for marketing and for teaching purposes, so it's fine to make suggestions like these to make the documentation look more professional with users and localization in mind.
Thanks.

@nvaccessAuto
Copy link
Author

Comment 2 by blindbhavya on 2014-10-10 17:35
Hi.
I appreciate your comments and respect your opinion. I completely agree with your post, especially this one
One small suggestion if I may: in the world of technical writing such as writing user guides, people would be looking for conciseness of a document, not a masterpiece essay which obeys grammar rules.
The example given is thought provoking.
Also, while making suggestions like this, I will definitely try to think from a user's perspective.
On the whole, I really appreciate you for this one.
P.S. Sorry for any errors in the past concerning such tickets, I sincerely apologize, and admire and appreciate the work and effort being put in the development of NVDA. Please excuse me for those past mistakes, and I will try my best to be more ... can't find the right word... probably better.
Thanks!

@bhavyashah
Copy link

bhavyashah commented Aug 2, 2017

CC @josephsl Feel free to close this ticket, or incorporate any relevant suggestions into any existing documentation PR, or whatever else is necessary...

@josephsl josephsl closed this as completed Aug 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants