When developing applications that could have a full screen view, such as
Writeroom or OmWriter, I'm interested in the users perception of the
application. Although the applications are aimed towards increased productivity
are users confused when they first launch the application? From thinking about
this problem you are introducing a new navigation method, they have lost their
normal toolbar at the top of the screen.

I understand that the first document that is shown can be a quick user guide,
buty do users read them and how do you make it accessible after first use? Is it
only worth implementing this feature by default if it is a major selling point?

Thanks for you thoughts,

-John

On 03.03.2010, at 10:39, lists@... wrote:
> When developing applications that could have a full screen view, such as
Writeroom or OmWriter, I'm interested in the users perception of the
application. Although the applications are aimed towards increased productivity
are users confused when they first launch the application?

  I think Writeroom & co. may not be the best example. They are mainly
fullscreen, and only then text editors, so users *expect* them to be fullscreen.
And Writeroom actually starts up in windowed mode, and you explicitly switch to
fullscreen.

> From thinking about this problem you are introducing a new navigation method,
they have lost their normal toolbar at the top of the screen.

  Do you mean the menu bar? Or actually a toolbar? Neither really makes sense in
this context:

Writeroom re-shows the menu bar when you move the mouse into the area where the
menu bar would be, so usage is pretty much the same, once you know that the menu
bar can be hidden and re-shown just like the dock when it is set to auto-hide.
If you're worried your users may not know this, you can do like many Flash
players do and show a little overlay temporarily that tells them how to get the
menu bar back.

And even in fullscreen mode, you could have a toolbar. It would be at the top of
the window, and it just so happens that this means it'd also be at the top of
the screen in this case.

> I understand that the first document that is shown can be a quick user guide,
buty do users read them and how do you make it accessible after first use? Is it
only worth implementing this feature by default if it is a major selling point?


  Showing long text like user guides is often not worth it. It is good for
methodical users who want to get an overview of their new software, but will
rarely benefit them beyond giving a general overview, because they're unlikely
to remember all those details. Better to provide them with information in the
context where it is actually needed and relevant.

  I can't really make sense of your last question. The short pop-up mentioned
above could help in reminding users how to get back after startup right into
fullscreen mode (mind you, that *should not* be an alert panel, that would be
annoying).

  I can't say whether your app would benefit from a fullscreen mode or not,
because you didn't say what app it is, what your target audience is etc.
Fullscreen mode can be useful or useless, a lot depends on context, how your app
is actually being used, and your concrete implementation of fullscreen.

Cheers,
-- Uli Kusterer
"The witnesses of TeachText are everywhere..."

Hi all,

I'm looking for some guidance on how undo and redo should behave.  The
AHIG is mostly silent on the topic.

That's an open-ended question I know.  But I'd be happy with any RTFM
links.  :)

One concrete example: my app is a multi-window document-based app.  I
have a main 'project' window, then multiple windows that show details of
objects contained within the project.  Consider: if the user opens such
a window, makes an undoable change, then closes the window... should I
still allow undo?  The affect of the undo would not be visible since the
window was closed, so I'm inclined to flush my undo queue when such
windows close.  Does that seem right?

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 sean@...
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada

there may not be a clear guideline about this, but i'd suggest that
the unit of undo should be "semantically" appropriate for the user
activity. in other words, i don't think the decision should be made
based on what windows are open or closed; rather, it should be made
based on whether or not the user would consider the last action part
of a semantic unit of activity that makes sense as undoable.

there are lots of apps like the one you describe, such as professional
audio applications; they often allow undo even after a window was
closed — sometimes a change is made in one window, the window closed,
the change "listened to," and then undone. it's natural, because the
action took place against a larger unit than the window itself
referred to. if the window was a self-contained home for an activity,
it would make less sense to allow undo. but i'm guessing based on your
description that your app is more like a music app, and it might make
sense to look at those for inspiration.

hope this helps!

adam
ux designer,
google

> One concrete example: my app is a multi-window document-based app.  I
> have a main 'project' window, then multiple windows that show details of
> objects contained within the project.  Consider: if the user opens such
> a window, makes an undoable change, then closes the window... should I
> still allow undo?  The affect of the undo would not be visible since the
> window was closed, so I'm inclined to flush my undo queue when such
> windows close.  Does that seem right?

The solution I found for my app was to make opening and closing
*editing* windows into commands. This way when undoing, everything is
in context. It's also more natural than not seeing anything.

