oXygen 9 beta with WYSIWYG-like editing support for DocBook

Hi,

Help us testing the new tagless editing support in oXygen
9!
The support for DocBook is, as usual, ready to use.
Everything you need 
to get started is here (no registration required):
http://ww
w.oxygenxml.com/download-beta.html

Here you have some useful information:
* click on the Author tab in the editor to switch to
WYSIWYG-like mode
* use the arrows, mouse and tab/shift+tab to position in the
document 
(notice the location tooltip that shows you in an intuitive
way the 
location in the structure, the outliner that shows the whole
tree and 
the location toolbar that shows the current path in the
document).
* type to add content
* press Enter to add markup through a content completion
like popup, 
then you can type to select proposals or use the arrows or
the mouse
* the position in the Text and Author modes is synchronized
so you can 
change between them when editing and continue to work in the
same 
location in the document

The WYSIWYG-like mode supports also customization and oXygen
ships a 
default customizations for DocBook 4 and DocBook 5. These
customizations 
include:

- Bold, Italic, Underline actions (insert emphasis with
different role 
attributes)
- Insert sections, paragraphs, images
- Insert list items and lists
- Insert tables, rows, columns, cells (both CALLS and HTML
table models 
are supported)
- Table management actions for joining and splitting cells

Version 9 works side by side with previous versions of
oXygen. The 
tagless editing functionality will be available also in the
Eclipse 
plugin and we plan to have available a beta for that in a
few days.

Best Regards,
George
------------------------------------------------------------
---------
George Cristian Bina - http://aboutxml.blogspo
t.com/
<oXygen/> XML Editor, Schema Editor and XSLT
Editor/Debugger
http://www.oxygenxml.com


------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

George Cristian Bina wrote:

> - Bold, Italic, Underline actions (insert emphasis with
different role 
> attributes)


I'm sorry. This is just wrong. We may want a WYSIWYG
display, but we 
don't want a WYSIWYG interface.  Moving away from WYSIWYG
interfaces is 
what SGML, XML, and markup have always been about.

The interface should allow us to choose emphasis, strong
emphasis, 
wordasword, foreignterm, variable, etc. It should not
present us with 
options for Bold, Italic, and Underline.

What is shown on the screen need not be tags. Indeed it's
quite useful 
if they're not. The document can be rendered in bold,
italic, or 
whatever style is appropriate. That's fine. However, the
user should be 
asked to specify what they mean, not what they want
something to look 
like. Otherwise you might as well be using Word.


-- 
Elliotte Rusty Harold  elharometalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.c
afeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0
596527500/ref=nosim/cafeaulaitA/

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

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.

I agree that we should add actions to insert elements as you
suggested 
with appropriate icons in the version 9 release so
suggestions on the 
elements that should be provided by default in the oXygen 9
support for 
DocBook and possible actions are more than welcome.

The whole customization support is configurable and one can
define or 
remove actions as one likes - but yes, the default that we
provide 
should be more focused on the semantics of the language as
most people 
will use that.

Thanks again for your useful feedback!

Best Regards,
George
------------------------------------------------------------
---------
George Cristian Bina - http://aboutxml.blogspo
t.com/
<oXygen/> XML Editor, Schema Editor and XSLT
Editor/Debugger
http://www.oxygenxml.com



Elliotte Harold wrote:
> George Cristian Bina wrote:
> 
>> - Bold, Italic, Underline actions (insert emphasis
with different role 
>> attributes)
> 
> 
> I'm sorry. This is just wrong. We may want a WYSIWYG
display, but we 
> don't want a WYSIWYG interface.  Moving away from
WYSIWYG interfaces is 
> what SGML, XML, and markup have always been about.
> 
> The interface should allow us to choose emphasis,
strong emphasis, 
> wordasword, foreignterm, variable, etc. It should not
present us with 
> options for Bold, Italic, and Underline.
> 
> What is shown on the screen need not be tags. Indeed
it's quite useful 
> if they're not. The document can be rendered in bold,
italic, or 
> whatever style is appropriate. That's fine. However,
the user should be 
> asked to specify what they mean, not what they want
something to look 
> like. Otherwise you might as well be using Word.
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

Elliotte Harold <elharometalab.unc.edu>,
2007-10-02 06:13 -0400:

> George Cristian Bina wrote:
>
>> - Bold, Italic, Underline actions (insert emphasis
with different role 
>> attributes)
>
> I'm sorry. This is just wrong. We may want a WYSIWYG
display, but we don't 
> want a WYSIWYG interface.  Moving away from WYSIWYG
interfaces is what 
> SGML, XML, and markup have always been about.
>
> The interface should allow us to choose emphasis,
strong emphasis, 
> wordasword, foreignterm, variable, etc. It should not
present us with 
> options for Bold, Italic, and Underline.

I'm sorry, but I don't see any real-world difference
between
"emphasis" and italics, nor "strong
emphasis" and bold. In
practice, they amount to the same thing, and pretending
that
they're not doesn't really help anybody. But what might help
a
little at least is giving people familiar "make this
italic" and
"make this bold" functions/buttons in a UI --
since that maps to
what they are likely already familiar with -- instead of
trying
to, um, educate them that they need to choose
"emphasis" when what
they really want is italics and "strong emphasis"
when what they
want it bold.

I agree about the need to provide UI features to choose
variable,
etc. But that need is separate to how to handle the cases
where a
user really does just want to do simple bolding and
italicizing of
text. 

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

http://sideshowbarker.net/

