Archive for July, 2006

SIGGRAPH starts tomorrow

Tomorrow the PLW will begin full-blown, fast-paced coverage of the 2006 SIGGRAPH conference. Takashi has put together an excellent new site, PLWire, to showcase the footage, images and contacts we make there. John’s urging us to avoid text and just go with images, video and links. Luis seems all set to get some awesome footage, though as of yesterday he was working through some MPEG-2 codec issues with the group’s new camera. PLWire will go live tomorrow.

It so happens that my parents are also coming in tomorrow, so it’s going to be a busy week for me balancing the conference and the family time. Then later next week Jenn and I are heading down to meet them and the rest of my mom’s side of the family in Ocean City, New Jersey for a little beach vacation. Armed with her board and stoked from a decent session last weekend with Danny, Jenn is hoping Jersey will actually have some waves. I guess like the rest of the east coast surfing population we’re going to have to hope for a storm swell.

Equal Status to the Visual and Irrational

In reading Hiroshi Kashiwagi’s forward in master designer Mitsuo Katsui’s book Visionary Scape, I found myself happily struck by his analysis of imagery in communication.

The modern era has been an age in which visual images have been in overflowing abundance but viewed to be inferior as a form of language. Today, however, the time has come for us to cast doubt on the special status accorded to communication whose purpose is rational agreement. We do not communicate only for the purpose of agreement. Rather than agree, we accept each other’s words. There is no need to set uniformity of awareness as our objective. It should be ample simply to understand what we are communicating. Communication gives rise to further communication in chain reaction. It should be enough merely to have the perception that one is participating. Though visual images may be thoroughly arbitrary as language, they are not inferior in terms of communicative function.

For most visual artists and designers this point is indisputable, yet in reading this I found myself confronted with my own biases . I don’t know how it happened, but I’ve come to favor verbal and written language over visual imagery. I like language’s range of expressiveness, from the poetic to the logical, and its potential for melding different styles within this spectrum. I like the intentionality in writing and speech, how its structure is crafted. But thinking about it now I’m reminded that visual langauge can also meld the precise with the poetic, the mathematical with the irrational, and much of its effectiveness is how it does so within the subconscious.

Promiserver alpha is online

It isn’t much to see at this point, but last week Promiserver went live on my PLW site.

The challenge now is to move beyond descriptive natural language to a more procedural, structured form. I still feel like Ruby is the way here, with some sort of Ruby DSL that is interpretted within a sandbox on the server. I’ve actually been tempted to go back to Scheme just to prototype something, since it lends itself so well to this style of programming.

As a small diversion I’m also becoming interested in wiki-style collaborative contract and license authoring, including sophisticated diff and windowed timeline views. This falls out of an idea Takashi mentioned a while back about community defined licenses. He’s currently putting together a madlibs style license that I’m looking forward to seeing. And as my first effort in this arena today I added a humble timeline slider to the openstudio tag cloud. It’s a little slow with the amount of Ruby processing happening on each Ajax request, but serves as a decent first step. I’d next like to augment the simple slider with additional information. It would be nice to get a macroview of community activity, something along the lines of Martin Wattenberg’s history flow, but less overwhelming in its detail. For now at least I am just satisfied to be able to look back on the past days when flower was a more popular tag than abstract.

Trust & Language

A few key slides from my SIMPLICITY consortium presentation this past week. I talked about trust and language, transitioning from marketing/consumer trust to my vision of p2p social contract systems.

Relationships as Contracts

Old versus New

The Contract Language

Below is a demo of a reskinned version of the promise system, dubbed PROMISERVER. Burak was a huge help in throwing together a fast, demoable interface.

promserver_th.png

Next step is to dive into this procedural language I’ve been pushing for.

Oligopoly 2.0

In this week’s New Yorker John Cassidy has a thoughtful review of Chris Anderson’s just published Long Tail. Among a few well-argued criticisms, I was particularly struck by Cassidy’s dissection of Anderson’s repeated reliance on certain major corporations as his supporting examples, such as Google, Amazon, iTunes, eBay, Netflix, or MySpace. These few large companies are the major “aggregators” in the long tail economy. They dominate.

There’s an ugly name for industries that are controlled by three or four big firms: oligopolies. A few decades ago, these lumbering creatures were easy to spot…. Today, thanks to globalization, deregulation, and technological progress, many of the twentieth century behemoths have fallen by the wayside. But don’t assume that giant, exploitative firms are a thing of the past.

Cassidy has well articulated a point that has bothered me about Anderson’s work since I first started following it. He focuses narrowly on media consumption, and in particular consumption via these behemoth centralized distributors. Anderson’s long tail world is consumer paradise, brimming with Wired-style techno-optimism. But of course technology itself is not necessarily good, and is simply a provocation for change. It can induce good, evil, or neither, just something in between. The article got me thinking about these new tech oligopolies, how much I depend on them yet how much I distrust them. It’s not a good situation.

Rails Layered Dispatching Hints

For my current Rails project I’m setting up my web services with layered dispatch, which nicely organizes all the methods while keeping them at the same endpoint URI. There’s some good documentation already out there in the Agile Web Development with Rails book as well as the ActionWebServices manual, but I have a few extra tips that could be helpful.

