Feedback on current prototype v0.8

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Feedback on current prototype v0.8

Andreas Schuderer
Hi there,

To get out of the current deadlock situation (one waits for more  
*info* about prototypes, the other for *feedback* about prototypes),  
I'd like to try to give feedback about the current prototype (v. 0.8,  
July 2 2009).

As mentioned in my previous messages, I'm not exactly sure about the  
scoping of the prototype. It's kind of hard to guess what properties  
of the prototype I should give feedback on, and what properties should  
be generously overlooked as they're not within the scope of the  
prototype. I'll try to do my best to constrain myself to aspects where  
I can be pretty sure that they're an explicit "try-me-out" part of the  
prototype.

The order in which I give feedback on the elements does not reflect my  
opinions about which elements are more important, better or worse.  
Some parts of the feedback (e.g. on succesive variant numbers) build  
on each other. I've made this explicit where it is the case. So please  
also read the feedback on XY, Variant 1 and 2, even if you're  
currently only interested in feedback on XY, Variant 3

As a premature conclusion of my feedback, I find the approach of  
scrolling toolbars promising as it just gives a more empowering  
experience. But it also poses new practical problems.


1. Slide pane

- For my taste, spacing is too generous, and the font size of the  
slide labels/numbers can be reduced. There need not be any space  
between the slide and the highlight box AND between the highlight box  
and the slide pane border. Just make the highlight box a *little* (4px  
or so) bigger than slide+label and make it go up to 1px to the edge.

- Also, I don't think you need the redundant numbering with and  
without the word "slide". If "slide 1" in the prototype in fact stands  
for a user-determinable slide title, please put the slide number on  
the same line as the slide title (instead of left of the slide) to  
save some horizontal space. Having both just wastes space.

- The slide preview in the side bar updates instantly when I change  
something on the slide. I like this.

- I like the smooth scrolling when you change the slide using the  
arrow keys and hit the upper or lower edge of the slide pane. It helps  
you understand that you've actually moved a slide up and down. But  
it's slow and leaves the (false, but felt) impression that it slows  
you down. The scrolling animation can be made *much* quicker without  
risking it's spatial orientation benefits. Right now the animation  
takes about 1000ms. In my opinion, it can be reduced to as little as  
250ms.
- Scrolling in the slide pane using the scroll wheel is much too  
sensitive. I always overshoot when using the scroll wheel.

- Selecting/changing slides using the scroll wheel is a new idea, but,  
not a good one. I'm on slide 1, and I just want to scroll down to  
slide # 7 (not select it) to compare the rough layout in the preview  
-- and my current slide in the main content area has changed! This has  
the potential to confuse the heck you. I don't expect scrolling to  
change what is visible in another content area than the actual scroll  
area, let alone change the selected slide. Not good. And just imagine  
someone being about to delete a slide, and just wanting to double-
check that another slide is in place before deleting: By scrolling  
about and hitting delete, he might actually delete the *wrong* slide.  
Data loss around the corner.

- Related to the previous point, smooth scrolling is annoying when  
combined with scroll wheel use. Even when reducing my system's scroll  
wheel sensitivity (turning scrolling in other apps to a crawl), I  
never end up on the intended scroll position, because, when I'm done  
scrolling, the scroll area always scrolls a bit further than expected.

- I find the mouse-over highlighting too prominent

2. Panes resizing/showing/hiding

- It's great that maximizing/minimizing the sidebar and speaker notes  
is now actually a continuum that merges with the concept of  
"resizing"! Very easy to grasp, very clean. I hope that this means  
that this unified concept will completely replace "open/close" (i.e. I  
hope that you'll get rid of open/close, now that they're not needed  
any more).

- The resizing handle is visible and wide enough to hit easily. It  
would even be more perceivable as a handle if it had a groove over the  
whole length. It's good that the whole border acts as a dragging  
handle (not just the dot in the middle).

- The maximize/minimize arrows are a really good idea. With the close  
button, the pane was just "gone" and you didn't know how to get it  
back. Now, you always know how to get it back, and the concept of  
"closing" doesn't exist any more, just "(min/max) resizing". Great!

- Unfortunately, the max/minimize arrows are hard to hit. Increasing  
the area (by increasing their size in the border's dimension = width)  
would probably help.

- Some very subtle 3d-ish appearance (outset/elevated) would help the  
max/min arrows get recognized as a clickable element quicker. (I'd  
prefer this over the alternative of tooltips/highlights, which only  
give away their "I'm interactive" clue when actually mousing over them.)

3. Slide (content) area

- Spacing is adequate. Not too crowded, not too wasteful.

- I understand that the red border exists to indicate the connection  
to the red highlight box in the slide pane. I don't think this is  
necessary. I find that such a color/contrast around your slide  will  
distract from the appearance of the slide itself. This problem of  
course depends on how artistic you're trying to be with your slides  
(There's now danger if you just use bullet points). But it makes it  
more difficult to judge whether you got the color scheme *within* the  
slide right.

- Yellow overview circle: Wow, THIS is REALLY neat! I see the  
(theoretic) problem that it sort of competes against the function of  
the scroll bar, but it's just SO much easier to hit and always zooms  
out to the "view all" level. Double-click and zoom in on another  
slide. Exposé for your slides. I would use his all day (but it needs  
an easy keyboard shortcut!). Two thumbs up. :D

- Double-clicking to zoom OUT. This is *very* prone to errors.  
Elements are frequently double-clicked (heck, many people even double-
click just to select something). If you miss your target (e.g. a thin  
line), you get punished by having your view zoomed out. And what about  
the behavior of double-clicking into non-filled vs. bgcolor-filled  
rectangles? Sure, having the whole slide as a click-target instead of  
just the yellow circle is faster. But IMO this is not worth the risk  
of annoying people trying to double-click a line in the attempt of  
giving the line a text label.

4. Status bar

- I don't see the purpose of the "rectangle selected", "text selected"  
messages. Accessibility?

- Outline/Sorter/3DView: None of these work. 3DView messes up the  
screen, but doesn't show anything.

5) FixedLabel Toolbar Variant 1:

- Overall appearance is pretty clean.

- I like it that there is no "open group on mouseover/hover" stuff.  
These often lead to unwanted changes right before a click (when  
diagonally mousing over another group tab towards an icon in another  
tab), or, in the case of hover timeouts, to timeouts being either too  
long or too short, depending on the user.

Dark gray row:

- I like the consistent use of the triangle selection indicator around  
the interface! I find it much better than tab-like selection  
indication both in terms of appearance and appeal, as well as in  
clarity. It's shape unambiguously makes clear whether the entity which  
the selection applies to lies to the left, right, top or bottom of the  
indicator. Very neat and innovative! This beats tabs-with-rounded-
corners-at-the-far-edge any day!

- Positioning, Spacing, Color, contrast and highlighting of the Home/
Insert/Slide/... text items is okay. Their font could be a little  
smaller. Choose a non-bold, easy-to-read font like Gill Sans and save  
space. You can give the text an inset appearance to improve contrast.  
This applies to all black text on gray background on the interface  
(cf. iWork).

- I find the naming of the "Home" category pretty bad (sorry!). It  
doesn't convey at all what I'll find inside. Reminds me of the  
"Extras" menu in the German Microsoft Office localization. I admit  
that this terminological vagueness doesn't do much harm in isolation.  
But it may contribute to a user image where the naming of elements is  
being discarded as "arbitrary" or "non-helpful", and actually useful  
usage hints are being discarded, the user instead clicking through all  
the menus "to make sure" they don't miss the function they're looking  
for. I've seen this with various users on MS Office.

- The tiny icons (open/save/print/hyperlink (?)/image/..../show) are  
easy-to-spot and also big enough (they're not frequently used when  
working on a presentation).

"Home" group icons:

- Generally, nice big icons. Good contrast. Button-appearance affords  
clicking. I like.

- Please lose the text shadow under the icon labels. It reduces  
contrast and makes stuff harder to read. Small, non-bold Gill Sans +  
Inset effect looks perfect to me for the icon labels.

- Too much vertical spacing, particularly under the icon labels.

- In my opinion, the group labeling above the icons (Insert Shape/
Color/...) is not necessary. This introduces another hierarchy level  
between main groups (Home/Insert/...) and the buttons, which needs to  
be named consistently and introduces names and concepts the user can  
very well deal without. We already have spacing between the groups.  
This is enough to make clear that they are different. The button names  
suffice, and in the case where it doesn't, the button's tooltips show  
first-time-users what would happen if they clicked on it.

- The checkbox to the bottom right of the "Insert Shape" surprisingly  
opens a menu with star shapes. It's (a) too far from the star button  
and (b) redundant with the star button itself.

- The star button has a dark corner to signify that it acts as a menu  
with a choice of star shapes. What about using the conventionally  
established "down arrow" symbol instead of the dark corner? Maybe  
another clue could be shown when mousing over the button, but this may  
not be necessary when the button's appearance itself is improved  
sufficiently.

- The star shape submenu smartly reuses the triangular "belongs-to"  
indicator. Looks good, but unfortunately results in the menu being a  
bit too far from the original mouse position. What I DO very much  
like, is that the items are arranged horizontally, which has a lot of  
benefits: It makes use of angular mouse movement with all its benefits  
against linear movement. Furthermore, it reduces the distance to the  
most extreme positions (Fitts' Law++). And it places the "most  
default" option DIRECTLY under the mouse cursor. This is a great  
improvement against standard vertical dropdown menus! I also like how  
the rest of the window subtly dims to let the menu stand out in higher  
contrast.

- When clicking an insert shape button, there's no indication that I'm  
now in "insert shape X" mode (i.e. that clicking in the content area  
will have a different effect than on other times). Mode errors may  
happen.

- I sort of miss an approach towards text formatting.

- Insert > Insert Slide: Hmm, I'm probably contradicting myself  
regarding monotony, but what do you think of the idea to additionally  
put a tiny "+"-icon in the edge of the slide pane. Law of proximity: +  
& slide pane = new slide.

6. FixedLabel Toolbar, Variant 2:

- Only the tab coloring is different from Variant 1 (mauve color),  
right? I found the tab coloring in Variant 1 better. Boxes are not  
necessary to make clear that the text items are clickable and clicking  
them selects something (clearly indicated by the triangular selection  
indicator). In fact, I find that the boxes add clutter. The spacing  
between the items completely suffices to separate them from each other.

7. When clicking Tabbed toolbar: Variant 1,  The toolbar vanishes.  
Nothing else happens.

8. Scrolling Toolbars, Variant 1:

- All of my praise/criticism on "FixedLabel, Variant 1" also applies  
here, except of course for the different "tab" selection.

- I REALLY like the feeling of working with a continuous row of  
functions instead of discrete "panels" of functions. I can't really  
say why, but it gives me a feeling of empowerment, of being in control  
and able to explore more freely. An illusion maybe, but nevertheless a  
good experience.

- I now see the item names (Home/Insert/...) as "bookmarks" or  
"shortcuts" to a particular set of functionality instead of "tabs".  
This (to me) seems less intimidating.

- I would lose the left and right arrows. Coming from Firefox, I at  
first thought they would act like the arrows that appear in the  
Firefox tab bar when having too many tabs to fit in the bar. I thought  
they would scroll the *dark grey* items, not the buttons above.

- Please make the scroll wheel work (horizontal scrolling for systems  
that support it [Mac]).

- Make mouse wheel scrolling continuous (the lack of continuous  
scrolling sort of stumps my feeling of empowerment and free  
exploration), and get rid of the dark borders that signify groups.  
Instead, *prefix* every group with its label to the left with vertical  
letters. Something like this:
http://schuderer.net/pub/OOo-horiz-scrolling-toolbar-grouping.png

To avoid a misunderstanding: By continuous scrolling, I don't mean  
that clicking the "scroll bar" at a particular position should scroll  
exactly to this position, possibly coming to rest somewhere inbetween  
two groups. Clicking on an item name should still bring you exactly to  
its position, same as now.

- Scrolling should be quicker when clicking on an item, about  
300-500ms. Ideally with ease-in and ease-out. The amount of time it  
takes should be constant, i.e. scrolling happens faster for faraway  
targets.

- I realize that some of the problems concerning grouping/organization  
would probably be alleviated when scrolling would be vertical. What do  
you think about trying a vertical scrolling toolbar?

Side note: I've just looked at scrolling toolbars the first time  
today. Funnily, just yesterday, I tried to figure out something very  
similar for my "scrolling sidebar" proposal. I wrote down some  
thoughts on the discussion page which might also apply here. There is  
also an approach on how to consolidate item highlighting with free  
scrolling. See
http://wiki.services.openoffice.org/wiki/Talk:Proposal_by_Andreas_Schuderer 
  (second and third list item)

9. Scrolling Toolbars, Variant 2:

- The yellow blobs increase contrast, but don't add much. The  
prototype's interface freezes immediately in Variant 2.

10. Scrolling Toolbars, Variant 3:

- My remarks on Variant 1 also apply here, except where otherwise noted.

- I preferred it when the scroll position indicator (moving semi-
transparent bar) stayed the same size and indicated the length of the  
whole toolbar, a feature we know from scroll bars.

- The scroll position indicator changes length as it moves over the  
items. This looks wobbly and unsteady. Watching it wobble its way from  
the first to the last item looks quite amusing.

- The arrow keys now scroll continuously. As I stated in (8.),  
continuous scrolling is good, but I still don't think we need the  
arrow buttons (cf. Firefox, where very similar arrow keys act very  
differently). Again, mouse wheel scrolling would be great. (cf. 8.)

11. Scrolling Toolbars, Variant 4:

- My remarks on Variant 1 and 3 also apply here, except where  
otherwise noted.

- Scroll position indicator length issue resolved (cf. Variant 3).

- The coloring is now more subtle, but to me, it still doesn't look as  
slick as in Variant 1.

- Scrolling speed is still an issue (time, not speed should be  
constant). 300-500ms. (See 8.)

- Lose arrow buttons (see 8.)

- Grouping issues (see 8.)

- Are you still awake?



I'm curious whether you'll find this feedback helpful.

Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Feedback Impress Prototype 0.8 / July 13 2009

Andreas Schuderer
Hi again,

I've looked at the prototype from 13 July.

What appears to be new in this prototype are the "x, +, 2" buttons in  
the slide pane:

Positive about the the "x, +, 2" buttons:
- Functions of "delete", "new slide below" and "duplicate" are near  
the slide they apply to.
- These functions are made visible and thus discoverable.
- Are easy-to-hit with the mouse.
- Color coding suggests that + and 2 belong to each other.

Negative about the the "x, +, 2" buttons:
- On first sight I mistook them for some sort of meta information to  
the slides -- not as clickable elements. Maybe stuff them in some sort  
of "panel" and/or give them an appearance that affords pressing.
- It took me pretty long to figure out that "2" was supposed to mean  
"duplicate", even after clicking it multiple times. Maybe another  
symbol can be tried. When clicking it, I noticed that something  
changed in the slide pane, but I didn't recognize the change as a  
duplication of the current slide. Maybe animation can help?
- Colors: Red/green are problematic because of color-blindness.  
Contrast between red and the selection border is very low.

By the way: I'm really impressed about the quality and richness of the  
prototypes. And this in such a short amount of time! Do you use a  
specific prototyping framework?

Cheers,
Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Feedback on current prototype v0.8

Frank Loehmann
In reply to this post by Andreas Schuderer
Hi Andreas,

Andreas Schuderer wrote:
> Hi there,
>
> To get out of the current deadlock situation (one waits for more
> *info* about prototypes, the other for *feedback* about prototypes),
> I'd like to try to give feedback about the current prototype (v. 0.8,
> July 2 2009).
Andre is currently checking the deadlock issue.

>
> As mentioned in my previous messages, I'm not exactly sure about the
> scoping of the prototype. It's kind of hard to guess what properties
> of the prototype I should give feedback on, and what properties should
> be generously overlooked as they're not within the scope of the
> prototype. I'll try to do my best to constrain myself to aspects where
> I can be pretty sure that they're an explicit "try-me-out" part of the
> prototype.
>
> The order in which I give feedback on the elements does not reflect my
> opinions about which elements are more important, better or worse.
> Some parts of the feedback (e.g. on succesive variant numbers) build
> on each other. I've made this explicit where it is the case. So please
> also read the feedback on XY, Variant 1 and 2, even if you're
> currently only interested in feedback on XY, Variant 3
>
> As a premature conclusion of my feedback, I find the approach of
> scrolling toolbars promising as it just gives a more empowering
> experience. But it also poses new practical problems.
>
>
> 1. Slide pane
>
> - For my taste, spacing is too generous, and the font size of the
> slide labels/numbers can be reduced. There need not be any space
> between the slide and the highlight box AND between the highlight box
> and the slide pane border. Just make the highlight box a *little* (4px
> or so) bigger than slide+label and make it go up to 1px to the edge.
We are working on a mid fidelity prototype. Please ignore sizes of
icons/elements and it's design or color. We want to test the interaction
and how we have to group elements in the toolbars.
>
> - Also, I don't think you need the redundant numbering with and
> without the word "slide". If "slide 1" in the prototype in fact stands
> for a user-determinable slide title, please put the slide number on
> the same line as the slide title (instead of left of the slide) to
> save some horizontal space. Having both just wastes space.
Also a detail, but I am not sure if we need the user defined slide name
at all, because it is rarely used.
>
> - The slide preview in the side bar updates instantly when I change
> something on the slide. I like this.
Agree. It works better than in the current product :-)
>
> - I like the smooth scrolling when you change the slide using the
> arrow keys and hit the upper or lower edge of the slide pane. It helps
> you understand that you've actually moved a slide up and down. But
> it's slow and leaves the (false, but felt) impression that it slows
> you down. The scrolling animation can be made *much* quicker without
> risking it's spatial orientation benefits. Right now the animation
> takes about 1000ms. In my opinion, it can be reduced to as little as
> 250ms.
Yes, we have to take care that this must not influence the rating of the
feature itself. Same is true for the 3d view. We will do fine tuning
before we finish the prototyping phase end of next week.
> - Scrolling in the slide pane using the scroll wheel is much too
> sensitive. I always overshoot when using the scroll wheel.
Agree. Zooming out (Ctrl+Scroll wheel) is too slow. We have to tweak
this during finalization.

>
> - Selecting/changing slides using the scroll wheel is a new idea, but,
> not a good one. I'm on slide 1, and I just want to scroll down to
> slide # 7 (not select it) to compare the rough layout in the preview
> -- and my current slide in the main content area has changed! This has
> the potential to confuse the heck you. I don't expect scrolling to
> change what is visible in another content area than the actual scroll
> area, let alone change the selected slide. Not good. And just imagine
> someone being about to delete a slide, and just wanting to
> double-check that another slide is in place before deleting: By
> scrolling about and hitting delete, he might actually delete the
> *wrong* slide. Data loss around the corner.
Need to discuss this with the team. Personally I think this should only
scroll the view. The normal view, showing one slide at a time, should
scroll to next slide if the end of the current slide has been made visible.
>
> - Related to the previous point, smooth scrolling is annoying when
> combined with scroll wheel use. Even when reducing my system's scroll
> wheel sensitivity (turning scrolling in other apps to a crawl), I
> never end up on the intended scroll position, because, when I'm done
> scrolling, the scroll area always scrolls a bit further than expected.
>
> - I find the mouse-over highlighting too prominent
Agree, but this also a detail.

>
> 2. Panes resizing/showing/hiding
>
> - It's great that maximizing/minimizing the sidebar and speaker notes
> is now actually a continuum that merges with the concept of
> "resizing"! Very easy to grasp, very clean. I hope that this means
> that this unified concept will completely replace "open/close" (i.e. I
> hope that you'll get rid of open/close, now that they're not needed
> any more).
>
> - The resizing handle is visible and wide enough to hit easily. It
> would even be more perceivable as a handle if it had a groove over the
> whole length. It's good that the whole border acts as a dragging
> handle (not just the dot in the middle).
>
> - The maximize/minimize arrows are a really good idea. With the close
> button, the pane was just "gone" and you didn't know how to get it
> back. Now, you always know how to get it back, and the concept of
> "closing" doesn't exist any more, just "(min/max) resizing". Great!
>
> - Unfortunately, the max/minimize arrows are hard to hit. Increasing
> the area (by increasing their size in the border's dimension = width)
> would probably help.
>
> - Some very subtle 3d-ish appearance (outset/elevated) would help the
> max/min arrows get recognized as a clickable element quicker. (I'd
> prefer this over the alternative of tooltips/highlights, which only
> give away their "I'm interactive" clue when actually mousing over them.)
>
> 3. Slide (content) area
>
> - Spacing is adequate. Not too crowded, not too wasteful.
>
> - I understand that the red border exists to indicate the connection
> to the red highlight box in the slide pane. I don't think this is
> necessary. I find that such a color/contrast around your slide  will
> distract from the appearance of the slide itself. This problem of
> course depends on how artistic you're trying to be with your slides
> (There's now danger if you just use bullet points). But it makes it
> more difficult to judge whether you got the color scheme *within* the
> slide right.
>
> - Yellow overview circle: Wow, THIS is REALLY neat! I see the
> (theoretic) problem that it sort of competes against the function of
> the scroll bar, but it's just SO much easier to hit and always zooms
> out to the "view all" level. Double-click and zoom in on another
> slide. Exposé for your slides. I would use his all day (but it needs
> an easy keyboard shortcut!). Two thumbs up. :D
I also like this one. Furthermore your are able to edit all the slide
elements in overview mode!

>
> - Double-clicking to zoom OUT. This is *very* prone to errors.
> Elements are frequently double-clicked (heck, many people even
> double-click just to select something). If you miss your target (e.g.
> a thin line), you get punished by having your view zoomed out. And
> what about the behavior of double-clicking into non-filled vs.
> bgcolor-filled rectangles? Sure, having the whole slide as a
> click-target instead of just the yellow circle is faster. But IMO this
> is not worth the risk of annoying people trying to double-click a line
> in the attempt of giving the line a text label.
OK. I am not sure if double click to zoom out will stay in final
version. Maybe we should do this only if you do it beside the slide area.
>
> 4. Status bar
>
> - I don't see the purpose of the "rectangle selected", "text selected"
> messages. Accessibility?
Just dummy content taken from current OOo.
>
> - Outline/Sorter/3DView: None of these work. 3DView messes up the
> screen, but doesn't show anything.
Should be fixed in current version.

>
>
> 5) FixedLabel Toolbar Variant 1:
>
> - Overall appearance is pretty clean.
>
> - I like it that there is no "open group on mouseover/hover" stuff.
> These often lead to unwanted changes right before a click (when
> diagonally mousing over another group tab towards an icon in another
> tab), or, in the case of hover timeouts, to timeouts being either too
> long or too short, depending on the user.
>
> Dark gray row:
>
> - I like the consistent use of the triangle selection indicator around
> the interface! I find it much better than tab-like selection
> indication both in terms of appearance and appeal, as well as in
> clarity. It's shape unambiguously makes clear whether the entity which
> the selection applies to lies to the left, right, top or bottom of the
> indicator. Very neat and innovative! This beats
> tabs-with-rounded-corners-at-the-far-edge any day!
>
> - Positioning, Spacing, Color, contrast and highlighting of the
> Home/Insert/Slide/... text items is okay. Their font could be a little
> smaller. Choose a non-bold, easy-to-read font like Gill Sans and save
> space. You can give the text an inset appearance to improve contrast.
> This applies to all black text on gray background on the interface
> (cf. iWork).
>
> - I find the naming of the "Home" category pretty bad (sorry!). It
> doesn't convey at all what I'll find inside. Reminds me of the
> "Extras" menu in the German Microsoft Office localization. I admit
> that this terminological vagueness doesn't do much harm in isolation.
> But it may contribute to a user image where the naming of elements is
> being discarded as "arbitrary" or "non-helpful", and actually useful
> usage hints are being discarded, the user instead clicking through all
> the menus "to make sure" they don't miss the function they're looking
> for. I've seen this with various users on MS Office.
>
> - The tiny icons (open/save/print/hyperlink (?)/image/..../show) are
> easy-to-spot and also big enough (they're not frequently used when
> working on a presentation).
>
> "Home" group icons:
>
> - Generally, nice big icons. Good contrast. Button-appearance affords
> clicking. I like.
>
> - Please lose the text shadow under the icon labels. It reduces
> contrast and makes stuff harder to read. Small, non-bold Gill Sans +
> Inset effect looks perfect to me for the icon labels.
>
> - Too much vertical spacing, particularly under the icon labels.
>
> - In my opinion, the group labeling above the icons (Insert
> Shape/Color/...) is not necessary. This introduces another hierarchy
> level between main groups (Home/Insert/...) and the buttons, which
> needs to be named consistently and introduces names and concepts the
> user can very well deal without. We already have spacing between the
> groups. This is enough to make clear that they are different. The
> button names suffice, and in the case where it doesn't, the button's
> tooltips show first-time-users what would happen if they clicked on it.
>
> - The checkbox to the bottom right of the "Insert Shape" surprisingly
> opens a menu with star shapes. It's (a) too far from the star button
> and (b) redundant with the star button itself.
>
> - The star button has a dark corner to signify that it acts as a menu
> with a choice of star shapes. What about using the conventionally
> established "down arrow" symbol instead of the dark corner? Maybe
> another clue could be shown when mousing over the button, but this may
> not be necessary when the button's appearance itself is improved
> sufficiently.
>
> - The star shape submenu smartly reuses the triangular "belongs-to"
> indicator. Looks good, but unfortunately results in the menu being a
> bit too far from the original mouse position. What I DO very much
> like, is that the items are arranged horizontally, which has a lot of
> benefits: It makes use of angular mouse movement with all its benefits
> against linear movement. Furthermore, it reduces the distance to the
> most extreme positions (Fitts' Law++). And it places the "most
> default" option DIRECTLY under the mouse cursor. This is a great
> improvement against standard vertical dropdown menus! I also like how
> the rest of the window subtly dims to let the menu stand out in higher
> contrast.
>
> - When clicking an insert shape button, there's no indication that I'm
> now in "insert shape X" mode (i.e. that clicking in the content area
> will have a different effect than on other times). Mode errors may
> happen.
>
> - I sort of miss an approach towards text formatting.
>
> - Insert > Insert Slide: Hmm, I'm probably contradicting myself
> regarding monotony, but what do you think of the idea to additionally
> put a tiny "+"-icon in the edge of the slide pane. Law of proximity: +
> & slide pane = new slide.
>
> 6. FixedLabel Toolbar, Variant 2:
>
> - Only the tab coloring is different from Variant 1 (mauve color),
> right? I found the tab coloring in Variant 1 better. Boxes are not
> necessary to make clear that the text items are clickable and clicking
> them selects something (clearly indicated by the triangular selection
> indicator). In fact, I find that the boxes add clutter. The spacing
> between the items completely suffices to separate them from each other.
>
> 7. When clicking Tabbed toolbar: Variant 1,  The toolbar vanishes.
> Nothing else happens.
>
> 8. Scrolling Toolbars, Variant 1:
>
> - All of my praise/criticism on "FixedLabel, Variant 1" also applies
> here, except of course for the different "tab" selection.
>
> - I REALLY like the feeling of working with a continuous row of
> functions instead of discrete "panels" of functions. I can't really
> say why, but it gives me a feeling of empowerment, of being in control
> and able to explore more freely. An illusion maybe, but nevertheless a
> good experience.
>
> - I now see the item names (Home/Insert/...) as "bookmarks" or
> "shortcuts" to a particular set of functionality instead of "tabs".
> This (to me) seems less intimidating.
>
> - I would lose the left and right arrows. Coming from Firefox, I at
> first thought they would act like the arrows that appear in the
> Firefox tab bar when having too many tabs to fit in the bar. I thought
> they would scroll the *dark grey* items, not the buttons above.
>
> - Please make the scroll wheel work (horizontal scrolling for systems
> that support it [Mac]).
>
> - Make mouse wheel scrolling continuous (the lack of continuous
> scrolling sort of stumps my feeling of empowerment and free
> exploration), and get rid of the dark borders that signify groups.
> Instead, *prefix* every group with its label to the left with vertical
> letters. Something like this:
> http://schuderer.net/pub/OOo-horiz-scrolling-toolbar-grouping.png
>
> To avoid a misunderstanding: By continuous scrolling, I don't mean
> that clicking the "scroll bar" at a particular position should scroll
> exactly to this position, possibly coming to rest somewhere inbetween
> two groups. Clicking on an item name should still bring you exactly to
> its position, same as now.
>
> - Scrolling should be quicker when clicking on an item, about
> 300-500ms. Ideally with ease-in and ease-out. The amount of time it
> takes should be constant, i.e. scrolling happens faster for faraway
> targets.
>
> - I realize that some of the problems concerning grouping/organization
> would probably be alleviated when scrolling would be vertical. What do
> you think about trying a vertical scrolling toolbar?
>
> Side note: I've just looked at scrolling toolbars the first time
> today. Funnily, just yesterday, I tried to figure out something very
> similar for my "scrolling sidebar" proposal. I wrote down some
> thoughts on the discussion page which might also apply here. There is
> also an approach on how to consolidate item highlighting with free
> scrolling. See
> http://wiki.services.openoffice.org/wiki/Talk:Proposal_by_Andreas_Schuderer (second
> and third list item)
>
> 9. Scrolling Toolbars, Variant 2:
>
> - The yellow blobs increase contrast, but don't add much. The
> prototype's interface freezes immediately in Variant 2.
>
> 10. Scrolling Toolbars, Variant 3:
>
> - My remarks on Variant 1 also apply here, except where otherwise noted.
>
> - I preferred it when the scroll position indicator (moving
> semi-transparent bar) stayed the same size and indicated the length of
> the whole toolbar, a feature we know from scroll bars.
>
> - The scroll position indicator changes length as it moves over the
> items. This looks wobbly and unsteady. Watching it wobble its way from
> the first to the last item looks quite amusing.
>
> - The arrow keys now scroll continuously. As I stated in (8.),
> continuous scrolling is good, but I still don't think we need the
> arrow buttons (cf. Firefox, where very similar arrow keys act very
> differently). Again, mouse wheel scrolling would be great. (cf. 8.)
>
> 11.     Scrolling Toolbars, Variant 4:
>
> - My remarks on Variant 1 and 3 also apply here, except where
> otherwise noted.
>
> - Scroll position indicator length issue resolved (cf. Variant 3).
>
> - The coloring is now more subtle, but to me, it still doesn't look as
> slick as in Variant 1.
>
> - Scrolling speed is still an issue (time, not speed should be
> constant). 300-500ms. (See 8.)
>
> - Lose arrow buttons (see 8.)
>
> - Grouping issues (see 8.)
>
> - Are you still awake?
>
>
>
> I'm curious whether you'll find this feedback helpful.
Thank you for your rich feedback, we will consider it!

Best regards,

Frank

--
Sun Microsystems GmbH                Frank Loehmann
Nagelsweg 55                         User Experience StarOffice
20097 Hamburg                        Phone: (+49 40)23646 882
Germany                              Fax:   (+49 40)23646 550
http://www.sun.de                    mailto:[hidden email]

OpenOffice.org User Experience Team
http://ux.openoffice.org

Sitz der Gesellschaft:
Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Feedback on current prototype v0.8

Bernd Eilers
In reply to this post by Andreas Schuderer
Andreas Schuderer wrote:
> Hi there,
>

Hi there!

> [...snip...]

 > 4. Status bar
 >
 > - I don't see the purpose of the "rectangle selected", "text selected"
 > messages. Accessibility?

This is just a visual aid to indicate which kind of object you currently
have selected because on different kinds of objects different kinds of
operations might be possible. It´s also a faeture already available in
current OpenOffice.org. So that something we already have and just
copied in the prototype but it´s not a new concept we try to check out
with it.

 >
 > - Outline/Sorter/3DView: None of these work. 3DView messes up the
 > screen, but doesn't show anything.

Outline and Sorter did have no action defined yet in that incarnation of
the prototype. Next version available now doesn´t have Outline anymore
but Sorter should work.

If 3DView doesn´t work for you that is probably due to lack of java3d
Support for your platform or graphics hardware. We do know there is an
issue with the Mac java platform here and we also do know that this
doesn´t work via Windows Remote Desktop protocol. Please check if you
can use any of the Java3D examples from
https://j3d-webstart.dev.java.net/test/.

If not you might consider moving to a newer java version or testing on
different computer.

 > [...snip...]


> - Insert > Insert Slide: Hmm, I'm probably contradicting myself
> regarding monotony, but what do you think of the idea to additionally
> put a tiny "+"-icon in the edge of the slide pane. Law of proximity: + &
> slide pane = new slide.
>

This is now there!

> 6. FixedLabel Toolbar, Variant 2:
>
> - Only the tab coloring is different from Variant 1 (mauve color),
> right? I found the tab coloring in Variant 1 better. Boxes are not
> necessary to make clear that the text items are clickable and clicking
> them selects something (clearly indicated by the triangular selection
> indicator). In fact, I find that the boxes add clutter. The spacing
> between the items completely suffices to separate them from each other.
>

I agree with you on this one. I also to like Variant 1 better.

> 7. When clicking Tabbed toolbar: Variant 1,  The toolbar vanishes.
> Nothing else happens.
>

Which platform?
I could not reproduce this (tried on Windows and Solaris).

> 8. Scrolling Toolbars, Variant 1:
 > [...]
 > - Please make the scroll wheel work (horizontal scrolling for systems
 > that support it [Mac]).

It´s not in the scope of the prototype to implement just every tiny
possible detail as well as it's not intended to define the exact spacing
pixelwise for a possible later real implementation. It's just about
presenting the general concept. We may eventually add scroll wheel
support to the prototype if time permits but that´s certainly not the
most important aspect because you can easily imaging using the scroll
wheel later in a possible real and non-prototype application.

> [...snip..]


> 9. Scrolling Toolbars, Variant 2:
>
> - The yellow blobs increase contrast, but don't add much. The
> prototype's interface freezes immediately in Variant 2.
>

This was a bug which has now been fixed! Variant 2 should now be working
and should be similar to Variant 1 just with a bigger font being used.

> 10. Scrolling Toolbars, Variant 3:
>
> - My remarks on Variant 1 also apply here, except where otherwise noted.
>
> - I preferred it when the scroll position indicator (moving
> semi-transparent bar) stayed the same size and indicated the length of
> the whole toolbar, a feature we know from scroll bars.
>
> - The scroll position indicator changes length as it moves over the
> items. This looks wobbly and unsteady. Watching it wobble its way from
> the first to the last item looks quite amusing.
>

Well I totally agree with you here! I immediatly disliked the concept of
having the scroll area being the size of the nearest text after we tried
that out.

>
> I'm curious whether you'll find this feedback helpful.
>

I did!

> Cheers,
> Andreas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Cheers,
Bernd


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Feedback Impress Prototype 0.8 / July 13 2009

Bernd Eilers
In reply to this post by Andreas Schuderer
Andreas Schuderer wrote:
> Hi again,
> [... snip...]
> By the way: I'm really impressed about the quality and richness of the
> prototypes. And this in such a short amount of time! Do you use a
> specific prototyping framework?
>

Just plain java programming ;-)

> Cheers,
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Feedback on current prototype v0.8

Jaron Kuppers
In reply to this post by Bernd Eilers
Hi all,
Amazing job on the prototype!  I am extremely impressed at how fast this has
developed!  Of course I have a couple opinions about stuff. ;-)  Please
don't be daunted by my first paragraph, I was just being wordy to clarify my
points...

The scrolling toolbar is a great idea.  I think it could also be easily
translated into a vertical toolbar (when relevant) for the other office
suites that require more vertical screen real-estate.
I have some concerns with how the scroll system works though.  If a category
(such as animation) exceeds the space provided by the toolbar width then the
user should be able to click anywhere on the scrollbar to get to a desired
location.  For example, lets say I want to use a command in Animate>Group4
then I would need to click "Animation" and then slide the scroll-tool to the
right to arrive at Group 4.  The desired feature would be to allow user's to
click anywhere within the scroll bar and directly arrive at any
command/button. Secondly I feel that the spacing of the tool categories
should reflect the physical size of the categories themselves; maybe it is
and I just can't tell but it currently looks like its spaced evenly and it
feels like scrolling is faster between Animate and Show, vs Insert and
Design.  See http://www.apple.com/mac/ for an example of both my first two
points (but not my third).  Thirdly, the position of the scroll tool should
have some physical correlation to the spacing of the commands/buttons in the
toolbar.  You essentially solve part of that issue in variant 3 by having
the scroll-tool left justify with the "Start" category's icon.  The left of
"Start" is the end of the toolbar and it feels correct when the two align.
 However, it is misleading that when you click on "Animate" that the entire
animate category icon is filled by the scroll-tool since the user can't see
the entire "Animate" category, especially in the current prototype where
Group 1-3 fill the entire toolbar space making it seem like all the Animate
commands are being shown.  Additionally in variant 3, I feel the
scrolling-tool should always stay the same width; it currently changes to
match the size of the selected category.  I envision the scroll-tool bar
being like a de-magnifying glass looking down on the toolbar, an
understandable (intuitive?) physical phenomenon.
I hope this makes sense and isn't too nit picky...  Especially let me know
if its the latter.

A general comment is that user's who don't use shortcuts will be greatly
hindered by the current scrolling toolbar.  If Micorsoft's (MS) user
feedback information is representative of our user's as well, then
copy/paste commands via buttons are used most often.  This method either
limits the user to copy-pasting by moving the toolbar around every time they
wish to use those commands or makes them use the menu.  Perhaps there is a
way to include the quick command buttons present in the FixedLabel Variant
in the Scrolling variant as well?

Once again, amazing work!  I anxiously await new features!

Cheers,
Jaron

P.S. Some random fun (because I am a dork): We have a fun optical illusion
in the prototype.  The pie zoom thingy looks like it gets bigger when you
zoom out but it doesn't... :-)  It's also a great feature!





On Wed, Jul 15, 2009 at 8:51 AM, Bernd Eilers <[hidden email]> wrote:

> Andreas Schuderer wrote:
>
>> Hi there,
>>
>>
> Hi there!
>
>  [...snip...]
>>
>
> > 4. Status bar
> >
> > - I don't see the purpose of the "rectangle selected", "text selected"
> > messages. Accessibility?
>
> This is just a visual aid to indicate which kind of object you currently
> have selected because on different kinds of objects different kinds of
> operations might be possible. It´s also a faeture already available in
> current OpenOffice.org. So that something we already have and just copied in
> the prototype but it´s not a new concept we try to check out with it.
>
> >
> > - Outline/Sorter/3DView: None of these work. 3DView messes up the
> > screen, but doesn't show anything.
>
> Outline and Sorter did have no action defined yet in that incarnation of
> the prototype. Next version available now doesn´t have Outline anymore but
> Sorter should work.
>
> If 3DView doesn´t work for you that is probably due to lack of java3d
> Support for your platform or graphics hardware. We do know there is an issue
> with the Mac java platform here and we also do know that this doesn´t work
> via Windows Remote Desktop protocol. Please check if you can use any of the
> Java3D examples from https://j3d-webstart.dev.java.net/test/.
>
> If not you might consider moving to a newer java version or testing on
> different computer.
>
> > [...snip...]
>
>
>  - Insert > Insert Slide: Hmm, I'm probably contradicting myself regarding
>> monotony, but what do you think of the idea to additionally put a tiny
>> "+"-icon in the edge of the slide pane. Law of proximity: + & slide pane =
>> new slide.
>>
>>
> This is now there!
>
>  6. FixedLabel Toolbar, Variant 2:
>>
>> - Only the tab coloring is different from Variant 1 (mauve color), right?
>> I found the tab coloring in Variant 1 better. Boxes are not necessary to
>> make clear that the text items are clickable and clicking them selects
>> something (clearly indicated by the triangular selection indicator). In
>> fact, I find that the boxes add clutter. The spacing between the items
>> completely suffices to separate them from each other.
>>
>>
> I agree with you on this one. I also to like Variant 1 better.
>
>  7. When clicking Tabbed toolbar: Variant 1,  The toolbar vanishes. Nothing
>> else happens.
>>
>>
> Which platform?
> I could not reproduce this (tried on Windows and Solaris).
>
>  8. Scrolling Toolbars, Variant 1:
>>
> > [...]
> > - Please make the scroll wheel work (horizontal scrolling for systems
> > that support it [Mac]).
>
> It´s not in the scope of the prototype to implement just every tiny
> possible detail as well as it's not intended to define the exact spacing
> pixelwise for a possible later real implementation. It's just about
> presenting the general concept. We may eventually add scroll wheel support
> to the prototype if time permits but that´s certainly not the most important
> aspect because you can easily imaging using the scroll wheel later in a
> possible real and non-prototype application.
>
>  [...snip..]
>>
>
>
>  9. Scrolling Toolbars, Variant 2:
>>
>> - The yellow blobs increase contrast, but don't add much. The prototype's
>> interface freezes immediately in Variant 2.
>>
>>
> This was a bug which has now been fixed! Variant 2 should now be working
> and should be similar to Variant 1 just with a bigger font being used.
>
>  10. Scrolling Toolbars, Variant 3:
>>
>> - My remarks on Variant 1 also apply here, except where otherwise noted.
>>
>> - I preferred it when the scroll position indicator (moving
>> semi-transparent bar) stayed the same size and indicated the length of the
>> whole toolbar, a feature we know from scroll bars.
>>
>> - The scroll position indicator changes length as it moves over the items.
>> This looks wobbly and unsteady. Watching it wobble its way from the first to
>> the last item looks quite amusing.
>>
>>
> Well I totally agree with you here! I immediatly disliked the concept of
> having the scroll area being the size of the nearest text after we tried
> that out.
>
>
>> I'm curious whether you'll find this feedback helpful.
>>
>>
> I did!
>
>  Cheers,
>> Andreas
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
> Cheers,
> Bernd
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on current prototype v0.8

Bernd Eilers
Jaron Kuppers wrote:

> Hi all,
> Amazing job on the prototype!  I am extremely impressed at how fast this has
> developed!  Of course I have a couple opinions about stuff. ;-)  Please
> don't be daunted by my first paragraph, I was just being wordy to clarify my
> points...
>
> The scrolling toolbar is a great idea.  I think it could also be easily
> translated into a vertical toolbar (when relevant) for the other office
> suites that require more vertical screen real-estate.
> I have some concerns with how the scroll system works though.  If a category
> (such as animation) exceeds the space provided by the toolbar width then the
> user should be able to click anywhere on the scrollbar to get to a desired
> location.  For example, lets say I want to use a command in Animate>Group4
> then I would need to click "Animation" and then slide the scroll-tool to the
> right to arrive at Group 4.  The desired feature would be to allow user's to
> click anywhere within the scroll bar and directly arrive at any
> command/button.

