Bugzilla:UI Hackathon: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Very old page, obsolete for more than 10 years)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
This page is our scratchpad for the current UI Hackathon.  Today's hackathon focuses on navigation usability.  We're meeting on [ircs://irc.mozilla.org:6697/ irc.mozilla.org] in the [ircs://irc.mozilla.org:6697/%23hackathon #hackathon channel].


'''Today's Hackathon: Friday, September 9, from 10am to 6pm PDT'''
=== Navigation Ideas/Patches ===
* Navigation should be moved to the top of the page, and top-page show_bug navigation should be consolidated
* Make the bugzilla banner atop the page link to the bugzilla.mozilla.org home page, instead of mozilla.org
* show_bug navigation should be in a floating box, instead of spread all over the page.
* Put admin navigation in an area separated from user navigation in order to  [https://bugzilla.mozilla.org/show_bug.cgi?id=286338 move the ejection seat button away from the door handle] – admin options box, intermediate page or admin options dropdown
* [https://bugzilla.mozilla.org/show_bug.cgi?id=303126 Add option to exclude a Saved Search from appearing in the <link> tags] - ''Will hopefully have a new patch by the time the hackathon comes around.''
* Subdivide advanced search page and edit bug pages to make more usable (i.e. separate sections and multiple commit buttons so users don't have to search for it or scroll to find it)
* Separate the bug information from the bug changes on edit_bug
* Add inline links to edit_bugs to get around easier
=== General Ideas/Patches ===
* Define a nomenclature (continue the work of [https://bugzilla.mozilla.org/show_bug.cgi?id=76507 bug 76507] and friends) and add the definition to the coding style and reviewers' checklist pages
* Define and consolidate markup and behaviour and add the definition to the coding style and reviewers' checklist pages
** Error pages (better than the given examples would be CSS classes):
*** Complaints about form values marked up consistently, for example always <code><nowiki>&amp;ldquo;<code>xxx</code>&amp;rdquo;</nowiki></code><br><span style="font-size:85%">(The product “<code>Foo</code>? does not exist.)</span>
*** Referrals to database data marked up consistently, for example always <code><nowiki><em>xxx</em></nowiki></code><br><span style="font-size:85%">(You must enter a default assignee for component <em>Foo</em>.)</span>
*** Field names marked up consistently, for example always <code><nowiki><em>xxx</em></nowiki></code><br><span style="font-size:85%">(The <em>content</em> field can only be used with <em>matches</em> search and the <em>matches</em> search can only be used with the <em>content</em> field.)</span>
*** Examples of valid values marked up consistently, for example always <code><nowiki><b>xxx</b></nowiki></code><br><span style="font-size:85%">(The value “<code>1</code>? in the <em>foo</em> field is less than the minimum allowable value of <b>2</b>.)</span>
** Admin pages:
*** <code>edit*.cgi</code> specific footer links:
**** Make a more relevant part of the text than just the item name active in <code>edit*.cgi</code> because putting just the item name into <code><a></a></code> is not descriptive enough<br><span style="font-size:85%">(<u>Add a product</u> (<u>to classification <em>Foo</em></u>). <u>Edit product <em>Bar</em></u>.)</span>
**** Consolidate the set of links accross admin pages
*** Move away from pages laconically saying “done?
**** After creations and edits: display the edited item
**** After deletions: show the list of same-level items
**** In addition to the before, in all situations: give a sensible list of follow-up options (most current <code>edit*.cgi</code> footers already do a reasoably good job at this, some could do with some looking-after)
* Stop misusing <code>h1</code>, <code>h2</code> and <code>h3</code> in <code>header.html.tmpl</code> &ndash; <code>h''x''</code> is intended to be used for page structure, so these should be replaced by CSS class styled <code><nowiki><p></p></nowiki></code>s (or a <code><nowiki><p></p></nowiki></code> containing CSS class styled <code><nowiki><span></span></nowiki></code>s)
=== Bug View Ideas/Patches ===
* Make the [https://bugzilla.mozilla.org/show_bug.cgi?id=99240 bug description editable] or let people [https://bugzilla.mozilla.org/show_bug.cgi?id=262087 bless a comment into the current bug description]
=== Attachment Ideas/Patches ===
* [https://bugzilla.mozilla.org/show_bug.cgi?id=302083 auto-convert uncompressed BMP to compressed PNG] status: ghendricks' patch coded, reviewed, approved, and checked in;
* [http://bugzilla.org/cgi-bin/mj_wwwusr?user=foo@bar.com&passw=&list=developers&brief=on&func=archive-get-part&extra=200507/178 make this comment an attachment] timello suggests we break this up into two separate chunks: [https://bugzilla.mozilla.org/show_bug.cgi?id=302726 moving attachment creation code to Attachment.pm], and [https://bugzilla.mozilla.org/show_bug.cgi?id=302726 adding the UI and functionality into show_bug.cgi]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=300949 optimize UI for viewing attachments]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=102957 redesign edit attachments screen]
* fix loss of "edit as comment" comments when going back to "edit attachment" page (new version of firefox won't have this problem, but other browsers still will; perhaps just submit the page back to the server for "edit as comment"?)
* [https://bugzilla.mozilla.org/show_bug.cgi?id=208827 autodetect attachment type by default] status: in further discussions it seems like we can get rid of content type selection upon attachment creation entirely, since autodetect has a very high degree of accuracy these days.  we can probably also get rid of the "patch" checkbox with a routine that checks text/plain attachments to see if they are patches; we might want to pull in File::MMagic to catch cases where the browser tells us the wrong thing
* [https://bugzilla.mozilla.org/show_bug.cgi?id=252782 inline image attachments]
* [http://bugzilla.mozilla.org/show_bug.cgi?id=302669 include attachment data in "export bug" XML output] status: ghendricks' patch coded, reviewed, approved, and checked in
* [https://bugzilla.mozilla.org/show_bug.cgi?id=5179 submit an attachment while entering a bug] this will benefit from the abovementioned attachment creation refactoring
* make attachment creation work when choosing reviewer on intermediate screen
* [https://bugzilla.mozilla.org/show_bug.cgi?id=149504 let users attach multiple URLs/references] to a bug when that makes more sense than attaching the file
* let administrators enter multiple versions/platforms/operating-systems at once
* [https://bugzilla.mozilla.org/show_bug.cgi?id=302372 Requestee input field is way too small] - Patch coded, reviewed, approved, and checked in;
* [https://bugzilla.mozilla.org/show_bug.cgi?id=292022 let users multi-request] at the same time by accepting multiple addresses in the requestee field and always showing the "addl. flag" UI - Patch coded, reviewed, approved, and checked in;

Latest revision as of 23:36, 24 November 2015

Retrieved from "https://wiki.mozilla.org/index.php?title=Bugzilla:UI_Hackathon&oldid=1107117"