As I’ve mentioned before, Dwight Wilbanks and I are presenting on AJAX widgits and a toolkit for Domino developers at Lotusphere. I bring to you now some design questions about building enhanced Domino Views with AJAX. Here’s the idea of the basic view widgit. I request a view, it brings back a scrolling viewport that has the first 10 view entries listed. Above the viewport, it says, “Entries 1-10 of 28 categories”. To the right it has a field for me to enter text and the view will jump to that entry in the view.

As I scroll down, more view entries appear, and if I keep scrolling, I’ll eventually get all the view entries (or categories). If it is a categorized view, and I mouse over the entry, it will tell me how many children there are for that category, and how many total descendants. So here’s question number 1. Rather than “twisty” style view categorization, what if I had a 2 pane view that showed the categories in the left pane, and when I click on the category, the list appeared in the right pane? Here’s an MS DOM reference page that has a similar orientation. It’s so easy to get buried in categories, I could see this type of navigation being handy.

5 thoughts on “

  1. #1 Sounds good.
    #2 Define an array frames(M). Load your view entries, N at a time, into an array entries(N). M * N is the total number of entries you will be caching. Also define an array frameIndex(M), and init all slots to -1. Each time you load a new set of entries(), first you look for a slot in frameIndex that is still -1. If none are found, you’re going to have to clear a slot — probably by looking for the value that is farthest away from the start position of the group of entries you are about to read. Then you read the entries, you assign the entire entries() array into one slot in the frames() array, and you set the corresponding slot in frameIndex(). This way, you can play pretty easily with the size of M, and the method for deciding which frames to keep and which to discard.
    #3 How about setting it up so that there’s the option of accessing a second view. If the second view is specified, it is a non-categorized view with the same selection formula, so one call to that view will return the correct total number of docs. That way you have the best of both worlds: “Entries 1-10 of 15000 documents in 28 categories”. And if the optional view is not specified, you just have “Entries 1-10 of -unknown- documents in 28 categories.

  2. I knew I could count on you Richard . As David Bockes, http://www.inthestorm.com, says, “I’m afraid to write anything in my blog anymore for fear that Richard will come by and reveal what an idiot I am.”

    Well in this case, I actually don’t feel too bad. Glad you like #1. As for #2, I just finished coding an approach earlier this evening that uses a paging concept. The visible portion of a data set (the viewPort) is x. The dataset collected for it is x*10, that constitutes a page (as in a ReadViewEntry call). We check for page, page-1, and page+1 whenever user scrolls and build table from that. Once the user has scrolled beyond page, we grab additional page as necessary, add some rows to table, remove some rows from table and adjust the divHeight spacer that sits above the data_grid table so that scroll position remains correct. Testing now.

    As for #3, I’d like to avoid building another view element on the back end. From the initial ReadViewEntries&count=1, you get a very small data return that tells you number of toplevelentries as well as whether this is a categorized view or not. If it’s categorized and the numbers are reasonable, you can issue a second call to ReadViewEntries&CollapseView to get a parseable tree that gives you all the doc counts you need. This also has the advantage of giving you a nice data set for the split pane to put categories in left pane and children in the right.

  3. Lance,

    Another thing to keep in mind is whether the view is changing beneath you or not. Caching stale data can be worse than not caching at all.

    When we implemented ReadViewEntries in Domino for the view applet, stale view data was a concern. The set of documents in the view can change, the number of top level items, etc.

    If your Domino web server is actually a cluster of servers behind a load balancer or sprayer, each request could be going to a different server which, depending on the replication schedule, may have different view data.

    So, it can be tricky to get this right when the view is changing a lot. With the view applet I believe that we provided the user with the ability to force a refresh (F9) to synch the view with the server.

    –bob

  4. I once worked on a mockup for a web interface that would show view entries (not using AJAX). The interface had a slider that was labeled “Speed”, with slow on the right and fast on the left. The idea was that the user could control how much data they could handle at a time, based on what they were looking at/for, their screen real estate and/or the feel of the speed of their connection. This was before we had ever heard of the AJAX stuff. Maybe a control like that could be useful for your widget.

    In my view (pun), I might care about knowing there are 120 entries, but when there are 15,245… to me, it is not necessarily useful data, in a viewing tool, to know the exact number of entries… I am *looking* for something, I am not RainMan, so maybe having a visual clue would be more helpful. Maybe an image that shows approximately how much stuff there is. Or perhaps combining the visual idea with the slider/speed control would be cool. A short slidebar device means there are not many, and a longer slidebar means there are a bunch. Come to think of it, the slider on the right side of this edit box on your site is already doing that sort of, by making the slider button progressively smaller the more I type.

    What if it said

    “Entries 1 – 10 of a Huge List”?

    Maybe making it more like a human assistant. If you had an assistant and said, “Fetch me some of those view items”. He might come back and say, “Here are 10 that I could carry… and there are a massive amount of entries in there”. After a while he might say, “you have seen 100’s of these entries already, and you have seen about 10% of what is there.” That is useful dialog / communication. It would be interesting to see that in an interface.

    Look forward to seeing your presentation.

Comments are closed.