• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Why does XCode 4 always open files up to maximum size?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: JongAm Park <email@hidden>
  • Date: Wed, 23 Mar 2011 09:06:38 -0700

Thank you, Jean-Denis Muys. You explained mental side very thoroughly and it covers most of foundation of my concern.

I also have been a long time Windows/ Unix/ Mac programmers. I remember that Borland C++ Workshop was very strong and popular before MS brought Windows 3.0 and was still popular until Windows 95 came.
They also used multiple windows approaches, which is to declare independence to editor/resource editor windows from the Windows' main frame window. But at that time I didn't like their multiple window approaches. The main reason was that you were destined to decide which button to choose when you switch back to the Borland C++ Workshop.
So, although a window hosting a project and its source files should be always key window when the whole app is brought to the front, users end up bring only the editor window he/she chooses. It can be a little similar to Xcode 3.x but if users once wet their hands on it, they will feel that it is not easy to use.
I was very active in usenet at that time, and many Windows-only people didn't like Borland's approach and they liked MS's "children windows inside of a mainframe window" and call Borland's "something only Mac users would like".


But you know what? It is not matter of whether single window or multi-window approach is better than the other.
If it has good behavioral design for each, they are all good.


Problems with Xcode 4 is that Apple already had very good working model until Xcode 3. I didn't like Project Builder. It had too many same configuration window here and there. People didn't know what configuration window to use. With the first version of Xcode and till Xcode 2, Apple people enhanced it a lot. Xcode 3 was something like to finalize those enhancement.
When I used Project Builder, I reported to Apple through the radar to bring Visual Studio-like variable panes or windows.
Problem with Project Builder and Xcode was that the call stack pane and variable panes don't deliver much information. With Visual Studio, watch, auto, local, and whatever you choose can share the same rectangle. You can choose any one for your case.
Also, I suggested to put GDB window like the one in Visual Studio. ( At that time, I was converted to compact configuration not all-in-one. )
They said All-In-One configuration could solve my problem and Xcode was not Visual Studio. I knew, I knew. However, All-in-one didn't have flexibility and compact was too messy. However, after certain version of Xcode 2, things felt a lot better. Although Apple people didn't put those panes or small windows there, the behaviour of compact, all-in-one, default configuration worked better.


What was virtue of Xcode was that it was easy to open multiple project at the same time and confirm some differences between projects. Or when you want to use another project's source codes as a reference ( because the new project is just a spawn off from the original projects or you are writing client and server programs, or whatever. ) It is true that one Xcode project window can hold multiple projects, but it is different. You have much more freedom than Visual Studio programmers can have, who is just another "I". ( I work on the both platforms. )

Xcode 4 allows to host multiple projects on one workspace. However, it means that you need to introduce another file, i.e. workspace file, or adding a project to existing project's workspace. Sometimes it is good, but for certain occasions you would want to avoid the case. Also, having two separate project window gives you more freedom that to have one workspace with two projects. For example, let's say you want to confirm project settings of the two. As Jean-Deans explained, windows can be overlapped. So, you can utilize the screen real-estate maximally, and thus have two project settings window can reveal enough information to compare manually and visually.
With "pane-approach", things are captivated in a rectangle. Even though a window you designed using the embedded IB takes only small portion of screen, your opening of another IB pane in its assistance view limits the efficient use of the screen real estate.


What about search result?
Currently the search result is captivated on the slim left pane. You can resize it. OK. Good.
So, if the width of the slim left pane is not enough wide for you to check which lines of codes you are interested in, you can make it wider and click it to see the actual lines in the source editor. However, because they are side-by-side, the width of the source editor is shrunken.
So, you need to make it wider again, then your slim left pane, which is search result pane, is narrowed again. Then, if you think that you are interested in other lines of search results... you know what I mean, right?


Also, when you want to see some explanation on document view, with Xcode 3, you can see through between windows. You put source editor window related to the document up there, and put some NSWindow instance of IB a little bit right side of the source editor while put its property accessory window to a little down. You have hole on your screen now. You want to see all of them because they are related in your project and your logic in your brain. You think, "Oh.. I want to have this view on this window behave like this, and then in this source codes, hmm.. this can be better to be changed this way... then.. will there be easy method to do that for me? let me check document. Oh.. hmm. this parameter is interesting. Hmm.. oh.. you know what? I may need to use some other class for carrying the parameters, because this class has different methods working with different parameters and one of the different parameter which is in another class can be better. So, instead of using this method, I think using that method with the better parameter looks better to me. Then, OK. I would like to open the document by clicking the class name" While your brain is busy in relating all those information and continually checking UI resources and your source codes, you are confirming if your approach can be good while reading the document.
Xcode 4 makes this a little difficult.


On last Saturday, I was writing my small local search application, because Spotlight search didn't give results sometimes. ( I know that directory is indexed. However, Spotlight from time to time doesn't behave. I can use the "find". But while I'm at it, why don't write an easy app for that? Probably I can sell it! Right? But I end up with wasting time by switching back and forth source editor pane, resource editor pane and document window.

There are many example how Xcode 4 approach is worse than Xcode 3. If we meet in person, I can show those to you.

Again, I'm not saying that single window approach is necessarily worse. What I mean is current approach is worse, and why you guys changed a model which already work quite well.

Criticizing is easy and bring up original ideas are hard.
I really appreciate Xcode team's hardwork. Truly, there are really good things in Xcode 4 also.
I think those people in Xcode team know about this better than me, but I think you guys just concentrated in the "how to bring a new idea, or new workfow. How to make this look newer". So, please understand my long message as a constructional feedback from long time Xcode user who are also very familiar with other companies best tools. Even I do things I don't like when I first brings a new approach.
After having a working model or product, I can think it again to refine things or decide that my first idea was too much, or in other words, "Bend a string too much to make it straight. So, the string is bent the other side this time."


Although I would like to capture screenshots to explain situation Xcode 4 can't handle well, I would like to believe that you, Joar, understand enough already, and I would like to appreciate Jean-Denis' nice summary on metal behaviour model. ( I think by actual case or example while you are conceptual! )

Thanks,
JongAm Park

On 3/23/2011 3:36 AM, Jean-Denis Muys wrote:
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
  • Follow-Ups:
    • Re: Why does XCode 4 always open files up to maximum size?
      • From: Joar Wingfors <email@hidden>
References: 
 >Re: Why does XCode 4 always open files up to maximum size? (From: JongAm Park <email@hidden>)
 >Re: Why does XCode 4 always open files up to maximum size? (From: Joar Wingfors <email@hidden>)
 >Re: Why does XCode 4 always open files up to maximum size? (From: Jean-Denis Muys <email@hidden>)

  • Prev by Date: Re: Why does XCode 4 always open files up to maximum size?
  • Next by Date: Re: Why does XCode 4 always open files up to maximum size?
  • Previous by thread: Re: Why does XCode 4 always open files up to maximum size?
  • Next by thread: Re: Why does XCode 4 always open files up to maximum size?
  • Index(es):
    • Date
    • Thread