Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design a sub menu to contain more capabilities for transcriptions and translations #784

Closed
gissoo opened this issue Apr 20, 2022 · 14 comments
Assignees
Labels
🗺️ design Tracks design work in an external app

Comments

@gissoo
Copy link
Contributor

gissoo commented Apr 20, 2022

the capabilities are:

  • view editors' names,
  • view transcriptions and translations by other editors,
  • ability to copy transcriptions and translations
  • each transcription and translation record on a page has its own sub menu
@gissoo gissoo added the 🗺️ design Tracks design work in an external app label Apr 28, 2022
@gissoo gissoo self-assigned this Apr 28, 2022
@gissoo gissoo added the 💬 awaiting review Ready for comments and questions label May 2, 2022
@gissoo
Copy link
Contributor Author

gissoo commented May 2, 2022

@rlskoeser @mrustow @richmanrachel Please take a look at the screenshots below. The only two sub menu items for the translation and transcription records are the ability to 1. Copy and 2. to select to view the translation/transcription by another editor.

Questions for you:

  1. Have we previously discussed any controls/sub menu items for fragment images that could go in the same place as copy and editor controls? (Other than zooming/rotation)

  2. What are we calling the "editor" for translations? Is it still "editor"?

  3. Is the format of the editor drop-down intuitive? I know MR and RR suggested that we combine the Editor info and turn it into a drop down to let users select transcriptions/translations that way, is this format intuitive? And is the language intuitive? Let me know if you have suggestions (we have already decided on using one set of controls on desktop per page)

  4. On mobile the controls are stacked and they appear above each record type, is this OK with you? I tried putting them next to each other initially but the size of the copy button won't be accessible.

  5. The green checkmark style would appear on the copy button when selected and the intended behavior is then the green checkmark would go back to deselected (the outlined version) after a few seconds (using the green checkmark style as a way to indicate the user has successfully copied the content), is this OK implementation-wise/accessibility?

sub menu items/controls when two toggles are selected
desktop
Screen Shot 2022-05-02 at 6.24.53 PM.png

mobile
Screen Shot 2022-05-02 at 6.26.57 PM.png

sub menu items/controls when one toggle is selected
desktop
Screen Shot 2022-05-02 at 6.27.46 PM.png

mobile
Screen Shot 2022-05-02 at 6.27.32 PM.png

@richmanrachel
Copy link

Have we previously discussed any controls/sub menu items for fragment images that could go in the same place as copy and editor controls? (Other than zooming/rotation)

  • No. Although "download" would be nice if we have the permission for that.

What are we calling the "editor" for translations? Is it still "editor"?

  • I think it might be "translator" -- @mrustow, do you agree?

Is the format of the editor drop-down intuitive? I know MR and RR suggested that we combine the Editor info and turn it into a drop down to let users select transcriptions/translations that way, is this format intuitive? And is the language intuitive? Let me know if you have suggestions (we have already decided on using one set of controls on desktop per page)

Yes, looks good to me (if I understand the screenshots correctly)

On mobile the controls are stacked and they appear above each record type, is this OK with you? I tried putting them next to each other initially but the size of the copy button won't be accessible.

I'm not sure I understand. Aren't these controls the icons that are next to each other?

image

The green checkmark style would appear on the copy button when selected and the intended behavior is then the green checkmark would go back to deselected (the outlined version) after a few seconds (using the green checkmark style as a way to indicate the user has successfully copied the content), is this OK implementation-wise/accessibility?

Copy looks way too prominent on mobile for me, such that it's unclear that it's an action (rather than telling you this is a "copy" of the document). But @mrustow is the queen of mobile PGP usage, so I'll defer to her.

@rlskoeser
Copy link
Contributor

  1. I don't know of any other controls for images and would prefer to keep it simple. Could imagine download being useful, as RR says; I think that's often supported in iiif viewers. That would likely be per-image.
  2. Translator makes sense to me.
  3. Format makes sense, but same concern/question as I expressed in the issues about toggles — how much information is needed, and how can we accommodate longer names here? Are there cases where we have two different transcriptions by the same editor from different sources (e.g., a published version and an unpublished)? Or is selecting by editor enough?
  4. I think copy is less important than the editor label, and the order on mobile should be reversed; also might help to have the copy button closer to the content that will be copied. On the desktop view with only one toggle selected I think the copy button is too large. Can we limit the width and give more space to the editor information?
  5. What you describe for the green checkmark to indicate actively and successfully copying the content sounds reasonable to me. The visual indicator won't be accessible to screen readers but we'd probably need to implement ARIA indicators or feedback anyway, so that's fine.

question:

  • What does the editor display / drop-down look like when there is only one transcription, as is the case for the majority of documents with transcription?
  • Are we going to implement the one-click copy functionality anywhere else (e.g., for shelfmark)? Would like to have a common button or other visual we can use everywhere so that users will recognize it.
  • On mobile, when content is stacked, do you intend that the editor label and copy button repeat, or is it only displayed with the first section? My expectation is that the copy button would give you the full text of the transcription, not just the current page — repeating it or linking it too closely to a section of the content might indicate otherwise.

@mrustow
Copy link

mrustow commented May 4, 2022

Yes to "Translator."

@gissoo
Copy link
Contributor Author

gissoo commented May 9, 2022

@rlskoeser @richmanrachel @mrustow thanks for writing.

  • @rlskoeser, Re: the size of the editor label – after meeting with Marina and Rachel we agreed on placing “Translation: translator’s name”, and “Edition: editor’s name” – We didn’t discuss source title or the case you have mentioned above. Regarding the cases with multiple authors, could we resolve by truncating when collapsed? Also, thinking now it might be worth to add “Translation: translator’s name”, and “Edition: editor’s name” and any other relevant info such as the source title above the records to resolve this issue, would definitely be helpful on mobile! Let me know what you think, @mrustow and @richmanrachel

  • After talking with Rebecca, we agreed to remove the menu items (edition/translation and copy) on mobile that were above each record and just display it once on top of the panel, below the toggles.

  • I have revised the copy button and its placement extensively :D – it’s consistent with our button styles now and I’ve generalized it so it could be used by the shelfmark field too, please see on Figma what it would look like on our various cases. 1. I’ve removed the checkmark from the copy button because it was an inconsistent affordance. 2. Because it would potentially copy both translation and transcription on the page, and because I don't want to customize the height of the button to match the height of the drop down, I think it's simplest that we move the button down closer to the text. There is also more space for the edition/translation drop down now. Though, Rebecca, I’m not sure if it’s clear that the copy button would be copying the transcriptions potentially across multiple pages, it might be worth seeing if it makes sense to people, I would think it’s more likely to be understood as a way to “copy content per page”.

@richmanrachel
Copy link

@gissoo - regarding the first part, can you show me an example please? I'm having trouble understanding what you mean about truncating or seeing source title above the record without a visual. I think I agree, just want to double check!

The copy design looks much better, thanks!

@rlskoeser
Copy link
Contributor

@gissoo I'm fine with "editor: name" and "translator: name"; if there are any cases where editor is ambiguous, it should be pretty rare. (and maybe not any).

I like the copy button, and like the choice to move it closer to the text. I'm not sure about the placement for the shelfmark, but can see the logic for putting it where you did. We may also want one for the top-level shelfmark on the document title.

@richmanrachel if you see a copy button near transcription/translation, would you expect to get all the content or only the next page? My presumption is that you would prefer to get all the content at once, is that correct?

@richmanrachel
Copy link

@rlskoeser - yes, I'd like to copy all the content at once please. Thanks!

@gissoo
Copy link
Contributor Author

gissoo commented May 10, 2022

@rlskoeser @richmanrachel Great! let me clarify: what I mean about the copy button's behavior (copy page-by-page vs. all) is that it's not clear to the user it that hitting that copy button would copy all the text, not just what they see on the page, till they paste it and find out. Is that OK?

@richmanrachel
Copy link

@gissoo - yes, I'd rather be surprised by getting more than not getting enough!

@rlskoeser
Copy link
Contributor

@gissoo yes, I understood you concern. I see that, but think it will be obvious enough in practical use and I agree with Rachel that it's ok to err in that direction. Perhaps we can mitigate with title text on hover or something similar.

@gissoo
Copy link
Contributor Author

gissoo commented May 11, 2022

@rlskoeser @richmanrachel @mrustow documenting some decisions here:

  1. Marina and Rebecca agreed to the proposed format and placement for the source information/citation.
  2. Marina stated the citation would need to have page and volume info (mostly book citation format).
  3. Marina and Rebecca also agreed with the truncated version of the drop down on mobile (won't probably need truncation on desktop) – this is for multi-authored cases (@richmanrachel, you can use the link below to see this)
  4. Marina agreed on displaying the record type (i.e. "Translation" or "Transcription" once on the panel at the top.)
  5. Marina agreed with the proposed display for the shelfmark and side information above each image (e.g. shelfmark recto/verso) – thanks to Rebecca for the proposed placement.
  6. @rlskoeser, Marina loved your idea to get citations copied along with the transcription and translation content, let me know if I can help track that if needed.

Also, @rlskoeser I will add the copy button styles to the components page on Figma.

You can find all of the above in this Figma frame (used State Document; DK 256 (alt:XXI) as an example here because it's multi-authored).

If you're all fine with these changes, I can close this issue.

@richmanrachel
Copy link

@gissoo - looks great! Thanks so much!

@rlskoeser
Copy link
Contributor

@gissoo thanks for documenting! This all looks great to me. I'm glad my suggestions were helpful.

Will be great to have copy button styles in Figma components for all states/interactions.

I'm not sure when & how we will translate your designs into user stories to articulate all the functionality and design work to be built, but it would be great to make sure we document that copying the content should include the citation. (I think it should also include the permalink for the document.)

@rlskoeser rlskoeser removed the 💬 awaiting review Ready for comments and questions label May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🗺️ design Tracks design work in an external app
Projects
None yet
Development

No branches or pull requests

4 participants