The Tweet is the Message

What's the value of talking to someone face to face? Why is it so easy to mis-interpret the emotional tone of an email? How is it that some messages just play better through some media than others?

Marshall McLuhan introduced the idea of the "heat" of a medium as its ability to communicate meaning and value without effort from the observer. The more effort an observer has to expend to derive meaning and value from a medium, the cooler that medium is.

I'd like to incrementally build on that idea, and suggest that media that enables person-to-person communication has varying degrees of presence built into it. If we define a person being physically in the room as "perfectly present", then presence is defined as the degree to which perfect presence is approached by the medium in question.

Presence, and specifically the absence of it, has many more faces than in times past. At one point in history you could be in a room with someone, or you could write a letter. That was about it as far as options were concerned. One was perfectly present, the other was fairly distant. The means of communication were so distinct from each other that they were characterized by significantly different cadences and patterns in their content. This is the "lost art of letter writing" for which some still pine.

Now, however, the two distinct poles have smeared into a continuum across where dozens (and perhaps hundreds) of possible modes of communication lie. Interestingly they all pretty much fall in the space between the letter-writing to in-person gap: they're more "present" than writing a letter, but not as "present" as actually being there.

This brings me to (cue grumpy old fart voice) the web's latest fad : Twitter. Using its web interface, or WAX apps like Twitterific, one is given an opportunity in 140 characters to post whatever they happen to be doing in that minute. You are encouraged to make it activity based ("what are you doing right now?") and to keep it short and sweet. This post is called a "tweet".

Its kind of like being there, with the person. Sort of.

In the weird way that technology does, it has increased the presence of the person on the other end - way past email, past IM, and with more longevity than session-based tools like Skype or video conferencing. It is an ongoing trickle of information about a person, like one would get if they were in the same room with them. Twitter is a presence app, and the tweets are the McLuhan-hot packets that convey that presence.

Unfortunately, presence starts to look like presence is the speed of light: we can get close to the experience of someone actually being there, but never equal or exceed it. There's always some kind of generation loss - our brains can tell the difference between a stream of tweets and the huge amount of information that someone gives off just by being there.

Or maybe its just a bandwidth problem, and someday we'll come up with a medium hot enough to be truly present. Tweet.

Oh yeah:

http://twitter.com/LorenDavie

Freezedown

The funny thing about creating a web site, web app or software project is that initially

• Everything is up for discussion, then...


• Nothing is up for discussion

This is because Project Variability is a time sensitive beast. And the best projects are ones where everyone, from the client, through the information architect to the developers and designers understand that the degree to which features are carved in stone is entirely dependent on when they are in the project lifespan.

The crux of this idea is that the tolerance for change in a project isn't an absolute - its a curve. Project's can undergo change midstream, but the tolerance a project has for change is in direct proportion to its remaining time. I call this phenomenon Freezedown: the degree to which features and implementation details are frozen in the project.

To try to express this lets compose a formula:

TV = F / T

where:

TV = Tolerable Variability: Change occurring against a feature set or implementation method.

F = Future Iterations Remaining in Project

T = Total Iterations in Project

So - lets say we had a project that was 16 weeks, broken up into 8 two-week iterations. Before the project development kicked off, there would be 8 out of 8 iterations remaining. That's "1" or 100%. At this point everything is on the table, there's no downside of changing the feature set, or the (at this point, planned) details of implementation.

As the project goes on, it can still accommodate changes, but the tolerance drops off:

• Iteration 1: 87.5%


• Iteration 2: 75%


• Iteration 3: 62.5%


• Iteration 4: 50%


• Iteration 5: 37.5%


• Iteration 6: 25%


• Iteration 7: 12.5%


• Iteration 8: Feature freeze

What do these percentages mean? They abstractly represent the amount of feature changes or implementation changes that are open for discussion. This is the tolerance of the project for change.

If something comes along that exceeds that level of change, at that time, the scope has changed - which at the very least means the original schedule is probably not going to be realistic any more. Everyone in the project should be aware of the degree of Freezedown in effect at any given point.

Code, Community and Pain Thresholds

Over the last week two applications I use made major announcements. Both are good apps, both are (or will be) WAX applications. It was fascinating to watch these two announcements happen so close together, because they represented two little software startups that have made significantly different choices for the road ahead.

Up until this point the companies had been similar. They were conducting a public beta of their software, which was indicated to become commercial software once the beta period ended. At the point that they went gold, there would be a price tag associated with the software. In the meantime you could participate in a public beta for free - or in other words, the community was testing software that was not yet ready for prime time.

The first of these is Spanning Sync, a company that makes a cute little applet of the same name that links iCal with Google Calendar. While there are some rumblings about Salesforce integration, the Google calendar sync is the main available feature at this point. Spanning Sync announced their 1.0 product, which meant the end of the beta testing period. People who wanted to continue to use it would have to pay up after 15 days - $25 for a one year subscription, or $65 for a lifetime subscription.

The second announcement was from Kaboomerang, the makers of a great little GTD productivity app called Actiontastic. Kaboomerang announced that as of now, Actiontastic was going open source. It would be free in both the beer and speech sense of the word.

Both announcements were made in the company blogs. Here's a fairly representative sample of comments from the Spanning Sync blog:

Pricing is outrageous!

That's $50 per year for something which is more of a convenience than a must-have.

That is very steep. I appreciate all the hard work that went into this, but I don't see that many people converting to paid at these rates. I won't.

In contrast here's a representative example of the comments from the Kaboomerang blog:

Jon,
I echo the sentiments that this is incredibly generous. You’ve done a great job on this application, and I’m incredibly grateful to you for doing this. I hope you can continue finding satisfaction in developing this application!
I also agree that at the least you should provide a donate button. Your work does deserve at least some monetary reward :)

So on the surface it definitely looks like Kaboomerang has made friends, and Spanning Sync has lost customers. On the other hand I can tell you that Spanning Sync now has $25 of my money, and Kaboomerang doesn't.

It's tempting to say that one of them is right, and one of them is wrong. But which?

Well according to Harry Beckwith, author of Selling the Invisible, pricing is a complicated and not always rational beast. He says that if no one is complaining about your pricing, its too low. If everyone complains its too high. Beckwith asserts that the sweet spot is when about 20% of your customers are telling you that your pricing is too high. I suppose that Spanning Sync could look at their sales and count negative comments and emails about their pricing and see if the proportions come out right. Beckwith doesn't say much about people who don't say anything, but silently walk away because the prices are too high.

Everyone has some sort of pain threshold, after all. I've long been a fan of the Quantrix Modeller, but I've never been able to justify the price tag on it when the alternative was to continue to use the Excel spreadsheets I already had. I (and other people, I know) have asked Quantrix to reconsider their pricing, but they don't seem particularly interested in servicing the sub-$300 market. Maybe we're the 20% in this case.

The more interesting case of the two companies who made announcements is Kaboomerang. Actiontastic is a standalone Mac OS X app right now, but its going to gain WAX status in the near future when Actionatr kicks into gear. While it's not yet clear, it looks like Kaboomerang may adopt the so-called "freemium" model: offer a base product for free, and charge for a "professional" package. This is the model undertaken by Web 2.0 companies such as 37 signals' BaseCamp and many others. If their open-sourcing of Actiontastic works out, maybe they will harness their community and make a success of their premium products. The "freemium" model has yet to really be proven, so it's not yet well known what it takes to make it a success or not.

And on the other hand, Spanning Sync has my $25 now.

Hello Technorati

Just a quick link up to my Technorati Profile.

WAX

Over the last year or so I’ve started to take notice of a new breed of online applications. I think that web-apps, exposed API’s, mash-ups, widgets and so forth are a number of different views of the same overall trend. Namely:

1. An online service that takes some silo of functionality and makes it available through many different means. This usually includes a web site, but can often involve many machine-readable formats such as XML-RPC, JSON, REST and so forth.


2. A bunch of different client apps that connect it together: other websites, widgets / gadgets, full blown desktop apps or plug-ins.

Previously we would have said the business hosting the online service was a web site, or a web application. But what if the web was no longer the primary way in which it was accessed? For example, what exactly is the iTunes music store? If most people just accessed Gmail with a POP or IMAP interface, what would it be? What if the primary interface to Google Calendar was iCal, and not the web?

