trust your technolust

Friday, June 12, 2009

Improving Common Tag : Worse is Better

Common Tag is an "open tagging format developed to make content more connected, discoverable and engaging" [commontag.org]. It mixes RDFa into XHTML to add metadata to specify metadata for a content block, most importantly a link to a common database entry that iconifies the topic like the one word tags used in many places. This is an improvement over word tags, which can be non-descript or ambiguous: does "apple" refer a fruit, a computer company, a record label, or someone's name? Tags that are acryonyms may have no meaning to the user. RDF is commonly referred to as the Semantic Web, because it helps computers link concepts together. Everyone wants the Semantic Web, but somehow it never happens... maybe its because RDFa looks like this:

<body xmlns:ctag="http://commontag.org/ns#" rel="ctag:tagged">
<span typeof="ctag:Tag" rel="ctag:means"
resource="http://rdf.freebase.com/ns/en.u2"/>
</body>

This is a very explicit piece of data. Much of its content is XML support structure. The semantic knowledge contained in there is:
  • the tag for this span is "en.u2" in freebase

The structure contained in there (removing any content) is:
  • xmlns:ctag="http://commontag.org/ns#"
  • rel="ctag:tagged"
  • typeof="ctag:Tag"
  • rel="ctag:means"
  • resource="http://rdf..com/ns/"

There are a lot of things that can break without actually removing any semantic meaning. If there were a typo anywhere in the structure above, your tag would be hopelessly borked - all that work (and bandwidth) for naught. More importantly, this format says that if I want people to understand my tags I have to embrace XML, and there are few things that I dislike as much as XML. Look at all the structure required because of XML, and the complicated tools that are required to manipulate XML!

Lets take that content and put in something sexier: simple HTML. Over at Hacker News, someone suggested
  • <p ctag="wikipedia/The_Beatles">We're talking about The Beatles here</p>

I like this direction, but its lacking in a gruesome way: ctag is not a valid HTML attribute. Browsers may not like it, and they certainly won't be able to read it, so it isn't as clean as the RDFa. How about this:
  • <p class="-ctag-wikipedia-The_Beatles">We're talking about The Beatles here</p>

This is valid HTML, browsers can operate on this content, and you can even style it! This is much better than the previous suggestion (which was quite good, and spurred me to write this article), but is it better than RDFa?

Content:
  • the tag for this span is "The_Beatles" at Wikipedia

Structure:
  • class="-ctag-"

It is by far more concise than RDFa, but it has limitations - the tag content has to be valid inside a CSS class, which means alphanumeric, dash, and underline. There is additional flexibility if you use backslash, but this is uncommon in CSS classes and may not play nice everywhere. Most significantly, it doesn't include a link to wikipedia, only the name, and Semanic Web people really dislike that. I suspect that most people will link to Wikipedia, and if not, a search engine can figure out the most likely host. I mean, how "smart" are your tools when they can't deduce the meaning of wikipedia? If you're using an internal host or very specific database, you can always fall back to RDFa.

Worse is better. The CSS tag format I propose is not as specific as RDFa, but it is easier to implement, harder to mess up, works with non-XHTML, and easy for humans to verify. These generally overlooked and undervalued qualities make adoption easier for people, which is in the end all that really matters.

Monday, May 04, 2009

The NYTimes Doesn't Understand Social Networks

In "Tinker Away, Facebook Says", the Times summarizes Facebook's recent API expansion announcement with a comparison to a grocery store that "props open the front door and invites everyone to come in, take the merchandise free of charge, and then give it away themselves". They call this "the counterintuitive business wisdom infecting Silicon Valley these days", and proceed to imply that Facebook is doing this from the kindness of their heart.

Let me suggest that Facebook is not a charity but a profit driven company, seeing the consumer primarily as an unavoidable obligation. An API expansion attracts additional users and (more importantly) encourages current users to not leave. A permissive developer API allows more people to participate in innovating their platform for little expense to Facebook. These companies not affiliated with Facebook take risks in developing features that users might want. If users like these features Facebook can incorporate them into the product, otherwise they will wither and die without tarnishing the Facebook brand.

