Re: Screenshots in Gnumeric Docs.
- From: Eric Baudais <baudais okstate edu>
- To: gnumeric list <gnumeric-list gnome org>, gnome-doc-list gnome org, Jody Goldberg <jody gnome org>
- Subject: Re: Screenshots in Gnumeric Docs.
- Date: Thu, 14 Mar 2002 19:40:09 -0600
I think that all this is very good to see. Planning for the docs in a sane
manner is will make everything easier. Yet right now the main push of the
GDP, imho, is to get the XML format working throughout the help system and to
correctly implement the API Mr. Blandford has made.
On Thu, Mar 14, 2002 at 05:37:32PM -0500, Jody Goldberg wrote:
On Thu, Mar 14, 2002 at 04:37:33PM -0600, Kevin Breit wrote:
I understand the purpose of having a GUI element reference. I don't
really think that they are a huge benefit to most users. I can't recall
the last time I said "What does this button do!?" If I do question, you
have tooltips for the job. A GUI reference is used less than the real
documentation and would be a huge task for the documentation writers.
If a user wants to write it, they can. But I question if it really is
OVERLY important.
As Scott points out there is a usecase for element docs. Specificly
finding an explanation of what some feature actually does.
I think this will require context sensitive help. For some reason people keep
saying this has to implemented in GTK+. Since it wasn't implemented in
GTK+-2.0 like it was supposed to hopefully this will happen in the next major
release.
Adrian asked the following requests:
1) Who the help (or sections) are geared towards
Gnumeric like most office apps is going to have 2 broad user groups.
- your average user that just wants to get some work done.
These folk need 'howto' type writups for day to day
operations. 1.0 is sufficient for the majority of there
needs.
- power users
This is a whole different ball of wax. 1.0 is no where near
complete enough to handle the extras these folk want.
Additionally what they want is ulta-detailed specs of what
each feature does. Something only marginally higher level
than reading the source.
Catering to the former seems like a higher priority right now
because that set of capabilities are not going to be changing that
quickly. Trying to document the power features as they are being
implemented seems like an excercise in frustration. Those docs will
likely be generated as the features firm up.
I would also like to add 2 other groups.
-your average user coming from MS Excel.
These folks will know the basics of how a spreadsheet works. They will
know how Excel does things and will want to know what has changed from
their traditional way of doing things. It should point out the changes
and also why the change has occured, possibly pointing how some new
features.
-your new user to spreadsheets.
These people don't know much about the general layout of the spreadsheet
or even how to operate one. They just know they need a pie chart or a
line graph of some data and maybe some formulas in the sheet.
2) What the outline of the help structure is to be
TOC
automated I hope
Introduction
optional
Task Description
useful
Glossary (optional)
optional
Index (optional)
NOT optional, A good quality index is paramount.
Very few people want to read an manual. They want to be able to
jump to the section they are interested in.
The long term goal is to have this automated so when the documentor wants to
put a term in the index they add an indexterm tag. I'm not sure the current
state of this feature. Maybe someone else can comment on it.
3) A clear long term (several year) committment to a particular set of
formats.
I don't follow what you mean.
I'm not sure what you mean either. The GDP has several long term commitments
to particular formats. Last year we decided to switch to DocBook XML and use
XSLT to process the documents. We're committed to using OMF for document
meta data and having that meta data processed by scrollkeeper. We hope that
all application's documentation will take advantage of the infrastructure
we've built or are in the process of implementing.
Eric Baudais
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]