E2 Client Developers (clientdev)

  • Do you think the Java Chatterbox is lame, and think you can do better?
  • Do you like the E2 node tracker, but think it can be improved?
  • Does your computer catch on fire from all the super buggy pre-alpha quality software you test?
  • Are you fluent in the programming language Ada?

If you said yes to any of those questions (except the last one - you need serious help if you know Ada that well), join clientdev so everyone can share in the misery together.

Clientdev Home

Venerable members of this group:

N-Wing, Devon, sleeping wolf, Toxick, jobby, rdude, jaybonci@, rycerice, Illumina, ascorbic@, call, ccunning, Oolong@+, wonko, Anml4ixoye, Ahab, Theus, Error404, spiregrain, in10se, ssd, elem_125, alisdair, Simpleton, dTaylorSingletary, kozmund, RPGeek, QuietLight, MALTP, BlakJak, StrawberryFrog, weivrorrim, Shatner's Bassoon, ariels, isogolem, themanwho, booyaa, jrn, OldMiner, jonas, DTal, in10se, quintopia, Old_New
This group of 44 members is led by N-Wing

Homenode List Generator
or
How to generate obtusely coy lists for your homenode

Part 2 of The "Wick Has Too Much Time On His Hands" Files1

Current source version: 1.1. Please download the new source code if yours is an earlier version.

A clientdev document intended for mass-consumption.

See also clientdev: How to predict your position in the Other Users nodelet (Part 1) for more sloppy perl hackery and irregular/excessive diction.


(r) haze says Using it seems to get attention to old nodes. Way cool


What It Does:

This client automates the task of generating obtusely coy lists that concisely summarize your "best" and "worst" writeups.

"Whoa! Just a moment there cowboy... 'Best' and 'worst' according to whom and in what sense?" you probe, momentarily clenching and unclenching your fists.

Well, I am glad you inquire, since my intention in having these obtusely coy lists on my homenode (and in releasing the source code to this script) is to prompt you to ask these very questions and think about them very hard.

The short answer is "best" and "worst" in the eyes of other users of E2, according to several metrics: number of votes, reputation, and goodness. (This last metric is explained in the FAQs at the end of this writeup.) You will have to figure out the long answer yourself.

Specifically, the script will generate six lists for your home node, each containing five elements in descending order. The lists are:

  • 5 Most Voted-Upon Writeups
  • 5 Least Voted-Upon Writeups
  • 5 Highest Goodness Writeups
  • 5 Lowest Goodness Writeups
  • 5 Most Reputable Writeups
  • 5 Least Reputable Writeups

For an example of what these obtusely coy lists look like, visit my homenode. Please look at the lists now, as the rest of this node will make more sense that way.

The following users have /msg'ed me to tell me that they have lists on their homenodes:


Requirements:

You will need Perl and curl to run the script.

You will need to change the username and password at the head of the script so that the script can log in and download your vote data.

If you have a lot of writeups, please do not run this script too frequently (more than once a day), as generating the list of all your nodes incurs server-side load proportional to your writeup list length.


FAQ's:

What is "Goodness"?

"Goodness" is an alternate evaluation metric that you may find more meaningful than reputation. It is the percentage of votes cast for a writeup that are upvotes. It ranges between 0.0 (no upvotes) and 1.0 (all upvotes), inclusive.

For example, a writeup with 16 upvotes and 9 downvotes has a goodness of 16 / (16 + 9) = 0.64.

I have generated the list and put it on my homenode. Now what?

/msg me and, if you do not mind, and I will add you to this writeup in a list of users with lists on their homenode. Then, sit back and wait for the XP to come in droves.

Facetiousness aside, since adding lists to my homenode I have noticed that voting on my nodes has not increased, rather stayed relatively constant but more evenly spread across my nodes.

I do not have Perl or curl on my computer and I am too lazy/intransigient to figure out how to run the script on my system. How can I too generate obtusely coy lists for my homenode?

You will have to wait for integration of the list generator with the E2 Node Trackers.2 conform has agreed that I could submit a patch for his node tracker. Apatrix and accipiter do not want to extend their node trackers, but I am sure they could be sweet-talked.

Keep your eyes peeled, like little grapes.

I like to keep my skeletons in my closet. How do I remove the "Least Reputable Writeups" or "Lowest Goodness Writeups" list?

The hard way: Comment the line out of the source code.

The easy way: Delete those lines from the output.

I do not want my lists to have 5 writeups each. How do I increase or decrease the list length?

Change the $list_length variable at the head of the source code. I would be interested in seeing whether M-noders with long lists have a lot of cross-fertilization across their lists, or there is little duplication of writeups across the lists.

I am not obscenely and shamelessly self-promoting nor do I like to be obtusely coy. Why would I want these obtusely coy lists on my homenode?

Because they are interesting statistics?

You must have some prurient fascination with voting or else you would have not read this far. The list will make it easier to understand how your nodes are received by the public and tailor your writing in the future.

Specifically, it will answer three questions:

  • (Votes) What sort of writeups are heavily read and cause reader response?
  • (Reputation) What sort of writeups will garner the most XP?
  • (Goodness) What sort of writeups are well-received, despite perhaps being relatively unknown and unvisited?

High goodness nodes will probably be those with no downvotes. The respective writeups will probably be very solid content nodes onnon-controversial topics.

The low goodness nodes may surprise you. Some of the most high-rep nodes on E2 are controversial and may have low goodness.

Ultimately, it comes down to fascination with statistics. If you still do not understand why one would want such lists on one's homepage, then you never will. I will go so far to explain that some of us are preoccupied by numbers, lists, and statistics. If you are not one of them, you will never understand.

Why "Highest Goodness" and "Lowest Goodness" and not just "Best" and "Worst"?

You haven't been paying attention, Buckwheat. Go back and read the What It Does section.

Good point. What about "Most Good" and "Least Good" so that you maintain consistency with of the usage of "Most" and "Least"?

This concept belongs in the noder lexicon. It is a relevant and informative measurement that someone should have thought of a while ago.

If you speak of how "good" a writeup is, it is ambiguous whether you are referring to this specific goodness metric or just an abstract sense. "Goodness" as an unambiguous term .

Another good point. What about "Most Goodness" and "Least Goodness" so that you maintain consistency with of the usage of "Most" and "Least"?

No. That does not parse and it too is inconsistent. "Goodness" is a noun, whereas "reputable" and "voted-upon" are adjectives.

And stop saying "good point", you incessant, unrelenting sycophant! You have the source, what more do you need from me?

Back off, Poindexter! I'm supposed to be asking the questions!

If you must know, I need you to integrate the source with the E2 Node Tracker. I was not really planning on running the script on my system anyway, I don't have Perl installed. I just like reading frivolous prose that leads me around by the nose and puts words in my mouth.

Good point.

