Hello Code Blog

Announcing Foreground 1.0

Ever since we started working on Exist, I've been tracking my productive time on my Windows PC. For the vast majority of this time I was using RescueTime, together with Exist's RescueTime integration, so that I could automatically see my productive and distracting time totals in Exist and correlate that with everything else. RescueTime is a great product that, until recently, had a very generous free plan that perfectly suited how I was using it. But I was always uneasy with the idea that all of the data on what I do on my computer every day—every app I use and URL I visit—was being sent to a third-party. To me, this is much more sensitive data than how much I weigh or how many steps I took in a day. It would be nice if that data never left my computer.

So please welcome Foreground to the Hello Code family of apps that track things!

Foreground is an app to automatically track your time in apps and websites on Windows. It’s efficient, offline, and private, and all your activity data stays on your computer. It lets you categorise and rank all those apps and sites so you can track your productivity over time, see where you spend most of your time, and keep tabs on distractions. It also has a dark theme and browser add-ons for all major browsers. Foreground is written in Rust and uses very little memory and processing power.

Foreground can optionally send productive, distracting, and time gaming totals to Exist. Of course, if you enable this, it's not operating totally offline, but it only sends numeric totals, keeping the rest of your details locally.

I'm also quietly proud of some of the insightful measures I've implemented in Foreground: "focus score" and "activity spread". Because we're tracking which app or website is in the foreground every second (hence the name), we can see how often you switch between windows and tabs, and the average time between switches is your focus score. Mine for today is 25 seconds, which is pretty good for me. I'm often jumping around between writing code and looking at the output, but when I'm writing a blog post, I don't need to switch so much. On a more code-focused day, it's more like 10-15 seconds. The other measure, activity spread, is the number of unique apps and sites you interact with, and here a higher score indicates you're less focused and needing to access a lot of disparate information or tools for whatever task you're doing. Or you're extremely distracted! My activity spread today is 16 apps/hr, which is a bit higher than my average of 12 apps/hr. This is probably because I was doing a lot of disparate tasks earlier in the day, like support emails and updating Exist's knowledge base, where each of those also involved looking up some further information. So from these two numbers I can see I'm more focused on larger chunks of time in the one app, but I've also been spending that time across more apps and sites than I visit normally. I find these numbers a really nice metric of what type of day I'm having, not just how productive I'm being.

Foreground is a perfect fit for my single-PC use case, but I recognise not everyone works this way, and I'm looking into ways to sync data across computers (and those on Linux, and MacOS) without needing to entrust it all to our servers. This isn't an easy problem to solve though, so for now, consider Foreground a purely offline solution. Run it on as many PCs as you like, but the data will be specific to that PC.

Foreground is free to download, and you’ll need to buy a licence to keep using it after the 30-day trial ends. Foreground licences are valid for as many PCs as you like, and Foreground doesn't "call home" to verify your licence, meaning it'll keep working without an internet connection and also in the far future when Hello Code no longer exists.

Please consider supporting our efforts to make privacy-respecting software that doesn't rely on surveillance capitalism, advertising, or other detrimental aspects of late capitalism in order to make money. And hey: no "AI"!

Ultrahuman Ring Air review

For many years, an Oura ring has been my sleep tracking device of choice. I was keen on the ring form factor because it's small, light, and unobtrusive — wearing a watch to bed has never seemed comfortable to me. So when we bought an Oura ring to use for testing an integration for Exist, I was happy to stick with it personally. I didn't care about its activity tracking, but I trusted its sleep tracking well enough. I set my sleep data in Exist to sync from Oura and left my activity data coming from my Samsung watch.

With the ring now being at least four years old, the battery life has declined to the point that it requires a charge every two or three nights, which is often enough to be irritating for me. It finally tipped me over the edge recently to hunt for a replacement sleep tracking device, ideally another ring.

You'd think that a new Oura ring would be an easy choice, but recently Oura has announced that, on top of the AU $456 cost of the hardware (converted from USD on 30/07/24), I would be spending AU $110 each year in order to get access to all sleep metrics beyond a simple "score", the score itself being worthless. I'm not against subscription costs, and I actually think a hundred bucks a year is acceptable for something I use nightly, but I object to another ongoing cost on top of the significant outlay for the ring itself. Subsidise the hardware cost and I'd find it a better proposition.

There are some other competitors in this space. There's something called Circular, which has bad reviews and doesn't appear to export any data to Apple Health or Health Connect, a must for me both personally and ethically; RingConn, another newcomer with pretty iffy reviews; and the Samsung Galaxy Ring, which sounds pretty good in initial reviews but hasn't launched in Australia yet. Ultrahuman's offering is more expensive than the Oura ring up front at AU $532, but crucially, they've promised they won't require a subscription to access all the stats the ring provides. They also sync sleep data to Health Connect and Apple Health. After looking around at the competition and reading some reviews, I decided to buy their Ring Air.

To save you from reading all the way to the end to see my verdict, let me tell you now: I was quite disappointed with the quality of sleep tracking, and asked for a refund. Read on to find out why!