Developers see this as a way to capitalize (however meagerly) on the success of a powerful brand. Consumers see it as a new channel to cater to their needs. What would be better for both developers and consumers is a federated system with non-centralized intellectual property ownership, and thats exactly what Facebook intends to prevent. The most important thing that you should know concerning any Facebook API is that one thing remains the same: Facebook owns its customer's data, and no one, not even the customer, is allowed to export that data from them.

To an extent, this bothers customers. Facebook recently changed their terms of service to say that Facebook owned the property rights all user entered content. Since this would have been catastrophic to artists and writers, there was a substantial backlash that resulted in Facebook rescinding this clause. They additionally apologized and claimed that this was never the intent. It seems unlikely that they would attempt to own all user content in this way, and I believe that they were honest in saying that this was a mistake. What the terms should have said is that Facebook claims ownership of the format and
context of data as it appears in Facebook. You own your posts, but the only way to use them outside of Facebook is to retype them by hand. You own your photographs, but maybe only if you have the originals. And under no circumstances can you export Facebook's bread and butter: the relationships that you have established.

And so Facebook's goal is to make you just happy enough that you won't jump ship. They will claim as much ownership of content that they can for the sole purpose of making it hard to leave. They will make it difficult or impossible to remove content. They will sell as much of your identity as advertisers will buy without the government getting involved. These are what the investors of social networks talk about, and the only way that they can survive as free services.

I am sad to see the Times miss what is blatantly obvious to me. Is it not the age old motto of investigative journalism to follow the money? It may be that our journalists have lost their curiosity. Or possibly that people have generally become consumers, and consumers see themselves not as powerful individuals but as reflected in their relationship to companies. With Social Networks, the money is in owning customer data as much as possible, and selling that data (via keyword advertising, or outright) to advertisers.

If I impress anything on you, let it be that Facebook needs you more than you need Facebook. They need you to buy products so that they can sell advertising, because Facebook is not really a free service. Years from now, the person who owns your past (photographs, notes, messages with friends) will be the one paying for it now, and if you are a Facebook user, that person is not you. The best thing that you can do for your future self is to get involved and start owning your present identity. Data in a product like Wordpress, Blogger (but not Blogspot), or simple HTML on a web server has been paid in full. There is no question about who owns the rights to your past, or what you are allowed to do with it - it is simply yours. Certainly, Facebook has extra features that you cannot get from these truly free products, but comparable features won't exist in other products (free or consumer paid) until there is a demand for them.

So get out there and encourage people to think about the past of the future, which might be tomorrow. Maybe even use Facebook to spread the word - but don't be surprised if they shut you down. After all, they are the ones footing the bill.

Wednesday, January 07, 2009

Firefox: An Acceptable Cross Platform GUI Toolkit

A recent Hacker News submission asked what an "acceptable" cross-platform GUI toolkit would be. It discusses common complaints about the existing toolkits GTK+, Qt, Tk, and wxWidgets. It suggests creating a new toolkit with the qualities of being written in C, keeping it simple, LGPL licensing, easily skinnable for different OS's, binding for scripting languages, and be "simple and easy to use".

Good news! I know of an existing GUI toolkit that fits this bill. Its written and extensible in C/C++, has liberal licensing, is very skinnable, has bindings for JavaScript, Python, Java, Perl, and Ruby, and lots of existing open source code that you can learn from. It even has a large, mixed platform install base, so you know that the bugs are minimal. Its based on an object brokering system called XPCOM, and an application framework called Mozilla, but often goes by the name Firefox. Given the popularity of web applications in the startup community, Firefox seems like an obvious option for desktop apps. Yet it hasn't caught on, and I'm not sure why.

I recently worked on a desktop application for my day job. Given their limited interface goals and a game-oriented 3d engine, they had decided to write the interface directly in OpenGL. It was difficult to design interfaces like that, so I did a prototype integration with wxPython. That worked well enough to start real product development, during which I realized that wxPython had many of the "cross-platform toolkit" woes like needless internal complexity, difficulty in writing new components, and general ugliness.

