The building blocks of offline support
1–10 of 31 posts
Re: The building blocks of offline support
#2This is really impressive and I like the app, it's fast and powerful.
However, I wouldn't consider using it without better undo, if i merge a set of cards by mistake it cannot be undone. Maybe store a larger undo history in IndexedDB?
Re: The building blocks of offline support
#3It conveniently doesn't mention the hardest part: conflicts.
If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
Re: The building blocks of offline support
#4It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
Conflicts themselves are not hard: Keep a directed acyclic graph of immutable records. Changes to a record point to the parent/prior record. Two users update the same record, now you have a tree.
The challenge is interpreting what that tree structure should mean.
If you can, let a user decide how to resolve the conflict.
- User logs in, they have a “conflict inbox” of things that need to be resolved.
- Two coworkers make conflicting edits, maybe the manager gets a notification in their conflict inbox and they decide
Re: The building blocks of offline support
#5It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
Conflicts themselves are not hard: Keep a directed acyclic graph of immutable records. Changes to a record point to the parent/prior record. Two users update the same record, now you have a tree. The challenge is interpreting what that tree structure should mean. If you can, let a user decide how to resolve the conflict. - User logs in, they have a “conflict inbox” of things that need to be resolved. - Two coworkers…
If we want to discuss terminology, I agree I should have said "handling conflicts" instead of just "conflicts".
What you are describing is just the beginning of conflict handling. The consequences for bad handling are dire: data loss. If conflict handling and resolving was easy (hint: it's not), the article would have mentioned it.
Re: The building blocks of offline support
#6That first load time was pretty long, though (like 4 seconds).
Felt as if it checked online or loaded too many things.
Re: The building blocks of offline support
#7Earlier quoted context omitted.
Conflicts themselves are not hard: Keep a directed acyclic graph of immutable records. Changes to a record point to the parent/prior record. Two users update the same record, now you have a tree. The challenge is interpreting what that tree structure should mean. If you can, let a user decide how to resolve the conflict. - User logs in, they have a “conflict inbox” of things that need to be resolved. - Two coworkers…
If we want to discuss terminology, I agree I should have said "handling conflicts" instead of just "conflicts". What you are describing is just the beginning of conflict handling. The consequences for bad handling are dire: data loss. If conflict handling and resolving was easy (hint: it's not), the article would have mentioned it.
Thank you. Do you see the difficulty in implementing the data structure to handle this? Or in the decision about what to do about it? Or about how to automate resolution?
Let’s take git as an example. If we both push changes to our branch, there’s no problem. We have a git repo with different branches. For a single record, this is even simpler, just an append-only table with a foreign key to the prior state.
If someone reviews a PR and finds a merge conflict, it gets handled. Maybe one wins, both get rejected, or both get accepted (a fork). But there’s no requirement that data be discarded.
But automating it seems impossible in all circumstances since it depends on the human intent.
Re: The building blocks of offline support
#8This is really impressive and I like the app, it's fast and powerful. However, I wouldn't consider using it without better undo, if i merge a set of cards by mistake it cannot be undone. Maybe store a larger undo history in IndexedDB?
While there is undo, you're right, it's pretty rough right now. That might be a good way for me to dip my toes into indexedDB
Re: The building blocks of offline support
#9That first load time was pretty long, though (like 4 seconds). Felt as if it checked online or loaded too many things.
that's def not ideal and not normal, loading up the page in incognito takes me less than a second. It does make a lot of requests for assets and to the API but those are mostly async. Can you repro the long load time everytime? Do you still see a long load time for a space url like https://kinopio.club/fonts-6n5memHYV0K1qmeUcX2Fs ? If the issue persists? What browser/OS are you using? Where in the world are you? (the client should be serving over a CDN)
EDIT: in case you were referring to the loading state in the vid in the post, I suspect that's a bug with the iOS loading screen that I didn't have time to fix before this post (it's just idling for most of that). will update later
Re: The building blocks of offline support
#10It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
The scenarios where people are simultaneously editing the same space online and offline are very rare. When both users are online, I use the UI to communicate who's editing what to avoid conflicts. I would like to improve this in the future, but for now it's a utilitarian scope/resource issue