[interactie formulier] textlengte in textarea

[PdeBie]

Hoi allen,

even jullie mening over wat het beste qua user-interactie is. Niveau eindgebruiker = computer leek.

Ik heb een tekstarea.
Dit veld mag maximaal 5 regels en maximaal 250 tekens bevatten (dus 5 x 50 tekens). Daarnaast moet er bijgehouden worden hoeveel karakters er ingevoerd zijn.

--------------------------
--------------------------
Idee 1:
Gebruiker kan typen wat hij wilt. Elk teken en elke <enter> die hij ingeeft telt 1 karakter op bij de teller.
Als hij een te lange tekst invoert of plakt vanaf het kladblok (dan wel meer dan 250 tekens, dan wel meer dan 5 regels), toont het formulier een melding bij het veld dat de ingevoerde tekst te lang is of teveel regels bevat.
--------------------------
Idee 2:
Gebruiker kan typen wat hij wilt.
Elke <enter> die de gebruiker geeft, telt 50 tekens bij de teller op.
Als de gebruiker de max. limiet van 250 tekens overschrijd, wordt de tekst automatisch ingekort (trimmen via javascript key-up event of iets dergelijks) en wordt er een melding getoond bij het veld.

--------------------------
--------------------------

Deze twee opties liggen nu op tafel en ben ik over aan het discussiëren met een collega. Ik denk dat idee 1 het beste is, hij denkt idee 2.

Ik vind persoonlijk het automatisch trimmen van een tekst niet gebruiksvriendelijk. Je bent lekker aan het typen en vervolgens verdwijnt de laatst letter elke keer omdat hij de max. limiet overschrijdt. Geen tegenargument van mijn collega gekregen. Hij vind dat juist handig!

Mijn collega zegt dan weer:
je plakt een hele lange tekst. Je ziet de melding dat hij te lang is, maar vervolgens moet je zelf gaan zitten tellen hoeveel hij te lang is. Mijn tegenargument hierop is dat de gebruiker best tot 5 kan tellen en dus ziet hoeveel regels hij in moet korten.

Reden voor de limiet van 5 regels en 250 tekens is dat de tekst op een kaartje geprint moet worden en we de layout van de invoer willen bewaren.

Dus als iemand onderstaand invoert, moet het ook zo op het kaartje komen.

code:

Lieve schat,

ik hou van je.

Je (b)engel.

Wat denken jullie?
Of zien jullie misschien nog andere mogelijkheden?

[Bosmonster]

Ik vind persoonlijk het automatisch trimmen van een tekst niet gebruiksvriendelijk.

Eensch.

Er is nog een optie 3: namelijk helemaal niet met de user input rommelen, maar de gebruiker real-time het resultaat tonen. Daarin kun je wel eventueel afbreken/trimmen met een melding waarom dat is gebeurd (jouw optie 1, maar dan bij het realtime resultaat).

[ Voor 7% gewijzigd door Bosmonster op 11-11-2013 16:56 ]

[418O2]

is er ook een limiet van 50 karakters per regel?

Ik zou gewoon 5 inputs met een maxlength van 50 karakters plaatsen. dit in een textarea doen is vragen om gezeik.

[PdeBie]

Elke regel is 50 karakters ja. Anders past het niet op het kaartje.

5 inputs hadden we vroeger, maar dat is ooit afgeschaft. Reden weet ik niet meer.

[Fish]

waarom zet je niet gewoon een wordwrap op 50 karakters en klaar ?

tel elke wrap als een enter en klaar

niets trimmen, gewoon je invoer beperken tot max 250 karakters. voor de regels kun je vast wel een melding verzinnen

[ Voor 59% gewijzigd door Fish op 11-11-2013 17:05 ]

[PdeBie]

Wablief? Je bedoelt als je door blijft typen zonder een enter te geven?
Dan zou hij inderdaad een extra regel moeten tellen.

Maar dan nog zitten we met de discussie zoals in de openingspost staat vermeld.

