Re: Avoid 'GET' method

>> >First, always use the POST method to update the database.
>> It would be nice if that were practical.
>
>Tell me why it is NOT practical?

(a) too many forms slow browser to a crawl and/or run it out of memory.
(b) the amount of HTML required has a noticible effect on load time.

>>>Second, do not put a separate set of buttons against each entry, use a
>>>single set for the whole page.
>>
>> This is WAY too clumsy a user interface for what I want.
>> Do you have stock in a medical corporation that treats carpal
>> mouse syndrome?
>
>It is not clumsy. I have been using a similar interface on desktop
>applications for 20 years and no user has ever complained.

*I* am the primary user of this interface, and *I* am complaining.

This is not a typical user interface: it's for admins, and you can
expect that admins will have privileges and know-how to do anything
the page can do with manually-typed-in SQL. If mass changes are
required, it will probably be easier and safer to use manually-typed-in
SQL. The page is supposed to be for quick entry of simple changes.
If it's not more convenient to use the page than manually-typed-in
SQL, it's useless.

I certainly wouldn't design something like this for the world at
large to use. And that's not who's going to be using it.

>> On your page I can only see 10 records at a time, and there's a
>> lot of space between them. I'd like to see at least 30.
>
>That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are for,
>to allow you to set your own page size.

But you still can't see that many on the screen at one time.
Checkboxes or submit buttons take up too much vertical space, out
of proportion to the actual size of the box or button on the screen,
and I haven't found a way around that even by making the type size
tiny. To make the interface usable, I want to be able to SEE lots
of records at a time.

>> Without
>> scrolling (on a 1024x768 display).
>
>You cannot guarantee that everyone has a screen resolution of 1024x768

I can guarantee that anyone who doesn't is not authorized to use
the application. :-) I'll tolerate scrolling if the screen is
smaller, although there aren't that many smaller screens around any
more.

>> But I don't mind scrolling if
>> there's hundreds of records. The different sort orders available
>> usually put the records I'm interested in at the top.
>
>The column headings are hyperlinks which, when pressed, will cause the data
>to be sorted on that column. I mean ALL the data, not just the data in the
>current page.

Ok, this is much like the pages I have, except I don't try to paginate
them, just put everything on one page. Also, there's a search function
to display a subset of the data.

>
>>>Put a checkbox against each entry so that the
>>>user may select one or more entries, then when a button is pressed it
>>>performs that action against those selected entries. Take a look at
>>>http://www.tonymarston.co.uk/sample/person_list.php for an example.
>>
>> Selecting more than one record at a time is rarely useful for
>> my purposes. The idea is to enter updates as needed, not save
>> up a whole batch of them and enter them every few days.
>
>It may not be useful for your purposes, but other people find it VERY
>useful.

Other people aren't authorized to use this application. User
interface design is not a one-size-fits-all thing: it should be
done with the users who are going to use it, which is not always
the entire world.

>It is not about storing updates for several days and then applying
>them in a batch.
>
>In your method I suppose you can only select one record at a time in the
>LIST screen before you can navigate down to a DETAIL screen. If you then

I want to be able to change the status of a record *WITHOUT* going
to a detail screen. If I want a detail screen, that's what the
EDIT button is for, which allows changing a lot more fields but is
used less often.

>want to move onto another record you have to exit the DETAIL, return to the
>LIST screen, make another selection, then activate the DETAIL screen again.
>Using my method you can select all the records in the LIST screen (that's
>what the "select all" hyperlink is for, by the way) then activate the chosen
>DETAIL screen. This shows you the first record that you selected, but gives
>you scrolling options so that you can scroll forwards and backwards through
>all the records you selected WITHOUT having to return to the LIST screen.
>
>How do you like THEM apples?

Manually-typed-in SQL is looking better all the time ...

Gordon L. Burditt
.