Re: [docbook-apps] oXygen 9 beta with WYSIWYG-like editing supportfor DocBook

[George Cristian Bina <george@oxygenxml.com>]

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.
>