I’ve got to post this. Not enough yet for an article, maybe later.
I’ve been learning a valuable lessons lately. The art of interfaces and processes. Where to put process, when to push it into the interface, how to create said interface?
When I put a button on an update window, let’s say it’s called ‘Send Email’, that is a Process. The process is held within an update window. To reach it, the User has to enter through a browse, or some kind of searching functionality, which really is a browse anyway.
Why should the User have to enter the update window to send the email? Well, the biggest reason is because that particular record doesnt’ have an email address field filled in. True. Okay.
But that’s like ONCE. What about the infinite next-times when the User wants to send an email?
These thoughts are new, and not nearly fully-formed .. but they are on the right track i believe. Of course, kudos to the brain that pushed me down this road.
Anyway. So we need to think of a intuitive interface. Functionality that cuts out any uneccessary steps. The most immediate thought is to implement a right-click popup menu on the browse, if it’s not already there. You know the one .. windows uses them extensively. They’re pretty good value.
Right-click, choose ‘Send Email’, and Bling, up pops an email window.
Now, I’ve missed a reason in here. I think there’s more to the Process/Interface argument than just "let’s move it out of this child screen onto the parent screen", although that’s a pretty big nice reason. Having process on the parent screen would probably eliminate errors that occur in update screens. Would relieve the update screen from a lot of logic, having to worry about things.
The more I go down this rabbit hole, the more questions arise. This brain doesn’t have the power at the moment. Gotta sleep. So more later. Posting this should be enough to keep it alive. Will think some more.