I’m going to put a stake in the ground and try to put a name to this thing: WAX. Web Application eXchange.

WAX consists of three core elements:

Web - not because it even has to have an HTTP interface, but because it usually does, and because this phenomenon is growing out of the Web community. HTTP has become the de-facto standard transport for applications, and almost all WAX apps use HTTP as their transport mechanism.

Application - because the core of the service is to provide some sort of functionality that might otherwise be provided with installed and licensed software, or just run on the desktop. WAX apps are more than just brochures on the web, and even content management systems don’t really qualify. This isn’t about publishing (unless its a publishing app, of course) - its about online software.

eXchange - because the online nature of the service works best and makes the most sense when it allows the user to collaborate or otherwise interact with other users who are also online. An online app that allows you to do something in isolation might as well be a desktop app. What makes an online spreadsheet or word processing document WAX is when it can be shared by people.



Where is WAX? Where are some good examples of WAXware?

Well, I was playing with Google Calendar and a beta of something called Spanning Sync. Now, Google has calendaring software which they happen to expose through a cool AJAX web interface. However, they also expose it through an open calendaring data exchange format called iCalendar. On my Mac I could subscribe to the iCalendar interface using iCal (the mac OS X calendar program) and see my Google calendar. However this is read-only.

Spanning Sync takes it a step further, by offering bidirectional sync between iCal and Google Calendar. Now if I enter an appointment in iCal it gets pushed up to Google. But wait, what if I’m sharing my Google calendar. Then someone else could be using it, also using Spanning Sync and iCal.

Suddenly we’re collaborating on the web, using Google Calendar. The only thing is - neither of us are actually going to the Google web site! Is it really a web application now? Well, not exactly - its really WAX.

A couple of implications of this idea:

On a business level, it does raise some questions about what models are sustainable. An advertising supported model doesn’t work when no one goes to the website to see the ads. The advertising model is why you can launch a Google search from anywhere (from the search bar in FireFox, for example), but you have to view the results on a Google search result web page. That’s because that’s where the ads are. Those search results will not be available via XML or JSON or whatever, so long as Google is working with their current business model. This implies that if WAX really takes off we’ll see more transaction-fee and subscription based business models.

On a technical level the concern with these kinds of integrations is that it creates dependency on a third party to deliver the service. In reality businesses and individuals make this compromise all the time - we rely on third parties for power, banking, payroll, HR, and so on, but this is a new area, so there’s reasonable grounds to pause before putting one’s mission critical systems in the hands of a startup “Web 2.0” company.

However, my prediction is these issues will be worked out sufficiently over time. WAX will allow businesses and application developers to collaboratively harness each others’ value, and should over time reduce the cost and complexity of developing sophisticated online applications.

How To Doc

Most of what you’ll find in the “Agile” development methodologies is just common sense. Anyone who’s been in development long enough would agree with most of the principles that the Agilists propose. One of the main areas of real controversy has to do with documentation.

This mostly comes out of a reaction to the heavy, “high-ceremony” methodologies of the 90’s (like Rational Unified Process - designed to sell Rational tools). The Agile folks essentially have dispensed with the UML, the use cases and so forth and gone with the lightest-weight documentation they can get away with, in pursuit of the idea that they should be building software, not documentation.

Well, for companies like AI where 99% of what we build is for our clients, this “no-documentation” doesn’t quite work. This is because:

• Documentation is part of the approval cycle, in which our clients let us know if we’re building the right stuff for them.


• Documentation lets our clients know what we’re going to build before we actually build it.

To fill this gap, some of the Agile methodologies, notably Extreme Programming (XP) recommend an “in-house customer”. This sounds both great and horrible to me for different reasons, but in any case I’ve never known any shop that’s actually been able to pull if off. Our customers are to busy doing other things like, say, running their own business, to sit around in our shop being our resident customer. That means we need to document.

At the same time, we certainly don’t want to go back to the bad old days of high-ceremony. So we’ve endeavored to create a light-weight documentation system built on the attributes of the part of the system being developed.

We have 4 documentation types:

Specifications: Written technical specifications that describe the system, either in paragraphs of text or some times with tables that define data structures.

Wireframes: Simple mock-ups of user interfaces that show the layout of the application to the customer.

