[MoshiKoi]

First take at #1323, testing and feedback welcome

This PR adds a new preference type for the community preference, as well as a separate "block preference" for styling purposes since it didn't make much sense trying to cram it into the horizontal layout the other preferences use. The styling is very much a work in progress, but it is functional right now.

You can reorder the communities by dragging. I pulled in JQuery-UI for this - not entirely sure if it's worth bringing it in as a dependency, but it can be replaced if needed. I have switch to SortableJS to avoid depending on jQuery.

Might try to also implement "collapsed" communities (#1993). Not sure if that has any real added value if it just sends communities to the bottom since users can do that anyway, but it might be useful as a foundation for later work if we want users to, for instance, be able to set up an email subscription of "posts from focused communities" or similar mechanism.

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.07%. Comparing base (36a1eb3) to head (d34d651).

Files with missing lines	Patch %	Lines
app/controllers/application_controller.rb	0.00%	1 Missing ⚠️
app/models/community.rb	85.71%	1 Missing ⚠️

Additional details and impacted files

Components	Coverage Δ
controllers	77.86% <0.00%> (-0.04%)	⬇️
helpers	85.62% <ø> (ø)
jobs	79.23% <ø> (-0.70%)	⬇️
models	93.47% <85.71%> (-0.03%)	⬇️
tasks	61.11% <ø> (ø)
scripts	∅ <ø> (∅)

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trichoplax]

I like the draggable handles. I think for many people that will be the easiest way to rearrange the communities. Could we keep the handles and also add up and down buttons (that shift that community one place in that direction)?

Some people may find up and down buttons more convenient, but also some people cannot drag (for various reasons).

See Dragging Movements accessibility guidance.

If both draggable handles and up and down buttons take up too much space, there's also the possibility of having up and down buttons only appear when a draggable handle is clicked/tapped rather than dragged. Personally I'd prefer up and down buttons that are always visible to aid discoverability.

[Oaphi]

@MoshiKoi what's the status of this PR? I recall a chat discussion but have lost track of further updates.
If it's ready to go or only needs minor tweaks, I should be around to review or make small updates if you are busy.

[MoshiKoi]

@Oaphi The big issue is still mostly design - the prototype works, but we've gone back and forth in chat on how the preference should function in terms of UI for accessibility, since it turned out to be more complicated than I had expected. Right now, it's still in the state with four buttons on each item to move to top/bottom and move up/down one slot, which is extremely cluttered.

For what it's worth the initial point of this PR was to have a public attempt at the issue and see what it would take to implement, so I wasn't particularly focused on getting it merged in, and the overall UI is also rather unpolished. That being said, since it is functional, if you want to take a stab at UI improvements to get it into a mergeable state, you're more than welcome!

[cellio]

Chat starts around here: https://discord.com/channels/634104110131445811/668890340199235613/1540952422040608769

[cellio]

This is the last screenshot I saw in chat:

We talked about removing the drag handle on the left; things are still draggable but we wouldn't have the extra control (and could add hint text right above this list in the UI). We talked about how even with that, four arrow controls feels like a lot on a small display. But with ~20 communities, move to top/bottom is useful. I tried to find out how others do this but didn't find anything like consensus or best-practice docs.

For displays small enough that it doesn't all fit on one line, what about having two arrows (up and down), default moves one position, but with a modifier it moves to top/bottom? Modifier = double-click or double-tap if using mouse/touch, or control/option with the keyboard equivalent? It's less discoverable than having all the controls, but it fits better on a small display.

For larger displays we could keep the fuller layout, like in this earlier screenshot but with better spacing. This would also help a little with discoverability, if you remember seeing more options on your computer while you're staring at the condensed version on your phone.

[trichoplax]

If you want to keep all 4 move buttons (up, down, top, bottom) and hide them but still have them discoverable, would a drop down box work? This could contain 4 links (that could each be an icon plus a word) to allow this to work without JavaScript, overridden to be buttons by JS when present.

Each row would then just be:

• Drag handle.
• Drop down arrow.
• Community name (and logo if room).

Could still omit the drag handle as mentioned previously if there is a wording hint at the top.

Maybe 4 visible buttons on a wide screen and a drop down on a narrow screen? Could include both in the page and use CSS to decide which to display so it works without JS.

[Oaphi]

For what it's worth the initial point of this PR was to have a public attempt at the issue and see what it would take to implement, so I wasn't particularly focused on getting it merged in, and the overall UI is also rather unpolished. That being said, since it is functional, if you want to take a stab at UI improvements to get it into a mergeable state, you're more than welcome!

Noted, thanks for brining me up to speed with this PR! I'll try to take a stub at brining it over the finish line if I (hopefully) get some time to spare - likely as a "suggestions" PR with this one as a target.