Guru: Make It Easy On Someone Else
August 20, 2018 Ted Holt
“Make it easy on yourself,” warbled Dionne Warwick when I was just a pup. That may be good advice when severing a romantic relationship, but not when programming computers. Instead of making it easy on ourselves, we who develop and support applications need to make it easy on the people we serve.
Recently I worked on a project in which users had to enter time values into various Web pages. The original specifications stated that users would enter time values in a format we commonly use in the United States: two-digit hour, a colon, two-digit minute, a space, and either AM or PM. For example:
10:30 PM
Something seemed wrong about this idea. It would be difficult for me to think of a more unwieldy data-entry format. There are too many opportunities for the user to key the value improperly. What if the user only keys one digit for the hour? What if the user omits the space after the minute?
This story contains code, which you can download here.
HTML supports a type=”time” attribute for the <input> tag, but it was not an option, I assume due to how that attribute behaves in certain browsers. Given the constraints, how could I make time entry as easy as possible for the people who would be using those Web pages?
I decided to write a routine that would allow the user:
- to key time in either 12-hour or 24-hour format
- to key hours and minutes only, or to key hours, minutes, and seconds
- to key a separator character or not
- to use a colon or period as the separator character
- to key a leading zero for one-digit hours or not
- to leave spaces or not
- to key AM or PM, or even more simply, A or P, in either upper- or lowercase
The user could key 8:30 AM and 2:30 PM in any of the following formats and more:
| 830 | 1430 |
| 8:30 | 14:30 |
| 8.30 | 14.30 |
| 830a | 230p |
| 0830am | 0230pm |
| 8:30am | 2:30pm |
| 8:30 A | 2:30 P |
| 8.30 AM | 2.30 PM |
Did it work? You’d better believe it! They liked it so much they changed the Web pages that they had already built to call the new routine.
I wrote the routine in RPG, then wrote a JavaScript version from the RPG version. Since I wrote the RPG version on my own time, you can have it. (See the downloadable code.)
I put the RPG source code into a single member, which you can compile as a program or module. If you compile it as a program, it will produce a report that shows each step it takes to interpret a time value. This is how I developed the routine. If you compile it into a module, you can create a service program to which other applications can bind. For completeness, I also added a subprocedure that you can call through an SQL interface.
By the way, some years ago, IT Jungle published a routine for entering date values in various formats. That article seems to have become a casualty of our move to WordPress. I will try to put my hands on it and republish it. After all, I may need that routine myself someday.
Think of your own shop. Whether you’re delivering modern browser-based applications or still using green screens, what’s causing the users consternation? What’s eating up their time? What can you do to make it easy for someone else?
Hi Ted, your article reminds me of times I would be writing or modifying some code (even my own and certainly back in my S/36 days) and I’d be testing it. After entering data a few times I’d realize I wouldn’t want to do this every day and would try to come up with a better/easier/faster way to do the data entry. I don’t often see developers looking at their code in the way you describe. They’re satisfied to just get it working. Sigh. All the best.
12:00 AM returns back noon and not the expected midnight. Modified the IF, where your checking if time needs to increase by 12, to correct this.
Thanks for letting me know, Lloyd. I fixed that code.