On 5/16/05 at 12:17 PM, x
xman.org (Christopher Smith) wrote:
> Travis Butler wrote:
> > That was just one example, I said above. :) The overall issue is
> > that you're partitioning your workspace, and you can't combine
> > operations with two applications in two partitions as easily as you
> > could if they were in the same partition.
>
> Absolutely true, which is why you tend to have related applications
> running in the same "partition". This is exactly why drag-and-drop
> tends to be a non-issue once you get used to using multiple desktops.
> What you end up doing is grouping things by task.
Yes, I understand the principle involved. It simply doesn't work for me;
my use is varied enough that there are no 'task groups' that remain
constant enough to actually use to partition. Sometimes I use Filemaker
together with Excel. Sometimes I use Excel with Word. Sometimes I use
Filemaker with BBEdit and Excel. Sometimes I use Filemaker, Excel, and
Mailsmith. Sometimes I use Mailsmith and Safari. Sometimes I use
Filemaker and Safari... the only pattern is that there *is* no pattern.
Games are about the only applications I can be fairly sure I won't need
to use together with something else... and even there, I like being able
to watch what's going on in the background. (Which is why I hate games
taking over the entire screen even when it's not needed, but that's a
rant for another day.)
> >>As a general rule, the way people use virtual desktops tends to
> >>make the need for drag and drop between desktops a non-issue,
> >>because nobody ever wants to do that. Still, it's good to have ways
> >>that work, regardless.
> >
> > Nobody that uses virtual desktops, you mean. For me, this is a good
> > reason *not* to use virtual desktops, because coordinating between
> > applications is something I do often enough that I don't want
> > barriers getting in the way.
>
> Well, if all your applications are typically coordinated through drag
> and drop, then I could see where you wouldn't have a need for virtual
> desktops.
It's not just drag-and-drop. It's having all applications available at
all times, instead of needing to find and switch to the particular
desktop that has a given application. It's being able to quickly switch
between two windows in *any* two applications by clicking on them. It's
being able to view windows simultaneously so you can refer to one while
working in another. It's being able to keep an eye on activity in a
background application when you're working on something in the
foreground (catching updates in my RSS reader, for example, or someone
talking in my MUCK client). I may be writing something in BBEdit while
waiting for a particular e-mail response; positioning the writing window
so I can see the inbox in the background means I don't have to keep
switching apps to check while I wait for it. There are too many
advantages to having all of my applications together, visible and
available in the same workspace for me to seriously consider
partitioning it.
> It seems unlikely to me that it is common for most people
> to have all their applications so closely connected. Even your
> average user will do some things with e-mail and a web browser while
> simultaneously doing unrelated work with office or a specific
> job-related application.
Ever played with the Project Center in Entourage? :)
Seriously, though, I see more movement towards integration than
partitioning in the general user community. Tools like Project Center,
or Six Degrees, or NoteBook/NoteTaker, that are designed to pull
together information from a variety of sources and organize it. I
suppose you could even put Spotlight into that category if you really
want to stretch things.
I can even feel a sort of vague philosophical idea hovering out of reach
- nothing I can really put into words, but a sense that the user
benefits when the system makes it easier to flow between applications
and tasks, instead of putting barriers in the way. Come to think of it,
this may go back to some arguments in the early days of the Mac, about
modal vs. modeless behavior; I think it used to be in the Apple Human
Interface Guidelines... and looks like it's still there:
<
http://developer.apple.com/documentation/UserExperience/Conceptual/
OSXHIGuidelines/index.html?http://developer.apple.com/documentation/
UserExperience/Conceptual/OSXHIGuidelines/XHIGHIDesign/
chapter_4_section_1.html>. In particular, this quote that opens the
_Modeless_ section: "As much as possible, allow users to do whatever
they want at all times. Avoid using modes that lock them into one
operation and prevent them from working on anything else until that
operation is completed." I think that applies just as much to virtual
desktop systems that partition applications into groups as it does to
applications that partition user actions into modes.
> I haven't met a Mac user yet who didn't take
> advantage of the "hide all other applications" feature once I showed
> them how it worked (doesn't mean they don't exist, just that they
> seem likely to be in the minority), and it has all the drawbacks of a
> virtual desktop with fewer of the benefits.
I beg to differ; 'Hide all other applications' leaves the hidden
applications still visible in the Dock, still accessible with a single
step, and still part of the command-tab rotation if you like to use
that. The applications aren't walled off from each other, just hidden.
Your workspace is still unified.
I've also noticed that Expose removes two of the most common reasons for
using 'Hide all others': finding a window hidden under another window,
and especially finding something on the desktop hidden underneath all
your application windows. I would also argue it's smoother in operation;
instead of hiding everything, finding what you want, and then showing
everything again, with Expose all you do is trigger-grab-release.
> >>There are more sophisticated and whiz bang approaches to doing
> >>virtual desktops that I'm sure Apple could (and most likely *has*
> >>come up with). You can easily imagine some mechanism like the fast
> >>user switching which operates independantly from the mouse.
> >
> > Why would it need to operate independently from the mouse? Ordinary
> > users would probably be more comfortable using the mouse.
>
> Because you already got the mouse tied up with a drag and drop
> operation. If you're willing to live with cut-and-paste, then this
> whole discussion is a non issue.
Are you still hung up on drag-and-drop? To repeat, that's not the issue,
though it is an example of the issue: partitioning your workspace limits
the ways you can use your applications together. See above for some
other examples.
> > Gurus may deride features like Expose as whiz-bang eye candy, but
> > in my experience they're actually used and liked by ordinary people
> > that make up the majority of that user base. Expose's operation is
> > obvious and intuitive (at least if you remember how to trigger
> > it!), and has little or no learning curve, which makes it perfect
> > for people who don't want to spend a lot of time learning to work
> > the machine.
>
> I myself wasn't taking a swing at Expose (I was more pointing at
> Dashboard), but I don't think that anyone who did would argue with
> the fact that Expose was liked and used by most Mac users. Indeed,
> that is exactly the argument. The question that is perhaps more
> worthwhile is does it actually make you more efficient? Most of the
> usability folks I've talked to have said it doesn't both from a
> theoretical standpoint and a practical one. It is eye-candy, simply
> put in because it's pleasing.
Again, I strongly disagree. More efficient? More efficient than *what*,
for *who*, measured *how*?
A) More efficient than simply clicking on part of an already-visible
window to bring it to the front? Obviously not. Of course, when you can
see enough of a window to identify it and click on it, you don't really
need Expose in the first place, do you?
B) More efficient than mousing over to the dock, clicking and holding on
the dock icon, than picking from the list of windows that pops up?
Depends on remembering what app it was in, what the window was named,
and having to endure the delay until the menu pops (anyone remember if
there's a setting that controls this? I couldn't find it when I did a
quick look just now).
C) More efficient than command-tab command-tab command-~ command-~ to
cycle through all available applications? Depends on how fast you type,
how many applications you have open, how many windows you have open -
and perhaps most important, whether you remember *where* you left it.
Even if you do remember exactly where you left it, you may still have to
traverse a long list of applications and windows to get to it. If you're
quickly swapping back and forth between two applications, cmd-tab can be
very fast, since the app switcher remembers the last app you were using;
OTOH, I've also wasted a lot of time that way, because the app order
switches on me and I let go too soon, or stop in the wrong place, and
have to do it again. Finally, I have to point out this is completely
learned behavior, that must be picked up from reading documentation and
cannot be intuited from the visible interface. I carped before about
ordinary users remembering the Expose trigger, but at least the triggers
are showin in the Expose prefpane, can thus be found through exploring
the interface, and can be changed; I don't remember cmd-tab getting a
visible interface clue anywhere, or being documented outside of the help
files.
D) More efficient than partitioning your workspace into virtual
desktops? First you have to remember what desktop a window's on. (And
have to search for the proper desktop if you don't.) Once you find and
switch to the proper desktop, you still have to go through A, B or C
above to get to the proper window. This is presumably made easier by
reducing the set of applications and windows A/B/C has to deal with. The
question is whether reducing the complexity of A/B/C is enough to
outweigh the overhead cost imposed by D. If the workspace is small to
begin with, A/B/C may not be reduced enough to make D worthwhile. If you
have trouble conceptualizing, learning or remembering the map of your
applications and windows in a partitioned workspace, the cost of D
increases and may outweigh any benefits to A/B/C.
Finally, there's the question of who is supposedly 'more efficient' and
how. As I keep trying to get across, a GUI is designed to reduce the
amount of training and memorization needed to operate a computer by
presenting its options in a visual format, where they can be scanned and
explored, streamlining operations to view, point and click and cutting
the need for learned behaviors to a minimum. Someone who's done the
cmd-tab cmd-~ dance often enough may be able to find a window faster
than someone who's triggering Expose, mousing to a window, and clicking
on it, but that's because they've *trained* themselves to do the
keyboard shuffle quickly, smoothly and with a minimum of error. For
people who don't or can't invest that time, Expose reduces the problem
to scan, point, click - exactly what a GUI is supposed to do. Arguing
that it's just 'eye candy' sounds very much like CLI die-hards arguing
that GUIs are 'just eye candy,' a passing fad that will go away.
I think John Siracusa does a good job of discussing this and other
window management issues in his review of Panther,
<
http://arstechnica.com/reviews/os/macosx-10.3.ars/7>. I think he begs
the question and asserts opinion as fact a couple of times, but I tend
to agree with his opinion.
> Fortunately it's eye candy that doesn't
> really introduce much in the way of new problems (although I'm sure
> most people have no idea how to do drag-and-drop through Expose...
> ;-). So it's not necessarily a bad thing in and of itself, but given
> the other factors that OS X needs to contend address (and I actually
> wouldn't argue virtual desktops is one of them) it's kind of like
> putting in stained glass windows when the house is on fire.
Oh, I agree there are certainly places where Apple has focused on flash
at the expense of substance. However, I don't think that Expose is one
of them. :) It solves a problem that's only grown as the number of
applications and windows a typical user works with has grown, and it
does so in a way that exemplifies the advantages of a GUI. I also have
to admit, reluctantly, that the simplicity of the Dock may be
better-suited for many users than a more featureful but complicated
program like DragThing would be - to cite a notorious example. I even
have to admit that the genie animation of minimizing windows has a
purpose beyond flash, as it provides a visual cue to the user showing
where his window went.
And finally, I have a somewhat wary view of loud complaints about
'frills' while basic functionality is unaddressed. Sometimes I think the
complaints are absolutely right - or at least much more right than
they're wrong, like Siracusa. And sometimes I think they're the 'GUIs
are window dressing' school who are unhappy because their favorite
techie feature isn't implemented or OS X isn't more like a Unix
workstation, regardless of how that fits ordinary users. (The argument
here a few months ago about case-sensitive filesystems is another
example that comes to mind.)
> There is a huge difference between features that *appeal* the
> majority of the userbase and functionality which would *benefit* the
> majority of the userbase.
Mmm-hmm. And is this 'trying to fit the system to the user's needs'
benefit, or 'you will learn to do things Our Way, it will be Good For
You' benefit? I've been hearing rather too much of the latter from both
the Jobsian Gang and the Unix Cliques, at different angles. As I said
above, I've reluctantly had to agree with the Jobsian Gang on some
issues by now, and I'd be one of the last ones to argue for
design-by-committee over unified vision (BBSW, your public is calling!)
At the same time, I think the development of OS X over time has shown a
clear case of arrogant 'we know what's best for you!' attitude that has
had to be ground down by user complaints over time, to the overall
detriment of the system. And when it comes right down to it, isn't user
appeal a big part of user satisfaction?
(I think I know what you're trying to say, that Apple has been putting
surface flash ahead of low-key usability features. And in some cases, I
agree. However, I really have to question your definition of surface
flash if you lump Expose in with 'eye candy'; heck, I wasn't that
enthusiastic about Dashboard leading up to the introduction, and now I
have to admit there's some stuff I like using it for.)
> Sure, the marketing folks will tell you to
> focus on the former, and basically only those with a janitorial
> perspective on systems building would argue for one to focus on the
> latter. In reality they are both right: if you want to sell well, you
> need to have whiz bang features that leads people's ids to say, "I
> gotta buy that", but if you ultimately want to improve the end user's
> experience (and keep them coming back for more), you have to focus on
> the latter. Ideally you want to find a balance, and pundits claims to
> the contrary aside, Apple does work on both areas with each release.
> I think it's arguable though that Tiger leans a bit more to the "whiz
> bang" side of things than previous releases, and that rightly annoys
> a lot of the "gurus" out there who are already past the point of
> making an impulse buy.
...I have to ask, and I'm not trying to be insulting - have you been
following the developer documentation on Tiger, or read Siracusa's
review of it?
<
http://arstechnica.com/reviews/os/macosx-10.4.ars>
I'll admit, I haven't been following the developer information, and
leading up to Tiger release I thought it was overhyped. Dashboard
sounded mildly interesting, Spotlight cool but overhyped and I wasn't
sure how much I'd actually use it (and so far, I really *don't* use it
much at all). So I was in the 'worth upgrading, but not excited about
it' camp. Then I read Siracusa's review, which was the first and so far
only 'general public' (all right, 'highly informed layman') review I've
read that delved into the guts of Tiger. And I was convinced.
Assuming he's right in his analysis, Tiger lays the groundwork for some
serious improvements in user experience, from providing developers
stable, consistent low-level system access interfaces to providing a
framework for fixing the mess that file-to-application mapping's been
since the public beta. (Which was brought home to me again with the
multiple test-installs I did for Tiger, as every time I ran a test I had
to spend a fair amount of time re-setting all my application bindings.
Joy.) Spotlight looks to be potentially much more powerful than what
Apple's done with it so far at the user level, and I'm looking forward
to what a lot of the small developers will be able to do with the
Spotlight API's. Little things like moving file copying into a universal
library that can be called by all applications, including both the
Finder and Unix utilities in 10.4. As a rough estimate, I'd guess that
two-thirds or more of the significant improvements in Tiger are in the
infrastructure and not the surface flash covered in the general press
reviews and even the Mac-specific press.
Travis Butler
tbutler
mac.com
![[F]](/Images/i7/site.gif){kind=small}
TidBITS 
TidBITS 