Not sure if I understand you here.
Well we already select the nearest group for a click as current group
and snap to the start of that group instead of arriving somewhere in the
middle where the user actually clicked. Do you mean not to animate the
transition to the new current group when clicking but immediatly
showning it or what?

> Secondly I feel that the spacing of the tool categories
> should reflect the physical size of the categories themselves; maybe it is
> and I just can't tell but it currently looks like its spaced evenly and it
> feels like scrolling is faster between Animate and Show, vs Insert and
> Design.  

Your analysis is correct the current implementation distributes the
catagory labels in the lower area evenly and than adjust the scrolling
speed in the upper area acorrding to the corresponding size of the
current tool-group in the upper area. Maybe we should experiment a
little bit with different kinds of layouts here once we have more
concrete ideas on what the actually tool groups should contain.


>See http://www.apple.com/mac/ for an example of both my first two
> points (but not my third).  Thirdly, the position of the scroll tool should
> have some physical correlation to the spacing of the commands/buttons in the
> toolbar.  You essentially solve part of that issue in variant 3 by having
> the scroll-tool left justify with the "Start" category's icon.  The left of
> "Start" is the end of the toolbar and it feels correct when the two align.
>  However, it is misleading that when you click on "Animate" that the entire
> animate category icon is filled by the scroll-tool since the user can't see
> the entire "Animate" category, especially in the current prototype where
> Group 1-3 fill the entire toolbar space making it seem like all the Animate
> commands are being shown.

Well there is probably just to much dummmy content in that and other
dummy categories. This will likely change once we have more concrete
ideas about the actuall possible content of those categories.

>  Additionally in variant 3, I feel the
> scrolling-tool should always stay the same width; it currently changes to
> match the size of the selected category.  

That was the idea behind that variant to match the size of the slider
with the nearest label. I think it would be fair to say we tried that
out but it doesn't work.

>I envision the scroll-tool bar
> being like a de-magnifying glass looking down on the toolbar, an
> understandable (intuitive?) physical phenomenon.
> I hope this makes sense and isn't too nit picky...  Especially let me know
> if its the latter.
>
> A general comment is that user's who don't use shortcuts will be greatly
> hindered by the current scrolling toolbar.  If Micorsoft's (MS) user
> feedback information is representative of our user's as well, then
> copy/paste commands via buttons are used most often.  This method either
> limits the user to copy-pasting by moving the toolbar around every time they
> wish to use those commands or makes them use the menu.  Perhaps there is a
> way to include the quick command buttons present in the FixedLabel Variant
> in the Scrolling variant as well?

There´s no indention to remove normal keystroke commands from the
application and replace them by toolbar items only. Toolbar items should
be seen as an alternative approach. And non availibility of allways
available keystroke commands is just a limitation of the prototype
application.

>
> Once again, amazing work!  I anxiously await new features!
>
> Cheers,
> Jaron
>
> P.S. Some random fun (because I am a dork): We have a fun optical illusion
> in the prototype.  The pie zoom thingy looks like it gets bigger when you
> zoom out but it doesn't... :-)  It's also a great feature!
>
>

Kind regards,
Bernd



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Feedback on current prototype v0.8

Jaron Kuppers
Hello,

On Wed, Jul 15, 2009 at 11:06 AM, Bernd Eilers <[hidden email]> wrote:

> Jaron Kuppers wrote:
>
>> Hi all,
>> Amazing job on the prototype!  I am extremely impressed at how fast this
>> has
>> developed!  Of course I have a couple opinions about stuff. ;-)  Please
>> don't be daunted by my first paragraph, I was just being wordy to clarify
>> my
>> points...
>>
>> The scrolling toolbar is a great idea.  I think it could also be easily
>> translated into a vertical toolbar (when relevant) for the other office
>> suites that require more vertical screen real-estate.
>> I have some concerns with how the scroll system works though.  If a
>> category
>> (such as animation) exceeds the space provided by the toolbar width then
>> the
>> user should be able to click anywhere on the scrollbar to get to a desired
>> location.  For example, lets say I want to use a command in Animate>Group4
>> then I would need to click "Animation" and then slide the scroll-tool to
>> the
>> right to arrive at Group 4.  The desired feature would be to allow user's
>> to
>> click anywhere within the scroll bar and directly arrive at any
>> command/button.
>>
>
> Not sure if I understand you here.
> Well we already select the nearest group for a click as current group and
> snap to the start of that group instead of arriving somewhere in the middle
> where the user actually clicked. Do you mean not to animate the transition
> to the new current group when clicking but immediatly showning it or what?


I wasn't commenting on the animation/transition.  I like that the user can
click on a group name and snap to the start of that group, but the user
should also be able to click elsewhere in the scrollbar as in my example on
the apple website.  My reasoning is that if a group's width (like Animation
currently is) exceeds the current viewable toolbar space then it may be
confusing for the user to find the not-shown group commands (such as group 4
of Animation).

For example, if you try and find "Final Cut Express" on the apple website
you may find it two different ways.  1) By click and dragging the bar (like
the prototype) or 2) by clicking the mouse half-way between the
"Application" and "Servers" groups, (the feature I would like to see
implemented in the prototype).  (The snap functionality should of course
also stay).



> Secondly I feel that the spacing of the tool categories
>> should reflect the physical size of the categories themselves; maybe it is
>> and I just can't tell but it currently looks like its spaced evenly and it
>> feels like scrolling is faster between Animate and Show, vs Insert and
>> Design.
>>
>
> Your analysis is correct the current implementation distributes the
> catagory labels in the lower area evenly and than adjust the scrolling speed
> in the upper area acorrding to the corresponding size of the current
> tool-group in the upper area. Maybe we should experiment a little bit with
> different kinds of layouts here once we have more concrete ideas on what the
> actually tool groups should contain.


I am curious why you chose to distribute them evenly instead of reflecting
the size of the tool groups.  I look forward to seeing how this tool evolves
as we develop a better idea of the content of the tool groups.


>
>  See http://www.apple.com/mac/ for an example of both my first two
>> points (but not my third).  Thirdly, the position of the scroll tool
>> should
>> have some physical correlation to the spacing of the commands/buttons in
>> the
>> toolbar.  You essentially solve part of that issue in variant 3 by having
>> the scroll-tool left justify with the "Start" category's icon.  The left
>> of
>> "Start" is the end of the toolbar and it feels correct when the two align.
>>  However, it is misleading that when you click on "Animate" that the
>> entire
>> animate category icon is filled by the scroll-tool since the user can't
>> see
>> the entire "Animate" category, especially in the current prototype where
>> Group 1-3 fill the entire toolbar space making it seem like all the
>> Animate
>> commands are being shown.
>>
>
> Well there is probably just to much dummmy content in that and other dummy
> categories. This will likely change once we have more concrete ideas about
> the actuall possible content of those categories.


