Edit work > Visibility panel text duplicated, confused

[atz]

The text is confused.

• Repeats itself
• Links to SHERPA/RoMEO twice
• "Rare books/Atlas" is interjected, possibly from a bad search/replace on "work"? Like, if you have cured cancer, you're fine, but let's have a word of warning if you've got a rare atlas there...

• Lease datepicker is missing "until" to identify what the relationship is w/ the date

  

[ggeisler]

This is somewhat tangential, but I've never been a fan of all of this text (beyond the basic option text) in the first place. It, combined with the colored labels, make the panel very busy and feel more complicated than it actually is.

I wonder if we could just hide the warning text behind a tooltip (icon next to the option text that when clicked on reveals a tooltip with the existing (corrected) text)?

The warning text could be shortened into a more compact form without losing meaning by removing the "Please" and parenthetical bits and putting the bullets into the sentence directly.

Thoughts @mjgiarlo @hannahfrost?

[hannahfrost]

@atz Thanks for this ticket. Note that the Hyku demo doesn't exhibit the problem with injecting the resource type in the "open access" level description (it just says "work")

@ggeisler Yes I too have been looking forward to trimming this text and de-cluttering the experience. A tooltip would certainly help.

[mjgiarlo]

I'm cool with making changes to the design here that simplify things. Thoughts, @projecthydra-labs/hyrax-ui-ux-advisors ?

[atz]

I agree with Gary that the text has always been problematically formatted and problematically complex.

[ggeisler]

Mockups for alternative way to present text associated with Visibility options:

Simplify options area by moving help text into tooltips

Open access tooltip activated

Institution tooltip activated

Private tooltip activated

[jcoyne]

I recall there being an effort to remove tooltips from sufia last year because they were not good for accessibility. Are you sure we want to go back to that?

[ggeisler]

There are ways to make tooltips more accessible: http://paypal.github.io/bootstrap-accessibility-plugin/demo_3.1.1.html#tooltips

But if there was a deliberate effort to remove them previously, it doesn't seem like a great idea to add them back in. That would've been good for me to know before I spent time doing these mockups. My original suggestion was to use tooltips and this ticket was put into design needed so I wasn't aware of any previous move away from tooltips.

An alternative could be to use the approach currently in place for the Open Access button, where, when it is selected a div expands to show more text. We could just do that for all three relevant radio buttons, so that when unselected they look like the first mockup above (without the icon), which visually simplifies the form. When one of the three relevant radio buttons is selected, a div expands to show the text that is shown (in the tooltip) in the mockups above. That way, at least the text only ever shows for one option at a time, which will keep things less cluttered.

This approach would still enable showing all the Open Access text at once in the div, edited to match what I show in the mockup above. That would eliminate the redundant text problem @atz noted in his original comment on this ticket.

That all assumes the whole expand a div when a radio button is selected is accessible, but since it's there and you previously removed things that weren't accessible, I'll assume it is.

[front-endian]

For context about the previous tooltip accessibility change: though it is possible to make custom tooltips accessible for screenreaders, user research on other projects has shown that they are problematic for a surprising number of users. In testing on a number of applications some users were confused when part of the interface was obfuscated by a tooltip and either couldn't figure out how to get rid of it, or wouldn't notice that there was additional information below it which they weren't seeing.

The last time I worked on this rights section on a Sufia instance we ended up going with a single short chunk of help text that described all the items. With careful editing that was enough and it promoted simpler help text. When needed we would add a link to a dedicated help page for more details.

If that can't work here, expanding help text when a radio button is selected could be made accessible with the proper ARIA attributes and some usage testing. There should also be some text that is always visible to say something like, "Select an item to see a description of that option."

[hannahfrost]

I am in favor of reducing the text on the settings panel, moving the longer explanatory text to a static page, perhaps with a configurable content block if people want to adjust the language?

For brief descriptions of each visibility level, how about the following:

Open Access - Make available to all Institution - Restrict access to [institution] <- a variable showing value entered in "Institution name" on Labels configuration page Embargo - Set date for future release Lease - Set date for future reduced access Private - Keep to myself with option to share

[newmanld]

+1 to @hannahfrost suggestions. At Cincinnati we have a longer ‘Creator’s Rights’ page that we have linked to from input forms, and are likely to expand on a static page and adjust/customize this block anyway. Removing unnecessary text and having a longer static page would be well received.

Side point - we have an unresolved discussion at Cincinnati about the appropriateness of the ‘Open Access’ label, since we allow content submitters to create content that they mark as open access but do not assign a Creative Commons or Public Domain license to, and instead simply claim ‘All Rights Reserved.’ (We separate ‘Visibility’ from ‘Rights’.) Some have pointed out that if the Rights are “All Rights Reserved” then the work is not truly open access. However, the term ‘Public’ doesn’t work as well as a label throughout the UI. So I like the brief explanation from @hannahfrost that in this context ‘Open Access’ means “Make Available to All.”

[ggeisler]

@hannahfrost Below are some mockups illustrating how your text updates would look.

(I'm not sure "read more" is the most enticing label for the link but can't come up with anything better at the moment.)

Example 1 - new text, otherwise the same

Example 2 - new text but putting text on new line

The potential benefit is it reduces chances that the option text will wrap when the user doesn't have a wide viewport (most of the option text in Example 1 will wrap on all but the widest viewport, which looks somewhat ugly).

Example 3 - new text on new line, removing label styling

The potential benefit is same as Example 2 but also calms the visual appearance by reducing the colored blocks (which do have some value in reinforcing the visibility levels, but perhaps not enough to justify the visual clutter they add).

[elrayle]

If we are going to use the color tags on show pages to indicate visibility, then I would prefer to see it maintained in this dialog in order to reinforce the visual recognition of the state at a glance.

I have a preference for the description being on the same line in order to reduce the height of the dialog, but it's not strong enough for me to fight for it. It also reads well for me, but that may be a personal preference.

VOTING for Example 1

[newmanld]

+1 to @elrayle's comments about maintaining color tags for visual consistency with other places in the UI. I also think the colors are intuitive and make it easier to read (assuming an Accessibility check of colors and contrast has already been done.)

+1 to shorter descriptions

Hard to choose between Example 1 and Example 2. Example 2 has more height but also less width, and as @hannahfrost commented will be less likely to wrap. Slight preference for Example 2, but would leave choice of Example 1 and Example 2 up to implementors, in case there are issues with greater height and the floating nature of this dialogue. Or possibly adjust display based on viewport.

[ggeisler]

FWIW: I don't think the height difference in Examples 1 and 2 should be a factor in deciding which approach to go with. Example 1 is with a 1200px wide viewport while the next two examples are at a width less than 1200px (i.e, the widths shown in the screenshots are just based on browser width; there is not inherent width difference between them). If I made a screenshot of Example 1 at the same widths as the other two examples, I believe the text for at least 4 of the 5 options will wrap, making the height effectively the same as the other examples.

I think the decision should be based on readability and ease of quickly scanning the options, not on how much vertical space the panel takes on the page.

[mtribone]

We did some overrides for contrast of the default colors from Bootstrap to meet AA requirements in ScholarSphere if you need 'em.

https://github.com/psu-stewardship/scholarsphere/blob/2.x-stable/app/assets/stylesheets/scholarsphere/typography.scss#L32

[newmanld]

@ggeisler - good point about height changing with smaller viewport anyway. The point @hannahfrost made about wrapping being somewhat ugly may support seeing Example 2 as more readable.

[ggeisler]

@newmanld Yes, that was actually my comment and that was my meaning. I don't think Example 1 is the most readable even when it doesn't wrap (because of the ragged left-edge of the descriptive text parts) and when the text wraps it is pretty unattractive, in my opinion.

[hannahfrost]

I'm good with Example 2!

[newmanld]

Is Example 2 the decision?

[hannahfrost]

@newmanld I think so!

[hannahfrost]

@ggeisler Can you please post a revised mockup of Example 2 where the label "Open Access" is replaced with the label "Public"? This request is based on feedback received via other channels. "Open Access" carries meaning that is less generic than "Public". I (and others) advocate that Hyrax should provide a label that does not assume or imply that an adopting institution has an open access policy.

[jcoyne]

@hannahfrost I believe @mjgiarlo already changed the text to "Public" last week.

[ggeisler]

I like the change; @mjgiarlo did you in fact already change this, and if so, is it changed throughout the application?

This panel that is the subject of this ticket is not the only place where the term/label "Open Access" is used, so I just want to make sure it's been addressed globally, otherwise we should probably make a ticket to do that.

[mjgiarlo]

There are a couple of stragglers that I am cleaning up right now, @ggeisler. Hyku will pick these changes up soon after we get Joe's PR (that fixes file attachment) merged.

[hannahfrost]

Barring any further discussion, @ggeisler and I think this ticket is ready to be worked on. The consensus here is to implement Example 2 shown above (with the notable change that the "Open Access" label is now "Public").

[atz]

@hannahfrost, @ggeisler: Collection edit > Visibility tab (e.g. http://localhost:3000/collections/w9505044z/edit?locale=en#visibility) already looks minimal:

What are we doing with that?

[ggeisler]

This ticket is about the tab on the Work page. Are you asking about how the visibility tab is handled on the Collection page?

If so, the Collections Extensions sprints started yesterday and I don't think our team should do anything related to collections in the next month unless they're doing so as part of that sprint effort (else there is possibility of stepping on toes/duplicate work).

[atz]

Freshly generated engine_cart instance, why can't I upload works to a collection? This the result of clicking "Add works":

EDIT: ok, needed to do:

rake hyrax:default_admin_set:create hyrax:workflow:load && rails generate hyrax:work Work

[atz]

Yeah, I'm asking about all the places this same functionality is exposed. They are all over the place instead of consistent. Here's the file level page, possibly the ugliest of them all:

• Alignment and styling issues everywhere. Why are 3 paragraphs bold? With subject headings that are blended right in? Then a heading that isn't bolded.
• Floating grey X is detached from the rest of the design
• Why are the embargo/lease options still presented auto-expanded and misaligned like were 18 months ago?
• Again, does the explanatory text matter or not? If it matters for the Work, then it matters for the File and even moreso it matters for the Collection.

[atz]

@ggeisler: please clarify whether the "Public" explanatory text that displays when selected should be removed. Also please specify what path the "read more" link is targeting. It seems like something that does not exist yet.

I am disinclined to create an entire new controller just to display a new page of what is effectively a single html chunk from i18n, but if I do, it certainly won't be hardcoded to hyrax.visiblity.open.warning_html.

[ggeisler]

@atz I noted the many problems with the File Edit page in previous tickets; there is an existing ticket that includes mockups proposing ways to improve that page: https://github.com/samvera/hyrax/issues/942

The explanatory text aspect of the current ticket was only briefly touched on in all the earlier discussion above, so I'm not sure there is a consensus on what the community wants to do with that. I don't have the impression that we agreed to remove it entirely.

At a minimum the text needs cleaned up to eliminate duplicated wording. So if you don't want to create a new page as a target for the "read more" link I'd suggest leaving the same expand-on-selection behavior but update the text to something like this:

Be aware that when you assign "Public" visibility to a work this might be viewed as publishing the work. This could impact your ability to:

• Patent your work • Publish your work in a journal

Check out SHERPA/RoMEO for more information about publisher copyright policies.

I personally like @newmanld's suggestion about creating a static page as the target for the "read more" link (with the assumption this page would eventually be used for other similar explanatory text or help). If you wanted to go that route maybe we could just start with a static page called "Creator's Rights" to follow the U. of Cincinnati example (eventually we might rename and adjust how that page is edited/used). So the "read more" link would end up pointing to a page like this:

Perhaps @hannahfrost @mjgiarlo or others have opinions on this.

[atz]

@ggeisler thx for your response and the link to #942. Quick question about the expanded lease/embargo sections: which of the following is correct (if any)?

Do we want the picker sections flush with the left edge of the badge or indented? My preference is the former (also "Available for public" sounds clunky and a missing "until"), but I don't feel strongly about it.

Note: The "static page" described would not really be static since it would still have to support i18n.

[ggeisler]

@atz Yeah I agree that the alignment of the Embargo example is better.

Seems like the Lease text should read:

Is available to Public until [date]

[bnhowell]

Just wanted to chime in with some alternatives for UX/UI patterns around embargo. I'm working on embargo options for Deep Blue Data and found this inspiration for embargo design in Figshare helpful as I made design mockups for our deposit process. I'm trying to use accordion dropdowns for a desired option rather than radio buttons with all the additional options always showing.

Figshare example: [image: Inline image 1]

Deep Blue Data embargo designs: (Attached files)

Best, Ben

On Wed, Aug 9, 2017 at 4:35 PM, Gary Geisler notifications@github.com wrote:

@atz https://github.com/atz Yeah I agree that the alignment of the Embargo example is better.

Seems like the Lease text should read:

Is available to Public until [date]

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/samvera/hyrax/issues/1030#issuecomment-321374044, or mute the thread https://github.com/notifications/unsubscribe-auth/AQBqv7sgcUvtEpv8t-s7v3x-7_1B4tiuks5sWhgtgaJpZM4NkbHD .

-- Ben Howell | User Experience & Accessibility Specialist Design & Discovery | LIT | University of Michigan Library bnhowell@gmail.com

[ggeisler]

@bnhowell It doesn't look like your attached image or files made it to Github (unless there is something special going on with my browser).

The current UI around embargo/lease could certainly use improvement, but since this ticket involves more than just that part of the UI, and the particular embargo/lease pattern is used in multiple places, I wonder if it might be more helpful if you created a brand-new ticket along the lines of "Improve UI for presenting embargo/lease options" and make your suggestion there. That way we don't bog down this ticket considering new options (it's already been dragged out over several months) and if there is agreement on your suggestions in a new ticket that work could more clearly be directed to all relevant places in the app.

[bnhowell]

Sure thing @ggeisler. I'll create a separate ticket.