Length of the document formatting dialog #6348

Closed
feerrenrut opened this Issue Sep 6, 2016 · 9 comments

Comments

Projects
None yet
5 participants
@feerrenrut
Contributor

feerrenrut commented Sep 6, 2016

Feedback on GUI, received via email, with respect to the Document formatting dialog.

The document formatting dialog is a very long dialog. may wish to consider a bit of a column layout with two columns of options after the first one which is longer and would sit on its own line. the other checkboxes could be grouped in different groups that make sense? just a thought.

document formatting settings

@feerrenrut feerrenrut added the NVDA GUI label Sep 6, 2016

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Sep 6, 2016

Contributor

I tend to agree that this dialog looks a bit off. Having a large list of checkbox options makes them hard to find. Some suggestions (not necessarily all compatible) I can think of for this would be:

  • to group similar options EG (font name, font size, font attributes and line numbers, line indentation, line spacing and table stuff) but split these up into multiple columns as already suggested.
  • try a multi list dialog (as used for instance in some IDEs). Enabled options are in one list, disabled options in another. The lists are allow you to type the first few characters of the item you are looking for. Pressing space toggles the option between lists. There are buttons in between the two lists for 'Enable All', 'Enable selected / Disable selected', 'Disable all'. Honestly I tend to think this looks a little ugly, but its fairly effective. This could perhaps be made more attractive by getting rid of the buttons.
  • Use grouped checkboxes, but have a section that shows those that are enabled, and allows you to disable them.

See also: http://ux.stackexchange.com/questions/23142/what-do-you-do-when-you-have-too-many-choices-in-a-checkbox-field-set

Contributor

feerrenrut commented Sep 6, 2016

I tend to agree that this dialog looks a bit off. Having a large list of checkbox options makes them hard to find. Some suggestions (not necessarily all compatible) I can think of for this would be:

  • to group similar options EG (font name, font size, font attributes and line numbers, line indentation, line spacing and table stuff) but split these up into multiple columns as already suggested.
  • try a multi list dialog (as used for instance in some IDEs). Enabled options are in one list, disabled options in another. The lists are allow you to type the first few characters of the item you are looking for. Pressing space toggles the option between lists. There are buttons in between the two lists for 'Enable All', 'Enable selected / Disable selected', 'Disable all'. Honestly I tend to think this looks a little ugly, but its fairly effective. This could perhaps be made more attractive by getting rid of the buttons.
  • Use grouped checkboxes, but have a section that shows those that are enabled, and allows you to disable them.

See also: http://ux.stackexchange.com/questions/23142/what-do-you-do-when-you-have-too-many-choices-in-a-checkbox-field-set

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Sep 6, 2016

Contributor

Yeah, this dialog really is quite horrible. For all of the check boxes in the form "Report x" (e.g. "Report font name"), I was thinking a scrollable list with checkable items might be better, except we could drop the "Report" prefix. However, there are two problems with this:

  1. While wx does have checkable list controls, they aren't accessible. However, I think we might be able to come up with a way we could subclass it to fix this.
  2. It means you can't get to the options with the existing accelerators and users have come to depend on these for quick changes. For example, "Report table row/column headers" is alt+e (because alt+t is already taken), but in a list, you can only type from the start. I guess we could implement our own key handling logic, but if we did this, the accelerators would not be discoverable.
Contributor

jcsteh commented Sep 6, 2016

Yeah, this dialog really is quite horrible. For all of the check boxes in the form "Report x" (e.g. "Report font name"), I was thinking a scrollable list with checkable items might be better, except we could drop the "Report" prefix. However, there are two problems with this:

  1. While wx does have checkable list controls, they aren't accessible. However, I think we might be able to come up with a way we could subclass it to fix this.
  2. It means you can't get to the options with the existing accelerators and users have come to depend on these for quick changes. For example, "Report table row/column headers" is alt+e (because alt+t is already taken), but in a list, you can only type from the start. I guess we could implement our own key handling logic, but if we did this, the accelerators would not be discoverable.
@nishimotz

This comment has been minimized.

Show comment
Hide comment
@nishimotz

nishimotz Sep 6, 2016

Contributor

Sometimes these items are inaccessible visually. see #6186

Contributor

nishimotz commented Sep 6, 2016

Sometimes these items are inaccessible visually. see #6186

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Sep 7, 2016

Contributor

In order to provide a quick and easy (and non disruptive) fix, the following is suggested:

  • Add some text at the start to describe dialog and what it does.
  • Try grouping similar options. Consider the difficulty of adding new options to these groups.
  • Make sure that the dialog can scroll if required.
  • Add text (at end of dialog) for "Announce formatting changes after the cursor" to describe what this does and move "Announce..." option below this, with a new shorter label.
Contributor

feerrenrut commented Sep 7, 2016

In order to provide a quick and easy (and non disruptive) fix, the following is suggested:

  • Add some text at the start to describe dialog and what it does.
  • Try grouping similar options. Consider the difficulty of adding new options to these groups.
  • Make sure that the dialog can scroll if required.
  • Add text (at end of dialog) for "Announce formatting changes after the cursor" to describe what this does and move "Announce..." option below this, with a new shorter label.

@feerrenrut feerrenrut self-assigned this Sep 20, 2016

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Sep 20, 2016