I found a bug! What should I do?

Horrors! /msg me and tell no one else.


Code:
#!/usr/bin/perl
# Homenode List Generator
# by Wick
# Version 1.1
# This code falls under the GNU General Public License

$user = "wick";
$passwd = "me and E2, sitting in a tree";
$list_length = 5;

# Hardcode the URL of the User Search XML Ticker II
$url = "https://www.everything2.com/index.pl?node_id=1291794"
        . "&op=login&user=$user&passwd=$passwd&nolimit=1&nosort=1";
$txt = `curl -s '$url'`;

sub print_list {
        ($l, $d, $v, $txt, $n) = @_;

        $lst = "null";
        @newl = ();
        @curl = ();
        for ($i = 0; $i < scalar @$l and scalar @newl < $n; $i++) {
                if ($lst != $$l[$i]{$v}) {
                        push @newl, sort { $b->{votes} <=> $a->{votes} } @curl;
                        @curl = ();
                }
                push @curl, ($$l[$i]);
                $lst = $$l[$i]{$v};
        }
        print "<p align=\"$d\">\n";
        print "<b>$n $txt</b><br>\n";
        for ($i = 0; $i < scalar @newl; $i++) {
                if ($i != 0 and $newl[$i]{$v} == $newl[$i-1]{$v}) {
                        $tied = " (tied) ";
                } elsif ($i != scalar @newl - 1 and $newl[$i]{$v} == $newl[$i+1]{$v}) {
                        $j = $i + 1;
                        $tied = " (tied) ";
                } else {
                        $j = $i + 1;
                        $tied = " ";
                }
                $c = $newl[$i]{"cools"};
                $ctxt = "";
                $ctxt = " <b>$c" . "C!</b> " if $c != 0;

                print "$j$tied\[$newl[$i]{name}\]$ctxt<br>\n" if $d eq "left";
                print "$ctxt\[$newl[$i]{name}\]$tied$j<br>\n" if $d eq "right";
        }
        print "</p>\n\n";
}

@wutxt = split(m|\</wu\>|s, $txt);
@wus = ();
@wus_votes = ();

foreach $w (@wutxt) {
        $cools  = 0; 
        $up     = 0;
        $down   = 0;
        $name   = "";

        $cools  = $1 if $w =~ m/cools="([0-9]+)"/;
        $up     = $1 if $w =~ m/up="([0-9]+)"/;
        $down   = $1 if $w =~ m/down="([0-9]+)"/;
        $name   = $1 if $w =~ m/>([^(<>]+) \([^\)]*\)</;
        next if $name eq "";
        $votes  = $up + $down;

        if ($votes == 0) {
                $goodness = "undefined"; 
        } else {
                $goodness = $up / $votes;

                push @wus_votes, ({cools => $cools, ups => $up, downs => $down,
                                rep => $up - $down, votes => $votes,
                                goodness => $goodness, name => $name});
        }
        push @wus, ({cools => $cools, ups => $up, downs => $down,
                        rep => $up - $down, votes => $votes,
                        goodness => $goodness, name => $name});
}

$gmt = gmtime();

print "(List generated $gmt GMT ";
print "by the [clientdev: Homenode List Generator|Homenode List Generator].\n";
print "Goodness is the percentage of votes that are upvotes.)\n";
@sorted = sort { $b->{votes} <=> $a->{votes} } @wus;
print_list(\@sorted, "right", "votes", "Most Voted-Upon Writeups", $list_length);
@sorted = sort { $a->{votes} <=> $b->{votes} } @wus;
print_list(\@sorted, "left", "votes", "Least Voted-Upon Writeups", $list_length);
@sorted = sort { $b->{goodness} <=> $a->{goodness} } @wus_votes;
print_list(\@sorted, "right", "goodness", "Highest Goodness Writeups", $list_length);
@sorted = sort { $a->{goodness} <=> $b->{goodness} } @wus_votes;
print_list(\@sorted, "left", "goodness", "Lowest Goodness Writeups", $list_length);
@sorted = sort { $b->{rep} <=> $a->{rep} } @wus;
print_list(\@sorted, "right", "rep", "Most Reputable Writeups", $list_length);
@sorted = sort { $a->{rep} <=> $b->{rep} } @wus;
print_list(\@sorted, "left", "rep", "Least Reputable Writeups", $list_length);


1 The title suggested by an insulting softlink ("You have far too much time on your hands") of clientdev: How to predict your position in the Other Users nodelet. A message to this Wildean rapier wit: I spent thirty minutes writing the code that later became one of my most well-received writeups. You spent ten minutes hitting reload. Who really has far too much time on their hands, you silly twat?

2 If you are really dying to get list output now, then change your password to a temporary one, /msg me with this password and what list length you want, and I will run the script for you and post the results in my scratchpad. I have done this for TheBooBooKitty.

This is a little complicated, if you spot any mistakes *please* /msg me.

Introduction

Many people have written little scripts and utilities designed to work on information from e2. At first, people extracted the information they required from the HTML you and me view every day on the site. However, this was buggy and required modifying for every theme, upon anyone changing the layout, etc. So along came the old XML tickers, still retrieved via HTTP, which you can find at the top of Everything Data Pages. And so did they provide the basic information we all love, and scripts and utilities such as the E2 Node Tracker and the Java Chatterbox used them. And also provided was the XML displaytype, which edev people could use to view their own nodes. And the magnificent nate made this buggy displaytype available to all to view e2nodes and others writeups, but it was buggy and exported minimal information. And so wasn't incredibly useful.

And so, the beloved JayBonci, after much prodding from me and my quest to write e2client, has developed a new set of XML tickers! They produce well-formed, valid XML, and replace the old tickers entirely, although they're still there for backwards compatibility. But you need not use them any longer! They have been cast off a cliff, impaled on rocks and left there to die, as they deserve! The new tickers export a lot more information, and have been designed so that, when correctly used, they add very little to server load. And displaytype=xml has also been replaced! We now have displaytype=xmltrue, which exports all available node information from a variety of nodetypes.

One requirement of all clients is to assume a server error on malformed elements. This is because of in case of an actual server error (yes, we all know how perfect our code runs and how infrequently one of the boxes does not run out of memory), the output will in fact be mangled. If you encounter a server error, please try to reload the page in a minor amount of time, and fire a decent user error off. This is a general limitation to ecore in the sense that this is only xml-ish behavior, and does not reflect any underlying changes to the core.

- jaybonci

Note that almost everything - node titles, document text, etc - is passed through the encodeHTML function before being output. This replaces < with &lt;, > with &gt;, & with &amp; and " with &quot;, which is obviously necessary for it to be valid XML (as, for instance, the HTML of very few writeups would turn out to validate as XML). So you'll probably want to reverse this before actually using the data.

Also note that you'll probably want to pass a login cookie along when you're requesting all this stuff! You can either construct it manually (it's a pretty simple structure, the password is just crypt()ed, with the first two characters of the username as the salt), extract it from an op=login, or extract it from a web browser's cookie.txt. :)

This writeup fully documents this new e2 XML functionality. I will be updating it as necessary as we update and add to the exports and/or tickers. If you'd like to discuss all this XML stuff, we have a usergroup - clientdev - for just that purpose! /msg N-Wing or JayBonci to be added. Alternatively, feel free to /msg me questions.

Node Exports

If you're in edev, you'll probably want to look at the code for this, which is in node xmltrue page. Called from this is the code for the header (xmlheader), the footer (xmlfooter) and the code to render the actual node (formxml, which just calls whichever one is appropriate for the node in question, see the links in the list below).

At present, we have exports for the following types of nodes (if you're in edev, you can view the code):

To retrieve the XML, simply add a displaytype parameter with a value of 'xmltrue' to the URL of your request. This would typically mean adding '&displaytype=xmltrue' onto the end.

So, for instance, if you were trying to retrieve the node Butterfinger McFlurry your URL might be http://www.everything2.com/?node=Butterfinger+McFlurry&displaytype=xmltrue. If you already had the node_id (which is 980113) and wanted to avoid the need for the server to look the name up, you might use http://www.everything2.com/?node_id=980113&displaytype=xmltrue.

But wait! If you're like me, you don't want the server to parse the links for you, you want them left in [link] form, with the square brackets. In that case, the 'links_noparse' parameter, which must have a value of '1' to work, comes to your rescue! So you'd request http://www.everything2.com/?node_id=980113&displaytype=xmltrue&links_noparse=1.

Okay, so, we've worked out where the code is and how to request the XML. Now you'll be wanting to know the format of the xml... well, here's an example.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<node node_id="980113" createtime="2001-03-12 17:25:41" type_nodetype="116" 
 xmlns="http://www.everything2.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.everything2.com/?node_id=1259759">
<type>e2node</type>
<title>Butterfinger McFlurry</title>
<author user_id="381970">donfreenut</author>
node-specific data here
</node>

Okay. The first line is just a generic XML header, of course. You can ignore most of the parameters of the node tag for practical purposes; you'll probably just want the node_id and the createtime, both of which should be self-explanatory. The contents of the node tag are of course what is important: the type is the nodetype, the title is, well, the title and the author tag provides both the node_id and the name of the node creator.

The node-specific data is discussed in seperate sections, below.

Node Exports: e2node/writeup

The node exports for e2nodes and writeups are very similar, the main difference simply being that only one writeup is exported for a writeup node, whereas many are exported for an e2node.

Both e2nodes and writeups have 'softlinks' and 'firmlinks' tags. These contain of a set of e2link tags, which consist of a node_id parameter and the node name as the contents of the tag; for example: <e2link node_id="1353299">VDMSound</e2link>. The softlinks are exported in order, and the same number are exported as are available; so if you're not logged in you will recieve less.

e2nodes have a 'nodelock' tag, which, if non-empty, contains either the softlock text or text which states that the account being used is locked so it cannot create writeups. They also have a 'sametitles' tag, which can contain 'nodesuggest' tags. These tags have a 'type' parameter and contain an e2link tag pointing to the target node, in the same format as above. 'nodesuggest' tags representing users may also have a 'useralias' tag which means that the user is a chatterbox forward for another one - the aliased user is detailed in an e2link tag inside the 'useralias' one. An example of this is shown below.

<sametitles>
<nodesuggest type="user"><e2link node_id="1271581">sex</e2link>
<useralias><e2link node_id="1275765">nate</e2link></useralias></nodesuggest>
<nodesuggest type="room"><e2link node_id="1106905">Sex</e2link></nodesuggest>
</sametitles>

An individual writeup will just contain one writeup tag, whereas an e2node may contain zero, one or more writeup tags. The parameter 'no_doctext', if provided and set to 1, means that the contents of the 'doctext' tag will not be provided. An example of a writeup tag is shown below:

<writeup node_id="1186415" createtime="2001-10-25 10:05:30" type_nodetype="117" marked="0">
<parent><e2link node_id="77439">sex</e2link></parent><writeuptype>thing</writeuptype>
<cools>
<e2link node_id="397402">moJoe</e2link>
</cools>
<reputation up="24" down="3" cast="-1">21</reputation>

<title>sex (thing)</title>
<author user_id="1082371">Mikkel</author>
<doctext>&lt;p&gt;A [useful] little [program] from [Nullsoft] (developers of [Winamp]).&lt;/p&gt;

&lt;p&gt;[Available] from www.nullsoft.com/free/sex/&lt;/p&gt;</doctext>
</writeup>

The 'marked' parameter is normally 0, but is 1 if the writeup is in the node row weblog, normally known as being "marked for destruction". The 'parent' tag points to the parent e2node, and is only really useful in writeups. The 'reputation' tag only appears if you've voted on, or are the author of, the writeup in question. I'd hope the rest should be pretty obvious from the example.

Node Exports: user

This is pretty simple. I'm just going to give you an example and let you work it out from there. The parameter 'no_doctext', if provided and set to one, means that the contents of the 'doctext' tag are not exported, to save bandwidth if you don't need it. The 'image' tag is empty if the user has no homenode image. The 'cools' tag doesn't appear if the user hasn't cooled any writeups. Note that the creation time is exported in the node header, and hence is not duplicated here.

<doctext>Homenode text here</doctext>
<experience>1234</experience>
<lasttime>2002-09-01 11:04:55</lasttime>
<level value="3">3 (Acolyte)</level>
<writeups>80</writeups>
<image>images/userincoming/fuzzie.jpeg</image>
<lastnoded>
<e2link node_id="1353299">VDMSound</e2link>
</lastnoded>
<cools>12</cools>
<userstrings>
  <mission>Monkeys!</mission>
  <specialties>Soy!</specialties>
  <motto>Pants!</motto>
  <employment>Lesbians!</employment>
</userstrings>
<groupmembership>
<e2link node_id="838015">edev</e2link>
</groupmembership>
<bookmarks>
  <e2link node_id="1354310">Binary literals in C (thing)</e2link>
  <e2link node_id="1228978">Yay! We're doomed!</e2link>
</bookmarks>

Note that groupmembership only exports edev, gods and content editors, just as it is on homenodes. Why? Because those three groups are already loaded when we get to this point, as they're used by various other bits of the code on each page, which means no extra server load.

Node Exports: superdoc

Okay, this is icky. When a superdoc is requested, the code is run, and the results placed in a 'superdoctext' tag. You should be warned, however, that many superdocs manually generate URLs, and as such, links_noparse may not work.

There are two possible parameters which can be used here - if you want to use either of them, it's recommended that you pass them with every request, because you obviously usually don't have a way to work out whether a node is a superdoc or not before you request it. The parameters, both of which have to be set to '1' in order to work, are 'no_findings' and 'no_superdocs'. They both do the same thing, the first just for the Findings page and the second for all superdocs, which is to disable generation and output of the superdoctext tag. This reduces server load for those cases in which you don't want the pages - clients will probably just use no_findings, as they'll be using the Search Interface (below) for this purpose (for instance, when e2client retrieves the Findings superdoc, it automatically sends another request to the Search Interface, so it would be pointless to generate/download the superdoc text).

Node Exports: usergroup

Again, this one is just an example. The contents of the 'description' tag are not exported if the parameter 'no_descrip' (which must, as usual, be '1') is provided. The 'weblog' is used for such things as edevify! and clientify!, and is only exported if the logged-in user is a member of that usergroup.

<description>TEXT HERE</description>
<weblog>
<e2link node_id="1350387">On Making E2 Distributed (idea)</e2link>
<e2link node_id="1338222">edev: User Data (idea)</e2link>
<e2link node_id="1337951">edev: User Data (idea)</e2link>
<e2link node_id="1329316">Mozilla Everything2 Search Plugin (thing)</e2link>
</weblog>
<usergroup>
<e2link node_id="459692">JayBonci</e2link><e2link node_id="220">nate</e2link>
<e2link node_id="9484">dbrown</e2link><e2link node_id="2447">sgtbaker</e2link>
</usergroup>

Node Exports: room

If you hit a room node, you meet the entry criteria (eg, only gods are allowed to enter Valhalla, only M-Noders in The M-Noder Washroom, etc) and you're not Guest User, then you're moved into that room. The returned xml has a 'canenter' tag which is 0 if you didn't enter the room for some reason, or 1 if you did (the usual case if you're not a guest).

<canenter>1</cancenter>
<description>room description here</description>

Tickers

Tickers are special pages which provide XML information, mostly data required for rendering nodelets, but also other information such as user search and clientdev client data. They all being with a standard XML header tag (plus maybe an inline DTD or schema or whatever), and then are all pretty much unique.

You should request them based on their node_id. And you shouldn't hardcode these node_id's into your code, if at all possible, but should instead use the Interfaces Ticker which is documented below.

Note that you can't request these with the xmltrue displaytype, you'll just get the xml header for the nodetype 'ticker'. They must be requested with the default ('display') displaytype, which you can do by simply not including a displaytype parameter with your request.

For each ticker I've provided a paragraph of explanatory text, and then example 'real' ticker output. Note that in most cases I've stripped the output down to just two or three items where there are many, and that I've obviously modified some of them considerably. :)

Interfaces Ticker

XML Interfaces Ticker; interface "interfaces"

This ticker is also available via '/interfaces.xml', which is an apache alias for the node. Why? Because this ticker is a site-independent way to retrieve tickers. You simply retrieve the xml file, lookup the node_id of the ticker you want in it, and then request that node_id. You obviously should just request this once per session, or even just request it once and then cache it.

Since the server move, interfaces.xml has not worked, presumably due to the removal of the apache alias.

<xmlcaps>
<this node_id="1261407">XML Interfaces Ticker</this>
<xmlexport iface="rooms" node_id="1254496">Available Rooms XML Ticker</xmlexport>
<xmlexport iface="search" node_id="1252400">E2 XML Search Interface</xmlexport>
</xmlcaps>

Each ticker documented here has the interface name, as provided by the 'iface' tag of each 'xmlexport' tag here, provided. So in order to download a ticker, reference your interfaces list, find the required one, get the node_id, and then download it.

Client Version Ticker

Client Version XML Ticker; interface "clientversions"

See clientdev: Registering a client for information about client registration. This ticker simply exports the information about all registered clients, mainly so that clients can automatically detect when a new version is available and suggest upgrading to the user.

<clientregistry>
<client client_id="1262679" client_class="jchatter">
<version></version>
<homepage>http://sourceforge.net/projects/jchatter/</homepage>
<download>http://sourceforge.net/project/showfiles.php?group_id=4370</download>
<maintainer node_id="9740">N-Wing</maintainer></client>
<client client_id="1262284" client_class="e2client.kde">
<version>0.03alpha</version>
<homepage>http://sourceforge.net/projects/e2client/</homepage>
<download></download>
<maintainer node_id="1167948">fuzzie</maintainer>
</client>
</clientregistry>

New Writeups Ticker

New Writeups XML Ticker; interface "newwriteups"

An integer parameter 'count' defines the number of writeups to return. It defaults to 15, and has a maximum value of 300.

<newwriteups>
<wu wrtype="idea">
<e2link node_id="1355036">Pentium (idea)</e2link>
<author><e2link node_id="1350577">carlos_avdas</e2link></author>
<parent><e2link node_id="28647">Pentium</e2link></parent>
</wu>
</newwriteups>

Other Users Ticker

Other Users XML Ticker II; interface "otherusers"

A list of users logged onto e2. An optional parameter 'in_room', with a parameter of the node_id of the room in question, restricts the output to users in a certain room. A parameter 'nosort', if set to 1, means that the output is not sorted. Please enable this and sort client-side by the 'xp' parameter, in order to reduce server load.

<otherusers>
<user e2god="1" ce="0" edev="0" xp="36251" borged="0" >
<e2link node_id="898906">Gritchka</e2link>
</user>
<user e2god="1" ce="0" edev="1" xp="23896" borged="0" >
<e2link node_id="768243">Professor Pi</e2link>
</user>
<user e2god="0" ce="0" edev="1" xp="8136" borged="0" >
<e2link node_id="7515">xunker</e2link>
<room node_id="553146">Noders Nursery</room>
</user>
</otherusers>

Available Rooms Ticker

Available Rooms XML Ticker; interface "rooms"

A list of all the room nodes, along with a link to the go outside superdocnolinks.

<e2rooms>
<outside>
  <e2link node_id="1102338">go outside</e2link>
</outside>
<roomlist>
 <e2link node_id="1062657">&amp;gt;hug)))&amp;gt;</e2link>
 <e2link node_id="1159213">Fruan's Hidden Place</e2link>
 <e2link node_id="930643">Hammock Heaven</e2link>
 <e2link node_id="1243647">House of Cheese</e2link>
</roomlist>
</e2rooms>

Universal Message Ticker

Universal Message XML Ticker; interface "messages"

