[rkward-devel] Usability: Reading CSV

[Thomas Friedrichsmeier]

Hi,

replying to your feedback in piecemeal fashion. First round:

On Tue, 29 Sep 2015 18:33:44 +0200
jan <d_jan at ymail.com> wrote:

> Dear RKWard Devs,
> 
> Since I was recently working again more with RKWard (analysing
> usability data…), here are some usability problems I found. I tired
> to estimate how hard they are to fix, so one could focus on the most
> effective fixes.
> 
> I split them in different mails, so that the issues stay separated.

Yes, much appreciated!

> 1) Reading CSV Data
> ===========
> 
> First row as col names (easy/medium difficulty fix)
> --------------------------------------------------------------
> 
> It took me a long time until I found how to get the first row as
> column name. Assumed reason: The checkbox for the option (nicely put
> on the first tab!) is somewhat squeezed between other elements. On
> Linux it looks like it is part of "quick options", on Mac this
> impression is even more extreme, since it resides in some
> darker-colored box.
> 
> Violated Heuristics: Usability, Standards (all other options have some
> sort of headline)
> 
> Proposed Fix: Give it a space on its own (an own line) and/or a
> headline

Hm. Rationale is: It _is_ part of the "quick options" / controlled by
that "Data format". However, in fact, we're probably not doing that
right. See further down. No action taken, yet.
 
> Aside there are several smaller issues I found.
> 
> Wordings (Easy fix)
> --------------------------
> 
> a) In "Column names in first row" (1st tab) it is unclear if the first
> row is the CSV’s or the resulting data.frame. (Suggestion: "Use first
> line as column names" (?))

Makes sense. Slightly changed to "Use first row as column names". Done.

> b) "Default": On the second tab there are many "Defaults", but it is
> unclear what this default is.

Changed to "Automatic". For "Column Names", this remains a bit
confusing (since this could either mean column names taken from first
row, or column names "V1", "V2", "V3"...), but less than before. Done.

> c) "Edit Object" (1st tab, save to options): This seems to open the
> object after import in the table view, but it suggests it somehow
> directly changes some object (like a mixin or an overwrite...)
> (Suggestion: "Open after Import" or "View after import")

I used "Open imported data for editing", now. If that sounds good to
you, I'll change the other import plugins accordingly. Done (?).

> Active/Inactive Fields (Medium)
> -----------------------------------------
> 
> Depended on other fields, some radiobutton options are active or
> inactive. Sometimes it is hard to follow why, and the many inactive
> options irritate
> Possible fix: Using Dropdowns (?) like in RStudio’s import

I think you're mostly referring to the first tab, here. Dropboxes might
help, but perhaps more with the symptoms than with the problem: The way
the "quick options"/"Data format" work is actually not by setting
specific settings, directly (was not possible at the time, would be,
now), but by disabling all conflicting settings. Hence the inactive
options.

Now, we have more flexibility in plugins, today, so we could make it
that setting "Data format" to "CVS2" does change e.g. field separator,
header, etc., but it would still be possible to change field separator
afterwards. In this case, the "Data format" control should probably
switch back to "Custom", automatically, to avoid confusion. (Sounds
like work, but not excessively much). Sounds reasonable?

No action taken, yet.
 
> Preview (Difficult)
> -----------------------
> This is probably hard to implement but a preview of the first 5 or so
> imported lines would be great (also RStudio inspired)

Yes, something like that is on the TODO list, already. No action taken,
yet.

> Flow: Call the file selector (easy to medium)
> ----------------------------------------------------------
> Before any option makes any sense, I file needs to be loaded. So
> flow-wise it would make sense to open the file picker right away. It
> also would match user expectations, since it is standard in many other
> applications.

May make sense. I'll need a bit more time to think about this. No
action taken, yet.

Regards
Thoams
-------------- 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/20151001/355cb389/attachment.sig>