GNOME Bugzilla – Bug 608688
Some suggestions for filling forms UI
Last modified: 2018-05-22 13:47:11 UTC
This is a modest and not strict suggestions list. Use it at your own. when editing a field * current behavior changes the entry displayed typography, which could be right for me, but entry text place get moved too, which is ugly at least; I suggest to use the same typography when editing and viewing; a rounded frame, a graphic baseline, a colored background or another graphic resource could be used to let clear the user she is currently editing a field. * when <esc> is pressed the spected behavior is to left the edition of the current field with content unmodified; the present behavior seems to lose the mouse focus and left the UI state to limbo * would not be the <tab> key spected to jump to the next form field? * in the same sense, it would not be spected to jump to next field when the current has been finished after an <enter> key? * pressing <alt><a> selects the whole page, as a non editing use, instead of the text of the current field. * when a field is a readymade selection list, now is impossible to navigate through it without the mouse, IMHO would be expected to be able of using cursor keys; probably this could be considered as a a11y bug too. saving/loaded filled forms: * it's not clear is possible to save a filled form with the user entered data * when saving, evince doesn't open the current directory where the original pdf is; I feel a user would like to either: o save on the original pdf file o save beside it; in this case maybe Evince could suggests to name it as original-filename-instanced.pdf opposite to original-filename.pdf Probably the best approach is to use to different GUI's: the current for reading documents and a second one for filling the forms. To switch between modes could be needed only a [Edit form] flag/button, as OpenOffice has.
(In reply to comment #0) > This is a modest and not strict suggestions list. Use it at your own. I think different issues should be filed in different bug reports. I added a dependency to related bugs to keep track of any of them by separate and leaving this one as a meta-bug. Other comments below: > when editing a field > > * current behavior changes the entry displayed typography, which could be > right for me, but entry text place get moved too, which is ugly at least; I > suggest to use the same typography when editing and viewing; a rounded frame, a > graphic baseline, a colored background or another graphic resource could be > used to let clear the user she is currently editing a field. See https://bugzilla.gnome.org/show_bug.cgi?id=699858 > * when <esc> is pressed the spected behavior is to left the edition of the > current field with content unmodified; the present behavior seems to lose the > mouse focus and left the UI state to limbo See https://bugzilla.gnome.org/show_bug.cgi?id=699857 > * would not be the <tab> key spected to jump to the next form field? > * in the same sense, it would not be spected to jump to next field when the > current has been finished after an <enter> key? See https://bugzilla.gnome.org/show_bug.cgi?id=503706 and https://bugzilla.gnome.org/show_bug.cgi?id=699857 > * pressing <alt><a> selects the whole page, as a non editing use, instead > of the text of the current field. Fixed in https://bugzilla.gnome.org/show_bug.cgi?id=699630 > * when a field is a readymade selection list, now is impossible to navigate > through it without the mouse, IMHO would be expected to be able of using cursor > keys; probably this could be considered as a a11y bug too. I did not understand this one. > saving/loaded filled forms: > > * it's not clear is possible to save a filled form with the user entered > data > * when saving, evince doesn't open the current directory where the original > pdf is; I feel a user would like to either: > o save on the original pdf file > o save beside it; in this case maybe Evince could suggests to name it > as original-filename-instanced.pdf opposite to original-filename.pdf I am not sure about this one. The current behaviour is to open the dialog in the last located used to save a copy. I think it makes sense to detect if a form has been modified and present the save dialog in the same location of the form. However, what if evince was opened right after downloading a form from the web? > Probably the best approach is to use to different GUI's: the current for > reading documents and a second one for filling the forms. To switch between > modes could be needed only a [Edit form] flag/button, as OpenOffice has. This seems like a workaround for Evince.
>> * when a field is a readymade selection list, now is impossible to navigate >> through it without the mouse, IMHO would be expected to be able of using cursor >> keys; probably this could be considered as a a11y bug too. > I did not understand this one. In html terms, he says evince users cannot choose from drop-down boxes using only the keyboard. Most web browsers – both TUI and GUI – permit to use of the UP and DOWN cursor keys to navigate w/in the menu once such a box is chosen, just like when navigating the program’s own menus. Fixing that, if it hasn’t already been fixed in git, would be welcome.
(In reply to comment #1) > (In reply to comment #0) > > This is a modest and not strict suggestions list. Use it at your own. > > I think different issues should be filed in different bug reports. I added a > dependency to related bugs to keep track of any of them by separate and leaving > this one as a meta-bug. thanks for taking the time for making this report something developer useful :-D > > saving/loaded filled forms: > > > > * it's not clear is possible to save a filled form with the user entered > > data > > * when saving, evince doesn't open the current directory where the original > > pdf is; I feel a user would like to either: > > o save on the original pdf file > > o save beside it; in this case maybe Evince could suggests to name it > > as original-filename-instanced.pdf opposite to original-filename.pdf > > I am not sure about this one. The current behaviour is to open the dialog in > the last located used to save a copy. Maybe it has changed. If my report here is not accurate please discard it. > I think it makes sense to detect if a form has been modified and present the > save dialog in the same location of the form. However, what if evince was > opened right after downloading a form from the web? if it's open just downloaded the current behavior would probably be to offer putting the instanced form in ~/Downloads, which seems to me fine. if the document is open by evince directly from an URL, that is: not after dowloaded as Firefox or Chrome do, then it should offer to put it at $HOME. No problem here. > > > Probably the best approach is to use to different GUI's: the current for > > reading documents and a second one for filling the forms. To switch between > > modes could be needed only a [Edit form] flag/button, as OpenOffice has. > > This seems like a workaround for Evince. This is just a suggestion. The important thing is the user should be aware she can save the instanced form (a newbie probably can't imagine it's possible) AND the filled form can be reloaded again. This warning is more important from free Acrobat users who never saw this feature before :-D
(In reply to comment #2) > In html terms, he says evince users cannot choose from drop-down boxes using > only the keyboard. Most web browsers – both TUI and GUI – permit to use of the > UP and DOWN cursor keys to navigate w/in the menu once such a box is chosen, > just like when navigating the program’s own menus. > > Fixing that, if it hasn’t already been fixed in git, would be welcome. +1
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/134.