![]() Your notes would still remain intact and can be retrieved again w/o loss. E.g., you could transfer your notes somewhere where there’s no file path info, like a database, a single text file, or an app that stores files internally using its own naming scheme. All relevant info always travels with the note. This way, you can do lots of things with your notes but don’t loose anything. I.e., the note’s body text (or its metadata) should contain all relevant information (like its tags, creation date, linking & citation info, related file info, and of course the Zettel ID). Notes are self-contained: Notes should be as self-contained as possible. This allows you to tag to the bullet point level, and it enables you to freely filter, rearrange and reuse them. The plaintext notes also give you a good data exit strategy. Notes are plaintext: This ensures maximum longevity, avoids lock-in, and allows for easy integration with other apps. So my app gets them out of the PDF immediately, and you then interact with the resulting plaintext notes. This is just a short summary:įree annotations from the PDF & work with them: As mentioned, annotations get only useful when they are extracted from the PDF. I will have to write a longer post to go into more detail. And I could draw from my own experience during my time in academics.Īs a result, I’ve come up with a list of principles that I consider crucial. Before getting started with my app, I’ve talked to many researchers, and read many posts where researchers described their own workflows. I actually tried to build my app around a typical research workflow. I still wish that the apps within this space (or a new one – such as seemingly being designed by would give some thought to who would most frequently use their app, and what their workflows would entail/require. ![]() I cannot but help thinking that If the market is already rich with PDF annotators that seemingly cover the ‘general’ approach, and do it well – then, in the absence of changing the emphasis, why would another one bring anything different? ![]() I acknowledge that it is almost impossible to please everyone – but then, that’s what the they all(?) end up doing – targeting the middle of the road, and not catering for use-cases… Which is possibly another reason why so many look/function the same… So, whilst it remains a mere link in the chain, I still wish that the apps within this space (or a new one – such as seemingly being designed by would give some thought to who would most frequently use their app, and what their workflows would entail/require. I still feel that most of them are too similar, simply since their point of departure is focusing on the PDF, rather than the process. I don’t disagree with that in the slightest – but at times, when spending several days reviewing PDFs, one can (depending on the task/environment/context) spend many continuous hours inside the PDF annotation process – and it is here that my comments were directed at. ![]()
0 Comments
Leave a Reply. |