Re: User impressions and suggestions about Conglomerate (long)

Dave Malcolm wrote:
> On Wed, 2003-11-05 at 15:49, Roberto Rosselli Del Turco wrote:

[...]

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

I will try, but it seems to be a very unpredictable behaviour. BTW, I'm 
running Conglomerate 0.7.6 on a Mandrake Linux 9.2 box.

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

Well, not much to elaborate :) when you start C. the main window is 
quite small, it would be nice if it remembered the size and position of 
the last window you close.

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

I will add that this behaviour comes most natural (to me at least) 
because it's like double clicking on a window bar to the same effect. 
The triangle, OTOH, is quite small a target in comparison.

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

Will do ASAP.

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

Hmm, this one's difficult too, because I only saw text wrap in when 
case, so it could be very difficult to pinpoint a specific case.

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

It would be nice to have a clear visual difference between 1. text 
areas, where you can click and type text, and 2. element areas, where 
you can add/modify/delete elements. You could use different backgrounds 
colours, and/or different mouse cursors.

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

AFAIK, the HIG recommends to have very short context menus, ideally with 
no sub-menus (don't trust my word for it ;) and that was the goal of my 
proposal.

>>     * 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!

I realize this, as I hinted above, but I quoted it nonetheless as one 
more reason to try and keep them as simple as possible.

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

My wish was to have attribute editing on the same level than element and 
text (via context menus), see below.

>>(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?

Best of both worlds, I'd say (but I'm sure the usability people would 
regard this as crack ;) Anyway I like the idea, you could turn the 
floating windows on and off via the (forthcoming) View menu. And thanks 
to the context sensitive menus you would know what changes are allowed 
in position X, reducing the possibility of making mistakes.

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

Two ways to do something is perhaps good, I would frown on three, but 
four (keyboard shortcuts, Edit menu, toolbar buttons and context menus) 
is definitely overkill IMO :)

[...]

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

Hmm, we have to think carefully about this one. At the moment it's a bit 
confusing that you don't know exactly what the tags are going to be 
applied on if you don't right click on selected text.

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

It is, just quoting as the opposite case of 3.

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

We can ask on the usability list about this (and other) issue. Other ideas:

* right click: allowed sub-elements list
* ALT + right click: allowed siblings list
* middle click: allowed attributes list

or we could add little widgets on the Element title bar activating pull 
down lists with all of the above;

or we could add standard gtk pull down lists to the toolbar.

In any case, nothing beats context menus when it comes to speed of 
activation.

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

But, as it is a sort of a cross between source text view and structured 
view (Overview), is it really necessary? Won't argue about that, 
however, if you say it's useful it is ;)

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

Nope, I meant expand/collapse the whole view and other structured views 
as well (RawXML); you already have the triangle widgets to operate on 
part of the structure.

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

But you plan to add one, right? It's a standard menu item.

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

You might do without that as soon as the standard file selector reaches 
decency ;))))

>>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! :-)

Alas, I really can't help you with that :(

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

I understand your point, anyway I think that Conglomerate is/ really of 
use to experienced 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.

Unfortunately the TEI dtd is composed of lots of different files: I 
tried to import the main one (tei2.dtd) then some of the others, but 
nothing happened (literally).

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

You're welcom. You might want to think about future directions for 
Conglomerate's UI, then ask for advice on the usability list: many other 
developers have done this receiving good advice.

I've just downloaded some other XML editors and, if I perchance find the 
time, will have a look at their GUIs then come back with some other idea.

Ciao

-- 
Roberto Rosselli Del Turco      roberto.rossellidelturco at cisi.unito.it
Dipartimento di Scienze		rosselli at ling.unipi.it
del Linguaggio			Then spoke the thunder	DA
Universita' di Torino		Datta: what have we given?  (TSE)

   Hige sceal the heardra,     heorte the cenre,
   mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)