patch list action bar design changes

[Jonathan Nieder]

Hi Raxel,

Raxel Gutierrez wrote:

> I designed a mockup for the UI of the “Patches” page for Patchwork
> that moves the actions that can be made on selected patches up above
> the list of patches. As can be seen, there is now a sort of action bar
> that can be used to change the state of and delegate someone to a
> patch. Also, there’s a text field to create a bundle as before.
> Additionally, for more one-off changes there are dropdowns for the
> delegate and state so that users can make those specific changes.

Hopefully others will weigh in as well, but here are my thoughts, in
terms of the proposed changes relative to the current UI:

 1. This moves the "change properties" and "create bundle" controls to
    the top instead of the bottom of the page.  That better matches
    other UIs with lists and controls to act on them, such as mail
    clients and bug trackers.  It makes the controls more discoverable
    instead of a user having to wonder "how do I edit these?"  I like
    it. :)

 2. Relatedly, it makes the controls more concise without losing
    information.  One nit: it looks like there's an "archive" /
    "unarchive" radio button --- what would a user do if they want
    to leave the archived state as is?

 3. It also allows inline changes on each line.  I like that since it
    seems a bit smoother and less error prone, allowing changing a
    value in the same place as one sees the current value.

[...]
> This behavior makes sense from the perspective of preventing behavior
> that can’t occur (better for safety). An alternative suggested by
> Jonathan that I think can be discussed is to have the rows selectable
> and the new action bar visible. If a user doesn’t realize they aren’t
> signed in, a popup message that lets them know to sign in when they
> try to submit changes would be helpful for them to figure that out.

After you sent this I think you suggested a different alternative: to
present the controls but disabled, with some hover text saying what
the user needs to do to use them (what permission they're missing, or
if they need to sign in).  I think that makes sense, since it avoids a
user spending time setting other fields only to find out that the
submit action is blocked.

> Adding on to that, users that don’t have accounts, and simply want to
> explore the website can see what actions are afforded to them without
> actually making changes.

The editable controls are not much larger than the non-editable ones,
so I don't think this interferes much with a "just browsing" user.

Overall summary: I like it!  Looking forward to seeing it in action. :)

Sincerely,
Jonathan