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    

[p4-feedback] bug reports and feature requests (1)

Rich Morin rdm at
Tue Apr 28 11:46:04 PDT 2009

At 18:22 +0100 4/28/09, Nick Drummond wrote:
> We haven't had the resources to do a full UI review, so appreciate
> the notes (although I think a lot will be low priority).

I can't argue with your priorities.  The program is quite usable
(eg, coherent, consistent, flexible, powerful), so getting it to
generate a full range of well-constructed ontologies is (IMHO)
the most important challenge.

However, I would submit that P4's UI is its main justification for
existence.  After all, I could perform the same functions with a
set of command-line tools and a text editor, if I wished.  However,
P4's integration makes it more of a specialized IDE than an "editor".

Finally, details matter, particularly when they violate the Principle
of Least Astonishment and/or leave the user feeling annoyed, confused,
trapped, etc.  So, please keep these nits on the list...

> "close" button in views ...
> Cmd-Z is reserved for undo on the model and nothing else.  I think
> anything else would be unintuitive.

Point taken, but a menu item could still take on this role.  BTW,
it's a bit unfortunate that there is a collision between "View" as
a P4-specific UI element and the Apple standard of using a "View"
menu for generic appearance changes to the application.  Sigh.

> Once a view is closed there is no guarantee that the place it would
> go still exists.

What I have in mind is a one-chance opportunity to recall the last
mouse click.  As in "OMG, what did I do and how do I get it back?"
So, just put things back the way they were before th user clicked.

> Why are you closing the view if you want it back?  Is this when
> you've made a mistake?  I don't think this is likely.

People commonly make positional errors when using pick devices (eg,
mice, track pads).  Given the tiny size and close proximity of the
View icons, new users are quite likely to make this error.  And, if
a new user closes a default View, s/he may not remember which one it
was, let alone know how to get it back.  Restoring the entire Tab
seems like a rather onerous remedy for such a minor mousing error.

> "Object property axioms" section ...
> This has been fixed for a few releases

Glad to hear it.  Curious that it isn't fixed in the one I pulled
down fairly recently...

> "Welcome to Protege" dialog: ...
> Did it not exist when you saved it?

I didn't save it, so the list entry should not have appeared.

>  "Create new OWL" uses the same view settings each time; there
>  doesn't appear to be any (reasonable) way to reset them to the
>  "factory defaults".
> The tabs can be reset to default as you said before.  I don't
> understand the problem.  There are no "per project" settings.

I'll try to come up with a clearer scenario.  IIRC, the problem
was that I (a) started an ontology, (b) fiddled with the Views
in some of the Tabs, and (c) killed off the ontology and quit
the program.

When I restarted the program, the Tabs retained my View changes.
My take is that, if the program is going to keep my (implicitly
defined) preferences around, it should do so in a more granular
and controllable manner.

> There are no "per project" settings.

Perhaps there should be. :)

> OWLViz tab
>  ...
>  How do I get OWLViz to try dot(1) again?  (Refresh User Interface
>  should do this, but doesn't.)
> I don't know how it was written, but I guess once you've set the
> path in the prefs it tries again.

This may not be obvious to the user, but if you search the PATH each
time for the dot(1) program, it may become a non-issue...

> Background colors of View headers ...
> OWLViz shows classes and is the class colour.  DL Query arguably
> shows more than classes, but it doesn't offend me that it is class
> colour.

I guessed that the logic went something like that.  The problem is
that a user might try to use the color as a hint for finding the
View in the Menu Bar.  Given that these aren't in the "Class view"
sub-menu, s/he will have to look around until s/he finds them in
the Misc sub-menu.  Basically, it's a violation of consistency.

>  Also, split and floated views do not maintain the same background
>  color as the original view.
> I think this is to show they are not synchronizing with the selection

That's fine, but there are ways to show this without breaking the
visual connection that the background color provides (eg, use some sort
of stipple or hash pattern, as well as a color).

> Refresh User Interface
>  This removes the visible indication of selection from (say) the Data
>  Properties View, but does not actually de-select the View.
> OK. Added to the list (is this a problem?)

My take is that "Refresh User Interface" should restore the UI (insofar
as possible) to an appearance and behavior that reflect the internal
state of the program.  Mostly, it does.

However, the treatment of selected items is inconsistent.  If an item
has been selected, it is used as the subject of (some) neighboring Views.
Currently, although this is still the case after a refresh, the selected
item is not highlighted.  So, the user has no indication of which item
the other Views are showing, etc.

Anyway, thanks for the prompt and detailed response.  Congratulations on
producing a fine program!

--            Rich Morin     rdm at     +1 650-873-7841

Technical editing and writing, programming, and web development

More information about the p4-feedback mailing list