[luke-stanley]

A hierarchical progress bar service is a cool idea in principle, for some tasks state is worth decoupling from process memory. I do note that the homepage example changes colour without real hierarchy shown though! Something worth noting, is that the hierarchy of an important task of some kind might not be known at the start. It's interesting to consider how to have a great developer UX for managing this. I'd probably want MCP support (or a boring OpenAPI). If someone can show in a few lines how a developer can have a messy process get meaningful hierarchy and progress added to it and it's child nodes, without being overly rigid or SaaS externality concerns, that would be really cool, it could perhaps help give feedback on some very intractable problems. People often don't realise that showing useful progress can easily be a really hard distributed systems problem that a lot of real life systems are bottlenecked by. It's interesting that LLMs might actually be able to help ask questions about progress to help better represent what progress should be shown as, asking about subproblems, helping guide the state with structured decision making etc.

[clav88]

Interesting! I agree that nested / hierarchical progress is not straightforward. Even if all child problems are known, the weighting between their individual progress to compute the overall, aggregated parent progress is not easy to determine as it depends on the relative complexity of the child tasks. Perhaps an LLM could help here, but it would have to know the detailed scope of each task it is tracking. Alternatively, pbar could allow users to set their own weights for each sub-bar, so they could integrate their own logic or an LLM to do that. I didn’t want this to become complex in any way though. I therefore opted to do the same as tqdm. A parent progress bar simply counts how many of its children bars are fully completed. It will show 90% progress if 9 out of 10 child tasks are done, even if the last task takes much longer than the others. You can try it e.g. by making nested loops using the tqdm wrapper.

[luke-stanley]

You've got a great start, I agree that your swap-in interface for tqdm is very important for migration, and so you solved at the right level first, and you've found an interesting problem / solution area with beautiful execution.

I can totally see a "social layer for progress bars" and "Deep Research for progress bars" as valuable things to do on top of it. Like how decision markets and search fit in. Where is reputation and trust? Is metadata encryption needed?

There are developer UX improvements possible of course, as with most things. How exactly parent and child relationships and completions are best represented for an intuitive UX is an interesting circle to square while keeping a simple tqdm API.

I'd love it if this was open-source or zero-knowledge, though that may be a bit of a loaded term when actually wanting client side title / description metadata encryption. I guess you'd want a client doing simple but robust encryption on the metadata, but probably not progress values (or at least not at first, for sanity).

Any plans for a MCP API? It's pretty easy these days.

[clav88]

No plans at this point, but I'm planning to open source it soon, so you can add the MCP API if you like and start building the "social layer for progress bars" ;)

[luke-stanley]

Like what about key life events?