Enhanced and moved summary table to request box.

Review Request #2964 — Created March 17, 2012 and submitted

Information

Review Board

Reviewers

Issue Summary Table will provide a brief list of all the issues found within a review. It will provide small details about every issue, and will allow users to navigate to the issue.

Usability:

Issues are now properly "link-able".
The linked or targeted issue will be highlighted. This is to avoid confusion between issues found at the bottom of the page.
Users are also provided with a 'back-to-issue-summary' link for easier navigation between issues and issue table.

Changes:

Moved summary table to request box.
Not open issues (closed/fixed) are now hidden by default.
Added "Show Status: Open/Resolved/Dropped/All" filter button.
Dynamically update issue summary entries according to filter status.
Adapted HTML/CSS to fit request box style.
Added "Last Updated" column to table.
Added "Issue ID" column to table which now includes a an issue type and id number.
Added 'issue-summary' anchor.
Added 'back-to-issue-summary' anchor.
Added comment anchors and highlighting when targeted.
Rows can now be sorted by clicking on the column headers.
Refactored some comment model, javascript, and CSS code.

Looking for feedback on visuals/functionality.
Local Machine: Ubuntu 11.04, Chrome 17, Firefox 11.
Description From Last Updated

If there are only two states (All, or Open), I wonder if we can simplify the interface by just using …

mike_conleymike_conley

Remind me again - do we wrap long comments like this? Or truncate them?

mike_conleymike_conley

Just curious - what's this column useful for? Is that the comment id? If so...I'm not sure that's information that's …

mike_conleymike_conley

Nit - the edges of these boxes don't line up. The border around the lone file attachment does not line …

mike_conleymike_conley

The yellow feels a bit jarring on this background. Can we turn it down? Maybe add a bit more padding …

chipx86chipx86

Hmm not sure a button is right for this, given that it changes states. A drop-down may be better.

chipx86chipx86

ChipX86 / purple_cow might disagree with me here, but I think we might want a darker border around this table.

mike_conleymike_conley

First line summary, on the same line as """. Then a blank line, then description.

chipx86chipx86

css_class

chipx86chipx86

No need for (), and don't use "not". Use !=.

chipx86chipx86

Two blank lines.

chipx86chipx86

Comparisons should actually use ===. No casting, so slightly faster. Same below.

chipx86chipx86

Combine these lines.

chipx86chipx86

Hmm, actually, I'm thinking we should just do an {% if %} here in place of the hide_not_open_issue filter. The …

chipx86chipx86

th:first-child?

AM ammok

th:last-child?

AM ammok

I'm curious - why is this defined as a new function instead of an object? Could you not accomplish the …

mike_conleymike_conley

Would it be useful to sort by description as well? Additionally, should we restrict the headers explicitly or just specify …

AM ammok

I believe .parent().children() can be simplified to just .siblings()

mike_conleymike_conley

Extra space in front?

AM ammok

Would it make sense to add some sort of delineation between a count and the next label (e.g., comma, vertical …

AM ammok

Missing trans blocks?

AM ammok

These should align. Blank line after variable declarations.

chipx86chipx86

Blank line between these.

chipx86chipx86

Align the parseInts.

chipx86chipx86

Same.

chipx86chipx86

As an optimization. pull out the text() results for each thing. Then compare these before doing any attr() or hasClass() …

chipx86chipx86

Can you make this !== && !== ? Just easier to read.

chipx86chipx86
chipx86
  1. 
      
  2. Show all issues
    The yellow feels a bit jarring on this background. Can we turn it down? Maybe add a bit more padding too.
    1. The yellow follows the open issue color scheme, as do all issue statuses. Do you want to change that?
  3. Show all issues
    Hmm not sure a button is right for this, given that it changes states. A drop-down may be better.
  4. Show all issues
    First line summary, on the same line as """.
    
    Then a blank line, then description.
    1. I'm not sure what you mean by: "First line summary, on the same line as """."
    2. Python docs are in one of the following two styles, depending on content length:
      
      """One-line summary."""
      
      Or:
      
      """One-line summary.
      
      Remaining multi-line description.
      """
  5. Show all issues
    css_class
  6. Show all issues
    No need for (), and don't use "not". Use !=.
  7. reviewboard/reviews/templatetags/reviewtags.py (Diff revision 1)
     
     
     
     
    Show all issues
    Two blank lines.
  8. reviewboard/static/rb/js/reviews.js (Diff revision 1)
     
     
    Show all issues
    Comparisons should actually use ===. No casting, so slightly faster. Same below.
  9. reviewboard/static/rb/js/reviews.js (Diff revision 1)
     
     
     
    Show all issues
    Combine these lines.
  10. Show all issues
    Hmm, actually, I'm thinking we should just do an {% if %} here in place of the hide_not_open_issue filter. The filter seems a bit wrong here.
    1. I feel that is a cleaner way of hiding <tr>'s. The other solution would have me rewriting the same line twice, once with the 'hidden' class, and once without.
    2. It's fine to keep the <tr> how it is. Just instead of the {{comment.issue_status|hide_not_open_issue}}, do {% if comment.issue_status == "open" %}hidden{% endif %}, or however the comparison is.
  11. 
      
