Elephant Blog

Elephant is a task management and notetaking app, using the Getting Things Done methodology by David Allen. In this blog I talk about the design decisions behind Elephant and productivity in general. You can learn more about the app at elephantneverforgets.com.au.

[elephanttasks-blog]

Shouldn't Apps be smarter by now?

Computers have changed the way we work, taking the load off a wide range of manual tasks. This is especially true when it comes to shuffling around information, be it number crunching, communication or storage. That said though, there's nothing particularly clever going on here is there? We can do things much better than we used to, but in so many instances applications are still just dumb tools waiting patiently to be told what to do.

Why can't computer applications do more with all the analytics we throw at them these days? It seems like the majority of their power is put into matching us with the right advertisements, rather than making it easier to work with their applications. Why can't Gmail take any educated guesses when it comes to tagging our emails for storage? Maybe suggest some rules for a user to help filter their inbox?

Why is it that near every task management application seems content with being a tool that makes managing information easier, but rarely does much in the way of giving advice to help you plan your tasks and projects? No tool can pretend to be entirely free of opinion as to how it should be used, so why don't applications go a step further and be proactive about guiding the user?

I'm talking about more than simply 'how' to use the software here. We have plenty of excellent advice and knowledge embedded in books, but truly taking on those lessons is not always the easiest for busy people. Getting Things Done by David Allen is 259 pages long, and while reading that is not necessarily an arduous task, absorbing all the lessons inside and being able to apply them to your life takes time.

Shouldn't the tools be able to help with this though? Not necessarily a substitute for having a true mentor or coach, but better than nothing right? What if the app recognises when you're making a project about organising a meeting, it gave you some important bullet points from Read This Before Our Next Meeting, to help supplement your mental check-list? How about reminding you about potential things you may have missed when you start recording a shopping list for your errands?

Why can't an application help you with your weekly review? It should be bringing your attention to dormant projects that aren't going anywhere, and give you suggestions to help clarify what's next. What about a simple step by step check-list of what your review should cover, that you can personalise to your own work-flow. Embedding the knowledge of all those experts out there into the application, it could guide a user from small beginnings to being a disciplined and organised professional, without sacrificing their productivity while they find their way.

Of course, this are a few obstacles to overcome here. Ensuring the intellectual property of all the great resources out there are respected. Not becoming another annoying paperclip from certain office package by making sure the advice is relevant AND wanted. Ensuring any analysis involved respects the privacy of the user, used to improve the user experience and not the advertisement targeting. Nothing here is insurmountable, and arguably very much worth the effort if it means more people can learn valuable skills in managing their lives.

I've built yet another tool for managing a 'Getting Things Done' system, but I'd like to think I can make it much more than that. I'm currently running a campaign to help turn my humble little application into a full service, and as it grows I'd like to explore the ideas I've talked about in this article.

Want to see it happen? Please support me by pledging to the campaign, and spreading the word to your friends. GTD applications should do more than just be a passive tool, they should be actively assisting you to keep on track and disciplined, and I'm going to do my best to make it happen.

[elephanttasks-blog]

Estimation is worthless without review

Estimation is hard, projects go over budget every single day causing trouble and stress for everyone involved. The only way to improve at anything is to practice it, a lot, and the best way to do that with estimation is to have that ingrained into your day to day work.

Improving your estimation doesn't require you to record your work time down to the literal minute, and in many cases that's impractical, but you do have to track something. Without a process that allows you to review the accuracy of your estimates, you won't be able to improve it. You need to make that process an integral part of your workflow, here's a few examples of formal processes that are out there.

The Pomodo Technique

The brainchild of Francesco Cirillo, the foundation of this technique is short sprints of work followed by rest. Called a 'pomodoro', traditionally this is 25 minutes of uninterrupted work followed by 5 minutes of rest, there's more to it than that but that's the gist of it.

The Pomodoro Technique uses this as a base for estimation when you plan your activities, and because part of the technique is deferring interruptions until the end of the pomodoro, it helps make it a true measure task complexity because you aren't allowed to multi-task while you're doing it.

When you plan out your day's activities, you estimate how many pomodoros each task will take to complete. Whilst you're working you record each pomodoro as you work through them until the job is done. This makes the technique not only a good way to keep disciplined and on task, but also makes it easy to review how your estimates line up with reality.

Agile Software Development

Agile development uses a rough method of estimation to help gauge the 'velocity' of your team. Rather than use an absolute measure of time like hours worked, you estimate using points. Each feature you're looking to implement gets given an estimate in points determined by the developers at the start of a sprint, a period of time that usually lasts one or two weeks.

When the sprint is finished, you look at how many features your team completed, and then add up the points to make your total for the sprint. What's the point of this? The system acknowledges that we are pretty bad at exact estimation, so instead you use a point system. As long as the people in your team and the length of sprint stay consistent, your point system should average out to 'velocity', that lets you reasonably predict how many points you can get through each sprint.

It doesn't necessarily matter which process you use, as long as use it consistently so that you can improve the accuracy of your estimates. With practice you'll have a much better idea of how you're spending your time, which is absolutely critical in all sorts of important decisions such as:

Quoting appropriate prices

Deciding when you've taken on too much work

Balancing the time you put in against the results you get out of work

What system do you use for estimation?

[elephanttasks-blog]

Tools are not motivation

