discuss: re:Online editing (was: One-page replacement for LDP-Author-Guide)
Subject:
Re: re:Online editing (was: One-page replacement for
LDP-Author-Guide)
From:
Tabatha Persad ####@####.####
Date:
2 May 2003 21:23:26 -0000
Message-Id: <1051910093.20320.108.camel@mysticchild>
On Fri, 2003-05-02 at 13:46, Greg Ferguson wrote:
> On 02 May 2003 13:26:24 -0700 Tabatha Persad ####@####.#### wrote:
> > The "form" idea, where a user could enter the relevant document
> > information, and then proceed to fill in the blanks until the document
> > is complete, is to me the secret of success.
> > ...
> How do you intend to enter tables, lists, code examples, graphics,
> etc. - all the content for the body of the document? Will the user
> need to know some form of markup? Or will they 'drop into' having to
> use DocBook?
I think a user could get by with the concept of markup without having to
necessarily know it. For example, when editing a paragraph that has a
command in it, I browse through the DocBook tags to find the most
suitable tag (in that case, <command>). Perhaps there is a menu or list
of basic markup items (not tables or graphics or the more complicated
things) for the user to choose from to markup a particular word or
phrase.
For more complicated items (as you mention below), maybe the user could
select, say, "table" from a list, and then they could enter some details
about the table, like rows and columns, add some headings, and then
enter the table data once a table was generated. Once complete, the
entire table markup along with the entered data would all be together.
(In my head I keep seeing a user choose an "Insert" button, choosing an
item they want in their doc, and then being prompted for the content
until it can be generated with its markup. Users could always go back
into areas, or leave them blank and fill them in later, because the form
would provide them with the field based on the "item" choice they'd
made.)
For a graphic insertion, maybe a user could click a link to browse their
hard drive for the file and then submit the graphic; they may be
prompted for specs on the layout, if any are available (like tags that
contain blah="something"), but if it were done in a form/wizard kind of
way the user wouldn't have to learn that markup, only make a few
decisions on placement or type of items. Maybe along the way they'll
start understanding the structure and move to an offline editor of their
choice... done correctly, it could help people learn a little as they
go. (I'll always be an optimist, no matter how many of you tell me I'm
crazy!) :D
> It's very *easy* to pull together a form to assemble a skeleton document,
> with some associated header and meta-data fields (like taking
> Sample-HOWTO.xml and slamming in fields from a form the user fills out).
> It's quite another problem to provide *true* document content editing!
> So what are the plans for that? I suppose you could have clickable
> entries for each tag-type that would in turn pop up a specific form,
> and allow the user to fill-in data, but that to me is very "clunky'.
>
> I'll stick with good old reliable vi ! ;-)
I agree, online editing probably wouldn't be a perfect process, but I'm
sure there are ways to make it simple enough for people getting
started. Skeleton documents/templates are kind of what would be used in
an online environment too, just that you're filling them in as you go
with fields instead of between tags.
I guess a lot of this would have to depend on what kind of users would
be using the tool - whether they are experienced with markup or not -
and other criteria. Do I want so much that it's impossible, or not very
viable? :D
--
Tabatha Persad
Web: www.merlinmonroe.com
Linux Documentation Project Review Coordinator (http://www.tldp.org)
Linux Counter Area Manager US:wa (http://counter.li.org)