Company background

Ultrahuman are a startup out of Bangalore, India. They were founded in 2019, and initially launched with Series A funding as a paid-subscription app offering content around workouts, meditation, bedtime stories, and "brain music". In the next few years they raised further rounds of funding and in 2022 finally launched their first ring device called the R1. The successor, the Ring Air, launched in mid-2023, making it about a year old now. The company also offer a continuous glucose monitor, or CGM, that is essentially the combination of an existing Freestyle Libre 2 needle and their own app. At CES 2024 they've announced a new home monitoring device that tracks things like air quality and noise levels in order to further give feedback on things affecting your health and sleep. It feels like they're really going for it in attempting to cover all angles. In my experience, though, they need to get the basics right before spreading themselves too thin.

The ring

When you buy the ring, Ultrahuman uses the same process as Oura — you pay up front, they ship you a sizing kit, and once you choose a size they'll send the ring itself. The whole process took just under two weeks for me. The ring looks and feels very nice. I opted for the matte black option, unsure if it would look cheap and tacky, but it delivers. The plain silver Oura always felt light and cheap to me, but somehow the Ultrahuman ring looks and feels more premium. Perhaps the almost $100 more it costs over the Oura is the reason for this.

Like Oura, the ring ships with a charger that matches the size you've chosen. Just like Oura, the charging light on the charger blinks very slowly while charging, a long-standing peeve of mine as it makes it very hard to determine at a glance if it's solid or actually slowly flashing. Unlike Oura, the Ultrahuman charger does not turn off the light when you remove the ring, making it unsuitable to leave plugged in anywhere in your bedroom overnight. But also, like Oura, the app does not reliably tell you when charging is complete, meaning you'll need to remember to go and check it.

I've always had trouble with my phone not connecting to my Oura ring, across multiple phones I've owned, and syncing each morning took forever as I tapped "Retry sync" over and over, or quit and reopened the app. In my experience the Ultrahuman app finds the ring nearly immediately every time, which is a vast improvement.

The app pushes you to charge the ring when it gets below 30%, which worked out to five nights of sleep for me. I'm pretty sure I could have eked out six nights if I didn't mind pushing it to about 15% battery left.

The app experience

When you consider that Ultrahuman launched as a content-only service, the complexity of its app makes more sense. It is a confusing mess. The tabs in the Oura app correspond to different types of data that are tracked by your ring, and it's easy enough to find where things are. The Ultrahuman app, however, has tabs for Home, Metabolism, Zones, Discover, and Profile. The last one does what you'd expect, but of the others, only Home has anything to do with the data coming from the ring. (Really, it should be called "Ring".) Metabolism is a dedicated tab for the CGM, Zones is something to do with sharing data with other users (no thank you), and Discover is full of content I don't need like the aforementioned "brain music". I can understand why things are laid out the way they are, but I don't enjoy it. The majority of the core navigation is irrelevant to me.

When I first connected the ring, the app asked to track my location so that it can help locate the ring in future. The copy mentions that it only keeps my location client-side, but the Android pop-up asking for location permissions notes that according to Ultrahuman's Play Store details, my location is sent to their servers. Which one is it? (I also noted with amusement the copy that says "Your data is 100% secure. We ensure all your data is encrypted." This vague reassurance is no less empty than hearing "your call is important to us" while on hold, and just as much of a lie.)

As I kept using the app, I was dismayed to discover the glut of ads beseeching me to upgrade to "Ultrahuman X", which is an optional paid subscription. The app tells me this is billed yearly at $30, but doesn't include the currency, and I don't trust them that it's AUD. The headline benefit for Ultrahuman X membership seems to be a free sleep mask. Otherwise it's billed like AppleCare — longer warranty, cover for if you damage the ring, and so on. The app really wants you to upgrade and pay for a subscription, which makes me uneasy and undermines the trust I have that they won't charge for access to the ring's data in future.

The next thing I noticed were all the notifications. Personally, I only want to wear the ring at night, but Ultrahuman clearly wants you to wear it all day, and reminds you of this fact by sending multiple "off-body warnings" a day. Not only are these annoying, but they're badly done. On Android generally, all notifications belong to one of many "channels" an app manages, meaning you can turn off the channel entirely to silence a particular category of notifications without blocking any others. In the Ultrahuman app, the channel for "off-body reminders" is called Miscellaneous! I turned it off regardless, so if I'm missing out on other miscellaneous updates, I'll never know. Hilariously, the day after I turned off this channel, I got a new notification warning that I wasn't wearing the ring. It came from a second channel! I've since turned this one off too. Best practice here would be to send all these notifications from a new "Off-body reminders" channel and make sure all other types of notifications come from other channels.

Sleep data

For the first week I wore both my Oura and the Ultrahuman Ring Air, so that I could compare the data. When making notes for this review I've been wondering, how do I personally know what is accurate sleep tracking? If the two devices disagree, which one is correct, and how can I accuse them of inaccuracy with any certainty given I'm not awake to measure things myself? The short answer is that I just don't know. However, I do have some small qualitative factors available to me, like how tired I am and how restful the sleep felt; more concretely, I can use my knowledge of times I woke in the night or when I was definitely still awake before sleeping to assess whether the devices tracked these accurately.

And here's where it all falls down. Every night, while reading in bed before sleeping, the Ultrahuman ring would decide that I was already asleep. With this single flaw, all of my trust in Ultrahuman's tracking is undone. If it thinks I'm asleep when I know for sure that I'm awake, how can I believe anything else it says about my sleep? (Oura does not have this problem.)

Edited 27 Sept 2024: Ultrahuman have fixed the issue with tracking time lying awake as asleep. Phew!

In the screenshots above, I've manually edited my sleep record to begin when I actually first slept.

Separate to this, in comparing the data from Oura and Ultrahuman, I found that they largely agree on my heart rate and HRV, in terms of the shape of the graph and what time my heart rate hit its lowest, but Oura often says my heart rate is lower and HRV higher, making my sleep look better. Their tracking of sleep stages matches somewhat, mostly agreeing about deep sleep but disagreeing more often about when I was in REM or light sleep. Oura's awakenings are usually longer and more frequent than Ultrahuman's — on a good night, Oura thinks I wake maybe 2-4 times a night, with an awakening being up to an hour at the outside, where Ultrahuman thinks I woke maybe once or twice in the night and only ever briefly. When I sleep exceptionally badly, the Ultrahuman data does reflect this, but it still overestimates the amount of sleep I got compared to Oura. I've noticed before that Oura sometimes doesn't track awakenings late in my sleep when I know I was awake, because I looked at my phone; Ultrahuman definitely does even worse in this regard, missing all such awakenings so far. So here, I'm forced to conclude that the sleep data provided by Ultrahuman is just Not Very Good. Oura may not be entirely accurate, but I have solid proof that Ultrahuman's accuracy is worse.

Edited 27 Sept 2024: Ultrahuman have fixed the issue with tracking time lying awake as asleep. Sleep is still consistently longer when compared to Oura, but not quite as obviously inaccurate.

Another thing I miss is Oura's breathing rate tracking. Again, I can't know how accurate it is, but I know that broadly, higher values (in breaths per minute) correspond with a less restful sleep for me and, combined with skin temp, can often indicate when I'm getting sick. Ultrahuman promised to add this measure "soon" in an article in 2023, but hasn't yet.

An extra datapoint against the newcomers is that the ring regularly tracks up to 200 steps for me when I'm asleep and, I promise, never left my bed. I thought it was weird that the app told me it wouldn't show my activity tracking until it hit 500 steps for the day; I now suspect this is to hide the fact that you can wake up with several hundred steps already on the clock.

Finally, I want to use this data in Exist, so accurate exporting to Health Connect is critical for me. The app syncs promptly every morning, which is great, but also has a bug where each day it syncs one or more duplicate records with an extra ten minutes duration. For now, I have to manually go into Health Connect and delete these; when I contacted support to make a bug report, they told me they'd pass it on to the developers and then closed my ticket. Perhaps it will be resolved in time, but it hasn't been yet.

Updates and "Plugs"

On the other hand, Ultrahuman are iterating quickly. In the month since I've had the ring, I've had two firmware updates and multiple app updates. Ultrahuman seems to be following a classic startup approach of shipping early, before things are complete, and then iterating often to refine the product. It's entirely possible that they'll be able to fix their sleep tracking algorithms and provide something that seems more accurate. So far, one of the app updates included a new "sleep cycles" visualisation to show how many full sleep cycles I managed, so it was nice to see new user-facing features appearing even in the short time I've had the app. If I could trust this data, I'd find it useful.

As part of those app updates, Ultrahuman have also launched something they call "PowerPlugs" and sometimes just "Plugs". These appear to be integrations and add-ons, with support for third-party offerings. The built-in "stimulant tracking" feature that tells you the time of day to take or avoid stimulants like caffeine has become a free Plug, and there are several more like Atrial Fibrillation (irregular heart rhythm) tracking that already come with a hefty AUD 7.90/month price tag. Apparently menstrual tracking will be available as a free plug.

I can see that with Plugs and their other devices, Ultrahuman is looking to build a platform for tracking activity and body measures. It may be a good sign that they're looking to make more money from optional add-ons, but it further undermined my trust that they wouldn't at some point charge a subscription fee for access to the core data I'm using.

The verdict

The vague bad feeling I have about the company's monetisation plans, on top of the glaring inaccuracies in the data, made me realise I had made the wrong choice in buying an Ultrahuman Ring. I'm also kind of annoyed at the reviews that made vague claims about accurate sleep tracking when all you have to do is lie still and awake to prove that untrue. Fortunately, Ultrahuman offer a 30-day return period (although you have to search their help docs to find this information). Support is conducted via an in-app chat, and when I asked to return the ring, it only took an hour or so to get a response, which was a pleasant surprise. But in what made me feel like I'd made the right choice, the support person put the hard word on me to change my mind with vague promises of future fixes, and asked me to confirm if I really really wanted to return the ring. However, when I said that I did, they offered me a refund without returning the ring, in the hopes that I would find it valuable at some point in the future. So I have kept the ring.

