[APBeta] UI for Locating Object could use improvement.

Dan Kuchta dankuchta at gmail.com
Sun Jan 4 14:42:44 PST 2009


This is something that always seemed very unintuitive to me in 1.6.x  
and it still exists in v2 so I thought I'd mention it during this beta  
round.

On the Objects screen, there are buttons for Lookup ID... and Lookup  
Name...   Since they are both under the ID: and Name: fields, it is  
clear that they are associated.  But the behavior between the two  
items (button and field) is different in different situations.  I  
think the problem is that it is used BOTH as a way to change the ID or  
Name of an entry, as well as a starting point for a lookup.  These are  
two very different functions and makes it confusing.

Let me give you a sample work flow.  First, I open a plan with a lot  
of items so that the list is full and requires scrolling.  I'm poking  
around on this list and when I'm done, there is an item selected.  Now  
I want to add the Trapezium to the list.

Ok, I click on the Lookup Name... button hoping to be able to enter a  
name to search for.  But, it takes the name from the already  
highlighted item in the list and uses that for the search. I have no  
way to change it after the button is hit.

So I cancel out of that realizing that the field above the Lookup  
Name... button is what is used for the search.  So I type in  
Trapezium.  Now I can search for Trapezium, but it isn't obvious that  
I also changed the name of whatever was highlighted to Trapezium! Not  
a good thing!

Not one to give up, I go back to the list and try to de-select the  
selected item so the field will be empty, only to find I can't!  I  
scroll to the bottom, but there is no empty space to click on to  
deselect all the items.  I finally succeed by enlarging the window by  
1/2 of the size of a line in the list.  That way when I scroll to the  
bottom, there is 1/2 empty line visible that I can click on to  
deselect everything.  Now I can type trapezium in the field and look  
it up.

There's got to be a better way!  I would suggest one of two things.   
In both cases the goal is to separate the function of searching from  
that of editing fields.

1) One thought would be to allow editing of the fields directly in the  
list.  This would eliminate the need for all those editing fields and  
clean up the interface.  It could follow Apple's interface used when  
selecting and editing file names in the Finder.  The first click on an  
item in the list selects it, and the second enters the editing mode.

2) A second way would be to simply have a separate section on the UI  
for searching.  It could just be a "Lookup Object" button along in the  
same row of buttons as "Search Catalogue" etc.  When you hit this  
button, it would bring up the "Paste or type items/s, separated by new  
lines ..." dialog.  But this dialog would now have a couple of radio  
buttons labelled "Lookup ID" and "Lookup Name".  This moves the  
selection of those two options off the main screen and leaves just the  
"Lookup Object" button. The user would always have to type in the name  
or ID information on this dialog.  You could leave those fields and  
the 2 buttons on the main screen, but they should be completely  
separate from the ID and Name editing fields.

I like option 1 the best because Apple's interface guidelines suggest  
direct manipulation of data as the best route.  However, there may be  
limitations in RealBasic that don't allow that.  In that case, the  
second option would suffice.

-Dan



More information about the APBeta mailing list