[rkward-devel] Usability: Reading CSV

[jan]

Am 01.10.2015 um 21:45 schrieb 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:
>
> [SNIP]
>> 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". 
Ah, I see.
It needs somehow be clear what it belongs to. I assumed that the "quick
options" are "None", "CSV", CSV2" etc.
1) If all the elements (CSV, CSV2 etc. List, "Decimal Point", "Field
seperator" and the "first row…") are "quick options", each should get a
headline/bold lable, so CSV... could have "Presets" and the "first row…"
gets the "first row…" (or rather its revised lable).
2) btw.: Presets are a great lable for that list in general, I assume.

See  https://community.kde.org/File:RKWard_LayoutMockup.png
Does this make sense?

…hope I made these suggestions understanding what the underlying
problems are. If it is still strange/not meaningful I’ll have a look at
the source.

> 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.
Great.
>> 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.
Great too.
>
>> 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 (?).

"Open imported data for editing" makes sense. So: 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.
Yes.
>  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.
I see.
>
> 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?
yes, this seems to make much sense.
> [SNIP]
>
>> 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.
Sure. I suggest to review some other applications, maybe my impression
was wrong here. If it is standard and there is no obvious reason against
it I’d recommend to change. Otherwise, naturally, leave it like it is :)

Jan