Re: [Usability] Re: [Epiphany] epiphany toolbar/bookmarks
- From: "Robert A. Thompson" <ucs_rat shsu edu>
- To: Christian Rose <menthos gnome org>
- Cc: GNOME Usability List <usability gnome org>,Epiphany List <epiphany mozdev org>
- Subject: Re: [Usability] Re: [Epiphany] epiphany toolbar/bookmarks
- Date: 01 Jun 2003 12:21:28 -0500
> The goals of most distributions probably isn't to please everyone.
> That's just not possible, especially with some long-time users that have
> gone accustomed to many kinds of different more or less exotic behaviors
> that have appeared in some pieces of software that have ever existed.
agreed but one should not suddenly have to roll their own just to get a
somewhat common feature/function b/c the distro decided to change apps
with out taking into consideration if the app change is a step forward
or backwards(this I've seen happen). I understand sometimes you have to
go backwards b/c for some reason outside your control, but you wouldn't
expect a gnome distribution to say lynx is the default browser. It does
work and it does have a clean, tight, simple interface(hell it is
probably hig compliant) but from the prospect of a gui interfaces that
ship with mozilla, galeon, epiphany, konqueror, and etc I'd say it is a
step backwards. I know this is drastic (and only to make a point),
epiphany does not appear to be a step backwards to _me_(granted it is
lacking in some features but it isn't finished either... you have to
give it a chance).
> The goals of most distributions is probably more in line of providing
> what makes most sense to most of their users or customers. Making
> everyone happy is unrealistic. So sorry, but you will probably never
> ever have a distribution that "just works" for you if you have that many
> special requirements, unless you roll your own.
and should be the goal of the distro. But from a view point of
usability, one shouldn't have to roll their own. If done
right/correctly those in need of special requirements become extremely
low and things will just work. Even in my case, a default redhat has
what I need to "just work" note, I have to configure it somewhat, but
that is understandable.
>
> The problem with this is that clicking with a mouse, for many users,
> isn't exactly a precise enough action. There are all kinds of reasons
> for this, ranging from bad motoric skills, being untrained or at unease
> with the pointing device, to actually crappy hardware (think a crappy
> mouse at the workplace, or a touchpad you'd rather throw out the window
> but can't since it's built-in on the laptop you have to use). Sometimes
> even a combination of those.
>
> That doesn't have to be a problem, for example with buttons. They are
> often big enough to allow for some pointing inaccuracy. In addition,
> they usually have some inactive spacing inbetween, so that the effects
> of a tiny miss need not be that severe.
> Links are worse, they are small pieces of text, usually far more thin
> than a typical button, and easier to miss. Having the mouse click doing
> entirely different actions depending on whether the user clicked one
> pixel away from the link (on the page background) or on the link isn't
> exactly the kind of fault tolerance that we typically require from user
> interfaces.
>
> So no, doing "what is right depending on the context" isn't trivially
> doable, and in some times maybe not even possible given that they may be
> in direct conflict with other goals, be that usability goals or
> accessibility goals or whatever.
I'm guessing mozilla doesn't allow for this in the code as I don't
understand why this could not be done with text links(forgive my
ignornace here). Also to answer the obvious response of sites clustered
with links all over the page, I feel should not be epiphany (or any
other browsers) responsibility. You can't expect a browser to fix poor
site design. The only part that would seem hard or awkward is detecting
when a link is close to the other(leaving overlapping "inactive space")
--rat
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]