Usability Suggestions

Marking with background colors seems to be very nice usability feature! That would indeed explain the hierarchy

HS is the #1 place on my site that causes the most difficulties for my users, it's pretty hard to use for people who aren't very familiar with technology, or maybe my users are especially stupid. :)

Heh, well, I've hadn't had a whole lot of bad feedback, so a view on the other side is welcome :)

But after thinking about it I've decided that part of the confusion stems from the Add button. 1. It's not clear that you HAVE to click add in order to categorize. I blame this on the obtuse 'selection' text.

Nothing has been selected.
All selections

Despite the name of the module, the actual task of the module has nothing to do with 'selection', and calling it that only causes confusion. Users don't get what selection means. Rather the text should more directly address the task at hand like so:

This post is part of these categories:
NONE
I think the all caps there might be useful…
"Categories" should also be a per-vocab text-setting, because it could be for some people, galleries, for some people terms, and so on.

Well, you can easily override the title of the dropbox. There's a "Title" setting in the config form. It defaults to that text when you have left it empty.
I'll stick with "Nothing has been selected" for now. You're the first to complain about that.

2. It's not clear what you're adding. It just doesn't make sense, and users assume strange things. For instance, I have a vocab called gallery and select options called 'add new gallery'. Because 'add new gallery' is the only explanation text for what 'add' is, users assume that the big add button also means to add a new gallery. Yes, I know, they're stupid, but I think we can work around their stupidity.

To make super clear what we're 'adding', the add button should be on the term itself. For instance:

Add new gallery
Apples (+)
Oranges (+)
Bananas (+)

On hover text over the plus sign, it should say things like this: Categorize image in this gallery. That way users know exactly what they're doing. That text should also be per-vocab setting.

This would probably mean not using the drop down boxes, and using regular boxes.

Well, I can imagine that it is confusing if the form is called "Add new gallery": if you then have an "add" button, that could indeed confuse your users.
But in any case, not using dropdowns, but "regular boxes" instead is *also* extremely poor for usability. These will never look the same as normal inputs and because of this lack of familiarity, this will also scare/confuse users. I've specifically chosen to stick with normal widgets whenever possible.

There are additional advantages to this. Now it's possible to add parent terms without de-selecting the child terms and then going backwards.

True. But I'm not sure this is a very common case.

It's also possible to add multiple terms at once, without selecting one, clicking add, waiting for request, then reselect, click add, wait for request, etc. Now you can add a whole bunch all at once and let the requests queue up in AHAH, and if you have apache keep alive, hey, you've just saved some requests!

You'd have to click the plus sign once for every term you want to add. That's not multiple at once. It's also possible currently to resize the HS to also show more at once.
You still wouldn't be able to add a whole bunch all at once because the dropbox is rendered on the server side. And I want to keep it that way: it reduces the amount of code and complexity.
Queueing up the requests will not become more possible then as it is now: the hierarchy still needs to be redrawn. You just can add more parts of the hierarchy to the dropbox at any time and for that particular use case you will need less requests, but you could just as well enable the client-side caching that is already built-in and argue correctly that that also reduces the number of requests.

Another major major issue is the lack of visual representation of the hierarchical nature of the select boxes. We know that the terms are in a hierarchical relationship, but it's hard for the users to figure out. It's unintuitive. Boxes next to each other never implies a hierarchy, so it's not the greatest choice in this case. For instance, right above this issue form I see some boxes next to each other. [feature request] [normal] [unassigned]. They're certainly not in an H relationship.

Agreed. The hierarchy is suggested with the animations though, because of the way they fold into each other.

But these problems might be alleviated by one easy change. Giving the second level a label from the first.

So for instance you have a first level thus:

[Cars]
[Food]
[Games]
[Flowers]

Once you select one of them, it looks like this:

-------------------[Food]

[Cars]-------------[American food]
[Food]------------[French food]
[Games]-----------[Italian Food]
[Flowers]----------[German Food]

Double bonus if the first selection's active background color is the same as the second layer background color, though the tab metaphor is lost with a scrollbar in the way. But with a label above the second level, now users understand that the second level is actually something UNDER the first.

Only Firefox supports background colors in <select> elements (I know you're talking about "regular boxes", but I explained why I won't do that).
Putting the selection of level n-1 at the top of level n makes *some* sense, but not significantly more than the current system. You're changing the hierarchy from being horizontal to it being vertical. That's not really significantly better, IMO. Plus, it will cause confusion with the level labels functionality.

I think it might make more sense to visually suggest a hierarchy by putting the selects for each level below each other, but with an indentation, like this:

[LEVEL 1 SELECT]
    [LEVEL 2 SELECT]
          [LEVEL 3 SELECT]

But this might then cause problems because level 1's select overlaps the other levels partially when expanded. Which is why the current horizontal system makes most sense

I hope my suggestions get implemented soon, as I'm having a lot of trouble fielding support currently. Thanks for listening!

It's unlikely that all of this will be implemented soon. But I *am* listening :)

Looking forward to your reply!

Unfortunately closing due to lack of reply. Still looking forward to your reply, if you ever get back to this! :) Please do mark the issue as active when you do reply!