I would like to clarify the context these actions appear in oXygen 9.
We added a notion of *document type* that is associated with a document
based on a set of rules (root element name, namespace, file name, etc.).
For a document type it is possible to define
- a default schema
- default CSS stylesheets
- transformation scenarios
- document templates
- XML Catalogs
and also some custom contributions to the GUI when the user is in Author
mode.
These document types are fully configurable but we ship some defaults
and these defaults include DocBook.
These custom actions include table creation and editing actions (both
the CALS and HTML models are supported) like
- new table
- add column
- add row
- add cell
- join cells
- split cells
The custom actions include also support for lists allowing the insertion of
- ordered lists
- itemized lists
- variable lists
- list items
Then there are actions for inserting
- sections
- paragraphs
- graphics
In addition to these we added also the 3 actions for inserting emphasis.
Note that this represents just a default configuration of the DocBook
document type. One can create another customization with a totally
different set of custom actions, or no actions at all and share that
with his group of users.
All these custom actions are just making some processings easier but
oXygen 9 allows you to edit the file very easily without them - you just
need to hit Enter and you get the list of possible elements in that
context, we offer also something like the palette you mentioned with
possible elements in the Elements view. More, at any moment you can
switch back and forth between the text mode and author mode and the
location is synchronized so you can switch to a different mode and
continue editing.
These custom actions do not take anything from the generic editing power
of oXygen when it is in author mode, they are just shortcuts to insert
some markup in the document. If one uses very frequently question and
answers for instance then he may very well define some fragments and
assign them to custom actions so he can improve his productivity,
especially as you can assign also shortcuts to these custom actions so
you can invoke them more rapidly and without the need to use the mouse.
Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina - http://aboutxml.blogspot.com/
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
Elliotte Harold wrote:
George Cristian Bina wrote:
Dear Eliotte,
Thank you for your remark.
The Bold, Italic and Underline actions are part of the customization
we defined as default for DocBook and they were added like that
considering that people are very familiar with the *B*, /I/ and _U_
type of icons and they were added as shortcuts to insert different
emphasis levels.
I understand your point and we should correct the name and description
tool tips for these actions (they read now Bold, Italic and Underline)
to clearly specify that they insert emphasis.
Changing the visual representation of bold, italic, and underline isn't
the point. There shouldn't be any visual or other representations of
these actions when editing a semantic document. These shouldn't be such
actions in the first place. Users should be offered semantic actions.
Presentational actions would be appropriate only if they're editing a
stylesheet.
I also question whether there should be icons at all. There’s a common
but mistaken belief that proper user interface design requires lots of
pictures and icons. In fact, it doesn’t. Many concepts and actions can
be fully and best conveyed by text. While standard icons for directories
and disks and the like can be helpful, custom icons for an application’s
unique actions rarely are. The fact is, most icons are not
self-explanatory; and if they’re not common enough to be standardized,
they’re not common enough to be learned easily.
Nonetheless, many applications persist in creating pointless,
incomprehensible toolbars. Icon design is hard. It is not something that
just any art school graduate with mad Photoshop skills can accomplish.
Icon design is about conveying an idea with pictures. not merely making
a 32×32 bitmap look pretty. It’s hard enough coming up with a good icon
for basic actions like cut and paste. Now try imagining one for “Analyze
Module Dependencies” or “View Breakpoints”. There’s a reason Susan Kare
gets the big bucks.
You might be able to come up with good visual for foreignterm,
wordasword, variable, and so forth. However I suspect they'd be mostly
text anyway. I suspect the best interface here would not be a toolbar
with icons at all, but something more like BBEdit's HTML palette.
Sometimes the best representation of an action is a word.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
