Preparing the "now-page"
The “now-page” concept, designed to help users focus on their current tasks, faced unexpected challenges in implementing features like logging, timers, and notes. Due to these issues these additional features were removed from the design which improved our design.
The past week, we've been working on a concept called the "now-page." This page is designed for users to display their current tasks and activities. It's entirely focused on the user and includes many useful features to enhance their work experience. We envision this page as your "personal space," while all other features are designed for your "work space."
We make this distinction because life is unpredictable. Even if you intend to focus on one task, you're likely to be interrupted by something else, such as a phone call, a client, or a coworker. These interruptions can lead to exciting opportunities for your personal projects.
Therefore, the "now-page" allows you to combine all your workspaces and organize your work in a way that enables you to focus on the "now."
We wanted features like task management, logging, timers, and note-taking, which are essential tools that users often need "now" and that are often used in an unstructured.
However, as we've been designing the "now-page," we've encountered several challenges that we need to address. As we delved into each feature, we discovered that many of the smaller features were more complex than we had anticipated and should at least be delayed.
One small feature: Logging
For example, we want to introduce a system that is called logging, which initially seemed very simple, but quickly became incredibly hard. Basically every time we want to give the user the ability to record what happened, when, and where.
But while designing the feature we noticed that we don't always want to keep track of where it happened. Someone might be traveling or the location doesn't matter. And sometimes we don't care about the "what" and only the location since we just want to record our location.
And then we focussed on how we should handle location. Obviously the latitude and longitude seemed to make sense as a starting point. Until we assumed an use case where someone is flying. The accuracy of their location is highly inaccurate, so a virtual location like "airplane" might be a good solution. But what about physical locations that change? Someone might be working at the site of a client ("Working at Acme Inc.") which seems fine until that client moves to another location, and suddenly the address changes.
And then we got to the issue of privacy. Simply put, we don't want to store private information. And automatic tracking is something that sounds quite nice, until you attempt to find all the different strategies on how we should manage that information, such as deleting or updating.
And suddenly a very small feature became incredibly complex. So we looked at another small feature.
Another small feature: Timers
Another feature we wanted for the now page was the ability to keep track of time, essentially timers. However, we sometimes want a timer that counts up, while at other times, we want a count timer that counts down. Additionally, we want timers that we can interrupt and resume, and some timers should even do it automatically. We also wanted interval timers so that users can use them with the Pomodoro technique. And what about daylight saving if we are dealing with a timer that counts toward it? How far in the future could a timer be started? Can I put timers for birthdays on it? Should it have descriptive titles? How many can we run at the same time? Can timers be split or grouped?
Now we know that timers are very complex. But we had so many questions about what functionality we wanted that we decided to put a pin into it.
So... We looked at yet another small feature.
Yet another small feature: Notes
Okay, so we were thinking about using notes or Post-its as small pieces of text that we can display. That should be easy, right? However, we need to consider how long we should store these notes. We could decide on indefinite storage, but the entire idea behind the now-page concept is that "now" is temporary by its very nature. So, should we delete the notes at the end of the day? Should we ask the user which note should be moved to the next day? And if we store the notes as a separate entity, unrelated to the now, why can't we display them on a workspace? Can we recover notes that have been removed? Should we keep track of the changes? How much text can a note contain? Can the user search through the notes? And so on…
These questions made it clear that notes weren't just "simple notes."
It's not all bad
It sounds like we are complaining a lot, but in truth we quite happy that each time we discover these problems before even drawing a single design or even touching a single line of code. All of these issues demonstrated that the feature is far complex and requires a whole lot more thought before we should develop it, never mind releasing it.
We are mostly describing this process to demonstrate that we we take our product very seriously. We want humans to be central. And we would like to add that if we were using AI all these features would have been in production already but without the proper deliberation that we have demonstrated above.
Back to the now-page
In the introduction, we discussed the now page. We've already described three features that are currently being removed from the feature specifications. These features might return later, but they will not be introduced right now. This means that the now-page has significantly less functionality than we initially assumed. However, that's fine.
The more we eliminate features from the specifications, the clearer the intended functionality becomes. Essentially, we've simply removed unnecessary elements. We don't need logging, timers, or notes to focus on the "now".
Now all that is left are the elements that are actually needed and we can finally start making it. 😄