|
|
Posted by Tony Marston on 07/22/05 12:21
"Gordon Burditt" <gordonb.9rxa8@burditt.org> wrote in message
news:11dvovqmsomok58@corp.supernews.com...
>>> >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.
There are no studies which show that the POST method is slower than the GET
method, or puts a heavier load on the server, so I don't believe you.
>>>>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.
I prefer the opinion of all my users over the past 10 years over that of a
lone individual.
> 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.
If you click "show 50" it changes the page size to 50 lines. Did you
actually try it?
> 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,
I think that one checkbox per line and one set of navigation links per page
is FAR superior to a separate set of navigation links per line. But that's
just my opinion (and the opinion of all my users over the past 10 years.).
> 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.
That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are for.
>>> 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. :-)
So it's not an internet application then?
> 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.
There's also a search function in my screen. Just press the SEARCH button
and up it pops.
>>
>>>>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.
Surely a LIST screen is for listing data while an UPDATE screen is for
updating data?
>>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
If your users are happy to manually type in the SQL to update the database
then why bother trying to write your own user interface at all? Just give
them phpMyAdmin and have done with it.
--
Tony Marston
http://www.tonymarston.net
Navigation:
[Reply to this message]
|