It seems with bug and issue trackers, the default is to drop all of the data into a tabular format. While it’s easy and works great for numerical data, it’s never felt right to me for text-centric data, let alone task-oriented data. Tables, by design, put an equal amount of emphasis on columns (attributes) and rows (records). The underlying assumption in a table is that it’s equally valuable to quickly compare columns as it is to compare rows.

With bugs and issues where each of the attributes are inter-related with other attributes, the value of each column individually is diminished. For instance, a “critical” priority on an issue isn’t really all that critical if the issue is closed. Bugs and issues are, at their core, simply fancy todos. It’s a todo list. Not a todo spreadsheet. There are elements of todos where a tabular format helps, but it’s overkill to drop every single piece of data into a dedicated column.

In a subtle, but telling way, this has become more obvious to me based on how I explain what Sifter is to friends and family. Whenever non-technical people ask me what I do, I always end up telling them that I built software that is a "fancy team todo list’. Sifter isn’t a spreadsheet for tasks, it’s a team todo list, and I’ve been trying to think more in terms of tasks and less in terms of attributes.

Today, while the data isn’t in a table, it might as well be as it’s simply dumped out there as “groups of attributes”. It works, but it’s not very elegant. There’s way too much noise and distraction. In part, this was a result of a fixed-width two-column design, but that was a poor decision for the issue listing page that we’ll be rectifying soon.

Screenshot of the current version of issue summaries.
1 The current issue summaries are more “groups of attributes” than atomic tasks.

The new version places an emphasis on tasks rather than “groups of attributes”. It also helps give each row a more unique visual signature so that they don’t all blur together and look the same. This helps make it easier to quickly identify issues and distinguish them amongst the others in large lists.

Screenshot of the upcoming version of issue summaries
2 The new issue summaries treat issues as tasks first and data second.

Horizontal Spacing, Rigidity, and Alignment

The biggest challenge that tables bring is that they are incredibly good at forcing you into a structure that can quickly waste horizontal real estate because each column has to be as wide as the longest data point in that column. This disconnects the attributes from each other and makes it increasingly difficult to view each row as a connected piece of data.

Screenshot showing how horizontal space disconnects attributes.
3 Tables quickly lead to columns being disconnected from their row siblings.

Similarly, depending on the alignment, data points end up becoming more closely related to their columnar siblings than their row siblings, and the tasks end up as fragmented bits of data rather than atomic todos.

Screenshot showing how columns dominate rows.
4 With columns, the vertical alignment begins to dominate the reading and make it difficult to view each item as a task.

Data Relationships

When you’re simply display numerical data, there’s rarely a case for communicating relationships between two attributes within the table because that’s the purpose of graphing and visualizing data. However, when most (all?) of your data is text-centric, there’s a strong case for more closely grouping and associating related attributes.

With each task, there’s the primary information that you need to discretely identify any given issue. That is, there’s information that uniquely identifies an issue, such as subject or number, that will be unique the majority of the time. This is the primary information.

Then, you have the secondary information which are attributes like status, priority, category, project, assignee, etc. These attributes have varying degrees of value in determining what to work on next, and thus, have a different relationship with the task itself.

Screenshot showing two distinct sections of each issue.
5 The new version puts the critical identifying information first and the secondary information off to the side.

Priority, category, and project are effectively tags. Priority is special, and thus gets a special, more prominent, treatment. Similarly, you’re more likely to sort by priority to determine the list order and work from top to bottom than you are to want to choose an issue simply by priority. As a result, it straddles the line between primary and secondary information.

Screenshot focusing on the priority, category, and project.
6 Priority is handled in a way that it’s relegated to secondary data but given higher visibility.

Summary

Instead of swimming through columns of data and fighting the rigidity, we’ve chosen to emphasize each task individually and approach issue lists as just that. Lists. Not tables. The emphasis is on the work that you need to do, not an arbitrary structure imposed on a context where it doesn’t make sense.

Related articles… Never miss new articles…

Receive our blog posts in a consolidated monthly email. Don't worry, we hate spam too and make it easy to unsubscribe.

Alternatively, you can subscribe to our blog feed or follow us on Twitter at @sifterapp.