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

[d_jan]

Am 26.05.2015 um 15:10 schrieb Thomas Friedrichsmeier:

TLDR: Locking should be a checkbox or 2 buttons; separator issue was
added to the wiki; cover usecases for data/packages by two
sidebar-windows: 1. data, 2. the whole, "real", R Environment (both can
share the same code, is is more a matter is what is shown)

> Hi,
> 
> On Fri, 22 May 2015 15:35:01 +0000 (UTC)
> Jan Wort <d_jan at ymail.com> wrote:
>>    Issue 1: Deleting data
[snip]
>> Thus we could keep the current behaviour but offer an easy to find
>> protection too. 
> 
> indeed, good idea. I'll take care of that. One small follow-up, though:
> What is actually the best way to design such a button in the toolbar,
> from a usability perspective?
> 
> - Show a lock that can be toggled between open and closed. But then,
>   should it show the closed lock when the data _is_ read-only, or when
>   clicking on the lock will _make_ it read-only?
> - A lock symbol somehow combined with a checkbox?
> - A lock symbol as a toggle button (not changing the symbol between
>   open and closed)?
> - Something else?

A very good point. A single button toggle is not advisable for the
reasons you pointed out.

I don’t know what the technical possibilities are.
I assume that a "lock editing [x]" (text+checkbox) is easily understood
and implemented.

If we want to use a symbol it would only be unambiguous if one uses two
buttons side-by-side: one for locking, one for unlocking. Such
interactions are not as unusual as it sounds – the align
left/center/right control in a wordprocessor is a well known example.


>> Minor addition: At least in my version of RKWard (0.6.3 KDE Dev
>> 4.13.3) there is no visual separator between the
>> "workspace-buttons" (Open, Create, Save) and the "Object-buttons"
[snip]
> Could you
> add this to either https://community.kde.org/RKWard or the feature
> request tracker, so it won't get lost?

Yes, I do.

>>    Issue 2: Workspace
[snip]
> 
> That would be highly welcome! It's certainly a rather essential control.
> 
> I'll add a few more thoughs:
> 
> - If going with two separate tool windows, these would likely still end
> up looking pretty similar: Essentially the same controls, icons, and
> tool tips make sense, and also some actions (view, copy). This
> similarity _could_ be confusing, in case you mis-click and activate
> "Package Objects" instead of "My Objects"?

good point. I would assume this will probably not be a problem; I would
need to test this though.

> - Note that essentially the same control is also used in plugin dialogs
>   (the "varslot" where you select objects from). So that may or may not
>   be affected by a re-design.

The varslot seems to be a "only data" version of the dialog.

> - Also note that this "varslot" currently allows you to switch to
>   showing all package environments (via RMB menu) and selecting
>   objects e.g. from package:datasets. Not sure whether anybody else is
>   using this (I do, at times, for testing purposes).

Is there a production-relevant usecase for that switching? If not, I
would not worry too much about it; and for now the possibility to do so
does not need to be eliminated by a redesign.


> - Not sure any decent solution is to be found along these lines, but
>   to outline another approach: It would also be possible to re-arrange
>   the item tree a bit (while showing "All environments"): E.g. we could
>   add a pseudo-item "Package Objects" as a sibling of ".GlobalEnv", or
>   even simply next to the regular user objects, i.e.:
> 
> -- My Objects / .GlobalEnv
> \-- my.data.x
> \-- my.data.y
> -- Package Objects
> \-- package:base
> \-- [...]
> 
> - or -
> 
> -- my.data.x
> -- my.data.y
> -- Package Objects
> \-- package:base
> \-- [...]

>From a usability/frequency of use point I like the second one.

However I would think that the cleanest solution would be to expose two
of such windows to the user: A "my data" (or whatever) one that is
technically the .GlobalEnv and the "package explorer" (or whatever)
which allows the more advanced user to see every part of the packages etc.
Both could internally use the same code etc. but expose the kind of
display and options the target groups would need. Someone who "just"
analyses data with the GUI-accessible options gets a view focused on the
data, those who like to get more into the internals and/or write (short)
code on their own can be supported doing this – like previously
suggested e.g. with more search and filter-options.

Does this make sense?

Kind Regards,
 Jan