SnTT - Wizards and magic...
Bookmark :
If 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 ?
In 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).
You 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
Posted by Jens At 22:58:09 On 30/03/2006 | - Website - |
Posted by Jerry Glover At 08:05:28 On 31/03/2006 | - Website - |
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
Posted by Wild Bill At 08:51:21 On 31/03/2006 | - Website - |
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
Posted by Wild Bill At 08:56:10 On 31/03/2006 | - Website - |
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!
Posted by Richard Sampson At 10:12:08 On 31/03/2006 | - Website - |
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.
Posted by Jerry Glover At 16:57:37 On 31/03/2006 | - Website - |
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
Posted by Matt At 08:50:29 On 01/04/2006 | - Website - |
@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
Posted by Wild Bill At 10:20:19 On 02/04/2006 | - Website - |