Vaikuta Web-kävijöihisi reaaliaikaisella lomakevalvonnalla

online-muodossa

The first impression you usually have as a user of a Web Application is when you fill out a web form. I'm amazed at the number of web forms out there that have zero validation or that wait for you to submit your form contents before telling you what problems that you might have.

My rule of thumb is that anything that is not validated is supported. Anything that can be validated prior to submitting the form must be. With the advent of Ajax, you can even validate data against your database prior to submission. Don't pick the lazy route – users appreciate the help!

Tässä muutamia esimerkkejä:

  1. Sähköpostiosoitteet – I don't mind forms that make you fill out your email address twice to validate them, but the fact that they don't tell you whether or not they match or are constructed appropriately is inexcusable.
  2. salasanat – If you're going to make me type in a password twice, then please validate that the values are the same before posting the form.
  3. Salasanan vahvuus – If you require a certain password strength (combination of alphanumeric characters or cases), then provide some feedback for me while I'm typing my password in. Don't wait for me to submit before telling me it failed.
  4. Päivämäärät – If you'd like the date in a m/d/yyyy format, then allow me to enter the information in a single field by typing those values and formatting them appropriately. If you want leading zeros, put them in after. It's okay to display one format and save another in your database.
  5. Päivän Date - Täytä se minulle! Miksi pyydät minua täyttämään päivämäärän, kun tiedät sen jo ?!
  6. Päivämäärämuoto – If you have an international application, you can default a date format based on Internationalization of your application. Of course, it's good to have an option for users to override that option and select their own.
  7. Sosiaaliturvatunnukset – it's pretty simple to add some javascript that automatically jumps from field to field or programmatically put a dash in between values.
  8. Puhelin Numbers – taking Internationalization into consideration, these types of fields also can be simplified by formatting the telephone number in the interface, but saving it in another format that's efficient for your back-end. Don't make your users type in parenthesis, spaces, and dashes.
  9. Suurin tekstin pituus – if you limit the number of characters stored in your database, then DON'T let me type that many characters in! It doesn't even require difficult validation… it's just a setting on the textbox.
  10. Tekstin vähimmäispituus - jos tarvitset tekstin vähimmäispituuden, soita hälytys, kunnes minulla on tarpeeksi merkkejä.

Here's an example of a Password Strength function from Nörtti viisaus:

Kirjoita salasana:

PÄIVITYS: 10 - Löysin siistin resurssin, jolla on ladattavissa oleva JavaScript-kirjasto lomakkeen vahvistus, nimeltään LiveValidation.