This is going to sound odd coming from someone trying to build a business around a productivity application, but people looking for motivation in an app, or a new exercise bike, or a diet, **won't find it**. Motivation is about passion and drive, not gimmicks and gamification. If you think buying an expensive device, or a new application will shock you out of your procrastinating days you have another thing coming my friend. Watching a number go up every time you go for a run may hold your attention for a few weeks, maybe even months, but it doesn't substitute for real passion to achieve whatever it is you want. Real lasting change is something you give a damn about, it's making a commitment to changing yourself or your situation and doing something great. Real lasting change doesn't come with a price tag, it comes from within, you just have to _look for it!_ So you want to get fit? Don't just go run on a treadmill out of obligation. Do something you might enjoy, go trail running, take up a team sport, train Parkour; heck, do ANYTHING but the most boring and sensible option. You'll just be setting yourself up for failure. You want to learn a new skill, programming, carpentry, whatever? Choose to actually make something that you care about then, whether it's an application that solves your problems, or a piece of furniture that you need. Creating and achieving something you care about is **essential** to your success. You **will** have problems, you **will** make mistakes. It will not be easy, and people will doubt you, but that won't matter because you are passionate and committed to the thing you wish to create. If you haven't found it yet, you need to keep looking, because the safe road is the most risky road of all when you only have one life to live. The tools help you achieve your goals, but the motivation is all you, so get to it!

[elephanttasks-blog]

Development with AngularJS: Dynamic Directive Insertion

> This is a blog post about the development of Elephant, geared towards developers looking to use [AngularJS](http://angularjs.org) in their own projects. Complex applications can get quite heavy. Using the Angular directive `ng-hide` is a bad way to manage hidden forms, as everything underneath is still there even if it's hidden. With a long long list of items, if they each had a hidden form to itself you'd end up with way too much going on, and performance would suffer for it. With a usual application you'd probably use an AJAX request to get the HTML on demand, but with an AngularJS application that's not the way you want to go. Instead you use [custom directives](http://docs.angularjs.org/guide/directive), which you can give a template for your hidden form. Now, the way directives work in AngularJS is they only get compiled when the page/controller gets loaded, so if you want to use a directive this way, you have to insert it and then use the `$compile` service to compile it. You also need to get a hold of the scope to bind the compilation to, either by using `.scope()` on a DOM element or just by having it available within the controller or directive you're writing the function in. From within a directive the function might look a little like this if you were using jQuery:

// rest of the directive options link: function(scope, element, attrs) { scope.loadHiddenForm = function() { hiddenForm = $('<hidden_form></hidden_form>'); $(element).append(hiddenForm); $compile(hiddenForm)(scope); }; };

With that you'd be able to give an element `ng-click="loadHiddenForm()"` and it would load your form and compile it as per the directive. Any better ways to do this? Let me know and I'll edit them in.

[elephanttasks-blog]

Dangers of Due Dates

The Getting Things Done style of task management cops a bit of flak from some people for actively discouraging setting due dates. While for big projects I do agree that it is important to set realistic target dates to work towards, as they help keep it grounded and focused towards a finish line, setting due dates for little things can be a sure fire way to reduce your productivity. Whenever you set a due date, you're making a commitment to yourself to achieve that project. It's a symbolic gesture, you're making that task a priority. If you set due dates on everything, and you're busy enough, something will have to give eventually. You start breaking promises to yourself, missing due dates. As a result you start to lose confidence in the system you've made for yourself, you may continue to set due dates but you're not kidding yourself here, you're behind. Breaking promises to yourself comes with a cost. You feel less in control, and if you're not happy with how things are going your productivity will suffer. The idea to understand is that your priorities in your system is defined by the way they are **handled**, not the way they are **labelled**. A **#HighPriority** tag is meaningless without a system to ensure you keep yourself accountable. Whether you put something in your calendar that you check everyday, or in a list that you check when making calls, or on a someday/maybe list that you look over weekly, is what *shows your priorities for what they are*. Only put on time constraints when you absolutely need to, otherwise you'll lose the flexibility to respond to changing events and priorities. Well designed lists of actions in contexts such as **@Calls**, **@Emails**, **@Online**, **@Errands** and so on are a much more sure-fire way to keep forward momentum on your projects. They allow you to make the most of each context as they come up in your day, but the flexibility to react to emergencies and prioritise based on the information available to you. Make processes that help you move forward on projects, not vague obligations like excessive use of due dates, and you'll improve your system.

[elephanttasks-blog]

The problem with 'simple'

People like simple applications. So do I, I love an application I can get results out of with a minimum of effort, as I'm sure you do. The problem with simple is when you hit the limits, and then you're stuck with a choice. You keep using your simple tool knowing it's losing you time, or you learn to use something different, losing more time while you learn and bring everything over. This is part of what prompted me to start working on [Elephant](http://elephantneverforgets.com.au). There are heaps of cloud based applications for working with tasks, that I feel are just far too simple. They are literally a list with tasks which while great in small doses is hard to handle when you start really capturing everything that you need to be doing in your life. Our computer based lists should be smarter than simple, and that's the goal of Elephant. You tag next actions and projects appropriately using the **#** symbol for topics, the **@** symbol for contexts and **+** symbol for contacts. Elephant splits those lists up so you can always drill down to the information you need when you need it, and quickly. GTD is a complex system that you should be able to trust, but you shouldn't need to constantly fiddle with your tools to get the results you need. You should be working, and Elephant is about making a powerful system that doesn't require endless fiddling to get stuff done. As Merlin Mann said: > This is my stake in the ground about GTD: if you can stay focused on drawing from its best practices to get more of the important things in your life accomplished, then you’ll be a happy kid. For real. But if, like a seeming majority of people I encounter these days, you allow yourself to obsess endlessly over the minutest details of implementation and maintenance—well, you’re screwed. You’re wasting your time.