Tiger's keys and cursors

On May 21, 2005, at 3:31 PM, Dan Frakes wrote:
> All I can say to that is, "Thank heavens for the modern OS ;-)
>
> (Seriously, I'm very glad I can select text and then start typing
> to replace
> it. Considering how many times I want to replace text in the average
> document/email/etc., having to manually delete such text before I can
> replace it with something else is an unnecessary step, in my
> opinion, when
> the Undo command can get back any text lost from the occasional
> mistake.)
>

I agree. Having to first delete text and then type the replacement
text adds a step for a common operation. This reminds how Alan Cooper
criticizing programmers for adding extra steps just to be sure that
the user really wants to do that.

On 21/5/2005 4:28 AM, "John C. Welch" <jwelchbynkii.com> spake thus:

> It's more work that gains me nothing other than having to hit the delete
> key. May as well ask me if I'm sure, as long as it's wasting my time.

<cmd-Q>

"Are you sure that you want to quit this fine application? (Yes) (No)"

%^$#&^%$&^%$!!!

:)

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

--On 5/23/2005 9:40 AM -0700 Paul Chernoff <pchernoffwashingtonian.com>
wrote:

> I agree. Having to first delete text and then type the replacement text
> adds a step for a common operation. This reminds how Alan Cooper
> criticizing programmers for adding extra steps just to be sure that the
> user really wants to do that.

Yeah. He gripes about the print settings dialog box... but in the case
where you want the default settings, having the print command be "Cmd-P,
Enter" instead of simply "Cmd-P" prevents spewing paper uselessly when you
hit the wrong key at a fairly small cost to the user who does want to print.

(One thing I was annoyed by about BBEdit was the small difference between
Cmd-Shift-P ("print without confirmation") and Cmd-Ctrl-P ("preview in web
browser"). I kept having to cancel errant print jobs when my fingers were
in the wrong place and I wanted to preview. Fortunately, BBEdit allows you
to turn off command-key equivalents and after a few minutes frustration
last night I killed the Cmd-Shift-P shortcut altogether.)

Cooper seems to have the following logic...

(1) Programmers should make everything undo-able, plus
(2) Having users take unnecessary steps is bad, implying
(3) Any form of confirmation is bad.

However, at the interface between the computer and the physical world (in
fact, at the interface between the computer and the world outside it),
there is no longer a power to undo. In the simple printing case, there's
no way to "undo" the printing of a document.

In much more complicated network situations, there's a lot of stuff you
can't "undo" without control that reaches far outside your machine: Sending
an email, making a purchase on the Internet, placing a bid on eBay...

So point (1) is more properly described as "Programmers should make things
that can be undone undo-able", and in that context it makes sense to add
additional confirmation when something cannot be undone.

Dave

--On 5/23/2005 9:40 AM -0700 Nigel Stanger
<nstangerinfoscience.otago.ac.nz> wrote:

> On 21/5/2005 4:28 AM, "John C. Welch" <jwelchbynkii.com> spake thus:
>
>> It's more work that gains me nothing other than having to hit the delete
>> key. May as well ask me if I'm sure, as long as it's wasting my time.
>
> <cmd-Q>
>
> "Are you sure that you want to quit this fine application? (Yes) (No)"

I have to say I _love_ the Mozilla/FireFox confirmation when quitting or
clicking would close multiple tabs.

I often have lots of tabs open, and cmd-Q is only one key away from cmd-W.
At least once a week, in Safari, I would hit cmd-Q when I intended to hit
cmd-W and lose a whole bunch of pages that I'd opened and planned to read.

In a document-based application like Word, it makes sense to have no
confirmation for quit other than the query to save document changes. But
when an application (a) has significant user-determined state and (b)
resets that state in the quit-restart process, it makes a lot of sense to
add some sort of verification to the quit procedure to avoid losing the
user's state.

Dave

Den 23. maj 2005 kl. 18.40 skrev Nigel Stanger:
> <cmd-Q>
>
> "Are you sure that you want to quit this fine application? (Yes) (No)"
>
> %^$#&^%$&^%$!!!
>
> :)

