Adventures in code and computation.



Designing Taskelot's Initial Model and View

01 Jul 2015

One of the first thing one should do when developing a software system is consider carefully what the output will look like, and how the user might interact with the system to generate the output. A great talk that has further influenced my thinking in recent years is Ryan Singer’s 2010 talk, A tour of the design process at 37signals. In that talk he demonstrates how he approaches the design and implementation of a web application, starting with an analysis of the needs of the app, extracting a set of models and their relationships, then sketching out a basic design which is translated into rough HTML; that design is then ready for building out the application logic in code and iterating on the design.

Taskelot Output

For Taskelot the main output is a list of tasks (or TODOs), which can be grouped, filtered, and searched upon via tags, categories, and projects. I already have a bit of a prototype in place: the way I am managing my current TODOs in an interim text file. In a way, that might be considered my first prototype. Here’s a screenshot:

Screenshot of Vim showing my interim TODO file

Based on how I’m currently managing my tasks in a plain text file I can sketch out a little UI mockup in GIMP:

Tasks Grouped by Project, Design Sketch

I have each set of tasks initially grouped by project, with a project list on the sidebar for easy access to jump down to a specific project’s tasks. (Something I need to figure out is what to do with tasks not associated with a specific project).

The basic models I’m managing are:

I’m not certain there’s a good reason to differentiate between a tag and a category; that distinction may be removed as I go along with the project; but for now, that’s a start. It is noteworthy that in my initial sketch I didn’t bother showing tags or categories anywhere. For the first iteration of taskelot I will focus just on Projects and their Tasks, and some way to have non-associated Tasks represented. That way I can transition as quickly as possible to having an app, however incomplete, that I can use to get real work done.

Model Fields

Projects obviously have a name or title, and are associated with each of their tasks. You could say they contain the tasks (unless we find later we want tasks that can be associated with more than one project; for now we’ll just say that each task can be tied to at most one project).

Tasks have not just a name, but a state (completed or not completed). We may also wish to have a state of archival (whether complete or not), to indicate we no longer wish to have the task shown in our main views. Tasks that are not complete but which are archived might be a good indication that the task is no longer relevant and that we no longer plan to pursue it (i.e. it’s been canceled).

Model Actions (Methods)

Projects and Tasks may both added, removed, and have their names changed. Tasks additionally may be marked complete and archived.


Plan of Attack

I believe I have enough to work with to build something usable in just a few days. I’ll start with a traditional round-trip style web app; no front-end framework goodness just yet. I need to first get some ideas fleshed out using the most basic forms I can. Once I have the basics down with Taskelot I’ll study up on Backbone and refactor the user interface to be managed client-side with just a simple RESTful JSON API powering it on the back end.

I am learning Flask and Jinja2 as I go along here, so I will need to invest a bit of time into reading up on Flask and going through it’s available tutorials and documentation to build an effective first iteration. Also, I’m not worrying about user authentication at this point. That will presumabely be handled elsewhere by an authentication middleware; we’ll address that in the future.