Knowing your date format and other small details

I had gone to  a local multiplex in Pune last week. To be precise the date was 3rd February 2010. I bought the ticket, confirmed the date even though the show was starting in 5 minutes (old habit) and found the date to be printed as 2/3/2010. For a second, I thought the date is 2nd March 2010 and soon I realized that the date was printed in ‘mm/dd/yyyy’ format.

Whats wrong ? Well, the standard for date format in India is ‘dd/mm/yyyy’ format. I am sure that the local multiplex had bought its Ticket Booking Management Application from a local software company. Even if the vendor was non-local, they should have considered the location of the customer before developing and deploying it for him.

I guess no one involved in the whole project found this bug.  Or maybe while making the use-case diagram, the designers forgot that the person buying the ticket is also an actor in the project, even though the ticket seller is operating the application. And what about the security guard or the usher tearing the ticket ? Are they aware of the date format ? Should they be considered while designing the application ?

There are some things which can help in development like knowing  who the end user is. If the developers have the end user in mind and codes accordingly, many small bugs get eliminated at the source. Rather than waiting for the Team Leader or the QC guys to report the bug, which the developer will then fix and report back, I think its better to sit once with the developers and give them a detail know-how about the end users of the application. Details could include age group, sex, geography, technical knowledge, regional standards (like the date format) etc.

It would also help to know the business operation or user scenarios. Like in this case, possible user scenario could be –  A persons goes to the ticket counter, requests for a ticket from the operator, the operator sells him the ticket, the buyer (person becomes a buyer now) goes to the screen, shows the ticket to the usher, the usher checks the ticket (date, time and seat no.) and shows him his seat. Then the movie starts and maybe one user scenario ends.


3 Responses to Knowing your date format and other small details

  1. Saurabh Shah says:

    I was thinking in terms of how to avoid all this use case scenario and location-based mess. How about using 3-letter abbreviations for months, instead of assigning numbers to months? For example, 2/Feb/2010 and Feb/2/2010 would never create confusion. To generalize the concept, wouldn’t it be beneficial if we choose “one size fits all” policies? Wouldn’t a common protocol / standardized stuff work better than fragmented localized stuff?

  2. Saurabh, Having a standard protocol might work. But the end user at large is familiar with entering and reading dates in numbers. Since school, we have been taught to write dates in 2/2/2010 instead of 2/Feb/2010 or 2nd Feb 2010.

    Hence even though the industry adopts a standard, it will be difficult to implement.

  3. Saurabh Shah says:

    I actually quite disagree that we’ve been taught that way. In fact I find it more convenient to write the date in terms of 2/Feb something on cheques etc. And prefer to read it that way as well. My mind has always been confused with numbers. To write August I actually had to count on my fingers, the number for the month, before I discovered that I don’t have to :)
    what’s user-friendly is more important than what’s taught.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: