137855 - classic format for query form

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect, P3)

Description

[Myk Melez [:myk] [@mykmelez]]

Changing the user interface of a program is painful for its end users.  The
query form recently underwent a major transformation.  The old version of the
form should continue to be available to users as an alternative format.

Comment 1

[Matthew Tuck [:CodeMachine]]

How would this work?  Do we want a user preference?  Otherwise I don't see how
we could make this the default except by putting it in custom, wherein we should
ship the old template in contrib or something.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

The way it *should* work is that the old query form is put into default and
called query-classic.html.tmpl, the new query form is put into default and
called query-modern.html.tmpl, and there are both global and user-specific
"default template" preferences.  This isn't likely to happen for 2.16, so I'm
going to do something for b.m.o specifically.

Comment 3

[Gervase Markham [:gerv]]

If only you'd filed this bug earlier; I started the query.cgi templatisation by
making this exact template, and then transforming it into the new format. I kept
a copy, too, but it was on my machine in Mountain View :-|

Gerv

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Hmm, I wish I knew where your machine was.

Comment 5

[Bradley Baetz (:bbaetz)]

Do people find the new format a problem? AIUI, bugscape updated to an earlier
version, which still had all the regressions (no keywords field, default
checkboxes not selected, etc)

What specific problems do people have? We should fix those on the new template
so that they aren't problems, rather than just falling back to the old one.

Or is this a case of people just liking what they already have, and not wanting
to get used to the new look?

Comment 6

[Myk Melez [:myk] [@mykmelez]]

>Do people find the new format a problem?

Yes.

>What specific problems do people have?

Specific problems include the missing keywords field (fixed on the tip), email
fields that are too short (partially fixed on the tip), default email search
being "is" rather than "contains", the vertical orientation of the form (doesn't
make good use of wide screens), multiple search buttons (confusing), and the
isolation of the boolean chart.

>Or is this a case of people just liking what they already have, and not wanting
>to get used to the new look?

That's a trivialization of the problem.  Part of it is people not being used to
the new form, and part of it is actual problems with the layout.  Even if all
the problems with the layout were solved, however (doubtful since there are
trade-offs in it that benefit some users at the expense of others), it's still a
bad idea to drop a change this significant on people's heads without adequate
warning and time to move from one form to the other.

Comment 7

[Andreas Franke (gone)]

CC'ing the designer of the new query page for comments on and possible solutions
of the "specific problems people have" with it, mentioned in comment #6 above.
Note that this doesn't imply that we should not have a "classic" version.

Comment 8

[Bradley Baetz (:bbaetz)]

> Specific problems include the missing keywords field (fixed on the tip),

fixed, and this could be changed in bugscape - ISTR it was a one line change.

> email fields that are too short (partially fixed on the tip),

ditto

> default email search being "is" rather than "contains"

This is fixed on tip, and is just a matter of changing the default query param.

> the vertical orientation of the form (doesn't make good use of wide screens)

The old form didn't really do that either.

> multiple search buttons (confusing) and the isolation of the boolean chart.

Those are design problems which should be fixed in the default, then.

How do you plan on selecting between the 'clasic' vs the current type? The
current ('new') one will be the default still on bmo, right?

Comment 9

[Myk Melez [:myk] [@mykmelez]]

>How do you plan on selecting between the 'clasic' vs the current type?

I'm going to add a "format" parameter.

> The current ('new') one will be the default still on bmo, right?

I'm not sure yet, but I think this is how I'm going to do it.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: classic format templates

This patch contains the templates that implement the classic format of the
query form.  In order to use these templates, you must edit query.cgi, changing
the name of the processed template from "search.html.tmpl" to
"search-classic.html.tmpl".

Comment 11

[Matthew Tuck [:CodeMachine]]

I presume this is not happening for 2.16.  Wouldn't we also need a user pref for
the query page format?

Comment 12

[Myk Melez [:myk] [@mykmelez]]

>I presume this is not happening for 2.16.

No, but it should go into any 2.16 followup release, since some installations
will not want to subject their users to the new form without easing them into it
first (as I am considering doing for b.m.o).

>Wouldn't we also need a user pref for the query page format?

Yes, but that's a different bug.

Comment 13

[Gervase Markham [:gerv]]

> No, but it should go into any 2.16 followup release, since some installations
> will not want to subject their users to the new form without easing them into it
> first (as I am considering doing for b.m.o).

How is providing the old one "easing them into it"? If you provide the old one,
the complainers will still use the old one, and not be "eased into" the new one.
It also means you have to maintain and update two versions of the same template.

This is also the thin end of the wedge. If we provide this, and a user
preference for switching between the two as default, will we have to do the same
when we change the layout of other pages? My view is that this is a problem
created by Bugscape upgrading to the tip at the wrong time, and that (now the
bugs you mention have been fixed) tell people just to get used to it.

In any case, I believe that this change should not be checked into the Bugzilla
trunk, because it puts the burden of maintaining the old interface on the
Bugzilla developers rather than mozilla.org, and it is only users of b.m.o (to
my knowledge) who have objected to the new layout.

Gerv

Comment 14

[Jouni Heikniemi]

>In any case, I believe that this change should not be checked into the Bugzilla
>trunk, because it puts the burden of maintaining the old interface on the
>Bugzilla developers rather than mozilla.org, and it is only users of b.m.o (to
>my knowledge) who have objected to the new layout.

I agree, mostly on the basis that I wouldn't want to see us making prefs for
new/old versions for every file. But if b.m.o folks create a templatized version
of the old page, I can't see why we couldn't check it into contrib as
unsupported - it may be of use to somebody else as well, for various reasons.

For the record: I did receive whines about the new layout from our installation,
but no one is complaining any more - so I think the switch was worth it.

Comment 15

[Myk Melez [:myk] [@mykmelez]]

"Easing them into it" means giving them time to make the transition before
forcing them to make it.  It's bad form to significantly change an interface to
which users have grown accustomed without giving them time to switch to it.  In
the desktop software world, users can forego upgrades or run two versions of a
program at the same time until they have the time to retrain themselves on the
new version.  Web software should provide a similar mechanism.

Perhaps the best solution is for Bugzilla installations to set up staging
installations (separate installations running against the same production data)
with the new interface that run alongside the production installation for a
while, but schema changes make that impossible.  In any case, format files make
it easy to do the same thing with a single installation.

>This is also the thin end of the wedge. If we provide this, and a user
>preference for switching between the two as default, will we have to do the
>same when we change the layout of other pages?

Yes, if the layout changes significantly as opposed to iteratively as has been
the case up to now.  In the past we have added features to pages.  Now we are
redesigning pages wholesale.  It's a good thing, but we need to keep our users
in mind and not force changes down their throats.  It's not as easy for them as
it is for us to accustom to the changes; they're users, not developers.

None of this is b.m.o-specific, either.  I'm the one driving this format because
Bugscape users were accidentally the first to upgrade and happen to have my ear
(they work in my building), but other installations and their users are going to
have the exact same problem (and already have, from Jouni's comment).  This file
should be part of the standard Bugzilla distribution for that reason, and also
because we should be providing good examples for how to use formats in Bugzilla,
and this is a great use for them.

Comment 16

[Matthew T (active 1999-2002)]

| 9.  The practice of releasing early, releasing often frequently causes severe
|     damage to the interface. [...] Similarly, when something has an
|     inefficient design, people get used to the inefficiency, and complain when 
|     it becomes efficient. As a result, more user preferences get added, making
|     the interface worse.
|
<http://mpt.phrasewise.com/discuss/msgReader$173>

Myk mentions six specific problems with the new design. Of these, three have
already been fixed, two were just as much a problem with the old design, and the
remaining one (the two Search buttons) is deliberate, and is hardly `confusing'
relative to the (IMHO) vast reduction in confusion of the new design as a whole.

> "Easing them into it" means giving them time to make the transition before
> forcing them to make it.

Those using the current design were first notified about the new design, and
given a chance to play with it, six months ago
<http://groups.google.com/groups?selm=3C189E24.7CEE92F9%40mailandnews.com>. How
much more time do they want? A year? Two years? Five?

Comment 17

[Myk Melez [:myk] [@mykmelez]]

Playing with the changes is different than putting them to use.  If it wasn't, I
wouldn't spend the week after an upgrade chasing down and fixing regressions.

Yesterday I participated in a focus group of folks who had recently had a
corporate intranet redesign rammed down their throats.  The new design is better
in many ways, worse in some, and has a number of serious bugs (and a bunch of
minor ones) that no one managed to find before the site went into production.

Despite getting notice, everyone in the focus group was dissatisfied with the
new site and even more dissatisfied that they weren't given any time to learn
the new interface (and complain about the bugs, and get them fixed) before the
old one was yanked out from under their feet.

There's a better way to do it, and we have the capability to do it that better
way, so we should.

Comment 18

[Bradley Baetz (:bbaetz)]

I still think that the new version should be the default. Change footer html to
add a link to the classic version, too, if you want (at least temporarily), but
I still think that the new version should be the default.

Give people teh old version if you want, but make bugzilla.mozilla.org/query.cgi
use teh new version.

Comment 19

[Gervase Markham [:gerv]]

I completely agree with mpt's quote from his blog. It summarises extremely well
something I've never been able to write down. :-)

If you think users should have notice of the change, then what's required is a
post to the newsgroups like mpt made (and you shot down.) 

I plan to also post to the newsgroup, asking people who believe the new version
should be the default to mail Myk. He can then weigh up that number of people
against the number of people internally who want the old version as the default,
and make the appropriate decision.

I think bbaetz' plan is an excellent one - whichever is the default, add a link
to the other one in the footer. My prediction is that, if the new one is the
default, hits on the old template will be near-zero after a month.

Gerv 

Comment 20

[Robert Kaiser]

The new query interface is the one reason I really wanted this update to happen
ASAP - after I first had seen the new query form in February on Mozilla Dev
Meeting Europe 2002.

Lots of beginners would be prevented from filing new dupes if the query form
gets a bit more useable for them, this saves time from people who are e.g.
developers and this would give them more time to work for the project. This is
why I think the old query screen can be only an option for advanced users - if
anything - and even then it should be hard find. We should encourage people to
use the better design, not do the opposite.

Comment 21

[Bradley Baetz (:bbaetz)]

As myk points out, query.cgi doesn't accept formats. A simple:

if (defined $::FORM{'format'} && $::FORM{'format'} eq 'old')

before processing the template would do, or you can |cp query.cgi
query-old.cgi|, and change the value there.

I don't think we shoudl be encouraging people to email myk, though. If myk wants
to default to the old version til the second upgrade in July, then I suppose
there are reasons for that, in which case s/old/new above. Both links should be
in the footer, though. It is, however, a bit more complicated then that, because
of the 'edit this query' option. I think we can ignore that, though.

Comment 22

[Bradley Baetz (:bbaetz)]

Bug with the old query form template, only with mozilla (not ns4):

1. Using the old query form, select "mozilla.org" product, and "bugzilla: Other
moz. issues" component.
2. Perform the search
3. Go 'back'

Expected results:

m.o product is selected, and m.o components are shown, but not selected (theres
a mozilla bug on this)

Actual results:

m.o product is selected, but all components are shown AND the second component
on the list is selected (to match that the second one was previously selected).

This is probably some interaction with the other moz bug on this issue, but it
doesn't happen in the new query form.

Comment 23

[Jesse Ruderman]

It looks like this bug was fixed in bug 150703.  myk, since you filed both, you
should have added a link from here to 150703 to avoid making it look like you
were trying to hide the change from people cc'ed on this bug.

Comment 24

[Myk Melez [:myk] [@mykmelez]]

That doesn't make any sense.  First of all, the fix for bug 150703 doesn't fix
this bug at all.  Second of all, why would I have to go out of my way to prove
I'm not hiding something I already public announced I would do?

Comment 25

[Gervase Markham [:gerv]]

This has been done; the template was in use on b.m.o for a while, and is now
deprecated.

Gerv