Comparative review of XML editors

On Monday 25 April 2005 12:39, Jeff Martin wrote:
> > > > Mainly because people feel conglomerate is hectic and lost its way.
>
> May this is a good opportunity to re-examine where we are and
> what we'd like to be achieving.

Agreed. +1

> > On many occasions I have recommended the the use of Conglomerate.
>
> I'd say that whilst Conglomerate is aimed at all users, very much
> including the non-technical as these are the people who are currently
> catered for least by most xml editors. I'd say that Conglomerate as it
> stands at the moment is not ready for everyone to use as it is very much
> in development and not everyone appreciates what that means.

Some public relations would be in order. Perhaps explaining this position and 
inviting contribution and particpation, especially from non-developers. I 
think that the project needs to rally wide community support not a select 
profile.


>
> Possibly, might be due to a poor dispspec or maybe it's just a very
> complex and densely tagged document. Not quite sure how to get around
> the problem.

Maybe, but most people were trying to edit Docbook and had no clue about the 
dispspec.

I think the problem is that the text editing interface is cluttered with bling 
and the real-estate of the text editor is consumed with more bling than text. 
This gets in the way of the authors process of writing and reading back. Each 
move of the mouse results in the trigger of some event. Combined this is all 
to distracting. This aid I personally became accustomed to it and learned to 
even block it out of the minds eye. So perhaps what I am saying is that the 
current text editing controls are good for some, but not for the vast 
majority. A simpler, cleaner approach that retains visability into the  
structure would maybe feel less disruptive and intimidating. Most of the 
people I meet want OOo, but going to much in this direction is not good.

> > * its the most stupid app, close and quit both terminate the application
> > when all I wanted to do was close the current document
>
> Actually close only terminates the application when the document you are
> closing is the last one to be open. Maybe it should ask if you want to
> open/create another document or just leave (Though I've never seen
> another app to this.)

Why can't it just close the current document and return to its initial state?

>
> > I don't like the way I have to open dialogs in order to view or edit
> > attributes.
>
> Fair point, attributes should probably be dock-able like tool options in
> the gimp.
>
> Cue bad mock-up
> http://www.custommonkey.org/~jeff/files/Screenshot-1.png

Yes a tabbed properties approach like which is common in an IDE would be 
better. Another approach may be to toggle display of attributes (hide/reveal) 
inline to the editor. When revealed attributes can be added and removed based 
on context menu (right-click activate) or by context menus whose values are 
automatically populated from the attribute list assocated with the current 
element. While this option may serve to aggrevate the real-estate problem, I 
think if the bling can be toggled off, it will be a start.

>
> > * it does not support basic stuff like entities and we use xinclude and
> > xpointer so I can't even read the whole document
>
> Again good point, that I've had problems with myself (Though I've not
> found an editor that actually handles this in a way that I'm happy with
> either)
>
> This should probably be an option to link to or inline the sub document.
> Validation always seem to be a bit tricky with sub documents in most
> editors. You can validate the root doc and sub docs but if you just want
> to edit the sub doc you can't edit a sub doc and validate that with
> reference to the root doc.

This is true when using the entity method of inclusion but not for XInclude. 
providing that there are no external references with the XInclude instance it 
should validate like any other document. However, I think the issue is that 
users want to be able to see the expanded contents of an entity or XInclude 
inline of the including document. This is programatically not a difficult 
task. More difficult would be to enable editing of an expanded inclusion 
without requiring that the user open the source instance being included.

>
> > * validation is bad on complex documents
>
> Validation is a very important/complex part of any xml editor and as yet
> conglomerate hasn't really been ready to tackle it.

Perhaps it should not. Perhaps it should just act as a frontend to xmllint.

> > I can't remember all the comments I have had, but people see the editor
> > as crippled and poorly designed with little functionality or support for
> > basic things. In this view they see it as a poor choice when you have
> > alternatives like XMLmind to use.
>
> I think this is a little harsh. It's just early days for Conglomerate.
> It's nowhere near as stable as it needs to be and functionally it quite
> light but I think the design it good and we're moving the right
> direction albeit very slowly.

Harsh reality. It would be better to focus on functionality and stability 
early and add the power stuff as you go. This way the project can quickly 
gather a following and so the possabilities increase. More eye-balls makes 
for better end results.

<snip what="feelings"/>
Not going to debate it further. I was just my feelings although others have 
agreed.

> Please carry on the comments have valid, and if you stop talking to use
> we'll never get better.

If the team agrees, I will continue documenting the User Interface. I have a 
gnome commit account. My commits will of course be limited to doc/C
which will mean that they will not impact on other parts of the program. I see 
that most of the files we need are already there, so unless screen captures 
changed, the edits will be mostly in conglomerate.xml.


-- 
Sean Wheller
[email protected]
http://www.enbaya.co.za