If we’re using a before_invocation interceptor, like say for authentication, we can clean things up by creating a subclass of ActionWebService::Base that includes the authentication method:

app/apis/authenticated_web_service.rb

class AuthenticatedWebService < ActionWebService::Base
  def authenticate name, args
    @authenticated_user = User.find_by_login args[0]
    unless @authenticated_user.authenticated?(args[1])
      raise "Not authenticated"
    end
  end
end

Because we are actually using an instance variable here, @authenticated_user, we have to set up our layered web service controller to use instances of the services rather than the classes.

app/controllers/services_controller.rb

class ServicesController < ApplicationController
  web_service_dispatching_mode :layered
  wsdl_service_name 'contract_services'
  web_service_scaffold :invoke

  # Here we use instances...
  web_service(:contract) {ContractService.new}
  web_service(:account) {AccountService.new}

  # rather than classes...
  # web_service :contract, ContractService
  # web_service :account, AccountService
end

Then your various services can inherit from this "abstract" AuthenticatedWebService. Each can make use of the authenticate method and the @authenticated_user variable.

app/apis/contract_service.rb

class ContractApi < ActionWebService::API::Base

  api_method :all,
             :returns => [[Contract]]
  api_method :new,
             :expects => [{:login => :string},
                          {:password => :string},
                          {:description => :string}],
             :returns => [Contract]
end

class ContractService < AuthenticatedWebService
  web_service_api ContractApi

  def all
    Contract.find :all
  end

  def find contract_id
    c = Contract.find(contract_id)
    raise "Contract not found." if c.nil?
    c
  end

  ## Authenticated API Methods
  before_invocation :authenticate, \:only => [:new]

  def new l, p, description
    c = Contract.new :creator => @authenticated_user,
                     :description => description
    c.save!
    c
  end
end

Once your service is put together, keep in mind that XML-RPC requests will use a method of the form service.method. So for example, my contract service's find method is contract.find. I have to admit that this really threw me off for a little while when I was testing out the API in XML-RPC Client and I kept getting back a "no such web service 'api'" error message. The manual does point this out, but I missed it the first time, and only on a close reread did I figure this out, at which point I realized how much good sense this approach makes. Note that for SOAP requests the service API is encoded in the header.

One more final note is that Rails logger object is not available in the layered services. This could be a deal breaker in certain cases.

The Tempting Abstractions

I’ve been meaning to figure out OSX development for a few years now. I’ve halfheartedly gone through the currency converter tutorial a few times, fooled around in XCode with various sample projects, worked through some of the NeHe OpenGL lessons that were ported to Mac, and even bought and went through the first edition of Aaron Hillgass’s book 3 or 4 years ago. What got me going again recently was an interest in combining native accelerated graphics with functional language extensibility. I was in part inspired by the ideas of the scheme-based fluxus. I reread the docs for PyObjC and RubyCocoa, and both seem like a lead. Then a few days ago I found Will Thimbleby’s concise tutorial and example project for using Javascript to script a Cocoa view. This is nice because the Javascipt engine is exactly the one used in Safari, based on KDE’s KJS engine. Even nicer is that his code is short and straightforward. In the end I will probably go back to figuring out Ruby and RubyCocoa, but this tutorial got me moving in this world again.

The biggest stumbling block in my Cocoa experience has been Interface Builder. I know it is supposed to be easy and elegant. But I’ve been suspicious, and consequently hesitant to really get into it. Along with other Apple systems like WebObjects and Quartz Composer, it requires aquisition of knowledge that is essentially non-transferable. Learning how to visually connect these specific little icons, widgets and outlets just isn’t going to help me in any other system. It is abstracted to the point of simulation, and learning the rules of the system involves little knowledge of the inner workings. It reminds me of the tension Sherry Turkle noted in the introduction to the new edition of The Second Self:

The aesthetic of transparency (common to the Logo movement and the early generations of personal computer hobbyists) carried with it a political aesthetic that was tied both to authorship and to knowing how things worked on a level of considerable detail. There is a kind of understanding that is not communicated by playing off-the-shelf simulations (p13).

Turkle is concerned that the increasing opacity in modern software and systems is leading to a new type of illiteracy within the emerging generation:

…as I meet professional in all of these fields who move easily within their computational systems and yet feel constrained by them, trapped by their systems’ unseen and unknown assumptions, I feel continued concern. Are the new generation of simulation consumers reminiscent of people who can pronounce the words in a book but don’t understand what they mean? (p14).

Yet I’m giving in. After investing only a few days I’m realizing how Interface Builder takes care of many parts of the application that I don’t ever want to handle myself. The abstraction is easier, simpler, and it saves me time, leaving room in my brain for other problems and puzzles. Turkle’s concerns are understandable, and to some extend I share them, yet I wonder whether it is in part nostalgia for an aethetic that is only interesting now that it is so obviously impossible (in a recent talk my colleague and friend Jeevan elaborated on the connection between simplicity and nostalgia for a simple past).

Maybe it is this tension between opaque abstraction versus transparent details that makes for good design. Which details do we choose to hide by assuming defaults? Which details do we conflate versus keep separate? Which details to we expose? As the abstraction increases, the gap between the two increases as well. Finding the balance is harder, yet also much more important.