46039 - Back / Forward drop down don't show with click and hold

Status: VERIFIED WONTFIX

(Core :: DOM: Navigation, defect, P3)

Description

[johng]

Navigate some, go back and forward.  Click and hold back (or forward) button, 
but drop down does not appear.

Build 2000072008 as well as earlier builds.

Comment 1

[johng]

nsbeta3, regression

Comment 2

[johng]

Note I am only talking about click and hold - feature works if you click the 
tiny arrow.

cc'ing German to confirm that click and hold *should* work.

Comment 3

[Radha on family leave (not reading bugmail)]

John, I was under the impression that we are not going to do the Nav 4.x style 
of Click and hold due to visibility reasons. I understand that we are going 
to do only the tiny arrow like in IE.

Comment 4

[german]

My understanding was that it was desirable to support both modes, for both better 
discoverability and backwards compatibility. I remember somebody (hyatt) having 
stated that click and hold was difficult to impement for this time frame. I do 
not have any usability data to support that we *need* to keep supporting click 
and hold even with this new design though, but I'd imagine that at least for Mac 
and some other 4.x users it would be beneficial.

Comment 5

[Radha on family leave (not reading bugmail)]

I heard from hyatt too that click and hold was tough. This s'd probably go in 
RFE then. This is definitely not regression. This was not working at all at any 
time.

Comment 6

[johng]

nav triage team:
[NEED INFO]
reassigning to Hyatt
Hyatt, how hard is this?

ccing Lake for usability info

Comment 7

[Lakespur Roca]

Thought we have not expressly tested for the click and hold we should recognize 
that the arrow is tinney. This decreases visual recognition as well as the 
percieved click target area making it more difficult to mannipulate. Having both 
really increases the probability that the user will use it and not become 
frustrated.

Comment 8

[Peter Trudelle]

Should have made the button rectangular and the arrow larger. Not adding timer. 
resolving as invalid

Comment 9

[Claudius Gayle]

Invalid! Is that the right answer? You are saying we are never going to have this and moreover we shouldn't?

Never mind the fact that 4.x worked that way on all platforms and click+hold is a common gesture on the Mac?

reopening for reconsideration. Note, I'm not arguing +,- here, I'm just saying it's not invalid

Comment 10

[Peter Trudelle]

Yes, that is exactly what I'm saying, and it is something we have consistently
said for over a year now.  Button widgets are buttons, not some wierd
button/menu monster.  If you want a menu, add a decent-sized arrow. In 4.x, we
also have at least one menu that pops up only on the mouse-UP; would you contend
that we have to reproduce *that* idiocy for backward compatibility? resolving as
invalid, lets not spend any more time on this.  

Comment 11

[Claudius Gayle]

hrmpf. marking VERIFIED although I'm dismayed.

I outuse the menu over the button 10-to-1 and would've
liked to see it made easier to use(bigger arrow doesn't cut it) but oh well.

Comment 12

[german]

I'd like to see this re-opened for beta 3. reasons:
useful for 
a) mac users 
b) peopled used to 4.x

Comment 13

[Brendan Donohoe]

c) anyone who has trouble hitting that tiny little arrow target.

Comment 14

[Peter Trudelle]

No, for these reasons:
0) The time to discuss this was late '98 - early '99, when we made the decision.
(Don't play with dead snakes)
1) The button/menu is an abominable monster, not fit as either a button nor a
menu. (Internal consistency)
2) The current widget design is a defacto standard widget, in use on the vast
majority of desktops. (Do the same as everybody else)
3) There is an easier resolution - don't make the arrow microscopic!
(Conservation of energy)
4) The arrow works quicker, since there is no delay. (Faster is better)
5) Due to time/resource constraints, and reasons 1-4, this isn't even worth
arguing about in the last few weeks before we ship. (End of discussion, get over it)
Note:  I am a Mac user, very used to 4.x, and ready for bifocals. Please, just
make the arrows a reasonable-sized target.  Sacrifice a little visual
stylishness for usability.

Comment 15

[Radha on family leave (not reading bugmail)]

you said it peter

Comment 16

[Claudius Gayle]

filed bug 48303 to see if we can get the arrow a little bigger. (in case we lose this battle :-)

Comment 17

[Brendan Donohoe]

>> 0) The time to discuss this was late '98 - early '99, when we made the 
decision. (Don't play with dead snakes) <<

Hmmm... that's funny.  I remember discussing this quite a while ago and 
getting quite the same response even then: just a curt, unprofessional 
shutting down of discussion.

>> 1) The button/menu is an abominable monster, not fit as either a 
button nor a menu. (Internal consistency) <<

That's your problem, not the users.

>> 2) The current widget design is a defacto standard widget, in use on 
the vast majority of desktops. (Do the same as everybody else) <<

No, it's not a defacto standard widget.  Even so, those buttons that are 
similar have the very same problem.  (Do the same as everybody else 
and you're no better.)

>> 3) There is an easier resolution - don't make the arrow microscopic!
(Conservation of energy) <<

That only solves part of the problem since no matter how large the arrow 
is, it's still hard to hit and the only way to access the menu.  A *better* easy 
solution is to add a right click option to the main button as well (which I 
proposed long ago and was shut down).

>> 4) The arrow works quicker, since there is no delay. (Faster is better) 
<<

WRONG.  Faster is NOT always better.  And in this case, it is NOT faster 
since it is so damn hard to hit.  Larger target = easier to use.

>> 5) Due to time/resource constraints, and reasons 1-4, this isn't even 
worth arguing about in the last few weeks before we ship. (End of 
discussion, get over it) <<

Oh, grow up, would you?  These issues are being raised now because 
the UI group has been told, with EVERY SINGLE MILESTONE, that UI 
bugs will get fixed in the next milestone.  We HAVE been discussing these 
things; some people have chosen not to listen.

>> Note:  I am a Mac user, very used to 4.x, and ready for bifocals. Please, 
just make the arrows a reasonable-sized target.  Sacrifice a little visual
stylishness for usability. <<

Visuals mean nothing if the behaviors aren't right.  "Stylishness" is far 
from our most important concern here.  We don't make these requests 
just to save OURSELVES the trouble of making changes you know.

Comment 18

[Peter Trudelle]

I'm getting very annoyed by this, but we don't really know each other, so I'll
try to be civil. Bugzilla is not a fit medium for such emotional content.  If
you or anyone else wants to insult me, or argue about this, or even discuss it
politely, the place to do that is in person, not in this bug.  Please stop by,
or call a meeting or something.  However, given the product we're supposed to be
finishing in 5 weeks, I'm amazed that this is one of the issues you want to
spend time on.  We must be a lot closer to shipping than I think.

Comment 19

[Matthew T (active 1999-2002)]

FWIW, I agree with Peter here. (And I'm a heavy Mac 4.x user.)

This has been discussed several times. 4.x's buttons were a bad design because of 
temporal inconsistency (hold them down for 0.999 seconds and they do something, 
hold them down for 1.000 seconds and they don't), internal inconsistency (the 
tiny triangles didn't make it obvious enough that some buttons could act as 
menus, some were *only* menus, and some were just buttons), external 
inconsistency (no other software I know of uses the same design), and diminution 
of cancelling ability (drag off the button to cancel it too slowly, and you might 
end up choosing a menu item by mistake).

If you're going to do anything to make the menu part of menubuttons easier to get 
at, I suggest this: allow the user to drag from the button to the menu, or vice 
versa, and have the part of the widget she drags to act as if it has just been 
moused down on. That is, I can mousedown on the Back button, drag to the Back 
menu, and the Back menu opens. Or I can mousedown on the Back menu, drag to the 
Back button, and the Back button enters mousedown state. This would solve the 
problem where I mousedown on the Back button, and then realize that I actually 
wanted to go back more than one page.

Comment 20

[[e-mail]]

If you don't like the menu opening after a short delay, you could open the menu
immediately, but still click (closing the menu) if the mouse is released over
the button. At least you'd avoid confusing Mac owners :-)

Comment 21

[Peter Trudelle]

Clicking outside of an open menu shouldn't have any side-effect other than
closing the menu.  BTW, this isn't about what we, as individuals, like; it is
about what we should do for users, and are able to do in this release.

Comment 22

[[e-mail]]

Sorry, I was commenting on the fact that 4.x used a timer so if you weren't 
careful you could click on the menu that was just about to appear.

Comment 23

[Ariel Shkedi]

I just want to make a point that at least one person I know has decided that he 
hates Netscape 6 because of this one issue and deleted it from his system.

If you need to add a new type of wiget do so, or just start a timer onMouseDown 
and cancel onMouseUp. But this does need to be fixed.

Comment 24

[Viswanath Ramachandran]

nav triage team: not a beta stopper

Comment 25

[David Hyatt]

NOt fixing.

Comment 26

[sairuh (rarely reading bugmail)]

mass-verifying WontFix bugs which haven't changed since 2001-12-31.

use the search string "BoletusEdulis" if you want to filter out this msg.