Add download option to front end reference list

[someonehere15]

As discussed again, a download option for each reference to a reference container file (RIS as you said) for front end users if they want to reuse the reference. Maybe also an additional option to download all references in one file. Good luck!

[dsifford]

Would just an export-all be acceptable? Or did you also need single-reference exports?

[someonehere15]

Normally both would be the best, single ones probably better than all together because it doesn't force all if one is needed. But if you mean what I might need now, export all is also enough. Would that then be only for the references imported from RIS and not the manual ones? Just asking.

[someonehere15]

Sorry, just saw your last post on the other thread. If you're referring to EndNote XML, then it might also work. But I don't know any standard reference formats that use JSON. As we discussed, the three most popular are BibTex, RIS, and possibly EndNote XML. Anything other than that would be very limited, if any.

[dsifford]

@someonehere15 Just realized that CSL parses into bibtex. I can definitely have it exported as bibtex. 👍

[dsifford]

@someonehere15 Can you show me an example of how this might look? I'm trying to devise a way to make this optional, but there are several different application states that this option would have to reside in order for it to work and it's proving to be quite challenging.

Re: single exports. (Devils advocate question, so forgive me if this is perceived as condescending) -- What's the difference between me clicking an export reference link on your website for that single reference vs me clicking the link on that reference and exporting directly from the source? (literally the differece is 2 clicks, I'm aware of that, but... Is that worth the enormous amount of effort?)

[someonehere15]

I'm not sure I understand what you mean. The step by step process would be: I am the author. I export a file (RIS, bibtex, whatever), from my reference manager, and import it into your plugin, and add the references in the post. Now, the other side, I am the reader. I read the post, and I find interesting publications referenced there. For whatever reason, I want to have the reference in my own reference manager. So I don't search for it manually (it is sometimes difficult to find a right reference, even the publishing database doesn't have it right). Anyway, I just download the reference from the website in a format that my manager can import. In the optional case that I want to download all of them, I can download them directly in a single merged file again directly from the post (generated by your plugin). On the other hand, If I only want one reference, I dont have to import all of them in my manager, because if I import a file usually ref. managers import them all, so if you want only one you will have to manually delete the rest after importing, which is also not practical. That is why I said separate files are better than a single one. I just described this process to avoid any misunderstandings, not that I think you don't already know or anything. But I still don't understand what you mean. The first case you describe is the same one I described, right? But the second one, "clicking the link on that reference and exporting directly from the source?", what is the source?

[someonehere15]

So, not at all trying to tell you how to develop, so please don't take it the wrong way. But I was thinking, if you already save the parsed references in JSON, be it from importing RIS, from PubMed, or manually, can't you relatively easily generate a RIS file, or even bibtex for that matter? You just create the file with the RIS specs and fill the fields. You don't even need to create a downloadable file if that's the problem, you can generate it on the fly with php. Even further you don't even need a separate php file, you can just catch the bytestream of the generation inside the same file if you want, and provide the data in a data URI. Not sure if it would be completely possible, but I don't see why not. You don't even need to catch the bytestream probably, you can just generate the string yourself. So the only thing to do is fill a RIS file with data.

Here's a snippet I have in one of my stuff doing the bytestream catching and inserting an image:

ob_start();
header( "Content-type: image/png" );
imagepng($im);
imagedestroy($im);
$imagebase = ob_get_clean();
$html .= '<img src="data:image/png;base64,' . base64_encode($imagebase) . '" title="'.$data.'" alt="'.$data.'" />';

[dsifford]

The difficulty for me is twofold:

1. How am I going to display the download link? A button? Where would it go?
2. How do I make this optional? Only a small minority of people would be interested in this (at least in the circle that I swim in).

Generating the file isn't much of a concern. I wouldn't be using PHP to do it though (confession: I loathe php). I'd be doing it in TypeScript like pretty much everything else.

If you have some ideas you'd like to try out, feel free to fork the repo and give them a shot. If you get it working, send a pull request and I'll check it out.

[dsifford]

I just described this process to avoid any misunderstandings, not that I think you don't already know or anything. But I still don't understand what you mean. The first case you describe is the same one I described, right? But the second one, "clicking the link on that reference and exporting directly from the source?", what is the source?

The source I'm describing here is the journal's website. Say for example, you add a reference with a DOI or PMID and choose to add links by selecting that option. If you click those links it takes you to the journal's website (the "source") and there you can easily export the reference to whatever format you desire. My question was, is it worth it to add this very same feature to the reference list when all the user would have to do is click one extra time to get it from the source?

[someonehere15]

Ok, from the bottom up. Yes, it would just be an additional click, but I would think of two reasons that is not always the case:

1. The source websites are usually not intuitive in the exportation of references, most academic databases are ugly looking, and this would help, and...
2. More importantly, not all references have the link. If I manually insert a reference or import from my own RIS file, they may not have a doi. Sure it would be nice if DOI were a requirement everywhere, but nothing we can do about that.

As for the former questions, you just add a link near each reference, which as I said, if no other solution, you can also use to directly contain the info as a data URI, although of course you know better how to solve this. You don't need to make it optional, there's no harm in providing that, but even if that's the case, you can just add a checkbox or something in the editor widget for each reference. I don't know if this answers your question. Besides, didn't you say that you can easily export it to bibtex since CSL parses to that? ;)

I would have loved to experiment with the plugin, but my hands are currently very full with developing the prototype I told you, which I need to finish in two weeks, and the references are just one use case in it. That is why I may have been insisting on the download thing, of course with the reasoning that it not just for my prototype but that it actually is helpful and practical. I currently have a limited solution, consisting on papercite, another wp plugin, which I slightly modified to provide an additional download button for bibtex. It uses the "download" tag though, which limits browser support. I'm just trying to say that your plugin would have been perfect, considering all the other features it has.

Anyway, just one last thing. As I previously said, it would be nice if you added an additional manual reference type as I said, for footnotes only, or maybe at least make the Web Page type to require only the URL and title, in case of a simpler reference. The first one would be better though.

[dsifford]

@someonehere15

Good points Re: manual refs not having a "source".

Let me fix the open bugs first and then I'll start working on your request.

It'll have to be an icon or something that makes it absolutely obvious to the user that if they click it, they're getting a file downloaded, so that'll be one thing for me to mull over. Also, as you mentioned before (I think?) not all browsers directly support file downloads using HTML5 (safari being the biggest issue). It won't be possible in PHP because I'm not using PHP at all anywhere in this plugin (other than loading javascript).

So, to recap, there's still a few things I have to think over, but that'll have to happen after the bugs are fixed first. :+1:

One final question: What are your thoughts on instead making the references directly exportable to Zotero (and possibly mendeley and endnote?). I had a zotero dev member ask me about this and I think if they provide me the API docs to their zotero connector browser plugin, that would be a much better (and more demanded) alternative.

Let me know what you think.

[someonehere15]

If you mean what I said about the browser support, I was talking about the href "download" attribute, so unless you use that, I can't think of any other problems. For the icons you can use FontAwesome for instance, many themes even already include it. What do you use for the icons in the editor?

As for the rest. My initial thought actually was to directly export them to reference managers, but I decided to just ask you for exporting to a file because it can be used anywhere anytime, whereas directly exporting would be limited to the manager you support. With a file it would be just an additional download and import anywhere. However, I would love the idea of directly exporting, if you would include support not only for zotero, but Mendeley and endnote too, possibly also citavi. These would be the four most used to my knowledge. I don't know if this would be easier for you than just providing a file, but as I said, if you can support multiple managers, then hell yeah, it would be great.

[dsifford]

What do you use for the icons in the editor?

I use wordpress "Dashicons" -- reason being, they're already loaded into the page so there's no extra network overhead.

if you would include support not only for zotero, but Mendeley and endnote too, possibly also citavi

I'll keep that in mind. No promises, but who knows.

[someonehere15]

In my experience for instance, most of the people I know use Mendeley or Endnote,mostly because universities buy licenses for them. I personally like zotero too, although each has its advantages and disadvantages, but it's not my decision for different universities anyway. Just saying so you know zotero is not enough since the whole user base is niche anyway.

[dsifford]

@someonehere15 Good points.

I'm about to push a small update with bugfixes in a few. After I get that out into the wild I need to focus on finishing the one outstanding major issue ( #42 ) -- After I get that all sorted out I'll focus on getting this started. Sorry to keep you waiting!

[someonehere15]

No problem at all, thanks for even considering. I hope you solve the issue, I saw it earlier.

[someonehere15]

Any updates on this, or have you not had any spare time?

[dsifford]

@someonehere15 Haven't started it yet, but I plan on it within the next few days.

I just finished writing tests (sigh...finally!) for the features that already exist. It took me forever, but it had to be done.

Sorry this has taken me so long; in my defense, I had to write a lot of tests! 😱

> academic-bloggers-toolkit@3.1.1 test /home/travis/build/dsifford/academic-bloggers-toolkit
> jest
Using Jest CLI v12.0.2, jasmine2
 PASS  lib/js/utils/__tests__/Modal-test.ts (3.973s)
Modal
  ✓ it should render
  ✓ it should resize
 PASS  lib/js/utils/__tests__/HelperFunctions-test.ts (2.573s)
HelperFunctions
  ✓ it should parse inline citation strings correctly
  ✓ it should parse citation number arrays correctly
  ✓ it should format titles properly
  ✓ it should find and replace URLs and DOIs correctly
 PASS  lib/js/utils/__tests__/RISParser-test.ts (5.047s)
RISParser
  ✓ it should parse webpage correctly
  ✓ it should parse journal-article correctly
  ✓ it should parse books correctly
  ✓ it should keep track of unsupported reference types
  ✓ it should be able to handle empty strings
  ✓ it should process an assortment of fields correctly
 PASS  lib/js/utils/__tests__/CSLFieldProcessors-test.ts (4.233s)
CSLFieldProcessors
  ✓ it should process RIS names correctly
  ✓ it should process PubMed names correctly
  ✓ it should process RIS dates correctly
  ✓ it should process PubMed dates correctly
 PASS  lib/js/components/reference-list/__tests__/Card-test.tsx (6.942s)
<Card />
  ✓ it should render as selected when index is in "selected"
  ✓ it should render as unselected when index not in "selected"
 PASS  lib/js/components/pubmed-window/__tests__/ResultList-test.tsx (8.636s)
<ResultList />
  ✓ it should render with two children
  ✓ it should bind the PMID to the event on button click
 PASS  lib/js/components/import-window/__tests__/ImportWindow-test.tsx (7.451s)
<ImportWindow />
  ✓ it calls componentDidMount
  ✓ it calls componentDidUpdate
  ✓ it should properly toggle "links" when checkbox is toggled
  ✓ it should render citation selection properly when default is set
  ✓ it should default to "american-medical-association" when no default style is set
  ✓ it should render selected option properly and set state correctly on change
  ✓ it should trigger handleFileUpload when upload field changed
  ✓ it should handle form submit correctly
 PASS  lib/js/components/reference-window/__tests__/MetaFields-test.tsx (8.298s)
<MetaFields />
  ✓ it should render with the correct title
  ✓ it should dispatch META_FIELD_CHANGE event when fields are changed
 PASS  lib/js/components/peer-review-metabox/__tests__/ReviewRow-test.tsx (7.43s)
<ReviewRow />
  ✓ it should dispatch "onChange" with the correct data
  ✓ it should dispatch "onClick" with the correct data
 PASS  lib/js/components/reference-window/__tests__/ManualEntryContainer-test.tsx (9.323s)
<ManualEntryContainer />
  ✓ it should render with the correct option
  ✓ it should dispatch CHANGE_CITATION_TYPE when another type is selected
 PASS  lib/js/components/reference-window/__tests__/People-test.tsx (7.96s)
<People />
  ✓ it should dispatch the ADD_PERSON event when add button is clicked
  ✓ it should dispatch the REMOVE_PERSON event when remove button is clicked
  ✓ it should dispatch the PERSON_CHANGE event appropriately when input fields are changed
  ✓ it should dispatch the PERSON_CHANGE event appropriately when select fields are changed
  ✓ it should display the correct label for AUTHOR in varying types
 PASS  lib/js/components/peer-review-metabox/__tests__/CommonRowContent-test.tsx (7.087s)
<CommonRowContent />
  ✓ it should render as a reviewer
  ✓ it should render as an author
  ✓ it should dispatch "onChange" with the correct data
  ✓ it should dispatch "uploadHandler" with the correct data
 PASS  lib/js/components/pubmed-window/__tests__/Paginate-test.tsx (7.349s)
<Paginate />
  ✓ it should render with "next" enabled and "previous" disabled
  ✓ it should render with both "next" and "previous" disabled
  ✓ it should paginate to the next page when "next" is clicked
  ✓ it should paginate to the previous page when "prev" is clicked
  ✓ it should only be able to paginate to 4 pages
 PASS  lib/js/components/peer-review-metabox/__tests__/PeerReviewMetabox-test.tsx (7.861s)
<PeerReviewMetabox />
  ✓ it should mount showing no rows
  ✓ it should mount showing 1 row
  ✓ it should mount showing 2 rows
  ✓ it should mount showing all 3 rows
  ✓ it should mount with "state.hidden[1]" false
  ✓ it should mount with "state.hidden[1]" & "state.hidden[2]" false
  ✓ it should mount with all "state.hidden" false
  ✓ it should dispatch "handleSelectChange" correctly
  ✓ it should consume "handleInputChange" correctly
  ✓ it should consume "toggleHidden" correctly
  ✓ it should open mocked media manager
60 tests passed (60 total in 14 test suites, run time 18.046s)

[someonehere15]

hehe, well done, congrats!

[dsifford]

@someonehere15

Not sure if I asked this already, but can you send me a screenshot or a doodle of how you'd want this to look?

Are you thinking of just having a link or something after the citation or?

So, for example...

1. doe j. blah blah. citation 2015; 150-53. [export]

I can't really think of any way to do this cleanly.

[dsifford]

Also, FYI: The mendeley importer extension for chrome currently works with the plugin.

[someonehere15]

I can send you something later if you need, but basically you can just add a Download link at the end of the text as you said, in my opinion an icon would be even nicer. I think it's enough, people intuitively get it. Maybe add a title attribute to the link to say Download this reference in RIS format or something,for those who don't know what it does. The frontend part is basically this, simple, unless you are referring to something else.

As for Mendeley, so you are saying the Mendeley plugin would recognise the references? Very nice. I will try it out later. Thanks.

[dsifford]

@someonehere15 I'm now in a position where I can probably add optional export features. Let me finish up this next gigantic update and then we can chat more about this.

[someonehere15]

Sorry, just noticed. Sure, we can do that. Happy to help

[dsifford]

Unfortunately I won't be able to add this with the next release. I liked the idea, but it's just outside of the scope of the plugin.

If demand for this feature increases in the future, I'll reevaluate. I'll keep this issue open in the meantime.

To anybody who may be reading this: Use the 👍 on the first comment in this discussion if this is a feature that would be helpful for you. If I get enough thumbs up for this, I'll reevaluate.

[dsifford]

Closing this for now since I don't anticipate getting to this in the immediately foreseeable future. I'll come back and reopen if/when this feature aligns itself with the project trajectory.