I would be more than happy if we had that in Safari. Accidentally
hitting cmd-Q instead of cmd-W when having 100 tabs open is not fun.
I even edited cmd-Q out of the Danish localisation in order not to
hit it!

;-.)

Kim

On 23 May 2005, at 10:40 , Nigel Stanger wrote:
> <cmd-Q>
>
> "Are you sure that you want to quit this fine application? (Yes) (No)"

Yes, but how many apps do that? I can't think of any.

If there's an unsaved document open, then asking to save it is a good
idea. If you are closing the last window, and that will quit the
app, that might be ok. Asking to confirm a simple quit would NO be
ok. I, for one, would be annoyed.

--
I find Windows of absolutely no technical interest... Mac OS X is a
rock-solid system that's beautifully designed. I much prefer it to
Linux. -- Bill Joy

On 5/24/2005 10:26 AM, "Dave Scocca" wrote:
> I have to say I _love_ the Mozilla/FireFox confirmation when quitting or
> clicking would close multiple tabs.
>
> I often have lots of tabs open, and cmd-Q is only one key away from cmd-W.
> At least once a week, in Safari, I would hit cmd-Q when I intended to hit
> cmd-W and lose a whole bunch of pages that I'd opened and planned to read.

Have you seen Taboo?

<http://www.macworld.com/weblogs/macgems/2005/05/taboo/index.php>

On 25/5/2005 5:26 AM, "Google Kreme" <gkremegmail.com> spake thus:

> Yes, but how many apps do that? I can't think of any.

Not many; those that do are usually unusual apps that have been ported from
something else. (I've come across a few Java-based database tools recently
that do this.)

I certainly have no argument with a confirmation when it makes sense. It's
the apps that ask if I'm sure that I want to quit when there are no open
windows and nothing else happening that drive me nuts. It makes me feel like
I'm not really the one in charge (OK, I know that I'm not really, but leave
me my illusions :) Instead, it feels like the application (and by extension
the developer) is condescendingly patting me on the head and saying "I know
better than you".

It makes me wonder whether the developers who implement such "features"
actually use the products that they create on a regular basis.

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

[Seems to me we're drifting a lot here. Let's try to keep it Tiger-specific... -Adam]


> I have to say I _love_ the Mozilla/FireFox confirmation when
> quitting or clicking would close multiple tabs.

A definite "me, too" here. I suppose this was the case for a vast number of
people, since the feature got added.

[...]
> In a document-based application like Word, it makes sense to have no
> confirmation for quit other than the query to save document
> changes. But when an application (a) has significant user-determined
> state and (b) resets that state in the quit-restart process, it makes
> a lot of sense to add some sort of verification to the quit procedure
> to avoid losing the user's state.

Or the application could (optionally) avoid resetting that state in the
quit-restart process. For example, although the close-multiple-tab
confirmation dialogue was initially very useful to me, now that I have my
session automatically saved and restored, it doesn't matter so much (and is
close to being annoying).

(There are many extensions that do this sort of thing. For example:
<https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=6
25>
<http://piro.sakura.ne.jp/xul/tabextensions/index.html.en>
<http://extensionroom.mozdev.org/more-info/sessionsaver>
)

I think you could do similar things in (e.g.) Word, too. It's already doing
autosaves of the documents - closing could do a final autosave, and not
prompt you. When you start it up again, if you want to work on whatever
document you had open before you quit, you could access it via something in
the UI.

It seems to me that this makes for a more intuitive interface - there's no
need to do some sort of "save" (or "file") action with a physical document -
we just find it where we left it. I suspect people might find it equally
intuitive to do this with software.

=Tony.Meyer

At 10:26 AM 05/24/2005 -0700, Dave Scocca wrote:
>I have to say I _love_ the Mozilla/FireFox confirmation when quitting or
>clicking would close multiple tabs.

Opera allows you to re-open closed windows/pages, and can be configured
(trivially) to re-open on startup all windows/pages it had open before
quit/reboot.

Why do so many applications fail at these? Why should closing a window not
be undoable? Why should state not persist over a reboot? Why are we talking
about kludges to prevent things that have such obvious solutions?

Edward
Art Works by Melynda Reid: http://paleo.org