My command manager simply keeps commands in a FIFO stack and supports
"composite commands" : commands made up of sub-commands. For example,
the Cut operation is made of Copy + Delete where only the delete
operation is undoable.

Undo/Redo in editing applications is a pretty fascinating subject on it's own.

--
- Nick -

One is allowed to assign key equivalents to controls like Push Buttons.

For example, one might assign Cmd-P to push button. Would you make any attempt
to let the user know that pressing Cmd-P is the same as clicking on that button?
(Perhaps, via a tooltip, in the label of the control, etc.) Or, would you expect
the user to learn about such equivalents in the documentation alone?

Depending on documentation for "discoverability" of anything within
your app means that portion of your app failed at usability in
general.

Generally speaking I'd always want to put a menu item into a menu with
all shortcuts listed in a normal app. That way those who care about
shortcuts can go find them.

Chris

On Mon, Nov 22, 2010 at 3:45 PM, EricG <mailist@...> wrote:
> One is allowed to assign key equivalents to controls like Push Buttons.
>
> For example, one might assign Cmd-P to push button. Would you make any attempt
to let the user know that pressing Cmd-P is the same as clicking on that button?
(Perhaps, via a tooltip, in the label of the control, etc.) Or, would you expect
the user to learn about such equivalents in the documentation alone?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Generally speaking I'd always want to put a menu item into a menu with
all shortcuts listed in a normal app. That way those who care about
shortcuts can go find them.

Am 22.11.2010 um 23:44 schrieb Benjamin Ragheb:
>
> On Nov 22, 2010, at 5:17 PM, Christopher Forsythe wrote:
>
>>
>> Depending on documentation for "discoverability" of anything within
>> your app means that portion of your app failed at usability in
>> general.
>>
> I agree, but only if "anything" is limited to "features" and not "keyboard
shortcuts". If shortcuts are only discovered via documentation, I don't think
that makes an app less usable. On the contrary, insisting that the keyboard
shortcuts be represented visually can lead to a less usable app, as you add more
redundant information to the display.
>
> e.g., on Windows, a ctrl-shortcut for a button would be indicated by
underlining a letter on the button label. With time, that was changed so that
the underline only appears if the control key is pressed. I think it was an
overall improvement, even if the shortcuts are less discoverable.
>

I like the way BBEdit / TextWrangler handles this: the buttons normally don't
show the shortcut, but when you hold down the cmd key for longer than a second,
the button titles change to have the shortcut appended (try e.g. with the "Do
you want to save changes to..." dialog when closing a modified window. When you
release the cmd key, the button titles return to normal.
Only drawback with this approach: you have to reserve space in the buttons for
the extended title...

</jum>

I think the first time I saw that pattern was in apps from Claris (MacWrite,
MacPaint, later ClarisWorks), and I thought it was genius. I may be
mis-remembering, but in the few cases where the buttons were shrink-wrapped
around their labels (not a good idea anyway), didn't the labels truncate with an
ellipsis to make room for the cmd-key?

_murat

On Nov 23, 2010, at 12:05 AM, Jens Miltner wrote:

> Am 22.11.2010 um 23:44 schrieb Benjamin Ragheb:
>>
>> On Nov 22, 2010, at 5:17 PM, Christopher Forsythe wrote:
>>
>>>
>>> Depending on documentation for "discoverability" of anything within
>>> your app means that portion of your app failed at usability in
>>> general.
>>>
>> I agree, but only if "anything" is limited to "features" and not "keyboard
shortcuts". If shortcuts are only discovered via documentation, I don't think
that makes an app less usable. On the contrary, insisting that the keyboard
shortcuts be represented visually can lead to a less usable app, as you add more
redundant information to the display.
>>
>> e.g., on Windows, a ctrl-shortcut for a button would be indicated by
underlining a letter on the button label. With time, that was changed so that
the underline only appears if the control key is pressed. I think it was an
overall improvement, even if the shortcuts are less discoverable.
>>
>
> I like the way BBEdit / TextWrangler handles this: the buttons normally don't
show the shortcut, but when you hold down the cmd key for longer than a second,
the button titles change to have the shortcut appended (try e.g. with the "Do
you want to save changes to..." dialog when closing a modified window. When you
release the cmd key, the button titles return to normal.
> Only drawback with this approach: you have to reserve space in the buttons for
the extended title...
>
> </jum>
>

 

I think the first time I saw that pattern was in apps from Claris (MacWrite, MacPaint, later ClarisWorks), and I thought it was genius. I may be mis-remembering, but in the few cases where the buttons were shrink-wrapped around their labels (not a good idea anyway), didn't the labels truncate with an ellipsis to make room for the cmd-key?

_murat

On Nov 23, 2010, at 12:05 AM, Jens Miltner wrote:

> Am 22.11.2010 um 23:44 schrieb Benjamin Ragheb:
>>
>> On Nov 22, 2010, at 5:17 PM, Christopher Forsythe wrote:
>>
>>>
>>> Depending on documentation for "discoverability" of anything within
>>> your app means that portion of your app failed at usability in
>>> general.
>>>
>> I agree, but only if "anything" is limited to "features" and not "keyboard shortcuts". If shortcuts are only discovered via documentation, I don't think that makes an app less usable. On the contrary, insisting that the keyboard shortcuts be represented visually can lead to a less usable app, as you add more redundant information to the display.
>>
>> e.g., on Windows, a ctrl-shortcut for a button would be indicated by underlining a letter on the button label. With time, that was changed so that the underline only appears if the control key is pressed. I think it was an overall improvement, even if the shortcuts are less discoverable.
>>
>
> I like the way BBEdit / TextWrangler handles this: the buttons normally don't show the shortcut, but when you hold down the cmd key for longer than a second, the button titles change to have the shortcut appended (try e.g. with the "Do you want to save changes to..." dialog when closing a modified window. When you release the cmd key, the button titles return to normal.
> Only drawback with this approach: you have to reserve space in the buttons for the extended title...
>
> </jum>
>

On Nov 23, 2010, at 3:05 AM, Jens Miltner wrote:

> Am 22.11.2010 um 23:44 schrieb Benjamin Ragheb:
>>
>> On Nov 22, 2010, at 5:17 PM, Christopher Forsythe wrote:
>>
>>>
>>> Depending on documentation for "discoverability" of anything within
>>> your app means that portion of your app failed at usability in
>>> general.
>>>
>> I agree, but only if "anything" is limited to "features" and not "keyboard
shortcuts". If shortcuts are only discovered via documentation, I don't think
that makes an app less usable. On the contrary, insisting that the keyboard
shortcuts be represented visually can lead to a less usable app, as you add more
redundant information to the display.
>>
>> e.g., on Windows, a ctrl-shortcut for a button would be indicated by
underlining a letter on the button label. With time, that was changed so that
the underline only appears if the control key is pressed. I think it was an
overall improvement, even if the shortcuts are less discoverable.
>>
>
> I like the way BBEdit / TextWrangler handles this: the buttons normally don't
show the shortcut, but when you hold down the cmd key for longer than a second,
the button titles change to have the shortcut appended (try e.g. with the "Do
you want to save changes to..." dialog when closing a modified window. When you
release the cmd key, the button titles return to normal.
> Only drawback with this approach: you have to reserve space in the buttons for
the extended title...

Interesting.

One thing to note about what BBEdit is doing is that they are using standard
key-equivalents for common behavior..cmd-s to save, etc.

The case I am concerned with is actually more generic then that. Let's say that
instead of a Push Button, it was a checkbox on a preference dialog and the user
was allowed to press cmd-e to change the state of that checkbox before
dismissing the dialog with the return key.

Would you even ever consider using a key-equivalent for a checkbox on a
preference dialog?

If not, why not?

If so, how would you (assuming you would) let the user know the key-equivalent
was there for usage? Would you place it in a tooltip? Would you append the
key-equivalent to the end of the label of the check box when the cmd-key was
held down?

  Personally, I find the usefulness of such functionality to be questionable and
probably a bad idea.

Am 23.11.2010 um 15:39 schrieb Eric Gorr:
> On Nov 23, 2010, at 3:05 AM, Jens Miltner wrote:
>
> > Am 22.11.2010 um 23:44 schrieb Benjamin Ragheb:
> >>
> >> On Nov 22, 2010, at 5:17 PM, Christopher Forsythe wrote:
> >>
> >>>
> >>> Depending on documentation for "discoverability" of anything within
> >>> your app means that portion of your app failed at usability in
> >>> general.
> >>>
> >> I agree, but only if "anything" is limited to "features" and not "keyboard
shortcuts". If shortcuts are only discovered via documentation, I don't think
that makes an app less usable. On the contrary, insisting that the keyboard
shortcuts be represented visually can lead to a less usable app, as you add more
redundant information to the display.
> >>
> >> e.g., on Windows, a ctrl-shortcut for a button would be indicated by
underlining a letter on the button label. With time, that was changed so that
the underline only appears if the control key is pressed. I think it was an
overall improvement, even if the shortcuts are less discoverable.
> >>
> >
> > I like the way BBEdit / TextWrangler handles this: the buttons normally
don't show the shortcut, but when you hold down the cmd key for longer than a
second, the button titles change to have the shortcut appended (try e.g. with
the "Do you want to save changes to..." dialog when closing a modified window.
When you release the cmd key, the button titles return to normal.
> > Only drawback with this approach: you have to reserve space in the buttons
for the extended title...
>
> Interesting.
>
> One thing to note about what BBEdit is doing is that they are using standard
key-equivalents for common behavior..cmd-s to save, etc.
>
> The case I am concerned with is actually more generic then that. Let's say
that instead of a Push Button, it was a checkbox on a preference dialog and the
user was allowed to press cmd-e to change the state of that checkbox before
dismissing the dialog with the return key.
>
> Would you even ever consider using a key-equivalent for a checkbox on a
preference dialog?
>
> If not, why not?
>
> If so, how would you (assuming you would) let the user know the key-equivalent
was there for usage? Would you place it in a tooltip? Would you append the
key-equivalent to the end of the label of the check box when the cmd-key was
held down?
>
> Personally, I find the usefulness of such functionality to be questionable and
probably a bad idea.

I'd say - it depends...
To be a little more specific: if the key-equivalent is mainly for power-users or
for some functionality that's not used by everybody, having the info purely in
documentation or in the tooltip is probably the better approach.
However, if you expect the key-equivalent to be useful for most users, I'd
consider implementing the delayed title adjustment method (still depends on the
UI layout, e.g. how crowded the entire UI is, is there enough space, etc.)
If this is e.g. just for one frequently toggled checkbox in a rather uncluttered
UI - why not display the key-equivalent in the title (using the delayed title
update).
However, if you have 20 checkboxes, each with it's own key-equivalent, that
approach is probably a lot less useful...

Anyway, when assigning key-equivalents, you'll have to decide which elements
should get key-equivalents at all (based on frequency of usage, probably).

I don't think there's a generic answer to this question - after all, users will
be able to use the UI without the key-equivalents, so it's not a big deal if
they don't discover them, but you'll need _some_ way to tell the users about the
key-equivalents, otherwise you'll be the only person using them ;-)

just my €.02,
</jum>




Jens Miltner
jum@...

--
when I find my code in tons of trouble,
    friends and colleagues come to me,
        speaking words of wisdom
             "write in C"

Gentlefolk,

EricG wrote:
>One is allowed to assign key equivalents to controls like Push Buttons.
>
>For example, one might assign Cmd-P to push button. Would you make
>any attempt to let the user know that pressing Cmd-P is the same as
>clicking on that button? (Perhaps, via a tooltip, in the label of
>the control, etc.) Or, would you expect the user to learn about such
>equivalents in the documentation alone?

And also wrote:
At 17:30 -0500 22/11/2010, Eric Gorr wrote:
>This particular button would be on a modal dialog and the key
>equivalent would be specific to that dialog.
>
>It would basically just be a shortcut to the functionality readily
>available to the user by just clicking on the button.
>
>It is not uncommon for shortcuts undiscoverable except by reading
>the documentation, so I am not sure I would consider it a failure.

I'm a fan of Bare Bones's approach on this front.

When BBEdit drops down a document-modal sheet, hold the Command-key
down for half-a-second or so, and the Command-key equivalents for
buttons and other options in the sheet are displayed.

For example (Warning: ASCII-diagram ahead. If you aren't viewing this
using a mono-spaced typeface it will look awful), if you hit
Command-W or click the close button in a dirty window BBEdit drops
the following document-modal sheet:


	 Do you want to save the changes to "[document name]"?

	 If you don't save, your changes will be lost.

	 +----------------+    +----------+  +----------+
	 |   Don't Save   |    |  Cancel  |  |   Save   |
	 +----------------+    +----------+  +----------+

Hold down the Command key for half-a-second and the sheet displays
the following:

	 Do you want to save the changes to "[document name]"?

	 If you don't save, your changes will be lost.

	 +----------------+    +----------+  +----------+
	 | Don't Save  D |    |  Cancel  |  | Save  S |
	 +----------------+    +----------+  +----------+

Similarly for other document-modal sheets (such as the Change Case sheet).

It's not hugely discoverable, since it relies on the user knowing to
hold the Command key down. That said, and despite Bare Bones
documenting this niftiness (on page 127 of the current [BBEdit User
Manual][1] for example), I discovered this UI touch by accident.

      [1]: <http://pine.barebones.com/manual/BBEdit_9_User_Manual.pdf>

I long ago learned that Command-. (Command-full stop or
Command-period) is a nigh-on universal 'cancel' or 'stop' equivalent.
Once upon a long ago I accidentally pressed Command-W in a dirty
BBEdit window and nearly reflexively started to press Command-. to
activate the Cancel button. I happened to be looking at the screen at
the time and saw the text in the modal dialogue box (this was in Mac
OS 7.x days) buttons change.

I've been a regular user of this BBEdit feature ever since.

Hope this is at least diverting, if not useful.

Regards,

Brian Forte.
--
words, edits, type, layout, code
<mailto:bforte@...>
<http://betweenborders.com/>

Hi folks,

  since it's so quiet in here, I thought I'd mention that I recently blogged
about

	 "The menu must die" http://blog.orangejuiceliberationfront.com/?p=329

Would be interested what you people think (there's a comment form, too :-) )

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.lookandfeelcast.com

Hi,

  if you guys are interested in hearing lectures about
Human-Computer-Interactions, iTunes U has some nice lectures on "Designing
Interactive Systems" - in fact a year's worth of classes:

	 http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=390393818

and a second year can be found at:

	 http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=390393962

There's also this term's version, which you can subscribe to as a Podcast to get
the new classes as they get released:

	 http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=390393723

Welcome to our global study group :-)

-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.masters-of-the-void.com

I need to disable a NSTableView which is sitting inside of a NSScrollView. Doing
so is straightforward, but what I did notice was that the scrollbars weren't
disabled -- nor would I necessarily have expected them to be.

But, it did get me thinking as to whether or not they should be. So, I check the
HIG and couldn't find anything on this topic.

Did I miss something in the HIG?

I tried hunting around a little to see what other people did, but couldn't
really find anything.

Thoughts?

On Thu, 13 Jan 2011 09:14:29 +0100, Jens Miltner said:

>Whether or not the scrollbars should be disabled, depends a little on
>the usage for the table view when it's disabled. Why do you need to
>disable the table view at all?
>Generally, though, when the table view is disabled, from a user
>perspective, I'd expect the scrollbars to be disabled, too (unless
>there's good reason why I would scroll through a disabled table view).

What does it mean for a control to be 'disabled' anyway?  In a way, it's
like a read-only mode.  So you could argue that a disabled tableview
should still allow 'reading' which may need scrolling.  OTOH, a disabled
popup does not allow you to inspect the choices within.

--
____________________________________________________________
Sean McBride, B. Eng                 sean@...
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada

On 12.01.2011, at 18:34, EricG wrote:
> I need to disable a NSTableView which is sitting inside of a NSScrollView.
Doing so is straightforward, but what I did notice was that the scrollbars
weren't disabled -- nor would I necessarily have expected them to be.
>
> But, it did get me thinking as to whether or not they should be. So, I check
the HIG and couldn't find anything on this topic.
>
> Did I miss something in the HIG?
>
> I tried hunting around a little to see what other people did, but couldn't
really find anything.

  Scroll bars are not controls in the traditional sense. Unlike sliders, they
don't change anything in the *model*. All they do is let you *view* more than
would fit into a window/on the screen.

  Now, if there is enough data in your table for the scroll bars to be enabled,
why would you bother adding those items if you then prevent the user from seeing
them all?

  See scroll bars as a kludge to deal with limited screen real estate. You
wouldn't turn off part of the screen when the user can't use those items. You
keep them visible (so the user knows they're normally there) and just draw them
inactive so the user knows they're not applicable *at this particular moment*.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.lookandfeelcast.com

We're having some discussion about
applicationShouldTerminateAfterLastWindowClosed: and in what situations it's
appropriate to return YES from this method. Mostly, this is in response to
Apple's approach in the Mac App Store where closing the window quits the app
rather than just closing the window. Any good examples of apps that implement
this properly?

Except the menu items for new contacts are greyed out. Can still edit template
and whatnot, so I guess that still counts, but it’s not as strong a case as I
thought before.