In follow-up to my post from the other day, I thought I'd pose the following question via Twitter:

Lotus Notes Client design question: Do you still use Framesets in your Application UI?

The response from both Twitter and the various other social networking sites prompted me to create a quick MicroPoll:

Now, understandably, this is a pretty wide-open alternative with Frameset vs. 'Web', but I have this idea...

Look at the more successful cloud service solutions out there today. You're presented with - in most cases - a 3-column fixed layout with highly-stylized UI interaction with various functional nodes. Navigation to top-sections is fairly basic, with in-content drill-down options to specific content or functional sections.

This should be fairly simple to re-create within a Lotus Notes Client application without the *[conventional] use of Frameset Design Elements.

* - Have to give myself an out if there comes a situation where I'll need to use a Frameset in some unconventional ways.

And I know this won't be possible for every application-type within the Lotus Notes Client, as certain applications have certain user experience expectations... which begs the questions for those of you who might answer "We have a corporate standard UI": maybe that's a bad thing in some cases?

So I thought I had it - my dashboard application was complete. I had actually stolen implemented the technique used by NTF - an ultra-slick hack to allow embedding a frameset into a form, but in doing so I find myself yet again at an impass...

My original architecture of this "dashboard"-style solution was simple enough - embedded views on a form that contained fields that were used as categories for the various embedded views. The problem with that, there was no user-configuration capabilities to allow them to add their own views to their dashboard. So, we move onwards...

Using Nathan's solution, I was able to easily design a user-configurable dashboard application - exactly what I needed... with one glaring exception - I couldn't display sub-categories of documents in the embedded frameset-based views. It again seems to be a matter of focus, as I have to rely on @SetViewInfo (unless someone has a better idea) to create a sub-category filter for the given view.

I even thought that I had gotten around this by (despite NOT wanting to do this) adding the @SetViewInfo in the PostOpen event of the the View I'm openning itself... but the @SetViewInfo seems to want to trigger, as far as I can tell, on the Form element instead of the actual View itself.

So today, schedule willing, I'll venture back into the thick of it and see if I can't get a hack going for this... as soon as I get a working solution, I'll post it here. After all, you've been reading about this for the past few days... it's the least I can do!