Closed (fixed)
Project:
Hierarchical Select
Version:
6.x-3.5
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
29 Aug 2008 at 18:36 UTC
Updated:
6 Feb 2011 at 13:37 UTC
Jump to comment: Most recent file
Today, at the Usability enhancements for Drupal hierarchies (menu links and taxonomy) BoF session, I got a lot of interesting feedback, mainly from Charlie (cwgordon). (Thanks Charlie! And nice meeting you :))
Charlie's main concerns, and his/my thoughts about the consequences:
- The size of the HS is 1 by default (i.e. a "normal select"), instead of >1 (i.e. a "tall select"). But when it's >1, you don't have to click the select before you can click on an option, i.e. 1 click vs. 2 clicks. It's not good in all cases, but it's probably better in most cases. So we really should be using that as the default. But people are already used to the way HS works by default now, so it's kind of hard to change the default?
- When selecting an item and the child level appears, nothing should be preselected (right now the level label is being preselected, but this is not a necessity for HS to function anyway). This only is a problem when size is > 1.
- When going deep into the three, i.e. if you're at level 3, the first level should be hidden/collapsed (?), to minimize the amount of horizontal space required. I agreed, but later I decided this is actually not good, because you can't go from level 3 or deeper all the way back to the root level in one step, it would require multiple clicks.
- (There's one thing I'm forgetting I think…)
Other suggestions raised during the BoF:
- When there's only X terms, where X < 20 or so, we should default to a hierarchically displayed list of radios (single selection) or checkboxes (multiple selection). The problem with that is that if you go above, below, above, below, etc. your treshold, you're displaying different widgets all the time, which is not good. So, this should be a decision of the site admin. If you're using the Taxonomy CCK field (content_taxonomy module), this becomes trivial because you can simply select the widget you prefer.
- For creating terms (or menu items or …), it'd be nice to have the ability to order them, perhaps parts of the Taxonomy Manager's form element could be reused for this? But then it would become pretty unlikely that HS would make it into core. And ordering is something that's more likely to be done through the admin UI anyway?
Comments welcome!
Note to interested users: the size can be set using #size
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | resizable_hs_4.patch | 21.94 KB | wim leers |
| #4 | resizable_hs_3.patch | 50.42 KB | wim leers |
Comments
Comment #1
catchOf those points, I reckon defaulting #size to higher would be good - the one thing you miss compared to a normal select list is a quick scan of items, and this allows for that. As long as it's in release notes, it shouldn't hurt to change for existing users of the module (you're still in RC right?). I'm not sure about checkboxes/radios - pretty much agree that those who have content taxonomy + hierarchical select can do this manually, but it's worth thinking about longer term. I can't think of that many use-cases for re-ordering on the node form - and it's extra complexity for site visitors. Collapsing the first level also seems unnecessary to me.
Comment #2
wim leersI had written a nice comment here but then d.o decided to log me out. ARGH! There's nothing else I hate more than losing data because of buggy software.
ANYWAY. I'll repeat shortly what I wrote here. I won't repeat every detail because I'm too annoyed.
Setting #size to > 1 requires more screen estate, which sucks. Part of why HS feels good is because it's so small, so not prominent. To still allow for bigger HS without sacrificing this, I decided to make HS resizable.
See this screencast of the current prototype.
Still to do:
- make the size + CSS height persist throughout AHAH callbacks
- adjust the size attribute properly (i.e. reset it to 1 if the user makes it that small, set it to 2 if it gets bigger than the minimum size)
- make the resize bar span across the entire HS
Comment #3
wim leersThe current version, that implements everything on the TODO list, but is flaky thanks to the crappy bunch of code that jquery.ui.resizable is. I had to add at least 2 hacks to ui.resizable.js to make it work, and then 2 more to HS' JS code too.
prototype #2
Comment #4
wim leersHere's the code for prototype #2.
Apply as any patch, but also create an "images" directory inside the HS directory and copy misc/grippie.png to it (result: sites/all/modules/hierarchical_select/images/grippie.png).
Notes:
- ui.resizable.js has been patched at multiple places, without these changes, you'll experience VERY strange behaviors
- it breaks the ability to select options in a select in Safari, for an unknown reason
I'd prefer to go with something like textarea.js instead because of the bugginess of ui.resizable, but for yet another unknown reason, that code doesn't show the changes made by the dragging of the handle until you release the mouse button (i.e. stop dragging). If anybody would like to help me with that, let me know.
Comment #5
wim leersThird prototype. Completely different code than the previous prototype.
Changed:
- now uses code similar to textarea.js
- you can double click the handle, to make it toggle between the default height and 4.5 times the default height. In Firefox and Safari, the result is that you'll see 5 items cleanly. I'd already thought of this as well, but thanks to Kaaskop (Bart Feenstra) for suggesting this as well!
- works smoothly!
- enabled *everywhere* by default.
- configurable in the common config form.
So this was the main concern remaining, the other one being When selecting an item and the child level appears, nothing should be preselected (right now the level label is being preselected, but this is not a necessity for HS to function anyway). This only is a problem when size is > 1..
Removing this preselection didn't matter, as browsers seem to select the first item (which is the level label) by default if nothing is selected – at least Firefox and Safari.
So now that this patch has been committed, no HS UX feedback remains and therefore this issue has been marked as fixed.
Comment #6
pwolanin commentedI liked the demo, so hope we can get something like this into D7 core.
Comment #7
catchIt's very, very nice indeed.
Comment #8
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #9
1kenthomas commentedThis was auto-closed but I'm not sure of status in 6.x? HS still defaults to 1 (closed, required click), with no obvious way to change in UI, AFAIK. Therefore reopening, sorry if by error!
Ken
Comment #10
wim leersThis indeed can't be changed in the UI, because so few people find the need to change it. It can be changed using FAPI though. See API.txt. Set #size to your desired number of displayed options.