[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>>   \
; &nb \
sp; +-----+<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