-
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.
6 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)
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