Feedback Impress Prototype 0.11 / July 22 2009

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

Feedback Impress Prototype 0.11 / July 22 2009

Andreas Schuderer
Hi all!

Here's some feedback on today's prototype (0.11 / July 22 2009).

About "FixedLabel Toolbar, Variant 1":

Wow, I didn't know you could actually *load* real ODP (Impress) files  
into the prototype! It's very handy to try out how working with  
complex documents feels.

What I also didn't know: In zoomed-out mode (= slide sorter (?)), you  
can actually *manipulate* the currently selected slide. You can even  
*drag* stuff from the currently active slide to another slide. This  
works very good! On the other hand, this is modal that you must first  
select the slide and can only then manipulate its objects. Making all  
the slides manipulatable without selection could potentially unleash  
unforeseen power/creativity. It would have to be tried out to see.

Context sensitivity: A double click on an object brings up the format  
toolbar. Call it "context-sensitivity on demand." A nice idea, as I  
personally don't want toolbars automatigally changing around all the  
time. But somehow I have the nagging feeling that this will introduce  
a conceptual conflict: I'm afraid that the gesture "double-click  
object" is already in use for the action "begin editing/labelling  
object".

When really pretending to work with the prototype, screen real estate  
becomes a problem pretty soon. I find that, to be able to do fine  
positioning, I have to zoom in earlier than strictly necessary. Try a  
vertical toolbar.

3DView: Looks nice, but, as I said before, it doesn't really add  
value. What is it's main use case? It's neither suitable for editing  
or presenting a presentation (obviously), nor for navigating quickly  
to a particular slide (that's what slide pane is for), nor for quickly  
leafing through a presentation (normal mode is more efficient for  
this, and the slide pane gives a better overwiew over the next/
previous slides than the one-third-visible slides in the background).  
One positive factor of 3DView is that the animation makes it clear  
where I come from and where I’m going. But this can also be  
implemented in normal 2d view (animate up/down [or right/left]).
-- In my opinion, Cover Flow only shines when browsing through a heap  
of *unstructured* visual information in search of an interesting item.  
But slides are structured information and not as huge in number (at  
least they should be). I've tried to use Cover Flow for files, and  
it's suboptimal (you don't see enough of the adjacent items and lose a  
lot of time scrolling to and fro when searching for a particular item).

Again: I LIKE the submenus of the toolbar and their re-use of the  
triangular "belongs-to" indicator!

What I don't like is the "Frequently Used" shape group in the shape  
submenu. Is this a changing, "adaptive" list such as Windows XP's  
Start Menu? If yes, this is very bad, because it prevents the  
formation of habits. Habits are our friend, they make daily tasks much  
quicker and save on cognitive capacity, which is released to the  
user's work. But positive habits can only work if things don't change  
around in an interface. If "Frequently Used" is actually fixed, it  
just wastes a lot of precious space near the mouse pointer. This would  
give Fitts fits. ;)

Thanks for fixing mousewheel scrolling in the slide pane. When  
"arrowing" through the slides and reaching the edge, however, the  
animation could be much quicker (around 4 times as quick would be good).

Format buttons: Instant preview on mouseover in the content area is  
nice. But please make it consistent for all formatting options (also  
mundane options like bold, italic, etc.). Also, you can’t see the  
preview when the object is concealed by the menu (e.g. by the gradient  
menu). Also, I don’t think that making the preview appear in the  
slides pane is necessary (it could lead to performance issues).

When inserting a shape and clicking e.g. the “insert text box” button,  
visual feedback that you’re in “insert” mode is still insufficient.  
EITHER clearly indicate that the user must now draw a box, OR (better)  
make it modeless by inserting a default circle in the middle of the  
slide. This way, when simply inserting a default object, the user  
would experience immediate *closure* (a precondition for satisfaction)  
and the action of inserting a shape would be a one-step (instead of a  
multi-step) process.

Master slide button: A nice Idea. The mouseover is a good idea, too.  
But indicate more clearly which mode you're currently in (slide vs.  
master).  Also, perhaps use a flip animation (like you see it on Mac  
OS dashboard widgets or some iPhone apps). A flip animation would make  
it very clear that I’m now dealing with “another side of the same  
thing”. The zoom-out-zoom-in animation could mean anything (and it  
conceptually conflicts with animated zooming). There's an odd bug when  
switching to master view in slide sorter (=zoomed-out (?)) mode.

In slide sorter mode, how do you drag an object from one slide to the  
master view enabled on another slide? I couldn't achieve this.

Interaction elements placed next to the slide (pac-man, insertion/
deletion, master): Keep in mind that more often than not, elements  
like graphics, etc. will actually *stick out* of the slide and may  
conflict with those elements. It's even theoretically possible to hide  
an item behind the control (or worse: the control behind an item).  
Make clear what will end up behind what.

Zooming currently centers on the middle slide. It should center on the  
selected slide (maybe a bug in the prototype). Also, manual panning is  
not possible, and panning doesn't automatically follow when selecting  
another slide in the slide pane. And, while I'm at it, here's a  
suggestion to make it easier to fine-zoom with the zoom-slider : Make  
it direct (=coarse) when the mouse is over the slider, but make it  
become more and more fine-grained the further you move the mouse away  
above or below the slider. Cf. the music/movie progress bar on the  
iPod Touch/iPhone with iPhone OS 3.0.

Please make up your mind whether you want "slide sorter mode" or "pac-
man zooming". They're too similar to exist both, yet too dissimilar to  
merge (disappearing panes in slide sorter mode).


About "FixedLabel Toolbar, Variant 3":

On not-Macs, the toolbar labels will look like a second kind of menu  
(which they are). They are located right below the program menu.  
Surprisingly, this doesn't seem to be as bothersome as this  
description sounds.

The toolbars themselves are not visible by default, and therefore,  
there's more space for content. If you single-click a toolbar label,  
the corresponding toolbar is superimposed over the content area and  
slide pane. That way, it works similarly to a traditional menu. But  
when selecting a toolbar item, the toolbar, unlike a traditional menu,  
doesn't disappear and *stays* superimposed. When you want to access  
the content behind the toolbar, you have to explicitly dismiss the  
toolbar by another single-click on *its own* toolbar label. Hm, this  
gets pretty tedious.

Another way to use this variant is to *double-click* a toolbar label.  
The content area shrinks a bit to make room for the toolbar.  
Therefore, no content is concealed by the toolbar. When the toolbar is  
"enabled" like this, it effectively works like that in Variant 1, only  
with the labels above instead of below. To hide it again, you single-
click on the currently active toolbar label (doesn't really make sense).

Wow, this is complicated! The only benefit of Variant 3 that I see is  
that it can *temporarily* save content real estate. I would only use  
it the this way: Keep it activated by default, and double-click the  
currently active toolbar label to hide it temporarily in the rare  
situations when I want more content space but don't need the toolbar.  
The same can *much* more easily be achieved through a show/minimize  
button (where the toolbar labels stay visible in the minimized state,  
so you save 1 click when the toolbar is hidden and you want to go to a  
different toolbar)

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 Impress Prototype 0.11 / July 22 2009

Andreas Schuderer
Erratum:

> When inserting a shape and clicking e.g. the “insert text box”  
> button, visual feedback that you’re in “insert” mode is still  
> insufficient. EITHER clearly indicate that the user must now draw a  
> box, OR (better) make it modeless by inserting a default circle in  
> the middle of the slide. This way, when simply inserting a default  
> object, the user would experience immediate *closure* (a  
> precondition for satisfaction) and the action of inserting a shape  
> would be a one-step (instead of a multi-step) process.

Here I of course I meant that a "default text box" should be inserted,  
and not a "default circle".

Am 22. Jul 2009 um 20:39 schrieb Andreas Schuderer:

> Hi all!
>
> Here's some feedback on today's prototype (0.11 / July 22 2009).
>
> About "FixedLabel Toolbar, Variant 1":
>
> Wow, I didn't know you could actually *load* real ODP (Impress)  
> files into the prototype! It's very handy to try out how working  
> with complex documents feels.
>
> What I also didn't know: In zoomed-out mode (= slide sorter (?)),  
> you can actually *manipulate* the currently selected slide. You can  
> even *drag* stuff from the currently active slide to another slide.  
> This works very good! On the other hand, this is modal that you must  
> first select the slide and can only then manipulate its objects.  
> Making all the slides manipulatable without selection could  
> potentially unleash unforeseen power/creativity. It would have to be  
> tried out to see.
>
> Context sensitivity: A double click on an object brings up the  
> format toolbar. Call it "context-sensitivity on demand." A nice  
> idea, as I personally don't want toolbars automatigally changing  
> around all the time. But somehow I have the nagging feeling that  
> this will introduce a conceptual conflict: I'm afraid that the  
> gesture "double-click object" is already in use for the action  
> "begin editing/labelling object".
>
> When really pretending to work with the prototype, screen real  
> estate becomes a problem pretty soon. I find that, to be able to do  
> fine positioning, I have to zoom in earlier than strictly necessary.  
> Try a vertical toolbar.
>
> 3DView: Looks nice, but, as I said before, it doesn't really add  
> value. What is it's main use case? It's neither suitable for editing  
> or presenting a presentation (obviously), nor for navigating quickly  
> to a particular slide (that's what slide pane is for), nor for  
> quickly leafing through a presentation (normal mode is more  
> efficient for this, and the slide pane gives a better overwiew over  
> the next/previous slides than the one-third-visible slides in the  
> background). One positive factor of 3DView is that the animation  
> makes it clear where I come from and where I’m going. But this can  
> also be implemented in normal 2d view (animate up/down [or right/
> left]).
> -- In my opinion, Cover Flow only shines when browsing through a  
> heap of *unstructured* visual information in search of an  
> interesting item. But slides are structured information and not as  
> huge in number (at least they should be). I've tried to use Cover  
> Flow for files, and it's suboptimal (you don't see enough of the  
> adjacent items and lose a lot of time scrolling to and fro when  
> searching for a particular item).
>
> Again: I LIKE the submenus of the toolbar and their re-use of the  
> triangular "belongs-to" indicator!
>
> What I don't like is the "Frequently Used" shape group in the shape  
> submenu. Is this a changing, "adaptive" list such as Windows XP's  
> Start Menu? If yes, this is very bad, because it prevents the  
> formation of habits. Habits are our friend, they make daily tasks  
> much quicker and save on cognitive capacity, which is released to  
> the user's work. But positive habits can only work if things don't  
> change around in an interface. If "Frequently Used" is actually  
> fixed, it just wastes a lot of precious space near the mouse  
> pointer. This would give Fitts fits. ;)
>
> Thanks for fixing mousewheel scrolling in the slide pane. When  
> "arrowing" through the slides and reaching the edge, however, the  
> animation could be much quicker (around 4 times as quick would be  
> good).
>
> Format buttons: Instant preview on mouseover in the content area is  
> nice. But please make it consistent for all formatting options (also  
> mundane options like bold, italic, etc.). Also, you can’t see the  
> preview when the object is concealed by the menu (e.g. by the  
> gradient menu). Also, I don’t think that making the preview appear  
> in the slides pane is necessary (it could lead to performance issues).
>
> When inserting a shape and clicking e.g. the “insert text box”  
> button, visual feedback that you’re in “insert” mode is still  
> insufficient. EITHER clearly indicate that the user must now draw a  
> box, OR (better) make it modeless by inserting a default circle in  
> the middle of the slide. This way, when simply inserting a default  
> object, the user would experience immediate *closure* (a  
> precondition for satisfaction) and the action of inserting a shape  
> would be a one-step (instead of a multi-step) process.
>
> Master slide button: A nice Idea. The mouseover is a good idea, too.  
> But indicate more clearly which mode you're currently in (slide vs.  
> master).  Also, perhaps use a flip animation (like you see it on Mac  
> OS dashboard widgets or some iPhone apps). A flip animation would  
> make it very clear that I’m now dealing with “another side of the  
> same thing”. The zoom-out-zoom-in animation could mean anything (and  
> it conceptually conflicts with animated zooming). There's an odd bug  
> when switching to master view in slide sorter (=zoomed-out (?)) mode.
>
> In slide sorter mode, how do you drag an object from one slide to  
> the master view enabled on another slide? I couldn't achieve this.
>
> Interaction elements placed next to the slide (pac-man, insertion/
> deletion, master): Keep in mind that more often than not, elements  
> like graphics, etc. will actually *stick out* of the slide and may  
> conflict with those elements. It's even theoretically possible to  
> hide an item behind the control (or worse: the control behind an  
> item). Make clear what will end up behind what.
>
> Zooming currently centers on the middle slide. It should center on  
> the selected slide (maybe a bug in the prototype). Also, manual  
> panning is not possible, and panning doesn't automatically follow  
> when selecting another slide in the slide pane. And, while I'm at  
> it, here's a suggestion to make it easier to fine-zoom with the zoom-
> slider : Make it direct (=coarse) when the mouse is over the slider,  
> but make it become more and more fine-grained the further you move  
> the mouse away above or below the slider. Cf. the music/movie  
> progress bar on the iPod Touch/iPhone with iPhone OS 3.0.
>
> Please make up your mind whether you want "slide sorter mode" or  
> "pac-man zooming". They're too similar to exist both, yet too  
> dissimilar to merge (disappearing panes in slide sorter mode).
>
>
> About "FixedLabel Toolbar, Variant 3":
>
> On not-Macs, the toolbar labels will look like a second kind of menu  
> (which they are). They are located right below the program menu.  
> Surprisingly, this doesn't seem to be as bothersome as this  
> description sounds.
>
> The toolbars themselves are not visible by default, and therefore,  
> there's more space for content. If you single-click a toolbar label,  
> the corresponding toolbar is superimposed over the content area and  
> slide pane. That way, it works similarly to a traditional menu. But  
> when selecting a toolbar item, the toolbar, unlike a traditional  
> menu, doesn't disappear and *stays* superimposed. When you want to  
> access the content behind the toolbar, you have to explicitly  
> dismiss the toolbar by another single-click on *its own* toolbar  
> label. Hm, this gets pretty tedious.
>
> Another way to use this variant is to *double-click* a toolbar  
> label. The content area shrinks a bit to make room for the toolbar.  
> Therefore, no content is concealed by the toolbar. When the toolbar  
> is "enabled" like this, it effectively works like that in Variant 1,  
> only with the labels above instead of below. To hide it again, you  
> single-click on the currently active toolbar label (doesn't really  
> make sense).
>
> Wow, this is complicated! The only benefit of Variant 3 that I see  
> is that it can *temporarily* save content real estate. I would only  
> use it the this way: Keep it activated by default, and double-click  
> the currently active toolbar label to hide it temporarily in the  
> rare situations when I want more content space but don't need the  
> toolbar. The same can *much* more easily be achieved through a show/
> minimize button (where the toolbar labels stay visible in the  
> minimized state, so you save 1 click when the toolbar is hidden and  
> you want to go to a different toolbar)
>
> 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 Impress Prototype 0.11 / July 22 2009

Martin Hanzel
In reply to this post by Andreas Schuderer
That's a lot of words for "Going in the right direction"!
Point: would it be viable to 'merge' Sliding toolbars with the clickable
variant? Kindof like in MS Office, where you click on categories, but
sliding is also very cool... and would be the OOo UI "Signature move".

-Martin


On Wed, Jul 22, 2009 at 8:39 PM, Andreas Schuderer
<[hidden email]>wrote:

> Hi all!
>
> Here's some feedback on today's prototype (0.11 / July 22 2009).
>
> About "FixedLabel Toolbar, Variant 1":
>
> Wow, I didn't know you could actually *load* real ODP (Impress) files into
> the prototype! It's very handy to try out how working with complex documents
> feels.
>
> What I also didn't know: In zoomed-out mode (= slide sorter (?)), you can
> actually *manipulate* the currently selected slide. You can even *drag*
> stuff from the currently active slide to another slide. This works very
> good! On the other hand, this is modal that you must first select the slide
> and can only then manipulate its objects. Making all the slides
> manipulatable without selection could potentially unleash unforeseen
> power/creativity. It would have to be tried out to see.
>
> Context sensitivity: A double click on an object brings up the format
> toolbar. Call it "context-sensitivity on demand." A nice idea, as I
> personally don't want toolbars automatigally changing around all the time.
> But somehow I have the nagging feeling that this will introduce a conceptual
> conflict: I'm afraid that the gesture "double-click object" is already in
> use for the action "begin editing/labelling object".
>
> When really pretending to work with the prototype, screen real estate
> becomes a problem pretty soon. I find that, to be able to do fine
> positioning, I have to zoom in earlier than strictly necessary. Try a
> vertical toolbar.
>
> 3DView: Looks nice, but, as I said before, it doesn't really add value.
> What is it's main use case? It's neither suitable for editing or presenting
> a presentation (obviously), nor for navigating quickly to a particular slide
> (that's what slide pane is for), nor for quickly leafing through a
> presentation (normal mode is more efficient for this, and the slide pane
> gives a better overwiew over the next/previous slides than the
> one-third-visible slides in the background). One positive factor of 3DView
> is that the animation makes it clear where I come from and where I’m going.
> But this can also be implemented in normal 2d view (animate up/down [or
> right/left]).
> -- In my opinion, Cover Flow only shines when browsing through a heap of
> *unstructured* visual information in search of an interesting item. But
> slides are structured information and not as huge in number (at least they
> should be). I've tried to use Cover Flow for files, and it's suboptimal (you
> don't see enough of the adjacent items and lose a lot of time scrolling to
> and fro when searching for a particular item).
>
> Again: I LIKE the submenus of the toolbar and their re-use of the
> triangular "belongs-to" indicator!
>
> What I don't like is the "Frequently Used" shape group in the shape
> submenu. Is this a changing, "adaptive" list such as Windows XP's Start
> Menu? If yes, this is very bad, because it prevents the formation of habits.
> Habits are our friend, they make daily tasks much quicker and save on
> cognitive capacity, which is released to the user's work. But positive
> habits can only work if things don't change around in an interface. If
> "Frequently Used" is actually fixed, it just wastes a lot of precious space
> near the mouse pointer. This would give Fitts fits. ;)
>
> Thanks for fixing mousewheel scrolling in the slide pane. When "arrowing"
> through the slides and reaching the edge, however, the animation could be
> much quicker (around 4 times as quick would be good).
>
> Format buttons: Instant preview on mouseover in the content area is nice.
> But please make it consistent for all formatting options (also mundane
> options like bold, italic, etc.). Also, you can’t see the preview when the
> object is concealed by the menu (e.g. by the gradient menu). Also, I don’t
> think that making the preview appear in the slides pane is necessary (it
> could lead to performance issues).
>
> When inserting a shape and clicking e.g. the “insert text box” button,
> visual feedback that you’re in “insert” mode is still insufficient. EITHER
> clearly indicate that the user must now draw a box, OR (better) make it
> modeless by inserting a default circle in the middle of the slide. This way,
> when simply inserting a default object, the user would experience immediate
> *closure* (a precondition for satisfaction) and the action of inserting a
> shape would be a one-step (instead of a multi-step) process.
>
> Master slide button: A nice Idea. The mouseover is a good idea, too. But
> indicate more clearly which mode you're currently in (slide vs. master).
>  Also, perhaps use a flip animation (like you see it on Mac OS dashboard
> widgets or some iPhone apps). A flip animation would make it very clear that
> I’m now dealing with “another side of the same thing”. The zoom-out-zoom-in
> animation could mean anything (and it conceptually conflicts with animated
> zooming). There's an odd bug when switching to master view in slide sorter
> (=zoomed-out (?)) mode.
>
> In slide sorter mode, how do you drag an object from one slide to the
> master view enabled on another slide? I couldn't achieve this.
>
> Interaction elements placed next to the slide (pac-man, insertion/deletion,
> master): Keep in mind that more often than not, elements like graphics, etc.
> will actually *stick out* of the slide and may conflict with those elements.
> It's even theoretically possible to hide an item behind the control (or
> worse: the control behind an item). Make clear what will end up behind what.
>
> Zooming currently centers on the middle slide. It should center on the
> selected slide (maybe a bug in the prototype). Also, manual panning is not
> possible, and panning doesn't automatically follow when selecting another
> slide in the slide pane. And, while I'm at it, here's a suggestion to make
> it easier to fine-zoom with the zoom-slider : Make it direct (=coarse) when
> the mouse is over the slider, but make it become more and more fine-grained
> the further you move the mouse away above or below the slider. Cf. the
> music/movie progress bar on the iPod Touch/iPhone with iPhone OS 3.0.
>
> Please make up your mind whether you want "slide sorter mode" or "pac-man
> zooming". They're too similar to exist both, yet too dissimilar to merge
> (disappearing panes in slide sorter mode).
>
>
> About "FixedLabel Toolbar, Variant 3":
>
> On not-Macs, the toolbar labels will look like a second kind of menu (which
> they are). They are located right below the program menu. Surprisingly, this
> doesn't seem to be as bothersome as this description sounds.
>
> The toolbars themselves are not visible by default, and therefore, there's
> more space for content. If you single-click a toolbar label, the
> corresponding toolbar is superimposed over the content area and slide pane.
> That way, it works similarly to a traditional menu. But when selecting a
> toolbar item, the toolbar, unlike a traditional menu, doesn't disappear and
> *stays* superimposed. When you want to access the content behind the
> toolbar, you have to explicitly dismiss the toolbar by another single-click
> on *its own* toolbar label. Hm, this gets pretty tedious.
>
> Another way to use this variant is to *double-click* a toolbar label. The
> content area shrinks a bit to make room for the toolbar. Therefore, no
> content is concealed by the toolbar. When the toolbar is "enabled" like
> this, it effectively works like that in Variant 1, only with the labels
> above instead of below. To hide it again, you single-click on the currently
> active toolbar label (doesn't really make sense).
>
> Wow, this is complicated! The only benefit of Variant 3 that I see is that
> it can *temporarily* save content real estate. I would only use it the this
> way: Keep it activated by default, and double-click the currently active
> toolbar label to hide it temporarily in the rare situations when I want more
> content space but don't need the toolbar. The same can *much* more easily be
> achieved through a show/minimize button (where the toolbar labels stay
> visible in the minimized state, so you save 1 click when the toolbar is
> hidden and you want to go to a different toolbar)
>
> 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 Impress Prototype 0.11 / July 22 2009

Martin Hanzel
Oh, yes, and regarding the 3D view, I think that it would be a great idea to
leave it in. It would be really cool if you could present your slideshow
like that (and not to mention WOW the audience). The 3D view is *desirable*,
at least for me.

-Martin


On Wed, Jul 22, 2009 at 9:21 PM, Martin Hanzel <[hidden email]> wrote:

> That's a lot of words for "Going in the right direction"!
> Point: would it be viable to 'merge' Sliding toolbars with the clickable
> variant? Kindof like in MS Office, where you click on categories, but
> sliding is also very cool... and would be the OOo UI "Signature move".
>
> -Martin
>
>
>   On Wed, Jul 22, 2009 at 8:39 PM, Andreas Schuderer <
> [hidden email]> wrote:
>
>> Hi all!
>>
>> Here's some feedback on today's prototype (0.11 / July 22 2009).
>>
>> About "FixedLabel Toolbar, Variant 1":
>>
>> Wow, I didn't know you could actually *load* real ODP (Impress) files into
>> the prototype! It's very handy to try out how working with complex documents
>> feels.
>>
>> What I also didn't know: In zoomed-out mode (= slide sorter (?)), you can
>> actually *manipulate* the currently selected slide. You can even *drag*
>> stuff from the currently active slide to another slide. This works very
>> good! On the other hand, this is modal that you must first select the slide
>> and can only then manipulate its objects. Making all the slides
>> manipulatable without selection could potentially unleash unforeseen
>> power/creativity. It would have to be tried out to see.
>>
>> Context sensitivity: A double click on an object brings up the format
>> toolbar. Call it "context-sensitivity on demand." A nice idea, as I
>> personally don't want toolbars automatigally changing around all the time.
>> But somehow I have the nagging feeling that this will introduce a conceptual
>> conflict: I'm afraid that the gesture "double-click object" is already in
>> use for the action "begin editing/labelling object".
>>
>> When really pretending to work with the prototype, screen real estate
>> becomes a problem pretty soon. I find that, to be able to do fine
>> positioning, I have to zoom in earlier than strictly necessary. Try a
>> vertical toolbar.
>>
>> 3DView: Looks nice, but, as I said before, it doesn't really add value.
>> What is it's main use case? It's neither suitable for editing or presenting
>> a presentation (obviously), nor for navigating quickly to a particular slide
>> (that's what slide pane is for), nor for quickly leafing through a
>> presentation (normal mode is more efficient for this, and the slide pane
>> gives a better overwiew over the next/previous slides than the
>> one-third-visible slides in the background). One positive factor of 3DView
>> is that the animation makes it clear where I come from and where I’m going.
>> But this can also be implemented in normal 2d view (animate up/down [or
>> right/left]).
>> -- In my opinion, Cover Flow only shines when browsing through a heap of
>> *unstructured* visual information in search of an interesting item. But
>> slides are structured information and not as huge in number (at least they
>> should be). I've tried to use Cover Flow for files, and it's suboptimal (you
>> don't see enough of the adjacent items and lose a lot of time scrolling to
>> and fro when searching for a particular item).
>>
>> Again: I LIKE the submenus of the toolbar and their re-use of the
>> triangular "belongs-to" indicator!
>>
>> What I don't like is the "Frequently Used" shape group in the shape
>> submenu. Is this a changing, "adaptive" list such as Windows XP's Start
>> Menu? If yes, this is very bad, because it prevents the formation of habits.
>> Habits are our friend, they make daily tasks much quicker and save on
>> cognitive capacity, which is released to the user's work. But positive
>> habits can only work if things don't change around in an interface. If
>> "Frequently Used" is actually fixed, it just wastes a lot of precious space
>> near the mouse pointer. This would give Fitts fits. ;)
>>
>> Thanks for fixing mousewheel scrolling in the slide pane. When "arrowing"
>> through the slides and reaching the edge, however, the animation could be
>> much quicker (around 4 times as quick would be good).
>>
>> Format buttons: Instant preview on mouseover in the content area is nice.
>> But please make it consistent for all formatting options (also mundane
>> options like bold, italic, etc.). Also, you can’t see the preview when the
>> object is concealed by the menu (e.g. by the gradient menu). Also, I don’t
>> think that making the preview appear in the slides pane is necessary (it
>> could lead to performance issues).
>>
>> When inserting a shape and clicking e.g. the “insert text box” button,
>> visual feedback that you’re in “insert” mode is still insufficient. EITHER
>> clearly indicate that the user must now draw a box, OR (better) make it
>> modeless by inserting a default circle in the middle of the slide. This way,
>> when simply inserting a default object, the user would experience immediate
>> *closure* (a precondition for satisfaction) and the action of inserting a
>> shape would be a one-step (instead of a multi-step) process.
>>
>> Master slide button: A nice Idea. The mouseover is a good idea, too. But
>> indicate more clearly which mode you're currently in (slide vs. master).
>>  Also, perhaps use a flip animation (like you see it on Mac OS dashboard
>> widgets or some iPhone apps). A flip animation would make it very clear that
>> I’m now dealing with “another side of the same thing”. The zoom-out-zoom-in
>> animation could mean anything (and it conceptually conflicts with animated
>> zooming). There's an odd bug when switching to master view in slide sorter
>> (=zoomed-out (?)) mode.
>>
>> In slide sorter mode, how do you drag an object from one slide to the
>> master view enabled on another slide? I couldn't achieve this.
>>
>> Interaction elements placed next to the slide (pac-man,
>> insertion/deletion, master): Keep in mind that more often than not, elements
>> like graphics, etc. will actually *stick out* of the slide and may conflict
>> with those elements. It's even theoretically possible to hide an item behind
>> the control (or worse: the control behind an item). Make clear what will end
>> up behind what.
>>
>> Zooming currently centers on the middle slide. It should center on the
>> selected slide (maybe a bug in the prototype). Also, manual panning is not
>> possible, and panning doesn't automatically follow when selecting another
>> slide in the slide pane. And, while I'm at it, here's a suggestion to make
>> it easier to fine-zoom with the zoom-slider : Make it direct (=coarse) when
>> the mouse is over the slider, but make it become more and more fine-grained
>> the further you move the mouse away above or below the slider. Cf. the
>> music/movie progress bar on the iPod Touch/iPhone with iPhone OS 3.0.
>>
>> Please make up your mind whether you want "slide sorter mode" or "pac-man
>> zooming". They're too similar to exist both, yet too dissimilar to merge
>> (disappearing panes in slide sorter mode).
>>
>>
>> About "FixedLabel Toolbar, Variant 3":
>>
>> On not-Macs, the toolbar labels will look like a second kind of menu
>> (which they are). They are located right below the program menu.
>> Surprisingly, this doesn't seem to be as bothersome as this description
>> sounds.
>>
>> The toolbars themselves are not visible by default, and therefore, there's
>> more space for content. If you single-click a toolbar label, the
>> corresponding toolbar is superimposed over the content area and slide pane.
>> That way, it works similarly to a traditional menu. But when selecting a
>> toolbar item, the toolbar, unlike a traditional menu, doesn't disappear and
>> *stays* superimposed. When you want to access the content behind the
>> toolbar, you have to explicitly dismiss the toolbar by another single-click
>> on *its own* toolbar label. Hm, this gets pretty tedious.
>>
>> Another way to use this variant is to *double-click* a toolbar label. The
>> content area shrinks a bit to make room for the toolbar. Therefore, no
>> content is concealed by the toolbar. When the toolbar is "enabled" like
>> this, it effectively works like that in Variant 1, only with the labels
>> above instead of below. To hide it again, you single-click on the currently
>> active toolbar label (doesn't really make sense).
>>
>> Wow, this is complicated! The only benefit of Variant 3 that I see is that
>> it can *temporarily* save content real estate. I would only use it the this
>> way: Keep it activated by default, and double-click the currently active
>> toolbar label to hide it temporarily in the rare situations when I want more
>> content space but don't need the toolbar. The same can *much* more easily be
>> achieved through a show/minimize button (where the toolbar labels stay
>> visible in the minimized state, so you save 1 click when the toolbar is
>> hidden and you want to go to a different toolbar)
>>
>> 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 Impress Prototype 0.11 / July 22 2009

DrewJensen
Martin Hanzel wrote:
> Oh, yes, and regarding the 3D view, I think that it would be a great idea to
> leave it in. It would be really cool if you could present your slideshow
> like that (and not to mention WOW the audience). The 3D view is *desirable*,
> at least for me.
>  

Hello Martin,

Well - a WOW factor might be nice...but are you really wanting to
Impress the audience with the software used to make the presentation or
with the content of the presentation.

Also, didn't I hear something about keeping the UI uncluttered....how
would presenting in the 3D view fair against that ruler.

That said - yes it is really cool. Then again it dies on 1 of the
systems I've running the prototypes on..something about the graphic
driver not being up to the task...no big thing I suppose.

Drew

---------------------------------------------------------------------
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.11 / July 22 2009

Martin Hanzel
Well, we do want to impress people with the software... otherwise we won't
be having this discussion. As for the content,the 3D view would add to the
impression it makes on users. I say that there is no reason to remove the 3D
view now that we have a functional concept.

I'm not sure what you mean by the UI being cluttered. I take 'cluttered' as
having too many buttons and such as distractions. I don't think the 3D view
would 'clutter' the interface too much. Do you mean that the inactive slides
will steal attention from the active one? If so, the inactive slides can be
easily dimmed or faded so that the focal point is on the bright, active
slide.

If systems don't have appropriate graphics hardware or whatever to run the
3D view, it could automatically revert back with a subtle message instead of
a crash. Anyways, most users these days have decent systems capable of
running 3D. Heck, I have a graphics card from 2001 and it works like a
charm.

-Martin


On Wed, Jul 22, 2009 at 9:47 PM, Drew Jensen <[hidden email]>wrote:

> Martin Hanzel wrote:
>
>> Oh, yes, and regarding the 3D view, I think that it would be a great idea
>> to
>> leave it in. It would be really cool if you could present your slideshow
>> like that (and not to mention WOW the audience). The 3D view is
>> *desirable*,
>> at least for me.
>>
>>
>
> Hello Martin,
>
> Well - a WOW factor might be nice...but are you really wanting to Impress
> the audience with the software used to make the presentation or with the
> content of the presentation.
>
> Also, didn't I hear something about keeping the UI uncluttered....how would
> presenting in the 3D view fair against that ruler.
>
> That said - yes it is really cool. Then again it dies on 1 of the systems
> I've running the prototypes on..something about the graphic driver not being
> up to the task...no big thing I suppose.
>
> Drew
>
>
> ---------------------------------------------------------------------
> 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.11 / July 22 2009

Miroslav Mazel
Hi Martin and others,
I have to argue against a 3D View, because it is unnecessary. It just adds
more weight to Impress, which is already overflowing with things. Instead,
if we want to impress the user, we can definitely add a 3D-view-like
transition option -- that's much more useful, and it's actually something
that the user wants to use; plus, we can graphically polish all of the
existing parts of the interface. But having a 3D View is like having the
easter eggs MS Office used to hold, without the excitement of uncovering
them. The user might see it once and say "That's cool," but it would never
be used and would weigh the application down.

2009/7/23 Martin Hanzel <[hidden email]>

> Well, we do want to impress people with the software... otherwise we won't
> be having this discussion. As for the content,the 3D view would add to the
> impression it makes on users. I say that there is no reason to remove the
> 3D
> view now that we have a functional concept.
>
> I'm not sure what you mean by the UI being cluttered. I take 'cluttered' as
> having too many buttons and such as distractions. I don't think the 3D view
> would 'clutter' the interface too much. Do you mean that the inactive
> slides
> will steal attention from the active one? If so, the inactive slides can be
> easily dimmed or faded so that the focal point is on the bright, active
> slide.
>
> If systems don't have appropriate graphics hardware or whatever to run the
> 3D view, it could automatically revert back with a subtle message instead
> of
> a crash. Anyways, most users these days have decent systems capable of
> running 3D. Heck, I have a graphics card from 2001 and it works like a
> charm.
>
> -Martin
>
>
> On Wed, Jul 22, 2009 at 9:47 PM, Drew Jensen <[hidden email]
> >wrote:
>
> > Martin Hanzel wrote:
> >
> >> Oh, yes, and regarding the 3D view, I think that it would be a great
> idea
> >> to
> >> leave it in. It would be really cool if you could present your slideshow
> >> like that (and not to mention WOW the audience). The 3D view is
> >> *desirable*,
> >> at least for me.
> >>
> >>
> >
> > Hello Martin,
> >
> > Well - a WOW factor might be nice...but are you really wanting to Impress
> > the audience with the software used to make the presentation or with the
> > content of the presentation.
> >
> > Also, didn't I hear something about keeping the UI uncluttered....how
> would
> > presenting in the 3D view fair against that ruler.
> >
> > That said - yes it is really cool. Then again it dies on 1 of the systems
> > I've running the prototypes on..something about the graphic driver not
> being
> > up to the task...no big thing I suppose.
> >
> > Drew
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
This is a site which donates money to a custom charity when you search
(Google or Yahoo!): http://www.neoaid.com/index.php?referer_id=882
Reply | Threaded
Open this post in threaded view
|

Re: Feedback Impress Prototype 0.11 / July 22 2009

Martin Hanzel
Good idea! It would also fox Drew's concern about clutter.

And while we're at it, would it be possible to add some more cool effects to
transitions and such? It seems like they are quite old... and don't show off
OOo's 3D capability.

-Martin


On Thu, Jul 23, 2009 at 12:25 PM, Miroslav Mazel <[hidden email]> wrote:

> Hi Martin and others,
> I have to argue against a 3D View, because it is unnecessary. It just adds
> more weight to Impress, which is already overflowing with things. Instead,
> if we want to impress the user, we can definitely add a 3D-view-like
> transition option -- that's much more useful, and it's actually something
> that the user wants to use; plus, we can graphically polish all of the
> existing parts of the interface. But having a 3D View is like having the
> easter eggs MS Office used to hold, without the excitement of uncovering
> them. The user might see it once and say "That's cool," but it would never
> be used and would weigh the application down.
>
> 2009/7/23 Martin Hanzel <[hidden email]>
>
> > Well, we do want to impress people with the software... otherwise we
> won't
> > be having this discussion. As for the content,the 3D view would add to
> the
> > impression it makes on users. I say that there is no reason to remove the
> > 3D
> > view now that we have a functional concept.
> >
> > I'm not sure what you mean by the UI being cluttered. I take 'cluttered'
> as
> > having too many buttons and such as distractions. I don't think the 3D
> view
> > would 'clutter' the interface too much. Do you mean that the inactive
> > slides
> > will steal attention from the active one? If so, the inactive slides can
> be
> > easily dimmed or faded so that the focal point is on the bright, active
> > slide.
> >
> > If systems don't have appropriate graphics hardware or whatever to run
> the
> > 3D view, it could automatically revert back with a subtle message instead
> > of
> > a crash. Anyways, most users these days have decent systems capable of
> > running 3D. Heck, I have a graphics card from 2001 and it works like a
> > charm.
> >
> > -Martin
> >
> >
> > On Wed, Jul 22, 2009 at 9:47 PM, Drew Jensen <[hidden email]
> > >wrote:
> >
> > > Martin Hanzel wrote:
> > >
> > >> Oh, yes, and regarding the 3D view, I think that it would be a great
> > idea
> > >> to
> > >> leave it in. It would be really cool if you could present your
> slideshow
> > >> like that (and not to mention WOW the audience). The 3D view is
> > >> *desirable*,
> > >> at least for me.
> > >>
> > >>
> > >
> > > Hello Martin,
> > >
> > > Well - a WOW factor might be nice...but are you really wanting to
> Impress
> > > the audience with the software used to make the presentation or with
> the
> > > content of the presentation.
> > >
> > > Also, didn't I hear something about keeping the UI uncluttered....how
> > would
> > > presenting in the 3D view fair against that ruler.
> > >
> > > That said - yes it is really cool. Then again it dies on 1 of the
> systems
> > > I've running the prototypes on..something about the graphic driver not
> > being
> > > up to the task...no big thing I suppose.
> > >
> > > Drew
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
>
>
> --
> This is a site which donates money to a custom charity when you search
> (Google or Yahoo!): http://www.neoaid.com/index.php?referer_id=882
>
Reply | Threaded
Open this post in threaded view
|

Re: Feedback Impress Prototype 0.11 / July 22 2009

DrewJensen
Martin Hanzel wrote:
> Good idea! It would also fox Drew's concern about clutter.
>  

*smile*...,maybe.

> And while we're at it, would it be possible to add some more cool effects to
> transitions and such? It seems like they are quite old... and don't show off
> OOo's 3D capability.
>  

Just to clarify my statement about the 3D effect not working on a test
machine - all the real machines I have run on work fine.

The problem is happening only in a hosted OS (Win 7 (32bit) hosted under
Ubuntu 9.04 [64bit] using the latest VirtualBox  binaries). To date this
is the first real problem I've found with that setup. So, when I said
'maybe it doesn't really matter' before I wasn't trying to be
smart-alliky...my guess is that the fix will be found with the
supporting software and not the application.

Drew






---------------------------------------------------------------------
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.11 / July 22 2009

Martin Hanzel
But Openoffice exists as a Linux binary as well. I can't think of a reason why someone would use Openoffice for real work in Virtualbox

-Martin


On Thu, Jul 23, 2009 at 3:01 PM, Drew Jensen <[hidden email]> wrote:
Martin Hanzel wrote:
Good idea! It would also fox Drew's concern about clutter.
 

*smile*...,maybe.


And while we're at it, would it be possible to add some more cool effects to
transitions and such? It seems like they are quite old... and don't show off
OOo's 3D capability.
 

Just to clarify my statement about the 3D effect not working on a test machine - all the real machines I have run on work fine.

The problem is happening only in a hosted OS (Win 7 (32bit) hosted under Ubuntu 9.04 [64bit] using the latest VirtualBox  binaries). To date this is the first real problem I've found with that setup. So, when I said 'maybe it doesn't really matter' before I wasn't trying to be smart-alliky...my guess is that the fix will be found with the supporting software and not the application.


Drew






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


Reply | Threaded
Open this post in threaded view
|

Cloud Computing - another view ( was: Feedback Impress Prototype 0.11 / July 22 2009 )

DrewJensen
Martin Hanzel wrote:
> But Openoffice exists as a Linux binary as well. I can't think of a
> reason why someone would use Openoffice for real work in Virtualbox

Indeed - Next thing you know people will be talking about pushing
servers onto ( into? ) the cloud and using Remote Desktop Protocols to
commission and decommission virtual desktops to handle surges in
workforce on an as needed basis.

But this is most likely not the forum for such a discussion.

Best wishes,

Drew



---------------------------------------------------------------------
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.11 / July 22 2009

Bernd Eilers
In reply to this post by Andreas Schuderer
Andreas Schuderer wrote:
> Hi all!
>

Hi there!

>[...snip...]
> About "FixedLabel Toolbar, Variant 3":
>
> On not-Macs, the toolbar labels will look like a second kind of menu
> (which they are). They are located right below the program menu.
> Surprisingly, this doesn't seem to be as bothersome as this description
> sounds.
>
> The toolbars themselves are not visible by default, and therefore,
> there's more space for content. If you single-click a toolbar label, the
> corresponding toolbar is superimposed over the content area and slide
> pane. That way, it works similarly to a traditional menu. But when
> selecting a toolbar item, the toolbar, unlike a traditional menu,
> doesn't disappear and *stays* superimposed. When you want to access the
> content behind the toolbar, you have to explicitly dismiss the toolbar
> by another single-click on *its own* toolbar label. Hm, this gets pretty
> tedious.

Well the feature is just not finished. Consider that the idea is that it
should disappear if an item was selected.

 > [...snip...]

Kind regards,
Bernd Eilers



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