FAQ Memberlist Usergroups Register Log in
Profile Log in to check your private messages Search

Rant: Programming Dates and Times

 
Post new topic   Reply to topic     Forum Index -> General Discussion
Author Message
Tinalles
Site Admin


Joined: 22 Mar 2008
Posts: 1630
Location: Grand Forks

PostPosted: Mon Feb 09, 2009 1:48 am    Post subject: Rant: Programming Dates and Times Reply with quote

Okay, this is going to be a rant about technical stuff having to do with web design. If you're not interested in poking through the guts of web sites to see how they work, I advise leaving now.
















I. Hate. DATES!

I'm writing a form that goes in a web page. What it's for isn't terribly important, but there are a couple of different places where you need to fill in a date for something -- like, "Needed By" and then you indicate a date in the future. Simple, straightforward, right?

HA!

HTML defines a fairly limited number of form input elements. You can have little text fields, big text areas, check boxes, radio buttons, drop-down select boxes, and (if you want) multiple select boxes. None of those are designed for dealing with date or time information.

The easiest solution, from a programmer's perspective, is to use a text field. Just have the end user of the form type the date in. They can do that, right? But then you have to deal with eight bazillion ways of entering dates. Here are some of the ways people might potentially enter the date of June 17th 2009:


  • June 17 2009
  • 17 June 2009
  • Jun 17 2009
  • 17 Jun 2009
  • 17/06/2009
  • 06/17/2009
  • 6/17/2009
  • 17/6/2009
  • 17-6-2009
  • 6-17-2009


... and all that doesn't even consider things like the day of the week, whether they add 'th' on the end, or internationalization issues. What do you do when some Copt comes to your page and tells you that he wants it by Amshir 19, 1725?

Unless you're a programmer of preternatural thoroughness, your program chokes, that's what!

So just a plain text field is NOT going to cut it. That means that you have to come up with some other way of doing it.

Great! So, how about this? We have a drop-down box where you can select the day of the month, another drop-down box for selecting the month (by full name), and then a drop-down box for picking the year. Hard to screw that up, eh?

But then you run into all kinds of issues. The months in our calendar have between 28 and 31 days each. If you put 31 days in the drop-box for picking the day, then that lets people specify imaginary dates like February 30th. And that means that you have to write code to make your program reject such imaginary dates.

A month drop-down box is pretty simple. But as for years -- they just keep coming, you know? So you have to write code to populate the list of years with every year starting from when the program was written and going on until .... untill .... until they stop using your program, and who knows how long that'll be? In the meantime, the select box gets longer every year.

But imagine that you've worked out the details, and it's going to work for the foreseeable future. Right? Well, then you have to start worrying about accessibility and usability issues.

Using three drop-down boxes is not terribly hard. If you have your sight, that is. If you're blind and you have to listen to the cruddy things being read aloud by your computer, then it gets harder. It's terribly important to provide clear, unambiguous labels for every form input, labels that screen reading software can read aloud so blind people will know what's what.

But if those labels are visible in the document, then that decreases its usability for sighted people. They start wondering "Why does it always label those as day, month, and year, when it's perfectly obvious what they are from how they look?"

So maybe you work out how to hide the labels, say, by using CSS positioning to move them off the screen. The labels are present and read aloud for the blind, but neatly swept under the rug so they don't clutter up the page visually for everybody who can see. And all is well.

UNTIL .... you have TWO dates to deal with. Suppose that in addition to "Needed By," your form needs another date, "Archived On." Then you're right back at the labels-versus-clutter issue, because you have to provide some way of distinguishing the dates from each other for the blind. If you've got two drop-down boxes that are both labeled "Day," then there has to be some way for a blind person to tell which one pertains to "Needed By" and which one pertains to "Archived On". Ditto for the two Month and Year drop-down boxes. You could do it with a fieldset and legend combination, but doing that every time you need a date introduces a lot of visual clutter, which decreases usability, but not doing it decreases accessibility, and ....

ARRRRRGH!!!

When I think of the countless hours I have wasted writing programs to deal with just gathering dates and times, and never mind actually keeping track of them, it makes me want to hurl things at the wall, scream insults at passing strangers, scale the nearest skyscraper and fling alarm clocks onto the unsuspecting masses below!

Why, why didn't the W3C in its wisdom define a "date/time" picker in the specification for HTML? Then three or four different companies could have built it into the web browsers directly, and saved thousands or millions of hours of effort by web developers the world over. It makes me want to weep.

...

Okay, I think I've got that out of my system for the moment. And I've got an idea to solve the problem that inspired this particular rant.

I'll just go waste some more time on time, shall I?
_________________
Keeper of The Remnant Minuon (cognomen Lucy, the Eaten One) and the Emissary Caeli
Back to top
View user's profile Send private message
Squeeself



Joined: 23 Mar 2008
Posts: 258

PostPosted: Mon Feb 09, 2009 3:35 am    Post subject: Reply with quote

There's a reason that the variety of Javascript date pickers out there are a web programmers best friend....

And yes, there's a reason why everyone's working on HTML 5...cause the current HTML is incomplete and a decade old Razz
Back to top
View user's profile Send private message
Tinalles
Site Admin


Joined: 22 Mar 2008
Posts: 1630
Location: Grand Forks

PostPosted: Mon Feb 09, 2009 4:28 am    Post subject: Reply with quote

Yeah yeah -- have you ever run one of those JavaScript date pickers through a screen reader? I have. Just tonight, in fact, I looked at this one. It suffered from several problems. I put a full post at the bottom of the blog post I just linked, but, in brief:

1) A blind user wonít have any idea that the date picker is there.

2) If a blind user found it and activated it, they would hear several minutes of gibberish like "new: Tuesday, 3 slash VT pitch".

3) Once the date picker has loaded, itís fully possible to control it via keyboard. But there's no way for the blind visitor to know which keys do what. And anyway, changing it via keyboard generates no audible output. So, any blind user who manages to find the date picker, open it, and sit through the resulting welter of gibberish, is not actually going to be able to select a date using it.

If you know of one that works with screen readers, I'd love to hear about it!





As for HTML 5, well, I'm happy that they're working on it. Maybe in another two or three years they'll finish the specification. Maybe another two or three years after that, the various web browsers on the market will have implemented enough of those features that we can actually use them with reasonable certainty that they'll work. So, good long term effort, I approve, but it ain't gonna relieve my woe any time soon.


Edit: Oh, and while I'm at it, the Drupal Forms API is a pain in the butt. Making it generate forms which don't look like crap is tedious and irritating -- it makes way too many assumptions about how I ought to want my forms to look. The form I'm dealing with now has nearly fifty fields to deal with, and looks like complete !@#%$ if I let Drupal have its own way. >.<
_________________
Keeper of The Remnant Minuon (cognomen Lucy, the Eaten One) and the Emissary Caeli
Back to top
View user's profile Send private message
Nem



Joined: 14 Apr 2008
Posts: 2141
Location: England

PostPosted: Mon Feb 09, 2009 5:02 am    Post subject: Re: Rant: Programming Dates and Times Reply with quote

Why don't you just ask them how many days they'd like it in? Then you can take the gregcalendar utility and add the days to it.

Tinalles wrote:
... and all that doesn't even consider things like the day of the week, whether they add 'th' on the end, or internationalization issues. What do you do when some Copt comes to your page and tells you that he wants it by Amshir 19, 1725?

Unless you're a programmer of preternatural thoroughness, your program chokes, that's what!


Illegal data type Razz the program just wipes the field and tells you to do it in the normal callendar.
_________________
Never forget,
We stroll along the roof of hell
Gazing at flowers.
- Issa
Back to top
View user's profile Send private message MSN Messenger
Squeeself



Joined: 23 Mar 2008
Posts: 258

PostPosted: Mon Feb 09, 2009 5:29 am    Post subject: Reply with quote

Squee is pretty positive there's a calendar widget out there that's nice with screen readers...Squee remembers finding one back in the day for use on something that never ended up happening.
Back to top
View user's profile Send private message
Tinalles
Site Admin


Joined: 22 Mar 2008
Posts: 1630
Location: Grand Forks

PostPosted: Mon Feb 09, 2009 5:34 am    Post subject: Reply with quote

I'm inclined to think that asking how many days they need it in will force them to start doing arithmetic in their heads -- a clear violation of Krug's First Law of Usability. Also, it wouldn't work for the other two dates I need to track (date archived, date original item returned).

It's an interesting suggestion, though.

And I know you'd just handle the coptic date as an error, on the theory that it's way too much trouble to try and write a program capable of recognizing every date convention from every calendrical system in the entire world. It was just an example. :-ř

I think I've settled on using a fieldset with an appropriate legend and hoping people can figure it out. I just hate spending so much time on the task -- just this weekend I've spent nearly 19 hours on just one form, when I've got a bazillion other things to do on the project.
_________________
Keeper of The Remnant Minuon (cognomen Lucy, the Eaten One) and the Emissary Caeli
Back to top
View user's profile Send private message
Nem



Joined: 14 Apr 2008
Posts: 2141
Location: England

PostPosted: Mon Feb 09, 2009 6:49 am    Post subject: Reply with quote

Maths is good for them, it will make them feel better about all those years spent at school studying the stuff. Twisted Evil

Dang you Tin, now I feel the urge to go program something again. >_<

You could just make the text you want the screenreader to read the same colour as the background I supposed. :-/
_________________
Never forget,
We stroll along the roof of hell
Gazing at flowers.
- Issa
Back to top
View user's profile Send private message MSN Messenger
Tinalles
Site Admin


Joined: 22 Mar 2008
Posts: 1630
Location: Grand Forks

PostPosted: Mon Feb 09, 2009 7:57 am    Post subject: Reply with quote

Hiding text from sighted users so that screen readers can still access it is easy. Thus:

Code:

CSS:
.hidden { position: absolute; left: -999em; }

HTML:
<span class="hidden">Extra info for screen readers, hidden from visual rendering.</span>


The basic accessibility problem I'm facing is more to do with encoding information about the structure of the document in such a way that screen readers can access it. In each of the date picking things, I've got three separate select boxes:

- Day
- Month
- Year

Each of those has to be labeled individually. That's easy, here's a sample:

Code:
<label for="edit-archive-year">Year</label>
<select id="edit-archive-year">
  <option value="2008">2008</option>
  <option value="2009">2009</option>
</select>


The ID on the select box gives it a unique identifier within the scope of the document. Then the "for" attribute on the label refers to that identifier, saying "this label is for edit-archive-year." Explicitly creating that association between the form element and its label means that screen readers never have to guess as to which label goes with which form element -- they always know, and speak the correct label aloud when a blind user encounters the form element.

The problem is that all three of the form elements as a group need a label, too. Although they're all separate elements within the form, they're also logically part and parcel of a larger unit (the date as a whole). And I need to make sure, in a document containing multiple dates, that people can tell which date elements are grouped together. For example, the three archive select boxes need to be labeled "Archive Date", and it needs to be done in such a way that the association between the label and the select boxes remains retrievable on demand by screen reading software.

Unfortunately, you can't assign more than one label to any one form input. Or rather, you can write HTML code that will appear to do it:

Code:
<label for="edit-archive-year">Archive Date</label>
<label for="edit-archive-year">Year</label>
<select id="edit-archive-year">
  <option value="2008">2008</option>
  <option value="2009">2009</option>
</select>


... but screen readers won't actually read both labels if you try that. Usually the pick one and ignore the other.

HTML also offers the ability to group logically connected sets of form elements using a fieldset. Like this:

Code:
<fieldset>
<legend>Archive Date</legend>

<label for="edit-archive-day">Day</label>
<select id="edit-archive-day">
  <option value="1">1</option>
  ...
  <option value="31">31</option>
</select>

<label for="edit-archive-month">Month</label>
<select id="edit-archive-month">
  <option value="1">January</option>
  ...
  <option value="12">December</option>
</select>

<label for="edit-archive-year">Year</label>
<select id="edit-archive-year">
  <option value="2008">2008</option>
  <option value="2009">2009</option>
</select>

</fieldset>


... and screen readers are able to extract that information on demand. A screen reader would read this as:

Quote:
Fieldset: Archive Date.

Select Box: Day. The select box is set to 1.

Select Box: Month. The select box is set to January.

Select box: Year. The select box is set to 2008.


So, that works great for screen reader users.

But screen reader users constitute a vanishingly small percentage of the overall population. The default visual appearance of the fieldsets was designed with the assumption that there would be large numbers of related fields within one, and only a very few fieldsets present in any given form. Using one every single time I need to have somebody fill in a date really clutters up a form fast. I want to keep the visual appearance of the form as clean, simple, and uncluttered as possible.

I can do a lot of reformatting with CSS, but it's fiendishly difficult to get form elements to line up regularly while keeping the HTML as clean and accessible as possible. The inadequate labeling conventions for form elements, combined with the lack of a language specifically designed to handle web page layout pits accessibility for blind users against usability for sighted users.

It shouldn't be this way. Often it isn't, in fact -- in many cases, changes made for accessibility reasons wind up being helpful to everyone else, too. Think of all those curb cuts with slanted ramps at the corners of streets. They were initially installed for wheelchair users, but they're also handy for people pushing strollers, or carts full of boxes, or anyone on rollerblades or skateboards.

But in this case, it is that way -- no matter which I pick, serving one group of users is going to mean compromising the quality of service for another group, and it drives me nuts. I care about supporting blind users as a matter of principle, and as a memorial to a wonderful teacher I TA'ed for, who was blind and died of cancer last spring. I hate having to compromise the form's accessibility to the blind in order to make it more easily usable by the sighted. But basically, the particular people who I know for sure are going to be using this all have their sight, and so I'm going to have to sacrifice principle for expediency. And then I'll wind up agonizing about it for days.

And all because the W3C didn't think to add date or time pickers as default form types ten years ago when they were hashing out the current version of the HTML standard. BAH.
_________________
Keeper of The Remnant Minuon (cognomen Lucy, the Eaten One) and the Emissary Caeli
Back to top
View user's profile Send private message
Squeeself



Joined: 23 Mar 2008
Posts: 258

PostPosted: Wed Feb 11, 2009 12:58 am    Post subject: Reply with quote

Squee honestly doesn't see why using a fieldset is all that bad....seems like a fairly simple solution to Squee.
Back to top
View user's profile Send private message
Tinalles
Site Admin


Joined: 22 Mar 2008
Posts: 1630
Location: Grand Forks

PostPosted: Wed Feb 11, 2009 2:16 pm    Post subject: Reply with quote

It's not so bad, really. I'm just a wild-eyed perfectionist.
_________________
Keeper of The Remnant Minuon (cognomen Lucy, the Eaten One) and the Emissary Caeli
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> General Discussion All times are GMT - 4 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum



Elveron phpBB theme/template by Ulf Frisk and Michael Schaeffer
Copyright © Ulf Frisk, Michael Schaeffer 2004


Powered by phpBB © 2001, 2002 phpBB Group