[ANN] Release 8.1.6 RC-1

[Richard Gaskin]

Richmond Mathewson wrote:

 > On 7/12/17 7:56 pm, Richard Gaskin via use-livecode wrote:
 > <snip>
 > for reasons too lengthy to indulge in here.
 > <snip>
 >
 > Please could you indulge in them somewhere so we can understand your
 > argument fully.

For future readers to better understand my reply here, it may be helpful 
to include the relevant portion of the message so they can know what's 
being described:

     If the toggle is either in-window or in the SE's View menu that
     would be great.

     I would caution against adding more stuff to the Prefs window,
     for reasons too lengthy to indulge in here.


TL;DR version:

Immediacy.


Rambling version:

Discoverability is part of this, and, once discovered, ease of access 
becomes another important part.

If you want to change something you're looking at, it's often better to 
provide the means to do so in the thing being looked at, rather than in 
one of several panes contained in some separate window which may be 
found by accessing an item tucked away at the bottom of a menu.

A user will be able to discover that something can be changed in 
relation to the conceptual distance between the thing being changed and 
the location of the control that makes the change.

Ideally (and admitting up front that we don't live in an ideal universe, 
so there is no one-size-fits-all rule for every design problem), this 
would translate to a hierarchy that favors, in order of discoverability:

1. The content region of the window (rare for View options, since that's
    usually where the user puts their own stuff, but definitely at the
    forefront of user consciousness).

2. A secondary pane within the window (such as the View options at the
    bottom of many popular apps like Apple's TextEdit).

3. A menu item accessible while the window they want to change is in
    front (most HIGs specify a View menu for exactly this purpose).

4. A separate window which can be opened from a menu item (typically
    "Preferences" on Mac and "Options" on Windows).

(Side note: Context menus are not even considered here since they never 
include options not also available through more evident means.)

This hierarchy of immediacy might tempt us to cram every option directly 
in the user's window, but of course throwing all options in front of the 
user often backfires with cognitive overload and visual clutter, so we 
want to think carefully about what goes where.

Whether an option is part of the local view, or a menu, or better 
handled through a separate Preferences window isn't always obvious with 
complete confidence, and like most things can involve a bit of guessing 
(though guessing can be mitigated with A/B user testing).

But there are some questions that can be helpful in making that choice:

- Might the user want to change the setting more than once?

   Things like the script editing field's background color is
   often set once and rarely if ever changed.  It's a good
   candidate for the Prefs window.

   Things like ordering handlers either alphabetically or
   sequentially may be changed several times per session,
   a good candidate for a View pane at the bottom of the
   window, or at very least a menu item with a memorable
   shortcut.

   I can envision wanting to toggle the visibility of
   suggested handlers frequently during a session.


- Are there any potential downsides to leaving the default?

   As handy as the new list is, it risks confusion at first.
   Certainly not cripplingly so, and easily learnable, but
   it must be learned.  When a single control contains content
   used two different purposes, it's not necessarily a red flag
   but may be a yellow flag, requiring the designer to proceed
   with caution.

   Providing some self-evident means of turning those off helps
   communicate to the user that, handy as they are, they are of
   secondary importance to the list of handlers actually in
   the script being viewed.

   It's helpful to keep in mind that a very large majority of
   users never change any prefs in any app at all*, so anything
   we tuck away from immediate view off into a Preferences
   window should be the subset of options whose defaults are
   completely without downside.


- Are there any potential downsides to providing control over
   the setting directly in the context it applies to?

   Clutter is always a risk.

   And with anything involving reading or writing text,
   vertical space is a VERY high priority, esp. given that the
   most common screen size by far (roughly twice as many as the
   second-leading size) is only 768px tall.

   So while we always want to be mindful of clutter, we want to be
   especially mindful of vertical screen space in any layout involving
   scrolling text.

   Adding a new View pane would a poor choice for this reason.  But
   the LC SE has plenty of rarely-used space in the bottom-most group
   already there, currently used for left-aligned notifications but
   the rest usually empty.

   Since the group already has space, there seems little
   downside to considering a couple of the most frequently used
   View options there, such as perhaps hiding the suggested
   handlers and ordering of the handlers in that list.

   If that's at all problematic (textual controls are likely too
   long to fit, and icons too abstract to be worth using), having
   those available in a View menu takes no screen real estate and
   still keeps them in a more discoverable local context.

   Extra bonus points that putting that in a menu is probably
   the most cost-effective option in terms of development time.


There may be other reasons, but this has already gotten waaaay too long. :)


* In UX circles they bandy about "80% of users never change preference 
settings" so often it's usually taken for granted, but this morning as I 
noted that above I wondered about the actual research behind it.

Of course that rubric applies only to consumer apps.  There are many 
reasons why guidelines established from consumer research don't apply to 
developer tools, given the very narrow and highly specific demographic 
developers represent.

That caveat out of the way, for general app design it can be useful to 
learn about, so I did a quick search this morning.  My brief effort 
didn't turn up that original "80%" figure (would be nice if someone here 
has time to find it and provide a link), but along the way I found this 
gem from Jared Spool @ User Interface Engineering:

    What we found was really interesting. Less than 5% of the users
    we surveyed had changed any settings at all. More than 95% had
    kept the settings in the exact configuration that the program
    installed in.
    ...
    (Big takeaway: If you’re a programmer or designer, then you’re
    not like most people. Just because you change your settings in
    apps you use doesn’t mean that your users will, unless they are
    also programmers and designers.)

    We’ve repeated this experiment in various forms over the years.
    We’ve found it to be consistently true: users rarely change
    their settings.
<https://www.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/>

Like everything else at UIE.com, the details there are worth reading. 
That experiment has somewhat limited scope, but given how closely it 
seems to match other findings it seems worth at least noting the 
takeaway there:

Consider your app's defaults very carefully, because for most users 
they'll be the only options they'll ever experience.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com