I appreciate that opportunity to keep evaluating it, and I do truly hope that they keep working on it to the point where it provides data that's accurate and trustworthy. For now, I will keep charging my Oura every two or three days, and checking in on Ultrahuman's progress every so often. Maybe later I'll buy a Galaxy Ring.

Exist annual survey 2023

It's the start of a new year, so it's time to summarise the results of our annual user survey for Exist.

Top ways to find Exist include search, related services, and Reddit. 24% of survey responders found Exist through searching for something like it, 13% from a related service like RescueTime or Todoist, and 11% from Reddit. Articles and blog posts also accounted for 11%.

User numbers were stable across platforms. 44% of survey responders use Exist for Android, 46% use Exist for iOS, and 6% use both—almost exactly the same numbers as last year. Just 9 people said they don't use any of our mobile apps.

Reasons for using Exist were also stable, with 56% choosing "Seeking insights to understand or change my behaviour" and 30% choosing "Keeping all my data in one place". These numbers are very close to last year's survey.

The most popular use for manual tracking and custom tags was tracking emotions, mental health, or social interactions on 63%. 57% of respondents use these features to track "data relating to illness, symptoms, medications, or physical health", and 48% track "data relating to work, productivity, or other output (e.g. hobbies)". Less popular ways to use manual tracking included food and diet data on 33%, activity and exercise data on 29%, and sleep data on 22%.

The biggest problem respondents have with Exist is wanting more data analysis. 35% of people chose this option, which is very similar to last year.

23% of people chose "Too much effort to track tags, mood, or manual attributes, or trouble remembering to do so", which is up from 15% last year. In previous years, this option (sans manual tracking) came in at 21% and 25%, so either last year was an anomaly or something's changed recently to make this option grow again.

"Not enough integrations that I personally use" dropped from 19% last year to 16% this year, and "Nothing! All is fine" went from 17% to 14%. The free-form answers to this question mostly related to data analysis, as well.

If we could only focus on one thing for the next year, 37% of users would choose longer-term data analysis. "More features for custom tags" (such as sub-groups and merging tags) came in second with 20%, "More ways to view data in mobile apps" had 14%, and 13% chose "More personalisation" (such as choosing what's on your dashboard and setting your own goals). This question didn't feature on last year's survey.

The user survey helps us get direct feedback from our users about what's working well and where we can improve Exist. This year's survey had few surprises, with a lot of the results stable across the past couple of surveys. We confirmed that we should focus on going deeper on analysing the data we have, and finding new ways to display your data and surface trends and insights.

We also want to focus on improving the usability of Exist over the next year, making it easier to find what you're looking for and to understand how Exist works.

Thanks to everyone who took the time to fill out the survey this year! We also got lots of useful feedback in the free-form notes section, as always.

And thanks to all our Exist users for supporting us for another year.

Tracking the current active process in Windows with Rust

If you want to write a program that tracks your activity on Windows, like I'm doing with Foreground, the core of that tracking is finding out which process owns the currently active window. Only one window is the active window at any one time, and Windows provides an API function to tell us which one that is.

Fortunately, Microsoft also publishes official Rust bindings for Windows with the windows crate. So we can call any Windows API from Rust and import all the necessary data types we need. This means we have everything we need to get the job done in Rust.

First we'll need some dependencies in our Cargo.toml:

[dependencies]
sysinfo = "^0"
tokio = { version = "^1.19", features = ["rt", "time"] }

[dependencies.windows]
version = "^0.51"
features = [    
    "Win32_Foundation",
    "Win32_Security",
    "Win32_System_Threading",
    "Win32_System_SystemInformation",
    "Win32_UI_WindowsAndMessaging",
    "Win32_UI_Input_KeyboardAndMouse",
]

The sysinfo crate provides a convenient wrapper around getting all the running processes, so I'm choosing to use this too, instead of writing my own wrapper around the windows crate's native calls. Thanks sysinfo! We need tokio as we're using it to run our background loop for continual tracking.

Now that we have the dependencies we need, let's write our wrappers around the windows crate calls. All of the relevant functions are marked as unsafe, so we need to call them inside an unsafe block too.

First let's get the active window. I'll put this in windows.rs.

use windows::{
    Win32::UI::WindowsAndMessaging::{
        GetForegroundWindow, GetWindowTextW, GetWindowThreadProcessId,
    },
};

pub fn get_active_window() -> (u32, String) {
    unsafe {
        let hwnd = GetForegroundWindow();

        let mut pid: u32 = 0;
        GetWindowThreadProcessId(hwnd, Some(&mut pid));
        
        let mut bytes: [u16; 500] = [0; 500];
        let len = GetWindowTextW(hwnd, &mut bytes);
        let title = String::from_utf16_lossy(&bytes[..len as usize]);
        
        (pid, title)
    }
}

We get the handle to our window with GetForegroundWindow() (hey, that's the name of our app) but then we want to exchange that handle for a process ID (PID) with GetWindowThreadProcessId. A window handle isn't really useful here, but that PID will come in handy later. Finally we get the window title with GetWindowTextW, which gives us some icky UTF16 bytes. We can convert them to a String type and voila, we have the active process's ID and the title of the window! We don't strictly need the window title, but I'll show you how we'll use it later.

That's one piece of the puzzle, but we want to know the process name as well. We needed that PID to look up the process, so now that we have it, let's proceed to use it to get the process name.

Here's our function to get the running process. This time we'll work in main.rs.

use crate::windows;
use sysinfo::{Pid, PidExt, ProcessExt, System, SystemExt};

pub fn get_process() {
    
    let mut sys = System::new_all();
    
    let (window_pid, window_title) = windows::get_active_window();

    if window_pid == 0 {
        // idle process
        return;
    }

    let process = sys.processes().get(&Pid::from_u32(window_pid));

    if let Some(process) = process {
        let name = format_name(window_title.as_str(), process.name());
        
        // here you'd do the work to store the name, timestamp, and so on
    }
}

We create a new System object from our sysinfo crate, and this contains all the current process data, among other things. Then we use our get_active_window function to get us the active window's PID. 0 means the system idle process, which is what's returned if there's a screensaver, the screen is off, or you're sitting on the login screen — when the computer is idle. We don't want to track that.

Next sys.processes() gives us a hashmap of Process objects with PIDs as keys. From that process we can get the process.name() for our PID, and you'll see here I'm doing some further formatting to decide what name I want to call the process. Let's have a look at format_name.

fn format_name<'a>(
    window_name: &'a str,
    process_name: &'a str,
) -> &'a str {

    if process_name.eq("ApplicationFrameHost.exe") {
        return window_name;
    }

    process_name
}

