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

Lessons' banners layout - review and implementation #1767

Closed
amsichani opened this issue May 6, 2020 · 7 comments
Closed

Lessons' banners layout - review and implementation #1767

amsichani opened this issue May 6, 2020 · 7 comments

Comments

@amsichani
Copy link
Contributor

This ticket aims to group together and address a number of interrelated issues #1751 #1738 #1525 #1749 regarding the visual layout of the banners in the landing page of a lesson, mainly from a user experience point of view.

Let me first address a couple of theoretical concerns (which also have tech/layout implications) and some technical proposals:

  1. Original lesson and translated lesson (see also Handling all available versions/translations of the lesson as equals #1751) : do we want to keep this distinction visible in the landing page? Do we think its important to inform the user regarding the genealogy/ history of a lesson?
    In my view, as we are growing into a project with multiple equal publications, there will be multiple and equal versions of the same lesson. We will soon have an English translation of an ES original lesson, and perhaps later a Portuguese translation of a FR original.

I think we should avoid providing this information * in the landing page in a banner *, as the distinction between 'original and translation' contains a hidden prioritisation between these two lessons as well as somehow reveals (established) power dynamics between languages. Also, as we are growing as publications, we might have a model that is much different to the 'one original source -> many translations' -- actually we might have 'original -> translation1'| 'translation1 as original -> translation2 ' etc.

If a user or a team member wants to find the 'genealogy' of a lesson, she can find everything in the metadata at the start of the lesson (date, translator etc) as well as in code. Technically, as Matt notes, there is an underlying assumption that all pages (not just lessons) have an "original" source and this should be kept in terms of infrastructure also for lessons, but I suggest it might be better if we avoid to present this information in the landing page of a lesson.

  1. Following this rationale, I think its better if we handle all available version of a lesson as equals (while keeping the underlying original->translation data model), and simply display
    i. Available in: EN | ES | FR | PT | XYZ

or
ii.In English | En español | En français | Em português

with links to the related language version of the lesson, avoiding placing the translated title of the lesson for layout reasons (too much information!).

  1. By following the above in terms of layout , we will have 3 banners max for lessons
---------------------
| DONATION BANNER 
---------------------

---------------------
Available in: EN | ES | FR | PT | XYZ 
---------------------

---------------------
This is lesson number 4 of 15 of this series. Move back |  Move forward
---------------------

NB.

  • the 3d banner will be currently used only for two lessons' series Progress reporting for Lesson Sequences #1525

  • a small number of ES lessons (python) are having an additional banner regarding earlier version of Python used. For these lessons only we will have 4 banners.

I think it's a reasonable approach that will give a more clear layout to the lessons.

We welcome PT feedback before the @programminghistorian/technical-team moves on with the implementation - before 11th May would be great.

@mdlincoln
Copy link
Contributor

mdlincoln commented May 6, 2020

Relevant to your larger goals about de-prioritizing the original->translation question: how is this impacting displaying the original author, translator, etc. as well as publication date vs. translation date?

Screen Shot 2020-05-06 at 5 07 23 PM

I actually do think it matters that the author of a lesson wrote it in a certain language, and that it's clear to readers who land on one version of a lesson that it is in fact based on another work. We surely aren't getting rid of credits to the original author and editors. I really like the idea of tightly compressing these cross-lesson links like you propose here, but I don't like the idea of concealing the context behind the authorship of our lessons. Without some indication of which of the lesson versions is the one that Alex Brey himself first wrote, I think we do that.

@jenniferisasi
Copy link
Contributor

jenniferisasi commented May 6, 2020

Like @amsichani pointed out, the de-prioritization will occur only in the landing page in a banner and not at large, for that would devalue the labor of the original author, which is not our intention at all. In principle, the metadata shown on the image doesn't change. In there, we indicate that the lesson they are seeing is a translation with all the tags that say 'translated/translation', the author's name is still there under the title. @mdlincoln what you are saying is that you think that is not sufficient?

The good news is that, if we agree we want to show in the banner the authorial first, the word "original" is the same in all our current languages. The banner thus could be:

  1. In the original lesson En español | En français | Em português (whatever combination)
  2. In the translated lesson Original in English | En français | Em português
    [That would require a call like 'when a translation, put the word 'original' followed by lang.of.original+right preposition]

Do you like that better?

Just noting too that when one views the original, on the metadata only the original data shows (I don't know how else to put it).

@mdlincoln
Copy link
Contributor

sure, or

Available in: EN | ES (original) | FR | PT | XYZ

to keep the very tight display

@mdlincoln
Copy link
Contributor

Just noting too that when one views the original, on the metadata only the original data shows (I don't know how else to put it).

yeah, because that's the metadata for the particular page you're viewing

@amsichani
Copy link
Contributor Author

amsichani commented May 20, 2020

Sorry for the delay - I am now working on this together with #1525 and I am aiming to close the ticket in the next days.
Thanks @jenniferisasi @mdlincoln for your comments on this.
I think we have a consensus that the information about a lesson's history is to be kept in the metadata and in the header of the lesson and

We surely aren't getting rid of credits to the original author and editors

and in any case we won't

concealing the context behind the authorship of our lessons.

Let me reformulating the rationale behind this decision : what we are proposing here is more of a layout change on the multiple banners and their content and NOT on the display tab of the data regarding author/translator/ editor/ etc , ie the history/genealogy of the lesson.
We will thus create a unique banner out of the current two banners for original and translation in the landing page. I think this visual change is a wise movement especially as we are getting bigger as a project with multiple publications , and so compressing these cross-lesson links in the banner would be more user-friendly.

I think @mdlincoln 's suggestion for one banner

Available in: EN | ES (original) | FR | PT | XYZ

makes sense.

In terms of tech implementation now, my question is:

  • are we going to include all available versions of the lesson in the banner, including the version of each landing page , in other words is the banner going to be the same in all lesson's versions or are we going to include the versions minus the landing page's version?

I am happy to create a PR and try how things will look like, also in relation to #1525 (I will create a different PR for this, I guess).

@mdlincoln
Copy link
Contributor

Great, look forward to seeing the PR

@mdlincoln
Copy link
Contributor

I would like you to submit a PR for this before our mid-June tech team meeting. If you need help to meet that deadline, please ask now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants