--===============1169594921== Content-Type: multipart/alternative; boundary="----=_Part_324_30591658.1193299697311" ------=_Part_324_30591658.1193299697311 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 wrote: > > On 10/24/07, James Richard Tyrer wrote: > > Jos Poortvliet wrote: > > > On 10/24/07, James Richard Tyrer 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 > ------=_Part_324_30591658.1193299697311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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

------=_Part_324_30591658.1193299697311-- --===============1169594921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kde-usability mailing list kde-usability@kde.org https://mail.kde.org/mailman/listinfo/kde-usability --===============1169594921==--