From koffice-devel  Tue Feb 12 07:01:42 2002
From: Rob Landley <landley () trommello ! org>
Date: Tue, 12 Feb 2002 07:01:42 +0000
To: koffice-devel
Subject: Re: Question about your KPresenter's review
X-MARC-Message: https://marc.info/?l=koffice-devel&m=101351897609082

Another opinion from one of the other members of the presentation group...

On Monday 11 February 2002 10:24 pm, Catherine Olanich Raymond wrote:

> I did not intend to impute any particular intention to your passing that
> Web pointer to me, and if I did I apologize.
>
> I am glad that the next version will have improved documentation.  That is
> a good thing.

Documentation also helps people think through a user interface.  The 
interfaces we've seen that that are well documented tend to be better 
interfaces, simply because somebody went through it from the point of view of 
a new user, and if anything was particularly egregious they noticed it.  
(It's not quite real end-user feedback, but it's probably the next best 
thing.  And it makes collecting real end-user feedback easier, since it makes 
collecting real end users easier.)

A large part of the point of the presentation is that end user feedback is 
vital to making a good product.  The more you get, the better the product 
will be.  Everybody knows you can't find bugs without testing, and if you 
haven't subjected the thing to real world use yet then you haven't found all 
the bugs.  Trying to debug without real world usage situations is futile 
after a certain point.

The design and the user interface work the same way.  Naieve end users are 
your best design assitance.  They will try very hard to bend the product to 
what they need, all you have to do is listen.  (Eric can tell you about 
fetchmail, how it never occurred to him to just deliver the mail to port 25 
and let the local MTA figure out where your mbox is until and end user went 
"bonk" at him.  It wasn't hard to implement, it's just not how he was 
thinking about the project because he was coding it more than using it.  
Nothing is foolproof because fools are so ingenious.  You know how no battle 
plan survives first contact with the enemy?  Well, very few design 
assumptions or interfaces should survive first contact with the end user, but 
regrettably many of them do anyway.) 

It all boils down to cultivating your end user base as the number one 
priority, and LISTENING to them as your biggest asset.  Adding new features 
and polishing old ones in hope the shiny bait will attract new users isn't 
very effective.  It's probably a better use of time to talk a relative into 
using it for a week and asking them WHY they inevitably throw up their hands 
in frustration and go back to Windows, and then following those leads.  
10,000 lines of code to make the menus animated and transparent with pop-up 
tool tips isn't worth 100 lines to make the address book print, if that's 
what's really bothering the end user.  If a project only has 10 users, 
pumping them for information and making them happy enough to recruit an 11th 
for you is probably the best way to grow your user base.

Tim O'Reilley wrote a good piece on this that Eric could probably dig up...

(I feel all of this really should be preaching to the choir and restating the 
blindingly obvious...)

> However, it's not my understanding that a complete overhaul of KPresenter
> is contemplated (if I'm mistaken, let me know!).  KPresenter is out there. 
> It's available to users, and users are encountering it.  Users other than
> me, Eric and Rob likely are having problems with it.  Some of those
> problems could be lessened by improving the documentation.  Lessening those
> problems in that manner would, I believe, create goodwill for
> KPresenter/KDE generally by demonstrating the development team's interest
> in helping the program work better for the users.

I'm not too worried about KPresenter.  Eric and I found MagicPoint, and I 
personally think the easiest way to get good presentation software for unix 
is to write a good front end for that.  It's small and simple and does what 
we want already.  Bolting a good user interface onto a good code base that 
already does what you want is fairly easy.  If putting good code behind a 
snappy polished interface after the fact was easy, we'd all be using 
Windows...

(There's a book by a dude named Greg Pomerantz called "The Unix Philosophy".  
It's quite good.  Talks about separation of UI and engine.  Like XSane...)

> > I can't "send it to you". KOffice CVS requires Qt3 and KDE3, and
> > KPresenter is under heavy development... better wait a bit. But if you
> > can compile source code or if you can get Eric to do it ;), you can
> > always grab the latest stuff using anoncvs
> > (http://www.kde.org/anoncvs.html)
>
> Okay, that's fine.  Thank you.  See, I simply don't always know what is
> easy to do, and what is hard, or inconvenient, with regard to obtaining new
> versions of a program that's under "heavy development."  Part of the burden
> of being a user, I guess.  :-)

End users never mess with CVS. :)

> On the other hand, you knew enough to be able to "fix things".  I do not
> have that kind of knowledge.  As an end user, I don't know enough to know
> why a program does things in a particular way, or even how to find out why
> a program does things in a particular way.  I can only describe the fruits
> of my experience of attempting to use it.

Teaching Cathy more about how to understand the plumbing so she can jiggle 
the handle properly when it doesn't work is nice, but not the objective.  If 
we wanted to just 

> > > Out of curiosity, which other "applications for making presentations"
> > > have you tried to use?
> >
> > Powerpoint.
>
> Interesting.
>
> The law office where I work runs Windows NT and uses all Windows/DOS
> applications.  However, because I don't usually need presentation software,
> I did not attempt to experiment with PowerPoint until after I had attempted
> to use KPresenter.  KPresenter was the first presentation software package
> I ever used.