[OK, this is the last off-topic post in this thread. -Adam]


On May 24, 2005, at 11:26 AM, Dave Scocca wrote:

> I have to say I _love_ the Mozilla/FireFox confirmation when
> quitting or
> clicking would close multiple tabs.
>
> I often have lots of tabs open, and cmd-Q is only one key away from
> cmd-W.
> At least once a week, in Safari, I would hit cmd-Q when I intended
> to hit
> cmd-W and lose a whole bunch of pages that I'd opened and planned
> to read.

How much more elegant to simply save your state and restore the tabs
when you next launch your browser? OmniWeb does this (and lets you
save multiple "workspaces" of opened windows and tabs so you can end
a web session and return to it later) and it's WONDERFUL.

<http://www.omnigroup.com/omniweb/>

Between state saving an true undo/stepping backwards through history,
confirmation dialogs should be totally unnecessary. If you do
something wrong, you can undo it.

Of course, that puts a heavy onus on developers to support these
features, but some of the new technologies in Tiger that CoreData
supplies, this might be easier than it once was.

--Nik

Edward Reid wrote:

> Why do so many applications fail at these? Why should closing a window
> not be undoable? Why should state not persist over a reboot? Why are we
> talking about kludges to prevent things that have such obvious solutions?

What, exactly, is the obvious solution to making a web browser resume
where it left off after a reboot? Consider that after the reboot:

        You might be on a different network, and may no longer have
        permission to access the page, because that page was on
        your internal corporate network, and you are now at home.

        The page might of had session cookies associated with it, and
        those cookies have now expired.

        The page might of be the result of submitting a form, and its
        contents might of expired from the cache.

        The page might of changed between the time you shut down the
        machine and restarted it.

        Your server-side session might of timed out.

        The page, or a plugin on it, might be connected to the server.
        Not only has the connection timed out, but you might have a new
        IP address now.

        You might not have an Internet connection anymore.

This is only a short list of things that might go wrong. Resuming a
web-browsing session last had an "obvious solution" in, maybe, 1995.

On 5/27/05 15:44, "Anthony DeRobertis" <anthonyderobert.net> wrote:
> What, exactly, is the obvious solution to making a web browser resume
> where it left off after a reboot? Consider that after the reboot:
>
> You might be on a different network, and may no longer have
> permission to access the page, because that page was on
> your internal corporate network, and you are now at home.

There are other issues, mostly all security related.

On the administrator side, one of the primary purposes of a reboot is to
wipe the slate clean as it were. If it stops doing that, then you have to
deal with "what KIND of reboot do you want to do..." etc.

Jef and a lot in his camp tended to only see things from a very specific
POV, and while that POV has validity, it's not the only legitimate one, nor
the most legitimate one for all situations.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 01:44 PM 05/27/2005 -0700, Anthony DeRobertis wrote:
>This is only a short list of things that might go wrong.

Eppur si muove. Yes, but in practice it works very well in Opera. Some
pages don't re-open or persist for any and all of the reasons you mention
and more, but for the most part it simply represents an update of reality.
Pages that fail to load (say due to network connectivity issues) remain
active and can be reloaded explicitly or by the next restart. Pages which
have simply expired so indicate.

Part of the reason that I see so much success is that I get used to this
persistence and leave static pages open when I'll want to notice them again
soon, rather than bookmarking them or using some other marking/saving
mechanism. So I tend to see quite a few open pages/windows persisting.

Some of these issues might have better solutions if more people expected it
to work and used web browsers that did their best. Currently, with only a
tiny fraction of the web-browsing public using browsers that even attempt
persistence, there's precious little motivation for the standards bodies,
web server implementors, and browser implementors to develop improvements
in this area.

Edward
Art Works by Melynda Reid: http://paleo.org

--On May 27, 2005 1:44:02 PM -0700 Anthony DeRobertis
<anthonyderobert.net> wrote:

> What, exactly, is the obvious solution to making a web browser resume
> where it left off after a reboot? Consider that after the reboot:
>
> You might be on a different network, and may no longer have
> permission to access the page, because that page was on
> your internal corporate network, and you are now at home.
>
> The page might of had session cookies associated with it, and
> those cookies have now expired.
>
> The page might of be the result of submitting a form, and its
> contents might of expired from the cache.
>
> The page might of changed between the time you shut down the
> machine and restarted it.
>
> Your server-side session might of timed out.
[snip]

