Minimal kanban-esque tool
Many features of trello, planka, et al can be very useful for many users, but I find them distracting and overwhelming for my basic use cases. As such, I've set out to build an absolutely minimal kanban tool. The list of non-features should help explain my use case
Non-features:
- Multiple users and user management tools
- Labels and other advanced organization tools
- Stopwatches or time management tools
- Cross-device syncing
- Card-level todo lists
While I understand many users might depend on these advanced features, I generally view them as complications. Of these complications, only card-level todos immediately seem to compensate for the weight of their visual and semantic clutter.
Cross-device syncing as well is an obviously useful feature, but it comes with it's own drawbacks. Without cross-device syncing, all data related to a user's projects can simply be persisted in the browser (I'm currently planning on using IndexedDB) and the application can be served as a simple static page. Cross-device syncing requires some method of persisting a user's data outside of their own browser. Furthermore, this requires some concept of authentication, whereas without cross-device syncing the existance of the data on the user's computer is sufficient for authentication. This has the potential of becoming a slippery slope towards adding multi-user support, at which point simplicity is necessarily lost from the application. If cross-device syncing is ever implemented, it will be optional
The project can be built with npm in a standard manner
$ npm i
$ npm run buildOutput will live in a dist/ directory
Alternatively, nix can be used for the build (using flakes)
$ nix buildOutput will live in a dist/ directory within the result/ symlink. After updating npm dependencies, npmDepsHash within flake.nix will need to be updated to reflect the changes. A new hash can be calculated with prefetch-npm-deps, for example: nix run "nixpkgs#prefetch-npm-deps" package-lock.json.
This software must be run in a secure context as ids are generated by crypto.randomUUID(). There are other features which only function in secure contexts (such as persisting data), however these are generally optional.
Mobile support is currently passable, but not great.
The experience of moving cards between lists is clearly more comfortable on a pc as only about one and a half lists fit on the screen at once. This is especially awkward when wanting to move a card several lists over at once. A dropdown to move cards to a specific list could be added to the edit card modal but I find this solution somewhat clunky. Reducing the width of lists for narrow screens might help.
The app expects there to be a substantial amount of room for a project list. This can be an issue for desktop users as well, but only if they have a great number of projects. On mobile, it can be difficult to use the project list with only a few projects. A dropdown style list would likely be more comfortable for mobile.
Dark mode is currently not implemented. Supporting dark mode is somewhat complicated by the use of browser default form styles.
Despite being entirely static, this application makes no attempt to function as a PWA. I personally don't care as I don't really make use of PWAs at all, but if someone would like to use this as a PWA it wouldn't be much effort to support that.
Currently changes in one instance of Trone are not reflected in other open instances of Trone.
For better or worse, Trone uses IndexedDB to persist data. IndexedDB lacks observers (there was a proposal to add them, but it appears to have stalled). Observers would allow us to listen to changes in the db and update our applications live state (currently Redux). Other similar browser technologies, specifically localStorage, do support observers via the window.storage event. LocalStorage has it's own issues of course, but it might make sense to have a single lastUpdated which forces a reload of db storage into application state when changed by another running instance.
One method I've considered for enabling cross-device syncing without users' losing control of their data is something a "Bring Your Own Storage" approach. The idea is that users would be able to (optionally) set up their own data store (e.g. S3 bucket) and enter all of the information for accessing it in Trone. This would likely have the drawback of being a fairly involved process to set up.