Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

High standardsWe're collecting ideas here for Lotusphere presentations. I submitted six; we'll see what makes it through the approval process.

One of my proposed topics is, what every good Notes application should have. If it doesn't get approved, or maybe even if it does, I think I'll write an article or just blog about the specific items.

Here's my current list, off the top of my head; please chime in if I've missed something or if you think any of these is not worth the effort. I'm not saying that it's not worth creating an application if you don't have time to do all this stuff, but it's a list of features one should strongly consider. I'm not looking for suggestions for optimizing performance. What I want is a list of things to consider including in the user requirements.

  • F1 help that's specific to the screen you're in at the time (users should not have to see the "How to fill in a form" help screen).
  • Field help.
  • Alt text on images.
  • A sensible selection of default view design for new views and folders.
  • Personal default values using a personal profile document (the application remembers what the user entered in "Department" last time they filled in this form, and uses that as the default).
  • Tie-ins to other applications to avoid users having to enter data which is already known somewhere else.
  • A way to either resolve or prevent replication/save conflicts. Might be a tool for users, such as I blogged about recently, or turning on locking, or some sort of automated resolution, depending on the application.
  • Configuration screen for setting keyword lists, etcetera, using a profile document.
  • Error trapping and logging in all LotusScript and Java code; testing for errors in all formulas that might conceivably have one. Link to OpenLog project.
  • A way for users to easily report a problem with the application, which goes to someone whose responsibility it is to do something about it. A centralized support database would be ideal.
  • Combining the above two: all unexpected errors should result in the automatic generation of a trouble report to the centralized support database.
  • Assisted creation of local replicas, or if local replicas are not supported for this app, something to prevent their use.
  • Personalized views, preferably implemented in a way that does not require private views (e.g. using an embedded single-category view or @SetViewInfo).
  • Application-specific search assistant dialog.
  • (with version 8.0) The application should be enabled for participation in composite applications, with a sensible set of simple actions and properties.
  • ...?
I'm aware that these are not all easy to do, but if we're agreed on their value, I'll see what I can do to make them easier.

I suppose there should be a whole other list for web applications, but I don't develop those much so I don't know what they are.

  • Search field.
  • Javascript validations where possible, or at least display all validation messages at once rather than forcing multiple submissions to correct all errors.
  • ...?
Other things I wanted to talk about, are handy reusable UI bits that are useful in lots of applications, that people should keep in mind to see whether they can use. Things such as:
  • Table editing, one row at a time, in a dialog.
  • The list reordering dialog I blogged about previously.
  • Editing history footer in a form.
  • Progress bar for long-running tasks.
  • "Paste a database link" button that turns a doc/view/db link into server and filepath, in case you have a form where user needs to select a database.
  • Formula to convert a field containing a key value from another document, into a link to that document.
  • The "Don't show this message again" dialog (displays an informational message with a checkbox to let users skip the message in future). This should of course be accompanied by a "re-enable all messages" action somewhere.
  • On-demand reports using rich text and the ReportGenerator class, such as I blogged about previously.

Andre Guirard | 8 August 2007 09:05:11 AM ET | Caribou Coffee, Minneapolis, MN, USA | Comments (9)


1) I’ll add these to the SuperNTF list
Kevin Pettitt | 8/8/2007 5:59:14 PM

Andre, great list. Some of these are already in SuperNTF ({ Link } and others are already on the to do list, but several are new and worthy of inclusion.

Things like "personal default values" I have thought of before but never actually done. It's a really neat idea and I think worth doing...would be nice if you could package it all up into a subform and tie it into SuperNTF's form configuration infrastructure. You could configure what fields to offer to "remember" on a form by form basis, and do all the field populating in the Postopen of the subform, rather than fooling around with every field's default value formula. The less opportunity for novice developers to break stuff the better.

Things on the to do list already include integration of the ReportGenerator class. I've already integrated Sean Burgess' ASND Export tool from OpenNTF, so I'm figuring to blend the two somehow (maybe just adding a new output type to the existing report def form), but haven't taken a close look.

BTW - I adapted your "paste a doclink" code for a new "Insert URL Link" function for the upcoming release of Blogsphere. Instead of a link, though, I'm taking a URL text string from the clipboard and writing it to the environment variable, and THEN copying whatever text string the user has selected in the story field and putting that into another environment variable too, THEN presenting the URL and Link Text in a dialog. Click OK and out pops a perfectly formatted <a href...> link. The trick was how to capture two different strings via the clipboard in a single action, and your technique worked great. Should see it out soon according to Declan.

2) Where Can I Submit?
Julian Robichaux | 8/8/2007 6:00:55 PM

Hey, wait a minute. You already submitted Lotusphere session abstracts? Foul!


3) SuperNTF...
Andre Guirard | 8/9/2007 2:19:55 PM

@1: It's so easy to do this with a couple of formulas, that I thought a subform would be overkill. So you would have what, a profile document to store the list of fields in each form that would be auto-populated? But changes to the profile can't be inherited from a template. Maybe it's a good opportunity to use some design-programming in LotusScript -- store a new $Item in the form design note, which the subform would pick up?

The ReportGenerator needs table capability to be usable for generalized reports. I really focused on maximizing length, not on providing full functionality. It's not really easier to use ReportGenerator than just operating on the rich text field directly, if you want a table. And what report doesn't want a table?

4) you lost me on design programming
Kevin Pettitt | 8/9/2007 3:46:43 PM

"store a new $Item in the form design note, which the subform would pick up?"

I understand the notion of adding a $Item to a design note but am otherwise unclear on what you're suggesting.

5) My ambiguous suggestion
Andre Guirard | 8/9/2007 4:01:43 PM

I'm trying to store the information about which fields get this special treatment, as part of the design, to that you can do it in a template and it'll inherit down into the nsfs. So I was thinking the natural place to store it is in the form design note. Any note can contain any items, so you can just make up an item name (but use a name beginning with $ just because) and you can store whatever information you want.

To do that in LotusScript, you would get a NotesDocument handle to the design note using NotesNoteCollection. Then you would just use ReplaceItemValue to put in whatever value you want -- make it non-summary.

Of course, that means that to find out what fields to do this for, you would have to find the design note every time you composed the document, again using NotesNoteCollection. That could be something of a performance drain.

Alternatively, maybe it would be better (and require less UI on your part) if you would just tell the developer/victim:

'Define a field on your form named $PersonalDefaults, type Text, CFD, with the following formula: "fieldname1, fieldname2, fieldname3,...". If you also include the PersonalDefaults subform, all such fields will automatically remember the last value the current user entered in them.'

That makes it easy for them to see which fields they did it to.

The design-programming approach just appeals to me because it's sneaky.

What would be even better, of course, is if you could emulate the browser field behavior where you start typing and get a drop-down of all recently used values. I don't really see a way to do that, but I'll suggest it as a client feature, because we don't have enough to do yet.

6) Remembering ALL past entered values, etc.
Kevin Pettitt | 8/9/2007 4:53:55 PM

"because we don't have enough to do yet."

sounds like a good enough reason for me ;-)

Remembering *several* previous values does sound cool though. It would indeed be tricky to implement something like this without doing anything to the fields themselves, but I can think of a pretty simple way otherwise.

Just for the fields you want, and probably only open text fields in any case, do the following:

- Change the field type to "Dialog List"

- Change the "Choices" option to "use formula"

- Deselect the "Display entry helper button" option on the second tab of field properties

- Select option to "Allow values not in list"

- Define a keyword lookup formula that pulls from a user profile document storing all past entered values for each affected field.

- Add something to the querysave, or even to the field's Input Translation formula, that will take the current field value and append to the existing list of previous values, doing an @Sort and @Unique in the process. Input Trans is probably easier...just do an @SetProfileField and use @ThisValue and @ThisName and the formula would be completely portable between fields.

The end result would be a sort of autocomplete on a text field, without it being apparent it is actually a dialog list field. I can see this being a nicer touch in some cases than a straight "remember default", but you could also meet in the middle and do just a "remember last". The problem anytime you populate default values though is that folks ignore them and leave innappropriate values on the document, so the "remember all previous values" may be just the ticket.

7) Template inheritance and configuration for remember defaults
Kevin Pettitt | 8/9/2007 5:17:13 PM

I can certainly see the value of avoiding the need to update configuration documents following a form design change. But I still like the idea of having full control over this kind of feature from a configuration area. So what to do?

Compromise, of course. Take the feature set I outlined in comment #1 above regarding using SuperNTF's form configuration documents, but allow for the option of specifying a field name that stores the "remember field" list instead. So you could either select "define fields here" or "define fields using field value", and depending on that choice you'll either get a multivalue field from which to choose the fields to remember, or a single value field where you can select the field that contains the list. If you select the latter, no configuration update would be necessary for future design changes.

From a performance standpoint all that looking up to the form configuration document could be expensive, but I have made liberal use of @GetDocField so that the only DBlookup that is used simply returns the UNID of the form configuration, for use by the @GetDocField stuff. I'm certainly open to alternative viewpoints, but the intent here was the compromise between potential caching problems associated with profile documents and extremely expensive DBlookups.

8) On the subject of inheriting stuff from template ....
Richard Hogan | 8/10/2007 11:13:32 AM

@5 I like the idea of being able to store extra information and have it inherited down into the db's from a template.

Along similar lines, I often though it would be immensely useful if I could get 'help' documents in a template to update, along with the design, when an updated template is re-applied to a db (same could hold for app config info - lists of keywords, etc). I don't suppose there's any item that could be added to normal (help) docs so that they get picked up by the refresh design code, and any docs with the same unid in the target db would get replaced by updated versions from the template??

If not, would it be a feature worth considering (as you "don't have enough to do yet" ;-)

9) Default Paste Agent
Johannes Madsen | 8/14/2007 10:59:38 AM

My applications always include a default paste agent. The purpose of the agent is to stop users from pasting documents from other databases (which happens a lot). The code is fairly simple and it checks that a form equal to the contents of the Form field exists. If it doesn't, the document is deleted.

Unfortunately, this sceme doesn't work for applications with Author users. In this case, QueryPaste must be added to all views instead, which is a bigger task.

10) re: Default Paste Agent
Andre Guirard | 1/10/2008 2:29:12 PM

See my latest blog entry explaining why your agent approach doesn't actually work... sorry.

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact