Time to Write Use Cases

I think the best way to prepare for the killer app is to write down all the use cases. Examples are here. It is almost a daily chronology of the pains I encounter whether at work or church. At this stage, knowing what problems we want to solve is much more important than how we will solve them (remember we have been a hammer looking for nails for long?). I encourage everyone to do the same and document all the pains in using technology in our daily life. If we can solve a sizable chunk with our app, we will be on our way.

Confluence UI Being Redesigned

Redesign. We want to focus on what we want to achieve. We will part our ways with them eventually anyhow.

My Ideas from A Year Ago

About a year ago, we started to use SnipSnap, which was my first exposure to actually using Wiki. I was very much at loss to figure out what SnipSnap was and what it did for me (and other people). It was not obvious at all. The Germans don't usually produce good documentation. When I really got it, my mind started to race. Here is the main idea I had in that period.

ThinkTank: The Thought Processing and Sharing Tool

Purpose

• thought processing
• thought sharing

Data Types

• Paragraph
• content can be any type
• == p tag
  
• List
• Element can be any type
• Ordered List (numbered)
• == ol tag
  
• Unordered List (unnumbered)
• == ul tag
  
• Table
• Cell can be any type
• == table tag
  
• Custom Types

Editors

• text editor (for paragraph)
• outline editor (for nested lists)
• table editor (for tables)
• pluggable editors and viewers

Exports

• as Word
• as Excel
• as HTML
• as XML

Organization

• multiple categories
• keywords
• keyword and full-text search
• symbolic links

Architecture

• Local Application
• data entry for all types
• synchronized with remote service
• on PC or Palm
• Remote Service
• central storage
• data type processing

Sharing

• personal spaces
• shared spaces
• access control
• change notification
• change approval

Today when I reviewed this, I was really surprised at how little this idea had changed.

Our Partner Growing

Our marketing partner Atlassian is growing and has opened their first US office in New York City.

Document Version Control

From the previous post, we know Call-by-Reference is great for online access. Then how do we handle conflicts? This problem is actually everywhere. The scenario is: user A reads a document at t1; user B reads the same document at t2; user B modifies the document and saves it; user A modifies the document, saves it and thus overwrites user B's changes.

The solution seems to be a best practice that many have adopted (Hibernate, Confluence): use a version number. User A saves the document saying these are the changes on top of version 1. But the current version is already version 2 (with user B's changes). So user A either fails or is prompted with differences (as is the behavior of Confluence) to merge.

What does this mean for us?

1. We want to keep the unit of documents small to reduce chance of conflict.
2. We want to implement a structural diff that can show visually the differences, not just diff tool's textual differences.
3. Our approach of model changes works perfectly well here: any new document is created by applying model changes to its previous version.

Then what about offline mode when Call-by-Value has to be used? Fortunately, the same approach can still be used. The changes sent back to the server is nothing more than a list of model changes on top of a certain version n. If the current version is n, we can apply the model changes directly; otherwise, we prompt the user to merge the differences. Exact same implementation as that in the online mode. How beautiful!

Call-by-Reference vs Call-by-Value

Call-by-value: passing values around by using the copies of the value. Call-by-reference: passing values around by using a reference (also called pointer or handle) to the value.

In Java, only call-by-reference is used for non-primitive values and call-by-value for primitive values. In Smalltalk, everything is an object and everything is passed by reference. In C++, you can do it either way. Remember why you want to control your copy constructor? Because your values may be copied onto the stack if they are passed by value.

Now this post is not intended to be a discussion on this language feature. Rather, this is also a user model. When we send a document as an attachment in an email, we are passing it around by value. Problem is, this value may be modified by multiple users and the modified copies can come back to you for you to consolidate, which close to impossible to do. Call-by-value is a very bad user model. When you send a link to a web resource in an email, you are passing it around by reference. Everybody then goes to the same place to access it. This elimiates many problems. Call-by-reference is the correct user model in most cases. Of course, when the user is offline, you have to use some type of call-by-value. Modern email servers support this mode when you check download message to local so that you can access your emails when you are offline.

So, CBR for online and CBV for offline.

Desktop, A Thing of the Past, Eventually?

Emad, Francis and I were talking about how Google Desktop and Yahoo Desktop Search didn't solve enough of user's problems yesterday and the day before yesterday on separate occassions. Bam! Jon Udell, the influential Infoworld analyst who usually have good ideas and insights writes a piece about it today, when was desktop search when we needed it. He speaks of the cloud (The Network is the Computer, remember?) and how he prefers to save everything there and search there. This is his conclusion:

One of the ironies of desktop search may prove to be that, by the time it went mainstream, the personal hard drive was about to become an endangered species.

How appropriate! Users don't want to be concerned with the distinction between their desktop and the cloud. They just want to be able to:

1. Create stuff (documents, pictures, book marks, anything).
2. Tag stuff so that they know which is which.
   
3. Search for stuff so that they can locate it and use it.
4. Share stuff (humans are social, right?).
   

Where is the concetp of desktop this all of this? We strive to make the above easy for users, whether connected or disconnected, whether using a PC or a cellphone.

Concourse: Data is the Point

Yesterday I got every excited at realizing that Confluence's schema is not complicated at all and we can directly use it.

Concourse: the Better Confluence

For security reasons, this post has been moved here.

Concourse: the Cornerstone Demo App

I think we realized, this time completely, in the last couple of weeks that we need to do a real application to demonstrate the power of Cornerstone. While thinking of what kind of app, many things went through my mind: PetStore :) and the like. Then I bumped into the Confluence Remote API. I also heard of TimTam, the Eclipse Plugin for Confluence that uses the remote API. I tried it and found it has enough of Confluence's functionality to be useful. So I thought, why not build web app equivalent of TimTam? So I settled on this demo app idea: another (and better) web UI of Confluence that showcases Cornerstone's capabilities. I then looked up synonyms of confluence and picked concourse. This was the humble start of Concourse.

In Search of the Killer App

I think the killer app is a wiki. Here is why.

1. I have just rolled out Confluence in my church. The reaction in the user community has been universally positive, which is very rare in the years I have served in the church. This is a very tough crowd because they require a very easy to use system or otherwise they won't adopt it. Many users have actively got onto the system to post their content. This fact speaks of two things: 1) the application is very useful; and 2) it is easy to use. If this software has this level of acceptance by my church community, you've got to watch out.
2. Wiki has the potential to replace: 1) our file system; 2) our office apps; 3) our colloboration apps; 4) our desktop. No, we will not be in the business of topple the company in Redmond. But rather, we will be in the business of making the life of the user super easy. Or to put it moer plainly, I'd like to make my own life a lot easier while at the same time making the world a better place :).
   

There are many wiki implementations. But the most successful one in my opinion right now is Confluence. Why? Because they are a tiny company (I doubt they have more than 10 people), a little over two years of age, has been profitable from very early on, has 300 enterprise customers, has a great image in the open source community (it's free to open source projects and non-profit organizations), uses a pretty standard data format (Textile type of markup; XML backup) and has a plugin system that makes it extensible. All of the above are not difficult to immitate and we can do better.

Focus on Data

In yesterday's conversation, Emad pointed out one point of developing applications up side down: focus on data rather than logic. I think this is an important realization. It is very much related to the earlier post I had on developing using sample data. More interestingly, yesterday Mike Cannon-Brooks, the founder of Atlassian, developer of Confluence, had a post on the importance of Open Data vs merely Open Source.

Let's bear this in mind going forward when we build our killer app:

We want our data formats to be open and flexible. Applications that use them can be one thousand and one that come and go. But the data formats are here to stay.

More on the Google Model

One Google revenue source is those unintrusive text ads. Google Search has them, Google Mail has them, Google Groups has them. If we build an application which attracts enough eye balls, can we possibly sustain ourselves by AdSense revenues alone? How great a following do we need to get to generate $.3M a year to support 2 people, or $.5M a year for 3 people? If this is possible, we can build a truely (well, mostly) virtual company. We just rent dedicated servers from a hosting company at $50/month/machine and install software there. We don't need to own and operate a data center. We grow the number of dedicated servers with the customer base. Or we sell the software and support as a packaged product. The former seems a lot easier.