While I understand that you added a lot of dummy categories, but the problem
will remain if the OOo window is reduced in width.  Perhaps I am being too
forward thinking...  It is a prototype after all.  Essentially my point was
that I felt the toolbar scrolling should be modeled after physics, since I
imagine that nature seems most intuitive to users.  (Of course I am no
expert so I don't really know...)



>  Additionally in variant 3, I feel the
>> scrolling-tool should always stay the same width; it currently changes to
>> match the size of the selected category.
>>
>
> That was the idea behind that variant to match the size of the slider with
> the nearest label. I think it would be fair to say we tried that out but it
> doesn't work.
>

>  I envision the scroll-tool bar
>> being like a de-magnifying glass looking down on the toolbar, an
>> understandable (intuitive?) physical phenomenon.
>> I hope this makes sense and isn't too nit picky...  Especially let me know
>> if its the latter.
>>
>> A general comment is that user's who don't use shortcuts will be greatly
>> hindered by the current scrolling toolbar.  If Micorsoft's (MS) user
>> feedback information is representative of our user's as well, then
>> copy/paste commands via buttons are used most often.  This method either
>> limits the user to copy-pasting by moving the toolbar around every time
>> they
>> wish to use those commands or makes them use the menu.  Perhaps there is a
>> way to include the quick command buttons present in the FixedLabel Variant
>> in the Scrolling variant as well?
>>
>
> There愀 no indention to remove normal keystroke commands from the
> application and replace them by toolbar items only. Toolbar items should be
> seen as an alternative approach. And non availibility of allways available
> keystroke commands is just a limitation of the prototype application.

I think you may have misunderstood me.  What I meant was that the quick
command access for things like paste and copy is a very convenient feature
for many users (as you had implemented it in the FixedLabel Variant to the
left of the tab labels).  I was just curious what the Scrolling variant
would look like if that same feature was added (ie add those quick command
buttons to the left of the scrollbar).

Cheers,
Jaron
Reply | Threaded
Open this post in threaded view
|

Re: Feedback on current prototype v0.8

Bernd Eilers
Jaron Kuppers wrote:
> Hello,
>

ReHi!

 > [...snip...]
>
> I wasn't commenting on the animation/transition.  I like that the user can
> click on a group name and snap to the start of that group, but the user
> should also be able to click elsewhere in the scrollbar as in my example on
> the apple website.  My reasoning is that if a group's width (like Animation
> currently is) exceeds the current viewable toolbar space then it may be
> confusing for the user to find the not-shown group commands (such as group 4
> of Animation).
>

This should normally not happen since toolbar content must be limited to
fit into a fixed minimum window size.

If we can not assume a minimum size of well let´s say 640x480 or similar
(and adjust content of toolbar groups accordingly) we would be dooomed
for the other none scrolling variants as well.

> For example, if you try and find "Final Cut Express" on the apple website
> you may find it two different ways.  1) By click and dragging the bar (like
> the prototype) or 2) by clicking the mouse half-way between the
> "Application" and "Servers" groups, (the feature I would like to see
> implemented in the prototype).  (The snap functionality should of course
> also stay).
>

*hmm* snapping to the next nearest group and being able to click
somewhere in between and allow fine grained adjustment is well almost
mutually exclusive unless you want to adjust to the current group only
when hitting the text directly and allow fine grained adjustment only
outside the area covered by the text.

>
>
>> Secondly I feel that the spacing of the tool categories
>>> should reflect the physical size of the categories themselves; maybe it is
>>> and I just can't tell but it currently looks like its spaced evenly and it
>>> feels like scrolling is faster between Animate and Show, vs Insert and
>>> Design.
>>>
>> Your analysis is correct the current implementation distributes the
>> catagory labels in the lower area evenly and than adjust the scrolling speed
>> in the upper area acorrding to the corresponding size of the current
>> tool-group in the upper area. Maybe we should experiment a little bit with
>> different kinds of layouts here once we have more concrete ideas on what the
>> actually tool groups should contain.
>
>
> I am curious why you chose to distribute them evenly instead of reflecting
> the size of the tool groups.  I look forward to seeing how this tool evolves
> as we develop a better idea of the content of the tool groups.
>

I just felt that it would look better to distribute them evenly in the
first place.

Reflecting the size of the tool groups might (depending on the group
sizes) lead to a problem that text labels could actually overlap which
would actually look bad. I think with one of the next versions I will
try the following approach which i consider a compromise: Use a java
GridBaglayout for the labels with weights set to the preferred width the
corresponding tool group. Doing this the size for the labels should
reflect the tool group size as long as they do not overlap or get too
small to contain the text. If later is the case size will slightly be
adjusted and scrolling in the upper area will thus than still have
slightly differnet speed if the width of tool groups is different.



>>  See http://www.apple.com/mac/ for an example of both my first two
>>> points (but not my third).  Thirdly, the position of the scroll tool
>>> should
>>> have some physical correlation to the spacing of the commands/buttons in
>>> the
>>> toolbar.  You essentially solve part of that issue in variant 3 by having
>>> the scroll-tool left justify with the "Start" category's icon.  The left
>>> of
>>> "Start" is the end of the toolbar and it feels correct when the two align.
>>>  However, it is misleading that when you click on "Animate" that the
>>> entire
>>> animate category icon is filled by the scroll-tool since the user can't
>>> see
>>> the entire "Animate" category, especially in the current prototype where
>>> Group 1-3 fill the entire toolbar space making it seem like all the
>>> Animate
>>> commands are being shown.
>>>
>> Well there is probably just to much dummmy content in that and other dummy
>> categories. This will likely change once we have more concrete ideas about
>> the actuall possible content of those categories.
>
>
> While I understand that you added a lot of dummy categories, but the problem
> will remain if the OOo window is reduced in width.  Perhaps I am being too
> forward thinking...  It is a prototype after all.  Essentially my point was
> that I felt the toolbar scrolling should be modeled after physics, since I
> imagine that nature seems most intuitive to users.  (Of course I am no
> expert so I don't really know...)
>

I have never seen something like a scrollbar in nature ;-)

>
>
>>  Additionally in variant 3, I feel the
>>> scrolling-tool should always stay the same width; it currently changes to
>>> match the size of the selected category.
>>>
>> That was the idea behind that variant to match the size of the slider with
>> the nearest label. I think it would be fair to say we tried that out but it
>> doesn't work.
>>
>
>>  I envision the scroll-tool bar
>>> being like a de-magnifying glass looking down on the toolbar, an
>>> understandable (intuitive?) physical phenomenon.
>>> I hope this makes sense and isn't too nit picky...  Especially let me know
>>> if its the latter.
>>>
>>> A general comment is that user's who don't use shortcuts will be greatly
>>> hindered by the current scrolling toolbar.  If Micorsoft's (MS) user
>>> feedback information is representative of our user's as well, then
>>> copy/paste commands via buttons are used most often.  This method either
>>> limits the user to copy-pasting by moving the toolbar around every time
>>> they
>>> wish to use those commands or makes them use the menu.  Perhaps there is a
>>> way to include the quick command buttons present in the FixedLabel Variant
>>> in the Scrolling variant as well?
>>>
>> There愀 no indention to remove normal keystroke commands from the
>> application and replace them by toolbar items only. Toolbar items should be
>> seen as an alternative approach. And non availibility of allways available
>> keystroke commands is just a limitation of the prototype application.
>
> I think you may have misunderstood me.  What I meant was that the quick
> command access for things like paste and copy is a very convenient feature
> for many users (as you had implemented it in the FixedLabel Variant to the
> left of the tab labels).  I was just curious what the Scrolling variant
> would look like if that same feature was added (ie add those quick command
> buttons to the left of the scrollbar).

Ah you mean adding the icons there like on the FixedLabel Variant. Well
i can imagine that.


>
> Cheers,
> Jaron
>

Kind regards,
Bernd Eilers

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]