|
|
Posted by Tony Marston on 07/23/05 13:41
"Gordon Burditt" <gordonb.nkjrf@burditt.org> wrote in message
news:11e2gkki9pc4fca@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.
>
> Count the characters in the HTML (these take time to transmit over the
> net):
>
> Link method:
>
> <a href="zone.php?id=5&mode=delete">Delete</a>
>
> vs. form method:
>
> <form action="zone.php"><input type="hidden" name="id" value="5"><input
> type="mode" value="delete"><input type="submit" value="delete"></form>
>
> Can you shrink the form method to use less than 50% more characters
> than the link method?
Your style of coding is very inefficient. In my pages, using the POST
method, I have no more than this:
<input class="submit" type="submit" name="task#person_del.php"
value="Delete" />
The advantage of my method is that I do not pass primary keys in URLs as a
security measure.
> More HTML takes more time to send over the net. Multiply that by
> hundreds of lines of data and multiple buttons per line. Lots of
> forms seem to slow down the *BROWSER* much more than lots of links.
> I didn't say anything about server load, except the bigger the HTML,
> the more it takes to send it. IE6 seems to get much slower for
> 1000 forms vs. 1000 links. Firefox and Mozilla don't slow down as
> much, but they still slow down. I suspect it takes more memory to
> deal with forms than links and the browser starts paging. In any
> case, I don't get to redesign the browsers. Even with an open-source
> browser, that takes too much effort.
>
>>
>>>>>>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.
>
> You prefer the opinion of people who are *NOT* using the application
> over the person that is? I pity anyone you're doing web design for
> if you won't pay attention to the requirements for the design.
The people who have used the applications that I have been writing over the
past 10 years have not complained. I ignore the opinions of those who do not
use my software.
>>> 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?
>
> I want to see at least 30 lines on the *SCREEN*. Not the *PAGE*.
> I want 30 lines on the *SCREEN* simultaneously.
Whenever I have been asked by a lone individual to fill the screen with as
much data as possible in order to prevent the need to jump to another screen
all the other users reject it for being too "busy". They prefer the data
being presented in reasonably sized chunks rather than great masses.
Thank goodness I will never have to use one of your applications.
> Checkboxes and
> submit buttons seem to take much more vertical space than they
> visually occupy so you can't get that even if you make the font
> size way too tiny.
>
>>
>>> 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.).
>
> They aren't "navigation links", they are things you click on that
> DO something.
Then you don't understand the meaning of the term "navigation link". It is a
method of navigating to another script in order to perform a different
action. The current script also passes down any context so that the new
script knows which record to act on.
>>> 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?
>
> It does operate over the internet (admins can use it from home).
> It most certainly is not intended for general use by the public.
>
>>> I'll tolerate scrolling if the screen is
>>> smaller, although there aren't that many smaller screens around any
>>> more.
There are still plenty of people using screens at 800 x 600.
>>>>> 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?
>
> A <whatever you want to call it> screen is for listing data *and*
> making quick one-click updates to the status of things. That's
> what's needed.
Not in my designs it isn't. A LIST screen is for listing, an UPDATE screen
is for updating, and an INSERT screen is for inserting.
>>
>>>>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.
>
> A well-written (NOT according to your standards, though) page would
> allow users to make a set of simple changes (but which comprise a
> very large percentage of the changes actually needed in practice)
> faster than typing manual SQL. Change the status of something:
> call up the page (likely to be bookmarked), then one click to make
> the change. You seem to insist that because it's not a suitable
> interface for the general public (and I agree, it's not), it
> can't/shouldn't be done at all.
>
> Gordon L. Burditt
You design applications your way, and I will continue to design applications
my way.
--
Tony Marston
http://www.tonymarston.net
Navigation:
[Reply to this message]
|