Account created on 5 December 2007, about 16 years ago
#

Merge Requests

Recent comments

🇫🇮Finland simohell

One more thing about showing/hiding content:
Since the decorative image does not have an alt text it might be a good idea to hide the default alt-text as well as the override field. In my opinion it would be better express the effect of marking an image decorative.

🇫🇮Finland simohell

I commented the issue on long text summary https://www.drupal.org/project/drupal/issues/1562776#comment-15427067 🐛 Edit Summary label is unclear to users Active

🇫🇮Finland simohell

We discussed this issue at the usability meeting 📌 Drupal Usability Meeting 2024-02-02 Active where we agreed that a simple text change is not a sufficient improvement. At the meeting were present @benjifisher @shaal @ simohell @worldlinemine @duncancm and @rkoller.

We came up with a suggestion to

  1. wrap summary and full text into a fieldset
    (we noted that fieldset stlyles may be too sublte for proper accessibility, but that is another issue)
  2. use field name as the label for the fieldset
  3. label text areas as summary and full text

Summary and trimmed are terms that are used by field display add teaser is a standard view mode that implements displaying the summary and/or trimmed version.

Full text is referenced by the summary description but not present at form.

If we don't want to have the summary field always displayed, we can place it inside a details element. On content creation the details element should be open. On my opinion editing content it should be closed to save space if no summary text was added and open if a summary text was added.

🇫🇮Finland simohell

This issue is important but has changed a lot over the years.

With Drupal 11 and several versions before that we can have had several fields in the same node with a summary each. The teaser metafore is no longer present. However I see that the label "Summary" is not properly connected to it's "parent" field whenever the summary is not closed. Having an option to close the summary also seems to be theme dependant.

This seems to be an accessibility issue as well as in at least some situation the user might not know wether the summary above or directly below the long text field is the on that summarises that specific field.

I guess the Summary label should always have some reference to the main field label.

I would expect this issue belongs to field_ui but is also relevant for a number of themes.

Attaching screenshots from Olivero and Claro.



🇫🇮Finland simohell

Hi, Issue 📌 Field selection breaks conventions and increases cognitive load Needs review changes the type selection from radio buttons to links that are displayed as a grid.

Will this patch work with that version as well?

🇫🇮Finland simohell

Hi, I'm setting this as "won't fix". It will be fixed when 📌 Field selection breaks conventions and increases cognitive load Needs review is completed. That issue changes the field type selection from radio buttons to links and has already passed usability review.

🇫🇮Finland simohell

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-01-05 Active . That issue will have a link to a recording of the meeting.

For the record, the attendees at today's usability meeting were @AaronMcHale, @benjifisher, @emma-horrell @rkoller, @shaal and @simohell.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

The MR addresses the main points of the issue. Visual presentation has been improved. Some of the usability problems present in the current MR are being addressed by other issues and seen as out of scope for this issue. Keyboard navigation was tested roughly and the MR improves it's usability.

This issue would benefit from separate accessibility review.

Requested change

A small change request is to make description texts in both form steps visually consistent. At selecting the field type description is smaller that the label and in a dark grey colour. Selecting the option for field type uses same style for both the option text and the description. It is recommended to use same styles for text in both steps: larger text for label/option and a bit smaller maybe dark grey for description (like in the first step).

🇫🇮Finland simohell

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2023-11-24 Needs work and 📌 Drupal Usability Meeting 2023-12-01 Needs work . Each issue will have a link to a recording of the meeting.

For the record, the attendees at today's usability meeting were @AaronMcHale, @anushrikumari, @benjifisher, @ckrina, @rkoller, @simohell and @worldlinemine.

We recommend using compact text for easier reading. The context will allow short text for options.

    Images exceeding maximum dimensions
  • Resize proportionally
  • Reject

We were of the opinion it would make sense to swap places for maximum dimensions and minimum dimensions so that minimum setting is first. This will help the new resize setting to stand out better in it's context as well as make the commonly used minimum setting slightly more prominent. If this is difficult to include in this issue, it's ok to make this a follow up issue to be done later.

We also thought it worthwhile to consider using a fieldset for the "Images exceeding maximum dimensions" in similar manner to how /admin/config/development/settings shows the detailed options under the first checkbox when checked. It's ok to make this a follow up issue to be done later.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

🇫🇮Finland simohell