ME
ME
DD
  1. Aside from fixed issues blending in with the background and a background color for headers, there's a couple other finicky things.
    If you exit the page it resets your "Show status" option, which could potentially be annoying (might be ok, wishful thinking?). Changing status' also changes the sorting of the summary table. Aesthetically think they should sort the same as the review.
    1. I fixed the color issues, and the rows are now sortable.
      I can't preserve the state of "show status" without a cookie or a url modification, which I'm inclined to not do.
      
      Let me know what you think of the update.
  2. 
      
ME
AM
  1. It seems that the default method should be reachable again after sorting other columns.
    1. What default method? I think by default issues should be sorted by id/time opened. That would require some server side sorting. I will look into it.
    2. Ah, sorry. On my local review request, I had re-opened one of the issues, which updated the timestamp, making the list look out of order because the issues are initially sorted by the order of their creation.
  2. reviewboard/static/rb/css/reviews.less (Diff revision 4)
     
     
    Show all issues
    th:first-child?
  3. reviewboard/static/rb/css/reviews.less (Diff revision 4)
     
     
    Show all issues
    th:last-child?
    1. My issue with first-child/last-child is browser support.
  4. reviewboard/static/rb/js/reviews.js (Diff revision 4)
     
     
    Show all issues
    Would it be useful to sort by description as well?
    
    Additionally, should we restrict the headers explicitly or just specify all <th> in issue-table?
    1. I just couldn't think of a use-case where a person wants to sort issues by description alphabetically. That's why the jquery selector is restricted to the other 3 headers.
    2. I feel like it wouldn't hurt to also allow the user to also sort by description. This would also save you from having to enumerate each of the other columns here and in the CSS.
  5. Show all issues
    Extra space in front?
    1. In front of what?
    2. I see what you mean now. This is valid, I'll fix it.
  6. I'm wondering if this would make more sense, semantically, as a list or grouped in a stronger fashion.
    1. Not sure what you mean here.
    2. Right now this series of counters is just a bunch of divs embedded in other divs, but I feel like it would be better represented as an unordered list in the code.
      
      Not a big issue, though.
  7. Show all issues
    Would it make sense to add some sort of delineation between a count and the next label (e.g., comma, vertical border)? I feel like it might be best to remove the temptation to read it as "n things" rather than "things: n".
    1. I think the counters could use some styling/reformatting. Not 100% sure on what would be the ideal way of representing them.
    2. I'll leave this for another commit. I'm going to drop the issue for now.
  8. Show all issues
    Missing trans blocks?
    1. This is valid, I'll fix it.
  9. 
      
mike_conley
  1. 
      
  2. Show all issues
    If there are only two states (All, or Open), I wonder if we can simplify the interface by just using a checkbox?
    
    Or maybe even better, just a link like we do in the review request dashboard ("Hide submitted", "Show submitted", etc).
    1. The Hide/Show Submitted works kind of like the button. The difference with the one on the dashboard is that it reloads the page, but if that were dynamic, I'd say it should probably be a checkbox or something.
      
      I think there could be some use in a third state: "Closed." Going over what's been fixed, which could be useful when, say, reporting status to someone. *shrug*
    2. The drop-down was used to support additional filters.
  3. Show all issues
    Remind me again - do we wrap long comments like this?  Or truncate them?
    1. Long comments overflow and the overflow is hidden.
  4. Show all issues
    ChipX86 / purple_cow might disagree with me here, but I think we might want a darker border around this table.
    1. There is currently no border for this table, are you suggesting I add one? purple_cow / ChipX86, any opinions/ideas?
  5. reviewboard/static/rb/js/reviews.js (Diff revision 4)
     
     
    Show all issues
    I'm curious - why is this defined as a new function instead of an object?  Could you not accomplish the same thing via:
    
    var issueSummaryTableManager = {
      init: function() {
        // blah
      }
    };
    1. That's what we do with gCommentIssueManager now. In JavaScript, "new function() {}" is basically how you create an instance of something. It just looks weird.
    2. It is a way to create singleton instances. It also allows us to preserve internal variables and helper functions that aren't accessible outside of the issueSummaryTableManager scope.
  6. reviewboard/static/rb/js/reviews.js (Diff revision 4)
     
     
    Show all issues
    I believe .parent().children() can be simplified to just .siblings()
    1. .siblings() will not include the current element, so we won't be able to locate the index of the current element.
      
      I know it looks ugly, but its the only way I was able to get the index of the element.
  7. 
      
