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: Thu, 24 Mar 2011 18:30:09 +0000
- Thread-topic: Why does XCode 4 always open files up to maximum size?
On 24 mars 2011, at 17:56, Joar Wingfors wrote:
> Hello again Jean-Denis,
>
>
> On 24 mar 2011, at 02.37, Jean-Denis Muys wrote:
>
>>>> 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.
>
>
> I guess what I might object to is the statement about something being objectively more or less efficient. Are you making the argument that multiple-window users would more efficiently solve a problem compared to their single-window user counterparts (in some imaginary tool that allowed for both usage models)? I would certainly agree that multi-window users would feel more efficient and satisfied if they were allowed to use multiple windows, and to resize, position and overlap them freely. Would they actually have some sort of objectively measurable edge over their single-window counterparts though?
Definitely. You could measure the impact using a number of metrics. It's not hard to imagine such a study. I don't have the resources to do it. You do.
>
>
>>>> - 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.
>
>
> But what if you don't? How common is it that you have to work on two or more nib files at the same time, and need to see both of them at the same time, and not have enough space available on your existing monitor (whatever size it is) for being able to fit them in a split editor?
I don't get the argument. OK those who don't need to do complex things don't need overlapping windows. They also probably don't need Xcode. Nor a computer for that matter.
Regarding the specific example, I benefit from working with several nibs at the same time *very often*. When translating. When experimenting. Even when developing: so many new developments don't start from scratch, but branch from some existing development. My style of development at least, is very much "compare and modify".
>
>
>> 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.
>
>
> That's not an accurate representation of what it would look like in Xcode 4 though. The inspector doesn't sit inside the editor, it's shared between all editors in the window. So, it looks like this:
>
> |---------------screen width---------------------|
> |--views------------||--views------------||-insp-|
>
> ...or just like your Xcode 3 mockup. But granted, you could interleave the IB document windows in Xcode 3 and you can't in Xcode 4, so if you depend on being able to work on two or more of them at the same time, and to see all of them at the same time, you could get away with less screen real estate in Xcode 3 for sure.
>
>
>>>> - 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.
>
>
> How about I make the counter argument that single-window users would be less affected by moving to a smaller screen, because they don't have a workflow that depends on having lots of different documents visible at all times?
Who is moving to a smaller screen nowadays? My screen real estate has only increased over time. And Xcode 4 puts even more pressure in that direction. But even in this unlikely scenario: the frame model will break down and become totally unworkable sooner than the window model.
>
>
>> The concept of cognitive load is important and objective. But it's qualitative, not quantitative, until measured.
>
>
> I don't know that we should attempt to have this level of discussion on a mailing list. I think we'd need to be face to face, and perhaps have a whiteboard or two available.
Is this an invitation? I would gladly accept it! :-)
Thanks again Joar. I really appreciate your taking part in this conversation.
Jean-Denis
_______________________________________________
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