-
do we really need to see the column with numbers?
this feels like an under-the-hood info, that should be hidden -
the [Fix Positions] button is redundant.
pressing [Save Order] should fix position before saving. -
drag-&-drop for reordering would probably be more intuitive than arrows
7 Likes
Drag and drop would be cool
2 Likes
the [Fix Positions] button is redundant.
pressing [Save Order] should fix position before saving.
Agree here. I’m not sure if there’s a good reason for it that I’m unaware of, but it definitely seems redundant when I’ve used it.
I’m not so sure about that, drag and drop interfaces can be incredibly annoying especially with very long lists. Some sites may have dozens of categories, and scrolling while dragging and finding the correct place to drop can be frustrating. If I have a list of 50 items and I want to move item 49 to position 1, it’s much easier to use the number input.
7 Likes
I see you point about handling a large number of categories. OTOH, typing numbers to move a list item feels like MS-DOS era. How about drag-and-drop and a move-to-top button?
My definition of an efficient UX is, that it should speed up (fewer clicks, simpler input)
the most common actions, while providing an extended set of actions for less common tasks.
All while providing excellent visibility and avoiding clutter.
Per this definition, clicking a move-to-top button is a simpler action than typing a number, so it would work faster in most cases. There’s also a question of smart phone compatibility, where drag-and-drop beats any numerical input.
And then, there’s Discourse own motto: “Born mobile, born to touch”.
Fair point, but the majority of Discourse forums do not have an excessive number of categories so I don’t see why we should deny them the easiest option available just because drag&drop could be problematic in edge cases.
Furthermore, one of the biggest shortcomings of our current re-ordering interface is that it treats sub-categories as independent instead of being in fact a child of a parent category. Right now #howto:sysadmin can be position 3 while howto is position 8. In my opinion sub-categories should be positioned as something like 3-1, 3-2 etc, inheriting the primary position of their parent category.
If only parent categories are shown by default in the re-ordering page, with sub-categories shown upon toggle, the average Discourse forum will have a very manageable number of categories to deal with.
11 Likes
If it works it works, regardless what era it feels like it’s from.
Drag-and-drop and move-to-top as a replacement remove functionality… we’re making the UI less specific and requiring more steps for certain tasks. What if I want to move item 50 to position 10? I either drag past 40 other items and hope I don’t mess up (which can cause me to have to start the process all over again), or I have to click “move to top” and then drag. It’s less exact and requires at least 2 clicks if I’m doing everything perfectly. If we call for the numeric keypad on mobile (which we’re not at the moment), tapping an input and typing 10 seems at least as fast and less prone to error.
I strongly disagree that this is universally true. It depends on the circumstances. The longer a list gets, the more difficult drag-and-drop becomes to use. It’s a fringy but not completely uncommon for sites to have more than a hundred categories. Drag-and-drop only would make category reordering a nightmare for them.
I’d argue that’s it’s not problematic, but almost completely broken if it’s the only option for sites with large numbers of categories.
I’m not completely opposed to drag-and-drop, we just can’t sacrifice numerical input along with it. I don’t think it would be a problem to eliminate the up/down arrows for drag-and-drop, in most cases drag-and-drop is probably nicer than clicking an arrow over and over again.
Totally agree.
5 Likes
A simply approach to ease this up, without implementing a nice UI for reordering nested categories, might be to simply split out the subcategories:
-
Completely hide the subcategories from the reorder dialog by default, only allowing the top-level categories to be ordered.
-
On top, add a dropdown:
Reorder | Main Categories ​ v | |------------------------------| | Sub-Categories of Feature | | Sub-Categories of Bug | | Sub-Categories of Howto | |------------------------------|When the user selects a category in the dropdown, the list below only shows this categories sub-categories, allowing them to be reordered.
4 Likes
can you share a link to a forum with 50 main categories?
I’ve never seen anything like this myself.
If you were referring to a total number of subcategories, then they shouldn’t move independently of their roots anyway. If each of 10 main categories includes 10 subcategories, I can’t see how this would ever be a problem for properly designed drag and drop structure.
It’s not the norm, but I don’t think the concept of a numbered list is so abhorrent in an that we should make the default UI more painful for those sites. This is an interface for creating an ordered list, after all. If you do some searching here on Meta you can find questions referencing hundreds and sometimes thousands of categories. We generally recommend not doing that (and instead creating large numbers of tags instead), but there seem to be some valid cases for it.
A favorite example of a forum with a massive amount of categories (they’re not on Discourse, unfortunately) is XDA Forums
Totally agree.
I’m not trying to argue with you about improving our category ordering interface, it needs improvement, but I think abandoning a simple way of assigning a number to an item in an ordered list because “it looks old” is bad design.
I took a look. It’s a true monster! Just scrolling this is painful, like looking through a flattened image of a support database, with every product made into a separate category.
Most of them are records, that don’t ever require manual ordering, just alphabetical.
I’m really not here to judge. I just wonder if Discourse should even support this kind of design. A discussion forum is very different from a store or a repository database with a threaded commenting system, where Items you can comment on are not categories.
Would just leaving the category position box in the Category Settings be an acceptable compromise?
P.S. I apologize for making a clumsy MS-DOS reference. I didn’t mean to imply that a UX method is bad just because it’s old.
3 Likes
I for one certainly think so, yes. I was never suggesting that we should remove it in the first place. There’s ample space for both UI solutions in this case, and they both have merit.
One thing we should look into is the possibility of (maybe automatically) turning off drag and drop in massive lists. I know for a fact that WordPress ran into serious performance issues with large (100+ items) menus because of their drag&drop system. Although (1) that issue could have since been resolved and (2) as a SPA we probably have a better foundation for this type of feature.
OK going to make a call here on what we 100% support doing!
100% agree, this is confusing, we should remove, it can be done on save.
100% agree we should magically fix subcategory ordering on save. So:
Before:
foo
foo/bar
baz
User changes to:
baz
foo/bar
foo
System fixes to:
baz
foo
foo/bar
We do not support adding drag-and-drop. We are not too enthused about doing a giant UX redesign of the whole reorder menu.
Going to add a pr-welcome on remove fix order AND auto correct sub category position on save.
At the moment you can’t even get to the UI cause we don’t have fixed categories ordering enabled, so that is a different kettle of 
s
5 Likes
As Discourse matures, we are always looking for ways to accommodate the wildly different forums out there in the wild. Is not something we have a hard deadline for, but we are always looking at the landscape and trying to find solutions for the use cases people come up with.
2 Likes
PR’s up 
Also took the liberty to improve the move up/down button (assign the correct position number)
https://github.com/discourse/discourse/pull/6149
Before:
After:
14 Likes
Looks great! what happens if you fiddle with the numbers in the textbox?
3 Likes
Is there a reason to permit that? Why not make them labels? (just asking)
1 Like
I guess one could argue that it makes moving first to last way way easier… that said there are workarounds.
I think the behavior I just merged is fine though, it just fixes up on save and reflects in the UI… Just want to confirm it “fixes everything” not only numbers but position in the list.
3 Likes
That behavior remains unchanged: it will move to the position the number specifies. Should there be a position collision, Save will automatically correct it.
And yes, both the previous & the new flow manipulates the actual position value.
I imagine it makes moving up/down by more than one easier.
9 Likes