This is pretty simple, and we're just using it to account for one thing — UWP (Universal Windows Platform) apps. These are written using .NET and don't run their own process, but are managed by ApplicationFrameHost. So if the process name matches this, we use the window title instead, as this is more accurate. Easy!

So, to recap, we've started with asking Windows for the active window's PID and title and we've used that to look up the details of a running process, getting its name. Now when we call get_process(), we'll get the name of whatever is in the foreground — notepad.exe, for example, or Calculator rather than calc.exe, because it's a UWP app.

The final piece of the puzzle is to run this in a loop so that we can constantly track the active window. However, we want to pause tracking if the user stops input. We don't want to track activity if the screen is on but nobody's there, which is a fair description of me when I am very tired.

Back in our windows.rs file we add a function to get the time since last input.

use std::time::Duration;
use windows::{
    Win32::System::SystemInformation::GetTickCount,
    Win32::UI::Input::KeyboardAndMouse::{GetLastInputInfo, LASTINPUTINFO},
};

pub fn get_last_input() -> Duration {
    let tick_count = unsafe { GetTickCount() };
    let mut last_input_info = LASTINPUTINFO {
        cbSize: 8, // Probably only true for 64 bit systems?
        dwTime: 0,
    };

    let p_last_input_info = &mut last_input_info as *mut LASTINPUTINFO;

    let _success = unsafe { GetLastInputInfo(p_last_input_info) };
    let diff = tick_count - last_input_info.dwTime;
    return Duration::from_millis(diff.into());
}

I'm sure I found this code somewhere online, probably in a Stack Overflow answer, because the arcane incantations to summon a valid LASTINPUTINFO don't mean anything to me. Thank you, mysterious code provider. But the gist here is that we ask Windows for the "tick count", which is how long the computer has been running in milliseconds, and then we ask Windows for info on the last input. Our dwTime represents the last time there was input as an incrementing millisecond count too, so we can get the difference to find the duration in milliseconds since last input.

Okay! Now our loop can check and take into account the last input time, so that we stop tracking when the computer is idle.

Back in main.rs it will look something like this.

use std::time::Duration;
use tokio::time;
use crate::windows;

const IDLE_CHECK_SECS: i32 = 5;
const IDLE_PERIOD: u64 = 30;

pub async fn track_processes() {
    let mut interval = time::interval(Duration::from_secs(1));

    let mut i = 0;
    let mut idle = false;

    loop {
        i = i + 1;
        interval.tick().await;

        if i == IDLE_CHECK_SECS {
            // we check that the last time the user made any input
            // was shorter ago than our idle period.
            // if it wasn't, we pause tracking
            let duration = windows::get_last_input().as_secs();
            if IDLE_PERIOD > 0 && duration > IDLE_PERIOD {
                idle = true;
            } else {
                idle = false;
            }
            i = 0;
        }

        if !idle {
            get_process().await;
        }
    }
}

We use Tokio's interval function to make sure that our loop waits one second each time through. From there, we have two periods we care about for the idle checking in the loop. We don't want to check every single second if the computer is idle, because that's wasteful, but the less often we check, the longer we keep tracking erroneously when we should have switched our state to idle. So here we use an IDLE_CHECK_SECS of five seconds as a compromise.

The second period is how long to allow a lack of input before deciding the computer is idle. Too short, and the user can't have any time tracked while they're sitting and staring at the screen. Too long, and we'll keep tracking long after the user has walked away to make a coffee. So our compromise IDLE_PERIOD is thirty seconds.

Putting together these two periods, we run our loop every second, call get_last_input every five seconds to get a duration that has passed since last input, and check if that period is greater than our idle period of thirty seconds. If it is, we stop tracking. If not, the computer is still active, so we track the active process.

And that's the whole process complete! Get the active window, find the process that owns it, and do all of that in a loop as long as the user or the computer isn't idle. We need only to tokio::spawn a task to run track_processes() forever, and we'll keep on trackin'.

I've been very happy with the decision to write this in Rust, using Tauri for the interface. All of this code comes from Foreground, our fully local and private activity tracker for Windows.

Working in public

We've been working in public ever since we started building Exist. We've blogged about what we're working on and our long-term goals, published a podcast about the process of development, run yearly user feedback surveys, and since 2016 we've been publishing our user subscription numbers and income every single week. Right from the start we had a public roadmap, too, where users could see what we were working on, discuss proposed features, and vote for what they wanted to see come next.

We feel that working in public is a kind of superpower. It keeps us accountable to users and that in turn fosters trust. Our community can engage with us directly, see at any point what we're working on and what's planned, and have a very real impact on our priorities. Rather than trying to hide behind the facade of a Brand™, politely corporate and never personal, writing "bug fixes and improvements" in all the release notes, always passing on your feedback to the relevant team but somehow never acting upon it... we've always been open about being just a couple of humans who are making things. There is no curtain for us to implore you not to look behind, there's just us.

Ultimately, we feel that's a better deal for everyone. It makes for a better product, because users can have trust in us, feel heard, and get what they actually want. And we can work in a way that's in line with our values.

When we first made a public roadmap for Exist, we used Trello (which was the style at the time). It was never a very good fit for something we wanted our users to engage with, and as soon as I had time to spare, I started building us an alternative.

At the start of 2016 we migrated to Changemap, our new, proudly custom-built tool for public roadmaps! Changemap gave us a way of presenting at a glance our flow of work from suggestion through to completion, what was most popular with everyone, what we planned and what was in progress, and let us update our users as their suggestions moved through the process. And we've been using it ever since, with over 16,000 votes and comments made by our users for Exist, and roadmaps for our other products too. (We even have one for Changemap itself.) It's been invaluable.

Then a few years ago we opened up Changemap to public beta. During the beta we've seen other successful teams use Changemap with their communities too, like the symptom tracker Bearable and financial planner and simulator ProjectionLab. I feel proud to see something we built for ourselves become a part of the workflow of others who are making such cool things.

Now, finally, we've launched Changemap officially. Now anyone can use Changemap with their own communities, to work in public and engage their users, in the same way that has been so successful for us and integral to the transparency we care about. I'm happy that in some small way we'll be able to help encourage that, and maybe even make it a little easier to do well.

Existing monthly, January 2023

Exist

This month we finished up 2022-related tasks like writing up the findings from our user feedback survey, and started planning our work for the year to come.

Completed this month

Published a blog post summarising the results of our 2022 user feedback survey
2022 yearly report was sent out to everyone with enough data (you should have seen an email from us and a notification in Exist with a link to your report)

Numbers for this month

1,721 active users
1,290 paid users
379 new signups
$11,487 MRR

As always, you can check our stats anytime on our live stats page.

Exist annual survey 2022

At the end of 2022 we sent out our first user feedback survey since 2019. Since our last survey we'd released manual tracking, which was one of the biggest changes to Exist since we launched around 8 years ago. Manual tracking lets you enter data directly into Exist that you can't sync from other sources, and even define your own attributes.

As well as helping us get feedback on manual tracking and other changes we've made to Exist recently, the survey helped us understand which parts of Exist are most useful, and which aren't being used much.

Here's what we found.

The main ways people find out about Exist are articles/blog posts (22%), related services like RescueTime or Todoist (18%), and social media (9%). We had lots of people mention Reddit specifically, rather than counting this as social media, so we may need to add this as an answer in next year's survey. We also had lots of people say they found Exist by directly searching for something like it.

The split between iOS and Android usage has evened up further. In 2019 we had 44% of respondents using our Android app and 51% on iOS. This year we had 46% on iOS, 45% on Android, and 6% on both. Just 3% of respondents don't use our mobile apps at all.

Over half our respondents chose "seeking insights to understand or change my behaviour" as the main reason they use Exist. 54% of people chose this option, which is down from 57% in 2019, but exactly the same as 2018's survey, so this is a consistent winner. "Keeping all my data in one place" was the second choice, at 29%, up from 19% in 2019. Third was "Managing mental health, chronic illness, or other medical symptoms" on 13%. We're happy to see this third option in the mix, as we hoped manual tracking would make Exist more useful for managing chronic illness and other health-related data.

