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

[Thomas Friedrichsmeier]

Hi,

On Tue, 26 May 2015 23:53:33 +0200
d_jan <d_jan at ymail.com> wrote:
> Am 26.05.2015 um 15:10 schrieb Thomas Friedrichsmeier:
> > 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?

[...]

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

Actually, the gory truth is that we don't know what the user will see,
as users can configure the toolbars to show icons and text, only icons,
or only text. So the two button-solution seems preferrable. I have now
committed this feature to git.

Small hint, on following the bleeding edge development, easily: This PPA
provides daily builds for Ubuntu, i.e. should have the buttons by
tomorrow:
https://launchpad.net/~rkward-devel/+archive/ubuntu/rkward-dailys 

> >>    Issue 2: Workspace
[...]
> > - 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.

_Probably_ not.

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

To some degree. But I think the search and filter-options actually still
make sense for both groups / use cases. Searching/filtering by name
(or label) is something that can easily come in handy even for novice
users (e.g. dealing with wide datasets containing many variables).
Filtering by class, type, dimensions, etc. may be targeted at more
advanced users, _but_ this is somewhat orthogonal to what objects get
shown: In many (most?) cases the objects of interest to search through
will still be those inside "my data"/.GlobalEnv.

So that's why I think the two windows might end up looking confusingly
similar. But perhaps I did not understand your idea quite correctly,
or you have some nice solution for this up your sleeve...

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/20150602/9e807f6a/attachment.sig>