The Kindle

James Fallows has a good post on the deficiencies of the Kindle, and by extension, most online reading applications:

3) And about the process of reading:

Spent six or seven hours of the flight reading on the Kindle. Perfectly pleasant and legible. Only one inconvenience relative to " real" books -- harder to flip ahead or back several pages at a time. (You scroll page by page, or else go to the table of contents.) And a kind of mental-picture adjustment: it's easier to insert bookmarks or placeholders, or seach for a specific word in the text; harder to have a remembered visual image of a certain passage as it fits on a certain place on a page. Not good for books where pictures, illustrations, maps, production quality matter a lot. Very, very good for reading Word .DOC files or .PDFs that I would otherwise have to read on the computer.

In the same vein:

One added observation, however, would be that the Kindle actually suffers from several ridiculous flaws. James refers to the inability to "flip" multiple pages at a time. It also doesn't let you cross-reference Kindle "locations" with brick-and-mortar page numbers. And you can only highlight whole lines at a time rather than starting with specific words. There are various other things like that. They're annoying. But at the same time, these are problems that I'm sure have solutions. When the basic technology of the Kindle Reader and Kindle Store are married to a design team (either at Amazon or at a competing firm like Apple) that's somewhat better at thinking this stuff through then I think you'll have a product a lot of people want to buy.

Review: Dreaming in Code by Scott Rosenberg

Scott Rosenberg's "Dreaming in Code", despite its rather evocative title, is the mundane story of an ongoing software project called "Chandler", a tool for Personal Information Management (PIM). Wait, that's not right. It is a vividly written but altogether-familiar story of software development. A story of requirements ("specs") and disagreements, of delays and deadlines, of plans, of changes in plans and of more changes in plans, of ideals and of pragmatism, and of course, of bugs that make you tear your hair out in agony. The sort of things that are all too familiar, when it comes to coding.

Why then, was it written? Over to Rosenberg :

Chandler offered a look at the technical, cultural and psychological dimension of making software, liberated from the exigencies of the business world. [pg 54]

But I am getting ahead of my tale.

In the post-war era, a project that took on a special meaning with the development of computing machines: the augmentation of human intellect. Here, many people thought, was a tool to rival language, and writing, a tool perhaps to re-invent man himself. The vision has been expressed eloquently: most notably by Vannevar Bush ("As We May Think") and Douglas Engelbart ("Augmenting Human Intellect"). Chandler, an open-ended open-source project, follows in that same tradition.

Mitchell Kapor, the owner of OSAF, and the hero of our story, was the designer behind Lotus 1-2-3, the first widely successful spreadsheet used in the business world. Lotus 1-2-3 made Kapor a millionaire several times over. His next product called "Agenda", was supposed to take personal information management to the next level and from the reviews, it did! -- but it never really took off and Lotus dropped it like a hot potato (see this review by James Fallows, that praises Agenda but also gives a good idea of its difficulties). But Agenda remained on Kapor's mind and in Chandler, he tried to go back to the same feeling that inspired him to build it.

What was this spirit? PIMs like Microsoft Outlook separate their content into silos: there's email, there are tasks, there are lists, there are action items, and so on. But of course there are no such neat categories in human activity where everything is also something else. My email is also a task (not the least because I actually have to type a reply to it), a task or a project involves emails, emails are parts of projects, emails are a way to store and access files, documents. In other words, the decomposition of the artifacts of human activity, while convenient, is also just that: an analytic convenience. Agenda aimed to go beyond silos -- as does Chandler. A personal tool that would not be caught into silos, something that could truly capture the way humans actually worked, and thereby help them do their tasks better.

Of course, all this is easier said than done. Programming itself is all about silos. Formalization, which is after all what programs are all about, require us to logically decompose processes and methods into categories. The better the categories are defined, the better a program will work. Overlapping categories and amorphous boundaries, while not unimplementable, are almost guaranteed to break down in some scenario or the other. Still, Chandler was almost a romantic project, a project that followed in the tradition of Bush and Engelbart so it had an open-ended vision, something most software projects can't really afford.

That Chandler could do so was because it was administered by Kapor's OSAF, the Open Source Applications Foundation. This was to be a non-profit project, a project solely instigated by what is called "the programmer's itch", an urge to get something done that starts off with a personal wish or frustration ("I wish I had a software that did this" or "Damn, why can't this calendar software do that??" etc). The non-profit part (which of course depended heavily on Mitch Kapor's deep pockets) meant that the Chandler team was liberated from constraints that come when you program for profit.

But there was a third component that made Chandler special. Chandler was to be open-source and therefore it was meant to harness the forces of peer production. This meant that a core Chandler team would work on the code, while at the same time, at least in theory, relying on a vast array of programmers all over the world. In short it would take the best of the two modes of production, made famous by Eric Raymond: "the Cathedral and the Bazaar". In his essay, Raymond postulates that there are two modes of production. One of them, embodied by the cathedral, is a top-down, command-and-control approach, where a plan is built up and then systematically carried out. The other, embodied by the bazaar, is bottom-up: a group of people find each other and self-organize, without any command-and-control structure. The development of Linux followed the bazaar model -- and the main reason for its success that the internet offered a wide range of tools for a lot of people, all over the world, to collaborate. Raymond's conclusion is what he called Linus' Law: "Given enough eyeballs, all bugs are shallow".

