Are Notes Views Still Relevant?
Do users really use Views?! It's a question I've been asking myself more and more as the years go by, but it's a question I don't really know the definitive answer to.
The accepted approach whenever creating a Domino-based app is to stick in half a dozen or so views, each sorted by one or another primary field. Let's say it's an invoicing app to track invoices. You might have any of the following view and more: "by number", "by customer", "by value".
Do users want that though? To me it simply harks back to the days of Notes client app where the left hand navigation is simply made up of a set of links to different views.
It might work well enough in Notes, but does it translate to the web? The web is different to Notes, but it seems that we just try and mimic Notes apps in the above regard when webifying them.
Working as I do, remotely and isolated from end users, it's often hard to gauge how much a user uses or relies on what I give them. While it might seem acceptable to take a "no news is good news" stance, it doesn't mean the user is perfectly happy just because they haven't complained.
Over the last few years I've found myself questioning the usefulness of "Form X by Field Y" views. Especially those that contain 1,000s of documents and only show 30 at a time, with the obligatory "Next" / "Previous" navigation system at the bottom.
Surely users don't actually navigate through these views, page by page, looking for what they want, on a regular basis?!!
What's the alternative? I guess it's to give them quick and ready access to whatever it is they're actually looking for. This will vary for each application, but in most cases I'd guess they looking for one document in particular or a small subset of documents based on some criteria.
Either way what we should do is ask the users what their most common goals are and make it as easy as we can for them to accomplish them.
Over the coming days I plan on showing a couple of ways in which I think we can help. What I'll show are not perfect solutions by any means (but then nor are paginated views). They're just alternatives. One thing I want to show is an "infinite scrolling" view. The other is a "quick search" feature.
For now, it's open for discussion...
Skip to the 
You can subscribe to an individual
Hi,
I think users expect very fast full text search (with typeahead on the search terms) ala Google/Windows search. Click in the search field and,"Just Start Typing" and search results start appearing as the user types.
Reply
My thoughts exactly. Which is what one of the things I'll be talking about tries to achieve...
Reply
Show the rest of this thread
As Jonathan mentions most of the time I suspect some form of AJAX based lookup / filter is probably what people want when faced with the 1000's of rows type grid, either the in memory data or a server side call.
If people really want spreadsheet type functionality, to manipulate the data, then that's where it belongs.
The important thing here is to make sure the data is separate from the markup, the days of having markup mixed in with view columns should be over giving you plenty of opportunity to present the data in different ways, whether thats XPages or a javascript grid backed by a client side framework like backbone.js. A couple of good examples - http://datatables.net/index - https://github.com/teleological/slickback/wiki
Whats more interesting and possibly more difficult is the summary roll up of the data e.g. graphical dashboards, the ability to drill down and the initial high level display of data that's relevant to the user.
Reply
There are times when views are useful, such as the "I don't know what I want, but I know when I see it" brigade. For example I have had a long standing website out in the world where the owner doesn't want me to upgrade the design. This design is now nearly 11 years old and is really old school. http://www.up1.co.uk (slightly NSFW in places).
Users do scroll down the lists of what's available and put stuff they like into their baskets. They also use the search and series (a RestrictToCategory view) to find what they want.
Why? Browsing mentality I guess. That and the fact that a lot of people cannot spell some of the titles so a "Just start typing" option may not be as useful as you'd think.
Some just want a great big list of all the new releases. Some want exact titles and products. Some only buy models and figures. Trying a one size fits all design is really hard to please all users.
But for now, all I aim to please is the site owner. He calls the shots, not I.
Reply
Good point. Searching for something implies that you suspect the information is out there and may not be suited for all users/applications.
Reply
As views are the only means to navigate data natively in a Notes database, they're still relevant in that sense. As a user interface, which I think is what you're trying to rationalise, the web-based and other mediums being the norm, views themselves are becoming a programmatic access mechanism. Let me explain.
You have to do a lot of work to improve the usability of a standard view for the web. I think IBM should have looked at this approach and improved upon it rather than abandon its evolution completely.
Views are the cornerstone for Mobilite. We just re-interpreted the interface for the medium, that is to say, it's not just mobile, but "small touch interfaces" that we're involved with. The infinite scroller is a common requirement in the Mobile era. Obtaining the data is usually driven by views, simply for speed and simplified ordering it offers. You have FTSearch but this has no ordering. Again an easy fix for IBM to implement I would think.
Surprisingly scrollers themselves are not done well for HTML5, and we have had to tune it ourselves with frameworks that are only now starting to deal with it. You will eventually be able to use JS frameworks with much more ease to present data in a variety of ways, thus relegating Domino views as an access mechanisms.
Nothing wrong with the traditional approach, except that it's a method that IBM has left behind for Xpage controls. I believe if it works for the customer and they pay you for it, then mission accomplished.
Reply
IBM has already implemented ordering in ft-search: http://publib.boulder.ibm.com/infoc.. ..gner.domino.api.doc%2Fr_domino_View_FTSearchSorted.html
Works perfectly, but you do need to plan ahead a bit
Reply
Let's use the example of an approval database/app.
In my world, managers want to see who submitted requests by division, by dollar amount, by item type, etc. They're not really 'searching', but looking for cumulative signs of a problem. Views suit that type of user very well.
Ideally, a pie chart that they could drill into might suit them even better, but I can't do that natively, and that would require some retraining. As intuitive as some of that stuff is for us, it's not as easy for someone who has been with the company 35 years and used Notes views for 15 years.
Reply
As with all things, it depends on the need. Notes views are (almost) perfect for things like discussion type forums, for other things then yep typically a screen where constraints are picked and relevant results are displayed is the way to go.
Reply
Jake,
We do things a bit differently. We created an entire framework on top of Domino that uses only a limited number of view regardless of what application is running. The limited number of views reduces the view index and memory usage thus increase performance. In theory, you can have an unlimited number of different applications running using this limited number of views which is structured for REST-based look up only. All records (documents) are JSON containers with key index value store in fields. It is similar to how CouchDb using views.
Reply
I think one of the most useful and underutilized features of a notes view is the fact that you can start typing and automatically jump to the text in the sorted column. So in an inbox view sorted by sender, you can type a person's name and the view will jump to it. Similarly, Ctrl + F, will open up a search box and find any text in that view. That's what is most convenient for me in Notes views and what I miss most about views on the web. An ajax type-ahead for each column in a view would solve the first scenario. Good search would replace the second scenario.
Reply
I've always worked in an environment where web-based apps were only used by external customers who were only allowed access to their data. Pretty much no views needed for that.
In-house coworkers used the client. Managers loved views as a form of drill-down reports. They would have hated any web version that I can picture.
I'm sure XPages would make it easier somehow (look it's a floor wax AND a dessert topping!) but I'll wait and see what the XPages gurus say.
Reply
I'm finding users think they want the latest and greatest but in the end they want a web app to be just like Notes. They want a thousand views because that's what they had in Notes. Slowly, they are turning around. The adage "you can't teach an old dog new tricks" rings very true in tech.
I'll be very curious to see what your quick search is composed of. I've started adding a search box in my XPages apps that presents an AJAX dropdown with matching entries along with which field was a match. For example, if you search on "John Doe" you might get a dropdown like this:
John Doe (Author)
John Doe (Manager)
John Doe (Approver)
When you click the desired entry the view is ft searched to match the value/fieldname. It's a good solution to find granular data in a large view.
Reply
With the transition to XPages, Views have regained their importance in LND application development... arguably for the NotesViewNavigator alone. Using this as a data source to build a JSON data source, I can use it at-will to create (and filter) any representation of NotesData I want. Combine this with storing the JSON in scoped variable... the speed is unmatched. The "View" as a UI Element is dead, but as a data source it's invaluable.
Reply
Even Domino dev withou x-pages, the NotesViewNavigator is your bestest friend for speedy output rendering agents. From that perspective, you very much need notes views.
All my Notes UI views are for administration of the data provided by users via the web interface. It's quicker and easier to build them and App owners who want to work with the data without the fluff of the web interface appreciate having all the views they want.
Reply
No end to approaches when tackling this issue. I find myself most often serving up a "default view" (not really view because its done in the qo agent) that shows the user what they typically need to access. Above the view I give them the ability to run an adhoc report based on criteria they select. Use datatables.net to display the data.
Reply
As everyone said, there is no wrong answer. I think users want the best of both worlds. They want a view that they can do a google search on the web. Mark Roden talked about this at Connect http://www.slideshare.net/MarkRoden/lessons-learned-from-the-worlds-largest-x-page-project ... as the apps scale, you have to look at performance, user expectations, and costs vs. functionality
Reply
At work, in some of the larger custom .NET and PHP apps we basically have a single "view", in the form of a data grid that is indeed paginated.
As in large data sets pagination isn't practical, yet endless rows aren't an option either, the data grid itself allows for all sorting combinations just by clicking on their headers. This removes the need for seperate views.
Still, this only sorts results, and does not limit their amount. To help with that, there's a filter panel above the grid, where users can set one or more filters, typically custom designed.
Finally, and optional, there may be a free text search. Often we also make a second "my view" for records only applying to the current user.
All of these parts are needed to make it usable, and I'd argue it still isn't nearly as usable as a desktop-style data browsing application.
Reply
As Toohey mentioned, views are (almost always) still necessary as a way to programmatically get to data.
In terms of UI, grid-based views (as opposed to Carl's example of discussion features) are only useful to people who want their data to look like a spreadsheet. Spreadsheets are only useful to people who don't have an app that tells them what they really need to know without having to look at ALL the data. Ergo, if your application UI shows them all the data, the app has failed.
Reply
We have had success using views, almost as it on the web. You're right, paging sucks and is not used. So, just don't page - count=-1 and dump it all out. That combined with gzip, smart categorization, jquery search, and predefined filters using show-single- category work well for us. It is super fast to load and scroll, even in IE. Gzip made it possible on the loading front. We get 85% compression most of the time.
We have very large databases too - 96Gb (thanks DAOS!) and 5+ million docs. Obviously you would want to limit the number of docs showing in a view to less than 2,500, but that is doable with categorization (twisty action).
Reply
Perhaps a useful tip here:
In the admin client, you can see the sizes that the view indexes are taking for any particular database. It's a surefire indicator of whether a view is being used or not.
When I am refactoring an old notes database (client), one of my surreptitious improvements is deleting all the customer-facing views that are not being used.
My rule of thumb is that a well designed application really needs only 5-10 customer-facing views.
Also, a big performance boost is critically looking at those views which could be downgraded to a manual refresh instead of the automatic ones. Surprisingly, some customers completely accept the tradeoff between speed of display and up-to-datedness of their views. (depends on the application, of course, but good for the infrequently-updated-but-containing-loads-of-data-applications)
One feature which I sadly miss was the ability to select a document, press 'shift' - or was it 'ctrl', click on another view, and the document would still be selected in the other view.
I must also, guiltily, admit to sometimes creating 'sloppy views' used only by me when I can't be arsed to do a sort algorithm, especially when sorting over more than one column.
Reply