Move some post actions to "extra drawer"

Right now, with the addition of the wiki option via @velesin (and thank you very much for that) we have a grand total of eight glyphs / actions on each post:

From left to right:

  • like
  • edit
  • flag
  • delete
  • link / share
  • bookmark
  • extra / other
  • reply

This is too much. I think we need to change the wrench to an ellipsis and put these less-used functions there:

  • edit
  • delete
  • wiki, etc

I do not think we should move like, flag, link/share, and bookmark as those are essential. Bookmark is on the edge, I maybe could be convinced there, but note that we use bookmark to indicate active read state on each post too.

Per this mockup by @awesomerobot – before we hit V1.0 we need to move those three post functions to a drawer.

This also makes extensibility easier, as you can register new unique (rare?) post actions without overwhelming everyone with glyphs / actions on every post.

7 Likes

I like this, but please make sure those extras are accessible via a keyboard (easily!). Otherwise, it is a huge step backwards for keyboard users.

Why would this have any effect whatsoever on existing keyboard shortcuts? Not like we’re hiding “too many” keys on the keyboard…

It actually would VERY likely have an effect, most of the implementation just simulates mouse clicks. You can’t mouse click an element that is not in the DOM.

1 Like

Oh, I see. In that case, your concern is warranted @cpradio. I thought we were sending commands directly to the client, not simulating mouse clicks.

1 Like

Just to also process it via another point of view. Let’s say several new plugins add actions to each post, they may not build in keyboard shortcuts, so that only leaves tabbing to the action as a way to get to it. It would be nice that if tabbing to the ellipsis, pressing enter, that the next tab would cycle through the drop down menu.

Hiding the less-used functions is a good idea but I’d ditch the drawer. How about instead of a box below the row of icons the icons would appear in the same space as they do now? The … icon would simply reveal more icons instead of opening another ui-box. It would make more sense and there is ample room.

Where would the glyphs be “added”? On the left, or on the right? I guess it’d have to ‘expand right’ which is OK.

I really want the expansion to be on the right not the left anyway (we read from left to right, most important stuff on the left, that is why :heart: is on the left), so more like this:

This does highlight one small problem @awesomerobot, the ellipsis is kind of a crap click / tap target because it looks so tiny. I guess it’s an expandable drawer for less used functions anyway so it doesn’t need to be in-your-face.

It is nice that even after the expansion, we are still back to “only” 7 actions on the post versus 8. Since the expanding glyph consumes itself in the expansion…

1 Like

My gut feeling is to expand to left, but really the only way to know is to test it. Anyway, I believe expand to left is better because:

  • The most important stuff is already visible before you expand
  • Keeping the icons in the same place triumphs left to right reading direction for recognition
  • After expanding the most important icons (on the left) should be the expanded icons

How would this effect extending buttons through plugins and the configuration of the order of buttons through the admin interface? Would the ellipsis just hide everything after the second item?

What about when those are optional buttons?Like the “edit”, which is only shown when you have the rights to actually edit. I know for you, @codinghorror, as an admin they always show, but for a normal user like me, the like and the share buttons are way more frequently used.

How do we deal with the already a little awkward difference in behaviour for the reply-button? If I move that to position four of eight, will it also be in the ellipsis?

Quiet honestly, without any additional plugins, as normal User, I have four buttons and reply. I don’t feel that is too much. I’d rather argue the buttons for “delete” and “edit” belong into the admin wrench that has been created recently – which is only shown to a minority of users with special privileges on certain posts.

That’s exactly what this spec proposes, except wrench is the wrong glyph, it should be … as wrench implies ‘admin’.

For average users the main action that would be behind the ellipse is edit (and bookmark, I think I am ready to let that one go).

Ah, alright. then the first mockup was just misleading as it showed the edit outside the ellipse. But yes, if the point is to move “more advanced” options into a sub-area, I volunteer to build this (once there is an agreement on mockups). What will the rule be for whether they are moved there?

2 Likes

For me, the vast majority of the posts on meta look like this:

Of these four glyphs, only one is a candidate for hiding - either the share or bookmark button, depending mostly on perceived importance of the feaure in question.

Adding an ellipsis/wrench button to hide one of these four glyphs would then be a design flaw. Hiding only makes sense when more glyphs are added, e.g. when the current user owns the post, when the user is an admin or moderator, or when the post is marked as wiki.

Mockups should probably consider these three cases separately. For instance, adding a fifth glyph where there are normally only four - for example the edit button on wiki posts - would be a good visual indicator that the post provides additional actions and help to make that feature more accessible.

3 Likes

Yeah, from a language perspective it definitely makes sense to have the ellipses on the right… it’s a little weird to be shifting the already-visible icons to new positions, but on second thought don’t think it’s a big deal — these nav elements are anchored to the right anyway, so adding icons to the right and pushing things left feels natural.

The ellipses looks like a smaller tap target, but technically it’d be the same size as the other icons because they’re all bound by a larger box, so I don’t think it’d cause any issues.

I don’t really have a compelling argument to ditching bookmarks, I’ve just never used it… I don’t even really read it for post read status.

I really like the idea of having the ellipsis on expand to the left/right vs. the popup.

How about hiding everything but Like and Edit under the ellipsis?

For a normal user, you usually only see one of these anyway. And they are far more likely to be clicked than any of the other buttons.

Edit is good to keep as a single click for ninja-edits.

Having only the one most often used button aside from the ellipsis will also make normal users have to think less when they like posts as there are no other choices unless they seek them.

I, too don’t agree that we need to generally strip down to only two items (and decide those are Like and Edit) and I am one of these plugin authors and forum admins, who’s opinionated and dared to change the order (making it an annoyance every time something new is added though). So, how about this simple and clear approach for now:

We already do have the post_menu-SiteSetting allowing administrators to customize the order of buttons. Let’s add another Setting like post_menu_max_items (default 4) that if more than these buttons would be rendered (excluding … ehem … reply …) replaces the fourth with the ellipsis and hides all following behind a click. Once clicked it expands the original buttons from the right (pushing the important ones to the left) in the order giving in the site settings. If the setting is set to 0 the ellipsis never shows up and the buttons are always shown.

This case, what ever the admins considers most important for their community just needs to be at the front of that list (default: like, edit) to be easily accessible and what is closer to the end might be hidden behind a second click (for our community for e.g. flag, bookmark and make to wiki). How does that sound?

3 Likes

You could leverage the post_menu setting in other ways without adding a new site setting, for example by allowing and parsing prefixes. But that’s quite far from the “simple” v1 solution.

What should be possible, however, is to include the ellipsis button in the post_menu setting. Everything to its left is always shown, everything to its right is hidden as long as there are at least two elements to hide. @codinghorror’s “new” mockup would then be expressed as like|flag|share|...|edit|delete|bokmark|reply, assuming that the reply button is treated as special and is never hidden behind the ellipsis.

This adds no new functionality to the UI apart from what was already discussed for posts and provides a good mix of simplicity and customization.

4 Likes

Yeah, I’m down with this. Bookmark is so rare, let’s just put it in the ellipsis drawer. Think item: I really wish we had a nice “Discourse knows you read this post” indicator on each post. The feeling of seeing “read it, read it, read, it” marked on a post as you scroll down is a good, positive one. A glass half full indicator. Reading is fundamental!

But what could that indicator be? What subtle but visible indicator could be used for a “you read this” indicator on each post?

I see your point, perhaps the logic is flexible:

  • if there are more than (n) actions on a post, show the ellipsis expander
  • decide which actions are “hideable” (like should never be, for example)
  • hide the hideable actions when there are more than (n) actions on a post

That way we can avoid showing the ellipsis all the time, if there are only 3 actions, you’re right, it’s just noise to show an ellipsis in that case.

Yes, agreed, this is a good plan.

4 Likes

PR pending:

4 Likes

As a normal user on meta, right now the ellipsis is only hiding one button, which is kinda silly.

I’m assuming it was only intended to show up if it was hiding at least 2 items.

Just a little off by one error?