[rkward-devel] Usability: Reading CSV

[jan]

Hi List,
Hi Thomas,

Am 02.10.2015 um 09:05 schrieb Thomas Friedrichsmeier:
> Hi,
>
> On Thu, 1 Oct 2015 22:58:12 +0200
> jan <d_jan at ymail.com> wrote:
>>> 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.
> Well, "CSV", "CSV2", simply provide specific defaults for
>
>  - "Use first row as column names"
>  - "Decimal point character"
>  - "Field separator character"
> and (dirty, dirty: it's on the third tab, but then that's because it
> is probably a rarely customized option):
>  - "String delimiter"
>
> These correspond to the R functions read.csv(), read.csv2(), etc.,
> while "Custom" corresponds to read.table(). Now:
>
> a) It is perfectly possible and legit to make settings identical to
> "CSV2", manually, while the "Data format" is set to "Custom". In fact,
> if you happen to know your data format well, that may be much more
> straight-forward than learning what exactly "CSV2" is supposed to mean.
>
> b) It may also make a lot of sense to start with "CSV" as a preset, but
> then to change individual settings. Importantly, the first row column
> names. This would currently require a rather unintuitive workflow: Set
> "Data format" to "CSV", then set it to "Custom", then customize.
yes. totally agree.
> Long story short: Certain options are affected by the "Data format" /
> quick options. But they also make sense on their own.
>
> Thus my plan would be roughly:
>
>  - Don't worry too much about the layout(*).
> (*) Although, I guess this means your initial suggestion to separate
> "Use first row as column names" from the two separator character
> controls is the way to go, after all.
good :)

>  This is all centered around
>    being able to specify commonly used formats, conveniently. Not
>    around options that actually belong together, logically.
Yes, this makes sense. The layout suggestion was not meant to make the
layout corresponding more to the technical model, only to prevent
confusing settings and to enable to see the different options. But if if
turns out that another layout makes sense /is now possible, don’t worry
about my suggestion. It was just meant to illustrate what/why I
suggested it this way.
>  - When selecting a predefined format in "Data format", the
>    corresponding settings should be made, automatically, _without_
>    disabling any other options.
>  - If the user then customizes one of the options belonging to the
>    format definition, the "Data format" control should switch to
>    "Custom", automatically.
>  - Likewise, if the user happens to make settings corresponding to
>    "CSV2", manually, the "Data format" control should switch to "CSV2",
>    automatically.
>
> Agreed?
Agree.
>
>>>> 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 :)
> Ok.
>
> Regards
> Thomas
>
> [SNIP]