Bugzilla – Full Text Bug Listing
| Summary: | [plan item] Improve task assistance in text fields | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mike Wilson <Mike_Wilson> |
| Component: | UI | Assignee: | Susan McCourt <susan> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | alexberns, andre_weinand, bokowski, bradleyjames, christof_marti, daniel_megert, david_williams, djo, douglas.pollock, eclipse, gunnar, Karice_McIntyre, karsten, kelvinc, kieke, kpeter, lindawat, markus.kell.r, Michael.Valenta, michaelvanmeekeren, mkomor, mlists, morten-eclipse, n.a.edgar, sdavids, susan, Tod_Creasey, wassim.melhem |
| Version: | 3.1 | Keywords: | plan |
| Target Milestone: | 3.2 M4 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 120237, 120238 | ||
| Attachments: | |||
|
Description
Mike Wilson
Note that there's already code in Platform Text that offers code assist for the Text and Combo widget (in addition to text viewers). This is used to provide code assist in the File Search dialog, the Find/Replace dialog and several JDT UI wizards. This solution also offers - a yellow light bulb to indicate that assistance is available and how it can be invoked - an additional info popup which can be used to show more detailed information about the selected entry/value *** Bug 108952 has been marked as a duplicate of this bug. *** *** Bug 109062 has been marked as a duplicate of this bug. *** Additional info from bug #109062: From the UI summit: - Code assist in texts - *Owner* SF? - code is in JFace text right now - push down with forms - JDT draws indicators know - CVS uses content assist in dialogs Additional comments from mvm: Yes the idea is to have a generic popup (we should implement this and share it as part of the effort) and a generic Ctrl+Space support to drop down a specified list of completions. The other part of this is a text field that can indicate that it does have completions (or in the same vein, the text might indicate that it is a required field and not support completions). See also bug #72374 (generic info popup) Investigate during M3. I'm close to having a first cut on this one. Question for Dani - can you explain the use of USEVIRTUAL to use a virtual table everywhere but Motif? I assume this should be carried forward but would like to explain the issue in comments. The cause for this can be read in bug 98585 comment 36 ff and it boils down to bug bug 90321. I've added this comment to our code as well. Just a question on Comment 4 -- I read it as if either completion or required indication will be supported. I think both at the same time should be supported. Let's say you're writing an application for entering address data. You want to require the user to fill out the city field but have a content assist offering the cities previously entered. In an application I wrote a year ago I used the Text "Lightbulb" stuff and modified the background color and or foreground color of the text field. Yellow background -> needs entry White background/Red foreground -> erraneous entry White background/Black foreground -> acceptable entry Created attachment 28295 [details]
how it looked like
illegal "Vorname"; content assist invoked on required field "Nachname"
Thanks, Sebastian for the pics. Comment #4 does read as if it's either content assist or required, but I agree that they are not mutually exclusive. Since you've worked on this problem before, let me tell you what direction I'm moving in right now and if you (or anyone else watching this bug) have any suggestions, let me know. - "FieldAssistant" is installed on a field (currently working with text fields) - you can specify - that a field is required (which shows a visual cue - playing with colors right now, maybe borders) - an IContentProposalProvider for proposals (if none specified there is no content proposal). The light bulb indicates proposals available when field has focus (as with current Text implementation) - an IContentValidator to validate content (to be honest I haven't converted existing wizards or dialogs to see if this makes error checking cleaner, but it seems a good place to put that behavior) - a LabelProvider for showing the proposals - a simple proposal provider just specifies a list of objects - a filtering proposal provider filters the list (and can optimize accordingly) - presentation decisions are encapsulated in some policies. JFace could provide settings to help keep this consistent (location of proposal popup relative to the field, cue style, colors, etc.) My intention is to try to centralize the configurability by each client so that there is consistency, but I realize there are different needs - some content proposals are automatic (type-ahead styles) others are explicit (key binding) - proposals can have secondary popup (as with the text implementation today). cc'ing some other UI team members in case they have comments/suggestions The most common way to show a required field is by preceding it with an icon that looks like a small solid circle with a white exclamation mark overlayed on it. Is there a compelling reason to do something other than this? mcq, do you have a snapshot with the white circle + exclamation? I don't see any in Eclipse, just wondering what it looks like. Susan, it seems that there is potential overlap with the data binding framework that is being developed (bug 104570), in particular with regards to validation. I will contact you directly to talk about this. Haven't seen that "required" icon either. Several websites prefix text fields with * though (then there's usually a footnote along the lines "* this field is required") Here are some things I'd like to see: a) tooltip b) validator c) error indicator d) clue box e) content assist indicator "light bulb" f) content assistant with filtering g) required indicator h) instant propagation vs. lazy propagation Notes: "clue box" - "This little popup window looks and behaves just like a ToolTip [...] it explains the range of acceptable data [...] would appear as soon as the gizmo [widget] detects an invalid character." page 401 -- Cooper, Alan. 1995. _About Face: The Essentials of User Tnterface Design_. Foster City: IDG Books Worldwide, Inc. "instant propagation" - update of model as one types "lazy propagation" - update of model when one moves focus to another widget or presses special key sequence (this should be modifiable, e.g. Enter or Ctrl+Enter) in the widget "propagation" may be independent of validation. I think validation and model update are more in the data bindings area... but still valid needs, just wanted to say that we should be carefull not to solve the same problem in multiple places OR where it does make sense. oops.. .just read comment #13 from Boris *sigh*. I failed miserably to find a site that uses the icon I was talking about. Perhaps it was in the Mac registration dialog... I'll whip one up and attach it. In any case, it does seem that the most common pattern is to put a "*" beside the field and put "* this field is required" somewhere else in the page. That strategy is not ideal, of course, if we are talking about coding a stand-alone field. Maybe putting hover text to indicate it is a required field on the "*" itself? Aside: The other pattern that is quite common (but has crappy UI design) is to let the user type or not, then when they submit the form, refresh it with the field colored red and text that says "These fields must be filled in." Created attachment 28339 [details]
Example of a required field icon.
Just rolled a GIF with Photoshop Elements (i.e. it's not an ICON)
I did a quick pass on a few KDE/Qt and GNOME/GTK+ applications -- looking for such indicators. It seems that there is no consistent way of handling this information. Some disable the next button, and some just prompt with a dialog if the user can't advance. Some will modify a text label saying the entry is invalid, and some won't. Basically, anything we chose to do will not clash with the current Linux desktop. A side note: It is possible for wizards and dialogs to have required fields that are not text fields. There is risk of user confusion (especially in the "required field" use case) if the mechanism we choose cannot be applied to arbitrary SWT widgets. I see a layout problem with prefixing a widget with "*" or anything other -- same goes to our venerable light bulb :) One has to reserve space (in case it's a "regular" field) for it in order to not mess up the layout. In Eclipse lingo the "*" already has the meaning of unsaved changes. Colors have the following problem: "When information is presented by color alone, a person who is color blind misses that information." (http://www-306.ibm.com/able/access_ibm/disability.html ) "Some disable the next button, and some just prompt with a dialog if the user can't advance." This is bad UI. If I have a form (wizard) I want to be able to enter fields independently of another. One should not be able to complete the whole process (completing form/completing wizard) though if required fields contain erraneous data or a left blank. responding to today's comments in no particular order: - I agree validation is crossing into data-binding territory, and will talk to Boris about what they are doing. The main reason I considered it part of task assistance is thinking about whether field-based cues should be shown when there is an error. Propagation of values to a model (as Sebastian mentions) - is definitely data binding territory, and doesn't really fall into the category of task assist. I guess we need to define where the line is and who provides visuals for things like validation. - visuals for content assist (light bulb) and required field (*, colors, borders, the exclamation). I've been trying to wear two hats while working on this, JFace framework and the workbench. - JFace - should allow plug-ins (and RCP apps) to have lots of flexibility here. Platforms, accessibility, user prefs all affect what is appropriate. I've been looking at a "Field Decorator" that is a little like ILightweightLabelDecorator. The idea being, you would have a set of lightweight decoration techniques you could use such as: image next to the field (lefttop, leftbottom, righttop, rightbottom), set foreground color, set background color, set border...As mentioned, there are layout considerations with borders and images. Seems flexible, and then lets us easily say "Validation is not part of content assist per se" yet error status decorations could be overlayed or augmented by data binding if need be. Or is this overkill? - Workbench - would have a standard decorator (perhaps driven by preferences) for: content assist cue, required field cue, possibly an error cue. Each cue can likely have associated hover info, as discussed and as implemented in the JFace text stuff. If we have a light bulb for content assist, then do we want an exclamation (or *) for required? It gets crowded, which is why I looked at other techniques that web forms often use (like colors, borders). - Other (non-text) controls and "required field" indication. One assumption I've made is that you don't need to indicate a required field if there's always content. Many non-text controls have a default value (or selection) at all times, so I didn't focus on the need to show that they are required. We should consider things like a list with no selection, etc. cc'ing Michael Valenta since CVS has needs in this general area. Created attachment 28372 [details] mockup of wizard/dialog cluttered with task assistance icons (In reply to comment #22) > - Workbench - would have a standard decorator (perhaps driven by > preferences) for: content assist cue, required field cue, possibly an error > cue. Each cue can likely have associated hover info, as discussed and as > implemented in the JFace text stuff. If we have a light bulb for content > assist, then do we want an exclamation (or *) for required? It gets crowded, > which is why I looked at other techniques that web forms often use (like > colors, borders). Have you tried to make a mockup? I feel that the decorations will really clutter the whole UI. I tried making a mockup and I do have to say that it feels scary. (Mhm. Ok, I'm not good at mockups ;) But now, imaging a whole window filled with 20 text fields each with its own decoration. Brrrr. Personally, I prefere the current way, i.e. having a consitent status row in dialogs or wizards, which shows what's still missing or invalid. BTW, the content assist cue is not the problem. It's only visible if a field has focus. There is also a bubble visible that explains the light bulb. Will there be more bubbles for every decoration? thanks for the mockup. (I haven't made one in favor of working on a prototype that I can flip the switch on different looks). I agree about the clutter factor. I wouldn't expect required field indicators next to required fields that have content...just the ones that are empty (but there would still be quite a few in your example). The prototype API currently allows bubble text for any cue image, but again, that doesn't mean we'll use it for everything. More soon...will be working with the UI team in person this week on ideas and how it fits with data binding, etc. Created attachment 28387 [details]
mockup of wizard with color indicators
leftmost: just required indicator + content assist
middle: selected "Login-Status" now you're required to fill in the two missing
fields too
right: entered erraneous data for "Benutzername"
@@@@
Error/required messages are shown as a status of the wizard dialog.
Created attachment 28388 [details]
mock FormEditor with color indicators
The status/required message is shown in the applications status line.
I was happy with the way the wizards turned out but unhappy with the editor.
Unfortunately the status line just displays -- as it's name implies :) -- one
line of text. Depending on the screen resolution that's not many characters for
a meaningful status message.
What about a callback interface; something along the lines
interface StatusPresenter { void setStatus(String status); }
Then there could be three default implementations:
ApplicationStatusLinePresenter // sets the status on the application status line
TitleAreaDialogDialogPresenter //sets the status on a dialog
CueBoxPresenter // uses a presentation similar to the current "Content Assist
Available (Ctrl+Enter)" popup -- the popup's background color might change
depending on regular/error message
FYI: we tried hard to make dialogs and wizards come up without any error even if there are mandatory fields. Once the user changes the field and clears it again the error will appear. It would be nice to have support for this. As an example take the New Class wizard: it shows no error when opened but as soon as you enter and clear the name field you'll get an error. Moving this to M4. Here is the latest thinking. We are looking at adding support in JFace for two separate enhancements: 1 - decorated fields - allow specification of an image and placement for things like cue images, required field indicators, etc. There will be no implied semantics, just the ability to add the decorators, description text for a bubble, etc. 2 - content assist adapter - provides API for opening and closing a content assist popup, setting the content assist proposal provider, managing a secondary popup where needed, etc. 3 - JFace level classes that enhance #2, such as - filtering/type-ahead style content assist. There will likely workbench-level code that will tie a key binding to content assist. We will start using these features to start adding content assist, cue images, and possibly required field indication to workbench wizards and dialogs. However, it will still be up to the wizard or dialog implementer to set appropriate default values, ensure the wizard does not launch in an error state, etc. For example, an empty required field will not automatically trigger an error state. In the M4 timeframe (or beyond), we also hope to have a JFace data binding example that uses decorations and content assist to show the complete picture of retrieving/setting values from a model, validating input, showing required fields, etc. One thought I just wanted to capture is alignment. Depending on whether the layout tries to left align the text widgets or right align labels to texts etc... it might be important for an app to be able to leave the same amount of space free on other widgets in the same column that do not have the decorations. hi Susan - could you let me know when there's something in place for visual design feedback? Thanks. sure, Linda. Focus right now is on the framework and making room for whatever images are ultimately used. Apps will be free to choose whatever visuals they want. But there will be visual choices for the look that the SDK uses. Created attachment 31221 [details]
patch for org.eclipse.jface
Proposed framework API for DecoratedFields and Content Proposal
Created attachment 31222 [details]
TaskAssistExample.jar
Simple example showing API usage
I've attached a patch to org.eclipse.jface that introduces the proposed API for DecoratedFields and a ContentProposalAdapter for arbitrary controls. This patch is "mostly working" but requires much more testing, etc. I'm posting it here to solicit API feedback before releasing it to HEAD. The TaskAssistExample.jar is a simple dialog that demonstrates usage. Susan, as a proof of concept I suggest to convert existing dialogs that already offer user assistance. This would allow to compare the UI and the client code. Here are some examples: - Find/Replace (Ctrl+F) and Search (Ctrl+H) - if you enable Regex there will be code assist for the text fields - New Java Class wizard (Superclass field) See also comment 1. Wassim, there is a lot of potential value in PDE from this. Wassim - this is close to being released for M4, and I'm very interested in getting more clients to use this during M5 (before API freeze). Dani - I've been using your scenarios to drive much of the function, and will do at least the find/replace adaptation if not more. I started looking at this now. Here are my first obseravtions/comments/questions: 1) In DecoratedField.createForm(), you are setting a GridData layout data object on the composite created for the decorated fiels. This restricts the use of DecoratedFields to composites with grid layouts, or did I miss something? 2) Could you add a new method: FieldDecoration.setDescription(String description) for updating a decoration's hover text? The use case would be that you use the hover text to display field-specific validation error/warning messages. 3) If I wanted to use the same location (e.g. LEFT|TOP) to show warning or error decorations depending on the result of my validation, could I do that? How about a method: FieldDecoration.setImage(Image image) that updates the image? 4) package name: Is the task assistance support tied to dialogs (I've seen a number of references to class Dialog)? I think task assistance makes perfect sense outside of dialogs (e.g. for forms like in the PDE editors). If you can use task assistance outside of dialogs, shouldn't the package name be changed? Thanks, Boris. 1) in DecoratedField.createForm(Composite), I set a form layout into the composite that attaches decorations next to the control being decorated. This is by design and considered private to the control implementation. As a client, you are expected to interact with the control (getControl()) as normal for everything except layout. In that case, you use getLayoutControl(). You can set the layout data for the decorated field to whatever you want. 2 & 3) I can make setDescription and setImage public. (I usually try to minimize API by forcing everything through the constructor and then add the methods as really needed.) This lets the client decide if they want to reuse decorations, setting the description and image, or manage multiple decorations and swap them in and out. 4) I've been torn on the package name, and agree there is no tie at all to Dialogs. I'm trying to avoid the use of jface.contentassist because this isn't full blown content assist, but rather a set of utilities for making "fields" smarter. How about org.eclipse.jface.fieldassistance or org.eclipse.jface.fields I tried a few different package names and looked at imports, etc. to see what "looked good." I'm leaning toward org.eclipse.jface.fields. Added package to build >20051208 so that it can be in a nightly build before the M4 build warmup, and also to assist reviewers in easily looking it over. Note that all API is marked experimental and is likely to change as it is adopted. Patch containing the search/replace adaptation is in the works. re Comment #49 (1): Yes, but in line 491 of DecoratedField.java, you set the layout data for the layout control composite, I guess this should just be removed: composite.setLayoutData(new GridData(SWT.BEGINNING, SWT.BEGINNING, true, true)); > org.eclipse.jface.fields.
Sounds misleading to me. How about org.eclipse.jface.fieldassist?
I like keeping assist in the name. fields are an overloaded word as we already have field editors which are unrelated. re: comment #43. Thanks for the pointer, Boris. Fixed. Your comment made me think I had some lingering grid layouts, but for some reason couldn't spot it when I went looking for it. re: comment #44, 45. We'll go with org.eclipse.jface.fieldassist I am marking this bug fixed since the original plan item request was to provide support for showing required fields and providing field-based content assist. The preliminary field assist support is now released. This bug included several side discussions for which I'm opening new bugs and attempting to cc: those who were active in the discussions. If you want to follow the progress of these issues, please see these bugs: Bug #120238 - [Dialogs] - should required field indicators be used in Eclipse? Bug #120237 - [Field Assist] - adapt find/replace dialog to use field assist If you have comments on the released API or implementation, please open new bugs with [Field Assist] in the bug title. 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. verified I20051213-0100 that the new packages are in the built jar, and that the proper revisions were tagged for M4. Also ran (unreleased) example. Created attachment 31735 [details]
Mockup dialog with required fields marked
I have created a mockup dialog that has required fields marked with red squggle line.
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'll move your question and respond to it in bug #120238. I'd like to encourage discussion of required field emphasis to happen in that bug, since this bug is now closed.... Fine by me. |