Re: Why does XCode 4 always open files up to maximum size?
Re: Why does XCode 4 always open files up to maximum size?
- Subject: Re: Why does XCode 4 always open files up to maximum size?
- From: Jean-Denis Muys <email@hidden>
- Date: Wed, 23 Mar 2011 10:36:15 +0000
- Thread-topic: Why does XCode 4 always open files up to maximum size?
On 23 mars 2011, at 06:41, Joar Wingfors wrote:
>
> On 22 mar 2011, at 17.14, JongAm Park wrote:
>
>> I interpret Xcode 4 as a message from Apple :
>>
>> "You are developer. Don't buy 13" notebooks. Also, try our cool LED screens. You can hook up the nice screens".
>>
>> In your case, you need at least 3 screens. Good thing is whenever you don't really need to see all those, you can be OK with "spaces" from time to time.
>
>
> That Xcode 4 should require more screen real estate compared with Xcode 3 is an opinion that I've heard voiced before, but never quite understood. Can someone explain to me why that would be the case?
>
> You can navigate the whole workspace / project from the Jump Bar in the editor, that's new for Xcode 4, or using the good old Open Quickly. No need to keep the Project Navigator visible if you're on a smaller screen. You can of course always show / hide it as needed. The same goes for the Utility Area. The source editors themselves use less horizontal space on chrome such as the breakpoints gutter, etc. compared with Xcode 3, leaving more room for actual content.
>
> I understand the complaints about the changed workflows, and the lack of single-purpose document windows, but this is one argument that I don't get.
>
>
> j o a r
>
I really share that feeling that to be efficient with Xcode 4, a screen the size of a football field is now needed. To explain why and to what extent would be a long endeavor that I may undertake, so this is only scratching the surface here.
First you have to understand where I am coming from: I am a Mac user who has had to work with Windows machines professionally. This dual perspective lead me to deeply grasp a few usability points, eg:
- I often work with applications from several vendors at the same time, OpenDoc not withstanding, this means several windows open simultaneously *in the same mental context*. When developing, I may have the terminal, Pixelmator, the IDE, TextMate all open. Seamlessly switching between Pixelmator and Interface Builder is a useful proposition. This mental context benefits from having both IB Window AND Pixelmator window *visible* at the same time. *open* at the same time is *not* the same. The cognitive load on short term memory from having to switch between mutually hidden windows is high.
- this is why I always felt that the Windows users habit of "maximizing" their windows is totally counter productive, especially with Windows' dumb way of always maximizing to the whole screen.
- this is also why the way Windows put menu bars inside Windows is counter productive: it forces the user to maximize its windows to full screen size for Fitts' law's sake.
- the end result is that Windows users tend to have their mental contexts more focused on *one* window. Working with several windows on Windows ironically imposes a much higher cognitive burden that on the Mac. This fundamental cognitive burden is why somebody here even claimed that Mac OS X command-tab panel was wrong to show apps and not Windows. This is significant.
This leads to the fundamental question: why windows? why *several* windows even? or even why *overlapping * windows? The answer to me is:
---> Windows are the tools to visually organize your mental context when screen real estate is a limited resource. <---
This has several consequences. For example:
- when screen real estate is not limited, windows have little added value. For example, to play a game of mine sweeper, as long as your mine field fits on your screen, there is no need for windowing. Screen real estate is not a limiting factor here.
- as soon as your mental context may involve more than one application, the visual organization scheme will need to integrate those applications. Independent windows were invented for that. OpenDoc tried to imagine a different concept within a single window.
- the more complex the mental model to organize, the more flexible the organizing tools need to be. Arguably, software development involves mental contexts that are very complex.
- importantly, partially overlapping windows still allow for a richer mental context, even when screen real estate seems to have been totally depleted. Partially overlapping windows are still part of the same mental context. Granted, overlapping windows cannot show 100% of all content, but they *are* a graceful degradation when the screen real estate resource is depleted.
The crucial point is that screen real estate is a very valuable resource that is limited. As with any limited valuable resources, the efficiency of the technology that uses it directly goes towards extra mileage that can be extracted from the resource.
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.
Now I recognize that my use of the "force" verb in the paragraph above is too strong, even incorrect. Xcode 4 doesn't "force" the user that way, because it still lets us use multiple windows. But the end result is almost the same, because using multiple windows with Xcode 4 requires a much larger cognitive load. And with Xcode 4 I will almost always have at least one window screen-maximized, which I never had with Xcode 3.
Taking a step back, Xcode 4 offers two technologies to use screen real-estate: independent windows, and panes inside windows. Panes are strongly favored by Xcode 4. However, panes are significantly inferior to windows when it comes to organizing the user's mental context. Because they cannot overlap. This means that when the screen real estate resource runs out, they cannot go the extra mile with that graceful degradation.
This is so very clear and painful in this example: Interface Builder for iPad applications. In all but larger screens, with Xcode 4 it's impossible to have the iPad mockup, the view inspector, and the view library all visible on the screen without significant cognitive burden:
- burden : you will want to hide the top button bar, thus visually altering your carefully set-up mental model (even if only temporarily).
- burden : you will want to hide the left hand side file navigator thus visually altering your carefully set-up mental model (even if only temporarily).
- burden : the iPad mock up will not fit in its pane, and you will have to scroll through its pane to see it all, never seeing 100% of it at any time. Note that this is much worse than having the mock up partially hidden by a floating window that you can move aside any time.
- burden : the library will be very small, forcing you to scroll through it. Or you will grow it, thus visually altering your carefully set-up mental model. And even then, you still loose, because you lost most of your inspectors.
The workflow then becomes a constant fight, hiding/showing panes, dragging pane divider lines. All that because you cannot have them overlap. All that because you cannot tear them off in their own windows.
And if you decide to cut your losses and invest in several windows any way, you still lose the screen real estate race: each window has its own inspectors, wasting pixels by duplicating them.
So you end up throwing money at it and buying more screens. You don't solve the problem, but you push it back.
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
- it requires maximizing to full screen size, thus making other apps difficult to use, unless you have more than one screen
- 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.
- it constantly requires the user to constantly move the pane dividing lines, exponentially more with smaller screens, encouraging the purchase of larger screens.
Voilà. That was very long. I hope my English was not too French and that I managed to get my point at least partially across.
Jean-Denis Muys
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden