Mile Zero
no matter where you go, there you are
Jun 15, 2009
This weekend, the total number of posts on Twitter exceeded the possible range of a 32-bit number--
...hang on a second, and let's marvel at the sheer size of that. It is easy to forget that a 32-bit number is actually mind-bogglingly huge, since hey, there's only 32 bits. Remember, however, that bits are like the pennies on the chessboard in that old mind-teaser: each one doubles the size of the digit before it. So in binary, you may start out counting 1, 2, 4, 8... but by the time you hit your 16th bit the total is 65,536 and it just keeps doubling from there. 32 binary digits is enough to encode more than 4 billion: 4,294,967,295, to be exact. Even in the signed integer format Twitter uses, which reserves one bit for negative numbers, it's still more than 2 billion. That's a lot of work for only 32 bits.
Anyway! So the service passed the 2,147,483,649 mark this weekend with, hilariously, a post claiming ungrammatically that "The Tweets must flow" and linking to a lolcat--
...sorry, I have to make another digression here regarding the terminology in question. There's a widespread idea, encouraged by Twitter itself, that updates should be referred to as "tweets." This is, pardon my curmudgeonliness, really stupid. First of all, Twitter is nothing more than a microblog, and we already have a term for the basic units of a blog: we call them posts. Where Twitter primarily diverges from something like Blogspot is only in the speed and hothouse intensity of its ecosystem, and you can even see examples of this in people who write both long-form blogging and Twitter. The kind of person, for example, who writes polished, slightly-pretentious management advice on his or her blog will also tend to write polished, highly pretentious posts on Twitter. In my own case, it's more of a sidechannel for links and petty commentary, but the voice is not radically different.
For another thing: just because it's the Internet, you don't have to leave all your dignity at the door. "Tweets?" Really? Do you know how embarrassing that sounds, like when you're in the middle of an editorial meeting, and a bunch of middle-aged journalists start talking about the tweets they've written lately? Because I do, and it'll turn your hair white.
Right! Back on topic: Twitter passed the 32-bit overflow mark this weekend. Doing so is not just a landmark number, it's also a potential bug for Twitter clients coded to use only a 32-bit integer in their data structures. Of course, such clients are relatively rare: modern high-level programming languages often express their numbers in 64-bit formats (the range of which I find almost incomprehensibly vast). But older languages, such as C++ and Java, may default to 32-bit integers unless told otherwise--I remember learning them as "long" integers, which says a lot about the progress that we've made. Coders these days should know better than to use the int type for something like a Twitter post ID, but it's an easy mistake to make.
Sure enough, a few clients did not handle the overflow well. On the iPhone, Twitterrific began to crash for people. My favorite Android client, Twit2Go, also threw exceptions when it went to retrieve posts. I like Twit2Go quite a bit (it's fast and acts like a real Android app, with good long-press and menu-button behavior), so this was annoying.
But it was also an interesting study in distribution methods. The developer of Twit2Go started working on the problem on Saturday morning, soon after the problem surfaced. Five hours later, he uploaded the fixed version to the Android market, and it was immediately available for users. The developers of Twitterrific, IconFactory, were actually on the job even earlier: a Friday post on the company blog noted the bug, including details about a previous update that, unfortunately, had not caught all the errors. At 6PM on Saturday (almost exactly the same time as Twit2Go), IconFactory submitted an update to the App Store that fixed the remaining bugs. As of this moment, the free version has only made it through to end users this morning, and the paid version is still in approval limbo. Drama ensued.
The problem overwhelmingly faced by open platform advocates is that abstract dilemmas are hard to transfer into mainstream, non-geek experience. Try discussing DRM with the average person, or explaining the "shallow bugs" principle to them, and watch eyes glaze over faster than Krispy Kreme. But this is a great, easy-to-translate example of the walled garden problem: because control is centralized and accountability is non-existent, paying customers have been unable to use updated software for two days now, for no other reason than the arbitrary whims of a large corporation. No appeals, no alternatives.
To sum up: "binary numbers are very large, think twice before coining a neologism, and make sure you own your hardware." Not a bad range of topics for a service with a 140-character limit, but I suspect it lacks flavor by comparison. As usual, it's more interesting to write about Twitter than to write something interesting using it.
Apr 14, 2009
I have a solution for all the things that drive me crazy about HTML. At least, I think it's a decent solution. The bad news is that there's no chance whatsoever that anything like it would be implemented.
To restate the problem: HTML is a bad way of building an interface. Even discounting incompatibilities and rendering differences between browsers--and even well-behaved browsers can render differently--it's incredibly inefficient. I had another horror-show experience with it while working on another budget package for CQ.com. Normally, at the bottom of that page, there's a footer with CQ's information. Unfortunately, for simplicity's sake, I positioned the central content pane using "position: absolute," which is apparently a big mistake. It made the footer float up underneath the navigation menu and behind the content.
There is, no doubt, a solution for this, probably involving some combination of float, clear, and JavaScript. But it's missing the point. The fact that a footer even needs a clever solution--that there is, in fact, a 'sticky footer that just works'--is insane. Apparently they plan to solve this problem in HTML version 5 with new tags for headers and footers, which is well-intentioned but strikes me as bolting new and horrible combinations onto an already terrifying tag soup.
As is, I'm inclined to rely on either tables or Javascript for placing elements on the page. The former is crufty, and the latter is practically unmaintainable, but they do have the example of allowing me to lay out a page spatially in relation to its component elements. Javascript is particularly tempting, in fact: using tools like JQuery, I can easily find the various parts of a page and then reposition them in relation to each other. Sure, it'll probably break when the page resizes, on small screen sizes, and when confronted with non-dynamic HTML--but it's so much easier to move elements around that I almost don't care.
What we really need is a new model, one that combines the flexibility of CSS-based layout with the relational/visual model of tables and dynamic layout. Basically, when I'm putting a page together, I don't want to think about it in terms of elements floating around. I want to be able to say that this is 3em to the right of that (which is 1em below the other), containing a column of these. I want to be able to say that the footer is simply always below my content, instead of tricking the browser into setting that up for me. I want to be able to line elements up with other elements, or simply say that one should be next to another. Something like:
#container {
max-width: 50em;
margin: auto;
}
#header {
top: 2em;
}
#content {
position: relational(#header) below;
top: 1em;
left: 0em;
}
#sidebar {
position: relational(#content) right;
top: 0em;
left: 3em;
}
#footer {
position: relational(#content) below;
top: 3em;
}
There's even a model that I think we could use for this: Swing. For all the criticism heaped on Java's APIs (deservingly so, in many cases), Swing makes a lot of sense to me for building simple, reflowable layouts. My understanding is that XUL and XAML also implement similar container/layout strategies, which is also fine by me: anything's better than what we've got now, right?
I don't have a problem with new tags for semantic purposes. Being able to specify that something is an aside/nav/article element makes a lot of sense from an accessibility perspective, and that's important. But a single-minded focus on semantics at the expense of design and thin-client programming ignores a great deal of where the web has been going--and it imposes a top-down model on accessibility efforts that probably won't be able to keep up with innovation. I can't help think that we'd be better off with a global accessibility attribute that can be extended easily, while paying more attention to the glaring deficiencies in HTML as a presentation language.
Feb 13, 2009
Since I'm not a GMail user, I didn't know about the new button design that Google implemented until I saw a reference to this post by their designer. As an exercise in HTML and CSS trickery, it's pretty impressive. As a look into the sausage-making for serious web application design, it fills me with abject horror.
To summarize: Google apparently wanted a button that would A) use no images for its appearance, and B) allow new kinds of interaction to go with their labeling functionality. In order to do this, they ended up creating a set of custom CSS classes applied to six nested DIV tags, as well as a large chunk of JavaScript, I'm sure. It's very clever, but it also makes me wonder just how far we're pushing HTML beyond where it was meant to go--and how much it's holding us back.
I've been writing HTML code, off and on, for more than ten years now, and I have hated every minute of it. I don't claim to be very good at it, of course, so maybe that's the problem. But it's always struck me as a technology stuck awkwardly between two worlds. On the one hand, a platform- and display-agnostic representation of textual content. On the other, the desire to build attractive, well-designed presentation layouts, including application interfaces. These are not, I think, entirely compatible with each other. Google's new buttons illustrate that tension, as they torturously beat text layout elements into paintbrushes (ones that will display across all the various browser quirks, no less).
There are new options to alleviate that, of course: the Canvas element gives Flash-like drawing tools to JavaScript and HTML developers (once it's more widely available--figure another couple years, at the rate things are going). And toolkits--jQuery UI, GWT, Dojo--have proliferated. But at some point, I think we have to stop, look at this situation, and realize that we're bludgeoning these tools into doing things that they fundamentally were not meant to do. As interface design languages go, HTML is terrible. I have a hard enough time getting a decent text layout to work reliably, much less trying to build interactive custom controls for anything more complicated than a basic form.
The interesting thing about computing trends, though, is that they're cyclical. Displaying information through a clumsy "semantic" thin client/fat server relationship? We've been there, and then most of us ran away to something better as fast as we possibly could. It's only a matter of time, I suspect, before something replaces HTML for doing UI (while maintaining the lessons we've learned about REST and open communication standards), and at that point we will look back in horror, and wonder how we managed for so long.
If you want to see how this is going to go, consider Twitter. All the basic functionality is available from twitter.com, but almost no-one I know uses that if they can help it. Invariably, you get a better experience from one of the clients (I use Twhirl and TinyTwitter for desktop and mobile, respectively). They're more reponsive, they take advantage of the native platform, and they don't require a browser to be open all day long. The communication with the server is still standard Web 2.0, but Twitter developers have largely abandoned the idea that they need to muck around with HTML, and everyone's better for it.
For the last few years, tech pundits have repeatedly predicted that the browser will take over the space currently occupied by the operating system: via solutions like Google Gears or Prism, or a custom shell like gOS, you'll run everything over the network via HTML/JS/CSS. It's failed to happen so far, and it'll continue to fail. The closer the browser comes to "real" applications, as with GMail, the more its shortcomings become apparent, and the more developers have to rebuild basic functionality in a system that's just not meant to handle it.
If anything, the future is in the middle ground: a heavyweight, native or bytecode platform that can be run in a distributed fashion over the web, splitting application programming back out from the browser and providing a real API for developers to leverage. Such a format addresses the weaknesses of modern binary applications, such as heavy installation and slow startup, without abandoning the advantages that a real operating system provides. AIR, Silverlight, and XUL (as well as Java, to a much lesser extent) are possibilities that could achieve this. HTML, if we're lucky, is not.
May 28, 2008
Like every hip young person online, I've gotten myself a twitter account. My initial impressions are that I don't particularly care for the terminology: followers? Was "watchers" not creepy or sheep-like enough?
Anyway, if you are also on Twitter, I'm open to invitations. Additionally, I'm looking for suggestions of people who are interesting or innovative users of the service. I don't think I'll be broadcasting very much at the moment, but I'm interested in how other people are getting value from it.
To some extent, this is leading up to a low-priority project I'm starting: as anyone who attended college with me knows, I've been fascinated for a long time by what I call "guerrilla rhetoric"--rarely during my undergraduate career could anyone get me to shut up about Otpor, for example. But during the last few years, thanks in part to mobile phones and a much more flexible set of web standards, we've started to see examples of smarter protest and resistance movements using information and communciation technology to coordinate or publicize their work.
I've realized that I don't know as much as I'd like to about these developments, which I find fascinating. So I'm going to start reading up on the subject much more thoroughly, starting with Gene Sharp's work on nonviolent protest. Also, I've set up a del.icio.us linkstream where I'm going to start tagging my online research--there's not much there yet, just the Youtube videos from Anonymous and some stuff I remember from B-SPAN--but if anyone runs into anything, I'd appreciate a heads-up. Eventually this might be a subject that I'd be interested in exploring through grad school (he gazed enviously at Berkeley's doctoral program in Rhetoric), but that's probably a few years off.
Apr 19, 2007
Dotster just sent out an e-mail saying that .es and .cn domains are now available. I'm always tempted, when informed about new domains, to register a bunch just in case. Now I'm trying to think of clever uses of the suffix. I can't think of any for .cn, but .es is a goldmine, assuming they're not already taken (www.mistak.es, sadly, has already been reserved).
Or maybe I just really want elvs.es and its subdomain, tricksy.elvs.es (hence the title, my preciousssss).