The most popular new feature since our last survey was manual tracking. 79% of respondents said they found manual tracking useful, which confirms our prediction that manual tracking would be a big winner. 51% of respondents liked that we increased the mood rating scale from 1-5 to 1-9, and 43% appreciated the update that lets you deactivate custom tags to hide them without deleting their data.

Other popular updates included support for heart rate variability (38%), longer mood notes (31%), and the new Trends tab content in Exist for iOS (28%). The least popular options were "None of these are useful to me", chosen by 4% of respondents (phew!), and emoji and non-English character support in mood notes and tags, on 12% and 11%, respectively.

68% of respondents use the Trends tab in our mobile apps, and 59% use Trends on the web. One of our big updates after our last survey was to improve the Trends tab in Exist for iOS, which was lagging behind Android and the web. It's nice to see the extra data on that tab is proving useful.

61% of respondents use the rating feature on correlations, 57% use the Week and Month dashboards on the web, and 52% read the weekly email report. We were surprised how many people use the web app, but happy to see these numbers! We also found only 30% use the Optimise page on the web, which we suspected wasn't very popular. I'd like to make this page more useful in future, but also help users discover it more easily.

64% of respondents track mood in Exist daily or almost daily. In 2019 46% of respondents rated their mood daily. Since we included "almost daily" this year, it's hard to tell if this number has increased or not. 48% of people this year said they often write a note when rating their mood, and 43% found the "Looking back" feature useful—where our mobile apps show your mood rating and note from this day a year ago.

73% of respondents track tags daily or almost daily. In 2019 we asked if users had turned on the custom tags feature, which 91% of people had, but we didn't ask how often they were using it. 73% is quite high, though, and confirms that custom data continues to be important to Exist users.

51% of respondents track tags just once per day, while 16% update tags many times throughout the day. 25% use the web app to track their tags sometimes, which is higher than we expected. 20% of respondents said they organise their tags using prefixes or naming patterns to group them together, which is something we want to make easier in future. And 34% said they find it easy to rename, delete, and otherwise manage their tags. I think we can improve how easy it is to do these things in future, as well as making it easier for users to find these features.

47% of respondents enter manual data daily or almost daily, while 19% enter manual data "often or sometimes". 35% of people have replaced some of their custom tags with manual tracking.

Since manual tracking is new this year, we asked about the types of data our users are tracking. 35% are tracking illness, symptoms, or other data about physical health. 34% are tracking data related to emotions, mental health, or social interactions. 30% are tracking data related to work, productivity, or hobbies. 25% for food and diet data. And the lowest categories were exercise on 15% and sleep on 12%.

24% of respondents are using manual tracking to duplicate content from other apps or services, which means if we could integrate with those apps or services, manual tracking wouldn't be needed. Unfortunately so many apps for tracking personal data keep user data locked up in the app, and don't provide a way for us to sync that data into Exist. This answer was in the minority, though, which we expected because most manually-tracked data is the kind of data that isn't able to be tracked elsewhere. 23% of respondents chose "None of these" when asked about how they're using manual tracking.

61% of respondents said Exist has helped them make a new discovery about themselves/their behaviour. This is a really exciting stat! Of course, it's only a small percentage of our users that choose to complete the survey, but it's still really validating to see that so many users have discovered something new in their data with the help of Exist. 53% said Exist had helped them confirm a hunch about their data, and 27% said Exist helped them make a lasting change in their lives, which is perhaps the most satisfying thing any user could tell us.

30% of respondents have used the option to export their data from Exist, and 15% have shared data from Exist with someone else like a family member or doctor.

67% of respondents have visited our public roadmap, and 53% have voted for or commented on a suggestion there. 18% have used the API, and 37% visit our user forum often or sometimes.

The biggest problem respondents have with Exist right now is wanting more data analysis and insights into their data. This is what we expected, which is great—it means we have the right ideas about what our users want and where we should focus our time next (more on that below).

The next biggest problems with Exist were "Not enough integrations that I personally use" on 19% and "Nothing! All is fine" on 17%. It's nice to have the third-most popular choice be that nothing is wrong! That's a really great outcome for us to see, after 8+ years of working on Exist. Our to-do lists are never-ending, and we're always coming up with more ideas to improve Exist, but it's really satisfying to know we're in a really good place with what we've built so far.

"Too much effort to track tags, mood, or manual attributes, or trouble remembering to do so" was fourth, on 15%. In 2019 this option (minus manual tracking) was at 21%, and 25% back in 2018. Based on those past surveys we spent a lot of time and effort improving the process of tracking this type of data in Exist, to make it easier and faster. There's always room for improvement, but it's nice to see our efforts paying off.

"Not enough integrations I use" was 20% in 2019, so that option has remained fairly stable. As we said in our wrap-up of the 2019 survey, this option will probably be an issue for some users as long as Exist is alive, as there are always new apps and services being released to help you track personal data, but so few of them offer APIs for users to access their own data and for us to sync that data into Exist. And of course, we only have so much time, so we have to balance working on new integrations with improving Exist's current features, and finding new ways to help you explore and learn from your data. We'll continue adding new integrations, but now that we're somewhat into the "long tail", each one doesn't deliver as much of an impact, so they're not our main focus.

