Just a little teaser video showing you the Frameset-less Lotus Notes Client UI Design that I had mentioned a few weeks back.

It's not much, but it should give you an idea as to what I was getting at from a functional design standpoint. ;-)

More to come - as I mention in the video - as soon as I get some downtime to play around...

I've been - as several people suggested - following a Twitter keyword search for "Lotus Notes".

Note: I warn any yellowbleeder thinking of doing this - you will hear the most inane, hate-filled, and saddening complaints about Lotus Notes you've ever heard. Twitter - if anything - has given everyone creative license to air their grievances, and creates 140-character Internet Tough Guys.

Some complaints are valid, of course, but one in particular made me stop and think. Here's the exchange:

In training for lotus notes 8.5. Now it sucks *and* uses all your ram!

My response:

curious - and not trolling - what don't you like about Lotus Notes?

And their responses:

it's slow, uses strange non-standard ui for no reason, and I've never used an app with a more cluttered interface

it's all about the ui. its 2009. Don't give me a 1994 interface! I'm used to macs and iPhones!

This got me thinking... How should we be developing our Lotus Notes Client applications? I understand the move to Web 2.0-UIs for Domino Web Applications, but the vast majority of Lotus Notes Client Applications have a similar basic layout:

Left-hand navigation, top-row action menu, and a NotesView pane where all of the action is. NotesDocuments are often modified via Open in New Tab, ModeChange to Edit Mode, Save and Close. Some Notes Client Applications allow for multi-NotesDocument processing via gutter selection, clicking an action from the View Design Element's Action Bar, and finally refreshing the NotesUIView.

Is this wrong? Wait... that's not fair. Does this meet the user experience expectations set by the majority of today's consumer-facing, popular, and heavily-adopted solutions?

I guess my real question is this: If you were not restricted by limitations of the given client, how would you design your application user interfaces?

Jo Grant pulls off a great 2:47 minute YouTube screencast showing us just how easy it is to wire a component action in Lotus Notes 8.5.

IBM Lotus Notes 8.5 adds Live Text integration to composite applications. This allows an application assembler using the Composite Application Editor (CAE) to associate a Live Text Content Type to a component's action. Once configured, Live Text recognized in a document can be sent to a component action using the familiar Live Text UI. This video shows you the process of doing that.

Simple, quick, and shows the product! If you're not already subscribed to Jo's YouTube channel, I'd suggest you check it out... especially if you like great quick-bite showcases of IBM/Lotus technologies!

So we have the basics of the Events Calendar established, so we quickly get started on the next phase of the build: technology and UI/visual considerations.

Again, we'll be staying away from the Domino Designer client, as this phase is more about research and making sure that you're bringing the right tools to the jobsite.

Quickly reviewing what we already know:

• Event Admins want to control the posted events in the Lotus Notes client.
• Attendees - since this includes warehouse staff and other "user will be using a walk-up kiosk" usage scenarios - will be viewing the Events Calendar and creating reservations via a Web Browser client.
• Event Coordinators will be using the event and reservation info to schedule Meetings in a shared Mail Database - which will do the Calendaring & Scheduling heavy lifting for us.

So we absolutely know that we will have a Lotus Notes client UI to handle event management, Internet Explorer (their corporate browser of choice) to handle the walk-up kiosks, and we'll want to build a data "fetcher" in the shared Mail Database. After chatting with the project champion, we've come up with the following:

The Event Admin will open the Events Calendar from the Lotus Notes client, and select "New Event". They will be presented with a wizard, asking them information about the event, including start and end date and times, repeat controls that will generate multi-day events, and the location/venue. When they click "Generate Event" - which is the final step in the wizard - the event NotesDocuments will be created in the EC NotesDatabase. From there, the Event Admin can modify individual event NotesDocuments from both a flat meetings-type NotesView or a calendar-type NotesView.

The Attendee will open EC from the Web Browser client, and see an Events Calendar user interface displaying meetings. They can open a meeting for more information, and simply click a "Reserve your spot!" button, which will create a response reservation NotesDocument to the given event NotesDocument.

The Event Coordinator will - when creating a scheduled meeting for a particular event - click on a new button on the Appointment Form Design Element, which will prompt them to select an event from a list of those for which a scheduled meeting has yet to be created. Once selected, the location, title, description, date, time, and even reservation information will be pulled in from the selected event and used to populate their corresponding field in the scheduled meeting entry. From there, the Event Coordinator will manage the event like any other calendar entry - allowing Attendees to accept the invites and book out their own time.

The Lotus Notes client stuff is pretty simple here - calendar-style NotesViews are easy to create, and the step-by-step wizard is already done. I'll be jumpstarting the Notes Client UI development with my No-View NotesDocument Lookups, UNID Logic, and Environment Variables - Example Application. Modification of the Appointment will be pretty simple too.

So we're onto the web technologies that we'll use to render our calendar UI.

With every JS toolkit out there having their own calendar UI, you've got some options. Now, if you talked to me a year ago, I would have told you to pick your own poison and go nuts. However, with the inclusion and heavy usage of Dojo in Domino 8.5 - specifically with XPages - if you're planning on keeping this application in Domino (which we are), I can't recommend anything but Dojo for this... as you can move away from using (what will be) a Dojo library NotesDatabase and onto the Dojo libraries that magically show up when you upgrade your Domino servers to 8.5 (possibly with some tweaks, but you're still moving forward!).

Thankfully we can stand on the shoulders of giants for this one, as Victor Krantz wrote Creating a Dojo Calendar way back in March 2007!

So, we have our plan. We've gotten sign-off from the customer that the application that we've presented to them - via a lot of whiteboard sketching, usage scenario write-ups, and other up-front work - is the one that they wanted in the first place... and we're finally ready for the build.

... which is coming up in the next post!

My current 40+ Hours/Week Customer happens to be a larger and globally dispersed Notes Shop. In my going-on-two-years with this customer, I have yet to have a project where one of the requirements were multilingual user interfaces for a given Lotus Notes or Domino Application. Now, there are applications that span multiple countries and regions... but we've always just gone with English-based UIs.

So... do you have to deal with supporting multiple languages in your Lotus Notes and/or Domino Applications? If so, what is your preferred method?

I'll share mine once/if we get a few answers, and you can leave your answer in the comments section - but I'll give you a quick preview:

For Lotus Notes Client Applications:

For Forms this is easy - a simple hidden field that renders a key:translation paired list of all defined translations. Then, each UI component does a lookup to that field and renders the translation.

The problem I've run into in the past is Views - specifically View Columns...

For Domino / Browser Client Applications:

I tend to "roll my own", so this really isn't a problem. Forms are handled the same way, as are Views: I typically have my markup View tables render without headers and footers, which I add via Computed Subform logic in the ViewTemplate for my particular View.

I will elaborate more on this in the follow-up article...