virtual hosting

a review of our goals

Due to circumstance we didn't really have an opportunity to talk about our goals and vision in detail. We realized that there are some differences and this weeks goal was to find and resolve them.

Each of us wrote about their goals and the direction we should go:


(i am putting this one first because it is shorter and because zhangweiwu's writeup in part responds to some of my assumptions made here.
What is the goal for the product?
Enable the user to better manage their email
a personal task-manager that allows other people to send you tasks
How will this product become profitable?
Subscriptions for the server
Sales for mobile apps
At what stage do we need (can we get) investors?
If we focus on an early profitable model i believe we can build everything without outside investors. Of course it will take longer but it will last longer too.
Product roadmap
Based on our currently available skills and experience, i believe the webinterface is the easiest to build. We can have a minimal prototype in a matter of weeks and start using it ourselves as an email client.
Mobile clients
With the server built on sTeam, we can provide imap in the prototype to allow users to access messages from a traditional mobile email client. To provide a minimalistic solution around the webinterface that includes mobile support we could modify an existing email client (like kmail for android) to handle task features before diving into creating our own mobile client.
Desktop client
A desktop client would round up the product portfolio
Gmail and other client plugins and patches
Plugins to other email services or clients would widen our reach to allow more people to properly communicate with email-task-manager users. Patches may be contributed to Free Software email applications like Thunderbird, Evolution and others to implement native support for the task protocol.
Development roadmap
A web-prototype is almost done. At our current working speed it can be ready in a few weeks.
A quick mobile prototype is feasable if we use sTeam as the backend to save us some work.
A mobile prototype that operates without a server is a lot more work.
We should build the set of tools that you and i can use first. This will speed up testing and should help focus on a practical interface.
User validation
The prototype should be shown to users for feedback.
If the prototype is not accepted by users we need to change it or search for another customer segment.
When the prototype is in reasonable shape we can invite other users to actively use it for more serious testing by giving them free subscriptions.
Introduce paid subscriptions, no new free subscriptions, alpha users remain free
Close free subscriptions
To build a slow growing company with a steady revenue.
Regardless of the speed of growth the goal is not to sell the company to another owner for a lot of money.
Web subscriptions
A freemium model requires a lot of resources (funding) that we should only attempt after we have actually received investments. Until then we should focus on a subscription only model to not jeopardize our chance to make this work without funding.
Mobile app sales + server subscriptions
A simple mobile client will need our server and could thus be a free client with a trial offer.
A more sophisticated client that works with any email account could be sold for a higher price.
Desktop app - server subscriptions
The desktop app should be Free Software for inclusion in Linux distributions and as a free download for Windows users. For Mac we can potentially try to sell the desktop app via Apples market.

Zhang Weiwu

(this is not a direct response to the above, but to earlier statements)

Regarding making a good PIM solution1

Thanks to the lack of copyright protection in China I was using the very expensive professional Outlook even when I was a school kid back in 1996. During the last 8 years of customer service I also tried to use and served customers using a lot other products, e.g. I was using groupwise in this month following my customer's purchase decision. On opensource part, I was involved in the development of eGroupware at its prime: the most popular opensource groupware around 2005. I also use thunderbird, evolution (of GNOME), zimbra. Many of these are groupware, but I'll limit myself to their PIM features in the following discussion. The web based solution I also tried a few, including gmail and rememberthemilk.

All these solutions are good, but people are still looking for new solutions. Had these old solutions excel, we should be seeing most busy people using a PIM, but that's not happening. From my observation there are two types of failures specific2 to current PIM solutions that stem their potential:
  1. Lack of support of workflow in software.

  2. Lack of support of workflow in mobile devices.

Lack of support of workflow in software.

This can be demonstrated with examples.

The first example, is when the email does not arrive on the right time, there isn't an existing software allowing you to properly defer it.

The second example is Martin's favorite: when you receive an email, if it arrived in the right time, it is either informative, or requesting an action: the simplest action being to reply it3. Thus it makes no sense to create a task out of email: let's define an email be itself a task. This is a progress towards supporting workflow.

Many software products, like Evolution, support creating tasks out of an email, but that's more like patched work than built-in support: it unnecessarily splits the workflow to one about handling the email discussion thread, and the other being following this task in a separate task manager.


Why these solutions doesn't support workflow well? I guess the reason is the following:

A lot of technology like marking email with a star or tag it with an IMAP tag, or file it in an IMAP folder, are designed in a librarian model: the user work like a librarian, and emails are like incoming books. They are static, need to be managed well so you can review and find them easily. This model is not a true reflection of how people treat information nowadays. Information is not static, it's flowing. Modern users hope the information be out of the sight as soon as they are no longer needed, and comes back when needed. Most emails will not be read a second time, thus those who manually sort email find their practice not very rewarding. Librarian model is a wrong model. Workflow is a much better model.

Lack of support of workflow in mobile devices

I was once hoping Newton could solve this at the beginning of this century, but it is solved only very recently. Here is a scenario: you are sitting in front of your computer, receiving an email about joining a party, with the address and a map of the part on it. You pack your bag, and print the email – no that's too old-school, you have an tablet, so you mark that email with a star or something, probably even creating an calender event or an alarm. On the day of the party, you read the email to find the location. It is still not perfect, have space to improve, but having recent popularity of smartphones and tablets, it made a big difference already.

Let me give a few more scenarios:

  1. When you meet someone, you are reminded you should speak to someone else, perhaps, e.g. another friend share the same hobby as the person you are speaking to. You think to yourself, emmmh, I should send an email to that friend later. So you have a todo item to mark with your portable device.

  2. When you are in the taxi to the airport, you capture this uninterrupted space of time that you can finish your phone-to-call list. Luckily your mobile device maintains that list. Some of the phone call resulted in tasks, in marking other tasks finish, in more “phone-calls-to-make” or “emails to write”. You are probably not going to write a long email in a taxi, but it's good to know the mobile device remembers to whom you should write an email later when circumstance allows.

  3. A phone call you receives makes you realize there is one more topic to discuss in the yearly board-of-director's meeting. You need to add that a few items to the very calendar event. The phone call doesn't always catch you when you are in the office. You need a mobile device for that.

In all these cases, workflow took place when a user is with mobile devices. You cannot separate these workflow with the workflow you were creating sitting on a computer in a fine working day. That is, unless your job is like a typist or waitress with fixed routine. That means the best solution is to have a software solution sitting in the mobile device or tightly integrated with its desktop version.

However, even without a great mobile software system, you can manually weld mobile workflow into your PIM software's workflow. That's how I do it. e.g. I take a note in the above scenarios, and empty my notes to a computer workflow when I reach a computer. There are a few occasions when I have to make do without a computer for a few days, so I improved my paper notes, e.g. lists phone calls, emails-to-write, calendar events, in separate lists. A few month later I found I am no longer using computer for managing my workflow. The fact I “regressed” to paper notebook, is an important lesson to me, that having a mobile integrated solution is more important than having a much refined solution but fixed on computer. I almost can draw similar understanding from observing other users.

That means, mobile solution is not an optional feature but a integral part of the solution.

Technical impact

One topic we are talking for the a few days are if we should focus on making a software application or making a web application. This is on the assumption that we don't actively make both at the same time. To me the mobile device is apparently the priority, as it is the only way that integrates personal workflow of typical busy users, thus is forward looking. This is inline with my own experience and my observation. That means, if we built a web application, it has to support offline access very well, which I believe possible in a 5-year scale thus not of immediate concern.

My conclusion is we should do software applications, for the simple reason to target users who need a full support on their workflow. During the discussion, a few reasons to do web application poped up, and here are they and how I counter-argue about them.

Web reaches a great audience

True. In fact this is the major concern of me at this dilemma. If we do software application, the first product would be either based on Android or on iPad. I guess we would have to wait for the first product's success before porting it to the alternative mobile platform. The web audience is I guess 2 times bigger than mobile device audience. Meanwhile software application market for mobile device is fast growing, means people are actively looking for solutions. Such a market is for new things.

The key problem is sill this: a web application only cover part of the workflow. IMHO a system that doesn't support the full workflow is a system that doesn't support workflow, demonstrated by my “regression' to paper notes. This discussion reminds me of gmail. Gmail did almost half of what needs to be done on a web application to well-support personal workflow, and I guess google don't think they need the other half unless they are ported on mobile device too.

We can do a web solution faster, faster is to get more resource

Not completely true. None of Martin and I are very good at javascript (I did ajax around 2006) and none of us do Java or Objective-C neither, but in the end its the refinement that takes time, e.g. receiving feedback, discover subtle need of the users and so like. Many say prototypes are faster with the web, some say 5 times faster than developing desktop apps, while Apple keep demonstrating they can develop an app in a few minutes with simple drag-and-drop. I think perhaps both are true, but it doesn't matter much: after the first month, there will still be tweaks to solve, obstacles to overcome and so on. I watched how my close friend W.B.S., a guy 2-times smarter than I am on coding, learns javascript from a background of other programming languages. He is now a javascript guru. He started with quick codes, busy with keyboard all day for the first month, and then he just work half day, the other half sitting in a coffee bar, either reading javascript book or staring at the emptiness of the wall, and occasionally write something on paper. In the end he rewrote all his code. I think the real improvement is when he is drinking that huge amount of coffee, and for that part there is no silver bullet.

One idea being discussed is we can sell subscription to the web application and get some money earlier. We can get users into paying web application subscription in early stage, because, if we get software application users into paying in early stage, we enter a down-fall spiral of reputation fall, that is less starts in the AppStore or Google Play shop. But that's a moot point if I look back now after a few days. You got to do the job anyway in order to sell, either by subscription or by software application.

Getting users paying you in early stage is quite different than getting users to try your software in early stage. I experienced this around 2006 when I worked on a web 2.0 subscription-funded system. The users are not happy, some quite subscription, some demand features in order to stay, and the software development then focus on these specific features of a set of just 30 users, in the end it became customized software design. It's okay to do customized software design business, only that it is not big, it is a detour to greatness, or it never reaches greatness. In the end you are paying time, in a less worthy way, to avoid paying money directly. There is no net gain.

Let's face it, lack of resource is lack of resource. Maybe it's time we talk about early investors – although I thought maybe we need investors only after half a year, but now that the team is in trouble of financing even the first stage. Lack of resource makes everyone giving too much hope on uncertain approaches that cannot be justified at normal conditions, like how people who needs money falls to be victim of cheating schemes.

Potential income through web subscription is higher through software

True if the number of subscriber is the same as application buyer. But, competition exists, new things comes out, people would choose the less expensive solution, thus keeping user on subscription base require an advantage beyond software features. Luckily there can be such advantages: turning PIM solution to a groupware.

Those who buy the subscription in group can have networked features. Or, those who subscribed for his own use can decided to join a group. The group can be a company who newly employed him, thus “Take your own device” becomes “bring your own account to the company”, instead of the traditional style where a company deploys IT for the users.

Now let's think about a different case: a few buddies decide to form a discussion group like Google Group, those who joins it with their account enjoys tight integration of the discussion group into his workflow; those who join by subscribing with an email address don't get it.

So far so good, but it's not a strong reason to start with web subscription. Subscription based service could be added on later, as noted previously, because it has its own advantages.

Still, the key problem is sill this: a web application only cover part of the worflow.

Let's target those whose workflow doesn't need mobile device as part of their workflow

I thought about it. I am not giving away my current job just to do that. We can only consider this approach a way to get started, but then we would end up with two different pieces of software, because those who subscribe the web application without need of a mobile device, do experience different scenarios that requires different user interface.

The user-base is shrinking, and there are many who had competed a few decades to attract the attention of such users. It's just bad market.

1The project title is “email-task-manager” which I agree. For the integrity of maintaining user's work flow, I took it evident that calendar/notes related features are not avoidable, thus email-task-manager is PIM.
However, marketing it using the word PIM could be a bad decision.

2General failures that can happen to every type of software, like bad user interface wording, is not in the scope of this article.

3Martin's original version is, the simplest task of an email is to read it. Here I will simply define the “task” in user's language, where reading a task description not yet start a task.

the next step is to produce a unified vision out of this.

Author : mbaehr   |   size : 21540Bytes   |   Publish Date : Jul/4/12/09:44   |   to Top