Mozillaca/hansschmucker
Contents
Mozillaca usability issues
Mozillaca right now has a couple of annoying shortcommings that also have given a tremendous rise to spam.
Update notifications
The general idea
When an update happens, apparently nobody gets notified. This is on the one hand annoying to end users as they have to reload the page over and over again to see if there are any new reaction, and on the other hand allows spam posts to go undetected unless an administrator happens to check the page while the spam post is still on top.
A simple solution is a notifier. There are different kinds of notifiers, using everything from mail over popups to title changes to alert the user that a new note is waiting to be read.
I don't think sending a mail every time a new note gets published is the way to go: That would just create an exact replica of Mozillaca inside people's mailboxes. Also, there are times when you don't care about Mozillaca because you're busy with something else and mail notifications would still pile up.
So for me a title notifier à la GMail seems like the best option. Title notifier means simply that the window when not active displays the number of new notes since it last was in the title. With tabbrowsing the window title is always visible, so this makes for a simple, yet efficient system.
Things to consider
Don't require backend changes
Since Mozillaca is built on Laconica the functionality could be hacked into the backend, but updating such a customized version is difficult, so it's best to make it as independent as possible. In cases where this isn't possible at least make it configurable so it can easily be adjusted to changes in the backend.
Besides, this allows for testing without setting up your own installation of Laconica which really was the deciding factor for me.
Reloading vs. AJAXification
Status checking can basically be implemented either by simple reloading or by checking the status via XML requests. Reloading is however the easier method since it prevents desynchronization of displayed and processed content.
Development
I originally intended to do this as a Greasemonkey script, which allows for wide testing before deployment on the server. And for all intends and purposes the addon really just is a Greasemonkey script implemented as an addon, since Greasemonkey is currently broken on trunk.
Greasemonkey scripts of course have one significant advantage over deployed scripts: You don't have to care about legacy browsers and so the prototype makes use of functionality that a deployed script would have to get via support libraries like jQuery. But I think that's good enough for a prototype. I took care to not use any features that currently cannot be provided by third party libraries.
The basic idea is to test functionality with the current codebase until we're satisfied it does what we want to do, then port it over to a framework for deployment.
Program logic
The logic behind a notifier is quite simple:
On load, if in background: check if previous reference data exists in persistent storage, compare and add result to title. Carry over old reference data
On activation (or has focus on load) or if no previous reference data exists write reference data to persistent storage
On load, schedule reload. Postpone reload if user interacts.
For more details see the source .
Shortcomings of prototype
Aside from the porting that would be necessary before deployment, the current prototype has a number of shortcomings, mainly that it is only really tested on the index page (although it appears to work on profile pages as well) and that it has no logic for dealing with navigation. So if the user navigates to a different page, he'll get notified of the maximum number of new items possible.
There's also no distinction of own posts and foreign posts, so it will notify you of your own posts too.
