[rkward-devel] Usability: Reading CSV

[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.

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(*). This is all centered around
   being able to specify commonly used formats, conveniently. Not
   around options that actually belong together, logically.
 - 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?

> >> 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

(*) 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.
-------------- 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/20151002/e330c885/attachment.sig>