On 24 mars 2011, at 08:18, Joar Wingfors wrote:
Hello Jean-Denis,
Thanks for your input, it's much appreciated.
You are welcome. Let me also point out that I have switched [almost] full time to Xcode 4 and that I feel like overall, it's a rather large step forward, despite:
- numerous bugs left, most of which I'm sure will be ironed out over time.
- important missing features with very poor communication from Apple on whether this is temporary (eg IB plugins).
- the present issue which is to me the major problem with Xcode 4 (together with the issues with documentation).
On 23 mar 2011, at 03.36, Jean-Denis Muys wrote:
<snip>
The problem with Xcode 4 is that its main technology for managing screen real estate is now the pane and not the window. To organize her mental model, Xcode 4 forces the user to divide a unique window into many panes. By doing so, Xcode
4 forces the user to maximize its Xcode 4 window to full screen. By doing so, Xcode 4 prevents the user from integrating other applications into her mental model.
I can buy that argument. Yes, the single window model drives you to maximize the single window, or at least to make it rather large. A larger window makes it more difficult to work with other apps, at least if you need to view the contents from the different
apps side by side at the same time.
<snip>
To summarize, Xcode 4 puts strong pressure for getting more screen real estate because :
- it favors panes over windows to organize our screen layouts, and panes are cognitively less efficient because they can't overlap
This feels like a subjective argument to me. Then again, I'm not certain that I get what you mean. Moving on...
Subjective? It's rather objective. Here is a one-dimensionnal drawing that intends to show the difference (best seen in a monospaced font):
with this screen width:
|--------------------|
and this view width:
I can have at most 3 simultaneously visible panes:
But far many more overlapping windows (here, 6 of them):
I find this rather objective. And of course overlapping windows are partially obscured, but they are still part of the same mental model. To work in one of them you don't have to move or show anything, simply to bring it to the front. That's why their
cognitive load is much smaller than having to fully switch between competing panes.
- it requires maximizing to full screen size, thus making other apps difficult to use, unless you have more than one screen
Like I said above, I see what you mean with this argument.
- it requires inspectors to use up valuable pixels because they are not shared for all windows and they cannot float. This is particularly relevant for Interface Builder.
This I'm not sure that I agree with. Inspectors take up as much, or less, space in Xcode 4. And just like in Xcode 3, you would hide them when you're not using them.
Again this is objective. Here is a one-dimensional drawing again to illustrate.
Imagine you want to work simultaneously with 2 nib files in interface builder. For example they are almost similar, and you want to bring similar changes to them. Or they are two different localizations of the same screen. Or you want to cut/paste between
them. Whatever. With Xcode 4 I need to have:
|---------------screen width---------------------|
|--views---------|-insp-||--views---------|-insp-|
While with Xcode 3's Interface Builder I would have had:
|---------------screen width---------------------|
|--views------------||--views------------||-insp-|
(and this is assuming I don't use any overlapping. If I factor in overlapping, I can go much further in the same mental context).
As you can see in this mockup, my useable workable area is three units larger with Xcode 3, than with Xcode 4. If I need my view area to be as large with Xcode 4 as it was with Xcode 3, I need to buy a larger screen:
|--views------------|-insp-||--views------------|-insp-|
|------------- larger screen required------------------|
Or as you wrote, I need to constantly hide/show the inspectors, thus altering my mental context.
Another way to state the same thing: I need to hide the inspectors far less often with Xcode 3 than with Xcode 4.
That said, I use Aperture to organize and edit my photos. It's also a single-window app, but it has an optional floating window version of its inspector. That I quite like. Perhaps Xcode should add (back) something like that? Your opinions matter. Please continue
to think about this and discuss it in the appropriate forums, and file bug reports and enhancement requests via the Apple Bug Reporter.
- it constantly requires the user to constantly move the pane dividing lines, exponentially more with smaller screens, encouraging the purchase of larger screens.
I think you could make the counter argument that if you'd been using a many-window-model, you'd be resizing and moving windows around, encouraging the purchase of larger screens... ;-)
You are absolutely right: the more screen real estate, the better, even with a many-window model. My point is precisely that the many-window model tolerates or accommodates depletion of screen space more gracefully than the pane model by authorizing a degraded,
but still useful set up: partially obscured overlapping views.
Quite objectively, with windows you typically don't move them around, or rarely so. Most of the time you simply bring them to front. This doesn't alter you cognitive context because the geometry of your setup doesn't change. And it's acceptably easy to
do from a cognitive standpoint: simply click on the part of the window that is showing through.
On the other hand, the pane model *requires* you to change the geometry of your mental model by showing/hiding or by moving dividing line. The cognitive burden is much higher, thus putting a lot more pressure to easy that burden by purchasing yet another
of your lovely 27" screens.
Finally, this characterization of arguments as subjective/objective is very important. I understand that it is difficult to separate the subjective, from the objective, the habits from the intrinsic. I was very careful, and I spent the time, to outline
the objective reasons why I think the window model is better than the pane model:
- If it wasn't, operating systems would have stayed with the Windows 2.0 pane model
- Pane can only tile, not overlap. Windows can tile just as panes, but they can also overlap.
- Windows allow for a lighter cognitive load in a number of situation.
The concept of cognitive load is important and objective. But it's qualitative, not quantitative, until measured. Thus my next question: Apple popularized (if not invented) user testing. Have you conducted any controlled study of pane model vs window model
for Xcode? If so, could you tell us more: what was being measured? Which population were tested? How did you compensate for experience bias? How was the control group handled? If not, clearly that would bring very valuable data to this question. Apple is probably
in a unique position here as being able to setup such a study.
In the absence of such a study, analysis such as mine are the most objective way to approach the issue. User testing is the only definite way to validate those analysis.
Jean-Denis Muys.
|