This question included an option to add a freeform text answer instead, and most of these were related to wanting more data analysis, or different ways to explore and interact with your data inside Exist.

57% of respondents would recommend Exist to certain people, while 28% would recommend it to most people. 14% would recommend it to everyone. This is fair, even we don't recommend it to everyone. But it's great that so many of our users feel comfortable recommending it to some people.

As always, we included a freeform text box at the end of the survey, so users can share any feedback, ideas, or questions that weren't covered in the survey questions. We got a lot of really nice responses and encouragement, which was a great way to end 2022. Thank you to everyone who left us a nice message!

The rest of the text-based responses were mostly focused on variations of "I want more data analysis", which fits with the trends that came out of the earlier survey questions.

What's next?

We like to use the survey to get a feel for where we need to improve, what's working well, and what's missing in Exist. After so many years of doing this, we already have a pretty good idea of what we want to focus on next, but the survey responses are a good way to check that we're heading in the right direction.

For 2023, our plan is to reimagine how we can use all the data we already have. There's still so much opportunity to improve our analysis, to make insights and correlations more useful, and to find better ways to bring this data to you, so you can easily discover things you didn't know. We think this means adjusting the design of Exist to focus more on insights and trends in your data over time, rather than putting today's numbers front-and-centre. We want to do better at answering questions like: How am I going recently? How does my behaviour compare to last month, six months ago, and last year? What's changed, what's out of the ordinary, and what does it mean?

We always have lots of adjustments in mind to improve the experience of using Exist, as well, and we'll continue to work on those throughout the year.

Thanks to everyone who completed the survey! We really appreciate the time you took to share your experience with us so we can keep improving Exist.

And thank you to everyone who uses Exist, whether you filled out the survey or not. It's still amazing to us that after so many years we're able to spend our time building something we love making, and have it make a difference in the lives of others.

Happy 2023!

Existing monthly, December 2022

We started holidays the week before Christmas, so it was a short month as we wrapped up loose ends before taking a break.

Exist

Completed this month

Finished and released the user feedback survey for this year. It's now closed, and I'll have a write-up of the results on the blog soon. Thanks to everyone who participated!

Numbers for this month

1,701 active users
1,275 paid users
265 new signups
$11,762 MRR

Up next

The update to our weather integration to use Apple's weather data instead of Dark Sky is pretty much done, so that will be finished off and released early this year
We have a lot we want to get done this year, but we're not quite finished with our holiday break yet. Our first tasks when we return will be to analyse and write up the user survey results, and plan out our priorities for the year ahead

As always, you can check our stats anytime on our live stats page.

Existing monthly, November 2022

A quiet month, but progress continues!

Exist

Completed this month

Nothing this month, unfortunately. We have a couple of things almost finished, but didn't manage to get them done before the month ended.

Numbers for this month

1,644 active users
1,295 paid users
341 new signups
$12,108 MRR

Up next

I'm almost done with our transition from Dark Sky to WeatherKit, so I'll try to wrap that up this month
I'm also working on this year's user feedback survey, so I'll try to get that finished before the year is over, too

Changemap

Changemap is a roadmap and user suggestion tool for teams working in public. We use it for Exist, and have been working towards a public launch for a while (it's in beta right now).

Completed this month

Josh continued working on the public API for Changemap, and outstanding work to get it ready for opening up to paid users

Up next

More of the same this month!

As always, you can check our stats anytime on our live stats page.

Existing monthly, October 2022

It's been a long time since we wrote one of these monthly wrap-up posts! We decided the time required to compile the stats and write the blog post each month could be better spent elsewhere. However, I want to try a simpler approach that'll be quicker to write but still provide some transparency into what we're up to each month. Here goes!

Exist

Completed this month

Update GitHub repo for our developer docs
HRV from Fitbit
Since we've been away so long, a couple of notable updates from September were the release of manual tracking features on the web and support for new sleep types from Apple Health

Bug fixes

This month I tried listing all major bug fixes on our public roadmap, but we agreed this clutters up the roadmap too much and is unnecessary. I may not bother listing them at all in future, but for now I'll list them here and worry about whether that's worthwhile later.

Up next

I have an Exist for iOS update on the way to the App Store with some bug fixes and improvements to syncing for some Apple Health data. I've started the process of swapping our Dark Sky integration for Apple's WeatherKit, so I'll continue with that this month.

Changemap

Changemap is a roadmap and user suggestion tool for teams working in public. We use it for Exist, and have been working towards a public launch for a while (it's in beta right now).

Completed this month

Up next

Josh is working on the public API for Changemap right now, as well as working through the requirements for opening up Changemap to public (paid) signups.

Numbers

Exist

1,669 active users
1,303 paid users
237 new signups
$12,993 MRR

Larder

4,298 accounts including trial or lapsed
64 paying users
21 new signups
$210 MRR

As always, you can check our stats anytime on our live stats page.