Oncalls version 1.5 is (finally) out to the beta testers. I wrote an article for a healthcare newspaper about it (yet to be published). They had asked for an article on the topic of physician scheduling .. in which I was encouraged to "mention" our product. So I did it. A little odd .. trying not to advertise, yet clearly (in <750 words) describe the problem we're trying to solve. I've done my best to keep the product focused on really defining a solution to a problem.
Some have noticed that the problem of "on-call" management isn't unique to healthcare. Who else shares call?
- TEHNOLOGY SUPPORT WORKERS
- 7-11 WORKERS
- FIREFIGHTERS
- NURSES
- POLICE
- YOU?
Oncall solves several real-life problems. It wasn't developed as a solution looking for a problem. Real humans had real problems.
- Making the schedule is challenging
- It's hard to keep track of who has asked for a day off .. and when.
- People always argue about who'se done more weekends than whom
- There needs to be ONE schedule of who is on when. Faxed copies or paper versions on bulliten boards get out-of-date too quickly. One authoritative schedule has to live in one place, accessible to everyone.
Our software does not automatically create the schedule for you. Someday it will be able to, and I'm hoping that this will be soon. This is not the most challenging part of making the call schedule .. nor have our users been calling for it. Our strong point is how we cahn share the information. Users can do a palm synch, or even hear the schedule (using Voice-XML) on the phone.. or see it on their web-enabled phone or palmpilot. There's a lot going on behind the scenes.
That's the point of good software design. Hard work behind the scenes makes it easier in front. As Joel and Jakob remind us, good usability is the key to success. We've worked hard to make this software usable .. and meet the expectations of the user — rather than make the user adaprt to the limitations of our programming.
