[WIP] Adding buttons to deal with issues in the issue summary table

Review Request #6966 — Created Feb. 20, 2015 and discarded



Some potential options for adding buttons to fix and drop issues to expanded cells in the issue summary table.

Next to be added may also be the number of replies to an issue (which would link to the issue place in the review).


Description From Last Updated

I kind of like the idea here, since the issue table and issues are kind of like a checklist of …

  2. Show all issues

    I kind of like the idea here, since the issue table and issues are kind of like a checklist of things to fix, and this makes that more explicit.

    I wonder, however, if the action of setting the state should somehow be merged witht he "Status" column. They essentially report the same thing, except that one has mutability.

    Tri-state is tricky.

    Ok, wacky idea: How about instead of a checkbox, there's a 3-state slider, like one might find on a mobile device in settings?

    Center state is open. Left state Fixed. Right state is Dropped.

    See http://ux.stackexchange.com/questions/50747/three-state-button-for-a-medical-chart for inspiration.

    1. While I think it's a neat idea, it's also different from what people would use elsewhere on the same page. I think I'd rather we go for consistency instead of having two UIs for the same concept.

      Something that struck me with all the layouts is that they all feel cramped. I'd like to see what happens if we do the following (some of which was discussed at the sprint):

      1. Keep things as they are today, in terms of how the lines look. Don't show any extra UI as-is.
      2. When the user clicks on an entry, expand it to show the full comment.
      3. Show the Fixed/Dropped buttons below the comment text, left-aligned with the text.
      4. Upon clicking Fixed/Dropped, collapse the line (or hide it, depending on the filter mode), and expand the next one.

      Don't worry about adding a bit of whitespace in here. If we're only showing things when expanded, then it's totally fine to take up some space, since the user is working with that section.

      We can also play with expanding on hover (maybe with a slight delay), instead of clicking.

    2. The reason I added the extra UI elements in the default table is that David was concerned about keeping easy access to the current behavior of linking to the comment (see https://reviews.reviewboard.org/r/6910/).

      I'm personally more in favor of what we discussed at the sprint as well, but he has a point that it might be annoying for users who like the current behavior to need an extra click. I like the expanding on hover idea though, and that should also eliminate the aforementioned problem!

Review request changed