I'd like to start a discussion on how keyboard shortcuts are implemented in the staff client so that going forward developers can be working according to the same playbook. Right now there are two different kinds of keyboard shortcuts: - shortcuts via the accesskey attribute - shortcuts via a jQuery plugin, hotkeys (http://code.google.com/p/js-hotkeys/). (Please note that this was recently updated in HEAD and the syntax has changed). The advantage of the accesskey method is of course that it's not javascript-dependent. The disadvantage is that different browsers handle accesskeys differently, a combination of keys is usually required (Alt+ or Ctrl+Alt+), and not all keys or key combinations will be available (for instance, because of conflicts with built-in browser shortcuts). The advantage of the javascript method is that it is possible to configure single-key shortcuts, although I think different browsers will still retain their shortcuts. Try this demo page: http://jshotkeys.googlepages.com/test-static-01.html. Currently the core set of accesskeys are "u" for Check Out, "r" for Check In, and "q" for Search. The javascript-based match for these is "Alt-u," "Alt-r," and "Alt-q." Darrell Ulm just submitted a patch that would add "F12" to the list of js-based shortcuts, used for printing a circ slip. Ideally our goal would be to provide shortcuts via accesskeys wherever possible, and supplement the accesskey method with javascript-based shortcuts. However, this limits us to keys which are valid for the accesskey method. Going forward, how should we choose the default keyboard shortcuts? Should we attempt to fall back on accesskeys? If no, should we expand the use of js-based keyboard shortcuts? Eager for opinions, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
It seems like you are also talking about two different types of shortcut keys, global keys and context keys. For example the current accesskeys are global. No matter where you are in koha, they work. The new functionality for F12 looks like it only works in circulation. There's no reason F12 could not do a related function in other parts of Koha. For instance, print an invoice or a workslip in acquisitions, print out a routing slip in serials, or print out a check-in slip if items are being checked-in and the patron requests it. Maybe for the global keys we could continue using the accesskeys, but use function keys (js) for the context sensitive functionality. On Tue, Jul 14, 2009 at 3:35 PM, Owen Leonard<oleonard@myacpl.org> wrote:
I'd like to start a discussion on how keyboard shortcuts are implemented in the staff client so that going forward developers can be working according to the same playbook. Right now there are two different kinds of keyboard shortcuts:
- shortcuts via the accesskey attribute - shortcuts via a jQuery plugin, hotkeys (http://code.google.com/p/js-hotkeys/). (Please note that this was recently updated in HEAD and the syntax has changed).
The advantage of the accesskey method is of course that it's not javascript-dependent. The disadvantage is that different browsers handle accesskeys differently, a combination of keys is usually required (Alt+ or Ctrl+Alt+), and not all keys or key combinations will be available (for instance, because of conflicts with built-in browser shortcuts).
The advantage of the javascript method is that it is possible to configure single-key shortcuts, although I think different browsers will still retain their shortcuts. Try this demo page: http://jshotkeys.googlepages.com/test-static-01.html.
Currently the core set of accesskeys are "u" for Check Out, "r" for Check In, and "q" for Search. The javascript-based match for these is "Alt-u," "Alt-r," and "Alt-q." Darrell Ulm just submitted a patch that would add "F12" to the list of js-based shortcuts, used for printing a circ slip.
Ideally our goal would be to provide shortcuts via accesskeys wherever possible, and supplement the accesskey method with javascript-based shortcuts. However, this limits us to keys which are valid for the accesskey method.
Going forward, how should we choose the default keyboard shortcuts?
Should we attempt to fall back on accesskeys? If no, should we expand the use of js-based keyboard shortcuts?
Eager for opinions,
Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi, On Tue, Jul 14, 2009 at 3:35 PM, Owen Leonard<oleonard@myacpl.org> wrote:
Currently the core set of accesskeys are "u" for Check Out, "r" for Check In, and "q" for Search. The javascript-based match for these is "Alt-u," "Alt-r," and "Alt-q." Darrell Ulm just submitted a patch that would add "F12" to the list of js-based shortcuts, used for printing a circ slip.
Trying to bind single function keys doesn't seem to work well enough - for example, when I tested Darrell's patch on my MacBook, the browser was not able to capture F12, whereas binding Alt-F12 would have worked.
Should we attempt to fall back on accesskeys? If no, should we expand the use of js-based keyboard shortcuts?
I think whatever we do, we shouldn't hard-code the specific key bindings or scatter the bindings across multiple templates. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
Galen Charlton <galen.charlton@...> writes:
I think whatever we do, we shouldn't hard-code the specific key bindings or scatter the bindings across multiple templates.
Right, simple is good. I wondered about the F12 myself! _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
Owen Leonard <oleonard@myacpl.org> wrote:
The advantage of the accesskey method is of course that it's not javascript-dependent. The disadvantage is that different browsers handle accesskeys differently, a combination of keys is usually required (Alt+ or Ctrl+Alt+), and not all keys or key combinations will be available (for instance, because of conflicts with built-in browser shortcuts).
The advantage of the javascript method is that it is possible to configure single-key shortcuts, although I think different browsers will still retain their shortcuts. Try this demo page: http://jshotkeys.googlepages.com/test-static-01.html.
Why would accesskeys conflict with built-in browser shortcuts? Isn't the point of different browsers handling accesskeys differently that they pick a shift that doesn't conflict with their built-ins? It seems to me that the javascript method is the one which may conflict with built-in browser shortcuts on some browsers. But I guess at the moment, we only have a few javascript interpreters which work correctly in the librarian pages? If I've understood this right, I think we should attempt to fall back on accesskeys because they shouldn't conflict. Hope that helps, -- MJ Ray (slef) LMS developer and webmaster at | software www.software.coop http://mjr.towers.org.uk | .... co Notice http://mjr.towers.org.uk/email.html | .... op
not all keys or key combinations will be available (for instance, because of conflicts with built-in browser shortcuts).
Why would accesskeys conflict with built-in browser shortcuts?
I simply mean that we can't choose from the full array of possible keys because some keys will already be mapped to default browser functions. For instance, in Safari 4 for Windows the accesskey combination is Alt+letter. I can't choose Alt+F for use in Koha because Safari reserves Alt+F for accessing the file menu.
Isn't the point of different browsers handling accesskeys differently that they pick a shift that doesn't conflict with their built-ins?
I guess not! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Owen Leonard <oleonard@myacpl.org> wrote:
[I asked... please keep attributions]
Why would accesskeys conflict with built-in browser shortcuts?
I simply mean that we can't choose from the full array of possible keys because some keys will already be mapped to default browser functions. For instance, in Safari 4 for Windows the accesskey combination is Alt+letter. I can't choose Alt+F for use in Koha because Safari reserves Alt+F for accessing the file menu.
Well, that's wrong and means Safari doesn't support access keys according to the html specification. Or so I thought... see http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey but the "for instance" surprises me - I thought Windows generally used "alt" to open menus and Apple used "cmd" for menu shortcuts? Anyway, can Safari pass http://www.w3.org/WAI/UA/TS/html401/cp0101/0101-ACCESSKEY-BUTTON.html#test1 or select entry "F" on http://www.w3.org/WAI/GL/tests/accesskey3.html ? Confused but unsurprised, -- MJ Ray (slef) LMS developer and webmaster at | software www.software.coop http://mjr.towers.org.uk | .... co Notice http://mjr.towers.org.uk/email.html | .... op
Anyway, can Safari pass http://www.w3.org/WAI/UA/TS/html401/cp0101/0101-ACCESSKEY-BUTTON.html#test1 or select entry "F" on http://www.w3.org/WAI/GL/tests/accesskey3.html
Safari 4 for Windows can pass the accesskey test, and it can select entry "F" in that list *as long as the focus is on the body of the page* rather than, say, the location bar. Typing Alt-D fails either way, triggering instead the focus of the location bar.
Confused but unsurprised,
And so will our users be if we're not careful of these issues. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Owen Leonard <oleonard@...> writes:
Going forward, how should we choose the default keyboard shortcuts?
Should we attempt to fall back on accesskeys? If no, should we expand the use of js-based keyboard shortcuts?
The ideal solution is to employ a simple keyboard shortcut map interface. Of course there could be defaults, but the admin may change settings. This is a good way to do it because it makes everyone happy regardless of their key preference. Speaking of preferences.... :) One way to do this is another category of SysPrefs. Why would one need another interface when the SYSpref can certainly handle it. Check-Out [F1] <--use can set to whatever Check-In [F2] Then again, every database access is more time. Seems like these would be cached in short order. Sys Prefs are used to determine functionality elsewhere. Darrell Ulm _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
participants (5)
-
Darrell Ulm -
Galen Charlton -
Garry Collum -
MJ Ray -
Owen Leonard