[MGNLUI-2471] Form field labels are incoherent and confusing when requiring more then one line. Created: 03/Dec/13  Updated: 11/Sep/15  Resolved: 07/Sep/15

Status: Closed
Project: Magnolia UI
Component/s: forms, user interaction
Affects Version/s: 5.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christopher Zimmermann Assignee: Unassigned
Resolution: Outdated Votes: 3
Labels: next, quickwin, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2013-12-03 at 11.20.58 AM.png    
Issue Links:
supersession
is superseded by MGNLUI-2750 Support multi-line labels in dialogs ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When the label for a form field is too wide, it wraps onto more then one row.
The problem is that the row spacing is so large that the text typically sits directly above the label for the next field.
In this case the wrapped text is closer to the next labels text - and so it appears to belong to the next fields label!

See attached screenshot of the Contact form from the demo features http://localhost:8081/magnolia-bundled-webapp/.magnolia/admincentral#app:pages:detail;/demo-features/special-templates/contact-form:edit

The 4th field label should be: Marker for Required Fields.
The 5th field label should be: Text for Required Symbol.
The 6th field label should be: Step-by-Step.



 Comments   
Comment by Andreas Weder [ 03/Dec/13 ]

The original idea of the left column was that it would be only as wide as needed to accommodate all labels plus a left and right padding. For slightly larger-than-usual labels, that column would just grow to accommodate them.

But,of course, that doesn't solve the problem here.

  • we could not grow the label column indefinitely, but would have to define a maximum width
  • a growing label column takes away space from the value column, which gets hurtful quickly in a fixed-width dialog layout.

So I would think that, in the current situation, a good solution might:

  • grow the left column maybe to a max of e.g. 220px
  • wrap the labels to multiple lines, with the first line being properly aligned with the first row of text in the value column

I'd like to actually add a feature for dialogs to grow in width as well. I don't want users to have to grow or shrink dialogs maually. Instead, I'd like to provide a toggle to make them go "full-screen". This would extend them to almost the full available width (minus a larger, dark padding, so that you could still identify them as a dialog sitting on top of something) and to as much height as needed to show all fields in a tab at once. I would also expect text areas and rich-text fields to grow in height and width as well so that editing them would become more comfortable.

Comment by Roman [ 04/Dec/13 ]

In 5.1 long names of labels look more broken and ugly. I can use short names but they make dialogs more uninformative. Is there another workaround to fix the problem?

Comment by Diana Racho [ 28/Jan/14 ]

A tooltip or a mouse over effect with the entire label would be helpful

Comment by Roman [ 04/Feb/14 ]

The workaround for me is using static fields between text boxes with empty labels and long values. Magnolia 5 tooltips look not user-friendly. In previous version they were better. You could read them without clicking.

Comment by Andreas Weder [ 07/Sep/15 ]

I'm linking this to a planned improvement to allow for multi-line labels again.

Comment by Andreas Weder [ 07/Sep/15 ]

Closing this as outdated - it doesn't accurately describe the current state any more. We shorten labels now, but we do so too eagerly (see UX-240) for the follow-up issue.

Generated at Mon Feb 12 08:56:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.