Publication/dataset detail page sidebar

[verheyenkoen]

Enhancement

Add an icon sidebar on the right side in detail pages with 2 icons that open/toggle a drawer when clicked.

• Biblio messages

  • Biblio message
  • Librarian tags (librarian only)
  • Librarian note (librarian only)
  

• Add a "dot" to Biblio messages menu item when there is a message added to the Biblio message field.
  No need to add a "new message" state. The dot can be shown if the input field is "dirty".

• Details

  • Author/editor name and date
  • Source (if applicable)
  • All identifiers with links to external sources
    • e.g. https://booktower-ugent-ui.vercel.app/biblio/researcher/publications/detail/full-view.html#identifiers
    • If there is no link available, just display the text (e.g. Plato, ISBN, ISSN, ...)
    • For datasets: identifier and type
  • When published: link to biblio front office

• Activity history
  • We can already display the information we have, and extend later.

• remember whether the sidebar was opened or locked across records

Prototype

[mietcls]

Added:

• librarian tags
• librarian note

Suggestion for save: buttons for now until we have a coherent approach to saving everywhere (otherwise we will have different patterns which will be confusing).

[mietcls]

Q: Can we remember whether the message tab was opened or closed by default?

[verheyenkoen]

Q: Can we remember whether the message tab was opened or closed by default?

[verheyenkoen]

@nics I started this a couple of weeks ago but very quickly bumped into the fact that this is needed for both publications and datasets so the question is: is there something we can do to make sure we don't have to build the sidebar twice? We talked about deduping other views but never took any steps AFAIK. I guess it would be good to finally kick this off before we create any new duplicate views.

[nics]

@verheyenkoen you can dedup them if it isn't too much work. The next version combines Publication and Dataset into Work, so it's not worth it duplicating all that effort here.

[verheyenkoen]

@nics I guess my question wasn't clear. How do we do that? I guess we need some kind of common structure for publications and datasets for that to be possible but I don't know how to achieve a base interface in Go that can be both. As I don't really know how this is done, I can't really estimate the effort for that.

[nics]

That was my point, making a common interface isn't worth the effort now, the next version already solves that. But if you can easily avoid some duplication now by making the url configurable and passing a common args to the template, then go ahead.

[verheyenkoen]

But I guess that requires mapping the common fields on a new struct type before passing it to the view?

[verheyenkoen]

• Add a "dot" to Biblio messages menu item when there is a message added to the Biblio message field.

@nics Is this something we can achieve with the current Biblio? We can compare the message with previous snapshots but I don't think we have a way to log who has already seen this change (unless in local storage).

[nics]

• Add a "dot" to Biblio messages menu item when there is a message added to the Biblio message field.

@nics Is this something we can achieve with the current Biblio? We can compare the message with previous snapshots but I don't think we have a way to log who has already seen this change (unless in local storage).

Not efficiently no, better to postpone this.

[verheyenkoen]

@mietcls I think we're gonna need some kind of loading-feedback when you click one of the save buttons. In the current version you see the popup close when the save is complete but in the sidebar, if the save succeeds nothing appears to be happening which may cause confusion.

[mietcls]

Thanks for noticing, I'll make something @verheyenkoen

[mietcls]

Discussion yesterday:
Saving behaviour in the modals in the detail panel VS the save buttons in the side panel: might result into information loss.

@verheyenkoen can you confirm / add any thoughts?

• Option 1: We assume people have to save the side panel changes.

  • Upside:
    • it's already a few clicks less than the Biblio messages tab
    • it's consequent behaviour
  • Downside: if they open a detail panel modal and click save, without saving the edits they made in the side panel, the edits in the side panel will disappear be lost.

• Option 1.1: We explicitly ask on blur whether the user wants to undo the changes they made.

  • Upside: we make consequences explicit.
  • Downside:
    • A lot of small tweaking = a lot of maintenance.
    • Requires customisation we might throw out.

• Option 2: We autosave whatever happens in the Biblio messages, librarian tags an librarian notes

  • Upside: there will be no saving issue
  • Downside: our saving behaviour will differ in the application, causing mixed expectations which can cause frustration.
    • There is no autosave anywhere else. This is introducing different behaviour in one application, which can result in different problems.
    • Introducing autosave is not ideal right now. If we are going to tackle the full page, we might land on different behaviour, and taking that away afterwards is going to be hard.