Subject: Re: Topic: Templates and 1.0
From: Paul Rohr (paul@abisource.com)
Date: Fri May 04 2001 - 14:45:49 CDT
At 11:32 PM 5/3/01 -0400, Dom Lachowicz wrote:
>Sure, here's what I expect the UI to resemble (the Unix UI now resembles
>this):
>
>http://koffice.kde.org/kword/pics/kword9.png
Is that UI where you also got the idea for standalone Import/Export menus?
It looks like the main differences here from Word's File/New UI are:
- no previews
- the normal.dot equivalent has its own radio button
- another dialog to choose additional documents
- no way to specify the document/template distinction
I still like Word's UI here, because there are fewer entry points. Instead
of 6 menus (New / Open / Import / Save / Save As / Export), you only have
four, which work as follows:
A. File/New ... brings up a template-oriented dialog, which defaults to
creation of a normal new document, if you just hit OK. (Note that Ctrl-N
and the toolbar button both skip showing the dialog at all -- you just get a
normal new document.) It also allows you the following two options:
- choose a different template to start from
- create a new template for later use
The one thing they don't offer is a way to locate other files to use as
templates, which we should.
B. File/Open ... brings up a file selector dialog, where you can choose any
file to open that we know how to import. IIRC, opening a template file here
allows you to edit it.
C. File/Save ... either just does it, warns you, and/or triggers the
File/Save As dialog (whichever is appropriate).
D. File/Save As ... brings up a file selector dialog, where you can choose
the file name and save it as any file type we know how to export. If you
opened an existing file, this should default to the same file name and type
as it started out as. If this is a new file, it should default to either an
AbiWord document (.abw) or an AbiWord template (.awt), depending on which
you chose in the File/New dialog.
To implement all of this, we'd just need to add a trivial new file type, and
an XP dialog for #A (which you've already started on, I assume, although I
couldn't find anything in abi/shots).
>>1. Personalization. By changing your own copy of normal.dot, you can
>>change the default look of all new documents you create, thereby avoiding
>>lots of UI complexities for changing the default font-size, paragraph
>>spacing, etc.
>
>Sure, this is totally possible, and even preferable. This means that we
>should no longer hardware values into the PD_Document class. I'm envisioning
>the following - new pd_Document(NULL) returns a pd_Document.import() on some
>standard and defined default template:
>
><abiword>
><styles>
><s name="Normal" props=""/>
><s name="Heading 1" props=""/>
>...
></styles>
><section columns="1" ...>
><p props="lang:en-US; align:left;..."><c></c></p>
></section>
></abiword>
>
>This doc just basically contains all of the defaults that we rely upon/fall
>back to.
Exactly. I'd *love* it if we could migrate all the hardwired stuff here.
Two quibbles, though:
- There shouldn't be *any* explicit props on that empty p.
All default properties belong in the style definitions instead.
- What do we do if we can't locate any normal.dot file to bootstrap the
process? I've been assuming that we'd still need a hardwired set, but
we could just refuse to launch, I guess.
Otherwise, we're in total agreement on this. I think people would *love*
the ability to customize the default look of their documents by just editing
a template file in AbiWord. (That snazzy new Styles UI will come in mighty
handy, no?)
>>2. Boilerplate. It allows you to start new documents with other looks and
>>feels by copying in content and/or styles from another existing document
>>(which is usually read-only). For example, the fax cover sheet your office
>>uses can be opened repeatedly, creating a new document each time so you can
>>type in just the name, phone number, and a brief message in the right
>>spots.
>
>We already have this functionality via File->Import and File->Export. They
>thinly wrap backend calls that I've already implemented. This is necessary
>for #1 && #2
What do you think of the suggested File/New UI above? I'd like to get by
with less menu clutter here if we can.
>>3. Style upgrades. Some groups need a "house style" for their documents,
>>so that everything that goes sent out has a similar look. By sharing the
>>same template for a whole series of documents, each document can look like
>>it goes with the others, which is mighty handy when doing stuff like
>>distributed authoring of chapters of a book, or something. Indeed, some
>>groups invest a lot of effort in devising really pretty templates that
>>match
>>their letterhead, or whatever.
>>If those documents are written using styles, instead of explicit
>>formatting,
>>then a template system that Just Works allows you to -- somehow, I forget
>>the exact UI incantation -- *upgrade* all documents which reference that
>>template so they all inherit the new look and feel. (For a rough example,
>>think of how HTML can reference and use an external CSS stylesheet.)
>
>I think that this will be hard to implement and should be post 1.0, unless
>someone steps up to do the code. The bulk of this functionality is contained
>within proposal #2, but you unleash a huge can-of-worms when you talk about
>redefining a whole *set* of documents based on some common stylesheet.
Does anyone remember how the UI for this works? I'm thinking that the
implementation wouldn't be that bad if you do it right.
Specifically, what if you wait to trigger the update from the document
(rather than the template)? To do so, this would mean that you'd need to
store two additional pieces of information in each document:
- which template it was based on
- which version of the template we used
This doesn't necessarily need to be anything fancy -- perhaps even as simple
as:
- a URL-encoded path (to maximize portability)
- a date/time stamp for that file
Then, once you've got the document open, it's not hard to check whether that
template has been updated since then. If so, you extract the style
definitions from the template and merge them over any styles which the user
hasn't modified. (This extract and merge operation is the only real work I
can think of, but it's not hard.)
Note that since we've copied all the information out of the template to
start with, this whole operation can be skipped if the template file can't
be located.
Thus, the question becomes, when and how do you do the check? I can think
of three alternatives, off-hand:
Automatic -- When opening a document, do a check to see if the
template's been updated. If so, raise a yes/no message box to ask if the
user wants to merge. There should be a "don't ask me again" checkbox here,
as well, I suppose.
Reset -- From the styles dialog, we already know whether a style
definition is user-defined, no? Then we may also want a "reset" button
which changes the style back to it's default definition (ie, extract and
copy the definition from the template).
Manual -- For completeness' sake, we probably want an ability someplace
in the UI to allow users to explicitly change *all* styles back to the
template defaults. I think this may be an option in Word's style gallery
(or whatever they call it now), but there are probably other places this
could go. In any event, if we implement the "automatic" case above, this
can wait.
How does that sound?
one final note
--------------
The above proposal very deliberately mirrors Word's concept of templates as
a parallel filetype. As an implementation detail, the only three relevant
distinctions between .abw files and .awt files are:
- the suffixes
- one gets slightly privileged in the UI
- each .abw references one .awt, but .awts are standalone
Other than that, the file formats are identical, so they use the same
imp/exp logic. The only difference is that .awt files don't include
references to any other .awt files, so on import they skip the "automatic"
check mentioned above.
Of course we can choose *not* to do things this way, but I really like the
idea of using AbiWord to take advantage of other products' templates. In
effect, *our* template feature shouldn't care which file format the template
was originally created in, because we'll eventually be able to read and
write *anybody's* templates.
For example, the day you decide to "upgrade" from Word to AbiWord -- yes, I
know most people won't do so tomorrow without tables, etc. -- what do you
want to happen to all the customized templates you've been using?
Eventually, of course, you'll go ahead and use Save As .awt to strip all the
bloat out of your poky old binary templates, but in the mean time, wouldn't
it be nice if all your existing templates Just Work in AbiWord, too?
Cool, huh? :-)
Paul
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:02 CDT
