My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.

Here is a very first screenshot of the upcoming Gantt perspective. Don’t get fooled though, for there still is a ton of work. Some that is obvious, and some that is not. To make a long story short, adding such a visualization to SlickGrid is not entirely trivial, especially when you want to preserve virtual paging, pane freezing, collapsible tree sections, and the countless other features that are offered by the Grid and Gridtree perspectives from which we started.

Also, you can see on the right hand side a preview of the new and improved record view, which takes advantage of the fact that every single object not only has an icon, but also a color. We’ve used it to add left-side borders and we’ve repeated the borders on form sections in order to make them slightly more visible. We still have to fine-tune that part of the user interface, but it’s quickly converging toward something we can be happy with.

In the meantime, Florian is fighting with timezones and countless other details that are getting in the way of getting this done. While he did not want to work on this perspective initially, he is actually doing an excellent job. He was a little bit scared by SlickGrid, because it’s a big codebase for which we used a fork (for pane freezing) and to which we added a ton of code. To be fair, I would have been scared too. In fact, I was so scared that I did not even try to build a prototype first, handing over to him this very hot potato. But by the looks of it we should have something quite decent by the end of the week.

And while he is doing all that, I am starting to work on the concept of pluggable planification profiles that we need if we want to use the very same perspectives for supporting different methodologies, across different types of applications. For example, Kanban implemented by Pivotal Tracker in the context of project management is quite different from Kanban implemented by Pipedrive in the context of sales automation. And if you want to support a methodology similar to the one offered by Microsoft Project, you need yet another set of planification algorithms.

Our vision is that different users who like different methodologies and have different applications for the same dataset could use the same perspectives with different planification algorithms in order to get things done. Read the previous sentence a couple more times to better understand where I’m going with all this. We believe that if we can do that, we can significantly improve the way different people with different backgrounds, different mindsets, and different preferences can work together on complex projects.

We won’t do it all next week, but we should have a good headstart…

Managing resources with Stoic

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:

  • Glass Cockpit (boolean)
  • Number of Engines (integer or option list)
  • Type of Engines (option list)
  • Retractable Gear (boolean)

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…

More on this soon…

Parameters and variables in queries

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.

Go-to-market strategy

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).

More on Sutoiku Activities

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:

  • Filtering variables in query builder
  • Cron jobs on server
  • Gateway object

JavaScript Libraries
At a high level, this use case will require the development of the following JavaScript libraries:

  • Google Event Connector
  • Google Task Connector
  • Activity Expression Parser
  • Email Gateway (over SMTP)
  • Document Gateway (over Google Drive)

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!

Task capture

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…

Sutoiku Activities

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
  • Task contextualization
  • Task completion

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:

  • Create a native object (Project)
  • Create a virtual object (Event and Task)
  • Create a custom user interface (for the task list)
  • Implement a workflow (for the lifecycle of tasks)
  • Integrate with a third-party cloud application (for the task capture)

Stay tuned for more details…