Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Hi Marc,

On So, 2014-01-25 at 01:28 -0500, Marc Paré wrote:
Le 2014-01-22 16:16, Mirek M. a écrit :
I knew this was going to be brought up -- the word "complement" was chosen
Again, this is a question of focus.
I'd really prefer to focus on creating the best speech complements rather
than speech replacements, as, when given in conjunction with a speech, the
latter tends to take focus away from the speech. If the slides are a
full-on replacement, why is the presenter even there? Why not just autoplay
the slides?

That's not to say putting up only slides is worthless -- they often provide
a good overview of the speech.
That said, it's always better to provide the slides along with the talk
(video or audio, or even transcript), and that tends to be the norm

I believe what you are describing is an outcome ideal and not a 
functional use of Impress. IMO, we have to be careful to not purpose 
Impress to a narrow definition as it may lead to a tool that is rendered 
of less use for those who use it for what it essentially does best, and, 
that of slideshow presentations.

In education, we start school children experimenting with presentation 
software and later following with teaching them to complement their 
slideshows with speeches. It is only at the very end of their academic 
highschool years where we try to hone students skill sets at creating 
speeches that are in fact complemented by their slideshows.

What you are basing your present ideal of the tool is the outcome of all 
of this training. Till now, Impress fits in well with this type of 
training and it would be sad to see Impress being given a design purpose 
that sits only well with an end outcome goal.

IMO, giving Impress too narrow of a design purpose may result in having 
the very people who use it now to train early years students to look at 
using a different tool in primary/secondary school systems. It is pretty 
obvious to classroom teachers that tools used to teach young students 
are often times the tools they will use later on in life.

I see no purpose in moving the design of Impress away from what most 
people see it as being a good standalone slideshow tool. However, I see 
every reason to see Impress given an added design emphasis of not only 
being a good quality slideshow tool, but also one that helps in ways to 
complement speeches, for example, add some way to store "presentation 
notes" that may be read off a second screen, while the first screen runs 
the slideshow; or a way to store notes that accompany a slideshow, and 
where these notes may be pulled later to read along with the slideshow etc.)

We should be careful in giving any of our software too narrow a purpose 
definition, as we risk designing it for too narrow a slice of 
users/niche. Therein is where I would worry.

So, a couple of things:

First of all, there IS a need to define whether Impress is meant to
complement or replace speeches.
If it is the latter, we should optimize Impress for autoplaying
presentations without a speaker. Impress would essentially become
animation software.
If it is the former, we should optimize Impress for presentations
controlled by the speaker. Right now, we're more optimized for
complementing speeches. That's why Impress is slide-based rather than
keyframe-based -- to allow the speaker to spend as much time as they
want on each slide.

You can see how the two can be at odds, and we should be clear on which
use case to optimize for. If we don't optimize for either, we end up
with software that is mediocre at both, and we get replaced by software
that is focused -- animation software on one side, presentation software
on the other.

Second of all, as outlined above, optimizing software for a certain
use-case doesn't mean that that software can't be used for other
purposes. I myself have used Inkscape to craft presentations using the
Sozi extension, and Inkscape definitely wasn't designed as a
presentation editor. Thanks to our extensions and even to accidental
use-cases that arise (e.g. Paint was never designed as a photo editor,
yet I've seen people use it for that purpose), there will always be room
for alternative uses.

When I was in grade school, I was taught to use WordArt and ClipArt to
create "fancy" documents. The reason why I was taught this wasn't
because these features were in any way useful, but because they were
part of the software suite we were supposed to be taught. The teacher
just picked random features to teach us. If the software was more geared
towards creating quality documents (rather than toward adding as many
features as possible), perhaps I might have learned something useful

If we tweak something in Impress, the curriculum will change to
accommodate those tweaks. After all, the end goal is still the same --
to craft a presentation to complement a speech. If it's the goal of the
curriculum to progressively teach children to use presentation software
so that one day they could do that, there's no reason Impress would be
dismissed. In fact, if complementing a speech was simpler in Impress, it
would probably be chosen over the competition.

Lastly, if we are ever to develop independently of what the competitor
does, we need to know what we're striving for. If we don't have a focus,
we can't be surprised that the experience is sub-par.
(As Aral Balkan says, "when we examine the open source world, we find
only features‐driven products. It is not surprising, then, that open
source — and free software before it — has not achieved mainstream
adoption in the consumer market. The features-driven products it churns
out simply cannot compete with the design‐led, seamless experiences
being created by closed vendors using experience‐driven development
processes." [1])


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.