Community
Participate
Working Groups
We have come across many cases where our existing form for editing lists is unnecessarily bulky. These cases have the following attributes: 1. List entries have only one property. 2. Vast majority of these list instances are very short (0 to 2 entries). I think we need to develop a more compact alternative for such scenarios. Modern webapps have achieved reasonably good results in similar scenarios by utilizing a textbox and a button/link that allows you to add another text box to add an entry. I think we should be able to build on this pattern. Some considerations... 1. How do we present add? 2. How do we present delete? 3. How do list-level actions (add and delete) interact visually with entry level actions (browse). 4. Can we get by without move up and move down for these simple cases? 5. Can we support heterogeneous lists? Would need some way of indicate type next to each entry text field.
From Troy: ---------- Hi Konstantin, Do you have an example of a favorite implementation of this proposed pattern? I used to see this fairly often in web apps, but I don't recall coming across it in a while. To be honest, it always struck me as a convention that arose more out of necessity because of not having editable lists than as a solution designers would choose without that limitation. Kind of the same idea as duplicating Edit/Delete controls for each row in a table because there was no robust selection model underlying the table. AJAXy UIs - at least the ones I'm familiar with - seem to have trended away from this and more towards solutions that approximate native UIs, as the component sets have become more sophisticated. Another alternative to getting compact lists might be to provide a compact rendering of the current list pattern. That is, it could start with a list height of only 1 to 3 rows, and could grow dynamically as needed, up to the current limit before scrolling would kick. (Dropping the column header would be nice too, if possible.) And maybe we'd drop the Move Up/Down buttons. This might provide a more incremental approach where the basic behaviors are still the same - no new interaction model to learn - but it has less visual presence to begin with, and still presents a nice succinct list when browsing. -Troy
Gmail contacts UI is a good example of this. It’s used for things like phone numbers, etc. Compacting a table can mitigate some of the problem, but it is still arguably less usable of a UI due to the need to deal with cell editors as opposed to top-level controls. Add interaction with table: 1. click add button 2. type something 3. press enter Add interaction with a textbox (let’s assume that we present an empty text box if list is empty as the starting state): 1. type something Edit interaction with table: 1. double click on the row 2. edit something 3. press enter Edit interaction with a textbox: 1. type something Tables tend to work better when the number of items is higher than low single digits on average or when you got a usecase for multiple columns (multiple properties in list entry objects). We have a fundamental tension here between providing richer-and-richer table UI that is beneficial to long lists and keeping the representation compact. For instance, the column headers are shown because it is useful to sort the entries. We also have an outstanding item to support search/filter UI. - Konstantin
From Troy: ---------- Right. A compact rendering of the table/list could drop the richer functionality features that are oriented towards large collections. Re: the number of clicks saved, the disadvantage for lists disappears once you need to enter a second item to the collection. (Hitting Enter is optional anyway as you can just Tab or click elsewhere, as you would with a text field - not that it's much effort to hit Enter anyway after typing in a value. I'll look at the Gmail UI - probably long overdue anyway.
> Right. A compact rendering of the table/list could drop the richer > functionality features that are oriented towards large collections. I would consider that a partial solution. Not really optimizing UI for the fundamental aspects of data. Will probably do this anyway. It's good to have flexibility to turn off features as necessary. > Re: the number of clicks saved, the disadvantage for lists disappears once > you need to enter a second item to the collection. Yes, but it shouldn't be any worse than a table.
> > Re: the number of clicks saved, the disadvantage for lists disappears once > > you need to enter a second item to the collection. > > Yes, but it shouldn't be any worse than a table. Actually, I take it back fully agreeing with the statement. It is only for the add action where two approaches equalize for the second item. For edit, the text boxes approach continues to maintain advantage.
Progress made, but not close enough to completion. Deferring to 0.3 release.
From Ling via e-mail on March 17: ================================= Konstantin, I checked in the latest compact list code, there are still some issues to be ironed out, but I can't remember a few of the details where I left off. To see the code add the following to GalleryEditor.sdef. <property-editor> <property>Entities</property> <hint> <name>factory</name> <value>CompactListPropertyEditorRenderer$Factory</value> </hint> </property-editor> 1. The decorator - should we have a main one similar to the list or individual decorators? 2. I need to be able to insert (in addition to addElement) to ModelElementList. How can I do that? Thanks, Ling P.S. Is the way the editor works now close to what you have in mind?
From Konstantin via e-mail on March 17: ======================================= I took a look and it's coming together well. I added a permanent home for this feature in the gallery sample under List -> Homogeneous. > 1. The decorator - should we have a main one similar to the list or > individual decorators? Individual ones like you have now are the way to go on this. That does leave no place to display list-wide validation (count constraints and such), but I think maybe we can write that off as the limitation of this type of the property editor. It is something that is useful in described set of circumstances that we will document. > 2. I need to be able to insert (in addition to addElement) to > ModelElementList. How can I do that? How does that come up? > P.S. Is the way the editor works now close to what you have in mind? Yep, pretty much what I had in mind. Some notes on stuff that I spotted: 1. The add link should reference element type label, not column label. 2. Activating assist popup on any decorator other than the first one displays the popup in the wrong location (too far down). 3. If I add three blank items and then write text into the last one, the preceding elements arenât materialized. I would expect first two elements to be created as soon as I write text into the third one. That is, if I leave and come back, the preceding two blank lines should still be there. The same shouldnât apply to trailing ones. Clearing trailing entries (or not filling them in) should not materialize them. This might resolve your need for an insert. 4. Make sure you support actions that might be attached to value property in question. Browse, jump, etc. See how this works in DefaultValuePropertyEditor. You basically have a list of these. - Konstantin
From Ling via e-mail on March 28: ================================= Konstantin, I checked in the latest fixes for compact list. Can you please review my changes in PropertyEditorAssistDecorator? Instead of separating into a base class, I was able to reuse most of the class, but I had to remove the "final" in the class declaration. I also had to change 2 fields and a method from private to protected. Let me know if these changes can stay as is, or if it is preferrable to separate out the common code into a base class. I have 2 remaining issues. 1. I had commented out addControl() since I'm adding/removing the text controls, I need a way to modify the list of controls. I was able to do this with related controls. It seems to function fine without this, but I'm not really sure what the test case for SapphireKeyboardActionPresentation. 2. I need a way to override "show in source" since I'd like this to be enabled even when the list item is empty. Ideally I'd like to modify the hints on the child text property. I need to be able to modify HINT_ASSIST_CONTRIBUTORS and HINT_SUPPRESS_ASSIST_CONTRIBUTORS. Thanks, Ling
I've transferred this thread to the bug. In the future, please make sure that exchanges like this one happen on the mailing list or in bug comments. Private exchanges are a problem for open projects as they lead to lack of transparency for third parties and ultimately make it more difficult for others to get involved. This is something that we all need to be very sensitive to. > Can you please review my changes in PropertyEditorAssistDecorator? Instead of > separating into a base class, I was able to reuse most of the class, but I had > to remove the "final" in the class declaration. I also had to > change 2 fields and a method from private to protected. Let me know if these > changes can stay as is, or if it is preferrable to separate out the common code > into a base class. I am fine with this approach. > 1. I had commented out addControl() since I'm adding/removing the text > controls, I need a way to modify the list of controls. I was able to do > this with related controls. It seems to function fine without this, but > I'm not really sure what the test case for SapphireKeyboardActionPresentation. Action keyboard presentation is the system that ensures that user has keyboard access to property editor’s actions. For instance, CTRL+ALT+SHIFT+I to bring up the assist dialog or CTRL+ALT+SHIFT+L to browse for possible values. You will need to create and manage SapphireKeyboardActionPresentation instances on the per-line basis. Make sure they are disposed properly. I also noticed that you aren't surfacing property editor's actions. I have added another use of this property editor under Sapphire Gallery -> Browse Support. I expected to see browse button next to the text field. Also, see ctrl-click behavior on "eclipse workspace file path" property. Setup a similar list property and make sure that the compact list property editor handles ctrl-click. > 2. I need a way to override "show in source" since I'd like this to be > enabled even when the list item is empty. Ideally I'd like to modify the > hints on the child text property. I need to be able to modify > HINT_ASSIST_CONTRIBUTORS and HINT_SUPPRESS_ASSIST_CONTRIBUTORS. Let’s not worry about this for now. In general, we want to avoid display the light bulb indicator when property is not set. In this case, the situation is a bit more complicated as you can argue that the text box represents more than just the property, but also the list entry itself. We might come back to this, but don’t need to do anything for that now.
Forgot to mention that if you look closely at this property editor under Sapphire Gallery -> Browse Support, you can see that alignment on the right hand side of the text box is off by a few pixels.
Added a list of java types as a test case for browse action and ctrl-click jump action. Also fixes the 2 pixel issue. There is one minor issue - in the disabled state the add link does look disabled. This needs to fixed in SapphireFormText.
Verified action buttons, the jump hyperlink and keyboard activation. Look very nice. I agree that this is sufficiently completed to marked this as resolved. Will open other bugs to cover any remaining issues.
