2009 / February 23^rd/ Do people really like the window management in xCode?

I posted some thoughts to twitter last night about how much the xCode window management drives me insane. What I got back was a huge reaction of “it’s perfect” and “this is how OSX works” Suddenly I was wondering, am I just insane for thinking the window management is absolutely horrible?

No, no. I’m not. It’s horrible. Just because Apple built it, does not make it perfect.

Tabs are the future (actually it’s been the standard for years)

Tabs have clearly proven themselves to be a superior method for editing multiple code files. Why? Because the most recognizable thing about code file is it’s filename. Not the look of the text. Let’s look at this through some examples.

Case #1: Window-based management FTW, Photoshop

Window management in OSX defaults to a new window for each document. This works wonderfully for most applications when you can see the differences visually. Photoshop is a great example. Using Exposé, I can see which document I mean to be working on at a glance The visual representation of the document is the unique identifier.

Some more points on why this works so well:

• Image documents are the only windows you will ever see in Photoshop. Everything else is a panel. This functionality is the same for all five-star document-based apps. iWork, iLife, etc. There is a really good reason Apple chose to hide panels when activating Exposé.
• Photoshop is a document immersive program. It’s unlikely you’ll be working on more than one PSD at a time. The document is all that matters. Conversely with code, the project is all that matters (not one code file).

Case #2: Tab-based management FTW, Texmtate

Window management for Textmate is handled via tabs and a persistent sidebar. At a glance, you can see all files you’re currently working on. In the case of Cocoa, you are often switching between interface & implementation files, but this is easily handled via cmd-opt-up, so long as you have the name of the class right, you’ve got the right file.

Some points on why this works so well:

• Windows provide a way to group files in a meaningful manner. Each window is a unique project. Remember, the project is the important thing — when coding in Cocoa, you’ll need to edit multiple files at once to make them work with one another.
• I can quickly move between individual files via the keyboard. Considering coding is almost purely typing, keeping my hands on the keyboard is killer.

Case #3: WTF-based management FTL, xCode

Window management for xCode is handled via a combination of this thing called a Project window, which morphs depending on it’s toolbar state, windows for each document, and windows for ancillary programs (like the model editor). Please note I have the same number of windows open in this screenshot as I did in Textmate (7). It’s actually a pretty small program, but completely overwhelming.

Some points on why this doesn’t work so well:

• Windows mean different things. Some mean code documents, some mean visual aid, some mean a kind of “project” that groups all things.
• The project window continually morphs it’s state as you enter and exit debugging. It’s appearance is different, not upon your application’s state, but rather the toolbar button in the upper left, that automatically changes (one-way).
• All the code looks the same. There is no unique identifier in Exposé mode. I must selectively hover over each file and read it’s filename. Or, I can exposé to try and find the project window (which can look much like a code window too), and then open a new document.
• If I accidentally Cmd-W the Project window, I have to start from scratch, opening the whole project and each document again. This often happens as you accidentally open windows and want to immediately close them.

Some may counter, telling me that xCode offers editing inside the project window. Sure, this works, but offers just as many frustrations.

• You must single click on files to open them. Double-clicking them still opens them in a new document.
• Because of the above, and the last bullet on the previous list, I constantly find myself accidentally closing the project because I was trying to close an accidentally opened window.
• Unless I choose not to run my program, I constantly have to switch out of debug mode and back into editing mode via the toolbar.
• Every single time I open xCode I have to force it into editor mode.
• There is a delay in single clicking a document. You click the file on the sidebar, the sidebar highlights, but the new document doesn’t open in the editing window for a second or two. When trying to scan documents for some code, this results in endless confusion.
• There’s no idea of “open files” in this mode. No context for which I’m working. I can’t say, work on the View Controllers by opening each of them. Each time I must select the unique view controller in the sidebar, ordered alphabetically.

It’s a shame

It’s a shame, because other than the window management, xCode is really an awesome IDE. The actual text editing is great as is debugging, scriptability, and file management. It really helps solve all the problems that Cocoa apps force upon mere text editors (long method names, class names, files being in one directory, different types of files in the same directory, etc).

It’s the program’s fatal flaw in my mind. It isn’t that it’s sub-par, or not good enough — it’s downright infuriating to use. I want to do mean things to cute kittens whenever I use it. So I don’t. I use TextMate. Which actually is very good at Cocoa & Objective-C. But it means much more typing (especially with the shift key) since TextMate favors tab-triggers rather than tab-completion.

At the end of the day, this is the kind of stuff I hope Mac developers care about. It’s about making the user experience the #1 priority in software development. And it’s something that I’m confident Apple knows about and intends to fix in future versions of xCode. Because they care about the user experience.

1. 

   James

   February 23^rd | #

   Yeah, it’s a bear when you are new to it. Most Cocoa OpenStep/NeXTStep developers have been around so long that the evolutionary changes to Project Builder / XCode have been small over a long period of time. We are just used to the way it works.

   I agree, there needs to be an interface redesign for XCode. Especially with all the new developers jumping on board due to the iPhone and increasing OS X popularity.

   Culturally, it may stem from the original NeXTStep Project & Interface Builder design. Which at the time it was developed, was revolutionary and there simply was nothing else like it out there. i.e. NeXTStep is really Cocoa and that’s why all the API’s start with “ns”.

2. 

   Kyle

   February 23^rd | #

   James: That’s more or less what I expected. It happens with every platform that’s around a long time. Eventually the small interface tweaks just need to be completely rethought as a whole (OSX is a great example in this regard — no incremental change to OS9 would have gotten to OSX). I’m sure the xCode team is aware of it, but hopefully it’ll be a top priority in the next release.

   I was mostly just surprised to find so many mac devs that thought the window management in xCode was good.

3. 

   Jamie Kirkpatrick

   February 24^th | #

   Kyle

   I couldn’t agree more. I’ve developed in both XCode and Visual Studio on a professional basis for years now and XCode is shocking in it’s lack of usability. And it is indeed highly irking that a lot of the development community choose to turn a blind eye because it’s an Apple app so it must be right. They couldn’t be more wrong.

   Great post.

   Jamie

4. 

   jacob

   February 24^th | #

   I agree completely. I have been doing iphone dev for a couple months and I can go crazy pretty quick especially if you have multiple projects open. I wish xcode was more like eclipse.

   You’re not alone =)

5. 

   Jim

   February 27^th | #

   I’d have to agree with you Kyle. I’ve worked with a lot of different IDE and non-IDE environments. And XCode at first look, ranks up there on the “what the hell were they thinking” scale. As I’ve too have started venturing down the Cocoa / Objective-C path, when comparing it to other IDE’s, it feels like something is missing, which I think is a lack of a configuration that allows you to focus on what you’re doing. In part it’s due to the vast array of windows and tools you encounter from the Project Manager, Debugger, Interface Builder, Profiler, etc. I’m finding that with XCode, I typically have more dozens of floating windows open that I’m constantly flipping through to get something done.

   I would agree that XCode’s origins go back to NeXTStep, during a point in time when NeXT like IBM, Microsoft, Borland, and others were toying and trying to promote a non-traditional method of programming, which were more or less bastardized variants of Visual Programming applied to traditional languages. The idea behind pure VPL’s being that you pictorially ‘draw’ your program. Little or no code is actually ‘typed’ Languages that are considered VPL’s are designed from the ground up to be pictoral. What seemed to happen in the mid to late 90’s is that several tried the unthinkable, bring the concepts of VPL to upcoming languages like Basic, C++ and Java to make them seem more palatable to a wider, less technical audience. A slurry of IDE’s made debut’s VisualAge, Visual Basic, Builder, and the list goes on. Visual Basic is certainly the most successful, as the UI still lives a semblance of its life today in Visual Studio – which is often regarded as one of the best IDE’s around.

   Now circling back around to XCode XCode tries to do just that to developers. However I don’t believe it’s a whole-hearted effort. It’s still very rag-tag in that XCode is really a suite of seemingly unrelated tools that somehow integrate together. It’s alot like the ‘old Unix days’ when you had a myriad of tools to build an app… simple editor, compiler, linker, makefiles, etc. XCode appears to basically add Interface Builder which growing out from the company who challenges us to Think Different, it doesn’t surprise me that they took a very visual approach to make what was typically the most painful part of an application (the graphical ui) a cake walk. This is certainly a welcome addition to anyone who’d programmed for X could agree. That said, I’m convinced that to be proficient and successful with XCode, you have to start thinking visually, something a lot of programmers are not necessarily adept at doing.

   What I believe XCode needs is a more ‘unified’ IDE. I believe IB is a great tool, but it’s not enough to make the IDE. If Apple were to ‘complete the effort’ and make it more of a ’single view’ ide that integrated the suite of tools together better, allowing the user to focus more on a single task at a time – they could certainly give Visual Studio a run for it’s money. But until then, it’s going to drive us all crazy while we all are gonna try our fortune at the iPhone.

   BTW: If you’ve ever tried using the ‘competitors’ IDE for the BlackBerry… even with all the problems of XCode… RIM has an extremely long trail to catch up as it seemingly was designed by the same guy who thought ballots with chads that could hang was a good idea.

6. 

   Window management mit xCode. at .pindarsign|blog

   March 3^rd | #

   [...] Wapspire fand ich interessante Ideen zum Thema Usability und Fenstermanagement. Ich kann dem Blogbeitrag [...]

7. 

   Michael Parmeley

   March 10^th | #

   I agree with your article regarding the window management of XCode; however, I was flabbergasted by this statment:

   “It’s a shame, because other than the window management, xCode is really an awesome IDE.”

   I am flabbergasted because XCode is a horrible IDE. An IDE should help you be more productive and take care of boiler plate stuff on its own without bothering me with them. I am really surprised I can’t find many “XCode sucks” pages with a google search. My only guess is that Mac developers by and large haven’t used IDEs for other languages and specifically the incredible IDEs available for Java (IntelliJ being the premier one, but I will throw Eclipse in there as well). So Mac developers don’t realize what XCode COULD be doing for them, but it isn’t. If I write things down as I use it I could probably come up with 40-50 things that make it horrible. However, here a just a couple of things it should do but doesn’t:

   1) It has no VI key bindings, this slows me down more than anything. I don’t want to use the mouse to move code around. Please let me keep my fingers on home row, VI accomplishes this; at least give me h,j,k,l navigation and yy, dd, and p.
   2) It should auto-import header files, why bother me with this? Just do it.
   3) Why do I have to wait until compile time before XCode tells me a header file is missing and it can’t find a class? It can see that at the time I am writing the code.
   4) When I type a method signature in my header file, please just stub it out for me in the implementation file.
   5) If I declare a property in the header file, please just synthesize it in the implementation file.
   6) If I reference a member variable I have declared yet please offer to add it to the header file for me.
   7) If I add a method to my class please add its signature to the header file for me.

   Holy crap, I would just keep going and going. But I will stop for now.

8. 

   flo

   March 11^th | #

   your article summarzies just what I thougt.
   I like xcode for many things, but the window management is a disaster.
   so much time that get’s lost searching the correct window …
   I realy like cmd-t in textmate :)

9. 

   Robert Aubin

   March 16^th | #

   Agreed. Transitioning from Textmate to xcode was/is one the hardest shifts I’ve had to make in a while….way to call them out!

10. 

    Ashemah

    March 17^th | #

    OMG!!! How did you read my mind?? I previously used Visual studio heaps and XCode just sucks balls. And I mean really, I am not just saying that because the key-bindings are different or I have something against Macs.

    Man, get MDI already guys! Millions of windows just mean millions more possibilities for the window I want to be hidden by another window!

11. 

    Robert Stehwien

    March 17^th | #

    You are not alone – I call the XCode windows “flopping fish windows management”. I cannot stand it. I’ve used Visual Studio, TextMate, Emacs, Eclipse, and several other IDEs and XCode is the worst in terms of usability. Occasionally I open xcode, get reminded why I don’t like it, then continue using emacs.

12. 

    j o a r

    March 20 | #

    Thanks for taking time in thinking about and writing about your experiences and impressions of working with Xcode.

    To me this article seems to mostly revolve around comparing Xcodes multi-window layouts to other editors All-in-One layout. That seems a bit unfair, since Xcode does have a fully functional All-in-One layout. You raise a handful of issues with this layout mode, most of which I think can either be dismissed, or fixed by configuring Xcode to behave differently:

    [1] You must single click on files to open them. Double-clicking them still opens them in a new document.

    Yes that’s true. Get over it.

    [2] Because of the above, and the last bullet on the previous list, I constantly find myself accidentally closing the project because I was trying to close an accidentally opened window.

    I agree that this is unfortunate, but again, once you get used to it I don’t think it can be said to be a big deal.

    [3] Unless I choose not to run my program, I constantly have to switch out of debug mode and back into editing mode via the toolbar.

    [4] Every single time I open xCode I have to force it into editor mode.

    In “Xcode Preferences > Debugging > On Start” switch to “Do Nothing”. This will change the behavior to leave you in the editor, while still presenting you with the in-editor debugger bar. Problems #3 & #4 solved.

    [5] There is a delay in single clicking a document. You click the file on the sidebar, the sidebar highlights, but the new document doesn’t open in the editing window for a second or two. When trying to scan documents for some code, this results in endless confusion.

    This is simply not true. Well, perhaps if you have a very, very, underpowered machine. If there’s any delay, I can assure you that it’s certainly sub-second, and it’s there to allow you to quickly scroll in the list using the keyboard (without having to load each and every file).

    [6] There’s no idea of “open files” in this mode. No context for which I’m working. I can’t say, work on the View Controllers by opening each of them. Each time I must select the unique view controller in the sidebar, ordered alphabetically.

    Yes there is, look in the file history pop-up.

    The only difference between a traditional tab view and the file history pop-up is that you can only see the name of the currently selected file document in Xcode. Note that for traditional tab views you typically end up with a zillion small tabs and a lot of file documents in the overflow menu in any case, so this difference is typically less important than what you might expect at first glance.

13. 

    Mike Weller

    April 20 | #

    I completely agree. XCode is extremely frustrating. I use the single-click method to navigate between files, but on my rotated monitor there isn’t much horizontal space so the groups and files pane takes up too much room. Showing/hiding it is just annoying because there isn’t a keyboard short that I can find to do this, so I just don’t bother.

    Give me tabs dammit!

14. 

    gts

    April 26^th | #

    I agree, and telling people to “just get over it” is really counter productive. How can one not agree that If there is a superior practice, then one should adopt it? That seems to be the point with XCode – it is not adapting well established best practice – like Tabs and a true All-in-one interface. A lot of people keep screaming “just get used to it!”. Why should we when there are better ways to do things?

    For all the coders I know, it all boils down to two things:

    1) We want Tabs. They work, we know they work, and we know the current XCode setup sucks by comparison. The history pop-up is nearly useless – for large projects it ends up mostly full of files I don’t really want to see anymore, and at some point the hot-key commands can’t get you to the file you want. What I need is quick visual access, as in tabs and hot-key switching, to something like K important files – usually 4<K<20. Any clutter here, or extra key and mouse input, is a complete waste of time.

    Show me a way to move between a set of k high-priority files, to visualize this set, to know which one I’m about to switch to, and to do so with just one ctrl-tab style command, and I’ll pipe down. XCode does not have this fundamental capability.

    2) We want true All-in-one mode. We don’t want extra context switches all the time — it’s really a waste of time. The “all-in-one” mode does not go far enough, as it STILL splits debugging mode from the main browsing/editing mode. They really should have called it “two-in-one”.