Michael(tm) Smith wrote:
> I'm sorry, but I don't see any real-world difference
between
> "emphasis" and italics, nor "strong
emphasis" and bold. In
> practice, they amount to the same thing, and pretending
that
> they're not doesn't really help anybody. But what might
help a
>   
Come on, Michael. How can you say this? italics and bold are
two 
possible renderings for some internal meaning. In markup you
should mark 
your intended meaning, and then later you will decide the
better way to 
render this meaning. To say that italics=emphasis is wrong.
Because 
italics=(emphasis,foreign word,quotation,etc.) There are too
few 
rendering options for a huge number of intended meanings. If
we end up 
with only italics and bold, we can only distinguish two.
Come on, we are 
in structural markup. Bold and italics will NEVER be
structural.

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

Michael(tm) Smith wrote:

> I agree about the need to provide UI features to choose
variable,
> etc. But that need is separate to how to handle the
cases where a
> user really does just want to do simple bolding and
italicizing of
> text. 

I won't argue the point about emphasis vs. strong emphasis.
That's 
mostly historical. We could always have something like
<emphasis 
strength="5"> if we really wanted.

However I do think that if the user just wants to do simple
bolding and 
italicizing of text, then they just want to do
presentation-based, 
non-semantic markup. And indeed they probably do want that,
and that's 
OK. But if so they should be using Word, not DocBook.

-- 
Elliotte Rusty Harold  elharometalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.c
afeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0
596527500/ref=nosim/cafeaulaitA/

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

Javi wrote:
> Michael(tm) Smith wrote:
>> I'm sorry, but I don't see any real-world
difference between
>> "emphasis" and italics, nor "strong
emphasis" and bold. In
>> practice, they amount to the same thing, and
pretending that
>> they're not doesn't really help anybody. But what
might help a
>>   
> Come on, Michael. How can you say this? italics and
bold are two 
> possible renderings for some internal meaning. In
markup you should mark 
> your intended meaning, and then later you will decide
the better way to 
> render this meaning. 

For users used to M$ Word it is quite a transition.
'Leading' them 
gently  from bold and underline and italic to semantic
markup should be 
made as easy as possible, even if it upsets the hard line
semantic folks.


regards


-- 
Dave Pawson
XSLT, XSL-FO and Docbook FAQ
http://www.dpawson.co.uk



------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

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.

-- 
Elliotte Rusty Harold  elharometalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.c
afeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0
596527500/ref=nosim/cafeaulaitA/

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

Dave wrote:
> For users used to M$ Word it is quite a transition.
'Leading' them 
> gently  from bold and underline and italic to semantic
markup should 
> be made as easy as possible, even if it upsets the hard
line semantic 
> folks.
Elliotte wrote:
> However I do think that if the user just wants to do
simple bolding 
> and italicizing of text, then they just want to do
presentation-based, 
> non-semantic markup. And indeed they probably do want
that, and that's 
> OK. But if so they should be using Word, not DocBook.
I must totally agree with Elliotte. I do usually agree with
Dave in most 
of his ideas, but not in this one. If someone wants to write
a 
presentation-based document, DocBook is not a good
selection. There are 
much better things for this (quark, pagemaker, even word or
openoffice). 
There doesn't exist the right thing for everyone, the
program everyone 
will use.

I think, Dave, the idea is a change or perspective. You say,
to make a 
gentle transition from Word to DocBook, let's make the
markup less 
semantic so we come closer to Word.

Let me give you another perspective. If someone is using
Word and he 
thinks about using some other tool, it's because Word
doesn't give him 
what he wants. If he chooses DocBook it will be due to it's
semantic 
markup and the separation between presentation and
structure. You can't 
then offer him a tool with the same options as his old one.

I accept that oXygen people have a challenge, how to make
this 
transition a gentle experience. But I don't think the way is
to diminish 
the power of the tool and of the underlying model. Novel
ideas and 
imagination will win in this task, don't get always the
effortless way.

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org

Elliotte Harold <elharometalab.unc.edu>,
2007-10-03 04:25 -0400:

> However I do think that if the user just wants to do
simple bolding and 
> italicizing of text, then they just want to do
presentation-based, 
> non-semantic markup. And indeed they probably do want
that, and that's OK. 
> But if so they should be using Word, not DocBook.

I won't disagree with you about that. I think there are
plenty of
cases of users who think they want to author in DocBook but
who
might be better off using something else.

But for better or worse there does seem to be market demand
for
WYSIWYG DocBook editing, so it's hard for me to find fault
with
the vendor of what is a very good structural editor for XML
and
DocBook wanting to add WYSIWYG capabilities to try to
respond to
that market need. And I can imagine a scenario of a
representative
from oXygen going in to do a product demo of that editor
and
having one of the first questions from the customer be, How
do I
make things bold and italic?

Given that, I'm not surprised at all they they chose to
avoid the
need to explain, "Well, in DocBook the markup element
that causes
text to be rendered in italic -- across all output formats
supported by the DocBook XSL stylesheets and all other
common
DocBook processing applications is called emphasis, and the
one
for causing text to be rendered in bold is also emphasis --
with
(the hack of using) the 'role' attribute having its value
set to
'bold'." 

If somebody wants to argue that a UI should not include
features/
buttons for italic/emphasis or bold/strong-emphasis at all,
then
that would seem to me to make a lot more sense. But emphasis
in
DocBook amounts to meaning "markup for any content that
you want
to be output in italic but which does not have any other
semantics
associated with it", so it might just as well been
called italic
to begin with.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

http://sideshowbarker.net/