Your Development & Design Resource
BYOUI - Architecture for the mass adopters?
05/13/2008 10:41 AM by Chris Toohey
If the surge in both development and adoption of solutions like TwitNotes and the pick-your-poision Instant Messaging clients (GAIM/Pidgin, Trillian, etc.) have taught us anything, it's that people prefer to use their own or preferred entry point into community and collaborative solutions. But what's this mean for the Domino application development community? Well, it tells me that I really need to consider architecting my applications to facilitate BYOUI - or Bring Your Own UI. Now, for corporate applications, you may think that this doesn't apply... but I wholeheartedly disagree! I think that if you really look at it, you'll see just how truly limited the majority of our applications can appear.
Let's take Twitter.com for example. If you were limited to only the website itself to follow and update your and other tweets, how many people do you think would adopt such a thing? Now image if you could only have the reading capabilities, but you needed to log into the website in order to interact - slightly better, but I'll still pass thanks.
With the architecture initially designed to allow ANY chosen client to interact with near-full fidelity, they've given me no choice but to use their service and say thank you!
Now let's hop back into the corporate setting, and say that you have... a corporate travel requests solution. Now, that Lotus Notes client application has all of these do-dads and amazing things that get a person from their cubicle and onto that plane to parts-unknown, but what happens when they want to access that solution via the web? Simple right? We modify the current Design Elements (or the smarter of us create new client-specific Design Elements) and mirror the Lotus Notes client. Now you're cooking with gas!
And what about when the users demand access via their Blackberry? Kinda simple, right? More modifications and more design elements, ahoy!
What about implementation into Portal? What if you needed external travel vendors and agents to access this solution, but only for a subset of functionality? All things you're bound to run into to be honest...
Now imagine that they want a new button, a new function, a new feature - kiss your next month good-bye!
By architecting a solution to maintain it's content both separate from UI and Client Type, we can do away with a lot of that headache. Such a content management engine that is made available to the BYOUI crowd would require a Web Services (or like) mechanism to provide access to the data and functionality.
All this is fine and good, I'm certain that all of you agree... until you understand what that means for Lotus Notes Client Type applications that adopt this architecture. See, moving to a Web Services-like engine for data access goes against everything that IS Lotus Notes Development.
As Notes Developers, we modify "documents", not data. Data is stored in those documents, sure - but we're ultimately modifying an object that contains data.
And that was OK when all anyone ever wanted to do was modify "documents" in a Lotus Notes Client... but today, the demands are different. It's total BYOUI for the employee at home, why can't they work that way in the office?! We can adopt a different development methodology and deliver the same choices from Client Type to Subset of Functionality.... but it's gonna require a change to the way the majority of us think.
I'm babbling here a bit, but with good reason - I think I'm right here, or at least I'm onto something...