[js] inputfield format.

[PdeBie]

Mensen,

ik heb een input field die een bepaald format als invoer verwacht. Dit zijn barcodes op plastic pasjes.
Format: 6064-3653-1234-1234-123 (eerste 8 cijfers zijn altijd hetzelfde, de rest is numeriek)

Voorheen gebruikten we 5 input velden achter elkaar en verplaatsten we de focus naar het volgende veld, op het moment dat het huidige veld vol was. Dit heeft echter altijd gedoe opgeleverd in de verschillende browsers en we hebben nooit een waterdichte oplossing kunnen bedenken. Dus we hebben laatst besloten de 5 input velden te vervangen door 1 input.

Het format zou je normaal gesproken met een regular expression kunnen afvangen, maar het probleem is dat sommige gebruikers een handscanner gebruiken om de barcodes te scannen. Deze scanners plaatsen de streepjes niet.

Dus hebben we 2 opties:
- een mask op het veld.
- met javascript de streepjes plaatsen.

Omdat ik nog nooit een degelijke masked-input heb kunnen vinden die in alle browsers fatsoenlijk werkt (ie8, ie9, chrome, ff en sinds kort ook ie10) hebben we besloten om voor optie 2 te gaan, met javascript de streepjes plaatsen.

Dus je typt 4 cijfers, javascript zet een streepje, je typt de volgende 4, javascript zet een streepje.
Dit doe ik door bij elk keyup event het aantal karakers te tellen en vervolgens te bepalen of het veld een streepje nodig heeft.

code

JavaScript:

var startSequence = "6064-3653-"; //mandatory string at start of input
var control = $('#<%= tbBoncode.ClientID%>'); // textbox input
var hiddenControl = $('#hfBoncode'); // hidden field for history of textbox input
var splitChar = "-"; //split character for input
                
//KeyUp event on textbox input
control.keyup(function (e) {
var curValue = control.val(); //current input value
var hiddenValue = hiddenControl.val(); //current hiddenfield value
var isCorrectStartSequence = curValue.substring(0, 10) == startSequence; //current value contains correct start sequence

var textLength = curValue.length; //length of input text
var hiddenTextLength = hiddenValue.length; //length of hidden field text            
            
var lastChar = curValue.substr(curValue.length - 1); //last character of current value
var lastHiddenChar = hiddenValue.substr(hiddenValue.length - 1); //last character of hiddenfield

switch (textLength) {
    case 4: case 9: case 14: case 19:
        //if input doesn't end with split character, add splitcharacter.
        if (lastHiddenChar != splitChar && lastChar != splitChar) {
            control.val(curValue + splitChar);
        }
        break;
    case 5: case 10: case 15: case 20:
        //if input ends with split character, set focus to end of field. ! Doesn't work in FireFox
        if (lastHiddenChar == splitChar && lastChar == splitChar) {
            if (e.keyCode != 37 && e.keyCode != 39) {
                control.val(control.val());
            }
        }
        else if (lastChar != splitChar) {
            //if input doesn't end with split character, but text requires a split character add it and move last character to end.
            control.val(control.val().substring(0, textLength - 1) + splitChar + lastChar);
        }
        break;
    }

//copy current value of control to hiddenfield
hiddenControl.val(control.val());

probleem is nu, dat als ik het veld volledig vul en vervolgens in blok 3 cijfers begin te verwijderen (bijvoorbeeld omdat ik verkeerd ingevoerde cijfers heb) hij op een gegeven moment langs case 14 komt en dus een streepje zet en naar het eind van het veld springt.

Hoe zou ik dat kunnen voorkomen?

[Bosmonster]

Gewoon met of zonder streepjes accepteren en aan de achterkant (of onblur) er een goede code van maken? (streepjes weghalen of juist toevoegen)

Dit soort geforceerde javascript restricties levert juist nog veel meer gezeik op (zoals je nu al ondervindt) en voegt voor de gebruiker niks toe: die wil gewoon een code invoeren, zo snel en zo makkelijk mogelijk.

[ Voor 5% gewijzigd door Bosmonster op 12-04-2013 11:34 ]

[Verwijderd]

Met ^^.
Aangezien je user-input toch altijd aan de serverzijde moet bewerken, kan daar evengoed je check inbouwen. Controleer op de server of je streepjes er al dan niet staan.

Zoals je zelf al aangaf, gebruiken je gebruikers soms een barcodelezer en die plaatsen direct de hele string in plaats van cijfer per cijfer. Wat je dus ook zou kunnen doen is JS validatie uitvoeren na een aantal seconden. Ik bedoel dat je controleert dat er gedurende bijvoorbeeld 2 seconden niets in het tekstveld is gewijzigd en je dan de controle doet of de streepjes al dan niet op de juiste plaats staan.

[PdeBie]

Probleem is dat als wij die streepjes in het tekstveld weglaten, de code een stuk minder leesbaar wordt.
Op de pasjes staat de code ook in blokken: 6064 3653 1111 1111 1111

Dus om het leesbaar te maken, dachten we die streepjes automatisch te plaatsen voor de gebruiker.

Hoewel ik persoonlijk ook liever gewoon een lang nummer in het veld zie, weet ik nu al dat onze helpdesk plat gebeld gaat worden als we de barcode niet indelen in blokken.

de barcode scanner plaatst de barcode wel cijfer per cijfer overigens.

[ Voor 7% gewijzigd door PdeBie op 12-04-2013 11:39 ]

[Verwijderd]

Maar als de gebruiker de data moet invoeren kan hij toch zelf kiezen of hij de streepjes al dan niet wil plaatsen? Wanneer je de gegevens moet weergeven (uit je database halen bijvoorbeeld) kan je de streepjes toch zelf gewoon toevoegen?

[PdeBie]

De streepjes dienen puur voor het indelen in blokken om de leesbaarheid te vergroten. Daarom dat we eerst 5 losse input velden hadden.

De gemiddelde leeftijd van de eindgebruiker is denk ik wel over de 45 en daarvan zijn de ogen niet echt denderend meer. (woorden van de helpdesk, niet van mij )

[Slurpie]

Andes bij pas on submit of op blur doen.
Meeste banken doen het zo ook. alleen dan puntje en op andere plekken maar het principe blijft hetzelfde.

[PdeBie]

Slurpie schreef op vrijdag 12 april 2013 @ 11:42:
Andes bij pas on submit of op blur doen.

Het moet echt tijdens het invoeren gebeuren, omdat ze anders niet meer weten waar ze zijn gebleven en ze dus de hele code weer na moeten lezen of opnieuw moeten invoeren.

Onze eindgebruikers zijn echt van het type 'ga met muis naar rechterbovenhoek-commercial'.

-- edit --
dit is heel frustrerend soms, want wij moeten dit soort hakkie-takkie oplossingen bedenken voor echt de meest simpele dingen.

[ Voor 13% gewijzigd door PdeBie op 12-04-2013 11:47 ]

[jeroenikke]

Ik gebruik http://digitalbush.com/projects/masked-input-plugin/ en vind die erg gemakkelijk werken. Ik gebruik het om BTW nummers deftig te formatten, want gebruikers vinden het inderdaad gemakkelijker om tijdens het typen de fouten te spotten wanneer er kleinere getalgroepen gebruikt worden.

[PdeBie]

Die hebben wij ook geprobeerd, maar die werkt weer niet lekker met de handscanners helaas.

Ik heb het nu anders opgelost.

Op het moment van invoeren, blijft het een lange cijferreeks. Zodra alle 19 cijfers zijn ingevoerd, plaatst javascript de streepjes voor de leesbaarheid.

Dus input: 6064365312341234123 > javascript > 6064-3653-1234-1234-123

Dus ipv de switch-case:

JavaScript:

if (textLength == 19 && curValue.indexOf("-") == -1)
{
    //split text input into blocks
    var block1 = curValue.substring(0, 4);
    var block2 = curValue.substring(4, 8);
    var block3 = curValue.substring(8, 12);
    var block4 = curValue.substring(12, 16);
    var block5 = curValue.substring(16, 19);

    var newValue = block1;
    newValue += splitChar;
    newValue += block2;
    newValue += splitChar;
    newValue += block3;
    newValue += splitChar;
    newValue += block4;
    newValue += splitChar;
    newValue += block5;

    control.val(newValue);

    curValue = control.val(); //set to new current input value
    textLength = curValue.length; //set to new length of input text
    isCorrectStartSequence = curValue.substring(0, 10) == startSequence; //current value contains correct start sequence
}

Dit ligt nu bij onze tester en de helpdesk. Kijken wat ze ervan vinden.

[ Voor 5% gewijzigd door PdeBie op 12-04-2013 12:23 ]

[Bosmonster]

Het moet echt tijdens het invoeren gebeuren, omdat ze anders niet meer weten waar ze zijn gebleven en ze dus de hele code weer na moeten lezen of opnieuw moeten invoeren.

Een gebruiker die overzicht nodig heeft zal zelf de streepjes wel toevoegen (zo staat het ook op waar die het van overneemt lijkt me). Net als met een CC-nummer de spaties (bij voorkeur) optioneel zijn. Daarom is er ook geen enkele reden om juist de streepjes weer te gaan weren, behalve dan dat je het je gebruikers onnodig lastiger wilt maken.

Het gaat om het feit dat je de gebruiker het in laat voeren zoals hij/zij prettig/snel vindt. Daarna kun je hem re-formatten (bijvoorbeeld on-blur) en controleren.

[ Voor 11% gewijzigd door Bosmonster op 12-04-2013 12:42 ]

[Verwijderd]

Bosmonster schreef op vrijdag 12 april 2013 @ 12:38:
[...]


Een gebruiker die overzicht nodig heeft zal zelf de streepjes wel toevoegen (zo staat het ook op waar die het van overneemt lijkt me). Net als met een CC-nummer de spaties (bij voorkeur) optioneel zijn. Daarom is er ook geen enkele reden om juist de streepjes weer te gaan weren, behalve dan dat je het je gebruikers onnodig lastiger wilt maken.

Het gaat om het feit dat je de gebruiker het in laat voeren zoals hij/zij prettig/snel vindt. Daarna kun je hem re-formatten (bijvoorbeeld on-blur) en controleren.

Dit is net wat ik bedoelde, alleen slaag ik er blijkbaar niet altijd in om mij duidelijk te verwoorden

[Just smile]

In dit soort gevallen stel ik een formulier op waardoor er na bijvoorbeeld een blok van 4 cijfers de gebruiker automatisch naar het volgende blok gaat. Wat ze bij ING als 'betalingskenmerk' ook hebben.

[PdeBie]

Bosmonster schreef op vrijdag 12 april 2013 @ 12:38:
[...]
Het gaat om het feit dat je de gebruiker het in laat voeren zoals hij/zij prettig/snel vindt. Daarna kun je hem re-formatten (bijvoorbeeld on-blur) en controleren.

Echter hebben wij 1200 verschillende gebruikers met elk hun eigen voorkeur.
Dus dan krijg je of één methode waarop ze het allemaal moeten doen (met een mask of iets dergelijks) of vrije invoer welke in ons geval dan een blanco inputveld zonder een javascript-streepjes-zetten-methode erop en server side zelf de handel controleren (wat ik nu toch al doe).

De laatste vorm (vrij invoer veld) heeft ook mijn voorkeur. Ik krijg die barcode wel uit de input getrokken. Maar dan krijgt de helpdesk dus allerlei telefoontjes dat ze het niet snappen en daarom dat ze dus enige vorm van leesbaarheid verbetering erin willen hebben.

Just smile schreef op vrijdag 12 april 2013 @ 13:41:
In dit soort gevallen stel ik een formulier op waardoor er na bijvoorbeeld een blok van 4 cijfers de gebruiker automatisch naar het volgende blok gaat. Wat ze bij ING als 'betalingskenmerk' ook hebben.

Lees de TS eens. Dit hadden wij, maar heeft echter altijd gedoe opgeleverd in de verschillende browsers en we hebben nooit een waterdichte oplossing voor kunnen bedenken.

[ Voor 21% gewijzigd door PdeBie op 12-04-2013 13:45 ]

[R4gnax]

pdebie schreef op vrijdag 12 april 2013 @ 13:44:
Lees de TS eens. Dit hadden wij, maar heeft echter altijd gedoe opgeleverd in de verschillende browsers en we hebben nooit een waterdichte oplossing voor kunnen bedenken.

Kan nooit zo moeilijk zijn om met iets werkbaars op de proppen te komen. Hier; 15 minuutjes werk.

HTML:

<!DOCTYPE html>
<html>
<head>
  <title>Barcode typethrough</title>
  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
  <script>
    $( document ).ready( function() {

      $( ".barcode" )
        .on( "keyup", "input", function( event ) {
          var el = $( this ),
            value = el.val() || "",
            maxlength = +el.attr( "maxlength" ),            
            range,
            caret;
            
          // Internet Explorer
          if ( document.selection ) {
            range = document.selection.createRange();
            range.moveStart( "character", -value.length );
            caret = range.text.length;
          
          // Everything else
          } else {
            caret = +this.selectionStart;
          }

          if ( caret >= maxlength ) {
            el.next( "input" ).focus();
          }                 
        })
        .on( "change", "input", function( event ) {
          var el = $( this ),
            value = el.val() || "",
            maxlength = +el.attr( "maxlength" );
            
          if ( value.length > maxlength ) {
            el.val( value.slice( 0, maxlength ));            
          }
        });
    });
  </script>
</head>
<body>
  <div>
    <fieldset class="barcode">
      <legend>Barcode</legend>
      <input maxlength="4"/>
      <input maxlength="4"/>
      <input maxlength="4"/>
      <input maxlength="4"/>
      <input maxlength="4"/>
    </fieldset>
  </div>
</body>
</html>

[Herko_ter_Horst]

R4gnax schreef op vrijdag 12 april 2013 @ 20:48:
[...]


Kan nooit zo moeilijk zijn om met iets werkbaars op de proppen te komen. Hier; 15 minuutjes werk.

[lap code]

En dit heb je ook getest in "de verschillende browsers" waar de TS het over heeft?

[ Voor 71% gewijzigd door Herko_ter_Horst op 12-04-2013 21:29 ]

[Miyamoto]

pdebie schreef op vrijdag 12 april 2013 @ 13:44:
De laatste vorm (vrij invoer veld) heeft ook mijn voorkeur. Ik krijg die barcode wel uit de input getrokken. Maar dan krijgt de helpdesk dus allerlei telefoontjes dat ze het niet snappen en daarom dat ze dus enige vorm van leesbaarheid verbetering erin willen hebben.

Kun je dan geen duidelijke help-beschrijving bij het veld plaatsen?
In die omschrijving kun je wel zeggen dat men de code ook met streepjes in moet voeren, zoals het ook op het pasje staat. Desnoods een afbeelding van een pasje erbij en de barcode omcirkeld.

[R4gnax]

Herko_ter_Horst schreef op vrijdag 12 april 2013 @ 21:28:
[...]

En dit heb je ook getest in "de verschillende browsers" waar de TS het over heeft?

Omdat je het zo netjes vraagt; ik heb het getest onder IE9-as-IE7, IE9-as-IE8, IE9-as-IE9, Firefox 20, en Chrome 28 dev. Niet dat dat nou zoveel uit zal maken; de support hangt namelijk voor alles wat niet IE is enkel af van de selectionStart property en dat ondersteunt elke grote browser.

Merkte trouwens nog wel dat IE een probleempje heeft met teruguit tabben door de component velden. Dat heb ik nog even in 5 minuutjes recht getrokken. Simpele kwestie van bijhouden of het veld dat de keydown en keyup events verwerkt wel hetzelfde is, anders niet automatisch de focus voorwaards schuiven.

HTML:

<!DOCTYPE html>
<html>
<head>
  <title>Barcode typethrough</title>
  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
  <script>
    $( document ).ready( function() {
    
      var lastEl;
      
      $( ".barcode" )
        .on( "keydown", "input", function( event ) {
          lastEl = this;
        })
        .on( "keyup", "input", function( event ) {
          var el = $( this ),
            value = el.val() || "",
            maxlength = +el.attr( "maxlength" ),            
            range,
            caret;
            
          // Internet Explorer
          if ( document.selection ) {
            range = document.selection.createRange();
            range.moveStart ( "character", -((el.val() || "").length));
            caret = range.text.length;
          
          // Everything else
          } else {
            caret = +this.selectionStart;
          }

          if ( caret >= maxlength && lastEl == this ) {
            el.next( "input" ).focus();
          }         
        })
        .on( "change", "input", function( event ) {
          var el = $( this ),
            value = el.val() || "",
            maxlength = +el.attr( "maxlength" );
            
          if ( value.length > maxlength ) {
            el.val( value.slice( 0, maxlength ));            
          }
        });
    });
  </script>
</head>
<body>
  <div>
    <fieldset class="barcode">
      <legend>Barcode</legend>
      <input maxlength="4"/>
      <input maxlength="4"/>
      <input maxlength="4"/>
      <input maxlength="4"/>
      <input maxlength="4"/>
    </fieldset>
  </div>
</body>
</html>

[PdeBie]

allereerst bedankt dat je er die tijd in hebt gestoken, alleen is de requirement dat het naar 1 veld gaat.
Ik zal je oplossing hier voordragen, maar ik denk dat ze toch voor het enkele veld willen gaan.

[R4gnax]

Geen probleem. Puzzeltje op z'n tijd is goed om mij ook scherp te houden en het is zo'n typisch probleem dat ik er zelf ook onderhand wel eens een oplossing voor in mijn 'toolbelt' wilde hebben.

[ Voor 5% gewijzigd door R4gnax op 15-04-2013 15:59 ]

[TheNephilim]

Als je toch terug wil naar één veld zou ik met REGEX aan de slag gaan om je probleem op te lossen. Op het moment dat een gebruiker aan het typen is kun je dan makkelijk een streepje toevoegen en op het moment dat een gebruiker ergens een cijfer weghaalt, als het veld verder helemaal ingevuld is, kun je dat ook makkelijk ondervangen.

Gewoon 5 keer 4 cijfers die gescheiden worden door een streepje, dat moet toch met enkele patterns te ondervangen zijn.

[R4gnax]

TheNephilim schreef op dinsdag 16 april 2013 @ 16:55:
Als je toch terug wil naar één veld zou ik met REGEX aan de slag gaan om je probleem op te lossen. Op het moment dat een gebruiker aan het typen is kun je dan makkelijk een streepje toevoegen en op het moment dat een gebruiker ergens een cijfer weghaalt, als het veld verder helemaal ingevuld is, kun je dat ook makkelijk ondervangen.

Gewoon 5 keer 4 cijfers die gescheiden worden door een streepje, dat moet toch met enkele patterns te ondervangen zijn.

Wat jij voorstelt zou alleen werken wanneer de gebruiker klaar is met typen en het veld verlaat; via een change of blur event dus. Als je dit soort modificaties 'live' wilt doen terwijl een gebruiker aan het typen is dan moet je de caret positie ophalen en bijhouden, de inputwaarde aanpassen en daarna de caret weer op de correcte plaats terug zetten. Dat is verre van triviaal maar absoluut vereist om standaard type-through niet te breken.

[TheNephilim]

R4gnax schreef op dinsdag 16 april 2013 @ 21:02:
[...]


Wat jij voorstelt zou alleen werken wanneer de gebruiker klaar is met typen en het veld verlaat; via een change of blur event dus. Als je dit soort modificaties 'live' wilt doen terwijl een gebruiker aan het typen is dan moet je de caret positie ophalen en bijhouden, de inputwaarde aanpassen en daarna de caret weer op de correcte plaats terug zetten. Dat is verre van triviaal maar absoluut vereist om standaard type-through niet te breken.

Hoezo? Je kunt gewoon bij elke keyup kijken, in welk 'blok' je aan het typen bent. Je zult wel meerdere patterns nodig hebben om het vloeiend te krijgen, maar ik weet bijna 100% zeker dat zoiets moet werken. Heb geen tijd om een voorbeeld in elkaar te flanzen, maar checken of er 4 cijfers achter elkaar zijn en dan een streepje, geen streepje? Ophalen, replacen naar 4 cijfers en een streepje.

Maar, je hebt ook wel enorm veel eisen. Namelijk, één veld in plaats van 5, dan al typend de streepjes toevoegen. Ikzelf zou voor het 5 velden met auto-tab kiezen. Is echt het makkelijkst XD

[Bosmonster]

maar checken of er 4 cijfers achter elkaar zijn en dan een streepje, geen streepje? Ophalen, replacen naar 4 cijfers en een streepje.

Maar je caret staat dan achter het 4de teken en nadat je het streepje hebt toegevoegd moet ie naar de 5de. Anders type je gewoon weer over het streepje heen.

Ander scenario is dat je midden in de tekst wijzigingen aanbrengt. Je kunt dus niet dit netjes bereiken zonder ook de caret mee te nemen in je verhaal, en dat maakt het direct behoorlijk lastig.

Persoonlijk zou ik dit nooit "live" doen, maar pas na het invoeren (onblur). Het live doen heeft geen enkele toegevoegde waarde, behalve potentiele verwarring over het wijzigingen van de invoer waar iemand mee bezig is en het verplaatsen van de caret.

Daarnaast vraag ik me af hoe lekker dit gaat werken op bijvoorbeeld touch-keyboards, waar de caret niet zichtbaar is.

[ Voor 47% gewijzigd door Bosmonster op 17-04-2013 10:54 ]

[_Thanatos_]

Om nog maar te zwijgen over voice input

Ik begrijp het hele probleem ook niet. Als de gebruiker streepjes of spaties wil invoeren om het voor zichzelf duidelijk te maken, dan kun je dat toch toelaten? Als niet, dan niet.

[PdeBie]

probleem is dat onze eindgebruikers van het niveau 'ga met muis naar rechterbovenhoek' zijn. die moet je alles voorkauwen, anders snappen ze het niet.

[R4gnax]

pdebie schreef op woensdag 17 april 2013 @ 22:03:
probleem is dat onze eindgebruikers van het niveau 'ga met muis naar rechterbovenhoek' zijn. die moet je alles voorkauwen, anders snappen ze het niet.

In dat geval is je geld beter besteed aan educatie van je gebruikers dan aan halfwerkende software workarounds.

[Bosmonster]

pdebie schreef op woensdag 17 april 2013 @ 22:03:
probleem is dat onze eindgebruikers van het niveau 'ga met muis naar rechterbovenhoek' zijn. die moet je alles voorkauwen, anders snappen ze het niet.

Ze hoeven het ook niet te snappen als je ze vrij laat. Je accepteert elke invoer, met of zonder streepjes.

In het ergste geval zou je het er nog bij kunnen zetten met een voorbeeld van mogelijke invoer.

Een interactie-probleem op proberen te lossen met technische trucjes is meestal niet de juiste weg.

[PdeBie]

Ik snap je punt en ben het met je eens.

Ik zal het hier eens voorleggen. Kijken wat de rest ervan vind.

[_Thanatos_]

Lees anders ook eens het boek Don't Make Me Think. Als ik me goed herinner, wordt daar het invoeren van creditcard-nummers aangehaald. En dat het flauwekul is om streepjes te vereisen of te verbieden. Het is niet een mening die je kan hebben dat het goed of slecht is om user-input te beperken of af te bakenen. Accepteer gewoon alles wat je kan parsen.

[PdeBie]

Dat boek ziet er erg interessant uit. De preview op amazon leest in ieder geval al prettig weg