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 > > deliberately. > > 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 > > nowadays. > > 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 instead. 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]) [1] http://aralbalkan.com/notes/the-missing-quadrant-of-consumer-technology/ -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
