Monday was Tutorial Day. People willing to shill out a few hundred dollars more were treated to two half-day lectures unless you were one of the lucky few, or indeed, the lucky many that chose to listen to the all-day Flickr tutorial and learn about how to scale on the cheap and fast. I am told that this talk delved into the vagaries of automation and server setup, stuff that would seem somewhat obvious to those in the know. There were no secrets to be had, no deep insights.
Ah, forgive me for my impoliteness. I am attending the O'Reilly Emerging Technology Conference, known briefly as ETech 2006. This is a four day conference held in sunny San Diego, and is in its fifth year since inception, when it was originally a peer-to-peer conference. Year Two was held in DC. The rest of the venues have been in California, and more recently, in San Diego, presumably its once and future home.
This year's conference is held in the majestic Manchest Grand Hyatt, a twin towers of a hotel building, with two spires thrust upward like two Siamese twins coyly spying the lovely lasses on the beach. The choice, no doubt, is a pragmatic one, born of the fact that too many participants need a large space to congregate, and only a handful of hotels, most notably, the fancy overpriced hotels can reasonably host such conferences. Combine that with the fact that you can convince companies to pay several thousand dollars for attendees to show up, and you have a recipe for legitimate decadence.
Back to the tutorials. The first tutorial I went to was co-hosted by Jeffrey Veen and Jesse James Garrett. Apparently, both co-founded a company several years ago called Adaptive Path devoted to issues of user experience. Although Garrett considers himself a designer, he is the guy who coined the term, AJAX. Garrett is one of those small, ultra-thin men with a goatee. Veen is the opposite, quite tall, with a soul patch that makes him seem like Shaggy. They were the Wilbon and Kornheiser of the web set.
Their first goal was to talk about Web 2.0, a term coined by Tim O'Reilly, referring to the next generation of web apps. The web started off as a visual hyperlinking system. Static web pages would link to other webpages. You only had to click on the blue underlined link, and be sent off to a new web page. The pages themselves were not much more than pages. They had text. They had tables. They had pictures. Much like pages in a picture book, you weren't meant to interact with it much, except to go to other webpages.
Such content stands in stark contrast with desktop applications, such as word processors, photo editors, MP3 players, video displays, even the browser itself, excluding the content it displays. These applications are called rich clients not so much because they have money, but because you can interact with them in far more sophisticated ways than clicking on a link.
The problem with making web pages more dynamic has been several fold, none the least of which is bandwidth. If you want to update web pages, and you want the server to do it (as opposed to applets, which are client-side applications, once downloaded by your browser), that takes time, and in the early days of the web, this was not readily available. Worse still is the browser itself. There are many flavors of browsers: IE6, Firefox, Safari, and lesser known ones such as Opera. While many support JavaScript and CSS, they often do not agree on how they should implement it, making designing for multiple browsers a grand headache for designers.
Now the question arises: why should the server do the heavy lifting of the content on the web page? Servers can be much more powerful than your home PC. Think of the number of computers that Google has to process searches. There's no way your home PC could ever do this.
However, the loading of new web pages provides a jarring experience, as users must wait for new content to come down. Wouldn't it be much nicer if you could interact with the web page more dynamically, say, drag and drop, move slider bars, the kinds of things you expect from a rich desktop client?
Yet, the user, used to static web pages whose content only changes if they switch away from it, isn't quite ready for this new "Web 2,0", the browser as application. And worse still, a desktop application can usually command the attention of the user because they spent some money acquiring it. A web page is like one of those panhandling kids, dressed in tatters, begging for money in a language that's not quite English. If the web page is cute and adorable and easy to interact, you'll hang around. If it does things that are unexpected, they won't hang around.
This means modern web pages have to be more usable than usual. They can't be complex applications, and if they are, they have to be based on stuff that you're already used to, like Word or Excel.
The talk was about providing users with the ability to experiment without feeling they are being roped in to doing things (like purchasing stuff they don't want to), that gives them the opportunity to explore. That provides feedback so they know that their actions do something. For example, when Blogger was redesigned, people wanted to see that pressing a button caused their blog to get created, even though it was effortless. The user was also given a save button, even though there was auto-save. They needed the security of seeing things happen, and since they aren't changing web pages, they need other cues to let them know something is up.
That talk was interesting.
The afternoon talk was a disaster. David Heinemeyer-Hanson, who I'll refer to as DHH from now on, basically coded up a Rails application live. You needed to know the basics of Rails, Ruby, and even Ajax. For those who knew that, perhaps DHH's presentation would mean something. I sat at Dave Thomas's talk of roughly equivalent nature at "No Fluff, Just Stuff". He did roughly the same thing, but you could actually follow parts of it. Plus Dave is quite funny. DHH seems a bit spacey, twisting the English language, partly out of amusement, I'd imagine ("on the other leg").
I'll talk more about the evening in a later post.
Three opinions on theorems
-
1. Think of theorem statements like an API. Some people feel intimidated by
the prospect of putting a “theorem” into their papers. They feel that their
res...
5 years ago
No comments:
Post a Comment