[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: Some thoughts on toolbars in KDE
From: "Hans Chen" <hanswchen () gmail ! com>
Date: 2007-10-25 8:08:17
Message-ID: c59230380710250108p4c174be8ge89b226a6932b4f0 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
James: So basically you want to add the "zoom in" and "zoom out" buttons to
the new widget?
Let me try to analyze this with my (non-existing) usability knowledge. If we
consider different use cases; let's say we have a image viewer with this new
widget in the statusbar, and four different persons:
User A wants to zoom in/out until the image covers the whole page.
User B is just playing around and zooms in/out until s/he thinks it looks
good.
User C wants to zoom to half the original size, original size, double size
etc.
User D has a predefined % s/he want to zoom, let's say 137 %.
Now let's take a took at my mockup again (and imagine that the combobox is a
normal edible combobox on hover).
A: Use one of the buttons to the left (these aren't shown in my mockup) or
the combobox.
B: Here a set of zoom in/out buttons would be useful. If you have a mouse
with a scroll, you can obtain the same result by scrolling the slider. And
if you aren't pedantic you could also drag and/or click on the slider (the
former one faster than clicking on the buttons and probably give better
results).
C: These "common" zoom levels are in the combobox (you can use the
scroll/keyboard)
D: Click in the combobox and enter a value.
Personally I think the slider is superior to zoom in/out buttons. As I wrote
above, it does the same if you have a scroll/know that you can use the
keyboard - but you can also drag the slide to quickly find a zoom level you
like. This would be perfect in use case B.
Furthermore, I think there are enough widgets in the zoom widget - in my
opinion it would look cluttered if we added more.
If an application really need the "click to zoom in/out", I would suggest a
zoom tool in the toolbar which changes the mouse to a magnifier (take a look
at kpdf (KDE3.5.x) for example) and lets you zoom by clicking on the
image/whatever it is.
With best regards,
Hans Chen
On 10/24/07, Jos Poortvliet <jospoortvliet@gmail.com> wrote:
>
> On 10/24/07, James Richard Tyrer <tyrerj@acm.org> wrote:
> > Jos Poortvliet wrote:
> > > On 10/24/07, James Richard Tyrer <tyrerj@acm.org> wrote:
> > >> Here we are.
> > > Ok, so your point was that the widget proposed (from KOffice) doesn't
> > > make clear you can enter text, KCC does a better job? The fact some
> > > ppl don't see the text input field in editable comboboxes shouldn't be
> > > a reason to remove the comboboxpart and make it only an editable
> > > field, right? Or don't I get your point?
> > >
> > > About KPlayer, that's better than the KOffice widget? You can't enter
> > > or choose a value, I think it sucks...
> > >
> > > I guess I just didn't understand you, could you elaborate a bit more?
> > >
> > The original proposal was for a widget like with a slider with a small
> > triangular button ('<' & '>' in the diagram) at each end and a box with
> > no buttons. The box would be copyable and editable. You could make
> > course adjustments with the slider and the buttons on the ends would
> > move it exactly one unit per press.
> >
> > +-----+
> > <-----|----> | 55%|
> > +-----+
> >
> > This was originally proposed because developers sometimes use both a
> > slider and a spin box and it is a bit awkward. Or, people might want to
> > use only the slider and button part. I would like to see the slider be
> > a fixed length since these too long sliders are not that easy to use and
> > you don't need the length for resolution since you can use the step
> buttons.
> >
> > The other image shows the volume control toolbar widget from KPlayer.
> > It is just a standard square icon till the mouse moves over it and then
> > the adjustable part pops up. The same (similar) could be used for the
> > zoom list.
>
> OK, now I get it.
>
> So compared to the mockup, you'd add buttons with +/- or arrows like <
> --- > around the slider and get rid of the dropdown and turn it into a
> normal text entry widget.
>
> Hmmm. Well, you DO lose the ability to choose options from a dropdown
> menu, of course. But there currently are buttons for the most
> important things you might choose (fit page and fit width).
>
> I think it IS very slightly easier to use, though I do wonder if it's
> really needed. A combobox in which you can type is used all over the
> modern GUI - on windows, mac and Linux. Getting rid of it doesn't
> help, ppl have to learn to use them anyway - and it's not very hard.
>
> Same with a slider. People know how to use them, a +/- isn't really
> needed.
>
> So.
>
> 1. This is a very very minor issue, we're bikeshedding. But now we're
> on it anyway:
> 2. It would mean a slight improvement to very new users on one hand,
> but as both concepts we're trying to avoid are used everywhere, that
> won't help (one could even say it makes things less consistent, esp
> with the < -- > buttons). Those buttons also take space.
> 3. The mockup is slightly more powerful, having the drop-down options.
>
> Taken together, I think I would go with the mockup. We do focus more
> on ppl who use their computer more than 2 hours a day anyway, within
> KDE. Let G go for the dumbed down approach, I'd say.
>
>
> Anyway, considering the un-imporance (and vagueness) of this issue, if
> someone with deeper usabilityknowledge could give convincing numbers
> on the issues this tries to solve, I would consider that interesting.
> But as it stands now, further discussion is imho a waste of time.
>
>
> take care,
>
>
> Jos
> > --
> > JRT
> >
> > _______________________________________________
> > kde-usability mailing list
> > kde-usability@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-usability
> >
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
>
[Attachment #5 (text/html)]
James: So basically you want to add the "zoom in" and "zoom out" \
buttons to the new widget?<br><br>Let me try to analyze this with my (non-existing) \
usability knowledge. If we consider different use cases; let's say we have a \
image viewer with this new widget in the statusbar, and four different persons: \
<br><br>User A wants to zoom in/out until the image covers the whole page.<br>User B \
is just playing around and zooms in/out until s/he thinks it looks good.<br>User C \
wants to zoom to half the original size, original size, double size etc. <br>User D \
has a predefined % s/he want to zoom, let's say 137 %.<br><br>Now let's take \
a took at my mockup again (and imagine that the combobox is a normal edible combobox \
on hover).<br><br>A: Use one of the buttons to the left (these aren't shown in my \
mockup) or the combobox. <br>B: Here a set of zoom in/out buttons would be useful. If \
you have a mouse with a scroll, you can obtain the same result by scrolling the \
slider. And if you aren't pedantic you could also drag and/or click on the slider \
(the former one faster than clicking on the buttons and probably give better \
results). <br>C: These "common" zoom levels are in the combobox (you can \
use the scroll/keyboard)<br>D: Click in the combobox and enter a \
value.<br><br>Personally I think the slider is superior to zoom in/out buttons. As I \
wrote above, it does the same if you have a scroll/know that you can use the keyboard \
- but you can also drag the slide to quickly find a zoom level you like. This would \
be perfect in use case B. <br><br>Furthermore, I think there are enough widgets in \
the zoom widget - in my opinion it would look cluttered if we added more.<br><br>If \
an application really need the "click to zoom in/out", I would suggest a \
zoom tool in the toolbar which changes the mouse to a magnifier (take a look at kpdf \
( KDE3.5.x) for example) and lets you zoom by clicking on the image/whatever it \
is.<br><br>With best regards,<br>Hans Chen<br><br><div><span class="gmail_quote">On \
10/24/07, <b class="gmail_sendername">Jos Poortvliet</b> < <a \
href="mailto:jospoortvliet@gmail.com">jospoortvliet@gmail.com</a>> \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 10/24/07, James Richard \
Tyrer < <a href="mailto:tyrerj@acm.org">tyrerj@acm.org</a>> wrote:<br>> Jos \
Poortvliet wrote:<br>> > On 10/24/07, James Richard Tyrer <<a \
href="mailto:tyrerj@acm.org">tyrerj@acm.org</a>> wrote:<br>> >> Here we \
are. <br>> > Ok, so your point was that the widget proposed (from KOffice) \
doesn't<br>> > make clear you can enter text, KCC does a better job? The \
fact some<br>> > ppl don't see the text input field in editable comboboxes \
shouldn't be <br>> > a reason to remove the comboboxpart and make it only \
an editable<br>> > field, right? Or don't I get your point?<br>> \
><br>> > About KPlayer, that's better than the KOffice \
widget? You can't enter <br>> > or choose a value, I think it \
sucks...<br>> ><br>> > I guess I just didn't understand you, could \
you elaborate a bit more?<br>> ><br>> The original proposal was for a widget \
like with a slider with a small <br>> triangular button ('<' & \
'>' in the diagram) at each end and a box with<br>> no \
buttons. The box would be copyable and editable. You could \
make<br>> course adjustments with the slider and the buttons on the ends would \
<br>> move it exactly one unit per \
press.<br>><br>> &nbs \
p; +-----+<br>> \
<-----|----> | 55%|<br>> \
+-----+<br>><br>> \
This was originally proposed because developers sometimes use both a <br>> slider \
and a spin box and it is a bit awkward. Or, people might want to<br>> \
use only the slider and button part. I would like to see the slider \
be<br>> a fixed length since these too long sliders are not that easy to use and \
<br>> you don't need the length for resolution since you can use the step \
buttons.<br>><br>> The other image shows the volume control toolbar widget from \
KPlayer.<br>> It is just a standard square icon till the mouse moves over it and \
then <br>> the adjustable part pops up. The same (similar) could be \
used for the<br>> zoom list.<br><br>OK, now I get it.<br><br>So compared to the \
mockup, you'd add buttons with +/- or arrows like <<br>--- > around the \
slider and get rid of the dropdown and turn it into a <br>normal text entry \
widget.<br><br>Hmmm. Well, you DO lose the ability to choose options from a \
dropdown<br>menu, of course. But there currently are buttons for the \
most<br>important things you might choose (fit page and fit width). <br><br>I think \
it IS very slightly easier to use, though I do wonder if it's<br>really needed. A \
combobox in which you can type is used all over the<br>modern GUI - on windows, mac \
and Linux. Getting rid of it doesn't <br>help, ppl have to learn to use them \
anyway - and it's not very hard.<br><br>Same with a slider. People know how to \
use them, a +/- isn't really needed.<br><br>So.<br><br>1. This is a very very \
minor issue, we're bikeshedding. But now we're <br>on it anyway:<br>2. It \
would mean a slight improvement to very new users on one hand,<br>but as both \
concepts we're trying to avoid are used everywhere, that<br>won't help (one \
could even say it makes things less consistent, esp <br>with the < -- > \
buttons). Those buttons also take space.<br>3. The mockup is slightly more powerful, \
having the drop-down options.<br><br>Taken together, I think I would go with the \
mockup. We do focus more<br>on ppl who use their computer more than 2 hours a day \
anyway, within <br>KDE. Let G go for the dumbed down approach, I'd \
say.<br><br><br>Anyway, considering the un-imporance (and vagueness) of this issue, \
if<br>someone with deeper usabilityknowledge could give convincing numbers<br>on the \
issues this tries to solve, I would consider that interesting. <br>But as it stands \
now, further discussion is imho a waste of time.<br><br><br>take \
care,<br><br><br>Jos<br>> --<br>> JRT<br>><br>> \
_______________________________________________<br>> kde-usability mailing list \
<br>> <a href="mailto:kde-usability@kde.org">kde-usability@kde.org</a><br>> <a \
href="https://mail.kde.org/mailman/listinfo/kde-usability">https://mail.kde.org/mailma \
n/listinfo/kde-usability</a><br>><br>_______________________________________________
<br>kde-usability mailing list<br><a \
href="mailto:kde-usability@kde.org">kde-usability@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/kde-usability">https://mail.kde.org/mailman/listinfo/kde-usability</a><br>
</blockquote></div><br>
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic