SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    ********* Articles ArticleBot's Avatar
    Join Date
    Apr 2001
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Article Discussion

    This is an article discussion thread for discussing the SitePoint article, "7 Steps to Useable Forms"

  2. #2
    karthikeyan
    SitePoint Community Guest
    This article gives tips for both developers and Testers. really good

  3. #3
    SitePoint Addict sporkit's Avatar
    Join Date
    Jan 2003
    Location
    DeKalb, IL
    Posts
    290
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    the disappearing text trick from Add Help Information doesnt seem to work at all. am i doing something wrong?

    edit: ahh, ok. the name of the filed must be specified as the same name in the onclick field. maybe that could be changed? its confusing at first.

  4. #4
    Don't get too close, I bite! Nicky's Avatar
    Join Date
    Jul 1999
    Location
    Lancashire, UK
    Posts
    8,277
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I really disagree with tip 4 of this article. I believe that all websites should be getting built using CSS an valid XHTML in order to produce more usable and accessible sites. However, using tables in a webiste, aside for that which they were intended for (tabular data) is not the way forward.

  5. #5
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I take issue with a few of the points presented in the article too:
    1. Auto-focusing to an input on page load is frustrating to me, and to quite a few other users I've chatted with. I expect focus to stay on the address bar when a page loads, and nothing's more frustrating than seeing half a URL in a search box on the page when you're trying to get to another page.
    2. The status bar tricks are okay, but seem unnecessary. HTML has the title attribute for supplemental information, and that can be used on any element including form fields. This also has the benefit of not requiring scripting or altering the status bar (which a lot of power users disable thanks to fine-grained script permissions in browsers like Opera and Mozilla).
    3. The tables for form layout item is something I only slightly disagree with. For simple forms it's probably best not to use a table to lay out the form fields, but for a more complex form I could see a use for it.

    Seeing that this article was written in 2001 though, I definitely see why I disagree with what's mentioned here. 4 years ago there was far less choice in what could be done to make forms more usable, especially given the state of browsers web designers supported back then versus what they support now.

  6. #6
    SitePoint Guru hgilbert's Avatar
    Join Date
    Dec 2004
    Location
    London
    Posts
    839
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    isn't that article old?
    i remember reading it and getting mixed up


  7. #7
    Greg
    SitePoint Community Guest
    I can see a problem with the second code example under number three. If you give your input a * onClick = "document.forms[0].first_name.value='' *, then after a user fills in that input, if they click it again for any reason, their text is GONE. Particularly annoying with textareas, which hold a lot.

  8. #8
    itst
    SitePoint Community Guest
    @hgilbert: sure it's old. Tags and attributes wirtten in upper case, unquoted attribute, tables for layout... That's sooo 2000 ;) *scnr

  9. #9
    SitePoint Wizard bronze trophy conradical's Avatar
    Join Date
    Jan 2005
    Location
    Atlanta
    Posts
    2,354
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by vgarcia
    I take issue with a few of the points presented in the article too:

    1. Auto-focusing to an input on page load is frustrating to me, and to quite a few other users I've chatted with. I expect focus to stay on the address bar when a page loads, and nothing's more frustrating than seeing half a URL in a search box on the page when you're trying to get to another page.
    Yep, HOTMAIL is a good example! I type a "To" address and next thing i know i'm in the main text editor!

  10. #10
    Charles
    SitePoint Community Guest
    The problem with item #2 is that it is not nice to have if the page loads more slowly than I can type. I'm already typing in the 2nd or 3rd field, the page completes loading, and suddenly I'm back in the 1st field. This is a potential security risk if the field I'm typing into is a password field, as the password gets all or partially exposed in the 1st (focused) field.

    The logic would better be to place the focus in the first field if and only if the focus is not already in a form field.

  11. #11
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    San Francisco
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Autofocus not friendly to screen readers

    One problem with autofocus is that it is not friendly to blind site visitors using screen readers. They will find themselves in the first form field without any context for why they are there.

  12. #12
    perfect = good enough peach's Avatar
    Join Date
    Jun 2004
    Location
    -Netherlands-
    Posts
    1,383
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by conradical
    Yep, HOTMAIL is a good example! I type a "To" address and next thing i know i'm in the main text editor!
    yes I hate that one too, I must have typed over a thousand of half email adresses in the main text editor

  13. #13
    Juergen
    SitePoint Community Guest
    The problem with #3 is that the info text is also submitted if the user omits to enter information. How do you make sure that the info text is not submitted or that you can filter it out?

  14. #14
    SitePoint Zealot
    Join Date
    Jun 2005
    Location
    Sparks, NV, USA
    Posts
    136
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While it may be considered to fall into the realm of accessibility, use of the label tag can make forms more useable.

  15. #15
    Miruna
    SitePoint Community Guest
    What about positioning of the buttons, such as Back, Next, Cancel? What is the recommended standard arrangement? For example, if the options are Back, Next, Finish, and Cancel, would it be more intuative to have them be arranged as
    Cancel | Back | Next | Finish
    with the more likely buttons the user would click positioned to the left, or would it be better to position them as:
    Back | Next | Finish | Cancel
    with them being placed "positive to negative"?
    Thank you.

  16. #16
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    San Francisco
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't know about the other buttons, but I've had it suggested to me that there not even be a Cancel button as it is too easy to wipe out your work by mistake. I've certainly done that.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •