[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-ui-dev] UI-based bug reporting / feature requesting
|
Leon,
Here are some of my comments about the UI - my opinion only...I'm not
speaking on behalf of the ui team ;-)
I would probably go with a wizard approach. There are lots of fields and it
may be too much for one page to display (however, you may want to quickly
mock it up in some GUI builder just to get a feel for it).
I find most time when reporting a bug, I'm only interested in the summary
and description field - this could be on the first page. The product and
component are the used often. I'm unsure if this should go on the first
page or the second page (probably second page if you are going with the
suggestion in the next paragraph). The rest I find the default values are
usually correct. Once a summary and description is entered, it should be
possible to just "finish" without having to go to the other pages (i.e
defaults should be sufficient).
I would keep info about the various fields to a minimum. Users get
intimidated if there is too much instructions on the page - warning bells
go off in their hear - "this is a complex page...back out". I would use the
help facility to provide more information. Once they know what it is, they
probably do not want it "in their face" all the time. I see the Product and
Component fields needing info about what each value means. One option is to
have a list of Products and Components side by side, with a read-only text
field at the bottom with a description of the currently selected
Product/Component.
I would not provide two ways of entering a problem report (i.e. the novice
and advance user preference you were talking about). Keep the number of
options to a minimum until you get feedback on how people will use it.
Maybe nice to provide a "template" for the description field. It could list
things the user should remember to fill out. It could also automatically
include the build number (most forgotten piece of information I find).
You may also want to keep your public interface names generic (i.e.
IProblemReport instead of IBugzillaBug). Where the problem gets stored
could be plugable (i.e. by default to bugzilla, but maybe someone would
want to provide an extension to save to another bug tracking system).
You should also consider providing a message at the end with the problem
report number created.
Simon :-)
"leon j breedt"
<ljb@xxxxxxxxxxxxxx> To: <platform-ui-dev@xxxxxxxxxxx>
Sent by: cc:
platform-ui-dev-admin@ Subject: RE: [platform-ui-dev] UI-based bug reporting / feature
eclipse.org requesting
03/22/2002 03:40 AM
Please respond to
platform-ui-dev
Hi,
Some update on the progress of this...I've finally gotten around
to starting on this.
How the plugin knows about the
products/priorities/severities/components/platforms
in a particular Bugzilla installation is by way of a metadata file in
XML format. This is a custom format I've come up with since the Bugzilla
XML
DTD only defines structures for bugs, not their categorization and all the
other information associated with them which is only available from the
database (or the localconfig file).
Until there is some way to reliably (without error-prone HTML parsing)
query this information, this file will have to be constructed by hand,
or I will have to write a Perl script to generate one for an installation.
A default metadata file will be shipped with the plugin containing
the information for the Eclipse Bugzilla repository.
The Eclipse-specific actions for the plugin use this metadata file to
retrieve the component/product/platform/os information.
I've completed the parsing for this file, it gets parsed into an
IBugRepository instance, which contains all the relevant product/component
info, and also started on the UI for the reporting.
I'm at the point now where I want to streamline the UI, and I'm wondering
which approach people will find the most workable:
(1) One page like the Bugzilla bug reporting page containing
all the fields required for a bug, with defaults filled
in where possible for the Eclipse build / platform / JVM
information.
(2) Two or three wizard pages that break it down into more
manageable chunks:
- categorization of the bug (with info about the various
categories)
- more detail (description, how-to-reproduce, stack traces)
- more information about the reporter's environment
Or do you think this should be a preference for beginner user and
power user mode...Since I'd really like to provide as much information
as possible to the end user about what the various fields mean and
what the recommended values should be, so that the resultant reports
are useful. On the other hand, I don't want to get in people's way...
Also, how would be the best way for other plugins to access this
functionality, and provide some defaults for the pages...A
method on BugzillaPlugin, providing an already initialized EclipseBugReport
(which contains all the information for the bug)?
Comments?
Leon.
--
ljb@xxxxxxxxxxxxxx :: +27.82.789.0445
>> don't play in the kiln.
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
