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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
