Hi RKWard Devs, (Scroll way down for summary)
Am 04.06.2015 um 20:10 schrieb Thomas Friedrichsmeier: > On Wed, 3 Jun 2015 17:57:36 +0000 (UTC) > Jan Wort <d_...@ymail.com> wrote: >> [SNIP] … >> related to >> the GUI connected to otionset and not only a problem of the optionset >> control alone. >> >> E.g. the recode GUI could be redesigned like this: >> […SNIP] > > ok, yes, that can probably be improved. But it's a mostly independent > problem. Let's get the optionset straight, first. sure > (BTW, originally I > played with making "NA" a value to select in the "old values" list, but > that posed problems as it needs rather separate handling, internally. > Also there is the - corner case - problem of distinguishing it from > literal "NA" strings. So that's why arrived at making it a > radio-option. Checkbox would work as well, of course). ah, good to know. I came across the quoting/non-quoting stuff as well, in my case in terms of usability (it is probably an instance the question of how close the GUI should be to the underlying system) > > [SNIP] > >> A rather simple solution would be to provide the GUI for controlling >> the values in a pop up. Thats how SPSS is/was doing it. It is clear >> what does belong to what, but it is not very elegant. >> (http://imgur.com/fabT823). > > Yes, that always felt a bit clunky to use. I can't quite put my finger > on it, but perhaps it has something to do with having something "all > new" (the popup) appear for each item, having to re-orient myself over > and over again. > Just for brainstorming, though: Suppose we leave everything as is, > but _add_ an "Edit" button to each row in the display that will simply > activate that row. Possibly add some other visual cue (suppose a thin > frame that flashes, briefly) to highlight where editing takes place... > Would that solve most issues? (Note: a "delete" button could be added > in this solution, too). Hmm... It is unclear how much we can win by that approach. Core problems with mapping/orientation for the user would sadly remain. I don’t know how much additional work popup windows are, but they would be my way to go, if they are easy to implement. They are not fancy and a bit cluncky, but they are familiar (= "intuitive"), provide a sense of what-I-do-right-now and are reliable "workinghorse" controls. Either way, it makes sense to map the "delete button" to the items themselves (even if that takes a bit more space) – that would make the result appear where the input happens. > >> A better solution which combines the display of several values, gives >> easy access to editing them and provide a recognizable grouping could >> be the use of an "accordion" control. It would look like this: >> http://imgur.com/52pOvCr >> >> It combines several advantages: >> * It provides a clear structure >> * enough space in the accordion’s title to show several values (for >> recognizing/identifying) >> * it is clear which set of elements is selected (visually grouped in >> the accordion boxes) >> * the sets can be deleted directly (no select row, than delete). >> * The accordion is a standard control and not something unusual I >> made up myself. >> * You can create any GUI inside the accordion(s), as it is "just" a >> container. (one would define the GUI only once; it would be repeated >> in all accordions of the "accordion-optionset") > > Ok. I can see the merits of that solution. But it seems somewhat > non-trivial to implement. I'll have to read up on ways to implement this > some more. > > One caveat in our case is that in reality there can only be _one_ > underlying widget. We can probably make it look like separate > expandable widgets, but for instance, it will not (easily) be possible > to have two editor widgets expanded in the same optionset. So that's > one constraint. > > Another thing that is not quite clear to me, yet, is how we will > best handle the sizing. It may (or may not) be a good idea to make the > implementation _always_ show exactly one expanded editor widget > (disabled in case there are no rows), in order to avoid dynamic > resizing troubles. But in any case, we can't predict, how many items > there will be, but we still have to decide on some minimum / default > size. Any better ideas than making this something like editor height > plus four rows? Clarification needed: I’m not into the technical details and constraints here – is minimum/default size referring to the height of an opened accordion element? > > I'm slightly concerned that scrolling the whole thing > (including the editor widget) will feel somewhat clunky, when > required. I'm thinking it will probably make sense to implement > scrolling in a way that will make sure the editor widget is always > visible in full, i.e. scrolling will "flip" through the accordion > somehow ... That way of thinking makes totally sense, however by automatically opening stuff while scrolling, we get again the problem of "where am I"/"What is this". This would be no problem at all with scrolling though images or the like, but our stuff looks very similar (harder to orient on) > and then I'm scratching my head wondering how I can achieve > that. (OTOH, in typical usage, users will work their way from top to > bottom on merely a handful of items, and rarely have to scroll). Any > additional ideas / input on this? Clarification needed: Are you referring to ideas of how to avoid scrolling? > Anyway, probably still looks like the winner-solution, indeed. > >> [SNIP] >> >> * Tables (even better usability, less versatile) > > Yes. But again, I'd like to focus on the optionset, first, before > making any detailed plans on "option tables". sure. SUMMARY: So based on my experiences: Fixing the current optiontable approach (table+changing values in a form below) is hard (aka I have not good idea though we tried) Things to consider: - Accordions are imho a pretty good solution, however, they seem to be difficult to implement in a way that makes them work well as far as I understood. - If popups are much easier to implement, we should consider doing that, since they are reliable and have imho good usability apart from being a bit clunky. Regards, Jan _______________________________________________ rkward-devel mailing list rkward-devel@kde.org https://mail.kde.org/mailman/listinfo/rkward-devel