[R4gnax]

fish schreef op maandag 11 november 2013 @ 17:03:
waarom zet je niet gewoon een wordwrap op 50 karakters en klaar ?

Dan zit je alsnog met een probleem; namelijk het feit dat een browser een word-wrap zal prefereren op een word-boundary.

Zoals in dit
woordlengteprobleemvoorbeeld.

Het meest vriendelijke is sowieso altijd om je boodschap niet geforceerd af te kappen. Het is als gebruiker namelijk vreselijk irritant om, wanneer je een boodschap moet herformuleren om binnen een bepaalde karakterlengte te passen, de hele tijd woorden weg te moeten halen voordat je woorden toe kunt voegen.

Zeker power-users zullen dan geneigd zijn om de toevlucht tot een externe plain text editor met een character counter. Dus waarom geef je dat dan niet meteen? Je kunt altijd alsnog weigeren een boodschap toe te staan met een form validator op max. toegestane lengte, die je aan de submit van het formulier koppelt.

Daarnaast is het ook een technische nachtmerrie om dit goed te doen. Een kleine doch representatieve greep uit deze nachtmerrie:

1. Een key-up event vangt geen paste via een right-click context menu af.
2. Een drag & drop operatie van tekst genereert ook geen key-up event.
3. Het achteraf programmatisch aanpassen van de inhoud van een tekstveld verandert in IE ook de geselecteerde text range; het selecteert opnieuw de volledige inhoud. Je zult de vorige text caret positie en/of geselecteerde text range moeten onthouden en correct kunnen terugzetten.
4. Afhankelijk van de geselecteerde text range kan een toetsaanslag zowel de lengte van de tekst vergroten als verkleinen en in het geval van verkleinen kan dit meerdere karakters inhouden.
5. Voorgaande punt betekent dat je bij het bereikt hebben van de maximale invoerlengte niet domweg elke toetsaanslag kunt weigeren. Je moet controleren wat het effect daarvan zal zijn, en dat kan per browser verschillend zijn. Enige manier om dat effect te weten te komen is om het plaats te laten vinden en daarna mogelijk ongedaan moeten maken. En daarmee ben je weer bij punt 3 aanbeland...

Doe er ééntje fout en je hebt de usability voor je gebruikersgroep vernachelt.