So, did Chandler's combination of the cathedral and the bazaar work? Its still too early to tell, Rosenberg's book ends with the release of Chandler 0.5 (the most recent version is 0.7 -- the fully functional Chandler release is 1.0, still a long way off). But the book does illustrate the problems of having an open-ended software project. Because the Chandler team could not agree on a set of requirements, they could not get a batch of workable code out immediately -- the release of workable code being a crucial component in harnessing the forces of peer production. But Chandler never quite managed to get the participation that a peer-produced project generally needs and slowly its team slogged on, making compromises, slowly and steadily.

I could go on and on but I'll stop now. Try Chandler out, I liked it, even if I don't quite visualize using it just yet. What did I take away from Dreaming in Code? Perhaps, if nothing else, this quote by Linus Torvalds, his advice for people starting large open-source projects, burned into my brain (pg 174):

"Nobody should start to undertake a large project, " Torvalds snapped. "You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or, worse, you might be scared away by the sheer size of the work you envision. So start small and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly overdesigned."

Words from the wise, indeed.

[X-posted on "Crack a book"]

Wikinomics: a review

Wikinomics: How Mass Collaboration Changes Everything is a full-throated call to action for senior managers. The authors, Don Tapscott and Anthony D. Williams, argue that the new technologies of the web, and the new forms of production that they engender, will change the nature of the corporation, at least as it has traditionally been conceived. This is not really a book for researchers: it’s tone is evangelistic, and the authors end almost every chapter with a bullet list-like set of points which they intend as guidelines for the senior manager intent on changing the way her company works. ( An example (from page 176): “Use industry-university partnerships to shake up product road maps”, “Make sure the collaboration is win-win”, etc.)

Nevertheless, the book is interesting and a more than brief summary may be in order. The modern corporation today has a strongly demarcated boundary, a clear place that separates the people (and materials, and assets) “within” from those “without”. Of course, the modern corporation is not a monolith — there is a vast confusing network of business partners, subsidiaries, and the like, but the boundary is still clear, at least for its employees (Sometimes, for an employee, this boundary may even be that of her own group) . The book’s central thesis is that this boundary needs to be made porous; that, in fact, this is an inevitable change and that companies need to do this or perish. The point is made in starkly economic terms for corporations; the authors are not arguing for the adoption of “peer production” because it enhances human freedom or because it decentralizes the production of information (as Yochai Benkler does in his “The Wealth of Networks“, although his book is not pitched to corporations) but because this is necessary for both, innovation and growth and perhaps, even survival. Whether this is true or not, it is definitely a good rhetorical strategy to adopt, particularly by those who wish to adopt new methods of information production into the modern enterprise, and run into the usual barriers (resistance to change, inertia, etc).

The authors spend seven chapters of the book detailing seven ways in which companies can evolve and how they can harness the new technologies of communication and production now at their disposal.

(1) The first is to harness the power of, what Yochai Benkler has called, “peer production” (also see here). Peer production, in this case, refers to the way in which, the operating system, Linux and Wikipedia were created: by a bunch of distributed users who self-organized (i.e. without any command-and-control) via some communication channels (in this case, the web). The authors point to the example of IBM, which let its employees wade into the open-source community (as developers for Linux and other open-source programs) and integrated several open-source applications into its own proprietary products.

(2) The second, is what the authors call “Ideagoras”: a market place for ideas. Using the example of Goldcorp CEO Rob McEwen who opened up the company’s geological data to the public, which then lead to the discovery of more gold deposits (the company’s in-house experts had been unable to pinpoint to anything), the authors propose that by utilizing expertise outside their boundaries, corporations stand to gain more than they think. “Idea Markets” are platforms such as Innocentive and yet2 , where corporations (or people) can post “questions in search of answers” or “answers in search of questions”. In a world where there are a vast number of under-utilized ideas, this seems to make perfect sense.

(3) The third, is to view consumers as “prosumers” (the authors have a thing for inventing bad names) and to sell, instead of finished products, something more like “hackable” products. This means providing things like APIs and manuals (but systematically, and making it a core part of the product) so that users can pro-actively modify their products, and then (perhaps) share them with other users. creating, in the process, a rich community of interacting users. Here the example is Lego Mindstorms, with its hive of users/hackers, who are forever tinkering with the product, and sharing the results with the community at large.

(4) The fourth, which they call “The New Alexandrians” looks into the story of the sequencing of the human genome. This could have been done by each company staking a claim to some sequence of the genome (since a court ruling had effectively made sequences patentable). Instead companies started releasing sequences that they discovered into the public domain, thereby creating a huge database which could be used by all researchers, anywhere in the world. This was, and is, the key to the advances in the field and could arguably lead to some significant advances in the treatment of diseases. The lesson for corporations here, the authors argue, is that research can be done, perhaps better in collaboration with those outside their own boundaries. They point to business-university research collaborations as something most companies should do more of — an example being Intel’s Open University Network, which gives IP rights to all parties involved in the research.