Okay, this can be used to retrieve two types of messages: chatterbox messages, and your message inbox. It takes a bunch of parameters:

  • 'msglimit', an integer parameter. This should contain the id last message you have stored locally; it will only return messages which are newer than this one. If not present, all messages are returned.
  • 'for_node', an integer/text parameter. This should contain the node_id of the room and/or user you wish to retrieve messages for. If you set it to 'me', it will return your own messages. It will not work for retrieving messages from any user except yourself, nor any room except the one you are in. If not present, messages from the 'outside' room in the chatterbox will be returned, which will NOT WORK unless you're in that room. If you're not logged in, ie logged in as Guest User, you can retrieve the contents any 'public' room (this is currently outside and political asylum only).
  • 'backtime', an integer parameter. This should contain either '5' or '10', depending on whether you want the last 5 or 10 minutes of chatterbox messages to be returned. This only works if requesting chatterbox messages (ie, from a room).
  • 'nosort', which should be set to '1' if you don't want the results to be sorted. Please enable this and sort messages by their ids client-side, to reduce server load.
  • 'links_noparse', which, as with the xmltrue stuff, stops links from being transformed into <a> tags.

The first example is from the chatterbox.

<messages>
<room room_id="0">outside</room>
<topic>There's a progress we have found, a way to talk around the problem.</topic>

<msglist>

<msg msg_id="5254722" msg_time="20020901131007">
<from><e2link node_id="5404">Byzantine</e2link></from>
<txt>er, pass off, even</txt>
</msg>

<msg msg_id="5254724" msg_time="20020901131108">
<from><e2link node_id="974148">ascorbic</e2link></from>
<txt>Well, wertperch has a quote from bones on his h/n &quot;Unattributed c/p is plagiarism and
plagiarism goes, period.&quot;</txt>
</msg>

</msglist>
</messages>

And another one from my Message Inbox.

<messages>
<msglist>
<msg msg_id="5251400" msg_time="20020831181554">
<from><e2link node_id="1167948">fuzzie</e2link></from>
<grp><e2link node_id="1199641">clientdev</e2link></grp>
<txt>Jay/someone, could you add xmltrue support for rooms please? :-)</txt>
</msg>
</msglist>
</messages>

Personal Session Ticker

Personal Session XML Ticker; interface "session"

This ticker updates your session, and displays useful data like your personal nodelet, the votes/cools you have left, the amount of karma (Golden Trinkets) you have, and updates/displays your borg status. IN ORDER TO BE UNBORGED, YOU MUST EITHER REQUEST THIS TICKER OR CAUSE THE EPICENTER TO BE DISPLAYED (typically by downloading a normal (ie, web-based) e2 page). The 'forbiddance' character displays a userlock, which is the text displayed like a softlock if your entire account is stopped from posting writeups. The 'xpinfo' section only appears if your numwriteups or XP has changed since this ticker and/or the Epicenter were last executed. Note that if you're not logged in, only the 'currentuser' and 'servertime' tags are produced.

I made up a lot of the numbers in this example.

<e2session>
<currentuser user_id="1167948">fuzzie</currentuser>
<servertime time="1030887589">Sun Sep  1 13:39:49 2002</servertime>
<borgstatus value="0">unborged</borgstatus>
<personalnodes></personalnodes>
<cools>0</cools>
<votesleft>7</votesleft>
<karma>8</karma>
<experience>1203</experience>
<numwriteups>83</numwriteups>
<forbiddance></forbiddance>
<xpinfo>
 <xpchange value="1">1203</xpchange>
 <nextlevel experience="50000" writeups="999">4</nextlevel>
</xpinfo>
</e2session>

Random Nodes Ticker

Random Nodes XML Ticker; interface "random"

The Random Nodes nodelet, but an XML version! Along with that randomish witty phrase you've grown to love. You get 12 of them each time it's refreshed (every minute or so), and JayBonci says "It gets fed off a nodelet called Random Nodes XML Feed, so feel free to hit this nodelet as often as you like, it's quite cheap, I can assure you. It's also fine to hit from Guest User".

<randomnodes>

<wit>Just another sprinking of indeterminacy</wit>
<e2link node_id="408940">Oulu</e2link>
<e2link node_id="226765">Doughfaceism</e2link>
</randomnodes>

Search Interface

E2 XML Search Interface; interface "search"