ME
SM
  1. 
      
  2. The way the columns expand like this seems strange to me. I feel like it would be better if the description field grew to take up the space, leaving the other columns fixed to the left and right.
    1. I think the fact that the descriptions aren't falling under the title because they are left justified exaggerates the strangeness as well...
    2. I left justified the description header, I think it looks better now. What do you think?
  3. 
      
SM
  1. 
      
  2. It might be nice to have a horizontal rule between these sections. Like the ones that appear between Summary/Info, and Info/rest of request.
    
    It isn't really part of the request's body like the other fields it is appearing with.
    1. I added a divider, let me know if that's what you had in mind.
  3. 
      
ME
SM
  1. 
      
  2. Can I see this with short descriptions?
    1. Added a short description screenshot.
  3. I like it. Exactly what I meant.
  4. 
      
ME
SM
  1. 
      
  2. I think it's much better now. Great job.
  3. 
      
chipx86
  1. I think this is looking very good! A couple nits to pick, and then I'm happy if everyone else is happy.
  2. reviewboard/static/rb/js/reviews.js (Diff revision 6)
     
     
     
    Show all issues
    These should align.
    
    Blank line after variable declarations.
  3. reviewboard/static/rb/js/reviews.js (Diff revision 6)
     
     
     
    Show all issues
    Blank line between these.
  4. reviewboard/static/rb/js/reviews.js (Diff revision 6)
     
     
     
    Show all issues
    Align the parseInts.
  5. reviewboard/static/rb/js/reviews.js (Diff revision 6)
     
     
     
    Show all issues
    Same.
  6. reviewboard/static/rb/js/reviews.js (Diff revision 6)
     
     
     
     
    Show all issues
    As an optimization. pull out the text() results for each thing. Then compare these before doing any attr() or hasClass() comparisons (assuming that's not going to throw off the logic).
    
    That should shorten the sort time for all this.
  7. reviewboard/static/rb/js/reviews.js (Diff revision 6)
     
     
    Show all issues
    Can you make this !== && !== ?
    
    Just easier to read.
  8. 
      
mike_conley
  1. 
      
  2. Show all issues
    Just curious - what's this column useful for?  Is that the comment id?  If so...I'm not sure that's information that's useful to me.
    
    If that's true, we can axe that column.
    1. As discussed on irc, this field will serve as a name for issues.
  3. Show all issues
    Nit - the edges of these boxes don't line up.  The border around the lone file attachment does not line up with the left border of the issue table.
    
    Another nit - are we able to make the Total / Show status labels line up with the left border of the table?
  4. 
      
ME
ME
chipx86
  1. I applied this and spent some time playing with it. I like the direction a lot, but there's a style issue that's bothering me.
    
    I think the table itself doesn't fit in well enough with Review Board right now. The reasons being that the font sizes are hard-coded to be larger than you'd find in other tables, and the alignment is centered, which you don't find elsewhere.
    
    I'd like the font sizes to match that of the Dashboard, and for the content to be left-aligned.
    
    I'd also be interested in seeing how the header looked in dashboard style, in order to be more consistent.
    1. I fixed the styles in an attempt to match that of the dashboard and provide a more consistent experience.
      
      One issue that I brought up in last semester's post-mortem was that some fonts were too small beyond comfort (for me at least). For me, the move from 8pt->9pt, or 11px->12px font sizes would make text more readable (especially on darker backgrounds).
      
      Nonetheless, the fonts in this patch inherit the size from body and are consistent with the rest of the fonts.
      
      One issue that may come up in this patch is that the urls for the header backgrounds may be too absolute, and I'm not sure if this will break on a non-dev deployment.
    2. Yeah, fonts in general on the site need work. Been meaning to poke at that.
      
      Do you need the ../../../static/? Or would ../../djblets/ work?
      
      We'll see how well it does on an install tonight.
  2. 
      
ME
SM
  1. 
      
  2. I think Christian made some good points. This fits in much better now.
    1. Agreed - that's looking really good.
  3. 
      
chipx86
  1. Looks good, but no longer applies. Once it does I'll give it a final spin and then in it goes!
  2. 
      
mike_conley
  1. Bump - any chance you can unbitrot this patch, Yazan? When that's done, I think it's ready to go.
  2. 
      
ME
chipx86
  1. Ship It!
  2. 
      
ME
Review request changed
Status:
Completed
Change Summary:
Pushed to master (77e875a)