User-Friendly Finds

[LaRetta]

Hi everyone!

I'm in a quandary ... ... whether to let Users remain on an existing layout or jump to a Find layout. If they remain on an existing layout, I'll need to deal with issues such as: accidently entering data while in Browse mode, having to change the background color using Status(CurrentMode) or other methods to alert them that they're in Find, dealing with long screen redraws because of multiple portals, etc. OR ... Always switch to a Find layout, possibly as a pop-up window that they can move to view to live data below to assist them in entering the find criteria. And utilize globals.

As I review my options, my primary goal is user-friendliness, which indicates consistency of displays and options. However, I don't want to fall into a trap of RIGID design. At this point, I'm leaning towards a Find pop-up window which takes the User to a found-set list. From there, they select the record. But where do they want to go from there? I almost want a series of buttons on the List itself that a User can select, which will directly take them to the desired layout. Hmmm, those 'buttons' exist on each *regular* layout now! So maybe Finds SHOULD take place on the current layout!?

I know this post is a bit broad but that is exactly the perspective I need. Please share your general *philosophy* on your best user-friendly Find methods and other general words of wisdom or warning. I really need your input on this one as I am now addressing interface interaction issues. Thanks!

LaRetta

[jeffer]

Since our database has a user status (normal text fields) on the upper side of the body part of the layout. So when the user goes to a find layout "manually", the user status fields are empty. So the search must be done on another layout trough a relationship. Never trough the manual search modus.

For instance, i have a vendor field. The user can search on a vendor by clicking on that field. By that action the user is taken to a seperate layout witch explains where the user is gonna search for. It contains only one field. The search results are shown in a portal of a relationship from the searchfield to the relations database. So i have a script thats constantly looping to refresh the relationship. When the user types some letters...the relationship will be updated by the looping script and the find results will be shown in the portal. When the user has found an appriate vendor...he/she clicks on a graphic in the portalline and the vendor will be inserted and the lopping script get's a halt command.

So thats my philosophy of finding. I don't know if this is the most friendly method of finding, but it's working for me and my customers:)

If you would like to see it or if it's not clear...just post here and i'll reply to that post with a downloadable database.

Jeff

[LaRetta]

Hi Jeff!

Oh! I am most certainly interested I would love to see how you've accomplished this, particularly using portals and relationships. And, emm, one of my weaknesses is to get my hands on anything that others have done, and devour it!

Pleeese share an example?

LaRetta

[jeffer]

OK...here is the example! Keep in mind that this is just a very basic sample! To insert data to search on...just open the "data" database from the windows menu and make some new records:)

The sample of John mark Osborne does the same thing but in one database! (thanks lee!)

Jeff

[LaRetta]

Hi Jeff,

I love the simplicy and instant-update capability of this style. I really appreciate you sharing it with us! I assume I could continue to add to this Data:relation for textsearch calc to increase the match (up to 20 characters - 60 if I included spaces)?

And I have a question: I realise you have a relationship established from Search to Data but you have no relationship from Data to Search (but you display a portal in Data based upon Search) It sounds like I've missed a critical understanding about FM relationships

I thought that one had to establish a relationship from the MAIN dB - the dB one is currently *standing in* (Data) to the CHILD dB (Search),but you have no such relationship. Can you straighten out my obvious misunderstanding?

LaRetta

[jeffer]

Hi Laretta,

thnx for the compliment! In fact...i don't have a relationship from data to search. The only relationship is from search (parent) to data (child). The portal you see in the search database are the records from data that are related trough that relationship (search for text::relation for textsearch). A portal in data is not needed since the search action is only performed in the search database. The "one" you see in the data database (if that is what you meen by:[color:"blue"]<"the dB one is currently *standing in* (Data) to the CHILD dB (Search),but you have no such relationship"> ) is just a counter for the total of found records that runs in the search database trough the same relationship:)

I hope that this has cleared in all out...my english isn't that good:(

You could also add an option to break up the text in individual words. It's more work but it works the same. It only needs a third database, what could be a problem for some developers so....again...ask for a database and ill post that one to you:)

Jeff

[Razumovsky]

Hi Laretta,

I go through the same dilema myself. Here are a few basic standards I think about:

I almost never use the same browse layout for finds- this is mostly a function of not allowing the user to access fields in the browse layout. I have seperate buttons for find and edit that move to different "identical" layouts.

For certain find actions that will be performed frequently based on a single criteria (mark order completed by date, for example), I include the find in the script using global and portal and custom layout (type the date at the top and see a portal of all orders from that date showing a few identifying fields and with a "Completed" checkbox that the user can enter).

I make frequent use of "go to related records (show)" scripts on most layouts in most files. I chose a color/texture that is consitient throughout all the files that identifies a field as a "go to" button. So, when a user is looking at an invoice, they can click on the purple embossed (p/e) Order# field and go directly to the order, from there click on the purple embossed customer name field and go to all orders by the customer, click on the p/e product name and go to the product info sheet in inventory database, click on a layout in invoice sheet and view all open invoices that show this product, click on the p/e invoice# and go back to the original invoice, click on the p/e PO# and go to the purchase order for that product for that customer... Since all these relationships already exist, adding the button is no big deal, and severely cuts down on the number of finds a user will need.

I also almost always have a find layout for each file. Most often, I just use a copy of the browse layout with allow access into fields unchecked, and pop up lists. If found set is greater than one, results would be returned in list mode (I actually dont use this last step, but just thought of it and will use it next time ). I use this on the hope that one day, the user will realize how specific they can be in there finds and take full advantage of the multiple criteria they can implement (this may be a bit utopian).

It can take a lot of work to create type ahead scripts and custom global/portal scripts for all fields, and always limits the criteria that can be searched (say you want to find an invoice from january, 2001, that was for a customer in Palo Alto, never completed, sold by salesperson "John"). I am definitely not knocking suggestions like Jeffers- they can be slick, efficent ways of getting the user the info they want in a friendly format. IMHO, they are only worth the trouble for certain fields that would be referenced in a find operation many times a day (like vendor). I always like to include a true find mode layout in each file that has as many fields as possible to leave the user access to this capability.

My $.02

-Raz

[LaRetta]

Hi Raz

I appreciate your suggestions. Our systems are old and funky. I've noticed that finds performed on layouts with multiple portals redraw very slowly which can drive one nuts while attempting to Find. However I end up implementing this process, leaving a User on a layout with multiple portals will be a definite no-no.

I also like the option of giving a User a global in which they can type anything, and then search several *frequently searched* fields. FM is a bit *too* flexible at times (oh, the things we complain about)!

LaRetta