« FirM wins Lotus Advisor 2006 Editors Choice award for Admnistration Tooling! | Main| So why do people spend lots of money on Unix Servers ? »

SnTT - Wizards and magic...

Category None
Bookmark : del.icio.us  Technorati  Digg This  Add To Furl  Add To YahooMyWeb  Add To Reddit  Add To NewsVine 

hootsThursday_BLU.jpgIf you've been following my blog in the last few weeks, you'll have seen that I've not been updating it as much as I could - its been busy around here. Its starting to get back to "sane" now, so its now time for my much overdue SNTT for this week.

A common complaint about Notes applications is that they look like - well - Notes applications. A lot of folks like writing web-based notes applications because the "notes" look and feel can be hidden...

Now - in our product we've tried hard to at least give the user a slightly better user experience than just a Notes v3 standard form - you know the ones. The ones that have been in our faces for 10+ years, and look horrible by todays standards. Green Text, yellow background, seven fonts, and a road accident of text all over the place. (Actually, I'll be careful here and not name and shame really ugly commercial Notes applications at this point..)

How do you make Notes applications better ? One technique that we like to use is something called "Progressive Disclosure" - you give the end-user a simple series of choices, and based on the decision tree, ask them for little pieces of information at a time. So the users are prompted for few fields in a clear consise manner.

This isnt a new technique of course - most folks call them "wizards". Folks have told us that our UI is good, so we must be doing something right. (There's an animated GIF below showing this in action, and we have various video's on our site. So how to easily do Wizards in Notes ?

table-rows.jpgIn version six five, there was a new table property - "show only one row at a time". It displays in a tabbed table - the names along the top. You can then set "Switch Rows Programmatically" and then have it use a fieldname to decide which table row to display. This means that the "name" of the tab is no longer visible. (You have to futz with the "also show tabs so user can pick them" to SET the "name" of the table row, and then deselect it to hide the tabs again.). As you can see on the right, I've got a table just behind that properties box, and the tab names have been set to "1", "2" and so on. (You dont have to use descriptive names - the user never sees them).

table-field.jpgYou then define in the table properties the "name" of the table, and then create a field starting with a dollar sign, followed by that name. You set the field to the value you want, and it opens the correct table row, and the user sees what you want him to see. As you can see, I've called our table "Request" and so need a field called "$Request".

Lastly, you then in lotusscript:

  • Create a temporary notes document
  • Set the table name "field" to the correct row name
  • Use "NotesUiWorkplace.DialogBox" to display the temporary document using our form - and set the "only display the table."
  • Each time the user presses forward and back, the form "closes", your back end code decides what to do next, and then reopens the form.. For example, our wizard "forward" button sets a status flag - "direction=forward" and then closes the screen. The business logic then decides what button press happens (based on the value in the temporary document) and displays the next page, etc.

Now there's a few advantages to doing this

  • The user does NOT have to see all the possible wizards screens. For instance, when our user in our application decides to create a new user, the business logic looks up a view to decide how many "profiles" that the user can choose from. If he is only allowed to see one profile, then we dont prompt the user - we just choose it and move on.
  • You do NOT have to end up putting horrible business logic on the form itself - since your only using the form to collect data. So no extensive @formula validation stuff in the fields - you can collect the whole data set. This is an important point. The code that displays the form need not be in the form itself. Ours is based on Object Oriented lotusscript libraries, etc. So the business logic is separated from the presentation layer. Another good example is the transition on the user create wizard from the "please enter the names" to the "submit" page. We can do all sorts of really complex business logic in our back-end code, and not litter that all over the form itself.
  • The user thinks its a lot easier..
  • Did I mention that once you understand this, its a lot easier to write good code and then re-use most of that code with this technique? Yup. Simple, easy, looks good and saves you hassle.

How do you make your Notes applications look good ?

Technorati Tags: Show-n-Tell Thursday, Lotus Notes, SnTT

Comments

Gravatar Image1 - Thanks for that, thats a nice technique. Have done that, for me that did not start in Notes, but in VBA, but there is basically no difference.

Gravatar Image2 - I'm curious why, since you're using dialogbox anyway, you don't just switch the dialogbox display form on each load to the appropriate one rather than going to the trouble of setting up the programatic table. Seems to me multi-forms would be simpler.

Gravatar Image3 - Good question Jerry, and of course one I didnt discuss. Why use a multi-tabbed table and not just a new form for each part of the wizard ?

In our environment, we have 19 user transactions, 4 group, 9 Active directory, 3 application and 6 blackberry ones. As well as an Installer, and three importers. Thats 44 separate wizards. And most of those have 4-6 "panes" each. So thats between 176 and 264 separate wizard panes. We have 44 "forms" instead of say 200+ forms.

So very quickly this method helps scalability, and also helps you within the wizard, as a specific user scenario may well rely on form information that they typed in on a previous pane.

So each "wizard" is a separate form in our case, and each wizard "pane" is a separate row in a table.

So the short answer is scalability and convenience. Its also easier to programmatically perform - one piece of back-end code per wizard, that gets loaded with the correct form, etc, etc.

Remember - a good developer is essentially a lazy creature - always trying to leverage the technology to reduce the amount of work. In this case, the addition of a tabbed table and some logic saves a *lot* of separate forms - all of which require to be maintained, etc.

(And in fact we use the age-old notes "subform" to add standard logo headers, and button footers to each wizard form - so the amount of work consists of "copy, rename form, change wizard pane text and fields", etc.

Hope this answers this specific question...

---* Bill

Gravatar Image4 - Thomas Gumz - the IBMmer in charge of WebAdmin for Lotus Notes - dropped me a line and mentioned that he worked on an early version of the Lotus Notes Server install process for v5 that did exactly this - so this technique is at least SIX years old. Scary. eh ?

Apologies to Alan Lepowski and Thomas Gumz who were writing a piece on exactly this topic. Sorry we collided as opposed to colluded..

(There is no great SnTT committee as you can imagine, telling us all what to write. Can you imagine how hard *that* would be ? Herding cats and boxing frogs would be a walk in the park by comparison..)

---* Bill

Gravatar Image5 - Jerry@2

SwitchForm can be a valuable technique, but I think that this is in general a much better technique for a couple of reasons.

Firstly, although not clear from Bill's article, the tabbed table approach isn't limited to a uiworkspace.dialogbox approach - it works equally well for full-screen forms opened with just uiworkspace.editdocument. There will be a difference in code structure, but that's about it.

The second thing is that Bill is actually slightly incorrect about something (can't believe I've caught him out here!!) - the UI document does not actually need to be closed and reopened - simply refreshing it causes the table display to switch.

This means that you do not get the annoying screen redraw "flicker" that can be associated with switching forms (unless, that is, you put a graphic background or a gradient on your table cells... this may have been resolved in R65 & R7 but could be pretty awful in earlier versions).

As Bill has pointed out in his reply, it's also a pretty good way to ensure that all your form design and code for a particular dialog/wizard is kept in one place - the alternative is to formulate a strict naming convention for each dialog and it's pages so that you can keep them together. Fields common to all don't need to be subform'd or duplicated.

If you also wrapper all of the switching code and business logic for the process in one class or library then you also don't need to worry about maintaining the form events for each individual screen.

Finally, saving the status of the dialog/wizard becomes easier, because you don't need to worry about the switched form overwriting the Form field on the underlying document.

I appreciate that all of the latter points can be mitigated by strict design and implementation of the code/forms, but for me the lack of UI reload flicker and the ability to keep all the screens in one form are the key points.

It also makes UI alignment of items much more straightforward - just clicking through the tabs on the table shows you whether the text/field alignment is consistent or not, rather than having to click through different design elements & worrying about whether they're all scrolled to a uniform position.

In summary, I recommend this Bill to the house!

Gravatar Image6 - Of course I assumed use of subforms to keep standard look and feel across the forms (whether using forms or tabs). I didn't realize the shear number of wizards you were dealing with and certainly understand why you went the way you did. I only brought up the switching forms since Bill had mentioned the dialogbox method.

I like the programatic table function (with tabs) and something I've done with it is to implement a preference for a starting tab in a deep navigation UI. The Nav pane had 3 tabs of choices (Outlines on each) and users could set a preference for which tab to start on. This was handled simply by having the table control field do @getProfileField to their preferences.

Additionally, I've had functional role-based selection (@userroles) of that sort of navigation tab, or for a data tab corresponding to the particular role in a large workflow document. So, trust me, I wasn't knocking your usage in any way, just curious about the decision making process/inputs.

Gravatar Image7 - It's a good technique this - I've used it in the past, but I cribbed it from one of the out-the-box Notes templates. If you take a look in your events4.nsf database, you'll find a script library called Wizard - this is a base class for creating exactly the kind of apps that are mentioned here, plus some nice form examples (check out the event wizards)

Interesting little sidenote - if you trawl around the out-the-box templates, you can find some real gems of code (sorted and stack containers, for example), and you can also find some downright awful code (the rename resource agent in the resource reservations database springs to mind - every time I rename a resource I live in fear of the NO RESUME error message ) - it does seem as though IBM Lotus are slowly getting the hang of this whole LotusScript lark

Gravatar Image8 - @Jerry - of course every application development's direction should influence how you develop a particular technique. If there was only one wizard, I'm sure we would have dropped the dialog box constraint. "Horses for courses", to pick a random cliche out of the air....

@Matt - I tend to look upon the "out of the box" templates as a statement from Lotus as to what function is supported in what release. For instance, strLeft and strRight actually appeared in the mail template in R5, but wasnt documented till R6... And of course the @function registry stuff's been there for years... Handy resource, the out of the box templates.

Another useful approach is to use some of the techniques embedded in WebAdmin.ntf to automate some of the more exotic adminP processes...

---* Bill

Finalist's Site Marker 3.jpg

www.flickr.com
wildbillbuchan's photos More of wildbillbuchan's photos

News

Loading...

Quick Bill


I'm
- a Lotus Domino Dual PCLP - that is, a SysAdmin PCLP and an AppDev PCLP (or IBM Certified Advanced Application Developer and Advanced System Administrator) in nd7, v6, v5, v4 and v3.
- an IBM Certified System Administrator - Websphere Portal v5.0
- an IBM Certified Solutions Developer - Websphere Portal v5.0
- an IBM Certified Associate Developer - Websphere Studio v5
- an IBM Certified Solutions Expert - Websphere v4.0.
- a SUN Java 2 Certified Programmer
- a (probably lapsed now) Microsoft MCSE in Windows NT4.
- a (definately) lapsed now CLP in cc:Mail v2 and v6