I hadn't used powerpoint either when I tried kpresenter.  I played around 
with it a bit to see if Cathy was missing something obvious.

The two main things I wanted to do with it were place pictures and text in 
slides.  Pictures largely worked ok (modulo bugs: making a window 
significantly larger than the slide you're editing shows several bugs and 
paint problems.  Cathy's desktop is something like 1700x1200.  Positioning a 
picture off the edge of the slide displays off the edge when you drop it (and 
on some but not all redraws), but you can't grab it again outside the slide 
(although it looks like you can).  Clipping the display to the slide would be 
nice.  But on the whole it worked.)

Text was another story.  It took me a while to figure out how to make text 
work.  Right clicking on the slide didn't let me insert text, the pulldown 
menus didn't have an insert text, the toolbar up top didn't have any way to 
insert text.  (I'm used to toolbars along the top, not down the side.  I even 
find web browser sidebars annoying and turn them off.  Maybe it's just me...)

Eventually I found the tiny little unlabled icon on the left that let me drop 
text boxes.  I didn't have too much trouble resizing it, but figuring out how 
to edit took some doing.  (I'd never needed to double-click a picture.  What 
would that do?)

The resize rectangle went away when the cursor showed up: despite the thing 
still being selected, I couldn't see its edges.  Annoying.  The text window 
didn't start in edit mode, and didn't expand itself to fit the text I typed 
and expect me to hit enter when I wanted a second line.  That was the 
behavior I expected.  The behavior I GOT was that first I resize it and guess 
how big it should be with no text in it yet, because if I immediately 
double-clicked and started typing text I got one character per line going 
almost straight down, and if it went off the bottom I couldn't grab the 
bottom right resize dot like I normally do, because it was off the bottom fo 
the slide.  Then I had to resize it AGAIN when I was done, because I never 
guessed right and sometimes I wanted two lines of text anyway.

The border vanishing in edit mode contributed to this problem, of course.  I 
didn't know how much space I had before it wrapped me.  Once or twice I 
accidentally double clicked when dropping the box and it did go straight into 
edit mode, but went off the bottom of the screen before I'd typed ten 
characters (I touch-type...)

My assumption about changing the options of an object was to pop up a menu.  
So I right clicked on the text I'd entered, but that didn't let me change the 
text color, the font, underline.  I still haven't figured out how, actually, 
I gave up first.  (We gave it another try later and found several interesting 
behaviors.  It once swapped so much it triggered the OOM killer and exited, 
with around 20 slides on a machine with 1/4 gig of ram and twice as much swap 
space.  Inserting slides in the middle confused it on a couple of occasions.  
Stuff in full screen mode didn't always look like the preview (in some cases 
text objects that showed up in a window were completely missing full screen). 
 It sometimes took around 10 seconds to change slides on a dual pentium 400 
system.  One strange bug with resizing text objects was that sometimes it 
decided to double the size when you released it.  (This one might have been 
that the size was calculated as distance you'd let go from the top left edge 
of the slide, not the top left edge of the text object.)  And the "resize box 
to fit text" option (which SHOULD be what it does in edit mode anyway: when 
you've got one line don't start a second until they hit enter, when they've 
got two lines you know how wide it is already) left any extra space on the 
right edge alone, which was generally the main thing that needed resizing...

On the whole, I was not impressed.  Pictures and text are 90% of what you do 
with slides.  I got the impression nobody had ever really used the text part. 
 And since the project had 8 zillion other features you had to wade through 
to find text and pictures (which then didn't work very well), it didn't seem 
like the time being spent on the thing was particularly focused...

That's why we were so hard on KPresenter.

> > > I had never used a presentations application before my experience with
> > > KPresenter.  However, afterward I experimented a little with MS
> > > PowerPoint--and found text editing, at least, to be a lot easier to
> > > deduce and less frustrating.
> >
> > Doesn't powerpoint work the same way? Click on object to move it,
> > double-click on it to edit it ?
>
> I don't have PowerPoint on the machine I am answering you e-mail from, and
> I don't remember enough of my experiment with PP to answer your question
> fairly.  I'll take another swing at PowerPoint at the office tomorrow and
> let you know what I think.

While I realise that emulating powerpoint is a great way to attract an 
established userbase that somebody else has already terraformed and 
housebroken, using it as an excuse for bad behavior is not necessarily a good 
thing.  (Double-click meaning edit is great.  But does that have to be the 
ONLY way to edit, and does the default behavior have to be NOT edit and an 
absence of intelligent automatic resizing?  And double-click a random object 
to edit it didn't help us: we were only dealing with two object types 
(pictures and text), one of which you couldn't edit (no built-in paint 
program) and the other being text which you edit with the keyboard, not the 
mouse anyway, so when it's focused but not in edit mode it's basically in 
"intentionally ignore the keyboard" mode.  I can see that as a safety catch, 
but when the text object is first created and is empty?

Rob
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel