The screenshot below illustrates how Denby uses it in the most simple case — passing a link without choosing a particular service — and a more complex case, using bit.ly with login/key authentication.

As Denby is adopted beyond our cadre of keenly interested alpha testers, users are less likely to be forgiving of faults or crucial feature absence, so I’d like to see how much of the low-hanging fruit I can pick off before our next big leap in usage. (Which, by the way, is likely to be this weekend, soon after the new site streams based server goes live!)

To do that, I need your help.

A deceptively simple question for current and aspiring alpha testers: What do you need to use Denby full-time? Which absent feature has you regularly resorting to the Twitter website? What’s missing?

I’ll start!

The two main things for which I regularly visit the website are:

1. Viewing user profile information, especially of recent followers, retweeters or favor–*ahem*… favoriters.
2. Twitter history backfill, most obviously and inconveniently absent when I start Denby.

I’ll be working on both of these today… and I’m sure I’ll be pleasantly distracted by your great suggestions too.

And for amusement value, here’s an early twitbox prototype:

The client side of Denby is split into two pieces: the core communications module, which provides a programming interface to the Denby server; and the user interface module, which howitzers the awesome straight at your face.

As you can tell from previous posts, my focus right now is a multi-column, “death star console” user interface, but I do plan for more (single-column, mobile, etc). So in a way, the command line in your browser console is just another user interface profile.

Now for some technical details.

A set of functions on the server side is exposed to the client via JSON-RPC over the same Socket.IO pipe from which all your streaming tweets arrive. In the optimal case, this is a websocket or flashsocket, so it’s designed for bidirectional chatter.

When you Denby.send(), a JSON-RPC packet with a unique ID is sent to the server, which does whatever you’ve requested and sends back a response with the same ID attached. That way, the client can keep track of requests and responses.

I have tried to make this as seamless as possible, though I’m still cheating a bit. Surely it would be nicer to call, say, Denby.updateStatus() versus Denby.send('updateStatus')? I will eventually get there, but am also striving to get the balance right between getting out of alpha mode, surfacing features and gold-plating the infrastructure.

The example below shows one of the simplest functions, updateStatus(text, [params]), called on the server by Denby.send(method, [arg1], [arg2], [argN], callback). I made it accept an arbitrary number of arguments before the callback just to make things a bit easier. The callback is of course a local function, remembered by the JSON-RPC client and called when the server responds.

For the curious, here’s what it looks like in JSON-RPC. First, the client:

{
  "jsonrpc": "2.0",
  "method": "updateStatus",
  "id": 1294764619011,
  "params": [
    "Showing off the @hellodenby \"command line\" for a screenshot. #denby"
  ]
}

Then hopefully pretty soon after, the server:

{
  "jsonrpc": "2.0"
  "id": 1294764619011,
  "result": {
    "created_at": "Tue Jan 11 17:08:34 +0000 2011",
    "id": 24875324479115264,
    "id_str": "24875324479115264",
    "source": "<a href=\"http://www.hellodenby.com/\" rel=\"nofollow\">Denby DEVEL</a>"
    "text": "Showing off the @hellodenby \"command line\" for a screenshot. #denby",
    "user": { ... }
  }
}

(Crap, looks like both the Flash and WebM versions cut out after about 7 minutes, right in the middle of things… sorry about that. I will have to improve my screencast workflow again!)

https://app.hellodenby.com/ ← early prototype user interface action here!

Some notes for intrepid testers:

• This is a live, unmolested stream of the @hellodenby Twitter account, including a search feed for a few things Denby likes.
• Denby isn’t following too many people at this point, so you’ll probably only see my tweets in the “Home” column.
• If you mention or direct message @hellodenby, your tweet will appear in the “Me” column, and you’ll hear a notification sound — <audio> for the win!
• The “Debug” column shows the JSON blobs coming in from the Denby server. These are slightly trimmed from what Twitter developers will be used to seeing — I dump a bunch of the unnecessary gunk to avoid wasting bandwidth.
• Although multiple clients can connect to the Denby demo, only a single stream is maintained to the Twitter servers.
• Watch the “Debug” column for HELLO and GOODBYE events, letting you know when other viewers are checking out the demo… and how many!
• Minor UX features to enjoy: You can mark individual tweets as read (click on them), you can mark an entire column as read (click on the check mark), and you can clear read tweets (click on the trash can).
• All of the links in the Denby interface will open in a new browser window or tab, so don’t be concerned about the app disappearing when you find something cool to read.

Your thoughts and suggestions are always welcome — please add a comment to this post. Enjoy!

Update: What’s with Vault Boy? He’s our chipper, unflappable development mascot. At some point, we’ll need a real logo.

Korean and Japanese popping up in the search column, beautifully rendered.

The surrounding border is actually a <fieldset>, so the whole widget looks ripe for text entry (and accepts clicks to focus the <textarea>)… the only remaining hint that this is not true? The resize grabby at the bottom right of the <textarea>. Which will go away.