Community
Participate
Working Groups
The plan item bug #106199 calls for API to support required field indicators for text fields, as well as completion proposal support. Now that this support has been implemented, the question is whether we should be using required field indicators in the SDK. org.eclipse.jface.fieldassist provides a DecoratedField, allowing applications to specify an image that appears in one of four positions around the field. An optional hover can be used to describe the condition represented by the decoration. If Eclipse is to use required field indicators, then the question is what style (colored fields, decorated fields).
Attaching a field assist example that demonstrates how the DecoratedField API can be used to control the appearance of required fields. It provides a preference page for controlling the visuals for required fields as well as a simple dialog that uses the preferences. To run it, launch a workbench and then: - go to Window>Preferences>FieldAssistExample - under Required Fields, you can choose "Use Color," "Use Decorator," or "No Indicator" - if you choose "Use Decorator", you can also control whether the decorator shows at all times or only when the control has focus. - note that in this example, the required field indicator is different than the error indicator. You can also use the preferences to choose how errors are shown (decorator or status text or both). Note that the visuals in this example are quite ugly, the idea is to demonstrate that various forms of required field emphasis and indication are possible.
cc'ing those involved in discussing this topic in bug #106199. Note there is no milestone assigned to providing required field indication in the SDK. The commitment for 3.2 was to provide the support.
Required fields (when there is not content) could be marked with a red squiggle underline running accross the entire field. This would be the same type of error indication as the one that exists in Java editor. In fact, the absence on any text in the required field is an error, and so this marking is appropriate. The line goes away as user starts typing.
Note to self: See PDE manifest editor/Extension Element Details for their use of required field indicators and possible use cases for content proposals (class name, etc).
Created attachment 31702 [details] Field Assist Example JAR sorry, I never attached the example to this bug report. Here it is.
Created attachment 31734 [details] Mockup dialog with required fileds marked
I apologize for butting in but why would no content be an error? I normally think of an error as being something that the user has done wrong and in the case of a required field being unfulfilled I don't see this as an error. All the user did was open the dialog/form, they didn't do anything wrong. Also red as an indicator is alarming. Again, the user hasn't done anything wrong and when presented with anything red this will normally force the user to step back for a second and would take them out of the flow of the page. A common way this has been solved on the web is an asterisk next to the label and at times a yellow background for the unfulfilled field. In my opinion this is a less obtrusive way to present to the user that a field is required and is currently unfulfilled without alarming them to a condition that they just haven't attended to yet. Also by saying the unfulfilled status of a control is an error it could be confusing to the end user when a validation error did occur if the same metaphor was used to convey both states. Just my 2 cents...
All valid points. However, perhaps we should not take cues solely from Web design. There are supported operating systems, none of which offer notions such as asterisks and yellow background (some applications do, and this is ugly, imho, because it differs from standard user experience implemented by the OS). On the other hand, Eclipse already provides a way to indicate that something is wrong with a data in a widget. Why to invent yet another one? Java Editor has red (for error), yellow (for warning) squiggle lines. The empty value in a required field IS an error if you were allowed to continue. This is why there are messages with error icon at the top, and the buttons are disabled at the bottom.
Nick Edgar asked in bug #106199 (and I've moved it here...) Susan, is the current solution accessible? Some forms (e.g. PDE manifest editor) currently use '*' in labels to indicate required fields. These are correctly read by screen readers. If we move to a graphical decoration, this information will be lost to screen readers unless we do something to augment it.
I'm not sure. I don't like the mockup. It's not very sexy or eye-catching. I even tend to say it looks ugly. :( BTW, Nick made a good point in bug 106199 comment 51 about accessibility.
Good point, Nick. I didn't even think about accessibility in the decorations implementation, and it's an important consideration. Note that use of field color or squiggles has the same issue. I'd have to learn more about what is typically done, perhaps something analogous to alt text. cc'ing Tod who knows more about these issues...
One more comment re: accessibility. There's nothing that says decorations are used by all apps for required fields. We tried to be agnostic about whether an empty field is error, warning, not indicated at all, and whether color, decoration, are used. So one could argue that the semantic layer that defines which fields are required and how to show it, would have to keep accessibility in mind and possibly alter the field text when needed. On the other hand...decorations themselves are meant as a cue, and as we start using them more frequently, what do we do about accessibility? For example, we use them for the content assist light bulb, which is not communicated via a screen reader. So that is one argument for a generic solution. For example, each decoration does have descriptive text which is shown in a text hover. Perhaps decorations could be configured to show the text for the decoration at all times when configured thusly...? If this seems like a good idea to you all, I'll open a separate bug for that feature on decorations.
Using squiggly lines is visually disturbing. I favor the asteriks solution. It's a well-known idiom in web applications and is already used in PDE editors. Also we would not be color dependant = good for visually impaired users. The only problem I see for implementors I see is getting the dialog layouts right, i.e. text field alignment.
Any widget can have an accessible listener added to it to give information to assistive technologies only. This is hw we make a Canvas accessibile.
(cc'ing Karice who is taking over accessibility from Tod) I don't think showing the descriptive text all the time would help. Screen readers generally only read the label of the control that has focus (or the preceding label if the control doesn't have its own). Either we need to allow the decoration to take focus, or we need to somehow augment the accessibility info for the field having the decoration (or its preceding label).
Tod and/or Karice - do you know if these assistive technologies traverse the widget containment hierarchy in order to get the info? If so, then I could ensure the labels that represent the decorations (as well as their enclosing form) respond accordingly with appropriate text. Decorations are implemented as labels attached around the field being decorated, so no new API is needed. If instead these technologies explicitly traverse some declared set of widgets, then I'd have to make the internal implementation of decorations as labels known in some way.
Just collided with Nick's remarks - if it's a focus issue, then yes, we could try augmenting the field's accessibility info when it has focus.
Try not to rely on containment - it tends to change from prodcut to product unless it is a really reliable relationship like label-> text or label -> button
Hello all; I've been following this and the other related bugs with the intention of putting together design proposals. Given the amount of discussion around mandatory fields in particular, I'll jump in now with some ideas. I realize there are variations not covered, but am open to pushing any "what if" situations people have. For now, please consider the following thoughts and designs: From a visual design and accessibility point of view, the primary goals of the designs shown are to: 1 - Minimize clutter 2 - Use more than one cue so that the information on the field is accessible, i.e., both shape, or character, and color. (+ text on decorator in focus, if possible) As I understand it, the single cues that need to be represented are: 1 - Mandatory field 2 - Content assist 3 - Error associated with field 4 - Dirty field These might also need to be shown in combination, such as: 1 - Mandatory + Content assist 2 - Mandatory + Error 3 - Mandatory + Error + Dirty This first pass of images shows an approach for Mandatory and Content assist, where they needn't be shown on a field at the same time. I will look at "errors" and "dirty" in a separate pass. As to whether mandatory fields should show on fields with content, there are two camps: Show mandatory field markers regardless of whether field is filled or empty. Show mandatory field markers only when fields are empty. I would advocate the second option, where feedback on the fields is dynamic not persistent, and is therefore less cluttered than option 1. Using asterisks to show Mandatory fields: I've used asterisks to show mandatory because that is a conventional symbol used in context with the field. See image "task-assist_fields_proposed-1.jpg". Because it is conventional to use asterisks in this way, in context, I don't think there will be a clash with how asterisks are used to show that an editor, for example, is dirty. The challenge comes when you need to show both 'mandatory' and 'dirty' fields. Solutions for dirty might include: a different fill color than pale yellow or red, a different decorator, a message at the top of the form, dialog or wizard that indicates there are dirty fields in the body. I think this needs to be explored visually as well, but want to put out designs for mandatory to start. An alternative to the asterisk could be text inside the field. To keep this from looking to busy, I would recommend using a medium grey for the text, as shown in "task-assist_fields_proposed-2.jpg". Attachments to follow.
Created attachment 31763 [details] Current New Class wizard for comparison
Created attachment 31764 [details] Proposed 1 - Mandatory field indication Descriptive text within image.
Created attachment 31765 [details] Proposed 2 - Mandatory field indication Descriptive text within image.
Created attachment 31772 [details] screenshot of dialog with cross-field validation error Kim, the package name is not actually required. It is recommended, which is why we need to display a warning. I would like to draw your attention to another aspect: As you can see in the attached screenshot, there are cases where validation errors use more than one field in the dialog, i.e. the error is not attributable to a single input field - make a change in any of the fields folder/package/name to correct the problem. It seems that in this case, using the status area at the top would be more appropriate than decorating all three fields with an error icon.
Created attachment 32046 [details] Proposed 3 - Mandatory field indication Boris, Thanks for the clarification on package name not being required. Pardon my error. Because of the warning, it seems to be required. Looking at the new class wizard again, the required fields appear to be: - Source folder - Name If a field is 'required', then why not show that it is required rather than showing an error? Errors are better used for input issues rather than for required fields the user has not yet touched. I am interested in hearing back from people on what they think of representing required fields, only when empty, by either a combination of asterisk and pale yellow field colour, or by a combination of grey "Required" text and pale yellow field colour. Regarding validation errors, it does make sense to use one message at the top than error markers on each field if by changing one field you resolve all. That's a nice clean approach, though I can also imagine some folks would want to know exactly where the errors are, even if one field change fixed all. There might also be cases where each field has it's own distinct error to be corrected and, albeit potentially cluttered, seeing an error marker for each field would help users target the problems quickly. Going into vacation mode now :-) Will pick up on this in the new year. Cheers, Kim
Kim, this looks nice. My comments are: 1. I like the reinforcement of the yellow background together with the '*' indicator for required field, but to me the yellow means 'required but not yet filled in' whereas '*' simply means 'required'. So removing the yellow when the field gains focus is OK, but I find it strange to remove the '*'. Whether the field has focus or not, it is still required. IMO, the user should be able to scan all fields and determine which ones are required, without being affected by a focus-driven mode. 2. I think the 'Required' text adds too much visual noise, even if it's muted using grey. 3. For per-field vs. overall error reporting, I'm not sure what the best approach is. I agree that having more locality is good, but as Boris pointed out there is often cross-field validation being done. I think we should experiment with different presentations here for field-local validation errors, vs. overall validation errors.
Kim, the Proposed 1 and Proposed 3 mockups look great. And I completely agree with Nick's comment 25. Regarding error validation, I think we will always need the old possibility of "global" errors for the whole dialog. Nevertheless, it would be nice if there was a standard way to add an error message to a single field if that is possible from an application logic point of view (e.g. for syntax errors in a name field). This could e.g. be a small error icon at the place of the asterisk, and the error message could be shown either as a hover message like the "Content Assist Available" or in the wizard title area when the field has focus.
Thanks Nick and Markus for your feedback. Keeping the asterisk but removing the colour fill, once the field is filled in, sounds like the way to go. I have usability colleagues who agree with this as well. An additional aesthetic recommendation I would make is to not use black for the asterisk, but a grey or grey-blue so it is not so harsh looking, particularly when in multiple. Is an image required for this, or can a text character be used? I'll provide an image if needed. The attached images to follow: "type-exists-all-marked" and "task-assist_fields_proposed-4" attempt to address both local and overall validation as Nick suggests in comment #25. They likely don't fully capture the different levels of validation, so I welcome guidance by way of screen captures that will assist with the fidelity of this exploration. Thanks Boris for providing the "type-assists" example in comment #23. I also looked at Size, Style to some degree, and Location alternatives, and followed Markus's suggestion in comment #26 to use a hover message, something I see in the M4 New & Noteworthy is already supported. See attached images: "decorator-gridsheet-error" and "decorator-gridsheet-warn" for these studies. I've included some annotations on the far right for guidance. 'B', 'C', 'D', and 'J' seem to work the best. 'A' also works, but I think it works best when there is no asterisk, i.e., on fields that don't require input, rather than overlapping the asterisk on required fields. To achieve consistency, a possibility is to create a condition for placement that goes something like: - Place error marker above asterisk on left on required fields. - Place error marker in lower-right on fields that are not required. - Place Content Assist marker in upper-left. (I noticed in the M4 New & Noteworthy that the Content Assist bulb is on the lower-left of the field instead of the upper-left.) 'B' in the images shows the placement of all markers on the left. This left-side approach has a couple of advantages: 1. All decorators on one side are easy to spot; you don't have to discover them in different places. 2. Alignment of the right side of the fields can remain flush. Adding a decorator to the right of one field means you either have uneven right alignment, or you shorten all fields to maintain alignment. Some comments on the additional cues shown: - Color text: This works okay with red, but is not legible enough for 'warning', where the text is gold. - Outline: This works alright, as in 'J', with a semi-transparent red overlay, not full opacity red. - Fill: I'm not crazy about the colour fill here because of the potential rainbow effect with the required field's pale yellow fill. I look forward to your feedback on the images and ideas shown.
Created attachment 33116 [details] Shows both local field- and dialog-level validation.
Created attachment 33117 [details] Proposed 4 - Mandatory field & error validation
Created attachment 33118 [details] Treatment studies for 'error' markers
Created attachment 33119 [details] Treatment studies for 'warning' markers
Created attachment 33121 [details] Proposed 4 - Mandatory field & error validation Replacing "Proposed 4 ..." with smaller, easier to view image.
Note that the versions with 3 stacked decorations on the left hand are hard to implement with the current DecoratedFields, since DecoratedField#addFieldDecoration(..) currently only allows TOP and BOTTOM as vertical positions. I guess it would be no problem to add CENTER later iff DecoratedField is not to be extended by clients. Solutions: - specify DecoratedField as not subclassable, or - add SWT.CENTER as an option, or - document that other positioning constants may be added later
I will do two of your suggestions: - specify DecoratedField as not subclassable, - document that other positioning constants may be added later (Side note: the original DecoratedField implementation/prototype in early M4 had CENTER as an option but I ended up removing it as being unnecessarily complex/busy. It's not hard to add this behavior back in but I'll let the dust settle on visuals before jumping to any more conclusions).
Created attachment 34441 [details] Using only 2 decorator positions on left of field Marcus, your suggestion in comment #26, if I read it correctly, is to replace or overlay the Required graphic with the Error indicator. After some further consideration, I think this could work. In addition to keeping DecoratedField as it is with only TOP and BOTTOM locations, the other advantages are: - Saves real estate - Can use same overlays for warning and error as used elsewhere, since no longer same size constraint - Less crowded than stacking three decorators on top of each other - Puts most important item on top (as complete overlay) - Is temporary, so does not overlay Required asterisk permanently See attached image: task-assist_fields_left.png
Question - is there a plan afoot to get these visuals in for 3.2? I haven't done any experiments for using the decorated field's composite to provide these colored borders. It's possible we'd need more nesting to accomplish this on all platforms. Side note - I have an example (currently unreleased) that uses decorated field, field colors, etc. to show errors, warnings, required fields, and content assist cue. It's my test bed right now for testing all these theories. I will try to update it after M5 and release it so you can try these different things out on the fly. The example has preferences that let you decide whether to use colors, decorations, or both to indicate different things.
I like Kim's last rendering - nice and clean. Kim, were you suggesting we change the border colours as well when there's an error or warning? This may be achievable when using UI Forms (which paints the borders itself), but not when using regular SWT widgets with SWT.BORDER style.
I don't think we should shy away from doing something for this for 3.2, we want to exercise it in the base, in fact it's pretty cool and our student is using decorators in his re-work of the error message area in wizards (i.e. title area dialogs). However I think what we should only do this for things that can remain self consistant (like Dani is doing for the Find/Replace dialog) and grow from there. Doing it for wizard contents is likely too late as we have to give more lead time so other wizard page owners can migrate etc... We also might want to take some time to abstract the concepts into FieldEditors etc... where developers can indicate they have a field that is required and Platform UI does the decorating consistantly (that would be API). So what can we do in 3.2? - SaveAs dialog - Switch workspace dialog - New Working Set Wizard dialog Team - cvs login dialog JDT - search dialog I'm open to suggestions...
I'm marking this M6 so that it doesn't get lost in my pile of unmarked bugs. I agree with mvm that it would be nice to try something tangible and get reactions/feedback, but not try to do too much.
I'm adding Martin as owner of the Search dialog.
Created attachment 34636 [details] Using only 2 decorators on left and fill color for error In response to comment #37 from Nick, I've shown a fill color instead of a stroke color on the field when it is in an error state. There is no fill in the Warning field because 1) it is less serious, and 2) the light yellow is reserved for Required field before filled. Question: Is posting the Required decorator and color specs here the prefered way, or is there another route to get this information to the folks doing the implementation?
posting here is the right answer Kim. Especially as this item involves a number of teams etc...
Created attachment 34818 [details] Required Field GIF image (In reply to comment #42) > posting here is the right answer Kim. Especially as this item involves a > number of teams etc... Thanks Michael. Required Field gif (reqd_fld.gif) attached here, and a blueprint for image alignment and field color (task-assist_fields_bp.png) attached below.
Created attachment 34819 [details] Blueprint (specs) for image alignment and field colour.
Looks good. Where's the example mentioned in Comment 36 in CVS? I could take a stab at one/some of the dialogs mentioned in Comment 38.
Re: field assist example. I haven't released it yet...that will happen first thing after the M5 flurry is over. I'll update it to use these visuals.
Hi,(In reply to comment #41) > Created an attachment (id=34636) [edit] > Using only 2 decorators on left and fill color for error > In response to comment #37 from Nick, I've shown a fill color instead of a > stroke color on the field when it is in an error state. There is no fill in the > Warning field because 1) it is less serious, and 2) the light yellow is > reserved for Required field before filled. > Question: Is posting the Required decorator and color specs here the prefered > way, or is there another route to get this information to the folks doing the > implementation Hi-- What about required field markings for widgets like checkboxes or radio buttons? Mary Trombley HF Engineer for Rational Data Architect mtrombl@us.ibm.com
I'm no visual designer, but I assume: - A checkbox is either on or off, so there's no way to leave it "blank" and therefore no need to show that it's required. - Radio buttons are configured so that there is always a choice selected. However if there is a desire for a visual, the implementation would allow it, since it can go around any arbitrary control. A decorated field could be created for a checkbox. For radios, which one would you show as "required?". All of them?
Good point. I should have been more general-- are there any fields besides text fields that would need the decoration? Thanks!
(In reply to comment #49) > Good point. I should have been more general-- are there any fields besides > text fields that would need the decoration? Thanks! I mean widgets, of course. Not fields.
Sure: Combo, List, Spinner
I have just installed Eclipse 3.2M5 release, and the field assist example doesn't work. The decorated fields don't appear anymore. (I was using it with M4 release and it was ok).
You probably have an out of date example. There were definitely changes during M5. I'm working on getting an up-to-date sample in the builds (see bug #128720). In the meantime I'll post the latest to bug # 120173.
Kim, can you attach gif files for the correctly-sized images for the warning and error indicators?
Sebastian, what is the use case for decorating a list?
Created attachment 35094 [details] Error decorator (In reply to comment #54) > Kim, can you attach gif files for the correctly-sized images for the warning > and error indicators? Sure. Here is the error decorator. Warning to follow.
Created attachment 35095 [details] Warning decorator
Any selection could be mandatory. Depending of the number of items and whether 0,1 of n, 1 of n, m of n one could use: Check buttons Radio buttons List Combo Table/Tree w/ SWT.CHECK
Kim (and others) - I have just released the field assist example plug-in into CVS. Please see org.eclipse.ui.examples.fieldassist It uses the current visuals you've proposed and computes the indicator color as follows: - unfilled required field without focus - system info background color - field with error - color computed from JFaceColors.getErrorText() The pref page on the example lets you control whether to use colors, decorators, or both. By default, all indicators are on. To invoke the sample dialog, choose FieldAssist>Open Field Assist Dialog... from the action bar.
The example looks good Susan. Thank you.
Now that the support for the indicator look from Kim is implemented, it's time to introduce it in some dialogs. The most reasonable one to me seems to be the search dialog, as it's not clear what's required in each case. I've opened bug #131002 to track this. The other dialogs previously suggested by MVM in comment #38 (SaveAs, Switch workspace, New working set wizard, CVS login) don't seem to need it, as they either have only one field, or all are required. I could add emphasis here for future consistency, but I don't think it adds much information. Anyone have other suggestions?
Created attachment 36572 [details] standard description for required fields The "*" should have a hover.
I thought there was discussion that there would be no hover for required fields, but I'm not sure about this. I specifically left it out. I'll defer to Kim on this one...
Uninformed users might wonder what the * means hence the "tooltip".
Susan, I suggest providing standard "Required Field" hover text, but allow it to be customized to show more specific information. Regarding single field dialogs in comment #61, I agree it is odd to show required in these instances but it makes sense to treat all required fields the same.
Updated the decoration for required fields to include the hover message, available >20060321. Per Kim's comments, I'll start showing required field indicators in the simpler dialogs just to get the ball rolling.
Updated the SwitchWorkspaceDialog and the ResourceWorkingSetPage in the NewWorkingSetWizard to show required field emphasis. Available >20060323. The ResourceWorkingSetPage does bring up some layout issues for which we should establish guidelines early on, in particular what to do when the text field label is above the text box. Kim - I will attach a screenshot. I aligned the text and listbox controls, but left the labels above in their original location. Do you think this is appropriate and if not, could you provide some guidance on how to handle layout in this case?
Created attachment 36829 [details] screen shot of required field with label above note the text and list are aligned to leave space for required field indication on text. but the the labels are left in original location, causing an indented look.
I've also added required field emphasis in the ResourceAndContainerGroup and ContainerSelectionGroup. This means required field emphasis will show up in the following wizards/dialogs: SaveAs NewFile NewFolder ContainerSelectionDialog I will stop for now and wait for feedback. See also bug #133044 - we need to decide whether the old error status messages for required fields should stay in these dialogs.
moving to 3.2 RC1. Initial support is in for community feedback and we will determine during RC1 cycle what we want to do for 3.2
fyi, we are getting some feedback in bug #133529.
(Tracking full discussion) MVM, Susan, Jin, and I met to discuss the best resolution for 3.2. We addressed the following questions: What should we do in 3.2 across the board that is consistent? What can we do that doesn't destabilize Eclipse? - anything that affects layout is a problem Solutions: Add colour to fields, combos, spinners, text (don't deal with right now with tables and lists because there are default selections) - colour always present whether it has content or not - 15% yellow on top of existing background, unless it is a high contrast theme (Todd has code to detect) - keep errors at top as is - need accessibility hook to tell screen readers that it is required (post 3.2) Issues (with colour approach on high contrast themes): - schemes where foreground and background are not different enough - detect high contrast and don't do anything special (Todd has code for this) - forward James's code for detecting contrast betw fore- and background to Susan in case useful Future: - reconsider colour always being present - consider doing anything fancier than colour only - add accessibility hooks - consider action text in field + colour: issue as noted below - a lot of dialogs out there that will not know about this text, that will be looking for empty fields Possible solution is to draw <Required> over top of field so that field is still detected as empty. When to colour them? - (yes) have to do it in the SDK - (yes) if only one required field, then don't show required colour - (no) if all required, then don't show required colour - how does user know? - can't move forward, or show error at top once user interacts with a field - (yes) keep pages simple, mark required fields - (yes) provide default content where possible .................................... Notes from meeting leading to above: visual issues *asterisk* - ugly - distracting - layout issues - indentation - location issues - clutters dialog *colour* - when to use? other issues - are the sdk dialogs really a good use case for dialogs - are we reacting because we are not used to it implementation discussion - making space in dialogs possible solutions: 1. action text in field + colour No - a lot of dialogs out there that will not know about this text, that will be looking for empty fields Future though, draw <Required> over top of field so that field is still detected as empty 2. asterisk on right No - jin says should be available at one quick glance; have seen usability issues with this in past 3. asterisk beside label - dedicated column? (label above box, label beside box) No - too much of a layout change 4. use colour only - need accessibility hook to tell screen readers that it is required accessibility: used to say at top that this field cannot be empty errors: currently we show error only when you interact with dialog, you don't enter in an error state because you cannot
Removing the milestone from this bug. Required field emphasis will be revisited in 3.3. our short term plans for 3.2 are still open and being discussed in bug #133529.
assigning milestone. let's try again for 3.3!
(In reply to comment #74) > assigning milestone. let's try again for 3.3! Great. I visited the Zurich lab on Friday - here is why JDT UI is still using their own support for decorated fields: There are still some problems with the current support that stops JDT UI from doing this: - layouting: clients need to change their current layout to make space for the decorator - no support for cell editors ==> Markus will work with Susan on this one
The layouting issues are handled in bug 124873.
Yes, I'd like to keep implementation issues out of this bug and focus here on the actual visuals for required fields. Per comment #72, there were issues beyond layout that need to be resolved at the design level first. Various implementation issues are tracked in #124873, #144703, #145622, with the bottom line being that legacy dialog and framework owners want to be able to install a decoration on a field without changing layout or creation sequence.
Susan, I'm onboard to pick up this work again. Are there any issues that need to be solved, such as layout, before we can get started?
Let's get started... The implementation of decorated field has issues that make it hard to align decorated/non-decorated fields in existing dialogs. You can assume I will fix those in some acceptable way, so any objections should be focused on the use of decorations in general, their look, usability, etc., not the current layout pains. The only other implementation assumption I have at this point is that decorations are located in any/all of the four corners of the field (top right, bottom right, top left, bottom left). We can change this if needed, but I like this as a starting point. I also like the approach of designing with required field, error, warning (and any others that have come up) in mind so that we know these things look good together.
> so any objections should be focused on the use of >decorations in general, their look, usability, etc., not the current layout >pains. What I don't like in the current (R3.2) solution which is using background color to indicate required input is that it is already visible when the dialog or wizard comes up initially.
Using a color to indicate a required field does not look aesthetically pleasing in PDE editors. Take a look at the attachment in bug 141640 comment 12
I'd also like to see a better solution than using the background color. I should have been clearer - comment 80 applies to all solutions.
Here is another though. The current implementation requires layout changes by adding the decorators outside the field. Wouldn't it be possible to place/overlay the decorators inside the field bounds so that all fields still have the same size?
I apologize if I am repeating somebody else's ideas here, but would not it be possible to manipulate preceding label instead of the field itself? For example, you could automatically (or not) attach an asterisk to the label (which is what is often done in web forms, so people look for these), then you could change color of the label, a tooltip, and even add or remove icons (error or warning) if it is CLabel, which is capable of displaying both icon and text. The APIs can change so they take CLabel as one of the arguments -- this would give people some flexibility on deciding which label corresponds to the field. No broken layouts, easy to migrate existing code. Just a thought.
Hi, Alex. Putting the indicator on the label is one of the suggestions, and in fact PDE uses this technique in its forms. The "layout pains" issue is a more general problem with DecoratedFields. Even if not used for required fields, they are used for content assist indication and may be used for other visuals. The goal for 3.3 is to try to look at the different techniques used for required fields in Eclipse, native platforms, and other products and come up with a unified design that also works well with fields showing content assist, errors, etc. This bug will get updated when there are new proposals.
I've just digested this entire discussion thread (wow!). Is background colour still "on the table"? I think background colour to indicate "required" is unnecessary. All that is required is a small hint to tell the user why "OK" isn't enabled. Furthermore, once a user learns a particular page, they understand what data is required. Thus from a design point of view I feel the indication approach must remain subtle; enough to convey that the field is special but also easely visually ignored. I'd be careful drawing analogies to web pages because the dynamics are different: with web forms, "Submit" is typically always enabled, thus "requirendess" must be shouted a bit louder in order to avoid having to return the user to the web form for further input. Plus, often such pages are visited infrequently and so no learning can take place. I am very concerned about use of field background colour in general due to clashes with whatever colour scheme the user has. Additionally, when many fields have background colour, the aesthetics of the page is hurt.
> Is background colour still "on the table"? It's currently used in some dialogs and wizards in R3.2 and current 3.3. And like many others I also don't like it, see comment 80.
I would say everything is on the table for 3.3, we are sorting through use cases in Eclipse and other products to try to find a good answer for required fields that works well with other indicators needed (error, content assist, warnings, dirty indicators, etc.) Color was an easy-to-do experiment for 3.2, but it has its problems. Look for this discussion to move soon to a wiki where it will be easier to post suggestions and have a discussion...we'll post here when there's some new news.
Created attachment 52207 [details] PDF that describes the usage of decorators
Created attachment 52208 [details] PDF that describes the usage of decorators
Comment on attachment 52208 [details] PDF that describes the usage of decorators I prepared a PDF to describe the usage of the decorators from a UCD perspective. Feel free to review my thoughts ;-)
A brief update for those watching this bug: We are still iterating ideas for required field emphasis (as well as error and warning decorators), and there are no commitments yet as to what will be done in the SDK. That said, the field assist decoration support was updated to address some major issues, and as part of that work I modified the field assist example so that there are now two example dialogs. ExampleDialog uses DecoratedField and the stacked decorators discussed in the 3.2 timeframe. ExampleDialog2 uses the new ControlDecoration, and modifies the visuals in these ways: - it uses the "*" after the label approach instead of a decorator to show required field emphasis - it uses the same position for the content assist, error, and warning cues, placed in the center of the field. I've had discussions in bug reports and elsewhere with folks copying the support in the field assist example to use these techniques in their own apps. So I've modified the example in order to communicate some of the latest ideas, but please bear in mind that any particular design appearing in the field assist example is a snapshot in time, and a test bed for the code, and is not a guarantee of what will actually happen in the SDK.
fyi, the latest visual design proposal for required fields, errors, and warnings is now posted on the eclipse wiki. That is probably the best place to further discuss this issue. http://wiki.eclipse.org/index.php/Field_Decorators_and_Validation Comment #92 in this bug still applies...the latest example and field assist code will support most of these ideas, but there is no commitment that the SDK will migrate to use these techniques in any particular timeframe.
If its ok with everyone I would like to close this bug. The standard is now that required fields should use an asterisk after the label, rather than support via the field decorators mechanism. That's what the wiki page linked in comment #93 shows. I'm not sure if there's any more discussion to be had in this bug. We still have FieldDecorationRegistry.DEC_REQUIRED though. Not sure if much value in deprecating although a comment saying to use asterisk would help.
I think this bug also represented the work to actually use the indicators in the Eclipse IDE, which we do not do consistently. Not sure if we should have one generic bug or open bugs against different components....
(In reply to comment #95) > I think this bug also represented the work to actually use the indicators in > the Eclipse IDE, which we do not do consistently. Not sure if we should have > one generic bug or open bugs against different components.... Yeah I was figuring we'd open a new one for tracking just that. To that end I opened bug #237372 as a tracking bug and opened bugs for Platform UI, PDE, JDT, and P2. Please feel free to add your own as blockers to #237372.
