User:Jeblad/Links in adaptive portlets
I've been playing around with some ideas for the sidebar portlets, and what goes where, and more or less stumble across an idea that could be useful somehow. After moving links in and out of various portlets, and renaming them, and trying to figure out who needs what I ended with a pretty simple idea; portlets are approx a set of most used visual shortcuts to pages within a given namespace. As such there is one important root page and several most used pages. All important pages should be reachable from the namespace root page, but it should not be necessary for a page to be listed on this page to be on the most used list of pages. The list of most used pages should be adaptable by the system according to what the user has visited. In addition to this it should be possible for the user to add (pin) some pages that overrides the adaption system and always gets included.
The adaption algorithm that seems to work best is pretty simple; make a list of visited pages from each namespace, if a previous visited page is revisited then move it up front in the list, each time a page is visited increment its page view count, sort the list on page views before appending the most visited to the namespace portlet, and prune the list to a maximum number of entries before storing it in session storage. A complete or a shorter version of the list can be stored at the server to make it possible to regenerate the same list on different clients.
A variation on this scheme will subtract a normalizing factor from all old entries before the counter for the present page is incremented. This makes the present page win a position in the list of most used ones pretty often, and also make it possible to store a shorter list on the server and still get a pretty good representation of the most used pages. The client might store several hundred visited pages, while the server only keeps ten to twenty of the most used pages.
Special pages is an exemption as some pages will belong to a specific portlet. I tend to believe it is better to not allow any special page in namespace-specific portlets.
In a mobile interface this has several important aspects. Most important is the fact that this works without a fancy user interface, and that the list can easily be transformed into a horizontal representation. Because both client and server can track the necessary data, which makes it unnecessary to maintain state in a cookie, it reduce the data transfers and makes it possible to use the system without being logged in.
One problem that might affect some users is that the list will be a very powerful fingerprint for bridging the gap between different user accounts, and will therefore be a source of distrust for users. It must therefore be possible to run the algorithm in a "client side only" -mode, and probably it should also be explicit forbidden to use this data during CheckUser runs.