[rkward-devel] Usability progress, testing on Mac

[Thomas Friedrichsmeier]

Hi,

On Wed, 28 Oct 2015 14:32:38 +0000 (UTC)
Jan Wort <d_jan at ymail.com> wrote:
> > The first two steps require a good amount of downloading, and I
> > recall you were having trouble with your connection.
> 
> I can't guarantee that I'll manage to do it tonight, but it is pretty
> likely :) My Connection works again.

great!

> Just to be save: Does the building and installing change anything
> significant outside its folder? (If yes, it better goes into a VM)

It does install over your "real" RKWard installation, so if you want to
play it safe, a VM might be a good idea.
 
> Looking forward to see your work!

Ok, some further background and instructions, then:
- First, go to Settings->Manage R packages and plugins->RKWard plugins
- Activate "Plugins under development", there
- Open Analysis->Optionset Test

Perhaps, first take a look at the "Detached" optionset on the second
tab. Admittedly, I did not put too much love into that. Should be
enough to toy with the idea, though.

The more interesting set is the "accordion". It's on the first tab, but
also the default for all other optionsets, in this branch. Note that
this is not entirely finished, either, but again, enough to get an
impression.

I first tried implementing my "tab slide" idea, but kept running into
conceptual dead ends, then looked into implementing your "accordion"
suggestion. One thing that I wanted to keep was presenting the options
in a tabular fashion with header. That's because
- it really is presenting tabular data
- using a header saves some horizontal space: Instead of writing "Old
  values: XYZ, New values: ZYX", you only need "XYZ | ZYX" per row
- importantly, should some values / variable names or other things to
  display get exceedingly long, every once in a while, you'll still be
  able to resize the header sections to see a larger or smaller slice
  of the data, just as you need it.
Agreed?

One consequence of this is that I based my work on a "tree view", and
this has some visible differences in style to your mockup. This could
certainly be styled to look more like a regular control, but for the
moment, I'm not-so-unhappy with the looks, personally.

You'll note that each row in the accordion optionset has "+" and "x"
buttons for insertion and removal of rows. However, when the set is
empty, we still need a way to insert an intial row. For this, I
appended a "dummy" row at the end. (In addition, you will still find
the old large "+" and "x" buttons below the main control. Please ignore
these, they will be removed.)

Trying the "+" buttons, I felt the behavior was not so intuitive to
myself. One reason for that is that "+" means "insert above", not
"insert below". Changing that would mean that there is no way to insert
a row at the top. I'm also a bit unhappy with the fact that "+" and "x"
are so close together in each row, which might be asking for
mis-clicks. Also, inserting rows somewhere in the middle of existing
rows is important to have, but it's still not going to be used a lot.
For the most part, users will only need to add at the bottom.

Long story short, I figured, perhaps we can do away will all "+"
buttons except the one on the last (dummy) row. Instead, rows can be
re-arranged by dragging, if needed. I have implemented the dragging, but
not yet removed the "+" buttons. Your thoughts on this?

Another thing you'll find missing is an "expand / collapse" indicator /
button. Looking at the control I simply felt it might not be needed,
after all (and was too lazy to try): If you click any cell inside a
row, the row will be "selected", and it will expand, showing the
corresponding editor. That seemed discoverable enough to me. What do
you think?

Note that contrary to what I suspected, it is technically possible to
have all sections collapsed at once (but it would indeed be very
difficult to allow more than one section to be expanded at a time).

You are likely to discover quirks beyond the ones I mentioned. Do tell
me about the ones you run into, but it's still a bit too early to do
any systematic testing.

Looking forward to your feedback on this initial draft.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151028/f96fea71/attachment-0001.sig>