(5) Fifth: Platforms for participation. This is the most interesting chapter of the book, and I think, the most relevant for our work. The authors take up, what we today call “mashups”. Mashups are possible, because companies like Google and Amazon are offering “services” instead of portals, which can then be used by other programmers/companies. By opening up their services (in the form of open APIs), corporations such as Google are effectively harnessing a wide range of programmers who are not technically Google employees. This gives Google and Amazon visibility and increases the value of their services and increases the chances of their usage. More corporations need to follow this “open API” system.

(6) Sixth, “the collaborative shop floor” gives the authors’ take on how peer production can influence manufacturing. The examples are Boeing and car manufacturers like BMW, which rely on a surprising amount of distributed production and allow their suppliers to make significant changes into the actual product.

(7) Seventh and last, the workplace of the future, which the authors call “the wiki workplace”. How will the adoption of new forms of web-based communication (IM, chat, VoIP, email, wikis, blogs etc) affect the nature of collaboration in the workplace? A truly interesting example is Geeksquad, now a part of BestBuy. One of the ways in which the squad members kept in touch with each other is though MMOLGs (Massive Multi-Player Online Games). This is not by design, it just turned out to be so. The significant thing is that once this was discovered, the company actually encouraged it with even its owner Robert Stephens joining in from time to time. Bestbuy itself is engaged in some organizational changes: for e.g. allowing employees who actually come into contact with customers to contribute to the company’s strategy, giving significant responsibility to individual stores to design their displays, etc. All of these involve the use of new forms of communication such as wikis and blogs — hence the “wiki workplace”. The authors encourage more self-organization within the enterprise, with employees forming groups and disbanding when the task is done, rather than the normal way in which offices are organized: into rigid teams and sub-teams. While this is easier said than done, it can only be accomplished by workplace communication mechanisms that encourage this form of social self-organization.

In the next post I will try and list some points that could be potentially useful in the design of collaborative applications for the enterprise.

Anticipation and Design

In the latest Design Studies:

Towards an Anticipatory View of Design
Theodore Zamenopoulos and Katerina Alexiou

Abstract:

Anticipation indicates the capacity to act in preparation for a certain effect or future state of the world. Although the link between anticipation and previous termdesignnext term has not received particular attention in previous termdesignnext term research, it is a fundamental one. In the paper we review the concept of anticipation and discuss its meaning for previous termdesignnext term research. We further argue that in order to develop an previous termanticipatory view of designnext term it is necessary to move beyond long-established paradigms and abstractions such as those of machine, evolution and control. Based on a conceptual and methodological framework proposed by Robert Rosen we elaborate such an previous termanticipatory viewnext term that establishes the uniqueness of previous termdesignnext term compared to these paradigms.

Multi-agent Learning

The latest issue of Artificial Intelligence is devoted to perspectives on multi-agent learning.

Artificial Intelligence, Volume 171, Issue 7, Pages 363-452 (May 2007)Foundations of Multi-Agent Learning Edited by Rakesh Vohra and Michael Wellman

Limits on memory and reasoning

From Trends in Cognitive Sciences:

Separating cognitive capacity from knowledge: a new hypothesis
Graeme S. Halford, , Nelson Cowan and Glenda Andrews

Abstract: We propose that working memory and reasoning share related capacity limits. These limits are quantified in terms of the number of items that can be kept active in working memory, and the number of interrelationships between elements that can be kept active in reasoning. The latter defines the complexity of reasoning problems and the processing loads they impose. Principled procedures for measuring, controlling or limiting recoding and other strategies for reducing memory and processing loads have opened up new research opportunities, and yielded orderly quantification of capacity limits in both memory and reasoning. We argue that both types of limit might be based on the limited ability to form and preserve bindings between elements in memory.

Spatial navigation

From the latest issue of the journal Cognition, I found this interesting paper on how virtual taxi-cab drivers, use road signs and other cues to navigate.

Learning your way around town: How virtual taxicab drivers learn to use both layout and landmark information,
Ehren L. Newmana, Jeremy B. Caplana, Matthew P. Kirschena, Igor O. Koroleva, Robert Sekulera and Michael J. Kahana

Abstract: By having subjects drive a virtual taxicab through a computer-rendered town, we examined how landmark and layout information interact during spatial navigation. Subject-drivers searched for passengers, and then attempted to take the most efficient route to the requested destinations (one of several target stores). Experiment 1 demonstrated that subjects rapidly learn to find direct paths from random pickup locations to target stores. Experiment 2 varied the degree to which landmark and layout cues were preserved across two successively learned towns. When spatial layout was preserved, transfer was low if only target stores were altered, and high if both target stores and surrounding buildings were altered, even though in the latter case all local views were changed. This suggests that subjects can rapidly acquire a survey representation based on the spatial layout of the town and independent of local views, but that subjects will rely on local views when present, and are harmed when associations between previously learned landmarks are disrupted. We propose that spatial navigation reflects a hierarchical system in which either layout or landmark information is sufficient for orienting and wayfinding; however, when these types of cues conflict, landmarks are preferentially used.