News from the Product Desk: Baseline

In August 2021, OpenProject hired two UX/UI designers, Marc and Parimal, and formed a new product team along with CEO Niels. Since then, we’ve been working on three fronts with each release: new features, UX optimizations, and ongoing work on the design system. With this new series of blog posts entitled “News from the Product Desk”, we would like to give you an insight into what we are working on and how. In this first post, we will be looking at a new feature coming in version 13.0: Baseline.

Origins of this requirement

Baseline was a feature originally requested by Autoliv. Autoliv is a global leader in automotive safety systems such as airbags, seat belts and steering wheels. The development of security technology is a complex undertaking requiring coordination with a large number of specialists from different organizations. Project managers depend on highly sophisticated project and risk management tools to be able to deliver on time and on budget, whilst operating within strict legal regulations. To achieve this, Autoliv manages their projects with OpenProject and requires project baselines.

The use case is fairly simple: projects are planned at the beginning and organized into phases where multiple co-dependent teams complete tasks over a period of time. As the project progresses, changes, delays, and new constraints affect planning and adjustments have to be made. Some tasks are completed, some are extended, some pushed back in time, and new ones are added. How can a project manager and stakeholders see at any given time, say three weeks after the start of the project, what has changed compared to what was originally planned?

This is precisely what Baseline makes possible.

Before being able to implement such a powerful feature, however, we had three main considerations: user need, technical challenges, and design.

User need

In complex projects, project managers have to stay on top of fast-moving changes and successfully coordinate between different stakeholders and interdependent goals. Without the right tools, it can be difficult to keep track of changes and accurately report the current state of the project to top management. This is why project managers usually spend a lot of time on status reporting, recurring meetings, and bilateral project updates. Baseline comparison is a large step towards making project teams even more efficient, allowing any project member to easily track and report changes over a period of time. We believe this will greatly improve project communication in distributed teams.

But in designing this feature, we had to understand how it would really work for the end user. First, we had to define “changes”.

Changes can happen at two levels: work packages and filtered work package table views. At a work-package level, the title of a task might be updated later in time, the start date might be pushed by a preceding task, it might be passed on from one assignee to another, or the priority might change over time. When comparing, a user should be able to see these changes between time A and time B.

At a view level, a filtered list, things are a bit more nuanced. Companies create views to track work packages that meet certain criteria. For example, at OpenProject we use views to track the scope of an upcoming release. Over time, changes to certain work packages attributes might mean they are added to this view (e.g. the version for a feature is changed to “13.0”), removed from it (e.g. the status is set to “cancelled”), or already included work packages might be updated (from status “specified” to “in development”).

Users should be able to use the baseline feature to identify these additions, removals and updates between time A and time B. This means that unlike with traditional baseline comparison, our implementation makes it even possible to compare changes to a view between any two arbitrary points in time in the past, without the need to predefine specific baselines. Our approach also makes it possible to create “rolling” comparison time frames like “changes since yesterday at 12 PM”, which can be useful for daily or weekly team meetings.

Technical challenges

Once we had an idea of what the feature had to achieve, we had to make sure that the backend was capable of providing us the data we needed. We decided to split the feature into two: version 12.5 will extend just the API such that it can be queried for historical information on a limited set of attributes and version 13.0 will introduce a front-end UI.

Previously, our API had no concept of a resource changing over time. A work package or a list of work packages always represented the current state. With Baseline, each work package or list of work packages also has its history attached to it, so the previously one-dimensional query results had to be two-dimensional. Additionally, we had to compare data from two points of time to determine if a work package existed (or not) in the past and if it met (and still meets) the filter queries.

All this has an impact on performance. Whenever a work package is modified, a snapshot of the new state is stored in the database. This means there are vastly more snapshots in the database than there are work packages. Since Baseline allows users to pick any two dates for filtering, the system has to process a lot more data to identify the relevant set of snapshots. And this is complicated by the fact that the user can dynamically add and remove active filters at any moment.

A third challenge was user permissions and visibility, which can change over time. We had to consider the possibility of work packages being visible to the user in the past but invisible in the present (because it was moved to a new project, for example).

As we work on version 13.0, the Product and Development teams are working together to come up with an updated scope and support for additional attributes to track (like parent and custom fields), new UI ideas around technical constraints (like how to input and display time-based queries to users in different time zones) and new rules (like how deleted work packages should be handled).

Design

Even though version 12.5 was only meant to be an API-level feature, we already had a rough sketch of how it might look. Early mockups are important and allow the product team, the development team and community members to have a common basis for discussion and shared understanding.

This is what the initial design looked like:

We updated the mockups over the course of multiple design iterations as we further refined the scope, defined the user flow and discussed technical considerations. For example, the Baseline modal evolved to always require a comparison time and indicate this in the user’s local time zone when necessary. This is because saying something like “yesterday” (24 hours ago) is less useful than yesterday at a certain time, since otherwise the comparison period keeps moving throughout the course of the day and the actual reference time is not obvious.

The baseline modal then looked like this:

When we realized that we didn’t have to limit the comparison time between the a past date and now, and that we could really allow the user to compare between any two time periods in the past, the modal also evolved to allow a “range” comparison:

Every time we work on UI elements where phrasing is particularly important, we check the possible translations in three languages other than English: French, Spanish and German, to ensure that our approach works in other languages as well:

The work package table also became cleaner (and less Christmas lights-y), with an added legend on top to allow users to better understand what each icon represents:

And finally, we worked on how the feature should look on mobile devices, and in cards view (where a limited number of attributes are displayed):

Next steps

Over the course of the next few weeks and months, the Product, Development and QA teams will be hard at work on features, optimizations and bug fixes for version 13.0, including Baseline. At the same time, Marketing, Sales and Support teams will prepare additional documentation and training for our users. Baseline will be released as part of the Enterprise cloud and on-premises versions, which also means an existing Enterprise add-on will be made available for free in the Community version.

As an open source company, we also work in the open. If you would like to track progress of this feature or even contribute to it, join our Community instance and watch or comment on this epic.