zotero / publications Goto Github PK

Seems like a newline-related issue — I'm only getting one line for an RDF file and all text in one line in RIS (which has embedded \r\n).

Now that we're embedding this in the profile page, the accordion feels a bit weird. Let's try replacing it with a Bootstrap modal popup containing the details view, opened via the title link for every entry. The direct-view functionality can be a separate link in each entry (when available) that reflects what it does, similar to the drop-down menu in the client: "View PDF", "View File", "View Online".

If we go this route we'll need to fiddle with things some more, particularly in the details view (which will now need to be more of a standalone page with a title), but we can start by seeing how it feels.

Instead of the spinning Z (which is very cute, but too distracting), we should use the same spinner as other elements on the page (e.g., the groups list). Can either hard-code in the same spinner that the website uses or allow this to be specified in the config if we care about allowing sites to define the spinner.

(I'll also try to speed up these requests so that the spinner shows for less time.)

Can follow whatever we do in the client.

Now that we're generating references instead of citations, we don't need to focus on non-numeric ones. We should set citeStyleOptions to reflect our bundled styles, and we should default to Chicago. We can also discuss here whether we want to rethink which styles we bundle with the client.

These will likely be an ongoing series of changes, but here's a start. Let's update the cases for zotero-item-subline as follows:

• book should be publisher, year
• thesis should be university, year [maybe university maps to publisher anyway?]

Not sure whether we should do more to support multi-authored items. I'm a little concerned that we're calling this "my publications" and yet we might end up burying coauthors in the details view.

Because the height is styled inline for slide-out animation

e.g.

Hull, Duncan, Steve R. Pettifer, and Douglas B. Kell. 2008. “Defrosting the Digital Library: Bibliographic Tools for the Next Generation Web.” PLoS Comput Biol 4 (10): e1000204. doi:10.1371/journal.pcbi.1000204.

instead of

(Hull, Pettifer, and Kell 2008)

Can just use the item title for now. I can make a displayTitle meta field available that provides a title for some of the types that require special processing to generate a proper title.

This will allow us to remove the include=citation from the request, which should speed things up quite a lot and let us do caching more easily.

See below for updated requirements.

For the integrated version, when logged in, people should be able to add items to one of their libraries. Could be "Add to My Library", or could be smarter: if they only have a personal library, then that, or if they have write access to multiple, a choice.

@fcheslack said this would be easy client-side, but I can't remember if that depended on the new site. I can also create an API COPY call if necessary.

Loading data-urls to the top browser window is no longer supported as of Firefox 57.

A better solution is to use file-saver that will trigger "save file" dialog correctly in various browsers.

Related forum message:
https://forums.zotero.org/discussion/66669/my-publications-formatting-on-zotero-profile-page

Related user profile:
https://www.zotero.org/mrdcfp

Can just be a config option to hide (and should go to https://www.zotero.org, not http, while we're at it, though technically it doesn't matter because we're in the HSTS preload lists)

https://www.zotero.org/zuphilip-test5.0#QA4QWSPB

Firefox 47

Minor issue: I didn't have a closer look by now, but I noticed that the from() mixin in _respond.scss adds 1px, which leads to a min-width of 769px for tablets – so the iPad would not be included.

I guess we could just not add that 1px?

• The reference is generated with some inline styles – is this on purpose?
• Are we going to use clipboard.js or are we going to keep the current solution (at the moment there is no indicator in case the copy button does not work)?
• Switching between cite and export looks buggy

Also tweak spacing.

When viewing a publications list with Zotero installed — on- or off-site — Zotero should offer to save the items in the list.

Unfortunately our metadata options here aren't great, which is somewhat depressing at this point in Zotero's development. We can get COinS from the API, but it's lossy. Something like RDFa would probably be best, but we don't support that currently. We could probably hook up an API-powered unAPI endpoint easily, but since unAPI seems basically dead (the website is down), just writing an RDFa translator might be a better use of time.

See dissertation at https://zotero.org/sean for example of file that should pull directly from Zotero, not the URL associated with the attachment.

See below for updated requirements.

When grouping by type, we should sort groups.

The auto-highlighting is a little awkward, so if clipboard.js works well, we should just use that.

Right now until the list loads the spinner is halfway into the page footer. We should set a reasonable minimum height on the container to avoid this. (This might belong in the site repo.)

It would be nice to have a live demo website maybe on jsfiddle. This would help to get some visual impression and allow a user to play around immediately with the html, css, javascript. I guess it is just about copying some of the things here around, but I don't see currently how to do that exactly...

https://www.zotero.org/zuphilip-test5.0#QA4QWSPB

is there a way we can have structured abstracts or do they have to be exactly one paragraph?

The drop-down is a bit distracting and action-focused in what should be a reading-focused. Instead of showing the citation drop-down and a default citation automatically, Cite/Export should just be buttons in the details view that you can click on. If you click on Cite it can show the drop-down and default citation, but not before that.

Not sure if this belongs here or in at the level of implementation on www, but rights should be visible on a per item basis, e.g. BY-NC-SA, Public Domain, All Rights Reserved, etc.

"Saved!" should just be text and not a link, right?

(Might be centered in container, but the header and text doesn't run to the edge, so the spinner looks too far to the right.)

The collapsing transition of the details section is most often not triggered. In my understanding we would have to do the reverse thing than the expand: first set the height with inline style, add the .collapsed class (height: 0), remove the inline style.

Using dom breakpoints I tried to figure out how Bootstrap's collapse.js works – it seems they do not set the height for the collapse transition initially, which doesn't make sense to me, maybe the developer tools are fooling me.

When publications are rendered, it should check if there is already a valid item key in the url fragment and expand that section if there is. That would allow people to properly link direction to a specific publication.

Always cites in the default format

https://forums.zotero.org/discussion/64125/5-0-beta-my-publications-cite-function-on-zotero-org-broken

• Remove the build folder from the repo
• Reduce the amount of variants offered to one or two (modern + compat)
• Simplify the build process
• Simplify README

At the moment, if item has no url, first attachment will be promoted to act as one. That means it will be accessible by clicking on the item's title but won't be listed in details section as an attachment. This follows "View Online" behaviour of the Zotero Client.

However this means user can never be sure what exactly happens when the title is clicked. Thus it might make more sens to indicate items with attachments available at glance in the top view, e.g. by displaying an icon next to it. Attachments would then be explicitely listed in the details section and title would only be clickable if item url is present. The new "has attachment indicator" could also be clickable, linking to the attachment.

Thoughts and comments welcome. Any questions, please shout.

What about localization?

On the one hand we have the group titles (book, journal article, …) and on the other hand some texts in the user interface (details, cite, export, …).

Is it English only?

api get request is not sent in safari (v 9.0.3).

Because we're overriding some of the styles and inherit others, when embedded on other pages, button might appear with broken styling. Caused by #35

Right now export data is sent without content type. It should send the same types sent by format=bibtex, format=ris, etc.

I think it's a bit too unwieldy with a bunch of creators.

We could maybe use commas, or could just stick to the vertical list like in the client (with a hard-coded limit of 10, expandable to more, to account for papers with 1000s of contributors). With the latter we wouldn't have to deal with interspersed creators of different types (not sure what we're doing for that now anyway).