Re: User impressions and suggestions about Conglomerate (long)

On Wed, 2003-11-05 at 15:49, Roberto Rosselli Del Turco wrote:
> Hi all,
> I finally managed to write down some notes about the current version of 
> Conglomerate. I have been playing with it since the beginning, and I'm 
> really glad that DM picked it up to continue development at such a 
> steady pace. Hope my critics can be of help, apologies in advance if 
> there's something I just didn't get right. Thanks Dave for all the hard 
> work you poured into Conglomerate.

Thanks to everyone who's been helping!

> 
> 
> MIXED PROBLEMS
> 
> - trying to add a span element to another doesn't always work, and 
> sometimes has Conglomerate crashing (quite often, unfortunately);

Please try to isolate a 100% repeatable test case and report it in
Bugzilla.


> 
> CURRENT UI PROBLEMS
> 
> - windows don't remember size and position;

Please elaborate.


> 
> - the triangle is a nice indicator, but eliminating the double click = 
> shade on the element bar is a needless regression: please restore it!

Do other people agree?

> 
> - correspondance between the Overview/Raw XML frames and the main window 
> is very useful, but a) it would be nice to have correspondence when 
> clicking on text in the main frame too (now you have to click on the 
> element bar) b) colour use in unconsistent (black in the main frame, red 
> in the Raw XML one); I experienced a general "quirkiness", i.e. 
> sometimes it works flawlessly, sometimes you need several mouse clicks 
> to have it work;
Please file as enhancement requests/bug reports in Bugzilla.

> 
> - text (line) wrap is not there or doesn't work;

It works most of the time for me.  Again, please isolate a repeatable
test case and file in bugzilla.

> 
> - it's not clear to me if the black rectangle around text is equivalent 
> to selecting all of the text it envelopes: as trying to apply an item 
> from the context menu invariably fails, sometimes crashing conglomerate, 
> I'd say it is not;

It's a placeholder visual "prelight" effect, indicating the XML node
which the mouse is hovering over.   Need a better effect, e.g. a subtle
change of background colour, or perhaps none at all for the textual XML
nodes.

> 
> - the main problem lies in the context menus:

Some of this functionality should be moved/duplicated in a menu.  That
way we'd have keyboard navigability for it, and better discoverability.

> 
>      * they are overcrowded
Perhaps a submenu for the different span tags that can be applied?

>      * they mix completely different commands (the element property 
> window, the classic cut/copy/paste, the element related ones, the input 
> method)
Yes - the input method stuff is a bit of a wart, though it mimics how a
GtkTextEntry works, I think.


>      * they are sometimes confusing, e.g. in some cases you get the same 
> choices for sub-elements or sibling elements
>      * they might be confusing for some users because they change 
> according to what you right click on (this is inevitable, however)

It is a context menu; it changes with context!

> 
> - OTOH, if you want to add an attribute to an element you have to choose 
> the Property item in the context menu, wait for the window to pop up, 
> click on the "DTD" tab then choose the desired attribute.

You can create custom property dialogs for your own document types. 
There was a suggestion a while back of having a floating contextual
property window instead.

> 
> (FUTURE) UI SUGGESTIONS
> 
> To sum up (very quickly!) the different functions, Conglomerate must 
> show (directly or within 1 mouse click distance):
> 
> - the main view of the document currently edited;
> - alternative view of the same:
> 
>      View source (plain text with syntax highlighting)
>      Raw XML (XML structure with text)
>      Overview (overall document structure)
> 
> - standard menu/toolbar commands
> - element related commands (attributes, siblings, subelement)
> - text related commands (add/remove span tags)
> 
> There are two ways to quickly add/modify elements to texts: either you 
> use context menus to offer a context sensitive choice, as Conglomerate 
> has done so far, or you let the user choose from a list, as gedit does 
> with the Taglist plugin. The context sensitive approach has the 
> advantage to let you see only what's appropriate for the current object, 
> the taglist approach allows you to browse among all elements allowed by 
> the DTD (which can be useful as a quick reminder).

So perhaps a floating window that shows available tags, which changes
with context?

Can we have both context menus, and floating palettes of options?

> 
> If Conglomerate will continue using context menus, here are my 
> suggestions to improve the current implementation:
> 
> 1. take cut/copy/paste away from the context menu: they are already 
> available from the Edit menu (add shortcuts) and from the toolbar;