There are still some text changes coming from the usability meeting, I was on sick leave for a few days and failed to follow up. Sorry.

🇫🇮Finland simohell

@keszthelyi it's a bit hidden, but you can get the patch directly from the MR clicking the text "plain diff"'

🇫🇮Finland simohell

Regarding #240 there is widespread patterns of having the "show password" styled as a link. For instance USWDS
https://designsystem.digital.gov/templates/authentication-pages/sign-in - that should be accessible.
But I do see the problem with having an actual link close by...

🇫🇮Finland simohell

Dropped testing for the attribute that got removed.

🇫🇮Finland simohell

The latest screenshot shows help text that is outdated since field label update was about a week ago.

We might also consider to make the text a bit shorter.

- The options are mostly self explanatory, clear without help text.
- EXIF is a bit of excess detail. Usually if a person has use of EXIF there is already knowledge of how it behaves - I assume.
- If we want to give techincal info maybe link to image settings page where compression percentage. We could explain EXIF part there.
- Text could clarify that the resize method is scaling proportionally, not resizing to both dimesions.

🇫🇮Finland simohell

It looks like the fix for current core layout was simpler than I thought.
I managed to test this right, all that was needed was setting a minimun value for main column:
not grid-template-columns: 3fr minmax(22.5rem, 1fr);
but instead grid-template-columns: minmax(0, 3fr) minmax(22.5rem, 1fr);

I have implemented that fix as a merge request in the other related issue 🐛 Long string breaks the layout of Claro Needs review .

🇫🇮Finland simohell

It looks like the fix for current core layout was simpler than I thought.
I managed to test this right, all that was needed was setting a minimun value for main column:
not grid-template-columns: 3fr minmax(22.5rem, 1fr);
but instead grid-template-columns: minmax(0, 3fr) minmax(22.5rem, 1fr);

🇫🇮Finland simohell

W3C's "HTML and XHTML Techniques for WCAG 2.0" has an example code for using a-tag without an href attribute and without text content (so obviously invisible to sighted users) - but it does not discuss presentation in case there would be some text. An h-tag linked from an a with href in that document is not styled differently from other headings though. This feels like a contradiction to what is said in #23.
https://www.w3.org/TR/WCAG20-TECHS/html.html#H86-ex2

There is a case of links without hrefs though. It is possible to have an <a role="link">text</a> or more commonly an image or a span. Semantic HTML is however considered best practise.

I could bring this up during tomorrows accessibility office hours if somebody else doesn't want to do it.

🇫🇮Finland simohell

If the issue exists all the way to the latest dev we fix it there and then bring the fix from there to the other versions as well.

🇫🇮Finland simohell

Adding screenshots from different versions in different sizes.
One is narrow, second is about FullHD, third is about full 27" 1440p monitor.

🇫🇮Finland simohell

I think we have currently 3 options:
- fill the vieport width with form
- set maximum width and center form
- set maximum width and center main columns, fix side column to side of the window

(additional note: how does this work with RTL-languages?)

I will update screenshots with Umami demo-content in a while to give better comparison of actual use case.

🇫🇮Finland simohell

@amanire This latest version seem to work and also fixes 🐛 Long string breaks the layout of Claro Needs review

It might be a bit better to double the gap and allow side bar to grow a bit more in a larger screen, but that needs maybe a bit more eyes to decide. This fixes the bugs is good enough I think for now. I like having the sidebar stay in the middle but that is a bit bigger change to the current version so I hope to hear what @ckrina thinks.

I tagged this for usability review and hope to have this in the meeting next Friday.

I also added your screenshots and a new one with some clipping taking place.

Maybe also update the text description?

🇫🇮Finland simohell

Ah. But it's not a regression by this issue, so this would be improvement as such. I noticed that you updated the other MR so I'll check that one and compare results. This one fixes one single bug, the other one maybe more. Changing only one thing was an idea to get it merged quickly but let's see.

🇫🇮Finland simohell

The current MR does not add any hard-coded widths, so maybe you are testing an older commit?

width: 100%;
max-width: 52rem;

Perhaps the old CSS is cached in your setup. Or you have some custom plugin or forced CSS that overlaps here.

With an extremely long string the width may increase for Firefox and Safari but without the change the whole form is pushed away from viewport. Current dev branch does have certain viewport widths where some browsers clip the sidebar a bit, but that is not caused by this MR.

🇫🇮Finland simohell

