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

[Thomas Friedrichsmeier]

Hi,

On Fri, 22 May 2015 15:35:01 +0000 (UTC)
Jan Wort <d_jan at ymail.com> wrote:
>    Issue 1: Deleting data
> 
> > 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"?
> 
> Yes along this lines but that might be annoying.
> 
> 
> > It should be very, very obvious, how to switch from read-only to
> editable and back. […] Probably a KMessageWidget shown…
> 
> What about utilizing the top toolbar? It already adapts to the type
> of data, and for editable data it could offer a lock button. It would
> do the same as the option in the Edit menu. 
> 
> 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?

From your other mail:

> 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"
> which change according to the active content (e.g. Clip/Copy/… for
> dataframes or back/forward for documentation) It is just a small line
> to add, but this may help users to predict the results of pressing
> the toolbar button.

True. But I'm not sure how to do that, technically. (Actually the
"workspace buttons" and the "object buttons" are on two separate
toolbars, internally. Separators at the start / end of either will
likely be stripped, automatically. May have to change this). Could you
add this to either https://community.kde.org/RKWard or the feature
request tracker, so it won't get lost?

>    Issue 2: Workspace
> 
> >"Data" did not look entirely right to me (e.g., is .Random.seed
> >data?)
> Indeed. I would assume that for the user .seed is is more like a
> function (something tool-like that R provides for me), though
> technically it is not.  
> 
> 
> > Here's some background: […]Environments:You are not the first to be
> > puzzled …
> Thanks! That makes it clearer to me.     
> 
> 
> > 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).
> 
> Sounds good to me. 
>
> I can prototype some ideas and send them to the list to discuss
> how/what we can improve here and consider the information on
> environments and your usecases. Possibly I’d test them with some
> people too to get preliminary feedback; It sounds like a meaningful
> thing to improve. 

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

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

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

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

Regards
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/20150526/df541c3a/attachment.sig>