[scribus-dev] Who is going to kill the style dialog ? Urban renewal

[Christoph Schäfer]

On Wednesday 10 November 2010 18:06:12 Gregory Pittman wrote:
> On 11/10/2010 09:55 AM, dbolack at electricmulch.com wrote:
> >>> The values are always visible and accessible. They are in the
> >>> Properties Palette. The one issue to solve here is to put in the PP
> >>> all the settings that are only available into the actual Style
> >>> Manager.
> > 
> > I'm that wacky class of user who finds those side palettes distracting
> > and wasteful of screen real estate.
> 
> GUI DESIGN AS URBAN PLANNING
> 
> The PP has already become an overcrowded ghetto of functions that may
> have seemed like a good idea at the time, but have created a succession
> of cramming of information and choices into a dialog which would
> realistically need to crowd out the document display to easily show
> everything in it.
> 
> The answer is to find the philosophical approach that can serve as some
> sort of urban renewal, finding a new home for squatters on this precious
> real estate. At this point, if you're going to live in the PP, you have
> to justify your existence, either in terms of importance or kind of task
> you perform. I would propose that anything which is a simple toggle, a
> yes/no, check/uncheck, is a prime candidate for eviction to some other
> place, maybe a Context menu. (this brings up an interesting possibility
> of a Context Menu coming out of right-clicking the PP)
> 
> Only after some ground has been cleared, the remaining bits reorganized,
> are we in a position to putting more things in there, but even they
> would have to abide by the new paradigm.
> 
> The weakest argument for keeping something in the PP is that "it's been
> there since version 0.x". In software development, the only constant is
> change.

The comparison to urban planning is probably appropriate, and urban renewal 
can sometimes be achieved by adopting what works elsewhere.

Since the original posting was about the Style Manager and the future of this 
beast, I'd like to focus on this one, while the PP is currently being 
rewritten anyway.

When it comes to styles, there are probably three major aspects that have to 
be dealt with: editing, managing and applying them. In the future we may also 
have to consider whether a style can be a "shared resource" (Jon Cruz is also 
tinkering with this aspect in his work on Viaduct, and RagTime 6.5 recently 
introduced something like that: http://www.ragtime.de/img/art_tmb/308_1.jpg), 
but let's focus on the three obvious challenges.

To see how styles have been implemented elsewhere, I looked at several DTP 
programs and word/document processors: AbiWord, KWord, OpenOffice.org Writer, 
LyX, RagTime, QuarkXPress, and InDesign.

As it seems, there isn't much variety in style implementation (at least from 
the perspective of user interaction), and the details are only minor. The 
major differences can be found in style management. AbiWord, XPress and 
InDesign (and currently Scribus) use a free-floating dialog that lists all 
available styles and also enables access to style editing. Except for Scribus, 
all open a new dialog for style editing, whereas Scribus expands the Style 
Manager (sigh!). The fact that Scribus also allows for applying a style is, 
unfortunately, no advantage, as it is opaque and clumsy. As already mentioned, 
RagTime lists styles in a resource window, from which they can be accessed. 
LyX works similar to LaTeX, so the word "style" has a semantic definition and 
is dependent (among other things) on a document class -- nothing we could or 
should consider in a genuine DTP program. KWord and OO.o use a dialog that's 
dockable or docked to the right of the application window. This is an 
approach, which is familiar to users of programs like CorelDraw, sK1 or 
(partially) Inkscape, and its biggest advantage, at least in my opinion, that 
styles and other relevant resources or options are readily available without 
interfering with the view of the document, while free floating dialogs always 
hide parts of the layout, so, personally, I think that's the path to follow.

Both KWord and OO.o can also display style hierarchies, and OO.o has even more 
viewing options, although its mix of viewing options and sorting doesn't 
convince me. Both are also lacking a filter that allows to search for styles 
by names.

In general, I consider the OO.o style management to be the sanest (disclaimer: 
I always preferred StarOffice over MS Office even back in the days when it was 
proprietary software because of its transparent and superb style management).

For those who are unfamiliar with the use of styles in OO.o, here's a short 
description: The dockable style manager ("Stylist") consists of 3 parts: an 
icon bar at the top, a list field that lists all available styles and drop-
down list at the bottom that offers sorting/viewing options.

The icon bar is split into 2 parts: five icons for each supported kind of 
style (paragraph, character, frame, page and lists). To the right there are 
two icons for "quick actions": the infamous "bucket" icon that allows for 
quick formatting of text, a feature that regularly drives users of word 
processors mad, and another one that provides a feature, which has been 
(rightfully) asked for by Louis: creating a style from direct formatting. 
While it should be obvious that the details (e.g. the kinds of styles 
available for selection) would have to be different in Scribus, the general 
approach is transparent and clearly arranged.

The same is true for the style list: Double-clicking on a style will apply it. 
A right click on a style offers two or three options, depending on the kind of 
style: Default styles that are part of OO.o can be modified, and it's also 
possible to create a new style based on the default style. Custom styles can 
be deleted (the third option). Again, it's obvious that the concept can't be 
copied 1:1 for Scribus. E.g., there's no reason to have a long list of default 
styles, and the only styles protected from inadvertent deletion should be the 
ones created during document creation. On the other hand, it should be 
possible to easily assign a shortcut, something also requested by Louis 
(assigning keyboard shortcuts should be part of the "management" aspect of 
styles, in my opinion).

As for the sort/view choices, I already mentioned some of its shortcomings 
above. Let me add that many of OO.o's sorting options are probably superfluous 
in a DTP program, as they are based on typical automated word processing 
functions that remove the flexibility required in DTP.

What about editing styles? Now, if the 3 tabs we have in Scribus now are 
considered to be too much, there's even more to hate in OO.o. Here's a list of 
tabs available in OO.o Writer:

1. Paragraph Styles:
- Organizer (style name, next style, parent style, category -- all very 
useful, IMHO)
- Indents and spacing
- Alignment
- Text flow
- Font
- Font effects
- Position (i.e. subscript/superscript settings, rotation, scaling and 
spacing)
- Outline and numbering
- Tabs
- Drop caps
- Background
- Borders
- Condition (options for condtional styles)

2. Character Styles (provides a subset of paragraph styles):
Organizer, Font, Font effects, Position, Background

3. Frame:
- Organizer
- Type (i.e. dimensions, the other settings are or should be irrelevant for a 
DTP program)
- Options (editable: yes/no, printable: yes/no, text direction)
- Flow (i.e. types of text flow around the frame)
- Background
- Borders
- Columns
- Macro

4. Page:
- Organizer
- Page
- Background
- Header
- Footer
- Borders
- Columns
- Footnote

5. Lists:
- Organizer
- Bullets
- Numbering style
- Outline
- Graphics
(the three options listed above are actually three different ways to apply 
different bullet/numbering options)
- Position
- Options

As is obvious, not all of these options are applicable to Scribus. Some have 
been on the wish list for a long time, others may be appropriate in a word 
processor, but should be avoided in a DTP program. There are also other 
desirable options that would be wonderful to have in Scribus, e.g. kerning 
pairs as in XPress or nested styles as in InDesign. What's also obvious (at 
least to me) is that not all options require a separate tab. 

While the number of options and the number of tabs will depend on the features 
available in Scribus, as well as the space required for the design, including 
consideration of Qt limitations or portability across platforms, one thing 
that all dialogs listed above have in common is the "Organizer" tab. Since the 
options in this tab are directly related to style management, it should be 
considered to implement something similar in Scribus.

As for the layout of the style dialogs in OO.o, I think it shouldn't be 
considered an example at all. There are so many tabs that they don't even fit 
into one row and need to be stacked. As a consequence, the order of tabs 
changes depending on the selected tab. This more than confusing. An 
application that probably did it right is InDesign, as it uses a layout 
similar to our current Document Setup/Preferences, i.e. a dialog with two 
distinct parts, namely a column with categories to the left (but implemented 
as buttons, not icons, which saves space) and the content of the selected 
category to the right. This approach would also allow for easy expandibility 
in future versions with new features.

Another shortcoming of the style editing dialogs in OO.o (and other programs) 
is their modality. At least in this regard the current Scribus Style Manager 
is behaving a bit saner.

OK, this has been a rather long posting, but I thought it might be helpful to 
discuss existing implementations, especially since re-inventing the wheel is 
probably unnecessary. 

Perhaps we can start from here and reach a reasonable and flexible solution, 
even if the result will be something completely different. What we need, 
though, is a solution, because the Style Manager has to change, which, I 
think, nobody will dispute.

Cheers,

Christoph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20101111/e272acbd/attachment-0001.htm>