Abtract lists into a generalized task meta-data


#1

This post introduce a proposal to modify one of the core-concept used in both Wekan and Trello which aims to solve a number of usage issues Wekan users have raised.

No one asked directly for the feature presented in this post, but instead asked for “being able to use swimlanes”, or “being able to have different views of a board”, or “having the same card in different boards”, or even apparently less related issues such as “being able to customize the list background color”. The idea is to solve all of these issues by removing the concept of a list and replacing it by configurable card templates, or schema.

In the current model used by Wekan and borrowed from Trello, a board is defined as a list of list of cards:

Board = [ List(Card) ]

While it is true that this is the model we use in the implementation, it is not an implementation detail in the sense that it has some repercussions in the set of features exposed to the user and in the mental model we force him into.

Let’s remove the notion of a list of list, we ends up with:

Board = [ Card ]

With this model, we can no longer archive or restore a given list, but that that pretty much all the features we remove because it turns out that even with the current model most actions takes place either at the board level or at the card level.

While we are at it, we might also revisit the taxonomy

Project = [ Task ]

We removed one abstraction (the list) and ended up with a model that it is pretty similar to a TODO list, ie a one dimension list of task. How do we get back to the kanban views from this model? The idea is to attach some meta data to the tasks that are defined at the project level.

One of these meta-data might be called priority:

enum Priority {
Urgent,
Important,
Medium,
Low (default)
}

And then each Task has its own priority (and only one)

Task1 = { priority: 'urgent', ...otherAttributes }

One detail that we need to take care of is about defining a default position for newly created tasks, in the above example I assumed that new cards have a “low” priority. In practice it will probably be easier to always have an “Undefined” or “Unset” option in the enum that we can always default to.

enum Priority {
Urgent,
Important,
Medium,
Low
Unset (default)
}

Then the idea is that we can use this meta-data to represents the Todo list using a priority per column, and so we get back to kanban view of our project. But since our tasks can have multiple meta-data attached to them, we can have mutliple views on our project. Other examples of task meta data could be a release number, an assigned person, a completion state, etc. Each of these could then be used as a Project “dimension” used to define a view.

From them we can easily go further and define the swimlanes views, which is as simple as taking one data for the columns (for example, who is assigned to the task) and one data for the lines (completion state) which provide an easy way to see what everyone is doing in a team (the picture below is from http://rallydev.com)

One of the challenge of this development is to design a UI that is both intuitive and powerful. In my experience playing with project managers competitors, the one that implement the configurable kind of configurable views discussed here generally expose a lot of options and are pretty hard to configure.

We also need to think about the defaults, they probably should match the model that we currently have, ie Tasks have a single dimension which is usually their completion station (Todo, doing, done).

I’m super curious about what you think of this idea. If we end up making the sooner will be the better has a lot of the code everywhere is actually dependent on the core data model that we use.


This idea is inspired by this post and some discussions I had with frustrated Trello users.


#2

I think it is a very clever idea. I like the idea of factorizing several concept into one. With a filtering feature it will let you customize a lot of different view of your project. And since the default configuration can give the same behavior as today, I do not see any drawbacks.

However I do not see how it is related to swimlane or background color feature.


#3

From a model perspective, what is being envisioned here?

Swim lanes == tagging, like “priority”

BUT, is the real ask for “Grouping”, means a relatively loose association between cards?

This changes the model significantly:

SWIM

Cards:{
1: {
priority:high
},
2: {
priority:low
}
3: {
priority:low
}
}

GROUPING
Cards:{
1: {
link_id:hash123
},
2: {
link_id:hash456
}
3: {
link_id:hash456
}
}

The main difference is the binding of cards TOGETHER, not simply spatially arranging them.


#4

@shaunstoltz could you elaborate on what you were saying? I don’t understand the link between priority and ‘swim lanes’.

From what I understand of Maxime’s post, he’s referring to using swim lanes as a form of UI layout:

  • Two axis to show the progress of cards, plotted with the axii as ‘Username’ vs. ‘Completion State’ (or column name).

I envision the swim lane description very similar to how swimmers compete in a racing pool. From the audience’s perspective, each one has his/her progress clearly shown against the others, but they are all independent. This isn’t the best example photo, but it’s exactly what came to mind.

@mquandalle - I think what you’re proposing solves the ‘cards on multiple boards’ problem very nicely! I’d love to see it implemented. My team has a lot of tasks that are passed between developers, and this would ease keeping track of who is working (or reviewing, or merging) a given task, especially since everyone is multi-disciplinary and bounces between projects very quickly.

Along this line, it would be great as well to have a global ‘user’ view where we can view all assigned tasks for all projects we are a part of. Of course, it would require that each project has the same column names… Maybe I’m thinking of it incorrectly.

In any case, I do think having the ability to use arbitrary metadata associated with a card to create new ‘views’ is very powerful. I can’t think of a good way at the moment to combine User vs. Completion State vs. Priority though. Maybe the priority would be useful when a user wants to see their personal board only.

EDIT: elaborated on another idea


#5

Hey @mquandalle,

I LOVE this idea, and to me it’s always felt like an incredible limitation of Trello - I’d love something like http://www.hyperplan.com/ (with a better UI though…).

Here’s my use case: in Trello I currently have a board where each list is a project, and each card is a task, in chronological order. I also have a board for my current todo, where each list is the date I should be working on something, and the order in a list is more the priority. What I do right now is move cards from the projects to the todo when I schedule a task, which is sub-optimal, as I then lose the “project” information…

So I think we should even go one step further, and also remove the boards as first-class card data. Then we would be left with a set of cards as data model, and “boards” as views defining:

  1. the scope: which cards to show
  2. the axis (what do you use to define lists and swimlanes)
  3. the ordering (how do you order the cards)

Each of these could be defined using cards meta-data (core or defined in plugins), so for example a tag “scheduled” or a “due date” would cause my card to appear in the “Scheduled” board/view.

The challenges I see with that approach would be:

  • how to ensure you can always reach all your cards: we could define an “All cards” view (or, harder, a “Not in any other view” view)
  • how to make this usable by people looking for just a kanban: maybe defaulting to the current model (that is, have a “board” and “list” meta-data and generate a view per boardId), and then having an advanced UI for power users
  • how to define access rights in a usable way: we may define some at the view level, but how do we define who has the right to define a view, and on what cards? Also, what about cards that don’t show up in any view? We probably need a 2-step system, where you can manage rights on cards, and then those people can define views with enlarged rights.

#6

I’m copy pasting 2 messages that were written on GitHub about this exact proposal:

By floatinghotpot [source]:

I think it's good to abstract the cards with meta data. Actually, even when define labels, they can also be grouped into customized groups, like version/priority/module, etc.

The list in a Kanban board, to my understanding, usually means stage/progress, it’s the core concept of Kanban methodology, value flow. It will be more flexible if you can define arbitrary dimension for a board, but, I will still ask the same question, is it over-engineering? Will it be enough to select any label group as vertical dimension?

Another question jump into my mind is, now I can watch a list for progress and notification, I am just wondering, how to implement if the list is a meta data?

BTW, the animation gif showing swimming lane and dragging card to another user, it looks cool, but I am not very sure about its value in a real project, if several users all have multiple cards, the vertical space won’t be enough. And, in this implementation, how to assign a card to multiple members?

By nata-g [source]:

I was thinking along the same lines as @floatinghotpot, who articulated it better than I could have. Below is my .02 cents:-).

While having cards with meta labels abstracted to be used as proxy to lists is useful, in using as swimlanes and animation and can give a bird-eye view of the point in time awareness, I am not sure it is possible to capture all of them in an abstract meta-model with the various permutations and combinations that go along in a real life project. It can easily get overly complicated because there can be so many configurations and my concern is it might lead to unintended consequences.

Like, for example, if we use a meta-label tag of “Done”, and map it as one of the dimension, its definition is different for different projects. For some some projects “Done” means done of the whole project, while in other projects “Done” means closure in one stage but it is still a continuation in the whole scheme of things and goes to different stage where it might be the beginning of the same project.

For Example, if I have a project of writing and publishing a book, and I assign “lists” (or meta-labels) denoting each chapter, every chapter can have different ‘done’ stages that is defined by the author depending on his workflow. May be his workflow is taking each chapter instead of the whole book. Like, one task might be the ‘outline of each chapter’ and other task might be ‘writing each chapter’ and after he is ‘done’ writing he might send to ‘editing’ to a different person(who is doing his own tasks ) before taking on to the next chapter. Just this workflow piece can have so many configurations that needs some kind of ‘task completion’ ‘progress’ , ‘review’, ‘notifications’ etc. As you can see the flexibility will be lost if we provide anything that is pre-defined. I am assuming other projects can be as complicated, if not more.

I mean it is a good idea and I can see how just having ‘cards’ in ‘projects’ and using ‘labels’ as a meta for ‘lists’ is useful and can make it easy to map in to different stages and creating cool views. It can be made more ‘specific’ and I guess the biggest complaint against Trello is it is too general, so if we can be able to create the same flexibility using ‘meta’ notion of lists then it would prove to be really useful and I can see definite advantages in using it. But I really think it is going to be really hard to define all those configurations in an abstract meta model.


#7

I`m really love this Idea !
It would great to Coordinate the Task directly in WeKan :grinning: