I've stumbled upon this interesting and illustrated article on data lookup user interface design patterns (on both web and desktop applications, finally we seem to be starting to forget there's a difference!):
Here are two design paradigms for handling large amounts of data, not to be confused (or combined) as web design meets desktop in rich Internet applications.
[From Seek or Show: Two Design Paradigms for Lots of Data « Theresaneil’s Weblog]
The post describes two main groups of patterns, based on the way a user chooses what he/she wants to search (pictures linked from the article mentioned above):
- The Seek Paradigm - The user has to input a search criteria in order to access some search results.
- The Show Paradigm - The user is presented with several search results (or categories), and he may drill-down the search by clicking on the desired categories or selecting certain results to eliminate unwanted items.
This got me thinking in terms of offline work, and I can easily qualify both approaches as orthogonal to the online vs. offline decision. It is merely a user interface option, which is a good thing. To understand this, picture a lookup for book titles on a library. To go offline, one would have the client application to fetch them all from the server, thus making both kind of interface patterns possible without contacting the server. Similarly, if we wanted to know how many clients had already rented a book (assuming the algorithm implied a run through each client's details to look for their rental - I know, it's not the smartest way to do that, but it's only an illustrative example!), the client wouldn't be able to fetch all the other clients' details, hence not being able to use any of the search paradigms.
So the effort that has to be done, from the application logic design point of view, is related to how the services (those accessed by the user interface) access the information stored in the database. Let's draw some pseudo-code* for the book rental example above (the second example).
- Approach 1: The all-powerful service. This is the kind of service we would have written up until a few months ago, considering any sort of offline execution to be an academic dream or an edgy unfeasible mostly unsuccessful experiment. Basically it assumes that it is being executed with super-user privileges, hence able to access all stored data at any time with no constraints whatsoever.
- Aproach 2: The helpful, aware and conscious service. This is the service that knows that its code may be executed in many places, and so it tries to make a scarce usage of the stored data as much as it can.
Using approach 1 we could code a service like this:
(define-service get-number-of-book-rentals (book)
(let ((all-clients (get-storage-data "clients"))
(result 0))
(dolist (client all-clients)
(set result (+ result
(client-book-rentals client book))))
result))
As you can see, while this would work perfectly on the server, the client would never be able to to the (get-storage-data "clients")call, given its lack of permission to fetch them all to the client-side storage. This is the sort of services that must be thought over and rewritten - or, better yet, automatically translated to something more useful!
By using approach 2, we would instead code something in the lines of:
(define-service get-number-of-book-rentals
(:inputs (book)
:storage-data (books-rent-by-all-clients (get-total-rentals-from-clients)))
(let ((number-of-books 0))
(dolist (client-rentals (filter book-rent-by-all-clients
:field "book"
:value book))
(set number-of-books (+ number-of-books client-rentals)))))
number-of-books))
Here it's clear that the service knows what data is going to be needed from the storage. With this information, the server can fetch it for the client when it wants to disconnect, and the client is now able to perform the same functionality without having to run through the clients (read, without having to have access to all clients' personal details). Relevant, noteworthy changes between the examples:
- the service has to be declared with more information (like the storage-data requirements)
- the storage data requirements code is always performed on the server. The client counterpart consists of a lookup on the client-side storage for the previously fetched information. This way there is no risk of information not being available.
- If the service is to be run online, it also runs equally well, with no performance penalties.
- There must be either a mentality change or a tool to translate services made with the approach 1 to the approach 2!
I'm already laying out some code to achieve something like this. Expect news in the following week or two.
*Disclaimer - despite being in a lisp pseudo-dialect, all examples could exist in the language of your choice. It's really just a matter of personal preference!
