Re: preg_match() oddities and question [message #176140 is a reply to message #176139] |
Fri, 25 November 2011 22:23   |
Thomas 'PointedEars'
Messages: 701 Registered: October 2010
Karma:
|
Senior Member |
|
|
Sandman wrote:
> In article <1438797(dot)UceJUlZ0hu(at)PointedEars(dot)de>,
>> The kind of structured data that you need to enter in a form does not
>> matter. Using cursor keys to move the text cursor between delimiters in
>> a running text always causes has more accessibility and usability
>> problems, and consequently information processing problems, than tabbing
>> (or otherwise moving the focus) from one control to another.
>
> Whatever gave you the idea that I am proposing a solution where the
> user would have to "use cursor keys to move the text cursor between
> delimiter in a running text"? I literally have no idea what you are
> talking about, and it has absolutely nothing to do with this thread.
I am imagining a visitor of your Web site entering "foo street 34" (perhaps
as part of a longer text; your next question about phone numbers indicates
just that). Seeing that the "34" needed to be "42" instead, they would tab
back, upon which the entire text field is usually selected, and they have to
press the End key (or Alt+Arrow Right on Macs, IIRC) to get to the end.
Then they would perhaps press the Backspace key twice and type "42" Or
perhaps they needed it to be "134", so they would perhaps press the Arrow
Left or Backspace key twice (or Ctrl/Compose+Left) before they could make
their edit. (It would be comparably tedious with a pointing device, so do
not get me started on that.)
Now, it would be so much easier for them to work with the form, and easier
for you to process the data they entered, if you had the street name and the
house number in separate controls. Then they would tab back to the house
number control, which text would be selected, and they could immediately fix
their mistake. In addition, you could set up access keys and labels for the
controls with pure HTML so that users can use either way to focus the
control they want to edit. This would work with a graphical browser, a text
browser, a screen reader etc. Lately, it would work best with a mobile
device (anyone who has experienced first-hand how tedious it is to position
the text cursor with a mobile device, especially with a touchscreen, knows
what I mean). You cannot do that with one control.
This is just a simple example, of course, but it shows rather clearly the
benefits associated with providing separate form controls for the components
of structured data. Another good example are separate inputs for the
components of a date where you can, regardless of date format and component
order in that date format, always be sure what is the date, the month, and
the year *as meant by the user*; it is also one instance where client-side
scripts can assist the user in entering data in several ways.
EOD here or, if you want to, F'up2 comp.infosystems.www.authoring.misc
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|