carlhiggs
commented
3 months ago I noticed an issue with the use of embedded FigShare resources (#15), but still trialled approaches for how this could work, e.g. a list of resources with popup to view details and get citation. Each entry is generated using a function that takes a title and the FigShare article ID.
TL/DR --- I think it will be better to create a stand alone list of data resource details
- title
- description
- formats
- citation
- licence
- URL for retrieval (ideally, a DOI URL for a registered repository)
The above details could be accessed from an expanded list of resources by title, with helpers like a direct 'copy citation' button and button to get data from supplied URL, and perhaps view data in an applied example within the JibeVis app.
This way there will be no reliance on third party embeds, and the third party site can be directly linked to.
But for the record here are implementation examples of using embedded FigShare:
- I created a custom popup dialog function using Material UI elements; this function accepted arguments of
titleandarticleand used these to create a button containing the resource title that when clicked opened a dialog containing the embedded iframe for the article. This was done by constructing the iframe within the dialog, inserting the article ID into the URL string:
So I used import and used this function in the data sub-page for a range of example FigShare article types. None of these are actually from the JIBE project as data is not registered there yet, but they demonstrate an approach to simply listing data with more details viewable in a popup window:
This list looks somewhat like this:
And when a record is click, it looks like the following for a resource containing a list of outputs:
and its example citation (again, not actually from this project; its purpose was as a placeholder):
for a single PDF resource, it would look like this:
a CSV:
a Github repository software release:
an MP4 video:
So, it is quite usable, particularly when single resources are registered as the preview functionality is able to be used.
However there are downsides:
- the cross-site third party cookie issue could mean functionality in Chrome will cease (#15); I've reported this to FigShare but at the very least, the issue warnings are distracting (hundreds are generated in the development console)
- for most data resources these shouldn't be registered as a single file, e.g. a CSV file would ideally be accompanied by a data dictionary, and in that case the FigShare embed apparently won't display a preview, but a list of files as per first example above
- when you click on 'view' for a single resource, it doesn't actually show that single resource but links to the FigShare page containing all resources, and doesn't actually display that resource
- you have to dig quite deep to find the 'Share' button to get the citation; I attempted to use jQuery to extract the citation and display this, but besides being hacky and likely inefficient, I couldn't get it working.
So, a more efficient and robust approach will be to actually just make the list of items for each data record ourselves, pass this to a function that will create a formatted entry in the list of data resources that perhaps is collapsed and is expanded when clicked for details. That can contain a URL linking to FigShare, but also directly display the citation --- so that should achieve more or less the same without the downsides. The exception is direct media embedding, which could be useful where this is feasible (e.g. MP4s); we could do this on those occasions if the third-party cookie warning wasn't considered a problem.
It is planned that final JIBE outputs will be hosted in institutional repositories, such as FigShare or Zenodo. FigShare (and likely others) have options to generate an iframe to embed content in a website, which looks a bit like this:
(using demo data of my own in this example)
The benefit of this is a single official location with persistant DOI linkage is used for data storage, and the metadata associated with this could presumably be extracted. At the very least, the default iframe content includes option to get a citation by clicking on 'share', as in demo below:
If a repository has multiple artifacts, the embedded content appears as a list. If there is a single resource, if the file type is supported (e.g. a pdf or csv) it is directly viewable on the page.
It may be possible to make a list of published article IDs and then programmatically generate associated iframes; the article titles could perhaps be retrieved from the iframes and these could be displayed as a list on the page (or perhaps citations). Then, if clicked these could open up a pop-up dialog containing the embedded content for only the selected article (ie. not like images above were embedded iframes are stacked vertically down the page).