16 Kommentit

  1. 1

    I agree those are great features for forms, but saying that it is “inexcusable” to not do perform front end javascript validation is a more of an personal opinion. I love working in javascript, and have written some pretty neat editmasks to do some of the things you talk about, but a lot of them are far from trivial, and many of the javascript form validation packages out there have a number of big holes. Not everyone will invest the time into duplicating their back end validation with (more often than not) more complex front end javascript validation.

    Hyviä pisteitä, mutta ehdottomasti ei jokaisen verkkolomakkeen mielestäni "tarvitse".

  2. 2

    Salasanan tarkistaja on rikki. Mikä tahansa salasana on tarpeeksi hyvä, jos se on pitkä.

    Esimerkiksi:

    Onko tämä todella keskinkertainen salasana?

    f46dffe6ff4ffgdfgfjfgyu656hfdt74tyhdtu5674yfgh6uhhye45herdhrt64684hythdfth54y54348fgdcvzse8cn984v3p4m6vq98476m3wuw89ewfucsd8fg67s4v8tw76u340m6tver7nt+s89346vs+0em9u+s+09hrtuhss586ysvne4896vb4865tbv089rt++

  3. 4

    Minulle paras lomakkeen vahvistus on, kun annat käyttäjälle vaikutelman asiakaspuolen tarkistuksesta, kun se on AJAX / palvelinpuolen vahvistus.
    Sinun tarvitsee vain liittää lomakeelementteihisi tapahtumien käsittely (avaimet, sumennus, napsautus jne.), Jotka lähettävät koko lomakkeen AJAX: n kautta palvelimelle, kutsumalla "check" -toiminnon, joka palauttaa vastaavat virheilmoitukset (tämä salasana on liian yksinkertainen, päivämäärä on väärässä muodossa jne.)
    Kun käyttäjä vihdoin lähettää lomakkeen napsauttamalla Lähetä-painiketta, voit silti käyttää palvelinpuolen tarkistus -toimintoa vahvistaaksesi lomakkeen viimeisen kerran ennen tietojen lisäämistä tietokantaan tai johonkin muuhun prosessiin.
    Tällä tavalla käyttäjät ovat tyytyväisiä onthego-tarkistukseen JA kehittäjät ovat tyytyväisiä vain palvelinpuolen validointikehitykseen.

    • 5
      • 6

        Ei niin nopeasti Doug - Olen samaa mieltä alkuperäisen oletuksesi kanssa, että nämä hyödylliset ominaisuudet, kuten SSN: n muotoilu lennossa, ovat vähäpätöisiä. Ja sen laiska vain lähettää viesti, että se on väärä, kun voit korjata sen tarvitsematta arvailla muotoa.

        Olen kuitenkin samaa mieltä myös Nicolasin kanssa siitä, että palvelinpuolen logiikkaa käytetään yhdessä AJAX: n kanssa.

  4. 7

    Nimesi sanoo "Vaikuta ystäviisi ...", mutta et onnistu vaikuttamaan minua tällä 2 minuutissa, soitettuna postitse.

    Kirjoita otsikko uudelleen (liian harhaanjohtava, saa ajattelemaan, että keskustellaan esimerkkeistä ja käytännöistä).

    If people are not doing this already in their forms, then they are just learning or the form is not important enough to use validation.

    Todelliset web-ohjelmoijat tietävät tämän jo ja tekevät sen.

    • 8

      Jay,

      Sorry about that! My point was definitely not to provide developer feedback – I really was coming from the point of view of a Product Manager. I agree with you – but it’s interesting that some other developers don’t! I think that’s unfortunate.

      Kiitos, että käytit aikaa!
      Doug

  5. 9

    Olen täysin samaa mieltä siitä, että vahvistus on välttämätön osa kaikkia sovelluksia. Tiimijohtajana huomaan yleensä, että lähetän koodin takaisin "valmiiksi" esimerkiksi tarkistusten puuttumisen tai tekstinsyötön pituuksien rajoittamisen vuoksi.

    Useimpien asioiden parissa työskentelen mielestäni noin 50% ajasta saadaksesi jotain toimimaan normaaleissa olosuhteissa ja jos käyttäjät käyttävät järjestelmää haluamallani tavalla. Loput 50% kehitysajasta tulee tarkistamalla heidän syötteensä, varmistamalla tietojen eheyden säilyminen ja tekemällä lomakekentät estämään haitallisten tietojen syöttäminen.

    Kirjoitin viestin siitä, kuinka käytän InputVerifiersia hava swing -sovelluksissani, ja näytän, kuinka vahvistan sähköpostin tekstikentän. Käyttämäni säännöllinen lauseke on helposti muokattava puhelinnumeroiden, postinumeroiden, SSN: ien jne. Vahvistamiseksi.

    Blogikirjoitukseni on http://timarcher.com/?q=node/36

    Hyvä kirjoitus Doug!

  6. 10

    Olen samaa mieltä. Salasanat ovat todella tärkeitä, ja niihin on suhtauduttava vakavasti. Mielestäni on vain normaalia, että melkein kaikki lomakkeet kirjoittavat salasanan kahdesti, mutta kahden salasanan pätemättömyyden osoittaminen osoittaa, että sitä ei pidetä vakavasti.

  7. 11

    Olen samaa mieltä siitä, että asiakkaan vahvistus voi olla erittäin käyttäjäystävällinen ominaisuus. On kuitenkin tärkeämpää varmistaa, että validoinneilla itsessään on todella järkevää.

    Annoit loistavan esimerkin siitä, miten validointi voi johtaa käyttäjiä harhaan ja mikä pahempaa, ajaa heidät pois sivustoltamme:

    Geek Wisdomin salasanan vahvuuden tarkastelu harkinnoista tZhKwnUmIss olla heikko salasana. Sen lisäksi, että tämä on täysin vahva salasana, se myös vierauttaa vieraita, koska se antaa heille väärän käsityksen siitä, että kirjautuminen sivustoosi tällä salasanalla on jotenkin epävarmaa.

    Olisi paljon parempi (ja helpompaa) yksinkertaisesti vihjata käyttäjille, että hyvä salasana on vähintään kuusi merkkiä pitkä ja sen tulisi sisältää sekä numeroita että kirjaimia.

    Muita kyseenalaisia ​​vahvistuksia ovat käyttäjätunnukset, jotka tarvitsevat tietyn vähimmäispituuden tai eivät välttämättä sisällä välilyöntejä. Mikä vikaa käyttäjätunnuksissa X, John Doe, tai jopa # *! §? Pystyn käsittelemään sen.

  8. 12

    Olen samaa mieltä kanssasi. Jotkut lomakkeet näyttävät hyvältä, mutta se ei tarjoa hyvää validointia. Henkilökohtaisia ​​tietoja annetaan, ja on asianmukaista ottaa ne vakavasti aivan kuten kaikki liiketoimintalomakkeet paperiversiona.

  9. 13
  10. 14
  11. 15

    Minusta on hieman huvittavaa, että lähetät todellisuuden todellisen lomakkeen validoinnin hyvyydestä, mutta viestin alaosassa oleva kommenttilomake ei sisällä mitään näistä…

    Ymmärrän, että kirjoitat ajatuksiasi Internetiin WordPressin avulla, mutta ehkä myöskään sen varmistaminen, että harjoittelet saarnaamistasi, ei ole niin huono idea. 🙂

    Hyvä viesti, muuten, vaikka en välttämättä olekaan samaa mieltä kaikesta kirjoittamastasi.

    • 16

      Doh! You busted me, Amanda! I do wish I had time to do better form validation and to integrate it into WordPress. I especially like the Adobe Spry validointikehys ja haluaisi nähdä jonkun integroivan nämä kaksi!

      Thanks! (And I always appreciate that there are multiple opinions on any topic).
      Doug

Mitä mieltä olet?

Tämä sivusto käyttää Akismetiä roskapostin vähentämiseksi. Lue, miten kommenttitietosi käsitellään.