The Darktimer is designed to have multiple sequential timers, so particular attention was paid to making a simple UI so that entering, editing and deleting timers would be straightforward. The use of a 16x2 LCD makes this simpler, since it can spell out instructions as necessary.
The UI was also designed to facilitate usage in the dark: it has one Big Red Button (referred to as GO in the documentation and code) to make the next timer go, and three smaller buttons (NEXT, + and -). Hit the GO button to start the timer. Once it's finished, the next timer is armed and ready to fire on the next press of GO. Hit GO by mistake? Hit NEXT to pause, and NEXT again to reset that timer.
Because this was never designed to be a super-accurate timer, it makes use of the CPU clock (via TIMER1) to keep track of time. The maximum time for a timer is 99 minutes and 59 seconds, which should still come in with reasonable accuracy, and avoids having to add an RTC.
The LCD I'll be using is a cheap-as-possible 16x2 from MPJA. I think it cost $1.95, as did my BRB, and the other three pushbuttons were even cheaper. The lack of a backlight keeps the price down, and the whole project can be built for about $30, or less if you have a reasonably stocked junkbox.
The code was developed using Test-Driven Development, mostly as an exercise for myself in TDD. The end result, though, is that the Darktimer is almost completely covered by tests down to the hardware interface, with all the benefits that entails. It also means that all the development thus far has been on a Linux machine, and each complete test run takes ~0.3 seconds to execute. Much faster than attempting to do the testing on the Arduino. Of course, this also means that the code was developed independent of the limits of an AVR, and it's possible (though unlikely) that it will require reworking to avoid resource constraints. Fortunately, being developed divorced from hardware also means that if the Arduino proves an infertile ground for the project, it can be moved to some other processor with relative ease. UPDATE: the compiled code only takes up 8k of program space, and the 328P has exactly the right number of hardware timers, so there are no concerns about resource limitations!
Finally, the beep coding system is kind of cool. A brief, high beep indicates a key press (good confirmation in the dark). A low brief beep indicates a one-second tick. A low, longer beep indicates a whole minute marker. A per-timer double-beep can be set to mark that N seconds have passed (think every 15 seconds, to help indicate when to start or stop agitating film). Then, the last 5 seconds get treble-beeps in a higher tone, and the final alarm is currently set at 5 short beeps in the higher tone. These were inspired in part by the WWV time broadcasts on 2.5, 5, 10, 15 and 20 MHz.