Page MenuHomePhabricator

Improve editable vs. non-editable text box design
Open, Needs TriagePublic

Description

In https://www.mediawiki.org/wiki/Topic:Vp2o8we64u6zvbyf another user get's confused because they don't realize what they are looking at are editable text areas. This is not the first time I see users being confused about exactly the same. It appears like some users don't realize at all they can click anywhere and start editing. Instead they are confronted with UI elements and messages that don't make any sense, because they talk about an interaction that is (from the users perspective) not there.

Example screenshot:

Issues visible in the screenshot:

  • Only a few boxes have a scrollbar, depending on the amount of text and the window size.
  • Only a few box have a resize handle in the lower right corner.
  • Some boxes are gray, but this does not mean the can not be edited.
  • Some boxes are dimmed. But this is hard to see, and it's not obvious what the difference is between being dimmed and being gray.
  • Especially note how the left and right side appear almost identical, even if only 1 of the two can be edited.
  • There is currently zero (!) difference between an editable box that does have the focus, and one that doesn't. The only visible difference is the text cursor – which is tiny.

I remember us trying to improve this already as part of T251494: Confusing scrollbar & resize handle placement in no-JS mode (patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TwoColConflict/+/592633).

More ideas:

  • Try to give all textareas an outline or box-shadow. For example, here in Phabricator all input fields do have a thin gray border and a blue shadow when focussed.
  • Play around with a focus effect, e.g. the focussed textarea gets a much stronger outline (instead of the light yellow/blue).
  • Play around with some light gray background colors.
  • Make it so that the scrollbar is always visible.
  • Try to re-position the scrollbar so it always touches the yellow/blue box, and the box appears more like it is the edge of an editable field.
  • Make it so that the x button is not visible, unless there is actually an edit to undo.
  • Check if and when we start in edit-mode, without the user clicking a pen button.
  • Make sure the design of a box in edit mode is clearly different from a non-editable box (i.e. don't rely on the text cursor, which might not even be there when the box doesn't have the focus).

My personal preference:

  • Always show the scrollbar when a box is editable.
  • Let the scrollbar touch the box at the top and bottom (i.e. remove the small gap – note we already do this in no-JS mode).
  • Add some focus effect, e.g. the yellow/blue border becomes black.

Event Timeline

Restricted Application added a project: Design. · View Herald TranscriptJun 30 2020, 9:31 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Hey @thiemowmde - thanks for the detailed review.

First, the confused user was on the talk page interface but I see how some of their feedback is certainly applicable to the two-column layout too (such as the check mark and "X" in the editable textbox).

Second, I also agree there is room for improvement and think some of your suggestions might help with clarity. I think it makes more sense to do this though after the feature has been in small default for some time and we have all the collected feedback and can re-analyze it together, in a wholistic way. I think when something is new it can be hard to separate the between what is not working well and what is confusing simply because it is so drastically different from the old design. In this case, it's a huge change and we should give some time for adjustment too.

Demian added a subscriber: Demian.Jul 3 2020, 1:23 PM

@ecohen I think you make a good point about the value of feedback in understanding how well a design works, but I'd like to note that first impressions matter much more than second impressions, therefore I'd like to back @thiemowmde in considering a few changes. I think he's written an extensive list of possible changes to have a choice and implementing just a few simple adjustments would make the product much better received.

From a UX aspect I see there's a very noticeable need to make this UI more self-explanatory and to add more contrast to the colors and highlights. I've had similar impression with page diffs and fundamentally revised their design. While that design has different needs and the same solutions are not applicable here, I'd like to show it to get an impression how much some simple changes matter.


As this is not a diff, the colors don't apply here, but a very light background color might for the other version / my version part.

Demian added a comment.EditedJul 3 2020, 1:24 PM

To get back to Thiemo's ideas:

  • Try to give all textareas an outline or box-shadow. For example, here in Phabricator all input fields do have a thin gray border and a blue shadow when focussed.

I strongly support this. A box-shadow is just one rule and adds a lot to the comprehensibility of a page's structure and to recognizing the important elements. This would beyond all doubts give depth to the UI.

I'd add that changing the width or contrast of the emphasized left border could also help differentiate the different boxes.

  • Play around with a focus effect, e.g. the focussed textarea gets a much stronger outline (instead of the light yellow/blue).

Adding a blueish color to the focused box-shadow is just a 2nd rule. Note that the border color of the "Your version" box is almost exactly the same as Chrome<=82's focus ring color. The change to black in Chrome 83 necessitated T245887, which set the focus color to a darker shade chosen in WMUI (#36c). That darker blue would be a perfect fit.

  • Play around with some light gray background colors.

I see how this can be an opinionated choice and reasonable to give more thought to it. I personally would add a very subtle background to all 3 different area.

  • Try to re-position the scrollbar so it always touches the yellow/blue box, and the box appears more like it is the edge of an editable field.

I think this is basic. Scrollbars don't fit in with other designs. Inside a bordered area, but not attached to the border it gives a sense of disorder, lost structure and confusion.
Without touching the top and bottom borders, I'd say this is unfinished. Touching the right border seems to be in conflict with the intended positioning of the buttons, but I would consider moving the buttons to the left of the scrollbar. This might be non-trivial to implement, but with the mis-positioned resize corners I think this is important too.

Demian added a comment.EditedJul 3 2020, 1:25 PM
  • Make it so that the x button is not visible, unless there is actually an edit to undo.

That's important. I'd make it half opaque though to show there's a functionality which is not active atm. That's helpful in understanding the behavior of the UI.

  • Make sure the design of a box in edit mode is clearly different from a non-editable box (i.e. don't rely on the text cursor, which might not even be there when the box doesn't have the focus).

After 10 minutes I'm still thinking which boxes are editable on the screenshot. In the end I found that the resize icon is the most reliable sign of an editable box. This might be exciting for people who like to play Sherlock Holmes, but for the general user it might be a cognitive burden.
Gray colors and background are commonly used to convey the meaning of inactive/disabled elements. I think the non-editable boxes should have that background, not the common (non-conflicting) sections. This is also a simple change that's truly worth doing soon.

Closing thought

After a thorough analysis I think Thiemo's suggestions express very well some common sense requirements about this UI. I strongly suggest implementing these, it can make the difference between another product that has a memory of "Could have been great" and "This one hit the spot". It's always worth to take the last 5% of the journey, the biggest rewards come at the finish line.

Other than these design aspects this tool is really helpful and a much needed improvement to our toolkit. The developer team did a great job and with a few finishing touches they can make it awesome.