Gene Heskett wrote:
On Saturday 18 March 2006 11:34, Rod Engelsman wrote:
Jallan wrote:
And, of course, any interface can be improved, but probably won't be
without constructive criticism.
Jallan
You're on! Here's my constructive criticism for IZ:
1. I used to know how to get to it, but since the site has been
redesigned it takes me far too long to find it. The layout and
navigation of the site is really poor.
I agree totally about the site in general.
However, as to finding IZ, reporting a bug appears as an item in a very
short list on the sitemap, which is accessible from the bottom of most
screens and from the "How Do I List?" in the upper left of most main
screens.
It also appears when pressing the enormous "new user & general info"
button which is hardly to be missed. I doubt that finding it is really
an issue.
But it would help to add "Report a bug" to the "How do I?" list that
appears on other screens in the upper left-hand corner.
Suggestion: Have a link to IZ from the Home page. Maybe under a
section entitled "Get Involved". Test the design with "people from
the street". That's what professional web site designers do.
Some do testing, when they have time and money to do so. This is
probably not possible here ... that money is better spent on actual
development.
2. The issue-filing page is a confusing and intimidating mess. It was
designed for insiders. Altogether too many fields and drop-boxes.
Suggestion: Design a page for "regular users" to report bugs. This
page should have maybe a half-dozen fields and boxes to consider, no
more. A QA member will have to go in and "flesh out" the bug report,
but that happens anyway with the current system.
I don't see this.
A user clicks on "Report a Bug" and gets this screen:
http://qa.openoffice.org/issue_handling/pre_submission.html
This contains a simple search box, as well as a link to a complex,
advanced search screen. Either can be used in a search. A user
intimidated by the advanced screen, which I far prefer personally, need
not use it. Since the user most go to another screen to use it and it is
called "advanced", there is no pressure to use it.
There are some instructions following in point form, each point a link
to another page with fuller instructions ... a well designed way of
providing both basic rules for reporting concisely but also providing
further details if anything is not clear.
The user then clicks on "Go on - submit the issue"
The page that comes contains only one entry box on the screen, allowing
the user to search again if they have not already done so. THe complex
advanced search is not even an option here.
The rest of the screen is just various start points. Now if an
inexperienced user does click on either "• ... by code module (for
hackers to submit patches)" or "• ... the classical way (for the
fearless)", the the inexperienced user is likely to confused. But why
would any inexperienced user do this, except out of pure curiosity? They
would probably just go back to the previous screen.
The eleven fields on the following page are perhaps a few too many ...
especially as some are for use only for reporters actually working on
the project. I suppose a note on the page could state prominently
something like: "Please leave blank any fields you are not sure of."
In fact only 8 fields need be filled in. Four of them are trivial
choices while 2 of them are the submission summary and the submission
itself.
I do not see what the supposed difficulty is. And while this newsgroup
gets numerous requests about how to download, and what JRE is, and so
forth, it gets almost none about how to navigate the bug reporting
procedure.
3. Either pay attention to votes or just forget about it. It's hard
for me to consider the current system as anything more than a farce.
I presume developers do pay "attention" to votes, which is not the same
thing as letting votes direct the project. All things being equal, I
would hope items with higher votes would be considered before items with
a lower vote.
But on projects like this, all things are seldom equal. Fixing A may
depend on fixing B which depends on fixing C. Do you spend three weeks
on a quick fix of problem H, knowing that in a year from now the plan is
to rewrite the entire module in any case, in which case you will be
fixing H twice, once to work with the module as currently written and
again when you create the replacement module.
My own experience is that I've had been least productive on projects
where the end-users or coordinators were micro-managing how and in what
order I did things, continually changing priorities for this and that,
or changing specifications as I worked. Just let me finish A, and then I
will get to B, and you will have B finished the way it should be, later
than you would like perhaps, but done correctly. Otherwise you will get
a buggy B and a buggy A ... and both will be late and I will be
frustrated with continually being yanked back and forth and having to do
things twice.
But if votes are to be tallied and considered, then:
Suggestion: Recognize the effort expended in reporting an issue and
credit the report with an automatic 5 votes. This would also apply to
subsequent issues that are later marked as duplicates of some other
report. When issue X is marked as a duplicate of issue Y, then the
issue Y should inherit issue X's votes.
Moving votes automatically from an issue closed as a duplicate to
another issue is reasonable.
But it is also reasonable that if a user doesn't care enough to return
at least every two or three months and check the issues that the voter
has voted on, then why should anyone else care? This second philosophy
is easiest to implement.
I wouldn't want some of the issues I've reported to get an automatic
five votes. I don't think they are particularly important compared to
many other issues. I have reported them because they are defects or
enhancement requests that should be there to be noted when a developer
gets around to working on those parts of the application, perhaps only
because they are mainly fixing something that most (including myself)
would feel is far more important.
Providing five extra votes to be used as a reporter wished would also be
rather unfair. However much trouble it is to report an issue ... and
properly create a report is something an hour or two of investigation
... it is far more trouble (and far more valuable to the project) to
create patches and actually fix problems) and so forth. I suppose one
could set up some kind of salary of votes for unsalaried workers on the
project for help done for documentation, coding, and anything else.
But then you'd need people to administer this, and respond to complaints
that the fix provided by user A for 100 votes was in fact far less work
and far less valuable than the fix provided by user B for 50 votes.
I don't think anyone wants to go there.
Voting is just a very rough indication of which proposed changes have
some strong support behind them ... and I think should be left as that.
Now ... perhaps one might also provide users with an equal number of
negative votes to use on issues they would rather not see being given
priority or worked on at all. That would help to also more clearly
indicated which supposedly popular issues are also contentious ones.
Rod, spot on. In either BZ or IZ, getting the newbie thru the search
menu's that insist on trying to match your bug with an existing one is
an admirable objective, but it makes it far too hard to get to the page
that actually lets you file the report. This discourages report
fileing by non-developers, so the little itches just don't get
reported.
There is only a single, simple search box, unless the user purposely
chooses the advanced option.
Also, considering the large number of issues reported, I suspect there
are very few issues that don't get reported, even if up to 80% of those
who try to report issues get frustrated ... which I don't believe.
Current developers can't keep up with defect reports, not to speak of
enhancement reports. And again and again I've found things I thought I
might report on or suggest to be already covered. So what point in
spending a great deal of time making what seems to me to be an easy bug
reporting system even easier if in fact the new system wouldn't bring in
more valid reports?
These things really do need to be tested by the man on the street for
usability before they're use is carved in stone.
Nothing is carved in stone. And who will provide the funds for
international testing?
Jallan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