I spent some time contemplating how people wrote successful cross platform desktop applications, and the two things that struck me were (a) there aren't many, (b) except Firefox, (c) and this might underly the popularity of web applications. So I did a new prototype using Firefox with a XUL user interface. What I found was that Firefox worked out great as a standalone application with modular code design, but it was difficult to write good interfaces in XUL. XUL seems to be well tested only as far as the functionality in Firefox is concerned. We switched to Ext-JS, started pretending to be web app devs, and got down to implementing features.

Writing a desktop app based on XULRunner has some interesting side-effects. For one, it makes retargeting your code as a web application or Firefox plugin really easy. It also lets you develop using a variety of hacker friendly languages. Like programming in lisp, it changes your perspective on how applications should be developed, and makes questions like "which UI toolkit is the best?" seem fundamentally flawed. In an age when Apple is rewriting their apps to run in a browser (and still look and feel like desktop apps), isn't writing a code against a desktop UI toolkit fighting the tide?

Wednesday, December 10, 2008

JavaScript Performance

There are a lot of JavaScript performance benchmarks flying around out there. Some claim that Chrome shames the competition, others say that Firefox 3.1 is neck and neck with Chrome, others crown WebKit as the fastest of them all.

But what they never seem to do is compare them against other languages. One website, the Computer Language Shootout does, but it never seems to rate JavaScript particularly well. There are a few reasons for this. JavaScript has gotten a lot of attention recently and has thus been rapidly improving, and the CLS doesn't update very often. Tests are also written by different people, and folks who write JavaScript have never been the performance oriented crowd. Finally, the command line harness they use to execute JavaScript isn't representative of how users execute JavaScript.

So, what happens if we try to mitigate some of these? I picked a single test, rewrote it to run as a web page, and ran it using the latest version of browsers that can be considered stable. The results might surprise you.


n = 10
gcc0.5s1.0x
java60.7s1.4x
java51.1s2.2x
webkit1.8s3.6x
jsc4.7s9.4x
minefield6.4s12.8x
firefox19.4s38.8x
rhino22.1s44.2x
python33.1s66.2x
rhino47.8s95.6x
ruby58.3s116.6x
webkit [parallels/xp]1.0s
chrome [parallels/xp]2.0s

n = 11
gcc5.1s1.0x
java66.5s1.3x
java512.6s2.5x
webkit23.4s4.6x
jsc57.5s11.3x
minefield81.2s15.9x
webkit[parallels/xp]15.0s
chrome[parallels/xp]29.0s

Timings done on a Mac Book Pro 2.4 Gz Core 2 Duo / 4 GB RAM. Parallels/XP means running on Windows XP SP3 inside Parallels on the same computer.
WebKit is nightly build 39090.
WebKit [parallels/xp] is nightly build 39088.
jsc is built from svn rev 39090.
python is 2.5.1.
ruby is 1.8.6.

So, interesting things:

  1. The fastest JavaScript implementations are close to the speed of Java.

  2. The coming JavaScript implementations are substantially faster than Python or Ruby.

  3. WebKit is about twice as fast as jsc (the command line interpreter), so the Computer Language Shootout numbers will be inflated.

  4. Java 6 is substantially faster than Java 5.

So, I expect to see more web services written in JavaScript. Why? The argument for Python or Ruby has been that they are much more productive than Java/C/C++/C# that the performance of these languages isn't important. I certainly agree with this. However, JavaScript has about the same level of language productivity, and now has an implementation thats 18 times as fast as python and 32 times as fast as ruby. And you can use the same language across the board for web apps.

I also expect to start seeing desktop apps written in JavaScript. Why use a hacky python or ruby desktop app wrapper when you could use the best cross platform GUI kit there is? And, why bother with a local rails or django instance when you could do everything in a full MVC AJAX kit like Sproutcore or Objective-J?

At the risk of giving away the secrets to my sauce, desktop JavaScript is going to change everything. There are already a couple of frameworks out there (Jaxer, Titanium), but I think that there will be many more to come.

(PS: Lisp FTW!)