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

The option "Categorized as flat version 5 or greater" is one of life's little mysteries. What exactly does this do? The Designer help says:

If your view is [categorized], you can select "Categorized is flat version 5 or greater" to convert your view to a non-hierarchical, flat view, which displays all documents on a single level. Use this feature if your level of indentation in a view exceeds the limit of 32 levels.

Now, to me, this seems to be saying that if you use this option, the view is actually not categorized.  But in that case, why bother to add an option, since you could already do that by selecting sort rather than categorize to each column. There must be more to it than that. So I decided to try it. I started by creating a view with three categorized columns:

original view

Then I experimented with turning on the "categorized as flat" option for various combinations of columns:

column 1 flat

Columns 1 and 2 have essentially been combined into a single category -- one twistie displays all documents with the same requestor and status.

One thing I notice right away is that the value of column 1 is also displayed on the document row entries, which seems useless to me since all the documents in that category will have the same value there. Unless someone likes that behavior and can give a reason why, I plan to write an bug report.

columns 1 and 2 flat

All categorized columns are combined so that they effectively function as a single category. It's as if you created one column with the formula Requester+Status+AssignedTo and categorized that, except that they appear as three separate columns and let you control their widths and fonts separately.

Of course, having a twistie on each column is unnecessary; they all do the same thing.

columns 1, 2 and 3 flat

Now the view is simply sorted, as the documentation suggested.

column 3 flat

Notes forgets that the column is categorized, and only sorts it.

column 2 flat

Columns 2 and 3 are combined for sorting purposes.

column 2 flat, but column 2 is set to sort "None"

Even if you turn off sorting for column 2, if you make it "categorized as flat," it's used as part of the category heading with the next column which is categorized.

column 2 flat, where column 3 is categorized descending

To sum up what we're seeing here, "categorized as flat" apparently merges that column with the next column for sorting/categorization purposes, but maintaining the sort direction of each column (where "none" apparently defaults to "ascending"). This lets you reduce the depth of your category tree.

Aside from avoiding Notes' limit on categorization depth as the doc suggests, this also lets users navigate to document rows with fewer clicks. In any case where the number of combinations of two categorized columns will be small, you can consider the tradeoff of the user's time in scanning a longer list of the category headings for the combination they want, versus the number of times they need to expand a category to find a desired document.

For instance: If column 2 can contain two values, and column 3 can contain two values, and they're individually categorized, then the user has to decide between 2 values, click, decide between 2 more values, and click again -- a total of 4 values to examine, and two clicks. If you set column 2 to "categorized as flat", there are 2*2 4 combinations, but only one click to make the document visible -- "categorized as flat" saves a click, without any additional eyeball labor.

Or, say column 2 has three possible values, and column 3 has three. If separately categorized, there are 3 + 3 = 6 values to examine, and two clicks. If column 2 is "flat", there are 3 * 3 = 9 value combinations, but one click. One could argue that saving the user a click is worth giving them 3 more choices to look through.

Or, if there are a dozen choices each, the comparison is 12+12 = 24 values one way, with two clicks, vs. 12*12 = 144 choices the other way, with one click. This sounds like the "flat" option will be more trouble for the user.

You must also consider not only what the maximum number of value combinations will be, but the probable number of those combinations that will have at least one document in them. That depends on your data and the statistical distribution of your values. If you already have data in the application, it might be easiest to do this empirically with a document-scanning script, rather than try to calculate it (but bearing in mind that you'll probably add documents as time goes on).

Of course, that business of displaying the "flat" column on all the rows is kind of annoying, and the clutter/user confusion factor might prevent you from using this feature even when the numbers would seem to call for it. But anyway, that's what it does and that's my take on it. Hope this is useful.

I didn't try what would happen when this option is used with column values that contain \ (a.k.a. "ad hoc subcategorization"). If anyone feels like pitching in, that might be something to try.

Andre Guirard | 16 July 2009 08:00:00 AM ET | | Comments (7)


1) I don’t think that’s a bug...
Charles Robinson | 7/16/2009 11:10:21 AM

I had to pull that apart the pubnames.ntf template to figure out some LDAP lookup stuff. That was the first time I ever saw the flat categories property used in a real app, and it was when I discovered that flat categories are accessible from ColumnValues on every document. Pretty nifty.

Do you have any insight into what happens on the indexer side of things? Is using flat categories more efficient than multiple column sorts?

2) flat categories in ColumnValues property
Andre Guirard | 7/16/2009 12:24:02 PM

@Charles: Aren't regular categorized columns also available thru ColumnValues?

In any case, regardless of what it does in the back end, it seems to me those columns shouldn't display anything on the document rows. I'm just concerned about visual clutter.

I think categorized columns of any kind have to be less efficient than a simple sort, if only because there are more row entries created.

3) Yes
Erik Brooks | 7/16/2009 2:28:05 PM

@2 - Yes, ColumnValues gives you the categorized columns' values also. Unless you're restricting by category, then everything's off by an index of one and you don't get the ColumnValue for the column you're restricting by.

I completely agree, the visual clutter is annoying when using "categorized is flat". But it's not a big deal in my opinion compared with all of the other indexing enhancements that could be added to views that would greatly impact Domino app dev and scalability.

That'll probably be my next big blog post... with XPages the scalability of Notes/Domino UI gets a big boost. The next big scalability concern is going to be the current indexing limitations (views and the FT indexer).

4) Categorize as flat
Tim Paque | 7/16/2009 3:25:47 PM

Wow I've been doing notes for over a decade and had no idea how that setting could be useful. Thank's, thats pretty cool!

5) Wasn’t this originally for web development?
Rob McDonagh | 7/16/2009 3:33:47 PM

I can't remember the details (hey, I'm getting old), but this was put in for a very specific use case, and I think it involved web development. It was discussed in the forums at the time, I think. I seem to remember it as an R5 thing? Or 4.6, maybe. This one and "show single category" are linked in my memory for some reason.

6) oh, duh, of course R5, thus the "version 5 or greater"
Rob McDonagh | 7/16/2009 3:35:28 PM

*smacks head against desk*

7) Careful with that head, Rob | 7/16/2009 5:21:38 PM

You might need it later...

8) Might be helpful when exporting views
Doug Finner | 7/16/2009 8:11:42 PM

If you do a 'file export' on a categorized view, you get the categories exported on one row and the data on other rows. If you're using the data in Excel, you may want the category in each row.

I think you have the same issue with 'copy as table'.

While the view might be visually cluttered, the export move to Excel is going to be much more useful.

And yeah, I know building in export functions to do the heavy lifting is generally a better idea but this might be a quick way to make views exportable.

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

Search this blog 


    About IBM Privacy Contact