[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>> \
+-----+<br>> \
<-----|----> | 55%|<br>> &n \
bsp; +-----+<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/mailman/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