Het probleem met de exact 5x50 karakters uitvoer kun je het beste tackelen door een live preview uitvoer boven of naast de invoer te zetten. Het is belangrijk deze als zodanig te labelen en deze niet onder de invoer te zetten, want dan ziet een gebruiker deze mogelijk niet goed. In deze live preview zou je de vastgezette 50 karakters per regel nog eens kunnen benadrukken door gebruik te maken van een fixed width font icm met een afrastering die duidelijk karakterposities aangeeft. (Denk bijv. aan de oude papieren overboekingsformulieren voor bankrekeningen of aan accept giro's.)

Omdat gebruikers feedback krijgen op het eindresultaat via een live preview kun je ook qua herformatteren van de tekst met wat meer wegkomen, waardoor de line-wrapping in je invoerveld niet noodzakelijk 100% overeen hoeft te komen met het gedrukte label.

[ Voor 4% gewijzigd door R4gnax op 11-11-2013 22:46 ]

[PdeBie]

allereerst: bedankt voor je uitgebreide post. Top!

R4gnax schreef op maandag 11 november 2013 @ 22:44:
[...]

Zeker power-users zullen dan geneigd zijn om de toevlucht tot een externe plain text editor met een character counter. Dus waarom geef je dat dan niet meteen? Je kunt altijd alsnog weigeren een boodschap toe te staan met een form validator op max. toegestane lengte, die je aan de submit van het formulier koppelt.

Die teller staat al bij het veld. Elk karakter telt 1 op de teller op, evenals een enter aangezien dit ook 1 karakter is. Uiteraard zit er ook validatie op het veld dat de maximale limiet van 250 tekens niet overschreden wordt. Het aantal regels vang ik momenteel af door het aantal NewLines te tellen, maar hiermee vang ik de wordwraps nog niet af. Dus daar zit nog een issue.

Mijn collega wilt echter dat als je op enter drukt de teller tot 50 bij het totaal aantal tekens optelt, zodat je ziet dat je nog maar 50 tekens minder hebt.

Voorbeeld:

code:

1234567<enter>
1234567



------------------------------------------
Totaal aantal tekens: 57 / resterend: 193 van 250

Wat mij betreft is dit zeer onlogisch, maar hij vind dat het dan duidelijker wordt.

De live preview kan ik me op zich wel in vinden, alleen vrees ik dat we daar in ons grafisch ontwerp geen plek voor gaan vinden. Ik zal het hier eens voorleggen.

Wat een concurrent van ons doet is wel automatisch trimmen van de tekst. Ook daar zitten gebruikers aan dezelfde limiet. Ik denk dat mijn collega het daar afgekeken heeft.

[ Voor 8% gewijzigd door PdeBie op 12-11-2013 08:35 ]

[HuHu]

Ik vind een enter geen 1 of 50 tekens, maar 0 tekens. Je ziet hem niet en als je het kaartje uitprint neemt het ook geen ruimte in beslag.

Als je zegt dat er 50 tekens op een regel kunnen en enter is een teken, dan kunnen er dus maar 49 op een regel? Een enter als een teken tellen gaat je bezoekers echt verwarren.

Waarom laat je überhaupt zien hoeveel tekens/regels een gebruiker heeft? De kaartjes hebben toch een grootte van x bij y centimeter? Het feit dat daar 250 tekens in kunnen is niet boeiend, mensen gaan hun tekst echt niet natellen. Maak gewoon een textarea waar exact 5 x 50 tekens in passen en zorg dat mensen daar niet meer in kwijt kunnen.

edit:

HTML:

<textarea rows="5" cols="49" maxlength="250" wrap="hard">dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd</textarea>

Dit dus. Ik zou geen tellertje tonen.

[ Voor 22% gewijzigd door HuHu op 12-11-2013 09:01 ]

[PdeBie]

Je zal de enter ook moeten opslaan in de database om dezelfde structuur te behouden als de invoer van de gebruiker. Dus lijkt mij dat je de enter ook mee moet tellen.

En dan zit je nog met het feit dat je nog het aantal rijen moet tellen/limiteren. Die invoer moet ik dus ook nog zien te limiteren op een of andere manier.

--edit--
ik zal eens iets proberen te maken in jsFiddle. Dan kunnen we het eens bekijken aan de hand van code voorbeelden.

--edit--

Zie deze Fiddle:
http://jsfiddle.net/s6LkD/

Je ziet dat de enters ook als 1 karakter geteld worden door de code in javascript.
Voer maar eens in:

code:

12345<enter>

Je zal zien dat de teller op 6 staat in plaats van 5.

Verder komt het 'wrap' attribuut volgens mij uit HTML5. Aangezien wij gebruikers op IE8 hebben, zal hier ook nog een oplossing voor bedacht moeten worden.

[ Voor 46% gewijzigd door PdeBie op 12-11-2013 09:41 ]

[418O2]

Ik zou gewoon echt 5 input regels maken. Dan is het ook veel makkelijker om een voorbeeldje te laten zien. Dit gaat echt veel geklooi opleveren gok ik.

[R4gnax]

pdebie schreef op dinsdag 12 november 2013 @ 08:32:

Mijn collega wilt echter dat als je op enter drukt de teller tot 50 bij het totaal aantal tekens optelt, zodat je ziet dat je nog maar 50 tekens minder hebt.

Da's op zich niet eens zo'n gekke suggestie. Ik had een beetje tijd te doden, dus kijk eens of je collega dit iets vindt, zou ik zeggen.

[PdeBie]

Ah bedankt!

Ik zie zelf al wel wat eigenaardigheden in je voorbeeld, maar het is een begin. Ik zal het hem eens laten zien.

[HuHu]

pdebie schreef op dinsdag 12 november 2013 @ 09:10:
Je zal de enter ook moeten opslaan in de database om dezelfde structuur te behouden als de invoer van de gebruiker. Dus lijkt mij dat je de enter ook mee moet tellen.

En dan zit je nog met het feit dat je nog het aantal rijen moet tellen/limiteren. Die invoer moet ik dus ook nog zien te limiteren op een of andere manier.

--edit--
ik zal eens iets proberen te maken in jsFiddle. Dan kunnen we het eens bekijken aan de hand van code voorbeelden.

--edit--

Zie deze Fiddle:
http://jsfiddle.net/s6LkD/

Je ziet dat de enters ook als 1 karakter geteld worden door de code in javascript.
Voer maar eens in:

code:

12345<enter>

Je zal zien dat de teller op 6 staat in plaats van 5.

Verder komt het 'wrap' attribuut volgens mij uit HTML5. Aangezien wij gebruikers op IE8 hebben, zal hier ook nog een oplossing voor bedacht moeten worden.

Wat heeft de gebruiker er mee te maken dat databaseopslag en programmeertalen <enter> als een karakter zien? Misschien is een <enter> wel \r\n en heb je twee karkaters?

Als er op het geprinte kaartje ruimte is voor 250 tekens, met 5 regels en 50 tekens per regel, dan laat je dat aan de gebruiker zien. En niet dat er stiekem plaats is voor 254 tekens, want je mag ook nog 4x op <enter> drukken.

[R4gnax]

pdebie schreef op dinsdag 12 november 2013 @ 13:54:
Ah bedankt!

Ik zie zelf al wel wat eigenaardigheden in je voorbeeld, maar het is een begin. Ik zal het hem eens laten zien.

Ja; de manier waarop linewrap mogelijkheden opgezocht worden is nog niet echt ideaal en de manier waarop woorden afgekapt worden die op zichzelf langer dan de toegestande regellengte zijn is ook niet helemaal super. Daar moet je alleen even doorheen prikken voor een concept van aanpak, denk ik. Dat kan altijd nog verfijnd worden.

Hopelijk kun je er wat ideetjes uit halen.

HuHu schreef op dinsdag 12 november 2013 @ 13:57:
Misschien is een <enter> wel \r\n en heb je twee karkaters?

... Dat is het in IE in de context van een <textarea> element ook.

[PdeBie]

Inmiddels dit punt hier nogmaals aan de kaak gesteld en alles nog eens herzien.
Het afvangen van aantal regels etc. blijft een lastige kwestie, zeker gezien het feit dat elke browser er weer anders mee om gaat.

Ik ben benieuwd wat ze besluiten hoe ze het nu willen hebben. Zal me niets verbazen als ze ineens besluiten om het alsnog helemaal anders te doen. Na al dit gedoe hier op kantoor heb ik nu zelf zoiets van: je voert het maar in zoals je wilt en als je ziet bij het afdrukken dat het niet past, pas je het maar aan en druk je het opnieuw af. Ze hebben zelfs een print-preview, dus daar zouden ze het al op kunnen controleren. Dan maar iets minder robuuste validatie er omheen.

Ik vraag me ook echt af hoe vaak het nu fout gaat. Dat kon mijn collega me niet zeggen.
Volgens mij gaat het namelijk over het algemeen gewoon goed en zijn we al deze moeilijke horden aan het nemen voor een enkele order waar het mis in gaat.

Maar afijn, ik wacht wel af wat ze hier besluiten.

[418O2]

doe nou maar gewoon 5 losse inputs erdoor drukken. Is gewoon echt het veiligst.

[R4gnax]

418O2 schreef op woensdag 13 november 2013 @ 16:34:
doe nou maar gewoon 5 losse inputs erdoor drukken. Is gewoon echt het veiligst.

En het minst bruikbaar. Wat denk je van prefab tekst inplakken om op een label te zetten?