15. 

    Cyril Godefroy

    May 12^th | #

    I like the way I use XCode, withe the all in one combined to well known keyboard shortcuts.

    XCode is itself a redesign of Project Builder. And in the process, they added x-zillion different ways to see the windows due to the fact that developers asked for this and that and what if I could also do this.

    If you use the default behaviour, you shouldn’t be happy. If you use the all-in one on a notebook, you might be happier. Keeps you focused on the current task at hand. If you need to open 5 different windows to work, you’re multi threading. And multi threading is bad.

16. 

    mdhughes

    May 12^th | #

    You need to learn how to use Xcode, every single thing you are complaining about is already in Xcode.

    Also, how to spell Xcode: big “X”, little “code”.

    If you don’t like the multiple-window interface, you can change to “all-in-one” in preferences.

    Use the filename dropdown (Ctrl-1) above the editor to switch between open documents; it’s a tab, just vertical instead of horizontal. “Close File” will remove a file from the filename dropdown.

    Debugging does not have to switch to a different mode; in the Debug preferences, choose the Mini Debugger. Voila, inline debugging.

    If you don’t like “Close Window”’s behavior, change the keybinding so “Close File” is Cmd-W, “Close Window” is Opt-Cmd-W.

    All of this is in the basic Xcode tutorial. If you aren’t reading the documentation, you will fail to produce any usable Cocoa software, anyway. Visual Basic is for dummies, Xcode is for smarties. Up to you to determine which you are.

17. 

    Mark

    May 12^th | #

    No matter what the default settings are for an IDE, there will always be people that prefer another way.

    I’m not an expert on Xcode either, but to be fair, you should at least take a quick look through the preference settings before dissing it.

18. 

    Kyle

    May 12^th | #

    @Mark, @mdhughes: I’d appreciate if you re-read the section titled Case #3: WTF-based management FTL, xCode

19. 

    doug

    May 12^th | #

    Maybe the favorites bar or bookmarks would help?

20. 

    Anthony

    May 12^th | #

    How can someone appreciate Xcode if this same person doesn’t know how to spell it.

21. 

    zack

    May 12^th | #

    Photoshop on the Mac (at least recent versions) is hardly a good example of good windowing behaviour. Why the crap doesn’t cmd+` cycle though open documents like every other OS X application in existence?

22. 

    dude

    May 12^th | #

    You have 2 choices here:

    1) just use textmate

    2) learn how to customize xcode to your preferences, it’s not hard, yes, i read the article… you’re doing it wrong

23. 

    bacon

    May 12^th | #

    “pending on it’s to” should read its

24. 

    miles

    May 12^th | #

    i see you biting facebook layout and design in that first screenshot…

25. 

    Lally Singh

    May 12^th | #

    Yeah, it’s bad. I do the same thing on there that I have to do with every other IDE, that is, make them act like CodeWarrior :-)

    Specifically, setup BBEdit (or Emacs, depending on your platform) as your external editor, and make the IDE window a little more than a build button and a file list.

    Then it kinda works.

    Also, there’s pbxbuild (I think that was the name) which just builds it on the command line.

26. 

    Jason

    May 12^th | #

    Xcode baffled me too at first. The All-in-one setting was key. Only two things still make me crazy:

    1. Need to use the mouse to switch back to edit mode from run/debug mode.

    2. Having to hit “command-E” to make the top frame go away. (I think it’s file listing/project details frame). I don’t mind doing this once, but it pops up ever freaking time I click on the target or executable in the left frame, and I have to close it again.)

    If anyone knows how to fix these quirks, I’d LOVE to hear about it.

27. 

    Kyle

    May 12^th | #

    It’s pretty dissapointing to see the quality in comments drop as soon as this article hit Hacker News (May 12). Oh well, such is life. I’m closing comments on this entry now. Thanks for the feedback everyone.