Contributor

I propose grouping the items in the following way:

Font

  • font name
  • font size
  • font attributes
  • emphasis
  • style
  • colors
  • alignment

Document information

  • comments
  • editor revisions
  • spelling errors

Pages and spacing

  • pages
  • line numbers
  • line indentation
  • paragraph indentation
  • line spacing

Table Information

  • tables
  • table row/column headers
  • table cell coordinates

Document features

  • headings
  • links
  • lists
  • block quotes
  • landmarks
  • frames
  • if clickable
Contributor

feerrenrut commented Sep 20, 2016

I propose grouping the items in the following way:

Font

  • font name
  • font size
  • font attributes
  • emphasis
  • style
  • colors
  • alignment

Document information

  • comments
  • editor revisions
  • spelling errors

Pages and spacing

  • pages
  • line numbers
  • line indentation
  • paragraph indentation
  • line spacing

Table Information

  • tables
  • table row/column headers
  • table cell coordinates

Document features

  • headings
  • links
  • lists
  • block quotes
  • landmarks
  • frames
  • if clickable
@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Sep 20, 2016

Contributor

The following text could be added to the start of the dialog to give some more context.

The following options control the level of detail for document formatting reported by NVDA.

Contributor

feerrenrut commented Sep 20, 2016

The following text could be added to the start of the dialog to give some more context.

The following options control the level of detail for document formatting reported by NVDA.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Sep 20, 2016

Contributor

I think alignment should be under Pages and spacing rather than Font.

Regarding the dialog caption, rather than "level of detail", maybe this?

The following options control the types of document formatting reported by NVDA.

Contributor

jcsteh commented Sep 20, 2016

I think alignment should be under Pages and spacing rather than Font.

Regarding the dialog caption, rather than "level of detail", maybe this?

The following options control the types of document formatting reported by NVDA.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Sep 20, 2016

Contributor

Some additional things to consider:

  • I'm happy with the group names except for "Document features". If we can't come up with another name, I think I'd even prefer just "Other" or something. I don't want it to seem like "Document features" is an NVDA "concept".
  • We can rename "if clickable" to just "clickable".
  • If we do have the group names, we can probably drop the "table" prefix from "cell coordinates" and "row/column headers".
Contributor

jcsteh commented Sep 20, 2016

Some additional things to consider:

  • I'm happy with the group names except for "Document features". If we can't come up with another name, I think I'd even prefer just "Other" or something. I don't want it to seem like "Document features" is an NVDA "concept".
  • We can rename "if clickable" to just "clickable".
  • If we do have the group names, we can probably drop the "table" prefix from "cell coordinates" and "row/column headers".
@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Sep 22, 2016

Collaborator

Some names.

Document control

report element specificity

Element types

Also note that report comments is now one of them. and there's an open
ticket for report graphics that should go here.

On 9/19/2016 11:21 PM, James Teh wrote:

Some additional things to consider:

  • I'm happy with the group names except for "Document features". If
    we can't come up with another name, I think I'd even prefer just
    "Other" or something. I don't want it to seem like "Document
    features" is an NVDA "concept".
  • We can rename "if clickable" to just "clickable".
  • If we do have the group names, we can probably drop the "table"
    prefix from "cell coordinates" and "row/column headers".


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6348 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGive4BPI5kx1dC12sLI3rkwbebRViUks5qr21tgaJpZM4J1tQ5.


Derek Riemer
  • Department of computer science, third year undergraduate student.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Member of Bridge Cu
  • Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu
Phone: (303) 906-2194

Collaborator

derekriemer commented Sep 22, 2016

Some names.

Document control

report element specificity

Element types

Also note that report comments is now one of them. and there's an open
ticket for report graphics that should go here.

On 9/19/2016 11:21 PM, James Teh wrote:

Some additional things to consider:

  • I'm happy with the group names except for "Document features". If
    we can't come up with another name, I think I'd even prefer just
    "Other" or something. I don't want it to seem like "Document
    features" is an NVDA "concept".
  • We can rename "if clickable" to just "clickable".
  • If we do have the group names, we can probably drop the "table"
    prefix from "cell coordinates" and "row/column headers".


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6348 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGive4BPI5kx1dC12sLI3rkwbebRViUks5qr21tgaJpZM4J1tQ5.


Derek Riemer
  • Department of computer science, third year undergraduate student.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Member of Bridge Cu
  • Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu
Phone: (303) 906-2194

feerrenrut added a commit that referenced this issue Sep 29, 2016

incubates #6402
For issue: #6348
Merge branch 'i6348-documentFormattingDialog' into next

Conflicts:
	source/gui/guiHelper.py
	source/gui/settingsDialogs.py
	user_docs/en/userGuide.t2t

@nvaccessAuto nvaccessAuto added this to the 2016.4 milestone Oct 13, 2016

feerrenrut added a commit that referenced this issue Oct 13, 2016

Update changes file for PR #6287, #6402, #6339
For PR #6287 - Various padding and alignment issues have been resolved. (#6317, #5548, #6342, #6343, #6349)
For PR #6402 - The document formatting dialog has been adjusted so that the contents scrolls. (#6348)
For PR #6339 - Adjusted the layout of the symbols pronunciation dialog so the full width of the dialog is used for the symbols list. (#6101)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment