I would like to see URLs stored and used in a more nuanced manner. Three use cases:
I like to store the library catalogue permalink, especially for items that exist only in physical form. With this I can quickly find the item in Paperpile in which I am interested and with a single click got to the correct page in the library catalogue and find out if it is currently available and where it is on the shelves.
-> However, I do not want this to be included in my reference list or for its presence to generate [Online] through my citation style.
Quite a lot of items that I use are available online but only if one has appropriate permissions / organisational association. I want to store this direct link and to be able to use it through a single click in Paperpile. However, the inclusion of this URL in papers is conditional.
-> With internal papers I want to include the link as the audience will have the same access rights.
-> When publishing externally this cannot be assumed so it should not be included.
If I store a local copy of an item - e.g. on Google Drive, Dropbox, OneDrive - I want to have the URL in Paperpile and to be able to click on it.
-> However, I do not want this URL to be included in reference lists or its presence to generate [Online] through my citation style as I will not have permission for it to be made widely available.
I don’t think it is possible to do any of these now, but if it is, I would appreciate hearing how.
Is it possible to develop appropriate functionality in future releases? Anyone else have similar requirements?
I’m afraid, we don’t have any plans to distinguish URLs. All URLs you add already can be clicked in Paperpile like permalinks you mention in (1) or also Google Drive links you mention in (3) which are shown by default for each attached file.
(2) seems impossible without adding lots of complexity to what’s just a list of URLs at the moment. We will not do that.
(1) Sometimes you need to store more than one URL.
(2) Sometimes the URL wouldn’t be appropriate for a reference list (e.g. I have proxy information for my campus library in it; or no one has rights to an internal report)
You already can store multiple URLs, only the first one will be used in the reference list. So if you happen to have 2 URLs one of them public and one of them “private” just put the private one second and things should work as expected.
I’ve discovered a workaround which meets some of my needs but I’m not sure how safe it is in terms of Paperpile’s future development.
Press return on the first line in the ‘URLs’ field and then enter a real URL on the second line (and more on subsequent lines if you have more).
In the CSL file I am using the “URL” variable sees that field as empty so therefore does not interpret it as being an online resource in the reference list.
However, if you go to that record in Paperpile each of the URLs entered are still clickable.
This allows me to store the library permalink for a resource in a handy, clickable way but it does not interfere with my citations / reference list.
Stefan - is it safe to rely on that behaviour in the future?
I’m afraid that’s a bug not a feature. But we can declare it to be a feature for now and not fix it
One solution would be to add another field for private URLs, where you could store links just for yourself which never will be included anywhere except Paperpile. It seems simple but even such a minor feature comes at a cost, the main issue inevitable confusion about two URL fields and an additional support burden for us.
I like the idea of reframing it as a feature not a bug but it would probably lead to some rather unexpected behaviour later on.
I really do like the idea of ‘public’ / ‘private’ URLs.
Inevitably when I can’t do something that I want to in Paperpile, I think about how it’s done in Zotero. That is not to say it is always good - Zotero is feature rich but also quite complex, with many options, and that leads to a tough user experience. So I can certainly see why you should question every additional feature in terms of increased complexity for the user as well as support overhead.
And this is where I return to the question of what I want out of Paperpile, which may not be 100% in line with your (Paperpile’s) core objectives. My (personal) primary need is for a full-featured personal reference manager allowing me to record all sources I come across in my research, with enough detail to identify, select and locate a subset at a later stage and then easily include them in citations and references in my documentation.
Paperpile ticks a lot of those boxes, and does it very neatly, but there is more focus on collaborative authoring with reference to (only) digital resources. And this is understandable - it comes out of the scientific academic community. As you say in your recent blog post: “Paperpile is about academic productivity. Fixing collaborative writing is a big part of this equation…” I fully endorse the first sentence but the second is just not my need at the moment.
Perhaps there is also a slight mismatch with the needs of the humanities?
I am aware that I have strayed from my initial feature request but this seemed as good a place as any for a brief exploration of the context.
Thanks for your post. This forum is exactly the right place for brief or long “exploration of the context”.
There is no deeper strategic agenda behind our reasoning to consider a feature like this or not. There is certainly no bias against the humanities. Actually, we spent quite some time this year adding features only for the humanities.
It’s just I’ve heard the first time about that problem this week. There are literally hundreds of requests like that (you only see the public feature requests here which is only a fraction of what we get through the in app messenger).
If we blindly implement all suggested features Paperpile will become unusable eventually. If we ignore all suggestions the product will not evolve and will die.
The key is to translate the wealth of feedback we get into a feature roadmap that moves the product forward. That’s challenging.
I can imagine that it is challenging trying to choose which of the very many disparate requests you implement and which to reject - one of the least fun aspects of product development I guess!
I think it might have been in a separate email thread with Andreas that I previously mentioned that physical objects in libraries still play a big role in my research so having an actionable library catalogue permalink in the record - along with Library and Shelfmark / call number - is very useful (in Zotero). Clearly this URL is not a link to the content, so different actions apply.
Of course, this requirement may be wanted by only a tiny minority of your customers, or potential customers.
but it would probably lead to some rather unexpected behaviour later on.