The last two months have been very busy. Our software, DayTickler, is beginning to take shape. The basic features that enable to list, schedule and tick tasks are completed. We finally finished fine tuning the user experience and we are very proud of the end result.
The next story we will begin this week is "As user, I want to sync device calendar inside Today list".
In the coming weeks, we will expand the product to add personal workgroups. Since early this fall, we have made several prototypes of the workgroup functionality. Storyboarding is almost completed. As I indicated last October, the challenge is not only to team up with your close ones to achieve what is important in your day, but above all to enable asynchronous communication between workgroup members. I will be back soon with more information about this design challenge.
If you are planning your personal work, as you can easily do with DayTickler by committing and scheduling tasks in your “Today” schedule, you are not challenge by communication. You do not need to sync your brain with someone else to organize your daily schedule. As I explained in a previous post, the main challenge is to sync your brain with your gut.
The context is very different if you have to plan the daily schedules for a workgroup. Whereas personal planning is asynchronous – users scheduled tasks on their time and at their own pace – we expect group planning to be synchronous as it requires all parties to share information.
Meeting is the ultimate solution for synchronous communication. It is perfect for scheduling one on one conversation. Meetings are also perfect if you want to communicate a message from one person (the presenter) to many (the attendees).
However, as we have all experiment, meetings are very inefficient if you expect a many-to-many conversation and decision-making between all parties. Most decision-making is better left for asynchronous communication.
Writing is a proven solution for enabling asynchronous communication. Whereas meetings are synchronous – all parties must be present and engaged for the duration of the event – written communication allows the parties to address requests on their own time. It frees all the parties from the need to be “synced up.”
One of the strengths of DayTickler is that it allows to articulate your daily schedule in writing. In my next post, I will explain how we use this opportunity to add support for workgroups in DayTickler.
In this post, I present one of the most promising feature of DayTickler.
An important structural element of DayTickler is the daily list. It simplifies the challenge to pair your brain with your gut by providing a schedule for what needs to be done today. Separating your "Today" list from the master "To-do" list is a clear incentive for action.
I have long assumed that this was the most important feature of DayTickler. I changed my mind recently, as I just finalized prototyping a new feature that we call “personal workgroup”. This powerful feature enables users to tickle their family, friends and buddies to team up and complete tasks.
This is much more than simply list sharing. By relying on the daily schedule, everyone can easily follow workgroup progress.
In this post, I am providing a progress status on the development of DayTickler.
As I wrote last June, the first version of DayTickler (the one that we will officially published in the app store) must be a lovable and marketable product. Because we aim at validating if a product/market fit is obtained, we must avoid publishing a prototype.
A prototype is perfect to test for usability because it allows evaluating facts. However, it fails miserably for evaluating usefulness. It is not the appropriate tool to validate the degree to which a product satisfies a strong market demand. As stated by Laura Klein in the article Building the right thing vs. building the thing right, “you can’t use a prototype to learn if you are building the right product.”
The right product is a product that does what we imagined, but it is design so it has what customers really want and need in a form that is easy to use and atheistically pleasing. In order words, the right product is a product that is built “right” or at least “right enough”.
However, as Ron Jeffries wrote in 2014, “You can't build the right product if you can't build the product right.”
Therefore, in June and July, we continued to validate our design with prototypes. As always, we are learning to be humble. Obviously, some of our assumptions were wrong. We found serious problems with the user experience. At such a point that we spent the last month redesigning our application. The good news is that our recent prototype tests are conclusive. We are on the right track.
When will you have access to DayTickler in the app store? Not until November. We must build the product "right" and to reach that goal we need to do more usability testing.
In this blog entry, I explain that we should categorize DayTickler according to the structure it promotes.
DayTickler is a productivity tools that can be classified, in a general way, as a personal tasks manager. Unfortunately, I do not think it’s a good classification. DayTickler is a mix that paired a daily calendar with a to-do list. I think rather that it should be classified as a daily planner because it is the structure that it promotes and puts forward.
This might surprise you, but committing and achieving tasks is all about structure. In my life, if there is one key lesson I have learned, and on which I have already written, which has near-universal applicability:
“We do not get better without structure”
As a matter of fact, without structure, we do not change our behavior, and we do not become successful. Unfortunately, incorporating the right structure into your daily routine is challenging. This is why you should rely on a productivity tool such as DayTickler.
I am among those who believe that a mobile app such as DayTickler must be opinionated. By design, it should lock and guide the user to do things according to his way. Put another way, there’s clearly one right way of using the application which is nice and easy, and any other way of using it makes your life difficult. It provides a recipe that not only simplifies the user experience but ensures to achieve results. Recipe limits the options so that users are not thrown off course by externalities. When users follow a recipe they are relying on structure to simplify the complexity and improve the odds of success.
The most important structural element of DayTickler is the daily schedule.
Separating the “Today” schedule from the master “To-do” list of everything that need to be done is a clear incentive for action. If the user schedule its daily commitments, he (or she) is much more likely to achieve them. It is as if the act of scheduling that increase the moral obligation. The “Today” schedule lets the user focus on what must be done today, while the “To-Do” list gives the user a place to dump every little task he (or she) think that someday must get done.
The nameless is the origin of Heaven and Earth, while naming is the origin of the myriad things.— Lao-Tzu
We live in a complex world and one of our first challenge is to structure it so that it seems simple. Obviously, we will not be left to ourselves facing this major challenge. Early on, our parents will provide us with the foundations. Among other things, they will teach us a language and the meaning of words. We often forget that the simplest way to reduce complexity is to name things appropriately. A Chinese proverb says that the beginning of wisdom is to call things by their right names.
Slingboards Lab is not the first company that I founded. In 1991, after completing my master's degree in management of technology from the Ecole Polytechnique de Montreal, I founded a software company to market a drawing program for value engineering. Unfortunately, my company did not had the expected success. This is explained by the fact that my product, whose name was Fastdraw, found himself competing against the Visio drawing software. I had customers, but not enough for this to be very profitable. After a few years, I closed the business. Oddly enough, 24 years later, I still have an old client using my product. They still consider Fastdraw as a better option than Visio. Lately, they contacted me because they wanted me to program a modern version. I politely refused while freely providing them with the original source code.
A few days ago, I took a look and I was amazed by the structure of the sources. This program was a 16-bits Windows 3.1x app written in C ++ using the Borland C++ v4.0 IDE and OWL library. Each object has its own CPP and H files. The naming convention makes it easy to identify visual objects such as windows and dialogs.
For those too young, in early 90’s the filenames were limited to 8 characters (a MS-DOS constraint), here is why we find names like TOOLBARW instead of TOOLBARWIN.
As you can see, already at the beginning of my career, I was from the school of those who believes that words have meaning and names have power. By setting up an appropriate structure such as the combination of words with a convention, you can reduce complexity and make your code easily understood even 24 years later. Success is all about structure.
In this post, I explain why the first version of DayTickler must not only be lovable but also a marketable product.
Following my last post some readers were surprised that we will take almost nine months to produce a minimum viable product (MVP). According to Wikipedia, a minimum viable product (MVP) is the product with the highest return on investment versus risk. Usually, a MVP only has those basic features that allow the product to be deployed, and no more. The product is typically deployed to a subset of customers (early adopters) that are supposed to be more forgiving, more likely to give feedback, and able to confirm a product vision from an early prototype. As stated by Eric Ries in his colloquial book The Lean Startup, "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
At this stage in our product development, we seek to validate whether customers will agree to subscribe to the premium version of DayTickler. As we aim to market to consumer in an already mature market (there are already over a hundred to-do app), we can hardly launch a product that would be perceived as incomplete. We need to polish the software to the point of making it lovable, and this requires time. Furthermore, it must have all the necessary features to make it marketable. In our case, this requires building not only the core of the product but also the main feature that will convince customers to subscribe and pay for the premium version. This means that the product cannot be a prototype and this takes work. Especially that while building the product, at the same time, we continue to do consulting. Here's why the construction of the MVP is so demanding and requires more than 9 months.
In this post, I am providing a progress status on the development of DayTickler.
For more than seven months, with my business partner Erik Renaud, we are currently building the first version of DayTickler, a mobile app to plan your "Today Schedule". It's going well. By the end of August, we will have a Minimum Viable Product (MVP) ready for launch in the app store. The process may seem long but we must ensure that our first version will be a minimum lovable product.
As noted on twitter by Jussi Pasanen, building a MVP is much more complex than programming a few scattered features. This is a wise mix of a functional, reliable, usable and emotional design.
In this post, I explain why DayTickler allows to focus on “Today”. Why should you separate your "Today" list from the master "To-do" list of everything that need to be done?
“The list is the origin of culture. It's part of the history of art and literature. What does culture want? To make infinity comprehensible. It also wants to create order -- not always, but often. And how, as a human being, does one face infinity? How does one attempt to grasp the incomprehensible? Through lists, through catalogs, through collections in museums and through encyclopedias and dictionaries. There is an allure to enumerating how many women Don Giovanni slept with: It was 2,063, at least according to Mozart's librettist, Lorenzo da Ponte. We also have completely practical lists -- the shopping list, the will, the menu -- that are also cultural achievements in their own right.”
"The list is the origin of culture," said Umberto Eco in a fascinating interview with the magazine Der Spiegel about his book The Infinity of Lists: An Illustrated Essay. It seems to be in the genes of human nature to make lists. Unfortunately, lists always end up being too lengthy and in which the significant items are too often hidden. Exhaustive lists are useful to document and catalog the culture of a society but are little use to list things to do.To-do lists invariably crop up when we have so much to do that we can’t memorize all in our heads. Which means that we end up with lists far too long for us to complete. A to-do list with 20 or 30 items is not only daunting, it's depressing: why even start when there's no way you will ever finish.
DayTickler solves this problem by allowing you to create a list for things to do today, right now. Pick three or four items off your to-do list that will make the most difference and schedule them in your "Today" list. The action to schedule does not necessarily implies a temporal dimension, you can plan to do something in terms of a place, for example, when you are in your car or at your computer.
Separating your "Today" list from the master "To-do" list of everything that need to be done is a clear incentive for action. The "Today" list lets you focus on what you must do today, while the "To-Do" list gives you a place to dump every little task you think that someday must get done.
In this post, I explain that despite all odds a calendar is inadequate tool for scheduling todos. By the same token, through my argument, I take this opportunity to introduce you to the most unique feature of DayTickler.
A calendar is a fantastic tool for scheduling events. It provides a very appropriate visual metaphor for time planning. This tool is appropriate because it is rare that we have to postpone an event. Events come and go; when their time come they perish like flowers.
This is just the opposite with todos. Unlike events, more often than not, we are not able to complete a task on time. The accidents of life forces us to postpone the work later. Todos do not perish like flowers. They are rocks that clutter our way and that we must push ahead. Postponing a task is a very common scenario and unfortunately calendars do not forgive. Repeatedly we need to manually edit the start and end time. A cumbersome punishment that has no reason for being.
We need a tool that will automatically move, as time progresses, uncompleted todos.
This feature is one of the most important behavior of DayTickler, the personal task manager I am working on for several months. As I stated in a previous post, the most unique feature of our software is the ability to schedule a todo and the fact that, until it is completed, it moves as time progresses.