A tool for searching the site using keywords, just like the search textbox at the top of all e2 pages. Pass a parameter 'keywords' with your keywords and a parameter 'typerestrict' with the type of node you want returned (probably the default which is used if you don't provide a 'typerestrict' parameter at all - 'e2node').

<searchinterface>
<searchinfo>
 <keywords>rabbit</keywords>
<search_nodetype node_id="116">e2node</search_nodetype>
</searchinfo>

<searchresults>
 <e2link node_id="1239286">Flemish Giant Rabbit</e2link>
 <e2link node_id="1228072">cutaneous rabbit</e2link>
</searchresults>
</searchinterface>

Maintenance Nodes Ticker

Maintenance Nodes XML Ticker; interface "maintenance"

Returns the contents of the boring heaven nodes setting. Used for working out which e2nodes should have writeups be hidden by default, and that's it, basically.

<maintenance>
<e2link node_id="174079">Edit these E2 titles</e2link>
<e2link node_id="171917">E2 Nuke Request</e2link>
</maintenance>

Scratch Pad Ticker

Scratch Pad XML Ticker; interface "scratch"

Returns a scratchpad, by default yours, however you can provide a 'scratch' parameter, which consists of the node_id of the user whose scratchpad you wish to view. You cannot view it unless the user has set it as shared, and you cannot view it if you're not logged in. You can also pass 'links_noparse', as with the xmltrue interfaces.

<scratchpad>
<scratchtxt user="fuzzie" public="1">text</scratchtxt>
</scratchpad>

Cool Nodes Ticker

Cool Nodes XML Ticker II; interface "coolnodes"

Returns a list of cooled writeups, with optional parameters as listed below.

  • 'writtenby', an integer parameter, containing the node_id of the user whose cooled writeups you wish to view. If not provided, displays cooled writeups by all users.
  • 'cooledby', an integer parameter, containing the node_id of the user who cooled the writeups you wish to view. If not provided, displays writeups who were cooled by any user.
  • 'limit', an integer parameter with a default and maximum value of 50, which specifies the number of writeups to list.
  • 'startat', an integer parameter, which contains the location in the list you wish to start the list at, commonly used when paging through a large list (as a list of cooled writeups is likely to be). So, for instance, you'd retrieve the second page with 'startat=50', assuming you retrieved the first with 'limit=50'.
<coolwriteups>
<cool>
<writeup><e2link node_id="1355024">Lupe Velez (person)</e2link></writeup>
<author><e2link node_id="1177778">vixen</e2link></author>
<cooledby><e2link node_id="898906">Gritchka</e2link></cooledby>
</cool>
<cool>
<writeup><e2link node_id="1355024">Lupe Velez (person)</e2link></writeup>
<author><e2link node_id="1177778">vixen</e2link></author>
<cooledby><e2link node_id="8933">Lord Brawl</e2link></cooledby>
</cool>
</coolwriteups>

Editor Cools Ticker

Editor Cools XML Ticker; interface "edcools"

Editor Cools, otherwise known as 'Endorsements'. One integer parameter, 'count', which defaults to 10 and has a maximum value of 50, which specifies the number of writeups to return. Sorted by time of endorsement.

<editorcools>
<edselection>
 <endorsed node_id="949709">fuzzy and blue</endorsed>
 <e2link node_id="1028921">I am three, she said</e2link>
</edselection>
<edselection>
 <endorsed node_id="780564">WonkoDSane</endorsed>
 <e2link node_id="576555">How to cook rice</e2link>
</edselection>
</editorcools>

Everything's Best Users Ticker

Everything's Best Users XML Ticker; interface "bestusers"

The XML equivalent of the Everything's Best Users superdoc, along with a shiny 'ebu_noadmins' parameter, which, if set to 1, doesn't include gods, and if not set or set to anything else, does include gods.

<EBU ebu_noadmins="0">
<bestuser>
 <experience>78790</experience> <writeups>1924</writeups>
 <e2link node_id="2654">Segnbora-t</e2link>
 <level value="11">11 (Godhead)</level>
</bestuser>
<bestuser>
 <experience>57476</experience> <writeups>4235</writeups>
 <e2link node_id="4586">Pseudo_Intellectual</e2link>
 <level value="12">12 (Pseudo_God)</level>
</bestuser>
</EBU>

Node Heaven Ticker

Node Heaven XML Ticker; interface "heaven"

Retrieves the contents of your Node Heaven. An optional parameter, 'visitnode_id', means that the only writeup displayed is the one matching that node_id, if one exists, and that the contents of that writeup are also provided. The writeups are sorted by title unless the 'nosort' parameter is set to '1'. 'links_noparse' is also supported, and works the same as it usually does.

<nodeheaven>
<nodeangel node_id="1231188" title="Apogee Software (thing)" reputation="8" 
createtime="2002-01-09 00:26:30">writeup text here. delete all my nodes. etc.</nodeangel>

User Search Ticker

User Search XML Ticker II; interface "usersearch"

The equivalent of User Search, but in XML form! Supports the following truly amazing parameters:

  • 'searchuser', the username to display the writeups of. If the user doesn't exist or this parameter isn't provided, it defaults to the logged-in user.
  • 'startat', for use when paging through the list bit-by-bit: defines where in the list of writeups to start output.
  • 'count', which defines the amount of writeups to output at a time, with a default value of 50.
  • 'nolimit', which, if set to '1', means that 'startat' and 'count' are disregarded and all writeups written by this user are displayed. Obviously, try to avoid using this, it involves quite a lot of work server-side.
  • 'nosort', which, as ever, should be set to '1' to disable sorting and hence reduce server load. DO IT CLIENT-SIDE!
  • 'sort', which has three possible values: 'rep', which sorts by reputation, 'title', which sorts by title, and 'creation', which sorts by creation time. Obviously this doesn't work with nosort.
<usersearch user="fuzzie">
<wu createtime="2002-08-29 10:56:05" marked="0" hidden="0" cools="0" wrtype="">
<rep up="8" down="1">7</rep>
<e2link node_id="1353814">VDMSound (thing)</e2link>
<parent><e2link node_id="1353299">VDMSound</e2link></parent>
</wu>
<wu createtime="2002-08-26 07:06:03" marked="0" hidden="0" cools="0" wrtype="">
<rep up="12" down="0">12</rep>
<e2link node_id="1352546">Visual J++ (thing)</e2link>
<parent><e2link node_id="973217">Visual J++</e2link></parent>
</wu>
</usersearch>

Raw VARS Ticker

Raw VARS XML Ticker; interface "vars"

Exports the contents of the $VARS variables you're allowed to change, doesn't work for Guest User.

<vars>
<key name="topicCbox">1</key>
<key name="noTypoCheck">1</key>
<key name="powersChatter">1</key>
</vars>

Time Since Ticker

Time Since XML Ticker; interface "timesince"

Returns the time since a set of users were seen. Pass it either the parameter 'user', with a comma-delineated list of usernames (eg 'user=JayBonci,TheBooBooKitty,nate') or the parameter 'user_id', with a comma-delineated list of user_ids (eg 'user=4653, 452753, 296735'). If you don't pass it either of these parameters, it details to returning information about the logged-in user. ascorbic notes that it's also quite useful for matching usernames with user_ids...

<timesince>
<now>2002-10-18 12:59:42</now>
<lasttimes>
<user lasttime="2002-10-17 12:20:07">
<e2link node_id="459692">JayBonci</e2link>
</user>
<user lasttime="2002-10-17 12:55:36">
<e2link node_id="1019201">TheBooBooKitty</e2link>
</user>
<user lasttime="2002-10-16 22:01:33">
<e2link node_id="220">nate</e2link>
</user>
</lasttimes>
</timesince>
(A clientdev document intended for mass-consumption. See also clientdev: Homenode List Generator.)

Introduction:

Ever since reaching level 2, I have been wondering how long it would take for my username to ascend to the top half of the Other Users nodelet. For that matter, it seemed to me that one could easily write a client to poll the Other Users ticker and, given a user's XP, one could use the data to predict the expected user's position on the Other Users list. This sort of problem really appeals to me, as E2 is a large database with a lot of information, and one can coax salient information out of the data mass with minimal effort merely by asking the right questions.

In describing my methodology and by showing you how simple the Everything XML interfaces are, I hope to spur would-be client developers to write E2 client code. My total coding time, including figuring out that the Other Users XML Ticker II exists, was half an hour. If one can get useful data from E2 after half an hour of hacking, imagine what a serious effort could produce! E2 users who know a scripting language (Perl, Python, &tc.), take this to heart and write you own clients. Go unto everything and give them source.


Methodology:

The steps I followed to obtain my results are as follows:

  • Write a client, other-users.pl, to poll the Other Users nodelet every fifteen minutes and save the data to other-users.out.
  • Write a program, stats.pl, to analyze the data and produce statistics.
  • Collect data over a day that indicates the position on the Other Users nodelet, on a scale from 0.0 (lowest on the list) to 1.0 (highest on the list), given the user's XP. For example, in one instance, an XP of 262 had Other Users position 0.333, that is, one-third of the way from the bottom.
  • Run stats.pl on other-users.out and analyze results.

Bear in mind that I know nothing about the internals of the everything2 code base. But, such knowledge is not necessary for client development. Additionally, you will not need to muss with parsing HTML, as the Everything XML interface make it a snap to obtain real-time data from E2.

The Other Users XML Ticker II will spew the current Other Users list as a list of the following XML items:

<user e2god="0" ce="0" edev="1" xp="204" borged="0" >
<e2link node_id="1290327">wick</e2link>

Given the simplicity of the application, XML parsing was not necessary. The script extract sthe XP's using a simple regex. The position on the Other Users nodelet was the same as the position in the XML list, so the position is obtained by dividing the XML list position by the number of entries in the list.

Results:

The Other Users nodelet was polled every fifteen minutes from 5:00 EST 28 August 2002 for twenty-four hours. Although the standard deviations stabilized after a few hours (indicating that further data would provide no greater accuracy), I ran the script for a day.

For all the data collected, I split the output into XP ranges based upon level requirements. (This was purely arbitrary.) More narrow ranges are possible, but the results for more narrow ranges are not much more accurate or informative.

In the following table, mid is the average (expected) Other Users position for that XP range. dev is the standard deviation of the position. low and high are two standard deviations away from mid. In other words, for the given XP range, there is an 86% chance that the Other Users position will be between low and high.

      XP range        low     mid     high      dev
-----------------------------------------------------
  thefez -    50     0.000   0.114   0.269    (0.078)
      50 -   200     0.143   0.275   0.406    (0.066)
     200 -   400     0.233   0.350   0.467    (0.059)
     400 -   800     0.294   0.409   0.523    (0.057)
     800 -  1350     0.359   0.490   0.621    (0.065)
    1350 -  2100     0.446   0.570   0.694    (0.062)
    2100 -  2900     0.515   0.636   0.757    (0.060)
    2900 -  4000     0.575   0.704   0.832    (0.064)
    4000 -  7500     0.681   0.803   0.926    (0.061)
    7500 - 13000     0.809   0.887   0.966    (0.039)
   13000 - 23000     0.885   0.940   0.994    (0.027)
   23000 - 38000     0.943   0.974   1.000    (0.016)
   38000 - nate      0.976   0.994   1.000    (0.009)

As you can see, the position of XP<50 noders is relatively highly variable. This can be attributed to fickleness of newbie usage patterns. Between XP=50 and XP=7500 position variability remains relatively constant, until it drops of sharply at high XPs, where a high position is assured with little variance.

The average XP of someone with position 0.5, halfway up the list, is 1075. (Standard deviation is 0.064.)


Code:

Given the nature of this project, comments were added post hoc.

The following falls under the GNU General Public License.

other-users.pl:

#!/usr/bin/perl

# Hard-code the URL of the Other Users XML Ticker II
$url = 'http://www.everything2.com/index.pl?node_id=1291746';
# Download the XML ticker output
$users = `curl -s '$url'`;
@u = ();

# Push the XPs onto a list
while ($users =~ m/xp="(-?[0-9]+)"/) {
        push @u, $1;
        $users =~ s/xp="(-?[0-9]+)"//;
}

# Output a list of values:
# position    XP
$un = scalar(@u) - 1;
for ($i = $un; $i >= 0; $i--) {
        print (sprintf ("%.3f %d\n", (($un - $i) / $un, $u[$i])));
}

Edit your crontab (using crontab -e) to include the following line. This will poll the Other Users XML Ticker II every fifteen minutes until you disable the line. You will have to edit the directories to match those on your system:

0,15,30,45 * * * *   /usr/bin/perl /home/wick/e2/other-users.pl >> /home/wick/e2/other-users.out

stats.pl:

#!/usr/bin/perl

# Use Statistics::Descriptive module to calculate the standard deviations
use Statistics::Descriptive;

$big = 9999999;
# Put data in buckets according to level XP qualifications
@xp = (-$big, 50, 200, 400, 800, 1350, 2100, 2900,
        4000, 7500, 13000, 23000, 38000, $big);

# Read and chop up data from other-users.out
@us = split(/[\r\n]+/, `sort -n +1 other-users.out`);

$i = 0;
# Depending on which bucket the XP belongs, store
# the position data
for ($j = 0; $j < scalar @us; $j++) {
        $stat[$j] = Statistics::Descriptive::Sparse->new();
        if ($us[$j] =~ m/([0-9\.]+) ([\-0-9]+)/) {
                $i++ while $2 >= $xp[$i+1];
                $stat[$i]->add_data($1);
        }
}

# For each bucket, calculate and output the mean
# and standard deviation of the position values
for ($i = 0; $i < scalar(@xp) - 1; $i++) {
        $m = $stat[$i]->mean();
        $d = $stat[$i]->standard_deviation();
        print sprintf("%d - %d\t%.3f\t%.3f\t%.3f\t(%.3f)\n",
                $xp[$i], $xp[$i+1], $m - 2 * $d, $m, $m + 2 * $d, $d);
}

One of the difficulties [for Palm developers] is that there's no one killer program Palm owners want to go into a store to buy. In fact, aside from the built-in programs for the Palm, no application is on more than 10 percent of handhelds.

-- CNet article, "Can developers pull dollars from Palms?", Feb. 8, 2002

The Nokia Communicator. The Handspring Treo. The Samsung i300. Combined with about a thousand other mobile phones offering "Wireless Web" access in various shapes and forms, it's clear that the Internet is finally going mobile. The bandwidth is a bit low yet, but that should be changing as it becomes more popular. But the problem is, it's not all that popular. People everywhere are using mobile phones for SMS -- the small-screen equivalent of e-mail -- but the Internet and all its content is getting ignored.

Not for lack of services, mind you. Yahoo! is entirely handheld-friendly, and people still aren't using it in droves, despite the availability of things like weather, stocks, sports scores, movie listings, the latest news and so forth. Part of this is because the screens are so darned tiny, but I don't think that would stop people if they wanted to read badly enough. No, the real problem is that Yahoo! doesn't offer any compelling content online that a mobile phone user couldn't get just as easily by picking up a local newspaper -- either today's or tomorrow's. Sure, I can get sports scores for cities halfway around the globe, but why would people want to? I have Yahoo! on AvantGo on my handheld, but the only thing I ever use it for is to look up movie listings occasionally -- and that's because I'm just too lazy to find the newspaper.

Despite all the hype about the wonders of the wireless Web, the available mobile devices are not able to provide a wireless Web adventure that would impress anybody. Transmission speeds lag behind the dial-up access rates the average AOL user gets at home. And the big question remains, who needs it?

-- NewsFactor.com article, "Where Is the Wireless Web?," Feb. 13, 2002

So portal-type content isn't really driving people to use the Web wirelessly. What would? The kind of content you can't get in a newspaper, obviously -- niche reviews, obscure factoids, interactive discussions. These things are available on the Web, but most of those sites aren't designed for small screens. Browsers for those devices, like Handspring's Blazer browser, try to optimize 800x600-resolution Web pages for 160x160 screens, but they can only do so much. Try surfing the Web using the text-only Lynx browser and you'll see why: complex layouts using tables and JavaScript-dependent features cripple browsers that provide anything less.

The Wireless Web should be the mobile device's "killer app," but it's not. All the truly compelling sites are slow and badly formatted, and all the fast and well-formatted sites lack compelling content. Most sites try to offer as much information and navigation as possible in one page, filling up the left or right columns (or both) of every page with the same stuff and leaving the main page available for specific content. Everything2 does this, too. E2 is generally easy to use with Lynx, but all those wonderful nodelets still sit at the bottom of the page while the Search stays stubbornly at the top, forcing users of non-graphical browsers to scroll and squint to identify either one.

In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitchhiker's Guide has already supplanted the great Encyclopedia Galactica as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older, more pedestrian work in two important respects. First, it is slightly cheaper; and second, it has the words DON'T PANIC inscribed in large friendly letters on its cover.

-- "The Hitchhiker's Guide to the Galaxy" by Douglas Adams

E2 is never going to be popular with mobile users in its current state. But it should be. After all, E2 offers all the things the portal sites don't, and all in one place. Movie and book reviews, by people who aren't paid to hype them. Biographical information on celebrities and historical figures. Popular culture. Definitions. Textbook knowledge. Famous poetry and prose, both original and not. Humor. Blogging. Eclectica.

H2G2 tries to be what Douglas Adams' Hitchhiker's Guide wanted to be, but fails for a number of very good reasons. Plus, E2 offers a community spirit and a very open system for adding and editing content. At the time of this writing, E2 has nearly half a million distinct writeups by some 40,000 distinct users. And none of it is available in any other, single location.

We are the killer app. The world just doesn't know it yet.

I am pleased and proud to announce E2's new better XML output. This increases our current set of XML ticker functionality, plus provides a better and cleaner set of XML (well formed, but not yet validating) displays for this site.

clientdev: new XML ticker output, by JayBonci

I would like to put forth a vision for all the developers who use and enjoy E2: Build a wireless client to the full database that is small, fast, and easy to use. And, of course, freely available to anyone who wants to use it. This would be the killer app for wireless handhelds throughout the English-speaking world.

Imagine, for a second, being able to look up honest movie, music or book reviews right in the store before you buy. Or accessing a travel guide to New York City while you're waiting for the subway. Or getting some fun information on your favorite sports team's opponent rather than just statistics from last season. Or hearing a strange piece of slang while visiting a distant city, or a technical term while reading a magazine article, and being able to look it right up. Or just wanting something random to read until your class starts or your meeting ends without having to download it first. Imagine how much the rest of the world would like to be able to do all that, too.

But E2 isn't good for wireless use yet, because it requires a Web browser and because it's too friggin' slow. I don't mean server loads. I mean the nodes that contain too many writeups with too much text for a slow mobile modem to handle, the search tools that are too far away for a small screen, the soft links and nodelets that provide quick navigation for a user of a graphical browser, but just slow things down needlessly for those who don't.

E2 has all the content it needs to be a wireless hit. It just needs an optimized interface.


Things To Do

These are the major issues I think a wireless, mobile version of E2 would need. Many of them are things that would or should never be done on the graphical, PC-based version of E2. Nevertheless, a different environment requires certain changes.

  • Forget the Wireless Web. A slimmed-down version of E2 for portable browsers is not the answer. Certain elements, like the Search bar, need to be on-screen at all times or at most a single click away. A user who has his User Preferences set up one way for the graphical E2 might want them a completely different way for the mobile E2. What we need is an entirely new client that accesses E2 using XML, and then displays it in a interface designed for small screens.
  • Trim the Extras. Nodelets must go. Softlinks must go. Useful features like adding a writeup or gabbing in the Chatterbox should be available by selecting a menu or clicking a fixed, non-scrolling button. Bookmarks of favorite writeups should be tucked away in their own menu. The text display of the client should display nothing but writeup headers and text, using the same HTML formatting that we support now.
  • Optimize the Writeup Display. E2's current node layout is great for the WWW, bad for the Wireless Web. Getting several writeups at once would be prohibitively time-consuming on low-bandwidth, mobile connections. Only one writeup should be displayed at a time, with single-button access to the last or next writeup. Writeup titles should be static while writeup headers and content should scroll. Voting up or down should be as easy as pressing or tapping two buttons (one would be prone to accidents). Writeup headers should be kept to the bare minimum -- author, type, date, and reputation.
  • Get It Everywhere. PalmOS. PocketPC. Whatever the Nokia Communicator uses. As long as they're looking for developers and "killer apps" to sell their new wireless devices, we should take them up on it. This client should work on every popular mobile wireless device that's on the market, and it should work as identically on every one of them as possible. Obviously, different screen sizes and resolutions (especially the elongated Communicator screen) will require some major changes to the interface layout, but there's no reason we can't keep the same on-screen tools and menus, just stored in different places. UPDATE: There's a book on the way titled Flash Enabled: Flash Design and Development for Devices (http://www.amazon.com/exec/obidos/ASIN/0735711771) that discusses designing Macromedia Flash for portable devices. I'm convinced that Flash, especially the newly-released Flash MX, will be the way to go. Many smart phones can use it, PocketPC can use it, and I believe it's coming to the PalmOS very soon. With built-in XML support, this will be the fastest way to produce a multi-platform client (if not exactly the most backwards-compatible).
  • Let It Make Money. Yes, by all means, give the client away, especially to device manufacturers. And keep E2 on the WWW free for everyone. But the mobile client is a special "extra," and if it becomes popular, it should offer the opportunity to make money for its developers and servers. If we're going to tax the server extra with this, we should get something back, right? So let the client be a 30-day trial, or think of how to sell $2-a-month subscriptions to access the content with it. Or else develop a whole new way to sell ad space on the thing -- let Barnes and Noble put a blurb beside every writeup containing the word "novel," for instance. I can call anyone cheaply from my home phone, but I pay a privilege to do it on the go; it's fair and reasonable for E2 to expect the same.
  • Involve Your Friends. Yeah, maybe you're whiz-bang enough to develop something like this on your own, but why when you can get help? Join the clientdev group here on E2, find out what you need, stick it up on SourceForge, and do your darnedest to let everyone who owns a mobile device know what it is and what it does. They don't have to know or like E2. They don't even have to see the word "Everything2" anywhere on it. They just have to use it and love it. And if they offer suggestions, write 'em down and try to add 'em in. Again, just because E2 on the WWW doesn't do something a certain way doesn't mean a wireless client can't.

Who We'll Need

  • Anyone familiar with the development tools for existing mobile devices, especially PalmOS, and/or anyone willing to learn how they work.
  • Anyone familiar with XML and how to build and parse it, and/or anyone willing to learn.
  • Edev members to build a few new doctypes that the mobile client can access. Existing doctypes are designed for the graphical WWW; we need new ones just for mobile clients. (Example: a new type of node document that contains only one writeup and a link to previous/next ones.)
  • E2 gods who can make the above things happen on the server side.

Interested? Join clientdev and tell us what you can do.