Not sure about this...


> 2. move "Input method" to the Edit menu;

Good idea, I think.

> 
> 3. when you right click on any portion of text inside a text rectangle, 
> all of the text should considered selected: print it in reverse as 
> usual, and a span tag among those available should apply to all of it;

Interesting... What if there is a pre-existing selection within that
text node?

> 
> 4. viceversa, if you select a single word or group of characters, the 
> span tag should be applied only to what you have selected;

Should already be the case.

> 
> 5. now to elements, we can get rid of submenus altogether using the 
> keyboard:
> 
>      * right click: allowed sub-elements list
>      * ALT + right click: allowed siblings list
>      * CTRL + right click: allowed attributes list

I'm not convinced about this.  Are there accessibility implications?

> 
> Other thoughts about the UI:
> 
> 1. the Raw XML view seems kind of pointless to me (IMVHO of course, feel 
> free to disagree :) so I would get rid of it and leave more room to the 
> Overview (especially when resizing windows, should grow proportionally);

It's great for debugging, and, I suspect, for "power users".

> 
> 2. the Overview should be open expanded by default, and there should be 
> a button on the toolbar to quickly expand/collapse it;

Agree about expand by default - what would these toolbar buttons
actually do, though?  Operate on the current selection I suppose?

> 
> 3. it should also be easy to hide completely the sidebar containing the 
> Overview (main menu: View -> Sidepane);

Agreed (though we don't have a View menu yet; so exact UI to be decided)

> 
> 4. in future version, the sidepane could host other useful features, 
> such as a spell checker, an error log, a tag list view, a unicode 
> character selection, etc.

I'd add a Bookmarks view to the list.

> 
> MIXED SUGGESTIONS
> 
> - why a non-editable "View source" option? while it certainly is useful, 
> it would be nice to have an editable window using gtksourceview; as an 
> alternative, an "Edit source" option where you use the GNOME default 
> editor to edit raw XML;

Because it's really difficult! :-)

If anyone can see a good, integrated way of doing source editing, please
let us know.  The code is designed to work on the XML tree, rather than
on the raw character stream - a completely different level of
abstraction.  

We could perhaps figure out a correspondence between positions in the
XML stream and nodes in the tree.  I'm not sure how to do this yet -
probably some kind of two-way mapping that gets generated as a
by-product of the Source View refresh, perhaps giving byte offset into
the XML stream for the start of the start tag for the element, with some
kind of mapping structure going the other way???

This would allow us to indicate selection status and the cursor position
in the source view, which would be nice, and not too much extra work
assuming the infrastructure described above was in place (a big
assumption).

It would also allow us to do editing of TEXT and COMMENT nodes, though
that would be slightly harder - we need to enforce well-formedness.

We could even allow clicking on tags, and have the elements be selected,
cursor click/drag, with appropriate UI behaviour.

But beyond that there are big issues of well-formedness - Conglomerate
requires that the document is "well-formed", and we can't break that
assumption without a big rewrite.

I have considered supporting non-wellformed documents - it helps in the
case where you're trying to load a dodgy document - currently we just
reject it, with parser errors in a "Details" dialog.  See bug #121971. 
Not before 1.0.0

I don't like the "edit in another application" proposal - you get into
situations where multiple applications have copies open of a file,
potentially with different modifications, and the whole thing is only
understandable by experienced computer users.

> 
> - is it possible to have a dispspec file automatically created from a 
> DTD? tell me before I start working to a TEI dispspec ;)

Yes.   Either select File->Import and open your DTD file, or try loading
an instance document that contains a DTD.  See the FAQ (not yet on the
website, see the CVS version) for more information.

BTW the dispspec format is probably going to change somewhat in
incompatible ways over the next month (i.e. before we do a stable
release), but it shouldn't be too hard to migrate the files.

Many thanks for taking the time to put this list together; it's really
nice to get some feedback, especially as I'm so close to the code it's
sometimes hard to see things from a user's point of view.

There are a number of suggestions above that wouldn't be hard to
fix/implement for people who know GTK - please file Bugzilla reports. 
I'm trying to focus on the difficult stuff that needs fixing for a
stable release at the moment - so hopefully other hackers on the mailing
list can have a go at fixing some of this nice visual stuff?


> 
> 
> Ciao
-- 
David Malcolm
www.conglomerate.org