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)

Nick Drummond nick.drummond at cs.manchester.ac.uk
Thu Apr 30 07:48:50 PDT 2009


>> I could perform the same functions with a set of command-line tools and a
text editor, if I wished.

Well, you could, but...

>> a one-chance opportunity to recall the last mouse click

For just handling the views this would not be impossible but I doubt someone
that was this un-familiar with the interface would easily find the "undo"
anyway.
I don't think I can realistically have an undo for the last mouse press.
This is well beyond what most applications would do.
I don't even want to think about how hard this would be. A mouse click can
do an awful lot of things. Many of them pluggable.

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

Build 108 was a while back.

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

Perhaps this is a bug.

>> if the program is going to keep my (implicitly defined) preferences
around, it should do so in a more granular and controllable manner

We would like to have per-project preferences - it is a big thing on the
list - but unfortunately we don't have the resources at the moment to do
this large change (and more importantly get it right).

>> The problem is that a user might try to use the color as a hint for
finding the View in the Menu Bar

OK, if anyone else thinks these two views should be in the View | classes
menu then I'll move them

>> there are ways to show this [floated/split view header colour] without
breaking the visual connection that the background color provides (eg, use
some sort of stipple or hash pattern, as well as a color).

OK, on the list.

> Refresh User Interface

I'm sure this is just a bug in the property hierarchy views

Cheers

Nick


2009/4/28 Rich Morin <rdm at cfcl.com>

> 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!
>
> -r
> --
> http://www.cfcl.com/rdm            Rich Morin
> http://www.cfcl.com/rdm/resume     rdm at cfcl.com
> http://www.cfcl.com/rdm/weblog     +1 650-873-7841
>
> Technical editing and writing, programming, and web development
> _______________________________________________
> p4-feedback mailing list
> p4-feedback at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/p4-feedback/attachments/20090430/9de96d81/attachment.html>


More information about the p4-feedback mailing list