Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] Some suggestions on the Protege editor

Timothy Redmond tredmond at stanford.edu
Thu Oct 22 11:54:28 PDT 2009


You have made a good case for some Protege 4 feature requests.  From a  
developer perspective, several of them are awkward but as a user I  
have experienced some of the same issues.  I will put the first and  
third in gforge.  The second item is still a bit problematic.

> Please consider opening the bug tracker!

We have discussed this on several occasions but there is a real  
concern that the signal to noise ratio would be very bad.  Even this  
feature request - which is very thoughtfully written - is missing a  
key piece of data (Protege 3 or Protege 4) which translates into which  
bug tracker to use.

> 1) The keyboard short-cut scheme for editing ontology could be
> simplified. Like to insert new child node, Insert button could be
> used, to insert new sibling node - Enter keyboard button could be
> used. Delete button to delete a node is a pretty standard thing.
> Shift+Del could remove all instances and Del just the specific one.
> Good examples on efficient keyboard shortcuts can be found in
> Freemind[1] - the mind mapping application.

I like this one and it will be the easiest to investigate and  
implement.  It would be nice if a large percentage of ontology editing  
could be done from the keyboard.

> 2) The modal dialog that appears when selecting "Open.." from menu is
> not necessary. Decision of either your application has multiple
> document interface or single document interface should be made by the
> developers and enforced.

This is not clear in the case of Protege 4.  There is a meaning  
associated with with having multiple documents in the same window.  
Edits in one document can be immediately reflected in other  
documents.  Alternatively sometimes multiple windows are needed for  
example to look at  ontologies with the same name.

> For some info on that see Gnome HIG[2]
> (referencing the gnome hig, just because it is free and easy to read).
> Right now the user is forced to make a decision whose impact is almost
> none. Also, modal dialogs tend to condition the user, especially if
> they are using the passive Yes/No/Cancel trio and that leads to
> dialogs being ignored. For more of that, please see [3]

I agree - this dialog is a pain.  But I am not sure what to do about  
it.  Unfortunately it does serve a very important purpose because for  
Protege 4 opening in the same window is very different from opening in  
a different window.  This dialog is intended to have opening in the  
same window as the default.   There was some discussion about this on  
the protege 4 discussion group some time back before it was first  
introduced.

> 3) Edit -> Create new... triggers display of a modal dialog with
> single input box. Nowadays it is pretty common to perform such
> operations in-line, as it allows the user to stay in context of the
> previously selected node.


We create new items the way that you suggest for Protege 3.   From the  
developer  perspective, the problem with removing this dialog is that  
the new item is not "real" in some sense until it has a name.   
Conceivably we could do what Protege 3 does which is to choose a name  
when the item is created and then refactor the ontology when and if  
the user changes the name.   There is some magic done in Protege 3 to  
arrange that the right text is selected so the user can easily set the  
name.

-Timothy



On Oct 16, 2009, at 4:35 AM, Toms wrote:

> Hi all!
>
> First i'm wondering why are you so restrictive in bugzilla - having to
> subscribe to a mailing list and then put the suggestions under
> discussion is more commitment than is really needed.
> Would it be possible to configure the bug tracker so that registered
> users could enter new bugs? Or are you afraid that that will result in
> tons of bug reports flowing in?
> Please consider opening the bug tracker!
>
> I have a few suggestions that could be quite easy to implement and
> make the ontology edition process much faster:
>
> 1) The keyboard short-cut scheme for editing ontology could be
> simplified. Like to insert new child node, Insert button could be
> used, to insert new sibling node - Enter keyboard button could be
> used. Delete button to delete a node is a pretty standard thing.
> Shift+Del could remove all instances and Del just the specific one.
> Good examples on efficient keyboard shortcuts can be found in
> Freemind[1] - the mind mapping application.
>
> 2) The modal dialog that appears when selecting "Open.." from menu is
> not necessary. Decision of either your application has multiple
> document interface or single document interface should be made by the
> developers and enforced. For some info on that see Gnome HIG[2]
> (referencing the gnome hig, just because it is free and easy to read).
> Right now the user is forced to make a decision whose impact is almost
> none. Also, modal dialogs tend to condition the user, especially if
> they are using the passive Yes/No/Cancel trio and that leads to
> dialogs being ignored. For more of that, please see [3]
>
> 3) Edit -> Create new... triggers display of a modal dialog with
> single input box. Nowadays it is pretty common to perform such
> operations in-line, as it allows the user to stay in context of the
> previously selected node.
>
>
>
> 1 - http://freemind.sourceforge.net/
> 2 - http://library.gnome.org/devel/hig-book/stable/windows-primary.html.en
> 3 - http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en
>
>
>
> Regards,
> Toms
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03




More information about the protege-discussion mailing list