Community
Participate
Working Groups
JMS descriptor -> Destination keys -> sort key and user defined sort key. There are 10 known sort keys and the optional user defined sort key. Perhaps use a combo instead of radio buttons?
The current UI for sort key specification could be more clear, but it does work. The two radio buttons approach seems like the correct choice here. The first radio button would enable be next to a combo for named values. The second radio button would be next to the text field for the arbitrary values. The only thing that gives me a bit of a pause is handling of labels and how this block would look compared to the existing named values block. Existing block: [property-label] [*] [named-value-1-label] [*] [named-value-2-label] [*] [arbitrary-value-label]: [text-box] Proposed block for high number of named items: [*] [property-label]: [combo-with-named-values] [*] [arbitrary-value-label]: [text-box] Note that unlike the existing UI, there is no "introductory" label. I suppose that we could move the property label up there, but then we would have to come up with another label in front of the combo. I am thinking that it will be a bit difficult to avoid repeating the same text. It would also mean that we couldn't drive the rendering from the existing named values annotation. Would also need to figure out where to attach the assist indicator. Will need to talk to Troy about this pattern.
Hmm... I think there is still a case for keeping this enhancement, but I think that there is a better way to represent the specific case of the sort key in the UI... text field with a browse button. The named values construct is meant for cases where you want to give an alternate name/label to certain values that would clarify the meaning of those numbers. The sort key doesn't appear to be that case. The value in the combo is exactly the value that gets written to the descriptor. This strikes me as a values provider problem where values provider is configured to not flag non-matching values as errors. This is possible right now.
From Ling Hao: -------------- The existing UI highlights the ability to the user the specify a user-specified sort key. By switching the the value provider with no validation UI, the user-specified sort key is implied. Thus I will keep the existing UI. Closing bug since there is not a good test case for the alternate UI.
I'd like to keep this open even if we don't have a case for this now as I am sure we will see this again. > The existing UI highlights the ability to the user the specify a > user-specified sort key. By switching the the value provider with no > validation UI, the user-specified sort key is implied. Thus I will keep the > existing UI. Could you run this by Troy for his opinion? I am not sure that I share your concern with the user of the values provider in this case. From UI angle it seems no different from all the other places where you can either fill in an arbitrary value or select some values from a browse dialog.
From Troy: ---------- 1) Combobox would normally be ideal - except that it traditionally doesn't look much different from dropdown list, and that's even worse here since we usually show a default value. There's virtually no enter-a-value-here affordance. 2) The current UI with a dropdown that enables a text box when user-defined is selected works but is also non-obvious. There's nothing that immediately suggests the two fields are related - and it's been hard to do an indentation in this circumstance that looks right. 3) The value provider (textbox with browse button) does typically say enter-a-value-here except that we use the exact same thing in a number of places where really only the enumerated values are acceptable. This has me almost trained that when I see this widget in this context I think the value are not open-ended. 4) The two radio buttons - one with a dropdown list, one with a textbox, seems to satisfy all these points. It is very quickly undesrstandable and has the requisite affordances. The main drawback seemed to be that it required a bit more custom modeling. While true, it isn't a user-facing concern. So, if strictly advocating best UI for the user, given our context, I'd go with #4. If we still think it's not worth the extra effort, the remaining solutions are roughly equivalent imo - all haver notable drawbacks. That said, of those I'd probably go with #3 as being both succinct and nearly right. We could perhaps add some instructional text nearby saying suggesting to enter a user-define key or pick a standard one from the list, FWIW.
> 3) The value provider (textbox with browse button) does typically say > enter-a-value-here except that we use the exact same thing in a number of > places where really only the enumerated values are acceptable. This has me > almost trained that when I see this widget in this context I think the value > are not open-ended. Maybe there is a way to highlight that distinction somehow. A different icon perhaps? While the case where only enumerated values are acceptable is the predominant one, we certainly have many examples of the other. > 4) The two radio buttons - one with a dropdown list, one with a textbox, > seems to satisfy all these points. It is very quickly undesrstandable and > has the requisite affordances. The main drawback seemed to be that it > required a bit more custom modeling. While true, it isn't a user-facing > concern. The other drawback is that it is bulky and needs to be set-off from other property editors just like the existing named values controls. At least in that case you can justify the bulkiness because the problem you are trying to model is rather tricky as you are trying to assign more understandable names to some underlying property values. I would be hesitant to apply the same pattern to the arguably more simple situation described here.
From Troy: ---------- I didn't claim it was the best looking UI, just most immediately understandable. ;-) I don't imagine the labels would be hard to come up with. As an example: Sort keys: System defined: [_________|v] User defined: [___________] I don't disagree with textbox and browse button as a (less immediately obvious) alternative - just pointing out the issue that I think we currently have with this usage.
Fair enough and I can see how this pattern could be useful in some cases where extra highlighting of this distinction is useful. On the other hand, I think it is still worth it to spend some time thinking about whether there is a way to enhance our text-box/browse-button pattern to improve handling of problems like this. The trade-off between screen space and obviousness is not always easy to make and it would be nice if we had a compact form of representing this that worked well. A different icon for the button? Something else?
From Troy: ---------- Some distinction between the enumerated-values-only and the open ended case certainly seems handy. Nothing very obvious has hit me so far - but we could probably come up with something. So far I've mostly come upon things I don't want to do - like make the textbox read-only - since that imposes undue restriction on a users workflow - e.g., I'm putting in this currently nonexistant request class (or whatever) for now, but I'm going to go create an RQ by this name in a minute - oh wait, it won't let me since I have to choose from a list.
