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

[Plans] User plan presentation and explanation #51

Open
3 of 5 tasks
danieleguido opened this issue Nov 7, 2024 · 3 comments
Open
3 of 5 tasks

[Plans] User plan presentation and explanation #51

danieleguido opened this issue Nov 7, 2024 · 3 comments
Assignees

Comments

@danieleguido
Copy link
Contributor

danieleguido commented Nov 7, 2024

[ME wrap up] Following our discussion a while ago, the remaining steps regarding the presentation and documentation of user plans are:

  • revision of the file Impresso User Plans v2 (in /06-interface.../Impresso-Interfaces-Homepage)@e-maud
  • integration of revised table in frontend @danieleguido
  • production of the "corpus access catalogue" json file to list which title is available under what conditions and with which user plan. @piconti and @e-maud => see here
  • integration of the corpus access catalogue in user plans @danieleguido
  • writing of a few related FAQ @e-maud for first draft

In the future we will have one entry point to user plan and registration from the astro project website, but now keeping this on the two app separately.

@e-maud e-maud changed the title [Plans] Presenting how we present permissions [Plans] User plan presentation and explanation Dec 4, 2024
@e-maud
Copy link
Member

e-maud commented Dec 13, 2024

Hello @danieleguido, also pinging @mduering and @piconti (sorry I forgot to add you on the issue when updating)

Many thanks for bringing online the Corpus catalogue!

Below are a few suggestions for improvement and discussion.

But first here is an excerpt of the catalogue that was built and a screenshot of its current display, to have them close for the discussion

  {
        "data_partner_institution": "SNL",
        "media_alias": "DVF",
        "media_title": "Der Volksfreund",
        "time_period": "1879-1885",
        "media": "Newspaper",
        "medium": "print",
        "copyright_or_copyright_status": "Public Domain",
        "permitted_use": "Personal, Research and Educational",
        "minimum_user_plan_required_to_explore_in_the_webapp": "Guest User Plan",
        "minimum_user_plan_required_to_export_transcripts": "Basic User Plan",
        "minimum_user_plan_required_to_export_illustration": "Basic User Plan",
        "partner_bitmap_index": 5
    }

image

(1) About the objective

The objective of this table is primarily to give people the possibility to understand what is available under what condition (1), which is different from stating what a particular (logged in) user can access (2). For (1), the headers and values of the following properties should be reflected in the table independently from any specific user permissions.:

"minimum_user_plan_required_to_explore_in_the_webapp": "Guest User Plan",
"minimum_user_plan_required_to_export_transcripts": "Basic User Plan",
"minimum_user_plan_required_to_export_illustration": "Basic User Plan",

The display of personalised access possibilities (2) was not meant to be in this table, but it could be a useful addition if space allows. My initial idea was that users would encounter access error messages while browsing the app or API (e.g. "To see this source you need to have xxx user plan"). This is another corner of the story that I would leave out of this table, or add it on top (e.g. as a toggle feature, switching from plain access view to personalised access view). However, the table’s primary objective remains providing clear information on corpus accessibility conditions and permitted uses, independent of the user’s individual status.

(2) Terminology corpus / dataset

In our context, what we are showing here is the corpus, not datasets. This terminology is often a floating and context-relative one... A CH institution that have many many many collections would name a release of a specific newspaper a 'dataset' (in relation to all the rest). On our side, we curate various collections to build a corpus, from which (research) datasets can be composed. This curation aspect relates to the selection of what archival items are present, which composes more a corpus than a dataset (to me...) Beside, there is also the degree of preparation: Once we start working on it it becomes more data/datasets. Oxford definition can also be handy "data set: a collection of related sets of information that is composed of separate elements but can be manipulated as a unit by a computer"

Sorry for this lengthy explanation. In brief, the idea is that a corpus represents a curated collection of archival items, reflecting intentional selection and aggregation, different from a dataset, more related to structured, process-ready data typically used in computational tasks.

I would suggest to use (Impresso) corpus consistently across the User Plans (it was intentionally used there), related documentation, and web site pages.

(3) Page title

  • Dataset Availability by Plan -> Impresso Corpus Overview: Data Accessibility and Usage Permissions

  • Subtitle:
    Explore a wide range of datasets featuring newspapers and radio content, each associated with its permitted use. This table allows you to find the resources you need for your research. You can view which datasets are available under your current subscription plan and identify those that can be unlocked with an upgrade. If you’re not logged in, please log in or register to see your available datasets. To learn more about the various plans available through your university enrollment, visit the Plans page. -> The Impresso Corpus features newspaper titles and radio broadcasts from various cultural heritage institutions. This table outlines its composition, detailing data accessibility (required user plans) and permitted uses.

  • URL: dataset -> corpus

(4) Table composition

  • As suggested above, the last three columns should display the minimum required user plan.

  • Copyright Status and Permitted Uses should be into distinct columns. Together with the required user plan, this is important info this table intends to convey, and users should easily differentiate / read them. Alternatively, their mention in the cell should be prefixed with "Permitted uses: xxx".

  • If there is not enough space for many columns, the Media property is more important than Medium. I would suggest to put Media (newspaper / radio) as a column and have the Medium (print/typscript/etc) under the record description (currently in Title).

(5) Table headers

  • Period -> Time period
  • Title -> Media title
  • Please login to check data availability according to your plan -> Please log in to view data accessibility conditions based on your plan. (in relation with the toggle feature mentioned in (1) above)

(6) Cell values

  • Is it possible to display time periods with an hyphen: 1738 2018 -> 1738-2018 ? (as in the json)

@danieleguido
Copy link
Contributor Author

Thank you @maud! Here is a better version, in the last column I would add a small sentence below the copyright that could sum up the availability for the current user (e.g. only available in the app or similar) Screenshot 2024-12-16 at 12 28 21

@piconti
Copy link
Member

piconti commented Dec 16, 2024

Looks great, just warning, seems like there is a type "please log in to [...]"

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

No branches or pull requests

4 participants