[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: simpler UI for konqy
From:       Rui Malheiro <rmalheiro () 6mil ! pt>
Date:       2004-01-06 16:41:33
Message-ID: 200401061641.34207.rmalheiro () 6mil ! pt
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Era Terça 06 Janeiro 2004 15:44, e o Aaron Seigo escreveu:
> On January 06, 2004 7:54, Rui Malheiro wrote:
> > Opera uses a single, alteranting stop/reload button. First time I used
> > it, I liked it a lot and didn't find it a bit confusing. I also think
> > that having a single button can be used as a hint to show when the page
> > has finished loading.
>
> Q1. are reload and stop the same action?
> A1. no. the principle of "one element, one action" is therefore invoked.

Actualy I find those two actions to be quite related. And I never want to 
execute them at the same time, so having a "toggle" seems straightforward. 
Actualy it can be seen as "one element, one action". Just that the "stop" 
button is hidden when it doesn't make sense using and the "reload" button 
only appears when it makes. I prefer that behavior to having a "greyed-out" 
button for an action I cannot perform.

> Q2. do we already have means to show when a page is finished loading?
> A2. yes, the stop button disables and the throbber stops.

Erm... I don't say that's the *purpose* of a stop/reload button. Just a useful 
side efect.

> safari also does the toggle between stop/reload thing, but i really think
> that's a mistake. each UI element should have one and only one purpose. the
> book "The Humane Interface" covers the reasons for this quite thoroughly
> (including real-life case studies) but the basic principle is that if a
> button's action changes on you then the user must stop and consider the
> current context (the icon on the button, the state of the application, etc)

In this case, I don't think this would happen. Remember, we would't be 
changing the button's action, we'd be hiding a button that can't be used and 
displaying one that is now available.

> which slows the user down, decreases confidence levels and is just asking
> for a mistake to be made (people aren't great at managing "modes" as
> contexts).
>
> the quest for simplicity should not become an excuse for poor usability.

It would't make a case of "poor usability". At most it might not be the "best" 
but it wouldn't be "poor"...

Anyway, what I'd like to see was this kind of feature being an *option*. 
Regardless of what gets to be the default, giving the user (and eventualy the 
distribution) the chance to choose is IMHO the best.

-- 
Rui Malheiro				Edifício Empresarial 3 - Sala 2.09
Director Técnico				Pólo Tecnológico de Lisboa
6 Mil - Tecnologias de Informação			 Lisboa - Portugal




[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]