Most of these issues deal with a laptop that moves around. This doesn't
argue against the need for the feature, but that it should be setup as an
option so the user can decide if this feature is helpful or not.

More and more people are on broadband connections with desktop computers.
The feature maybe very desirable in that situation. Heck even when I had a
laptop the request isn't too different than the effect I would get when I
would sleep my computer, with the browser still open, then go to the local
coffeeshop, and fire back up on a new network. 99% of the time I had no
problems. I don't think Apple should throw out a feature because of failure
in 1% of the cases (if they did they should get rid of Safari altogether.)

In most of these situations, even the ones not caused by moving to a new
network, full session information shouldn't be stored -- just the window
position and frame/URL positioning. It should pretty much work like the
back button does. If the session times out or is no longer valid the user
gets an error, just like might happen with the back button.

Kevin

On May 24, 2005, at 3:52 PM, Dan Frakes wrote:
>
> Have you seen Taboo?
>
> <http://www.macworld.com/weblogs/macgems/2005/05/taboo/index.php>

Ooooo. On a Dvorak keyboard, the "Q" is where you normally think of
"X", which means that a misplaced thumb can quit an application. I
do it rarely enough that it doesn't bug me too much, but this is
definitely a nice insurance policy in the one app where I'm likely to
lose data when I do that.

Thanks,
Jeff

--On May 28, 2005 1:12:01 AM -0700 "John C. Welch" <jwelchbynkii.com>
wrote:

> On the administrator side, one of the primary purposes of a reboot is to
> wipe the slate clean as it were. If it stops doing that, then you have to
> deal with "what KIND of reboot do you want to do..." etc.

By this thinking we should get rid of Startup Items too. After all many
people put their Mail program in Startup Items and set to auto-login -- I
don't see that much different from auto-resuming a couple of web pages.
Heck I have so many apps in my Startup Items it takes longer for me to
login that the machine does to boot. I wish Launchd would speed up Startup
Items launches too.

It seems silly to me to not put in an option because the 1% case where it
is a disadvantage rather than an advantage. My normal user isn't an
administrator account anyway, so when I reboot to do something
administration wise I login as my admin account -- which has nothing in
Startup Items. But I still see where I might use this feature as an
administrator. Open Safari as administrator and a window with 3 tabs open:
Support page for my mini, software downloads, and the support advanced
search page.

<http://www.apple.com/support/macmini/>
<http://www.apple.com/support/downloads/>
<http://search.info.apple.com/>

On 27 May 2005, at 14:44 , Anthony DeRobertis wrote:

> Edward Reid wrote:
>
> What, exactly, is the obvious solution to making a web browser resume
> where it left off after a reboot? Consider that after the reboot:

None of this matters. The browser saves a cache of all the open
pages, this cache is opened. All the pages that were open are open
still.

Where you go from there is up to you, but all the info that was in
front of your eyes when you shut down is once again in front of your
eyes.

--
Can I borrow your underpants for 10 minutes?

On 5/28/05 09:37, "Kevin van Haaren" <kevinvanhaaren.net> wrote:
> By this thinking we should get rid of Startup Items too. After all many
> people put their Mail program in Startup Items and set to auto-login -- I
> don't see that much different from auto-resuming a couple of web pages.
> Heck I have so many apps in my Startup Items it takes longer for me to
> login that the machine does to boot. I wish Launchd would speed up Startup
> Items launches too.

What I'm seeing is a request for OS level preservation of workspaces.
Application - level preservation is one thing, OS level is another.

john

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 19:57 -0700 UTC, on 2005/05/29, Kevin van Haaren wrote:

[...]

> Heck I have so many apps in my Startup Items it takes longer for me to
> login that the machine does to boot. I wish Launchd would speed up Startup
> Items launches too.

launchd *does* deal with Startup Items. You mean Login Items! ;) (Tiger even
finally correcty labels them "Login Items".)


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>