UI change for editing groups and products

[Benton, Kevin]

> On Monday 19 September 2005 08:15, Joel Peshkin wrote:
> > I am considering a change to the behvior of editproducts and
editgroups
> > and I would like some input before starting this.
> 
> YAY :-)

Nods.

> > For sites with etremely large lists of products and groups, the
> > editproducts and editgroups initial selection pages are unmanagably
> > long.  At the same time, for small sites, I think we want to take
users
> > directly to the full list of products/groups.
> 
> Ours definitely falls into this category. We are planning on working
with
> classifications now that they are available in 2.20 which will, of
course,
> break up our huge list of products.

How would you propose handling the difference between large groups of
users?  I have to wonder if there isn't some way of associating a
specific list of users with a particular product/component pair and
still make the regex available for users outside that list...

> > I think we have the following options....
> > 1) If there are more than THRESHOLD (50?) items in the list, show
the
> > first 50 and a text box similar to the one in editusers to select a
> > subset by regexp.
> 
> Maybe. However I think it would confuse users as soon as they hit
their
> nth
> product to have the page suddenly change.

If there are more than THRESHOLD users, maybe we should tell them that
we can't display a drop-down list of users because the user's
preferences don't allow us to display a list that large...

> > 2) If there are more than THRESHOLD (50?) items in the list, show
the
> > first 50 and a set of hyperlinks to other groups of 50 (like mailman
> > does...     So, we show from aacme to beowulf, and there is a link
to
> > "show from bugzilla to gcc")
> >
> > 3) Prompt for a regexp just like editusers does today.
> 
> This is a good idea regardless of the number of products listed.

Nods.

> > For any of these options, should THRESHOLD be a param?  A userpref?
> >
> > Any other suggestions?
> 
> Along these same lines it would be good to make the enter_bug page
more
> user
> friendly as well. In our case we have a large group of users with
> different
> reasons for coming to bugzilla. Not all of them know what
classification
> or
> even what product they should enter a bug against. It would be good if
> there
> were a regexp search box on bug entry.
> 
> I am actually working on a way to clean up the enter bug page a
little. I
> am
> toying with taking the classifications and products selection and
putting
> them on a single page instead of having them on separate pages as they
are
> now.
> 
> I envision a classifications dropdown list and a products dropdown
list.
> The
> default selection in classifications would be ALL and the product list
> would
> contain all the products with <optgroup> tags much like it is on the
> specific
> search page. Selecting a classification would refactor the products
list
> to
> only contain products of that classification.
> 
> Selecting either a classification or product would refactor the page
with
> the
> description off to one side of the dropdown. The refactoring could be
> javascript which would make it fast. For those with javascript
disabled, a
> link that displays the page much as it currently exists would be good.
> 
> Thoughts?

Actually, I like the idea of having a table with classifications to the
left, products in the middle, and components to the right (for users
that can support JavaScript).  As the user moves through the product
list, the product and component list will display as the user moves
deeper into that list.  When the user gets to the appropriate
classification/product/component set, they click on the text, sending
the ID's as part of the string.

For users that don't support JavaScript, it seems that we ought to give
them a choice - select from a screen of classifications, products, and
components, or select from a drop-down list, progressing across each
item till we can put them in the usual create_bug.cgi screen.

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.