Sortable lists

[jrubenoff]

Outcome

Create a component which elegantly displays lists of sortable data not well-suited to a tabular structure.

Structure

First draft at a design. Ignore the tooltip at the bottom: https://redpen.io/fv7a9131f73748ea98

The toggle button is supposed to be a new iteration of .dropdown_toggle_button.gray. It is below the header, because you can place something to the right of the header: a .filter_form, or a secondary action.

[ajb]

Here's a new mock from https://github.com/dobtco/screendoor-v2/issues/2229#issue-95082655:

My feedback:

• Can we add the question number (sequential id) somewhere? Where would it go?
• This blank space looks kinda weird: http://take.ms/amAxP
• Should this component be the same as the collaborators page?

[jrubenoff]

For the places we use this (questions and messages) I don't think we need the sequential ID...

Customers can always refer to an item by the subject line / question title, or the timestamp (i.e. "take a look at the most recent question").

[ajb]

I disagree. How is this any different from us referring to GitHub issues by ID?

[jrubenoff]

The biggest strength of GIthub's issue numbers is being able to cross-reference them in other issues and pull requests. It doesn't make sense for us to do this in Screendoor: questions and sent messages aren't referenced often enough in other conversations.

Otherwise, Github's system is pretty awkward: by just seeing a number, you have no idea what the issue is about. Also, in a system where you can delete items (like how Screendoor lets you delete questions). you'll have missing numbers. That gets confusing quickly.

[jrubenoff]

FWIW it makes sense to think of this pattern like a support dashboard (or, hey, an email inbox) rather than a project management system.

[jrubenoff]

Here's an example of a more compact design:

Let's get this done sooner rather than later. Here's why:

• Clicking on column headers to sort data isn't immediately obvious, as we've heard from a few support requests.
• There's no way to establish visual hierarchy with tables, to de-emphasize secondary and tertiary information, and highlight actions you can take.
• Tables inevitably break on mobile devices.
• When full-width tables contain short strings, they're not the most info-dense way of displaying that content.
• When tables contain long strings that span multiple lines, they're not very readable.

[ajb]

we've heard from a few support requests

I wasn't aware. Thanks for bringing that up!

establish visual hierarchy with tables, to de-emphasize secondary and tertiary information

Your design does a great job of this.

highlight actions you can take.

But it doesn't seem to do this too well. The remove button is the only action I see -- and depending on context, a text link might be more obvious, right?