[APBeta] UI for Locating Object could use improvement.

[Paul Rodman]

I don't think I answered this one, so I'll add my comments.

On Jan 4, 2009, at 02:42 PM, Dan Kuchta wrote:

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

(1) is possible to implement, and I might implement it in the future  
as an optional way to change data, but it does require some thought.  
One problem it has is that you might not be able to see all the  
"editable" columns at once, and need to scroll around horizontally to  
find them. I'll add a feature request.

(2) I like, and is relatively easy to implement (i.e. low-hanging  
fruit).  I'll add a feature request.

Note that, since this message was posted, I have de-emphasised the  
current Lookup buttons (they are now smaller "?" buttons). The reason  
for that was to "smarten up" the interface, and also to allow space  
for a new object field (which I haven't yet decided to implement).

Paul R.