DEV Community: Imre Gera

Updating the design of a productivity timer app

Imre Gera — Tue, 03 Jan 2023 17:00:00 +0000

With a new name and design comes version 1.4 of FocusTide (formerly AnotherPomodoro). In this post I'll take a look at how I tried to make the app's design more compact.

FocusTide is a modern and flexible Pomodoro timer application I've been working on for some time now. It has timers that keep ticking after reaching the limit (people don't usually do something in exactly 25 minutes, this keeps track of that), a to-do list for each section, multiple timer styles, lots of settings and overall a design that tries to go out of the user's way.

I've been wanting to get rid of the clunky design of the top schedule view, the big control bar and the weird placement of the to-do list's button -- all of which were especially troublesome on mobile, -- but had no idea how. They all worked okay-ish on the desktop (as there's plenty of screen space there) but each of these components had their own share of design problems.

But before I get to the problems, here are some of the big changes coming in version 1.4, in a compact form:

AnotherPomodoro is now FocusTide. This rebranding is to avoid potential trademark-related clashes with the pomodoro word, which cannot be so freely used.
There is no separate home page now, just the timer view, accessible in the place of the home page (simply at https://focustide.app). If you had the /timer page previously bookmarked, don't worry, it will still work (and redirect to /).
The user interface got a big overhaul. New font, a more consistent and rounded design for all components, a compact top app bar, new timer controls and more harmonized colors.
The onboarding view now lets you set some of the settings for first use. Previously, it was just a bunch of small "reminders" of what the app can do, but now it is a complete setup process. Much more useful. It also has a progress bar so you know how much is left.
Time inputs are now easier to handle. The time input fields were reworked, they should be easier to use (no more small buttons to change between minutes and seconds).

Now, let me tell you how I (believe I have) solved those design problems.

Layout changes

First, as we'll need this later, the whole layout. My big problem with it was stuff that was scattered across the screen: the to-do button was near the bottom right corner (1), the settings button was in the upper right corner, and the schedule view was top center (2). Additionally, hacks were needed for mobile screens: the settings button was merged into the schedule view and the to-do button pushed the control buttons to the left (causing the timer start/pause button to be off-center) at mobile screen breakpoints.

This was both difficult to maintain and did not exactly achieve its goals: the control buttons were pushed to the side when the user enabled the to-do list, potentially causing missed taps due to muscle memory. The settings button was actually two buttons: one was shown on desktop, another was shown on mobile. The schedule display needed a lot of style changes on different screens.

Solutions

The schedule view at the top had big rectangles in it that multiple users identified as clickable buttons. They were not supposed to be clickable, instead they were just there to inform the user of what section they are in (work, pause or long pause) and what sections will follow. This was embedded in a grey box and it only looked right on mobile if I stretched it to cover the whole width of the screen. Essentially, the top part became a big panel on mobile devices and covered an unnecessarily large amount of screen space. Since I realized I like rounded designs more, I tried to create something smaller and circular.

To start off, I realized that a more traditional-looking approaching could work and went off to implement an app bar, essentially compacting everything into a 56px high bar. That meant the whole schedule view and the to-do and settings buttons. The buttons were easy, the schedule view was a bit more tricky. Since I wanted to put circles next to each other (and wanted them to seem less clickable), I wrapped them in a fully rounded panel and made them small. Then, since vertical space is small, I put the section's name right of this panel. The end result was a lot more compact bar that still achieved what it was supposed to.

For some extra flavor, I made the inactive entries smaller through a CSS scale transform and gave a white ring to the active item. I also reduced the default number of items from 5 to 3 (though this is still customizable).

Now the top bar does not block the view and it's also a lot smaller. Plus, I moved the to-do button here, too, so it does not shift the position of the control buttons anymore.

Colors

I use TailwindCSS for styling the app. I love that it's allowing me to have creative freedom over how I style my app instead of giving me prebuilt components (which is also great sometimes, especially for prototyping).

What I realized, though, is that I kept using Tailwind's colors freely, which made it difficult to identify parts of the interface: I used a 800 slate for one background, then later a 700 grey for another. The app was full of colors that were close to each other, but were still different. In the meantime I also used Flutter and Material Design 3, which uses primary, secondary (and sometimes tertiary) and surface colors and their variants (like primary, on primary, primary container, on primary container).

This use of abstract colors also helps keep the design consistent: a primary button is always of primary color and its contents are "on primary" colored. If I later decide to change the primary color of the app, everything changes with it (and I don't have to manually hunt down the individual uses of certain colors and their shades). Colors also have their dark variants, so I don't have to manually search for contrasting colors for a dark theme.

To make things even easier, I used the Material 3 theme builder to get a harmonic color theme for the app and set them as Tailwind colors, like so:

{
  colors: {
    primary: {
      DEFAULT: '#a7373a',
      container: '#ffdad8',
      oncontainer: '#410007',
      dark: '#ffb3b0',
      darkon: '#670311',
      darkcontainer: '#871f25',
      darkoncontainer: '#ffdad8'
    }
  }
}

Then I removed all uses of specific colors (like bg-red-200) and instead just used these abstract colors (e.g. dark:bg-primary-dark dark:text-primary-darkon). This helped me create a user interface where no component feels out of place.

The control bar

Another part to renovate at was the control bar. It used negative margins and z-index and fancy blurred animated rings to operate. It looked cool, but the buttons were close together, making it easy to tap the wrong button on mobile. Also, that spinning blurred ring wasn't a battery-friendly choice.

I no doubt like Material Design 3, and when I was looking for inspiration for a better design, I came across Google's Clock app, more precisely its stopwatch page.

It was exactly what I needed: the start/pause button in the middle and two secondary buttons to the sides. The main button is bigger and wider (though only while the stopwatch is running) and uses the primary color scheme. The buttons on the side use the secondary color scheme and are circle shaped. This is what I ended up implementing as well, without the resizing effect. Also, the secondary buttons disappear when they cannot be used, just like in the Clock app. And finally, the fancy glowing-rotating outline is gone. It was redundant and did not fit into the overall design of the app. The new design looks like this:

A quick word on fonts

Previously the app used Poppins, a friendly, rounded sans-serif font that looks a bit similar to Google Sans and became hugely popular. I now have switched over to Lexend, a font I really like and use as the display font on my KDE desktop, too.

The end results

With the above changes, I believe the app looks a lot cleaner than before.

What do you think? Feel free to share your thoughts on the changes and tell me what you would change. Check out FocusTide at https://focustide.app and see it in action!

AnotherPomodoro 1.2: export settings and non-strict timers

Imre Gera — Wed, 01 Jun 2022 15:06:08 +0000

Ever tried the pomodoro technique only to realize that you can't work for exactly 25 minutes? This update tries to solve that.

I've just released the 1.2 version of AnotherPomodoro, a modern, customizable and open-source productivity timer. This new release is seemingly small, but it actually implements two bigger new features.

Continued ticking of timers

One of the ideas was that we don't usually work for exactly 25 minutes: sometimes a task can take more time than what we set for the timer. The same goes for breaks. So AnotherPomodoro's timers now don't stop at the specified time mark but instead keep counting the extra minutes you spent working or watching memes. These timers now display how much extra time you spent on a section, allowing you to better keep your time management in check.

Exporting/importing settings and tasks

This feature was implemented based on a request. Since the app does not (yet) have syncing capabilities, saving your settings and tasks to a file can be useful when moving across devices or browsers. The saved file can then be imported in a different instance. It can also be helpful when you want to save different settings and tasks for different moods or environments.

Bonus: welcome screen

While the app is relatively simplistic, it does have quite a few settings and features and not everyone might be familiar with the pomodoro technique. Because of this, I added a small modal that pops up when launching the app for the first time. It shows a quick few-step-long tutorial on what to do and where to look for stuff.

To determine whether the app was launched for the first time, it checks if the app's state was restored during launch. If there was no data to restore, the app considers it a first launch.

The modal was modified for mobile devices to look like a bottom sheet, hopefully providing an experience that feels more at home.

The rest

There were some additional minor changes. See the full (though quite short) changelog here or check out the new features yourself and if you find something that you'd like to see to improved, don't hesitate to create a new issue on GitHub.

Have you tried productivity (or pomodoro) timers before? What are your thoughts of them?

How I reached 1.0: programming bit by bit

Imre Gera — Fri, 21 Jan 2022 16:46:44 +0000

In this article, I'll share my experience of how I built a productivity timer web application from start to finish, without entirely losing my motivation in the middle of it. I'll share some strategies and tips that have worked for me. Maybe they'll work for you, too.

This is part of a series on how I built a new Pomodoro web application, AnotherPomodoro, from start to finish. This article focuses on the development side of the process, but I plan to do a detailed write-up on the release part (buying a domain, managing branching, creating graphics, launching etc.) as well.

💡 Motivation

Probably the most critical question when building an app is why you are doing it. At some point, I realized that I couldn't structure my time well and ended up not being too productive. I thought that a small tool would perhaps help me: something that tells me to keep working for a little longer, possibly keeping track of my tasks as well.

I ended up searching for Pomodoro timers: the technique is about working 25 minutes and then taking a 5-minute-long break and repeating the cycle, turning every few pauses into longer ones. I tried a lot of these browser-based timers but none could make me keep using them. Among the main reasons were bloated designs (eg. small timer, lots of links and unnecessary stuff on the screen), simple customization features locked behind paywalls or the app just very clearly asking me to pay for it. Such things not only frustrate people but also distract them from the app's main purpose (to stay productive), in my opinion.

I also thought that making such an app should not be so difficult, maybe I could create something even better. I just had to decide on the platform and tooling, but since I was already looking at web apps and I already had some experience with Nuxt and Vue.js, I believed that I could leverage them to build my very own take on a great timer application. Time to start building it!

🏗️ Building an application little by little

So I started making the app and while coding it, I made a few observations of myself: how I worked, what helped and what didn't help. If there are two essential takeaways from the following paragraphs, they are to start small and work little by little. As cliché as they sound, they allow you to reach the end of the tunnel without giving up or sinking into "feature creep" mode.

Start with a working prototype

This is an advice that strongly applies to game development and many other fields, too. When starting a product, you should always try to make a minimal, working prototype first (like how on StackOverflow it is advisable to provide an MWE or minimal working example). In the case of AnotherPomodoro, that working prototype was the timer page with the following items:

A timer/countdown in the middle
A button that starts and pauses the timer

And that's it. No less, no more. See, the above list does not contain features that any viable productivity timer should, but that was not the goal, either! This was something that I, as a beginner, could implement in a short time, too, and once that timer page was there and I could start and stop the countdown, I knew that I was on the right track. I just created a timer, now I only had to extend it, and if that small prototype is not flexible enough anymore, I'll rewrite it, but I won't have to start from scratch again.

Go for the most critical parts first

Having built a working foundation for the app, it was time to put the word "productivity" into the productivity timer. For me, I had to move on to the following features:

Create sessions of three different lengths: 25 minutes for working, then 5 minutes for a short pause, and eventually 15 minutes for a longer pause. The app had to be able to switch between these in a particular order (work -> pause -> work -> ... -> long pause -> work).
An advance button to skip to the next session
A display showing the type of session that is currently running (just a string initially, like "work")

... and then I could start doing all kinds of fancy stuff: a progress bar in the background, coloured boxes for the different session types, a settings panel, fancy animations, whatever I liked. And once the timer page was done and had a minimally viable set of features, I could have a go at the home page and other stuff. I did the timer page first because that is what users would spend most of their time on, anyway.

It would've been pointless to start with the home page, because, logical it may sound, it's nothing more but a funnel to the timer page. Alternatively, I could have made the timer page the home page, too, as is the case with some apps. But then I would have had to introduce the app there, bloating a page that was meant to help you focus with its cleanness.

Managing priorities

It was also important to realize what is critical and what is not. There's no point building the fancy glowing ring animation for the play/pause button if the app still cannot switch between sessions reliably. Usually, it's a good idea to leave refining the visuals (eg. adding animations or making colours consistent) to the end, unless they are a key part of the application.

This won't be new if you've worked on a project before. If you're keeping your application in a hosted Git repository like GitHub, GitLab or Bitbucket (you better be!), then you should start making use of issues (with labels) and milestones as soon as you can. They help you categorize the features you want to have and avoid feature creeping, where you keep adding new stuff and thus growing an endless wish list instead of finishing the thing.

Here's something that maybe I could have done, too: assign 0.1, 0.2 and such milestones to my issues. It would have helped me "feature freeze" releases so that I don't keep adding all kinds of new wishes to the 1.0 milestone and release 0.x versions ad-hoc. It will be borderline impossible to create a fixed set of features for 1.0, because as you develop the app and time passes, your expectations will change, too. Still, it's a good idea to only add something to the 1.0 milestone (or any milestone) if you are sure you need it. You can also ask your friends or the people of the internet if they would want a feature or not.

As a bonus point, the issues you create in your repository can also serve as part of the documentation. You can outline new features there and you will even be able to generate changelogs from the merged pull requests (like I do using conventional-changelog/standard-version).

Face it: it will never be perfect

As with all forms of art, at some point, you'll have to draw the final stroke. In software development, it's not the final one, though, but it's a very important one: the 1.0 milestone. If you keep refining your app for years without ever releasing 1.0, it will remain unfinished and possibly hidden forever. AnotherPomodoro has been in development for more than a year now, which is probably a bit too long compared to that

I won't be making a lot of money with it (people don't support free projects that much) and
it likely won't have tens of thousands of monthly users.

Speaking of feature creep, in my case, I still think that it would be cool to add motivational quotes, a reward system, personal statistics and more to the app, but if I started working on these before releasing 1.0, it would probably take another year to finish. Also, new ideas and wishes would arise anyway, so maybe I wouldn't be much ahead on this journey. These things are not critical to make the app usable and enjoyable, so they go to the backlog, and I'll finish them if I have enough time and motivation.

Now I only need to fix the remaining bugs 🐞

I'd love to hear your opinion about this post, how you stay productive or what you think of my app! Don't forget to check out the app's GitHub repository!

See you around.

Creating a pomodoro app with open-source tools

Imre Gera — Mon, 11 Jan 2021 17:10:54 +0000

In this short and absolutely-not-technical post, I'll take a look at the choice of software used to create AnotherPomodoro. No code here, it's more about the choices I made for the technology stack and a bit of talk about static sites being capable of doing a lot.

The web as a platform

So I knew I wanted to build a Pomodoro timer (here's why I decided to do that). The question was: where do I distribute the app? Do I build a mobile app or a desktop app? Do I really need to build something that users should install at all?

I've been playing around with web development for quite a while, so I was quite biased towards front-end web technologies: just building something with HTML, CSS and JavaScript. You can actually build mobile and desktop apps with these technologies (Ionic for mobile, Electron for desktop), but since web browsers are essential and frequently-used apps in almost every operating system, you can just build a webpage and there's no need to install anything: just type in the address and there you go. Or if the webpage is a Progressive Web App (PWA), you can easily pin it to your home screen, too. Zero effort.

Vue and Nuxt.js

Web page it is, then. But I did not want to write HTML files because as the app would get bigger, so would its maintenance become more difficult.

I've grown to like VueJS recently with its huge flexibility (use JavaScript or TypeScript and integrate any CSS pre-processor, among others). Reactive frameworks make it easy to build an app where once you change something, that change is immediately reflected everywhere else in the app. You can notice this behaviour in AnotherPomodoro as well: go to the settings menu, to the display tab and toggle the schedule or change the number of items in the schedule. You'll see that once you click the checkbox or enter a different number, the changes are immediately applied - no need to press a "Save" button or reload the page! The best thing is that I did not need to program this behaviour into the app, first: Vue does it all for me.

Before starting out with AnotherPomodoro I've found that there's something that makes it even easier to build a Vue app: Nuxt.js.

Nuxt allows me to create websites that just work: no need to set up things like a router (what to do when the user types in /timer into the address bar) or some kind of state management (Vuex) and on top of that, the app is optimized out of the box thanks to server-side rendering. It also lets you create statically generated websites. With that nothing special is required to run your web app other than the "dumbest" kind of web server: one that can serve plain old HTML, CSS and JavaScript files. That's cool.

That's what I wanted, so I focused on building a fully static website. I probably cannot list all the benefits of using something like Nuxt.js and it might not be too interesting either: they are most noticeable to me, a developer. Among a lot of advantages, I can easily separate my app into components - like how the three styles of timers are just different components: when you switch between them, they get swapped. This makes it really easy to build more stuff into the app without it getting too bloated (like having thousands of lines of code in a single file).

Extending Nuxt.js

Right, web technologies are cool. Nuxt.js is really cool. How do I make it even easier to develop a web app? Well, let's get ourselves a UI library first to create a beautiful app quickly!

At first, I tried Vuetify. I loved it because it allowed me to build an app without having to know how to style stuff and program things like a modal (dialog) window. I just wrote v-dialog and I had a modal window with beautiful material design looks.

In the end, I felt that it slowed the app down and without effort, the whole site started to look really generic. I then decided to switch to Tailwind CSS (kind of the opposite of what Vuetify provides) and refreshed the app's looks with a hand-crafted design. There were no ready-made components any more but it's really easy to create whatever you want using Tailwind. I just write p-4 border border-gray-200 shadow and I have a box that now looks like a card: it has padding inside it, a grey border and a shadow. Awesome!

Later on, some more plug-ins were added to the site: I needed an app that can be translated into different languages (thanks nuxt-i18n and vue-i18n!), I wanted it to save the settings so when the user comes back they are reloaded (thanks vuex-persistedstate!), I did not want to write my own date and time formatting functions (thanks Day.js!) and so on. You can find the full list of modules I used on the project's GitHub page! There's a lot and they all helped make AnotherPomodoro what it is now.

Publishing the results with Netlify

Once the app was sort-of ready, I needed a place where I could host it so that it has a URL address and anyone can access it without having to execute commands on their computers. Normally one would say that you cannot host your website without paying for a hosting service. Sure, when you want to build an app with a database and extra logic and authentication (register and log in) - anything that requires some extra work on the server's side - that's not necessarily free. Or if it is free, you'd soon reach the free tier's limits, anyway.

Remember when I mentioned that AnotherPomodoro is a static website? There are services like Netlify (and Vercel) that allow you to not only upload a static website (one that consists of HTML, CSS and JavaScript files and no server-side logic) but also offer you to build that website from your source code! That means that whenever I change the app's code, Netlify runs a command so that Nuxt.js creates a static website from the app's code. These services are also a lot more generous with their free tiers: you get 100 GBs of bandwidth per month (the full app is around 2-300 KBs but you likely won't download all of that) and 300 minutes spent building your app (at least on Netlify) - of which one build takes around 2 minutes. This is more than enough even for a growing app.

"Hacking the system" with static websites

AnotherPomodoro is equipped with features that one could easily say would require a "proper" server: storing your settings and tasks, for example. Thanks to frameworks like Nuxt.js and their static site generation functionality, this can be avoided in a lot of cases. You can even build a blog or a news site with static site generation! Since there's no authentication (you edit the code of your site on your machine, not the content in some database on the internet) there's also a lot less space for attacks. Just be sure to protect the source code and your materials properly.

Static site generation is not some universal magic wand to avoid databases and more complex servers, though. Since no data is stored on servers, AnotherPomodoro is not able to synchronize your settings and tasks across your devices: if your browser does that for you, all the better. There's no way to create leaderboards, either. In fact, sharing any user-generated content (think social media posts, for example) through a static app is without any supporting server is (mostly) impossible, if not tricky. To me, these things were never really important, anyway. I am willing to spend 30 seconds to configure the app and I don't think that Pomodoro apps need leaderboards. I can build a statistics module into the app, though 🙂

The key is to recognize when the features you want in your app actually might not require more than what a static website can provide. It might be tempting to include a login feature just to share data across devices but in some cases that might be overkill. In AnotherPomodoro's case, a quick setup page is being made to set the app up for first use even quicker so users will not need to delve into the settings that much. This also helps avoid having to sync settings across multiple browsers.

The app's source code (along with more technical information) is available at the project's GitHub page.

Hanziness / AnotherPomodoro

Modern and customizable productivity timer app that runs in your browser.

⏳ AnotherPomodoro

Free and open-source Pomodoro application, right in your browser.

What is it?

AnotherPomodoro is a Pomodoro timer application running in the browser. It helps you manage your time so that you can do more work instead of watching videos of cute cats 😿

Quickstart: your schedule

When working with AnotherPomodoro, you'll be moving between three types of sessions:

Work. Do what you have to do.
(Short) Pause. Take a short rest, stand up from your computer and drink some water.
Long pause. Having worked some time now, take a longer break. You can grab a cup of coffee, watch some memes and scroll social media.

With the default Pomodoro settings, every third break will be a long one.

💡 Tip. You can customize the length of the timers and the frequency of long pauses, too!

What you get

Here's the looong list of features…

View on GitHub

Thanks for reading this little snippet of the making of AnotherPomodoro. If you haven't yet, check out the app at https://another-pomodoro.netlify.app!

This blog post was originally shared on my Buy Me a Coffee page.