Re: DOMContentReady and focus() in Opera

Conrad Lender wrote:
On 19/05/09 00:46, Garrett Smith wrote:
Conrad Lender wrote:
Honestly, I don't see anything wrong with it in our case - at all. 98%
of this application is about data entry and management, and the most
important (= most frequently used) fields are right at the top of the
form. Why would it be preferable to force everybody to manually focus a
field before they can begin entering data?
Without being able to use your application, I might speculate that the user had submitted the form but failed to fill the second and third fields out properly. The page is presented again and the user is be asked to fix the second and third fields. Drawing focus to the first field would throw the user off.

That's a good point, and we actually do focus the fields that need to be
fixed in such a case. I left that out of my original description to keep
things simple.

The user might have decided to start typing in a different field first.



I see what you mean. On PubMed, they always focus the global search
field, which is definitely not a good idea. And they seem to do this
onload, over the net, on a site with a lot of graphics and scripts. I
can assure you that we're not doing anything like that.

Using NoScript, the links to search results beyond the first page don't work. I can't think of a good reason that search results cannot work with javascript disabled. Seems like an obvious program design error.


Keyboard navigation is simply easier and more intuitive for some users. Particularly when the "mouse" is a trackpad. Or worse.

I agree. I would probably have been the first to notice that, but it
just doesn't apply to our situation. When somebody goes to the "look up
invoice" form, they want to type in an invoice number; there's nothing
else to scroll down to.

I thought you said it was a login page. I read:
| I've got a login page for a private area on a webserver, with nothing
| but [user] and [password] input fields on it.

But then earlier you wrote:-
| and the most important (= most frequently used) fields are right at
| the top of the form.

Which would seem to imply at least three fields, with at least two of those being "most important" of the set of fields (and that set presumably containing other elements below) those "most important" ones at the top.

So the page has a few fields, and now we know one of those is an invoice. I guess your login page was just a straw man, then. Am I right?

If the browser's viewport is not large enough to accommodate the vertical size of the page, the viewport should be scrollable. The user could be on a smaller device, or have a smaller-sized window, for multitasking/switching between windows and applications.

Garrett
.

Relevant Pages

  • RE: Automate a default value
    ... First thing this morning I created a combo box on the AV invoice ... Data entry form and that was a good solution. ... Control source Recap Date ... > called RecapDate. ...
    (microsoft.public.access.forms)
  • Re: Sub form not displaying as continuous
    ... "John Vinson" wrote: ... >>and data entry = False and no difference at all. ... >>Invoice number does this ... > as the Master Link Field and Child Link Field of the Subform control ...
    (microsoft.public.access.formscoding)
  • RE: Table Design
    ... this database is created on the fly. ... in and receives an invoice preprinted by head office. ... The data entry operator enters Inv number, ... > form enter the transaction data or have a sub form tied to the transaction ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Sub form not displaying as continuous
    ... >and data entry = False and no difference at all. ... >looked at the tables and noticed that the Ordersub was not keyed on ... >Invoice number does this ... as the Master Link Field and Child Link Field of the Subform control ...
    (microsoft.public.access.formscoding)