Ok. I updated the CSS so, that this fix does not create regression to Firefox and Safari.

Firefox and Safari continue to have certain clipping in some viewport widths, but not more than with the current production version. FF and Safari both also benefit from this fix even if other add/edit form layout issues still affect those browser.

I think this small fix is ready to be merged and the other browser specific issues could be handled in 🐛 Layout Issues with Claro theme Needs work .

🇫🇮Finland simohell

Testing this MR I see that the main column expands without limit.
Expanding a text area without a limit harm usability on large screens.
Studies show that optimal width is around 45-75 characters/line.

The solution in #3400762 was chosen as the only change it was supposed to make was fixing the bug, but unfortunately it was not tested on all browsers and some browsers render it in a way that was not intended.

I think we need to find the CSS to keep the form in a usable width while making the form keep from breaking up.

I'll try to tag @ckrina in Slack on this to check if there how much space there is to iterate on the layout or just to fix the actual bugs.

🇫🇮Finland simohell

The bug mentioned in comment #37 will be fixed in 🐛 Long string breaks the layout of Claro Needs review  with a minimal CSS change.
The patch here deals with the piece of CSS, so it would make sense to recheck this issue against that code.

🇫🇮Finland simohell

I updated the 3 tests for word "dimensions".

I had deliberately left out changing the "high-resolution" part since it makes sense if read according to for instance Adobe's definition
"High resolution images are pictures or photos where the media has higher concentrations of pixels or dots, resulting in better quality and clarity of the image – as it contains more detail."

A number of end users deal with high-resolution photographs and the help-text would make sense to them. In the past the industry used terms like "press quality", "print quality" or "web quality" and here press & print would be high-resolution and web quality low-resolution. The help text communicates that Drupal handles original high-resolution photos just fine.

🇫🇮Finland simohell

Functionality not changed since previous review

🇫🇮Finland simohell

Quite right. Missed that one, but now it should be ready.

🇫🇮Finland simohell

The patch changes the UX significantly for large screen and is out of scope for this issue. Very wide textareas are usually considered bad UX.
I working on this at the moment at Helsinki contrib event and my current goal is to fix the bug without changing the layout as a whole.

🇫🇮Finland simohell

I can confirm this bug on Drupal 10.2 alpha1, testing with Umami.
Pasting a very long string, the body-field moves right almost completely outside viewport.
Uploading a video to demonstrate. I will test the patch against dev branch.

🇫🇮Finland simohell

There is actually also an existing setting content type / vocabulary. For "An example would be updating an existing site to have multi-lingual content, but not wanting to enable additional languages yet." one would just fix the language appropriately for the content and uncheck the box "Show language selector on create and edit pages".

I am a little bit confused in which real world scenario this proposed code change would really be useful compared to existing configuration. I wonder if there is something I'm missing from the problem description? I'm looking at this from node/term perspective. I didn't check where else this would affect the site.

Having intentionally enabled translation, decided to show the widget but then use code to hide the widget feels a bit odd a combination. When one enables translation there is already decision wether or not to allow selecting the language.

A couple of lines of code isn't much and doesn't slow down the system so that it could be noticed by the human eye and uses hardly any extra electricity, but it is still a bit extra to save a few clicks on edge cases. Current version supports also starting to allow languages gradually but just not site wide change with a single click. Then again the change would usually go to production via CI/CD pipeline in configuration yamls.

But it's not a big deal, I guess.

🇫🇮Finland simohell

Ah. There appears to be a suggestion to fix this on localize.drupal.org already https://localize.drupal.org/translate/languages/es/translate?project=dru...

Will be fixed when that one is processed.

🇫🇮Finland simohell

There are a few different points of view to this, especially if single language is only a temporary phase.
- Having less information on the form vs. having the form change.
- The same effect could be achieved by not showing the language selector on the form. It may be confusing if site builder adds the language selection to the form but this does not appear.
- There may be modules that restrict languages per user (maybe Allowed Languages does this) or some other use cases where language information is useful to have even if only one option.

I would go with a softer approach by making this configurable and on by default. We already have a setting for including "Not specified" and "Not applicable".

Current:

New version:

🇫🇮Finland simohell

Thanks and sorry I was online only for a short time. I checked the Miro and added a couple short notes.

🇫🇮Finland simohell

I made updates to comments and user interface changing the word resolution to dimensions where relevant.
This does not change wording where referencing Drupal 6 terms (migration).
Does not update any variables and that would be a follow-up issue.

🇫🇮Finland simohell

This issue is still very much valid and came up in the last Usability meeting 📌 Drupal Usability Meeting 2023-10-27 RTBC as we reviewed an issue on resizing image. This should be done everywhere: replace incorrect "resolution" with the correct "dimensions" especially for all user facing texts.

I wonder of this could be split to 2 issues to provide the first easier fix faster?

  1. Fix the user facing text
  2. Change the variable names and other related code

I removed some of the tags that listed old events.

🇫🇮Finland simohell

We discussed this issue at 📌 Drupal Usability Meeting 2023-10-27 RTBC . That issue will have a link to a recording of the meeting.

For better usability we suggest making the setting a radio button that has options:
- resize larger images
- reject larger images with error message

Such a list of option would also allow extending via contrib modules.

Then information about resizing should be removed from the description of the dimensions fields.

For the record, the attendees at the usability meeting were @AaronMcHale, @anmolgoyal74, @benjifisher, @rkoller, @shaal, @simohell, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

🇫🇮Finland simohell

This is expected to be fixed by https://www.drupal.org/project/drupal/issues/3386762 Use modals in field creation and field edit flow Needs work

🇫🇮Finland simohell

@laurii suggested this on Slack and I'm happy to have a go with this one
https://www.drupal.org/project/drupal/issues/3325551 Add "Disable image resize" setting to image fields Needs review

🇫🇮Finland simohell

This jumped in on my search as "active" - so for clarity I'll close this as outdated as the last activity was 12+ years ago.
We have made good progress since.

🇫🇮Finland simohell

@donquixote In user testing Boolean didn't got low percentages for grouping so it might be hard to find in any group. I'll tag you in Slack to the thread where the results are visualised. Single item groups were noted as special cases on Friday by the UX meeting but they probably need to be handled under the "Modal" child issue.

Personally I would like to test many-to-many groupings but maybe not now that we are working against a minor release deadline.

🇫🇮Finland simohell

I did a survey on cloning content recently (you can find it from the DrupalCon Lille recordings soonish, or already now if you attended) and I think this is very important in order not to accidentally publish something unfinished. This is especially important for multilingual content.

🇫🇮Finland simohell

I did a survey on cloning content recently (you can find it from the DrupalCon Lille recordings soonish, or already now if you attended) and my question on redirect is: which language version? If this goes to module this is fairly important question for multilingual.

Also this goes hand-in-hand with alerting user if the entity (or with multilingual entities) was already published as the form view somewhat suggest that it is still in creation phase.

🇫🇮Finland simohell

Proposed solution for task #4
1. make radio buttons for options visually distinct from the buttons in type selection phase. Then navigation difference is understandable.
2. use USWDS as a reference for usable radio buttons: only single column of radio buttons, aligned in a single vertical line, add some margin before additional descriptions

Visibility of options on the screen is not affected comparing single column and 2 column versions. Cognitive accessibility/usability is reduced by 2 column layout.

2 column layout can result in lines of text so short they are hard to read. Usually literature recommends to have 45 to 75 characters by line. Single column layout may result in a 85 character line but not usually.

Comparison of the single and 2 column versions:

To be done elsewhere:

Additional text should be reviewed and unneccessery text removed.

Some modal scaling issues appear, but this is reported against core JS and will be fixed via getting rid of some jquery ui stuff, so it is out of scope.

🇫🇮Finland simohell

I have been categorising field types and options and I have one major recommendation:

Rename "Selection list" to "Predefined values" with the term "value" is debatable - options, list...

Reasoning: selection refers to a widget, predefined implies that the options for these field can be hard to edit later.
The counterpart of "prefined" would be "free" - but renaming "text" to "free text" might be excessive even if it would define difference to fe. link (which is special case of text) quite well.

🇫🇮Finland simohell

@webengr we can use
https://github.com/mglaman/composer-drupal-lenient to allow composer to install older versions in order to pach them.

🇫🇮Finland simohell

Changes to the 11.x-dev field creation
https://www.drupal.org/project/drupal/issues/3389200 📌 Field selection breaks conventions and increases cognitive load Needs review

🇫🇮Finland simohell

Here is a rough example how to use proximity to connect type and options (the extra large "boolean" is an unintended side product)

Production build https://api.contrib.social 0.61.6-2-g546bc20