[rkward-devel] Usability: Informal/Heuristics based remarks

Thu May 21 12:46:34 UTC 2015

Hi!

On Wed, 20 May 2015 21:05:28 +0000 (UTC)
Jan Wort <d_jan at ymail.com> wrote:
> Hello RKWard Developers,
> 
> I’m new to the list and RKWard development. I wrote with Thomas
> before, whom I asked if RKWard would be interested in
> Usability-related input (and possibly some JavaScript for Plugins)
> I’m a user researcher and do mainly qualitative (interview-based)
> research, though I use R since some years and recently started using
> RKWard. 

Welcome on board!

> 
> So far about me or how I got here.
> 
> My first input is not very formalized and based on my experiences
> using RKWard. However, the issues I’ll address are checked against
> the common 10-Point Nielsen-Heuristc for UI Design. 

Thanks a lot!

I'll fill in some background information:

> ==1. (deleting) Data==TLDR; being able to delete data in the
> dataframe view causes trouble.
> 
> 
> Scenario: I imported my data (from a cvs or the like) and have a look
> at it via RKWards Data Frame Viewer. I interact with the data in some
> form, like marking a part to copy it in the clipboard. For whatever
> reason I touch the "del" or the "Backspace" key.
> 
> The Data is gone, I need to reimport.
> 
>     Solutions
> 
> Best would be undo. But this is often hard to implement.

Agreed. Undo is definitely on the TODO list, but unlikely to happen
soon.

> Second best: A warning and/or a "locking" of the data, which allows
> to select data and copy it, but not to manipulate the data itself
> manually (In my experience, the manual changing of data points does
> rarely makes sense anyway, but that is just an educated guess)

What kind of warning do you have in mind? "You are about to clear X
cells of data. Are you sure? --- Don't ask again --- Clear / Don't
clear"?

We already have support of sorts for locking, but it is not active by
default, and probably not too discoverable: Open a data.frame, then
uncheck Edit->Enable Editing. So it would be rather easy to build on
this. To spin some thoughts:

- Data could be presented read-only by default, and require unlocking,
  instead of the other way around. Possibly configurable.
- It should be very, very obvious, how to switch from read-only to
  editable and back. Probably a KMessageWidget shown on read-only data
  (see http://kate-editor.org/2012/07/08/rfc-data-recovery/ for a
  screenshot of the widget, although showing totally unrelated use
  case). Note that this would mean increasing our library requirements a
  bit, but would not be an (additional) issue for the KF5 port.

More ideas?

> == 2. Workspace and Data ==
> TLDR; "Workspace" content display controls are difficult to get
> 
> 
> 
> The "Workspace" on the left was a bit puzzling to me and will
> probably be even more so for people who come from commercial
> applications like SPSS (I use RStudio). 
> 
> 
> "Show hidden objects" and "Functions" is sort of understandable,
> though this *may* be already jargon the user is not familiar with.
> "Non Functions" assumes some kind of boolean logic in the UI (people
> tend to be bad at this) and "show all environments" is difficult to
> grasp (I know "global scope" in programming, but are there several
> "global" scopes in R?) [2] I assume there are good reasons for the
> current design, but it is hard to comprehend even with some
> R/programming knowledge.
> 
>   Solution
> 
> Since I don’t know what the exact goals of the dialogue are I will
> not/can’t suggest an other design. If you or someone else could
> explain me the intentions of the dialogue and of its current options,
> I gladly try to set up a design which keeps the power of the current
> one while not confusing people who don’t have deep knowledge of
> R(KWards) inner workings.

Here's some background:

"Functions" and "Show hidden objects":
These will be useful at times, but arguably they are more visible than
necessary. Users are unlikely to need these settings unless and until
they can make sense of the terms, too. These could probably be grouped
into some (hidable / expandable) "Filter" group. Several extensions of
that group might be useful in the mid term, too, e.g.
searching/filtering by name, by class, by dimensions...

I did think about a different term for "Non-Functions" back then, but
"Data" did not look entirely right to me (e.g., is .Random.seed data?).
Maybe that was just being pedantic, though.

Environments:
You are not the first to be puzzled by R's various uses of
environments. R does use environments to implement scoping, but in this
case, you can rather think of environments as namespaces (but not
quite: a namespace is actually another distinct and even more puzzling
concept in R). Environments can also be present as symbols. E.g. try
    x <- globalenv ()
In this particular case, the switch controls whether only the "user
objects" (technically, .GlobalEnv) are shown, or every object on R's
search path (see ?search), importantly including functions and data from
loaded packages.

Most of the time, users will be interested in their own objects, and in
fact we've changed the default very recently (in 0.6.3) to show only
those, initially. However, browsing through the contents of packages
can be quite useful, too, and personally, I use this a lot more often
than the "Functions" and "Hidden objects" filters. Main use cases for
browsing through objects in packages are:
- "What's the name of that function, again?"
- "What else is inside this package (which other datasets/functions
  could be useful to me)?"
- Easy access to function reference.
- For developers: "How does R store this information?"

Arguably, the use cases for browsing .GlobalEnv and "All Environments"
are somewhat different. So one idea (good or bad) might be to separate
these into two distinct tool windows, one for "My Objects", one for
"Package Objects" (or whatever the names).

> Because Usability people tend only to complain here some uplifting
> remarks :) ==3. Praise==
> * The general Structure is, like the description of the application
> says, accessible for people who are used to commercial programs.
> 
> * In contrast to changing *data* (see issue above), being able to
> change the datatype and name of columns in data frames directly is
> just great. It is a pain and error prone to do this in code imho
> (Everyday R users will disagree though I assume)

Thanks!
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/20150521/fe9213bb/attachment.sig>