Our friend James Dailey recently posted an interesting comment about our mindmap perspective. This reminded me that we need to resume work on Activities, which is our sample application for task management. If you’re interested by the topic of task and project management, make sure to check its description, for there are quite a few interesting ideas in there…
Here is what STOIC Activities looks like…
Our recent posts about Stoic Activities have triggered some interesting discussions about resource management, with really awesome contributions from our Aussie friend Jim Alateras. What follows is a short summary of our exchanges.
The use case is pretty simple: you’re developing an application that will allow end-users to book some physical resources such as a meeting room or a seat on a flight. For the sake of the discussion, we will assume that you’re managing a local flight club, that your users are student pilots, and that you’re building an application that will allow pilots to book a plane, usually for a few hours or a few days at a time, sometimes in a recurring fashion.
A first solution would consist in providing a standard Resource object, which could be used in different ways for different applications. This Resource object would be used to capture all the planes operated by the flight club and would be related to Events (managed by Google Calendar) to model reservations (aka bookings). With such an approach, all you would have to do is customize the standard Resource object with a few fields that would capture the properties of an airplane (used for setting some rules down the road), such as:
While this approach would work, it presents two challenges: first, pilots don’t want to fly Resources, they want to fly planes (or helicopters maybe); second, once the standard Resource object has been customized for planes, it can’t be customized for other kinds of resources, such as a meeting room for example, which might be used for training purposes in the flight club.
A way around this problem is to replace the standard Resource object by a purpose-built object, such as Plane in our use case, then to link this custom object to an Event for the purpose of modeling a reservation. In order to model this link, two options are available: the first that comes to mind is to create a Reservation object that would link a Plane to an Event; the second, and more elegant solution, is to add a Reserving field to the standard Event object. This field would be modeled as a 1-N Dynamic Relationship from Event to any object. In the context of our use cases, instances of this relationship (we call these relations) would point to Planes.
The reason why we like the second option better is that it uses two objects instead of three, and requires the creation of a single record (of the Event object) when a reservation is made, instead of creating both a record of the Event object and a record of the Reservation object. In this case (as in many others), less is more.
This is pretty much the approach we will take to support the management of resources with Stoic, and the only question that remains to be answered is whether we will add a Reserved By field to the Event object, or whether we will assume that its implied function could be handled by the standard Owner field. I guess the latter might be enough initially…
Our recent work on Sutoiku Activities outlined the need for query variables. Following some internal discussions, we also realized that we should add support for query parameters as well. Both apply to the values of query filters (account.country equals "France"), but they address two different sets of requirements.
Query Parameters
Query parameters allow the value of a query filter to be set by the user when a query is executed. To define a query parameter from the query builder, simply check the “Query parameter” checkbox in a given query filter. When doing so, the placeholder for the query value goes from “Enter value” to “Enter default value”, the latter being optional.
When a query parameter is defined, a corresponding input field is displayed underneath the query name in the query selector box. When the query is selected, default filter values are automatically populated, and the user can set the values of any query parameter, then click on the “Run” button to refresh the Object View.
Query Variables
Query variables allow the value of a query filter to be dynamically set when a query is executed. To use a query variable as value of a query filter, simply add the dollar sign ($) as prefix to a variable’s name. The variable must be within the query engine’s scope in order to be properly evaluated at runtime.
Our recent roadshow in Asia gave us plenty of opportunities to refine our go-to-market strategy. Ultimately, our product can appeal to any business user interested in developing a custom application for the cloud. But we can’t really target such a broad and ill-defined audience. Instead, we must identify smaller market opportunities and develop complete solutions for them, one after the other, in a very incremental fashion.
Initially, we’ve decided to focus on small to mid-size Independent Software Vendors (ISVs) that have an existing application in need of an upgrade to the cloud. Typically, the application is designed for a particular vertical industry, and is distributed within a limited geography. It was originally designed for the web (or migrated from a client-server legacy), never architected for multi-tenancy, and does not provide proper support for mobile interfaces. And now time has come to migrate this application to the cloud, with an existing development team, very limited R&D investments, and no disruption to the existing customer base.
For this particular market, Sutoiku will provide a platform that enables the rapid migration of an existing application to a cloud environment, for a fraction of the time and cost required with any other tool we know. We will also provide some professional services to help with the migration, both in terms of strategic consulting (how to sell an application in the cloud), architecture design (how to design an application for the cloud), and technical implementation (how to migrate). These services will be delivered by a group of consultants based in California and Singapore, as well as software engineers based in China. We will initially focus our sales and marketing efforts toward customers based in Silicon Valley, then extend our footprint based on market demand.
Later on, we’re likely to push our platform through specific applications, either targeted at specific vertical industries, or focused on particular business processes. While it’s too early to tell which applications will have the most traction, a few are interesting to us, for various reasons.
From a vertical standpoint, we’ve been giving very serious thoughts to the development of a fund management application targeted at the private equity market, especially venture capital firms. This application would be used by partners, analysts, and other staff members in a VC firm to automate the process of raising a fund, developing a deal pipeline, closing deals, making capital calls, and generating annual reports. We like this application because of its high level of value added (translation: you can sell it for a lot more than $20/user/month), and because we have so many prospects in our backyard (think Sand Hill Road).
From an horizontal standpoint, activity management (Events, Projects, Tasks) will be our first attempt, with what we call Sutoiku Activities. Here, we’re interested in promoting an application that everybody needs (I have yet to meet someone who found the perfect task manager) and that can support the development of many vertical or horizontal applications on top of it. Essentially, Sutoiku Activities will be the mother of all templates, and should teach us a ton of things about what can be done to facilitate the adoption of a new development tool.
Beyond these first two applications, we will gather as much user feedback as possible on this blog, prioritize inbound requests using a tool like Get Satisfaction, and fund development through dedicated Kickstarter campaigns. These are our three steps to the epiphany (three, not four).
This morning, Ken and I defined a detailed use case for Sutoiku Activities, from which we outlined an architecture and implementation roadmap. As mentioned earlier, Activities will be the default sample application for the Sutoiku platform, therefore we’re trying to keep it as simple as possible, while ensuring that it properly demonstrates most of the platform’s key features.
Object Model
The application will be built around three main objects:
For the first release, most of our attention will be focused on the Task object.
In situ Task Capture
One of the primary goals of Sutoiku Activities is to make it easier for users to quickly create tasks from whichever tool they’re using at any point in time. We call this in situ task capture. In order to implement this feature, we’re making the assumption that knowledge workers spend a majority of their computing time using either an email client (eg. Gmail, Outlook) or a note taking tool (eg. Evernote, Google Docs, Microsoft Word). In such a context, we want to make it possible to create tasks directly from these tools.
Email Task Capture
To create a task from an email client, the user can simply forward an email to a particular email address (eg. tasks@mydomain.com). The email will be automatically picked up by some email gateway that will parse it and create a matching task for it. Optionally, some meta-data about the task can be added at the top of the email’s body, before its forwarded content. The syntax is directly inspired from the one used in OmniFocus. For example, the following line will create a task called “Buy milk” associated to the “Replenish fridge” project, due by Monday, expected to take an hour, and marked with a priority level 1.
-- Buy milk :: replenish fridge # monday $ 1h ! 1
This form of task capture will work with any email client, from any device. An alternative mode will be offered for Gmail (if we find a way to implement it) by adding a “Create Task” button allowing a task to be created in relation to a particular email. This button should allow most of the task’s fields to be set, including its assignee (by default, a task is assigned to its creator). Either mode will store a link to the original email within the task’s record.
Document Task Capture
To create a task within a document stored in Google Drive, the user can simply use the exact same syntax, anywhere in the document. A cron job running on the Node.js server will search for documents containing the double hyphen prefix on a regular basis (maybe every 30 seconds) and parse the activity expression upon finding one, then create a corresponding task.
This mechanism will work with any note taking tool that produces files which content can be indexed and searched by Google Drive. But when used with Google Docs, any processed activity expression will be automatically replaced by a link to its related task, while it will be left untouched when using any other note taking tool (unless we develop a connector for it later on). Based on the previous example, the link will look like that:
[Task: “Buy milk” related to the “Replenish fridge” project, due Monday, 1 hour, Priority High]
The link will point to the related task displayed by Sutoiku’s record view. Ideally, users should not modify this link, since any modifications will be ignored (for performance reasons). Instead, users should click on the link and modify the task from the record view. In order to prevent links to be modified, we might display them as images, ideally using the SVG format. It should also be noted that when using another note taking tool, the activity expression is left untouched, therefore users should not modify them once a task has been created.
Gateway Object
In order to create tasks from an Email or a Document, we need to either execute custom JavaScript code or add some new capabilities to the platform. The former would be nice but would require that we make our Node.js server multi-tenant, which is a massive undertaking, therefore we must do the latter, through the implementation of a Gateway object. This object will let users create custom gateways capable of creating records for any object based on the reception of an email or the addition of specific expressions within files stored in Google Drive. The Gateway object will have the following fields:
Related Object (su_task in the current example)Expression Syntax (a JSON object describing the expression’s syntax)Email Username (tasks in the current example)Document Link (a JavaScript expression describing the Document’s link format)In the context of our previous example, the Expression Syntax will be something like this:
{
prefix: "--",
mappings: [
{prefix: "::", field: "su_project"},
{prefix: "#", field: "su_due_date"},
{prefix: "$", field: "su_time"},
{prefix: "!", field: "su_priority"}
]
}
The Email Username will be optional. Setting it will activate the email gateway.
The Document Link will be optional. Setting it will activate the document gateway.
Task List
For obvious reasons, users will need a way to lookup lists of tasks, either the ones assigned to them, or the ones they are managing and that might be assigned to them or others. To do so, they will use the Object View with two pre-built views defined with the query builder, My Tasks and My Managed Tasks. But for these views to work out of the box, the filtering component of our query builder needs to support the use of filtering variables as filter values. This is something that we will discuss in a future post.
Platform Requirements
This use case added a few requirements to our platform:
JavaScript Libraries
At a high level, this use case will require the development of the following JavaScript libraries:
Implementation
Ken will be responsible for developing this application. Luckily for him, our CTO already implemented a connector for the Task virtual object using the Google Task Service, which is by far the most complex component for this project. Therefore, Ken will start by implementing the Activity Expression Parser, Email Gateway, and Document Gateway as standalone components, then integrate them with the rest of the product when it’s in good enough shape. After that, we will start to use it internally in order to get most of the bugs out of the system.
If you have any idea to improve this first use case, let us know!
Making it easy to capture tasks while taking notes is one of the main goals for Sutoiku Activities, the sample application that we’re developing on top of our platform. For this purpose, following an original idea by Andrew McLeod and a suggestion by one of our friends, we’re going to adopt the syntax defined by OmniFocus. To get a better idea for what I’m talking about, take a look at their documentation, on pages 33 and 34. In a nutshell, this will allow you to create contextualized tasks directly from any note-taking tool, as long as your notes are stored in Google Drive.
Stay tuned for more details…
Out of the box, Sutoiku will initially provide one sample application called Activities. It will help anyone manage Events, Projects, and Tasks. It will implement a relatively simple process for getting things done that drew its inspiration from David Allen’s GTD.
Events and tasks will be implemented as virtual objects (objects served by an external system), while projects will be supported by a native object. The application’s initial release will be centered around tasks, and focus on three main aspects of task management:
Task capture will be inspired by some work done by my friend Andrew McLeod, who devised a clever way to capture tasks from any note taking tool like Evernote, Google Docs, or Notepad.
Task contextualization refers to the needs for setting a task’s due date and priority, relating it to another object (very often a project), and assigning it to someone else.
Task completion will make it easy to mark a task as being completed, from any device.
While we expect this application to be useful in and by itself, its primary function will be to provide a meaningful example for how to build an application with Sutoiku. More precisely, it will demonstrate how to:
Stay tuned for more details…
