NVDA Settings Documentation
Does such exist?
When reviewing the User Guide (at least what I've been able to find) there is very little to nothing regarding a number of NVDA settings, what they do, and how they change interaction with "the real world" things NVDA's working with. One example is the Maximum Characters per line setting in Browse settings. I can find absolutely nothing that clearly documents what that setting does or what changing it will do to NVDA's behavior. I have to presume that there is a document that would go, panel by panel, and setting-by-setting, through these and what they do. But if such exists, I really don't know where it is. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Hi, Generally, the newer the setting, it is better documented in the user guide. For example, consider the just mentioned setting in browse mode panel versus touch interaction panel – the former is an old setting, while the latter is a recent section (bonus: I wrote the touch interaction section apart from a bit on toggling touch interaction with a keyboard command). The user guide as currently stands has limitations, including covering only the basic scenarios. Part of the reason why I produced Welcome to NVDA tutorial series (2013, 2015, 2018) was due to personal frustrations with the NVDA user guide. The biggest frustration is the issue Brian mentioned: lack of real-life scenarios. This is why when you listen to (or watch video) tutorials, you’ll notice more real-life examples being presented, and I believe that’s one of the strengths of NV Access’s own basic training material as well. One idea I briefly considered was producing the fourth edition of Welcome to NVDA series this year but shelved it, knowing that there are folks who can produce better tutorial sets, along with the fact that NV Access has a basic training material now. But if there is a really strong demand for it, I’ll revisit this idea next year, with a possibility that the fourth edition will be the last Welcome to NVDA set I produce. Cheers, Joseph
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian Vogel
Sent: Sunday, October 18, 2020 9:35 AM To: nvda@nvda.groups.io Subject: [nvda] NVDA Settings Documentation
Does such exist? Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Joseph,
While I applaud your efforts, and tutorials are invaluable, I wasn't even going that far. I'm talking basic documentation, where each item in a panel/pane/settings group in a given pane are briefly documented. There are myriad NVDA settings that, if their actual function is not directly obvious, which is the case, for example, with most checkboxes, then they're a black hole. Even I will admit that for all software it is a limited number of end users who refer to this sort of thing. That being said, some do, and it serves as a very important basis for new developers to develop depth of knowledge of "what's in there and what it's for." I was just commenting to someone for whom I've done custom VBA scripting for Outlook that I am eternally grateful to myself for having developed the habit of rigorously commenting my code, at a bare minimum, as even I would have no idea what some of what I've written actually does when looking at it much later. Complex stuff doesn't remain in "off the top of my head" mode (for most "mes") as time moves on. That's one of the reasons that basic documentation is so important. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Hi, Agreed (that’s one of the reasons why I comment a lot in my add-on source code). One holiday wish I have (possibly a long-term wish) is to help folks get started on revamping the NVDA community documentation. At least this can include add-on user guides, but I foresee a day where the screen reader user guide would not escape this rewrite in hopes of making it more relevant for users. I would go so far as ask NVDA code contributors to add extensive documentation in source code itself – it is now possible to do it easily with help from a module called Sphinx, a source code based documentation generator. There are major issues to consider, however:
My responses to the above questions are:
Another wish I have, mostly for Quentin: can we develop some sort of a training program for would-be contributors wishing to improve the overall NVDA community documentation, including the user guide? It may include basics on technical writing, tone and style, audience analysis, exercises where coding and documentation should be done together, and documentation production in a variety of formats (including online media). I think this may help us dive deeper into user guide issues being brought up, including the guide being “too thick” for newbies (in terms of understanding, lack of solid examples, and friendliness), especially for preferences chapter. Cheers, Joseph
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian Vogel
Sent: Sunday, October 18, 2020 11:56 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation
Joseph, Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Joseph,
First, in reference to your final comment, there are different levels of documentation for end users, too. All user guides I've ever seen, and I say this as a tech geek, are "too thick/too information dense" for newbies, but they're really not meant as getting started guides, either. Hence the rise of the getting started guide, which is really focused on just that, as well as, oftentimes, an intermediate guide that hacks out of the full user guide the things that most users use most of the time, and tweaking as needed. There is no way that I've ever seen that one can create documentation that is really useful for newbies, versus average somewhat sophisticated users, versus those who are willing and able to do "deep dives under the hood." As to the mindset of code contributors, and I speak from general experience of many years in software development, you are going to have to be able to discuss your software with someone who knows next to nothing about how it works and do so such that they can understand what you're saying. Coders take specifications (or often they do) which are minimum requirements, and often more, and translate those into working code. You very often have to go back and forth with the specification writers, who have back and forth with end users requesting something, and often both on the front end, and then after the code is written, if you're not writing the documentation yourself, with the technical writers who are tasked with producing same. It is, and always has been, a myth that coders can live in a coding-only bubble and not have to interact with those outside that bubble about anything. And some of the biggest problems in the industry as a whole are the direct result of trying to create that artificial bubble that have failed, and repeatedly, before most organizations clue in to the concept that computer people do have to have people skills and be willing to use them. A spectacular coder who cannot communicate about what they're producing to others is worth less, in any organization I've been in, than a good coder who can communicate with ease with all other stakeholders about what they're producing. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Robert Doc Wright godfearer
toggle quoted messageShow quoted text
Where I need direction on what I need to study in
order to be a tech writer for NVDA. I believe that once I understand something I
can teach it to anyone. My stumbling block is that I have had some programming
classes but that was twenty years ago. I taught myself basic web design from a
book. What do I need to know to be of help where the users guide is
concerned?
******
Jesus says, follow me and I'll help you through the rough spots. the world says, hey come with me. My way is broad and easy. So what if you get crap on your shoes. You can always wash it off, can't you! Or ask your A device to play Family times on tuneIn You can also find us on your mobile device install OoTunes and search for Family times
----- Original Message -----
From: Joseph
Lee
Sent: Sunday, October 18, 2020 1:45 PM
Subject: Re: [nvda] NVDA Settings Documentation Hi, Agreed (that’s one of the reasons why I comment a lot in my add-on source code). One holiday wish I have (possibly a long-term wish) is to help folks get started on revamping the NVDA community documentation. At least this can include add-on user guides, but I foresee a day where the screen reader user guide would not escape this rewrite in hopes of making it more relevant for users. I would go so far as ask NVDA code contributors to add extensive documentation in source code itself – it is now possible to do it easily with help from a module called Sphinx, a source code based documentation generator. There are major issues to consider, however:
My responses to the above questions are:
Another wish I have, mostly for Quentin: can we develop some sort of a training program for would-be contributors wishing to improve the overall NVDA community documentation, including the user guide? It may include basics on technical writing, tone and style, audience analysis, exercises where coding and documentation should be done together, and documentation production in a variety of formats (including online media). I think this may help us dive deeper into user guide issues being brought up, including the guide being “too thick” for newbies (in terms of understanding, lack of solid examples, and friendliness), especially for preferences chapter. Cheers, Joseph
From: nvda@nvda.groups.io <nvda@nvda.groups.io>
On Behalf Of Brian Vogel
Joseph, Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Quentin Christensen
Hi everyone, Lots of good points here. So firstly, from a very simplistic view - if there are any settings which experienced people such as yourselves can't get an explanation of from the User Guide, then that's definitely something we should address. Please either let me know (or file a GitHub issue) as you find examples. Re the user guide being too thick and heavy for new users to get start with - that's largely because that's not who it is really aimed at. For a lot of users, the Basic Training for NVDA would be the best place to start. There is potentially a gap for a short "quick start" guide, and I'd be happy to explore that further with anyone who has ideas on the subject. Joseph, re some sort of training for new contributors - that too is a great idea, and I'd be happy to work further with you on it. I've made a note to follow all of this up (since it's into the evening here and I'm trying to figure out book week costumes while getting the kids to bed).
On Mon, Oct 19, 2020 at 10:44 AM Robert Doc Wright godfearer <godfearer@...> wrote:
--
Quentin Christensen Training and Support Manager Training: https://www.nvaccess.org/shop/ Certification: https://certification.nvaccess.org/ User group: https://nvda.groups.io/g/nvda Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess
|
|
Gene
I haven't looked at the user guide a lot. However, I found yesterday, regarding the line length documentation this:
toggle quoted messageShow quoted text
12.1.14. Browse Mode (NVDA+control+b) The Browse Mode category in the NVDA Settings dialog is used to configure NVDA's behaviour when you read and navigate complex documents such as web pages. This category contains the following options: Maximum Number of Characters on One Line This field sets the maximum length of a line in browse mode (in characters). That's true but how many people would understand where it might be useful? I found the same feature useful in JAWS years ago becaused when I moved from line to line manually, the lines as displayed were too long to find something conveniently. I wanted lines shorter so I could skim by line much faster and more efficiently. There are two things that come to mind: When browse mode is discussed earlier, should the section that shows the settings with explanation be referenced as a further information or see also, or for settings, see or something of the sort? Also, is this section and some other parts of the user guide intended for those who already have an idea of how such settings might be used in general or for a more advanced user who may either understand the information or play around and see what the effect is of settings information that isn't clear. Manuals, in my experience are usually concise and I think that is one reason tutorials are so much more popular. But the degree of concision may be opened to useful discussion. Gene
-----Original Message-----
From: Quentin Christensen Sent: Monday, October 19, 2020 4:01 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation Hi everyone, Lots of good points here. So firstly, from a very simplistic view - if there are any settings which experienced people such as yourselves can't get an explanation of from the User Guide, then that's definitely something we should address. Please either let me know (or file a GitHub issue) as you find examples. Re the user guide being too thick and heavy for new users to get start with - that's largely because that's not who it is really aimed at. For a lot of users, the Basic Training for NVDA would be the best place to start. There is potentially a gap for a short "quick start" guide, and I'd be happy to explore that further with anyone who has ideas on the subject. Joseph, re some sort of training for new contributors - that too is a great idea, and I'd be happy to work further with you on it. I've made a note to follow all of this up (since it's into the evening here and I'm trying to figure out book week costumes while getting the kids to bed). On Mon, Oct 19, 2020 at 10:44 AM Robert Doc Wright godfearer <godfearer@...> wrote: Where I need direction on what I need to study in order to be a tech writer for NVDA. I believe that once I understand something I can teach it to anyone. My stumbling block is that I have had some programming classes but that was twenty years ago. I taught myself basic web design from a book. What do I need to know to be of help where the users guide is concerned? ****** Jesus says, follow me and I'll help you through the rough spots. the world says, hey come with me. My way is broad and easy. So what if you get crap on your shoes. You can always wash it off, can't you! Family times where there is fun for every ear! http://stream.wrighthere.net:8000/stream.mp3 Or ask your A device to play Family times on tuneIn You can also find us on your mobile device install OoTunes and search for Family times ----- Original Message ----- From: Joseph Lee To: nvda@nvda.groups.io Sent: Sunday, October 18, 2020 1:45 PM Subject: Re: [nvda] NVDA Settings Documentation Hi, Agreed (that’s one of the reasons why I comment a lot in my add-on source code). One holiday wish I have (possibly a long-term wish) is to help folks get started on revamping the NVDA community documentation. At least this can include add-on user guides, but I foresee a day where the screen reader user guide would not escape this rewrite in hopes of making it more relevant for users. I would go so far as ask NVDA code contributors to add extensive documentation in source code itself – it is now possible to do it easily with help from a module called Sphinx, a source code based documentation generator. There are major issues to consider, however: Who is the target audience: thinking about this changes the game, as it will dictate tone, style, word usage, and organization of the document and supplemental materials. Mindset of code contributors: are we just software developers or technical authors? Some people would argue that developers should focus on programming and testing, leaving the task of documenting what developers wrote to technical authors, and this separation of concerns may foster better communication amongst team members. On the other hand, by forcing developers to become technical authors, they can make crucial decisions about the user-visible aspects of a given product a bit early. How can we show we accept diversity in terms of culture, language, skill level, and other factors: although the community documentation was written by NV Access people at first, it is increasingly written by people from diverse backgrounds in terms of culture, language, skill level, and other factors (although I did receive training on technical communication and software development, I’m not a native English speaker). This is more so for parts that are written by people who may have different interpretation about a UI message or concepts, more so if the author’s native language is not English (the reverse is true for translators as they need to grasp concepts written in English in their native languages). My responses to the above questions are: Who is the target audience: it varies. For NVDA user guide, it is users with differing skill levels. For add-on guides, they target end users. For this reason, whenever I edit the NVDA user guide or add-on guides, I think about what users expect and NVDA’s response. This changes if we’re dealing with a document meant for developers (such as add-on internals and such). Mindset of code contributors: I believe that, as much as programming skills is important, willingness to communicate with audiences (users, other contributors, industry experts, etc.) is also important. One way to practice both is thinking and writing to and about users, therefore I tend to fall into a bit of the latter category from above: programming is, in one way or another, writing. Python is just one of the more specialized languages used to communicate with another entity (the machine), and if one can teach a computer to do something (along with fixing mistakes), it would be possible to train developers to respect users more by writing good documentation (of course someone may need to look at the documentation for style and such). My philosophy partly stems from my experiences as a former computer science major at a college I attended (different from the one I’m about to graduate from): my first computer science professor stressed the importance of source code comments and documentation, and I still practice this lesson today, which fuels my overall frustration with the current state of NVDA user guide and source code documentation in general. I think one exercise code contributors can do before submitting anything to GitHub (specifically, pull; requests) is writing an early user facing documentation, because doing so helps you improve your writing skills and think carefully about the impact of your changes when users meet them (I sometimes find myself struggling for minutes to hours over UI messages and documentation for this reason; I know what my code will do, but I hit a roadblock when explaining what I’ve done to would-be users before actually writing code). How can we show we are a group of people coming from diverse backgrounds: I think this goal was somewhat achieved when we look at recent NVDA work – many new features and bug fixes included in NVDA 2020.3 were written by someone other than an NV Access staff member, from people living in different countries and speaking many languages. But I know that we can improve on that somehow. Another wish I have, mostly for Quentin: can we develop some sort of a training program for would-be contributors wishing to improve the overall NVDA community documentation, including the user guide? It may include basics on technical writing, tone and style, audience analysis, exercises where coding and documentation should be done together, and documentation production in a variety of formats (including online media). I think this may help us dive deeper into user guide issues being brought up, including the guide being “too thick” for newbies (in terms of understanding, lack of solid examples, and friendliness), especially for preferences chapter. Cheers, Joseph From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian Vogel Sent: Sunday, October 18, 2020 11:56 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation Joseph, While I applaud your efforts, and tutorials are invaluable, I wasn't even going that far. I'm talking basic documentation, where each item in a panel/pane/settings group in a given pane are briefly documented. There are myriad NVDA settings that, if their actual function is not directly obvious, which is the case, for example, with most checkboxes, then they're a black hole. Even I will admit that for all software it is a limited number of end users who refer to this sort of thing. That being said, some do, and it serves as a very important basis for new developers to develop depth of knowledge of "what's in there and what it's for." I was just commenting to someone for whom I've done custom VBA scripting for Outlook that I am eternally grateful to myself for having developed the habit of rigorously commenting my code, at a bare minimum, as even I would have no idea what some of what I've written actually does when looking at it much later. Complex stuff doesn't remain in "off the top of my head" mode (for most "mes") as time moves on. That's one of the reasons that basic documentation is so important. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn -- Quentin Christensen Training and Support Manager Web: www.nvaccess.org Training: https://www.nvaccess.org/shop/ Certification: https://certification.nvaccess.org/ User group: https://nvda.groups.io/g/nvda Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess
|
|
Quentin Christensen
I think having the maximum number of characters per line setting described where it is in the browse mode settings section is fine - where the previous section 6 covers Browse mode in general, the settings section covers how to change the behaviour of different aspects. So for that setting particularly, currently the user guide simply offers: "Maximum Number of Characters on One Line This field sets the maximum length of a line in browse mode (in characters)." I guess when working out where best to add information, what would you suggest needs adding? That seems to describe the feature to me, but maybe I am too familiar with it to see what is missing? If anything more was needed on that, I'd be inclined to consider covering it in more depth in the "Basic Training for NVDA" module moreso than the user guide.
On Mon, Oct 19, 2020 at 8:14 PM Gene <gsasner@...> wrote: I haven't looked at the user guide a lot. However, I found yesterday, --
Quentin Christensen Training and Support Manager Training: https://www.nvaccess.org/shop/ Certification: https://certification.nvaccess.org/ User group: https://nvda.groups.io/g/nvda Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess
|
|
Quentin,
Here's some input in the form of questions. What constitutes a line? Does the maximum number of characters result in truncation and, if so, under what reading conditions? (I can't imagine this setting affects read all behavior, for instance). If a line (after defined) is longer than that maximum, what happens when that occurs during browse mode? -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Gene
It might be a good idea to add that when moving by line in a web page looking for something, the user might want to make the lines shorter so that you don't have to listen to long lines of text to make sure you haven't missed the information when you move to another line.
toggle quoted messageShow quoted text
-----Original Message-----
From: Quentin Christensen Sent: Monday, October 19, 2020 6:37 PM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation I think having the maximum number of characters per line setting described where it is in the browse mode settings section is fine - where the previous section 6 covers Browse mode in general, the settings section covers how to change the behaviour of different aspects. So for that setting particularly, currently the user guide simply offers: "Maximum Number of Characters on One Line This field sets the maximum length of a line in browse mode (in characters)." I guess when working out where best to add information, what would you suggest needs adding? That seems to describe the feature to me, but maybe I am too familiar with it to see what is missing? If anything more was needed on that, I'd be inclined to consider covering it in more depth in the "Basic Training for NVDA" module moreso than the user guide. On Mon, Oct 19, 2020 at 8:14 PM Gene <gsasner@...> wrote: I haven't looked at the user guide a lot. However, I found yesterday, regarding the line length documentation this: 12.1.14. Browse Mode (NVDA+control+b) The Browse Mode category in the NVDA Settings dialog is used to configure NVDA's behaviour when you read and navigate complex documents such as web pages. This category contains the following options: Maximum Number of Characters on One Line This field sets the maximum length of a line in browse mode (in characters). That's true but how many people would understand where it might be useful? I found the same feature useful in JAWS years ago becaused when I moved from line to line manually, the lines as displayed were too long to find something conveniently. I wanted lines shorter so I could skim by line much faster and more efficiently. There are two things that come to mind: When browse mode is discussed earlier, should the section that shows the settings with explanation be referenced as a further information or see also, or for settings, see or something of the sort? Also, is this section and some other parts of the user guide intended for those who already have an idea of how such settings might be used in general or for a more advanced user who may either understand the information or play around and see what the effect is of settings information that isn't clear. Manuals, in my experience are usually concise and I think that is one reason tutorials are so much more popular. But the degree of concision may be opened to useful discussion. Gene -----Original Message----- From: Quentin Christensen Sent: Monday, October 19, 2020 4:01 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation Hi everyone, Lots of good points here. So firstly, from a very simplistic view - if there are any settings which experienced people such as yourselves can't get an explanation of from the User Guide, then that's definitely something we should address. Please either let me know (or file a GitHub issue) as you find examples. Re the user guide being too thick and heavy for new users to get start with - that's largely because that's not who it is really aimed at. For a lot of users, the Basic Training for NVDA would be the best place to start. There is potentially a gap for a short "quick start" guide, and I'd be happy to explore that further with anyone who has ideas on the subject. Joseph, re some sort of training for new contributors - that too is a great idea, and I'd be happy to work further with you on it. I've made a note to follow all of this up (since it's into the evening here and I'm trying to figure out book week costumes while getting the kids to bed). On Mon, Oct 19, 2020 at 10:44 AM Robert Doc Wright godfearer <godfearer@...> wrote: Where I need direction on what I need to study in order to be a tech writer for NVDA. I believe that once I understand something I can teach it to anyone. My stumbling block is that I have had some programming classes but that was twenty years ago. I taught myself basic web design from a book. What do I need to know to be of help where the users guide is concerned? ****** Jesus says, follow me and I'll help you through the rough spots. the world says, hey come with me. My way is broad and easy. So what if you get crap on your shoes. You can always wash it off, can't you! Family times where there is fun for every ear! http://stream.wrighthere.net:8000/stream.mp3 Or ask your A device to play Family times on tuneIn You can also find us on your mobile device install OoTunes and search for Family times ----- Original Message ----- From: Joseph Lee To: nvda@nvda.groups.io Sent: Sunday, October 18, 2020 1:45 PM Subject: Re: [nvda] NVDA Settings Documentation Hi, Agreed (that’s one of the reasons why I comment a lot in my add-on source code). One holiday wish I have (possibly a long-term wish) is to help folks get started on revamping the NVDA community documentation. At least this can include add-on user guides, but I foresee a day where the screen reader user guide would not escape this rewrite in hopes of making it more relevant for users. I would go so far as ask NVDA code contributors to add extensive documentation in source code itself – it is now possible to do it easily with help from a module called Sphinx, a source code based documentation generator. There are major issues to consider, however: Who is the target audience: thinking about this changes the game, as it will dictate tone, style, word usage, and organization of the document and supplemental materials. Mindset of code contributors: are we just software developers or technical authors? Some people would argue that developers should focus on programming and testing, leaving the task of documenting what developers wrote to technical authors, and this separation of concerns may foster better communication amongst team members. On the other hand, by forcing developers to become technical authors, they can make crucial decisions about the user-visible aspects of a given product a bit early. How can we show we accept diversity in terms of culture, language, skill level, and other factors: although the community documentation was written by NV Access people at first, it is increasingly written by people from diverse backgrounds in terms of culture, language, skill level, and other factors (although I did receive training on technical communication and software development, I’m not a native English speaker). This is more so for parts that are written by people who may have different interpretation about a UI message or concepts, more so if the author’s native language is not English (the reverse is true for translators as they need to grasp concepts written in English in their native languages). My responses to the above questions are: Who is the target audience: it varies. For NVDA user guide, it is users with differing skill levels. For add-on guides, they target end users. For this reason, whenever I edit the NVDA user guide or add-on guides, I think about what users expect and NVDA’s response. This changes if we’re dealing with a document meant for developers (such as add-on internals and such). Mindset of code contributors: I believe that, as much as programming skills is important, willingness to communicate with audiences (users, other contributors, industry experts, etc.) is also important. One way to practice both is thinking and writing to and about users, therefore I tend to fall into a bit of the latter category from above: programming is, in one way or another, writing. Python is just one of the more specialized languages used to communicate with another entity (the machine), and if one can teach a computer to do something (along with fixing mistakes), it would be possible to train developers to respect users more by writing good documentation (of course someone may need to look at the documentation for style and such). My philosophy partly stems from my experiences as a former computer science major at a college I attended (different from the one I’m about to graduate from): my first computer science professor stressed the importance of source code comments and documentation, and I still practice this lesson today, which fuels my overall frustration with the current state of NVDA user guide and source code documentation in general. I think one exercise code contributors can do before submitting anything to GitHub (specifically, pull; requests) is writing an early user facing documentation, because doing so helps you improve your writing skills and think carefully about the impact of your changes when users meet them (I sometimes find myself struggling for minutes to hours over UI messages and documentation for this reason; I know what my code will do, but I hit a roadblock when explaining what I’ve done to would-be users before actually writing code). How can we show we are a group of people coming from diverse backgrounds: I think this goal was somewhat achieved when we look at recent NVDA work – many new features and bug fixes included in NVDA 2020.3 were written by someone other than an NV Access staff member, from people living in different countries and speaking many languages. But I know that we can improve on that somehow. Another wish I have, mostly for Quentin: can we develop some sort of a training program for would-be contributors wishing to improve the overall NVDA community documentation, including the user guide? It may include basics on technical writing, tone and style, audience analysis, exercises where coding and documentation should be done together, and documentation production in a variety of formats (including online media). I think this may help us dive deeper into user guide issues being brought up, including the guide being “too thick” for newbies (in terms of understanding, lack of solid examples, and friendliness), especially for preferences chapter. Cheers, Joseph From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian Vogel Sent: Sunday, October 18, 2020 11:56 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation Joseph, While I applaud your efforts, and tutorials are invaluable, I wasn't even going that far. I'm talking basic documentation, where each item in a panel/pane/settings group in a given pane are briefly documented. There are myriad NVDA settings that, if their actual function is not directly obvious, which is the case, for example, with most checkboxes, then they're a black hole. Even I will admit that for all software it is a limited number of end users who refer to this sort of thing. That being said, some do, and it serves as a very important basis for new developers to develop depth of knowledge of "what's in there and what it's for." I was just commenting to someone for whom I've done custom VBA scripting for Outlook that I am eternally grateful to myself for having developed the habit of rigorously commenting my code, at a bare minimum, as even I would have no idea what some of what I've written actually does when looking at it much later. Complex stuff doesn't remain in "off the top of my head" mode (for most "mes") as time moves on. That's one of the reasons that basic documentation is so important. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn -- Quentin Christensen Training and Support Manager Web: www.nvaccess.org Training: https://www.nvaccess.org/shop/ Certification: https://certification.nvaccess.org/ User group: https://nvda.groups.io/g/nvda Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess -- Quentin Christensen Training and Support Manager Web: www.nvaccess.org Training: https://www.nvaccess.org/shop/ Certification: https://certification.nvaccess.org/ User group: https://nvda.groups.io/g/nvda Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess
|
|
Gene
There is no truncating. I worked with the feature in JAWS years ago. I don't remember the line length in JAWS, if it was the same, longer or shorter than in NVDA, both using default settings. The point of it is that the MSAA buffer needs to have a line length set. the underlying page has none and the line length is determined by how much will fit on the screen being used unless the page designer has placed line codes on the page, which they usually don't. So you can set the length of a line you hear when you up and down arrow on a page.
toggle quoted messageShow quoted text
If I am looking for something on a page and I want to be able to move quickly from line to line listening to a bit and then moving on, I may want shorter lines than the default so I can quickly move by line and when I'm close to what I'm looking for, slow down. If lines are too long, I may miss what I'm looking for because it may be near the ende of a long line and I may move down before hearing it. Others may have other uses. That is the use I made of the feature. I set the line length to be shorter and left it there so I could move quickly from line to line and not have too much on a line to prevent easy skimming. Gene
-----Original Message-----
From: Brian Vogel Sent: Monday, October 19, 2020 6:45 PM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation Quentin, Here's some input in the form of questions. What constitutes a line? Does the maximum number of characters result in truncation and, if so, under what reading conditions? (I can't imagine this setting affects read all behavior, for instance). If a line (after defined) is longer than that maximum, what happens when that occurs during browse mode? -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Gene,
Interesting. And nothing I ever, in a million years, would have "read in" to this setting. It sounds like it's a way to break up text into segments a maximum of X characters long, at most. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Gene
I would compare it to Word Wrap in Notepad except that you define the number of characters before the wrap occurs. I think the comparison is especially apt to Notepad because you can write as long a line as you wish in Notepad but the wrap makes it manageable on-screen.
toggle quoted messageShow quoted text
Gene
-----Original Message-----
From: Brian Vogel Sent: Monday, October 19, 2020 7:38 PM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation Gene, Interesting. And nothing I ever, in a million years, would have "read in" to this setting. It sounds like it's a way to break up text into segments a maximum of X characters long, at most. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Hi all, <snip I guess when working out where best to add information, what would you suggest needs adding? That seems to describe the feature to me, but maybe I am too familiar with it to see what is missing? PL] When would I want to alter this setting?
Pranav
|
|
On Mon, Oct 19, 2020 at 10:32 PM, Gene wrote:
I would compare it to Word Wrap in Notepad except that you define the number of characters before the wrap occurs.- Gene, that is a good analogy. But what I want to know is what "reading command context(s)" this has an effect on. I'm imagining only line-by-line reading, but . . . Having something under the setting such as, "If a document has a line longer than the number of characters you set, for line reading it will be split into multiple virtual lines of the maximum length you specify." I also wonder if it's intelligent as far as splitting at word boundaries, not hard and fast character counts. Mid-word splits would make things potentially very ugly. That setting, naked as it is, is not something that's intuitive, clearly, just based on this topic. And I'm not saying that you're arguing that it is, just restating the need for some context regarding settings where the effect of same is in no way immediately obvious to the uninitiated (and even the initiated, much later on). -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Gene
We'll see what others say but I know it applies to moving by lines. If I do something else that causes a line to be read, such as move by screen, with page up or down, or move to beginning or end of a document or tab, I would think it would apply in all those contexts, but we'll see what others say.
toggle quoted messageShow quoted text
The intelligent question is a very interesting one and One I haven't thought of. Based on my experience, I don't recall ever having words split when I read in browse mode and the document has no such splitting, I think it is intelligent. Just how much of such discussions should be in the user guide depends on what the purpose of the guide is. Perhaps some of these stipulations should be in some sort of document for developers or a wiki rather than in a user guide. I wonder if this or that effect of a command my not be considered when discussing it by those who really know details. A wiki might be a good way to address this. I just found this very interesting discrepancy: If I set the line length to a short amount, moving using k to move by link will cause an entire link to be read, no matter how long. Moving by arrow or tab and shift tab, will cause the line length stipulated to be read with more of the link being read as I move in the link. Its an interesting discrepancy and one I wonder if those knowledgeable in the matter have given any thought about as to implementation and what is desirable. Gene
-----Original Message-----
From: Brian Vogel Sent: Tuesday, October 20, 2020 10:53 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation On Mon, Oct 19, 2020 at 10:32 PM, Gene wrote: I would compare it to Word Wrap in Notepad except that you define the number of characters before the wrap occurs.- Gene, that is a good analogy. But what I want to know is what "reading command context(s)" this has an effect on. I'm imagining only line-by-line reading, but . . . Having something under the setting such as, "If a document has a line longer than the number of characters you set, for line reading it will be split into multiple virtual lines of the maximum length you specify." I also wonder if it's intelligent as far as splitting at word boundaries, not hard and fast character counts. Mid-word splits would make things potentially very ugly. That setting, naked as it is, is not something that's intuitive, clearly, just based on this topic. And I'm not saying that you're arguing that it is, just restating the need for some context regarding settings where the effect of same is in no way immediately obvious to the uninitiated (and even the initiated, much later on). -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Hi,
toggle quoted messageShow quoted text
Had to dig into C++ part of NvDA to figure this out: This setting sets browse mode line length, so yes, it applies to when reading by line. Specifically, based on what I can tell, it will do its best to break at word boundaries. This is one of the reasons why links can "span" across multiple lines in browse mode. In terms of documenting this, one way to improve this is taking Brian's suggestions into account: expand that section and give practical examples, like the following: This field sets the maximum length of a line in browse mode (in characters) for reading by line purposes. Unlike documents in programs such as Word and Notepad, browse mode documents do not have a specific line length or a new line character to denote ends of lines. Because of this, you can set arbitrary line lengths between 10 and 250 characters, and NVDA will try to split lines at word boundaries. A side effect of this setting is that links and other elements will be split onto multiple browse mode lines. I'm sure we can make it better, but at least the one I wrote above might be a useful starting point and captures the discussion so far. Cheers, Joseph
-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Gene Sent: Tuesday, October 20, 2020 9:23 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation We'll see what others say but I know it applies to moving by lines. If I do something else that causes a line to be read, such as move by screen, with page up or down, or move to beginning or end of a document or tab, I would think it would apply in all those contexts, but we'll see what others say. The intelligent question is a very interesting one and One I haven't thought of. Based on my experience, I don't recall ever having words split when I read in browse mode and the document has no such splitting, I think it is intelligent. Just how much of such discussions should be in the user guide depends on what the purpose of the guide is. Perhaps some of these stipulations should be in some sort of document for developers or a wiki rather than in a user guide. I wonder if this or that effect of a command my not be considered when discussing it by those who really know details. A wiki might be a good way to address this. I just found this very interesting discrepancy: If I set the line length to a short amount, moving using k to move by link will cause an entire link to be read, no matter how long. Moving by arrow or tab and shift tab, will cause the line length stipulated to be read with more of the link being read as I move in the link. Its an interesting discrepancy and one I wonder if those knowledgeable in the matter have given any thought about as to implementation and what is desirable. Gene -----Original Message----- From: Brian Vogel Sent: Tuesday, October 20, 2020 10:53 AM To: nvda@nvda.groups.io Subject: Re: [nvda] NVDA Settings Documentation On Mon, Oct 19, 2020 at 10:32 PM, Gene wrote: I would compare it to Word Wrap in Notepad except that you define the number of characters before the wrap occurs.- Gene, that is a good analogy. But what I want to know is what "reading command context(s)" this has an effect on. I'm imagining only line-by-line reading, but . . . Having something under the setting such as, "If a document has a line longer than the number of characters you set, for line reading it will be split into multiple virtual lines of the maximum length you specify." I also wonder if it's intelligent as far as splitting at word boundaries, not hard and fast character counts. Mid-word splits would make things potentially very ugly. That setting, naked as it is, is not something that's intuitive, clearly, just based on this topic. And I'm not saying that you're arguing that it is, just restating the need for some context regarding settings where the effect of same is in no way immediately obvious to the uninitiated (and even the initiated, much later on). -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Gene,
There's definitely intelligence being displayed in relation to links, at the very least. It would be disastrous to split links in virtually any context I can think of. They really are an atomic unit. -- Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041 It’s hard waking up and realizing it’s not always black and white. ~ Kelley Boorn
|
|
Dave Grossoehme
Good |Day: This brings a question to mind on this setting. Would that work for a line in Word, if wrap is turned on? Which a line of text that continues to wrap.
toggle quoted messageShow quoted text
Dave
On 10/19/2020 2:14 AM, Gene wrote:
I haven't looked at the user guide a lot. However, I found yesterday, regarding the line length documentation this:
|
|