User:Splarka/userstatus

Users like to sometimes show their onlineyness status, as WP:STATUS can attest. But doing this on a MediaWiki system, especially one so high-profile and streamlined as one on Wikimedia servers, is not an easy task.

=Abstract= This is an abstract overview, see for more details on the current implementation.

User status script
A script that edits a subpage every time you 'login' and 'logout'.
 * prone to failure
 * requires remembering to 'log out'
 * inefficiently adds revisions permanently to the database

Manually setting
Same as a script, but manually edited.
 * meh

User status bot

 * BANHAMMER!

Core feature
Some sort of core support for this sort of thing.
 * would probably never be approved
 * would break cache or be broken by cache

Extension tag
A tag which would automate user onliney-ness.

This has some possibilities. Imagine a parser tag like: user=Foo imageactive=Image:Online.png imagearound=Image:Semi-idle.png imageaway=Image:Offline.png imagegone=Image:Very-offline.png imagesize=200x200px Which would create simply an tag with an SRC to a server-side script, which would check your contributions and log entries, and return the appropriate image (with a reasonable cache, say 5 to 15 minutes).

...but you'd have to write such an extension, test it, and get it approved for Wikimedia. Not an easy task. See for example 13520.

Javascript faking an extension tag
Often a precursor to an extension, is a javascript implementation. This can show developers a more streamlined method of doing things, while proving the popularity and rigor testing it.

This is my goal in writing usershowidle.js:


 * A javascript implementation that would activate in certain namespaces and looks for a trigger object.
 * When found, the script then would iterate over specifically-classed objects configured to show a user's status
 * Each such object would create one API call, checking for the last edit or log entry of the specified user. In this way it is no more stressful to the backend servers than checking Special:Contributions.
 * Upon return of the API call, the object would then be changed to reflect the duration since that edit or action. Several API calls should be possible at once, with a modest limit per page (say 5 or 10 users).
 * Non-javascript Fallback should have _some_ functionality (a real gadget would be almost fully functional without javascript).

=Previous/Current situation=
 * Bots (all deactivated)
 * User:SoxBot_V (Soxred93)
 * User:Chris G Bot 3 (Chris G)
 * User:StatusBot (User:TheFearow|)
 * Scripts
 * WP:QUI
 * User:Xenocidic/statusChanger2.js
 * Manual
 * User:Hersfold/StatusTemplate
 * Editor_activity_indicator

=Practical=
 * Edit this page if needed, but direct discussion/comments/questions to User_talk:Splarka/userstatus.

First javascript implementation
At testwiki:MediaWiki:Common.js/usershowidle.js I have a working implementation of a javascript status script with easy to opt-in formatting and low-server-stress partially-cacheable API calls.

Ideal usage here (if ever) would be something like this in MediaWiki:Common.js:

And the code itself in that subpage. My test version of the code has a second addOnloadHook and namespace check in the called code (so as to operate as a standalone script) but this would be removed in a final version to streamline operation.

Why site-wide? As an opt-in or gadget script, this would not work. It is totally client-side and requires no edits or maintenance by the target user other than intitial setup. Were it simply a gadget, there would be a lot of inactive status indicators hanging around for most viewers.

Per my abstract points, the current implementation operates thusly:


 * A javascript implementation that would activate in certain namespaces and looks for a trigger object.
 * Activates with
 * When found, the script then would iterate over specifically-classed objects configured to show a user's status
 * Objects are [[Image:~|~px|link=Special:Contributions/~]] (more below)
 * Each such object would create one API call, checking for the last edit or log entry of the specified user. In this way it is no more stressful to the backend servers than checking Special:Contributions.
 * Does this with &list=usercontribs|logevents
 * Upon return of the API call, the object would then be changed to reflect the duration since that edit or action. Several API calls should be possible at once, with a modest limit per page (say 5 or 10 users).
 * I have the script take the above (from [[Image:]]) tag SRC attribute and change it based on the time since the last action. It also sets the title="" to the exact time since that edit/action.
 * Non-javascript Fallback should have _some_ functionality
 * The image is by default a link to the user's Special:Contributions, sorry for the convenience!

The configuration is a bit odd and mostly documented in the comment code. I'll touch it lightly here
 * var usI18n are the translations of most messages returned, which isn't many.
 * Api error is in english so the "lack of an error" error doesn't need translation IMHO.
 * The duration abbreviations aren't translated, should they be?
 * showidleDefaultTheme is the default 'theme'.
 * showidleImages is the magic. Rather than just have one set of images for a given idle-time, this one lets the user choose from a variety of predefined images, sizes, times, and number of threshholds.
 * Each theme has a set of images sorted by longest-time to shortest-time (in seconds).
 * If the user's idle is more than the time indicated in gt, then img is shown, else the next one is checked.
 * You can define two images, or 50, with any range of seconds you want.
 * I considered having this configurable in the wikicode, but that would be a horrible mess of hidden spans. Ugh!

Client side usage is pretty straightforward. The simplest application is a span around an image (not necessarily in the activation div): &lt;span class="user-status us-nolog us-theme- THEME "&gt; &lt;/span&gt; An example implementation would be:

Notes:
 * The image can't have any thumb, frame, border, or float.
 * The image should be the same size and shape as the theme images, ugly browser sizing will take effect in the case of size mismatching.
 * class user-status is required.
 * class us-nolog prevents log entries resetting your user status. You can actually have a status for each (contribs, and contribs + logs).
 * class us-theme- needs the exact case and name of a theme, fails to default if none found.
 * Code requires you to link to your contributions with link=. This gives it a hardcoded fallback without JS.
 * Ideally, the base image should probably indicate an 'unknown' status.
 * I built the current example themes from scrounging around on commons. Themes based on uploaded images custom-made would work better. But I didn't wanna spam commons.

Testing needed
Needs to be tested in various user browsers. You can check out testwiki:User:Splarka/idle or create a user or user talk page there with similar code. Bugs can be directed to this talk page.