Mini:Strobili session manager
The Strobili session manager is the front end part of Strobili applications. The session manager can be implemented either as a lightweight HTTP server that the users direct their web browsers to (similar to the Google desktop application), or as a browser plugin. The session manager's main role is to allow users to browse trough the network of cones of the strobili application, to search for specific knowledge within this network, or knowledge space, by performing proximity based serach inside the cones. In addition, when users browse trough seeds and cones, their sequence of selections is recorded by the session manager, that at certain points checkpoints the sequence by increasing the popularity rank of the visited cones and seeds. The result is a set of trails in the cones network that represent the recommended selections of users – and create Strobili's unique active recommendation process.
Contents |
[edit] Why is the session manager needed?
The need for the session manager can be justified from both a technical and a user experience point of view. From the technical point of view, the session manager allows for better utilization of CPU and network resources, by offloading some of the work from the Strobili servers to the personal computers of the users. In addition, in this manner the communication between the session manager and the servers can be done over dedicated data exchange protocols, such as LDAP or dRB, and not in HTTP.
ֲBesides the technical justification, there is the more important user experience related justification. The idea here is to conceal the socially-driven operation principles of Strobili, behind a self-interest motivated user experience. This is important not because there is something wrong with users knowing that they participate in a socially driven process, but because we would like this participation to become a seamless part of the way people use the application, and not something they have to go out of their way to do. This seamless collaboration is one of Strobili's main principles, and is discussed in more detail hereafter,
[edit] Operation principles of the session manager
[edit] The cones browser
When users use the session manager, what they actually do is to browse trough the network of cones and perform a proximity based search in each of them. In each step of this process, the session manager "enters" a certain cone and generates a HTML form that allows the user to enter the search values of the descriptive indicators that make up the search criteria of this cone. When the search is performed, a combined action of the session manager and the Strobili server that stores the cone creates two lists of output: one of the seeds in the cone and one of next cones.
The list of seeds is sorted by the proximity of their associated criteria with the requested search criteria. Perfect matches will appear first, followed by approximated matches. If two seeds have the same proximity to the search criteria, they will be sorted according to their ranking indicators. The list is presented to the user in the conventional manner of a search results list.
The next cones list is not really sorted but rather organized into a "tags cloud" or some other text-graphics representation that displays the relevancy and popularity, and perhaps some additional relevant information (such as novelty) of the cones.
[edit] Session recording
The session manager keeps track of all the actions that are done by the user during the session. This includes not only the sequence of browsed cones and selected seeds, but also of the descriptive indicators and their values, that where used to search the cones. Besides for checkpointing, the information in this session trail is also used by the session dictionary, and can be saved by users so that they can leave a session and return to it later.
[edit] Session dictionary
The session dictionary is a temporary storage of information that can be used by the session manager to assign default values to search criteria indicators, build up selection menus, etc. The data in the dictionary can come from various sources such as the session recording process, content of seeds, etc.
[edit] Session checkpointing
Checkpointing is a process in which the session manager increases the popularity rank of the rows that where selected in the visited cones trough the session. This is done (as the term "checkpointing" suggests) only at certain points, and not as each row is selected.
There are two reasons why checkpointing is a more effective mean for Popularity-aware ranking than just increasing the popularity rank of selected rows as they are selected - loops management and Quickest path emphasis. We will now look at both in more detail:
[edit] Loops management
If the same search on the same cone is done more than once in the same session, the sequence of selections that where done between the first and last appearance of the identical searches is called a loop.
A simple loop situation is when a user that selects one of the search results of a certain search does not like that result and goes back to the same search results to pick another one. In a general purpose search engine, this happens quite frequently, and it is quite obvious that we would not like to increase the popularity rank of results that where just glimpsed at. In this, as well as in some cases of longer loops that include one or more searches between the two identical searches, we would like the application to do Loops elimination, which means that the selections that are inside a loop will not be checkpointed.
In other cases, it may not make sense to avoid checkpointing the intra-loop searches, but we would still like to somehow manage the loop situation. We may, for example use a loop indicator which is a ranking indicator that is decreased when intra-loop selections are checkpointed, causing these selections to rank lower in the next searches trough the knowledge space.
[edit] Quickest path emphasis
When users browse trough the knowledge space, the checkpointing process is creating virtual trails in the knowledge space and it is clear that if there are several possible trails from one checkpoint to another, the one that takes less time to follow will be checkpointed more often than others and thus the cone rows which make up this trail will rank higher in searches. In this manner checkpointing enables us to emphasis not only specific choices of search results but also sequences of multi-searches. Furthermore, sequences that represent a meaningful interrelation between the selected results, will be followed more consistently than those which represent a random set of selections and therefore will gain more emphasis than similar trails.
[edit] Seamless collaboration
Many collaboration driven applications (like most ERP applications for example) fail (either completely or at least fail to return the investment made in them) because they require users to go too much out of their way to participate in the application's underlying social process. The paradox here is that while collaboration is most important in complex tasks and high tension environments, it is exactly these environments in which people are the most suspicious - if not even hostile - toward collaboration driven applications. The reason for that is not only that people in this kind of environments have very little spare time for "punching in data" for the applications, but also prisioner dilemma-like social effects.
In the design of Strobili, much thought was given to trying to reduce this "collaboration friction" to minimum and the seamless cooperation that the session manager enables, is one of the main means for achieving that. The following table sums up the main principles of how seamless cooperation is achieved:
| Collaborative effect | Concealed as | Description |
|---|---|---|
| Thumb up/Thumb down items | "Passive browsing" of the knowledge space |
|
| User contributed indexing | Indirect criteria assignment |
|
| User contributed content | Social bookmarking |
|