Prototypes: Simple, interactive versions of the application which demonstrate the interactivity of the app to the user.

Nothing!: Not everything needs documentation! Sometimes the best approach to document is not not document at all.

These four “directions” form our compass:



(Well - its almost N,S,E,W - instead we have N,S,P,W).

When deciding how do document a feature or part of an application, we’ll want to look at the following criteria:

Linearity: Is this a serial, step-by-step kind of process we’re describing, or is it something that can wander in any direction?

Visibility: Is this a part of the application that is reflected in the UI? Is it something that the user is going to see, or is it strictly behind the scenes?

Interactivity: How interactive is this feature? Is there a lot of back and forth with the user, or does the user just fire off one event and a bunch of stuff happens without further input?

Uniqueness: How unusual is this feature? Is this something that is unique to this app, or unusual in this business space, or is it something that everyone has seen a thousand times before?

These four attributes influence our documentation decisions:

Linearity



The more linear a process is, the more it drives documentation towards a specification. Specifications are particularly good for describing automated, back-end processes. They are less useful for non-linear processes.

Visibility



Visibility in a feature is a good indication that wireframes or prototypes should be used. This is because everyone, including customers and developers, needs to be able to visualize the user interface for the feature.

Interactivity



Interactivity drives towards prototyping. The more back and forth a feature presents with a user, the more inefficient a wireframe is at properly representing it. Instead we need to resort to prototypes - interactive but “hollow” versions of the app that simulate the back-and-forth the real application would provide. This allows the observer to properly understand the interactivity of the feature.

Uniqueness



Unique or notable features require documentation, common and already well-understood ones do not. One option that is always available is to do nothing: to not document the feature. I believe that the driving force here is uniqueness - how notable a feature is. Conversely, common or well-understood features may not require documentation at all.

So how do we use these driving forces? Lets look at a couple of examples.

Lets say our first feature is a complex set of preferences. Choices made by a user may cascade into more choices, and may spawn dialog boxes. Looking at this feature, we can state that it is Visible, Interactive, Nonlinear and Unique. Putting this characterization against our model above, gives us something like the following:



The model has spoken: a prototype of the feature is the best way to document it.

For a very different case, lets say that we have a common print function occurring in the application. Well, everyone has pretty much knows what printing means, so lets call it Invisible, Linear, Non-interactive and Common.



Applying the model, we can see the best thing to do with this feature is to leave it undocumented, everyone already understands it.

Technology Intelligence and Business

Why do some business make such smart decisions with technology, and some are so helpless? What’s the difference between a business that leverages technology to grow its business, increase its profit margin and out-maneuver the competition, and one that sinks a lot of money down a useless, costly, black hole project?

I’d suggest that alongside intelligence (IQ) and emotional intelligence (EQ) that businesses also sport technology intelligence (TQ). A business’ TQ governs its effective use of technology, which in turn has a substantial impact on its effectiveness as a whole.

Here’s how I see the five levels of TQ in business:

1. Business Problem: The first step a company takes towards TQ is when they acquire the knowledge to address a specific business problem with technology. This could be hiring developers or an external vendor to write a custom application, or it could simply be the purchase of a system to meet a specific need.

2. Tech Strategy: The second level is where a company stops looking at individual business problems in isolation, and develops a comprehensive tech strategy. At this level, the application of technology to individual business problems is evaluated within the context of the overall strategy.

3. Tech Ecosystem: At the third level, the company is aware of its tech strategy in a larger eco-system of always changing technical trends. The company is sensitive to how the "tech landscape" will affect its internal strategy, whether through availability and cost of personnel, the continuance of particular tech platforms or the development of new ideas and paradigms.

4. Tech Vision: Once aware of the "tech landscape", a company begins to have the opportunity to make strategic decisions based on an understanding of where things are going. A company can purposefully choose where it wants to live on the adoption curve, and then monitor new developments as they work their way down the curve. At this level a company starts to be able to anticipate movement in the landscape before it happens, and can position to get ready for change, and to avoid destructive disruptions.

5. Tech Leadership: At the very highest level of TQ, the company can make change happen in the tech landscape. This very sophisticated understanding involves identifying unfulfilled needs beyond the company that intersect with the company's business, and applying technological solutions to meet them.