Ticket #11017 (closed PLIP: fixed)
Tags MultiSelectionWidget w/scrollbar & checkboxes
Reported by: | rmattb | Owned by: | RMattB |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | User Experience and Interface | Version: | |
Keywords: | Cc: | plip-advisories@…, Matt.Barkau@… |
Description (last modified by rmattb) (diff)
Proposer: Matt Barkau (RMattB)
Seconder: David Glick
Motivation
Plone currently utilizes the MultiSelectionWidget listbox for selecting tags (aka categories, keywords, DC subject) to apply to a content item. However, when users add more tags to an existing item, they often inadvertently remove existing tags, due to not knowing or forgetting to use the control/command key. If a site contains more than 14 tags, users may not even see that other tags are already selected in the list below the box. Further discussion of this usability issue is in the Plone improvement ideas forum (currently ranked fifth).
Since tag lists tend to be long, using MultiSelectionWidget checkboxes (instead of listbox) for this purpose would render pages rather long since there is no scrollbar, impacting usability. HTML 4 offers no intuitive widget which combines the best of both approaches: a scrollbar and checkboxes.
Assumptions
Future versions of Plone do not already improve this widget. Plone will continue to include jQuery.
Proposal & Implementation
Since Plone includes jQuery, this PLIP proposes to improve the tags MultiSelectionWidget by adapting and maintaining a proven, GPL-compatible, accessible, and jQuery-based widget, which includes both a scrollbar and checkboxes. This approach strives to be the least-invasive change that will make the user experience intuitive.
Further suggestions are welcome, but based on a brief survey, one project appears to be a good starting point, with some refactoring for speed from a derivative project. Guidance from the community on implementation is much appreciated.
This PLIP focuses on the implementation of the MultiSelectionWidget for tags, but this may later also be useful for any other areas in Plone also currently using the MultiSelectionWidget listbox. For flexibility, this new widget could be registered in Plone as a new third variety of MultiSelectionWidget.
Deliverables
What code and documentation needs to be produced?
- A registerable javascript
- A page template for the new MultiSelectionWidget variety
- An update to the edit view’s Categorization fieldset template to use this new widget variety
Standard items:
- Unit tests & test buildout.cfg
- Localization: 3 new i18n fields (2 are help text, 1 is currently selected tags)
- Documentation: Existing UI has no on-page documentation (although maybe it should have). Oddly, the Plone 3 and 4 end-user documentation on this doesn’t mention use of the control/command key for multiselection, but the screenshot would change.
Risks
What are the risks of implementing this proposal? If jQuery Tools later provides a similar widget, this work will not have been needed, although I’m not sure of the likelihood of this due to jQuery Tools’ intentional minimalism.
What incompatibilities can it cause? Non-JavaScript failover would be to existing widget. Please advise of any other areas to consider.
Participants
Who is signed up to do the work? Matt Barkau, RMattB (collaboration welcomed)
Progress
Is any of the work done already? Not specifically implemented in Plone, but two variations on the functionality exist, linked above.
Should there be a proof of concept? A proof of concept will be the first step after discussion of this PLIP has reached consensus.
Attachments
Change History
comment:3 Changed 6 years ago by rmattb
- Description modified (diff)
- Summary changed from Categories MultiSelectionWidget w/scrollbar & checkboxes to Tags MultiSelectionWidget w/scrollbar & checkboxes
comment:9 Changed 6 years ago by ldr
Approved in principle, assuming we avoid adding a JQuery-UI dependency.
comment:10 Changed 6 years ago by rmattb
Correct - the seed projects mentioned above use jQuery, but not jQuery UI.
comment:13 Changed 6 years ago by rmattb
comment:15 Changed 6 years ago by rmattb
comment:16 Changed 6 years ago by rmattb
comment:18 Changed 5 years ago by rmattb
Per esteele, checked approaches used in plone.app.collection's querywidget and found that the LaViska & Richmond work (mentioned above) includes almost all of those approaches & many more, except for the practice or wrapping the selector in definition list tags (recommended for name:value semantics in HTML5). (This PLIP's widget may be a bit heavy for use in plone.app.collection's querywidget.)
I'll include definition list tags in this PLIP.
comment:19 Changed 5 years ago by rmattb
As of revision 13132, the new basic widget is operational (although not pretty). Remaining are: refactoring text & css out of the LaViska & Richmond js, styling, some nice-to-have features, and some nice-to-have non-functional optimizations.
comment:20 Changed 5 years ago by rmattb
comment:21 Changed 5 years ago by rmattb
comment:22 Changed 5 years ago by rmattb
comment:23 follow-up: ↓ 24 Changed 5 years ago by rmattb
Demo screencast: http://www.youtube.com/watch?v=Yz_zhfkPPOw
comment:24 in reply to: ↑ 23 Changed 5 years ago by rmattb
Replying to rmattb: Apparently YouTube doesn't like audio in QuickTime 10 screen recordings. Please visit this new file (with narration!) at http://www.youtube.com/watch?v=jjT09c9PF8M
comment:25 Changed 5 years ago by rmattb
A few enhancements remain: better keyboard nav, search as you type, and selected tag list item removal.
comment:26 follow-up: ↓ 27 Changed 5 years ago by rmattb
Researched available extensions for search as you type / autocomplete functionality:
- Current LaViska & Richmond js supports searches for the first character of tags.
- jQuery Plugins/Autocomplete supports that and also searches for the first characters (plural) of tags.
- FCBKcomplete v 1.09 supports that and also searches within tags (& only for consecutive characters, as it should), but is not GPL.
- jQuery UI/API/1.8/Autocomplete does everything, but depends on jQuery UI, which has theming overhead ruled out for Plone.
See attached comparison.
Ruled out jQuery Plugins/Autocomplete since it would add yet another js file, increase complexity for accessibility with another text box, but only add a tiny bit of the full functionality.
Currently using the LaViska & Richmond js, which supports searches for the first character of tags. Labled it in the UI as "Type a character to skip through tags." (Any suggestions on a better word for "skip"? "Scroll" seems incomplete, since the search also gives the result focus, which mere scrolling does not. And when previewing this ticket comment, Trac shows an action "skip", so maybe that is the best word.)
comment:27 in reply to: ↑ 26 Changed 5 years ago by rmattb
Replying to rmattb:
"Type a character to skip through tags."
Revised help text which is not technically complete, but likely more understandable: "Type the first letter to skip through tags."
comment:28 Changed 5 years ago by elvix
Comments (based on image 07)
I would prefer if we avoided the scrollbars when the list of tags isn't very long (say up to 10 or so). Scrolling stuff inside windows is generally painful.
Is there a particular reasoning for duplicating the list of currently selected items next to the scoll-list and also duplicating the checkbox-functionality with a new widget? (the red X). This does the same as unchecking the checkbox, just in a new way. I find it confusing.
In the example in image 07. all the tags with checkboxes would fit without scrolling if you used both columns for the list instead of duplicating the currently selected ones. I see that this wouldn't scale to hundreds of tags, but in most cases it would work better.
(oh. and just to have mentioned it: I think this is a massive improvement over the current unusable one already. And long overdue. Thanks for fixing it!)
comment:29 Changed 5 years ago by rmattb
comment:30 Changed 5 years ago by rmattb
comment:31 Changed 5 years ago by rmattb
comment:32 Changed 5 years ago by rmattb
Thanks for your comments, elvix.
Re: size of box. Currently, 6 tags typically display without a scrollbar - are you saying that the box should be taller to show 10?
Re: seleced tags. The screencast (linked above) explains some of the reasons for showing currently selected tags. A common example from Plone <=3 is where a user left clicks on tag #2, not seeing that tags #21 & 22 were already selected below the scroll, and thus inadvertently removes #21 & 22. They can literally lose tag data. With the new widget however, since a left click no longer deselects other tags, showing the selected tags is not a *must*, but many have said it's nice to have. Since the coding of that is done, I'm inclined to leave all the options in, and a simple css change can hide the selected tags, if desired. GMail and Flickr show selected tags (labels) outside the selector widget.
Re: red X. It was suggested that in the case of long tag lists, it would be convenient (though redundant) to be able to deselect a tag without scrolling, and it wouldn't require much space. Could the alt text be improved to explain it better? GMail again has similar functionality on tags (labels). Flickr only shows this tag delete X on hover - maybe that's the best middle-ground approach.
Re: two columns. This is another case for showing more than 6 tags, so I've increased it to >8.
comment:33 Changed 5 years ago by rmattb
Fixed bug in original js where after checking a box w/mouse, keyboard up and down arrows do not scroll all the way down the list. Every few items, the acive element jumps up a few, and then continues down again.
Mixing of mouse and arrow key navigation is now optimal.
comment:34 Changed 5 years ago by rmattb
comment:35 Changed 5 years ago by rmattb
comment:36 Changed 5 years ago by rmattb
For better accessibility, completed ability to seamlessly switch between arrow keys & mouse, and mouse & tab key navigation. Hopefully js frameworks will make this easier in the future.
comment:37 Changed 5 years ago by rmattb
To do at this point: cross-browser testing & refinement (FireFox is complete), finish accessibility, and i18n placeholders.
comment:38 Changed 5 years ago by rmattb
[Note that most commit messages do not appear here, since they apply to Archetypes, in a separate SVN repo.]
comment:39 Changed 5 years ago by rmattb
Working on issue with Safari's handling of jQuery mousemove.
comment:41 Changed 5 years ago by rmattb
Added workaround for Safari firing mousemove events when mouse has not actually changed position.
comment:42 Changed 5 years ago by rmattb
comment:43 Changed 5 years ago by rmattb
For better accessibility, completed ability to switch between arrow keys, mouse, and tab key navigation, in any order.
comment:44 Changed 5 years ago by rmattb
Tested on Firefox (3.6.12 Mac, 3.6.11 Windows, 3.0.3 Ubuntu), Safari 5.0.2 (Mac), IE 8.0.6001.18702 (Windows). Will test older versions of IE tomorrow. Does Plone officially & fully support IE 6 at this point?
comment:45 Changed 5 years ago by rmattb
Some outstanding questions:
- Change TAL static attributes to match the dynamic ones?:
In src/Products.Archetypes/Products/Archetypes/skins/archetypes/widgets/keyword.pt the keyword widget template’s original select element has a static id="predefined_subjects" and name="predefined_subjects:list", but these are redefined to different values by TAL at runtime. It would seem to be more self-documenting to use the actual values that TAL provides at runtime in the static definitions, and add a tal:comment to better explain the purpose of this select element. I'm not sure of the rationale of the current implementation, though. Is there any reason not to make such changes?
- Widget CSS location?:
For now I’ve added generic, monochrome CSS for this new widget to src/plonetheme.sunburst/plonetheme/sunburst/skins/sunburst_styles/authoring.css, but is there a place to put this generic CSS for all themes to inherit?
- Comment out JavaScript & CSS for other instances?:
The JavaScript & CSS for this PLIP is capable of being reused for other multiple select elements, either drop-down or always-visible style, but would require some work to generalize it. Since it's not yet general, should I mark & comment out any unused code for now? (After profiling, I may do some of this anyway for speed.)
Thanks!
comment:46 Changed 5 years ago by rmattb
Non-functional things I plan to work on during the PLIP review time:
- new i18n fields (2 are help text, 1 is currently selected tags)
- more code commenting
Functional & non-functional things I could also work on during the PLIP review time:
- animation for adding & removing selected tags
- profiling &/ refactoring
- other documentation? (please suggest)
- more keyboard support
- testing with QUnit, zptlint, Selenium, Hudson (this PLIP is a complex UI case)
Please comment on what you think is most important. Thanks!
comment:48 Changed 5 years ago by rmattb
comment:49 Changed 5 years ago by rmattb
Change log for Archetypes, where most of this PLIP lives, except for css: https://dev.plone.org/archetypes/timeline?from=12%2F20%2F10&daysback=90&author=rmattb&changeset=on&ticket=on&wiki=on&update=Update
comment:50 Changed 5 years ago by robgietema
comment:51 Changed 5 years ago by rmattb
A little css work remains for IE7.
comment:53 Changed 5 years ago by rmattb
Reduced size (unpacked) from 25KB to 17KB by removing code only used for drop-down & other functionality outside of Plone tagging. Size can be further reduced to 16KB if FWT prefers not to include the remove selected tag functionality (red X icon).
comment:54 Changed 5 years ago by cah190
comment:55 Changed 5 years ago by rmattb
Added js metadata file for caching.
comment:56 Changed 5 years ago by rmattb
Refactored existing tags help text so that "Hover and" would not appear with javascript disabled. With the old widget, instructions to select multiple tags are more important than type-to-skip, so replaced help text when javascript is disabled.
comment:57 Changed 5 years ago by rmattb
comment:59 Changed 5 years ago by rmattb
Removed red X icon and associated function to uncheck selected tags, per reviews.
comment:60 Changed 5 years ago by rmattb
comment:61 Changed 5 years ago by rmattb
comment:62 Changed 5 years ago by esteele
comment:63 Changed 5 years ago by esteele
comment:64 Changed 5 years ago by esteele
- Status changed from new to closed
- Resolution set to fixed
comment:65 Changed 5 years ago by rmattb
comment:66 Changed 5 years ago by rmattb
comment:67 Changed 5 years ago by rmattb
comment:68 Changed 5 years ago by rmattb
comment:69 Changed 5 years ago by rmattb
comment:70 Changed 5 years ago by rmattb
Added QUnit tests.
comment:71 Changed 5 years ago by rmattb
comment:72 Changed 5 years ago by rmattb
comment:73 Changed 5 years ago by rmattb
comment:74 follow-up: ↓ 76 Changed 5 years ago by potzenheimer
- Status changed from closed to reopened
- Resolution fixed deleted
Just addressed #8792 (keyword widget: performance issue in edit mode) which is still an issue in Products.Archetypes trunk. Appologies for highjacking this PLIP ticket, but since this PLIP is scheduled for inclusion in Plone 4.1 fixing this potential performance problem is not only overdue but also mission critical.
Index: Products.Archetypes/Products/Archetypes/skins/archetypes/widgets/keyword.pt =================================================================== --- Products.Archetypes/Products/Archetypes/skins/archetypes/widgets/keyword.pt (revision 13688) +++ Products.Archetypes/Products/Archetypes/skins/archetypes/widgets/keyword.pt (working copy) @@ -29,7 +29,9 @@ allowedKeywords python: context.collectKeywords(fieldName, field.accessor, widget.vocab_source); site_props context/portal_properties/site_properties|nothing; format widget/format | string:select; - allowRolesToAddKeywords site_props/allowRolesToAddKeywords|nothing;"> + allowRolesToAddKeywords site_props/allowRolesToAddKeywords|nothing; + selectionview context/@@at_selection_widget; + selection python:selectionview.getSelected(allowedKeywords, contentKeywords);"> <div tal:condition="allowedKeywords" id="existingTagsSection"> <tal:comment tal:replace="nothing"> @@ -68,7 +70,7 @@ name string:${fieldName}_existing_keywords:list;"> <option value="#" tal:repeat="keyword allowedKeywords" tal:content="keyword" tal:attributes="value keyword; - selected python:test(context.unicodeTestIn(keyword, value), 'selected', None)"> + selected python:keyword in selection and 'selected' or None;"> An existing tag </option> </select> @@ -103,7 +105,7 @@ type string:checkbox; name string:${fieldName}_existing_keywords:list; id string:${fieldName}_${repeat/keyword/number}; - checked python:test(context.unicodeTestIn(keyword, value), 'checked', None); + checked python:keyword in selection and 'checked' or None; value keyword" /> <label tal:content="keyword" @@ -140,7 +142,7 @@ rows="4" tal:attributes="id string:${fieldName}_keywords; name string:${fieldName}_keywords:lines;" - tal:define="subject python:[item for item in value if not context.unicodeTestIn(item,allowedKeywords)]" + tal:define="subject python:[item for item in value if not item in selection]" tal:content="python:'\n'.join(subject)"> A new tag </textarea>
comment:75 Changed 5 years ago by rmattb
comment:76 in reply to: ↑ 74 Changed 5 years ago by rmattb
Replying to potzenheimer:
Just addressed #8792 (keyword widget: performance issue in edit mode) which is still an issue in Products.Archetypes trunk. Appologies for highjacking this PLIP ticket, but since this PLIP is scheduled for inclusion in Plone 4.1 fixing this potential performance problem is not only overdue but also mission critical.
Index: Products.Archetypes/Products/Archetypes/skins/archetypes/widgets/keyword.pt =================================================================== --- Products.Archetypes/Products/Archetypes/skins/archetypes/widgets/keyword.pt (revision 13688) +++ Products.Archetypes/Products/Archetypes/skins/archetypes/widgets/keyword.pt (working copy)
Thanks for the fix and the heads up potzenheimer, I was not aware of #8792 - my changes to these lines were only to clean up indention, so these appear to be separate issues.
I think your diff for keyword.pt could go into #8792.
comment:77 Changed 5 years ago by esteele
- Status changed from reopened to closed
- Resolution set to fixed
Please create a new ticket for any remaining issues. At this point, it's merged and released, so anything wrong with it is a Plone bug and not part of the PLIP.