Your Development & Design Resource
Multi-Client Type Design Elements - Ya gotta keep'em separated!
02/26/2008 03:09 PM by Chris Toohey
Author's Note: I'm certain that I will hear about this from people who disagree - but that's what the comments are for I suppose...
I was actually on an interview a few years ago for a rather big-name product development company, when they brought in their lead developer to ask me a few technical questions. One of the things he asked me, was whether I developed common design elements or used individual (per Client Type) elements. In case I lost you there, do I have one Form design element for the Lotus Notes client, Web Browser client, and Mobile Device client types. In horror, I said "No - that's insanity. The only way you could pull that off is with hide-whens or subforms or something just as resource-consuming..."
His repsonse, which added shock to my horror, was that "[doing that] was [his] biggest pet-peeve" and that the products that they developed all had common Client Type design elements. He wanted to cut down on the maintenance of all of these design elements by having single design elements per all Client Types.
While such a thing can work - I don't recommend it. In fact, I'll be a little more stern with my suggestion: Don't do it!
An application that is delivered via both Lotus Notes client and Web Browser client has major environment and usage considerations. Creating multi-client applications (especially when you factor in the Mobile Device client type) requires both an understanding of the application (what it does, and how it's being used) as well as an understanding how the to-be-supported Client Types are going to work.
So, to recap.
Don't be an asshat Create seperate design
elements for your various supported Client Types whenever
possible - which should be all of the time.