![]() ![]() Some knowledge today won't be useful in 5, 10 o 20 years from now. What you think as "knowledge" today will only be data for algorithms in 10 years. Personal opinion : I think this is not the right way to look at knowledge. > Ideally, notes I take on the book I am reading today should still be available to me in 20 years. But most users, even programmers, that I know don’t seem to enjoy this level of exactness. ![]() For notes this is best for me, since note update frequency of one to five times an hour doesn’t need any auto sync. I use multiple iPads and laptops at once, so google drive and Dropbox bugs in sync may bite me. I don’t like placing the security of my synchronization in the hands of cloud files providers such as Dropbox or Google Drive. I prefer manually syncing my files as commits to a repo, so this all works beautifully for me. That’s all understood by the user, if he’s using a git repo as his files backup. Any writes to WC in the meantime will just overwrite. Since Working Copy has no such auto sync as something like Dropbox would have, since WC is a git repo app and not a cloud files service, the user would manually open it themselves and make a commit and push it at their own choosing. With a git repo program like Working Copy, you’d just write into its Files space (same as above for Dropbox), then Working Copy handles the syncing. All you need to is ensure that you write into Files api properly (Ie don’t leave any locks around on files, etc - I’m not an iOS developer so I have no idea what’s actually required for very good/correct Files api interoperation, but it should be in Apple docs). So, supposing Dropbox has a sync with the files api, then that sync would be the responsibility (and implemented by) the Dropbox app. I really like the beauty of the iOS Files api - it acts as a very convenient bridge. It has enough quality of life features to be efficient, but you also don’t end up trying to import every pdf into it - allowing you to focus on making just the key notes. The former was too inefficient to stylize everything by hand without even keyboard shortcuts for bold, underline, etc, and the latter was too heavy handed in its insistence on visual placement for the user. I have given up on both LiquidText and MarginNotes - neither were able to offer me the visual learning I needed. I often ended up doing nested frames, so it wasn’t a big deal, but visually it was still jarring to see the highlight boxes that you’ve made to visually switch up their positioning on you due to the auto arrange. The one issue with Margin Notes is that it refuses to let you manually position the frames. (In comparison to Liquid Text - liquid Text has so few to 0 quality of life features, there was no nuance to figure out, other than knowing what poor quality of life implied for doing the visual styling that you needed to do). I also frequently held down the Apple key to see the shortcuts, and worked off from there. Being the hn type I enjoyed figuring out the nuances through heavy use. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |