Opinions: Select All on Entry to Field?

[kennedy]

Right Brain doesn't seem to be getting as much traffic after the forum re-org... but here's another query...

What have you all found more effective for your users:

To have fields to select all the contents on entry, or just put the cursor at the end?

Do you tend to go with one way or the other for a whole layout? or app?

Or do you tend to make different choices based on the contents of the field?

For example, a Y/N Boolean field should always select all on entry... there's never a time when you want to just add to the end of it... you either replace the whole or leave it alone.

For notes fields, or other long, accumulating text fields, its definitely best to just put the cursor at the end. In fact, its very annoying for it to select all... you almost never want to delete the stuff that's there.

I am tempted to select all on entry in most cases, as it seems more common to want to replace than append... but it is also the more dangerous choice... an accidental keystroke deletes all the contents, whereas it simply adds an ugly appendage to the proper data in the alternative.

Thus, with my concern about bad data, I've chosen to NOT select all on entry in almost all cases.

Opinions?

[LaRetta]

It's me again Brian! I know little about scripts and formulas but I certainly know data entry. I agree with you. It's best usually to select the whole field unless it's a note. Then I plan on implementing Ray's Multiple Undo and/or Rolling Log. Even if you shut the computer down, you can go backwards (I think) like 10 times) on the Undo. I want that feature as a button right there for users and I will make them aware of it. Even if you're REALLY good at keyboarding, you can accidently delete something. Every db should have undo.

Thanks for bringing up these issues -- it's the unasked questions that make us lazy in design. I hope more people give their input -- most have much more valuable input than mine!

[jeffer]

The part where this gets annoying is that filemaker auto saves every change in the database after exiting a field and do something else. In that case you can't undo annymore:(

thus: I mostly turn the option off with fields that have critical data in them. For the not-critical field i leave the option on!

jeff

[LaRetta]

Hi Jeffer!

That's why, IMHO, CobaltSky's Undo (or a similar procedure) is so vital to implement. The option to 'go backward' is vital in FM because it IS so fast at saving everything you do -- whether you want it to, or not!!

[kenneth2k1]

When I first started, i didn't have it select all upon entry. Then I found it to be useful on certain things. Then I found myself using it on almost every field. If I want to go to the end, I usually just hit the End key. I wouldn't say that I implement it on a app-wide scale, though. Only in the fields I deem necessary.

Ken

[falkaholic]

My $0.02

I have Select All off for everything I've done so far. There's not alot of reasons for me to use them. The only time I might user them is for say, filling a date range for a report. Most of the time the prevoius entry isn't needed and a completly new date is going to be put in.

Since 99% of them time a user enters a field, it is to fill in, or to change a small part of it, I'd never use it on "normal" fields.

[harryk]

Point your end users always on the UNDO-function in the edit-menu, and there is also a Revert Record option in FM which works if a record is not 'committed' yet. Unfortunaly FM commits very fast..

Harryk

[CobaltSky]

Like Kenneth2k1, when I'm using a database myself, I tend to prefer it if 'select all' is turned on for most fields - expept where appeanding to the field is a more common part of the workflow that replacing it with a new value (and in most applications replacement is more usual, I find).

I agree that there are some situations (or, more to the point some users) where the risk of data loss is increased when select contents is turned on.

However one other consideration which has a bearing on the decision relates to scripting. A large number of script steps which involve entering or acting upon a field have the option to select the field contents or not. It is important to know that the field setting for select-on-entry for the current layout over-rides the script settings, so that if you turn 'select contents' on, your scripts can no longer append to the field.

This latter issue is a blockbuster in certain situations - contrary to expectations, changing the 'select contents on entry' for a field on a layout (in either direction) can cause certain script steps to no longer produce the expected outcome(s). This is one to keep in mind when you're tweaking an established solution (ie one where you may not be sure what scripts may be acting in what ways on the field you're changing).

[kennedy]

Hmmm... that flag is just two-state, true or false... there is no "empty" state. If you set it and then want it unset, do you delete the field and create a new one???

In my case, I have no scripts that append to field... and very few that even touch the layout fields... most use SetField.

Thus, it seems the recommendation is to go ahead and use Select all contents on entry for most fields.

Thanks.

[CobaltSky]

Hi Brian,

The situation is not as bad as I may have made it sound.

If you leave 'Select entire contents of field on entry' off, then the script settings are applied, and you can use the script step parameters to append or replace according to whether the 'select' option is enabled.

It is only if the field format settings for the current layout have 'Select contents on entry' turned on that the script parameter is over-ridden (and even if you have it off in the script, expecting it to append, it will nevertheless replace).

You can work around this so long as you are aware of it. It is a bit surprising, though, since the other 'sister setting' for 'Allow entry into field' is typically over-ridden by script steps - so FMI seem to have used opposite paradigms for the two settings. Wierd.

But as you say, these issues aside, I lean towards turning "Select entire..." on for fields/solutions where replace is the usual mode of editing. This makes a database more friendly. Concerns about user behavior leading to data loss can generally be better addressed 'positively' in other ways using validations, logs and undo options - rather than 'negatively' by making the user jump over extra hoops and hurdles to do basic everyday things.

[jasonwood]

I find it most critical to use the "select all contents" on line items on invoices/quotes/etc, because these are areas where you often want to enter data rapidly (eg: changing quantity from default 1 to something else, or changing sell price from regular price to something else.

Otherwise I could go either way, but definately not in description fields where most of the time you just want to change a few words.

--

Jason Wood

HeyWoody.com