6 ms·

Xcode UI Improvements

112 points by jpedroso 16y ago

bokchoi 16y ago
Microsoft did a usability study on a similar grouping of APIs by usage in Visual Studio. The end result was it was harder to find what you are looking for than using the alphabetical ordering. The lesson for API designers: group related methods by prefix so they can be predictably found in code-complete popups.
- rbanffy 16y ago
  Prefixing methods is ugly. Methods should be named after what they do. Squeak (not sure about other Smalltalks) has a thing called protocols: a method belongs to a given protocol and the browser shows it to help you explore your classes. Depending on the method name, the browser can suggest a protocol to file it within. A "sort by protocol" could then be useful in this scenario - provided you had some way to tell the IDE where your method should be grouped.
jpedroso 16y ago
Every single proposal you make is very much welcomed and needed. Wondering if any of this is feasible with a Xcode plugin or should we just wait/wish for Apple to pick this up?
- weaksauce 16y ago
  I didn't think that Xcode had an API that would allow this. To my knowledge the only thing the API allows is adding differ end ways to build things. For example, adding fortran support natively. I could be wrong though. I agree this is the way that the code autocompletion should be though.
  - gte910h 16y ago
    It has a very poorly specified api. Here is a plugin template: http://github.com/phausler/XcodeAPI/tree/master/Xcode%20Plug-in%20Template/ http://github.com/phausler/XcodeAPI/tree/master/Xcode%20Plug... Here is a (pretty detailed) description of what API there is: http://xcodeapi.versv.com/ http://xcodeapi.versv.com/
    - weaksauce 16y ago
      Interesting! It looks like the main thrust is for additional languages but there seems to be a way to do extra code completion: http://www.obdev.at/products/completion-dictionary/index.html http://www.obdev.at/products/completion-dictionary/index.htm...
- potatolicious 16y ago
  The only thing I disagree with is the visual dropdown for enums (e.g., the modalPresentationStyle). At the end of the day we're still writing code - I feel like instead of English-equivalent descriptors like "Full Screen", "Page Sheet", etc, it needs to labeled with the actual programmatic name. This way the UI is a transparent, helpful supplement to code, not an opaque interface. This way when I type: viewController.modalPresentationStyle = it will pop up the list of possible values, along with visual aids, but I can just keep typing the value I want and tab-complete it. This keeps workflow smooth and prevents me from having to exercise the mouse, and keeps me focused on the code I'm writing rather than creating something that's more of a wizard. The imageNamed example is a good one: it displays the string you'd use under each icon, and hopefully the search narrows as I begin to type the image name. Quick workflow-easing popups should not require users to interact with them.
  - grinich 16y ago
    You could solve this easily by only activating it after a period of inactivity. Stop typing for a second, and the suggestion box pops up. I think it would save a lot of typing with the UIViewAutoresizingMasks. Those are always a pain.
    - potatolicious 16y ago
      You misunderstand what I mean - personally I find it impossible to remember the crazy number of enums that iPhone programming foists upon you, so the popup of options is greatly welcome. The thing I don't like about that is that instead of displaying the name of the enum, it displays a human-friendly name. I love the menu, but I'd rather not move my mouse to select one of the options, nor move my hands to the arrow keys to navigate it. It'd be great for the popup menu to provide the actual programmatic name (along with the awesome visual aid of what the enum actually means) so I can just start typing the first few characters of what I want, hit TAB, and complete it. Similarly, if I want to include an image, the popup with the image previews is awesome, but I'd rather not have to move my mouse to scroll through it and pick it out. Odds are I have some notion of what the name begins with.
    - 16y ago
- rbanffy 16y ago
  Plugins for Xcode would be great. My first candidate is one that helps you write code that will run under GNUStep. If Macs have 10% market share than being able to port your code to all other Unixes with a simple recompile would increase your market by about 10%. And Mac programmers could help by filling whatever blanks GNUStep may have.
aaronbrethorst 16y ago
You know what would be an awesome Xcode UI improvement? A Find feature that isn't completely broken. Back in Xcode 3.0 (I think), Apple replaced the old single-file Find dialog (i.e. Cmd-F) with one of those newer style inline search bars (like what you see when you do an in-page search in Safari or Firefox). Great in theory, and completely broken in practicality. Setup: Create a UIViewController, go to the implementation file, scroll to the bottom, insert your cursor. - Wrap-around search only works intermittently: Search for initWithNibName. It will tell you at least one match exists, but it won't show it. Hit Cmd-G to try to make it wrap around. It might work, it might not. Who knows?! Weirdly, I found just now that if I switch over to the header file (by pressing Cmd-Option-Up Arrow) and then switch back that wrap-around search magically starts working. - Case-insensitive search only works intermittently: search for initwithnibname. It will, most likely, tell you that no matches were found. - Single-file find and replace requires me to take my hands off the keyboard. It is not possible (at least by default) to enable single-file find and replace without moving the mouse cursor to the drop down on the left side of the Find 'strip' and choosing Find & Replace from the menu.
- teaspoon 16y ago
  Not to mention that locating the search-in-selection feature is now tantamount to discovering an easter egg. I had to google it.
  - aaronbrethorst 16y ago
    I had NO idea that existed. Care to share the trick?
    - teaspoon 16y ago
      Hold the option key and see which button changes!
      - conover 16y ago
        The find feature in Textmate is the same way. I'm not sure how that became prevalent. It's really difficult to notice if you are new to an application.
loveat528hz 16y ago
Please get hired by apple.
- watmough 16y ago
  Yes, I second this. An absolute tour-de-force article, which I've skimmed and plan to go back an re-read. One point though, successive versions of XCode help have got slower and slooowwwwer. The current 'public' release is wretched compared to even a couple years ago. This is reminiscent of what happened to Visual Studio / Visual C++, in that Visual C++ 4.2 (?) had a fantastic super-speedy help, which basically slowed down to a crawl in later versions, and lost its 'tight' feel. Even if nothing else in XCode got fixed, speeding up the documentation would be a big step forward.
grinich 16y ago
His pixel-by-pixel criticisms are also great. http://emberapp.com/bwalkin http://emberapp.com/bwalkin
petewarden 16y ago
XCode is an awesome IDE, way better than Eclipse, and nicer than Visual Studio+Visual Assist, which was a surprisingly strong combo. But, it keeps getting crippled by its need to do fancy UI stuff to impress Steve. Wheee, pretty iChat bubbles for errors! A find using standard Apple conventions! A per-edit file history! In theory these would be fine, if a bit irrelevant to my daily coding, but inevitably the execution breaks something important that used to work. The find problems are documented elsewhere in this thread, but my personal bug-bear is the file history. You used to be able to cycle back and forth through the files you'd opened in a window, which was an awesome way of building up a working set without having to think. Now if you make an edit, all of your 'forward' history is lost. See the comments here for others bitten by that: http://stackoverflow.com/questions/1724655/xcode-3-2-1-file-history-via-keyboard-shortcut http://stackoverflow.com/questions/1724655/xcode-3-2-1-file-... It's not that the XCode team aren't aware of these bugs, all of Apple's internal developers use it and give feedback, but their priorities seem to be driven by demo-ability not usability.
- mirkules 16y ago
  I am annoyed by the error bubbles too because they truncate the actual error message - you have to open a whole new window just to see the entire message. In Eclipse, you get a red (X) in the sidebar on which you can click (and a list of problems) so you never have to fight any extraneous windows just to see your error in context. In my opinion, Eclipse is way better than XCode (not to mention more versatile), and Eclipse's code assist (or whatever they call it) is far superior to XCode's precisely for the reason outlined in this article.
- sshumaker 16y ago
  I disagree entirely. There's a lot of things it does poorly - from managing the list of files in the project (why can't I have it just choose a directory?), it's half-baked implementation of Open Quickly, and it's bad find UI. But all of this wouldn't be an issue if XCode was easily extendable with plugins. And this is where Eclipse and Visual Studio wins out - you can download plugins to do almost anything you need, and to customize it exactly the way you want it. This is the most glaring omission from XCode, and it's really long past due.
- 16y ago

112 points by jpedroso 16y ago

Microsoft did a usability study on a similar grouping of APIs by usage in Visual Studio. The end result was it was harder to find what you are looking for than using the alphabetical ordering. The lesson for API designers: group related methods by prefix so they can be predictably found in code-complete popups.

rbanffy 16y ago
Prefixing methods is ugly. Methods should be named after what they do. Squeak (not sure about other Smalltalks) has a thing called protocols: a method belongs to a given protocol and the browser shows it to help you explore your classes. Depending on the method name, the browser can suggest a protocol to file it within. A "sort by protocol" could then be useful in this scenario - provided you had some way to tell the IDE where your method should be grouped.

jpedroso 16y ago

Every single proposal you make is very much welcomed and needed. Wondering if any of this is feasible with a Xcode plugin or should we just wait/wish for Apple to pick this up?

weaksauce 16y ago
I didn't think that Xcode had an API that would allow this. To my knowledge the only thing the API allows is adding differ end ways to build things. For example, adding fortran support natively. I could be wrong though. I agree this is the way that the code autocompletion should be though.
- gte910h 16y ago
  It has a very poorly specified api. Here is a plugin template: http://github.com/phausler/XcodeAPI/tree/master/Xcode%20Plug-in%20Template/ http://github.com/phausler/XcodeAPI/tree/master/Xcode%20Plug... Here is a (pretty detailed) description of what API there is: http://xcodeapi.versv.com/ http://xcodeapi.versv.com/
  - weaksauce 16y ago
    Interesting! It looks like the main thrust is for additional languages but there seems to be a way to do extra code completion: http://www.obdev.at/products/completion-dictionary/index.html http://www.obdev.at/products/completion-dictionary/index.htm...
potatolicious 16y ago
The only thing I disagree with is the visual dropdown for enums (e.g., the modalPresentationStyle). At the end of the day we're still writing code - I feel like instead of English-equivalent descriptors like "Full Screen", "Page Sheet", etc, it needs to labeled with the actual programmatic name. This way the UI is a transparent, helpful supplement to code, not an opaque interface. This way when I type: viewController.modalPresentationStyle = it will pop up the list of possible values, along with visual aids, but I can just keep typing the value I want and tab-complete it. This keeps workflow smooth and prevents me from having to exercise the mouse, and keeps me focused on the code I'm writing rather than creating something that's more of a wizard. The imageNamed example is a good one: it displays the string you'd use under each icon, and hopefully the search narrows as I begin to type the image name. Quick workflow-easing popups should not require users to interact with them.
- grinich 16y ago
  You could solve this easily by only activating it after a period of inactivity. Stop typing for a second, and the suggestion box pops up. I think it would save a lot of typing with the UIViewAutoresizingMasks. Those are always a pain.
  - potatolicious 16y ago
    You misunderstand what I mean - personally I find it impossible to remember the crazy number of enums that iPhone programming foists upon you, so the popup of options is greatly welcome. The thing I don't like about that is that instead of displaying the name of the enum, it displays a human-friendly name. I love the menu, but I'd rather not move my mouse to select one of the options, nor move my hands to the arrow keys to navigate it. It'd be great for the popup menu to provide the actual programmatic name (along with the awesome visual aid of what the enum actually means) so I can just start typing the first few characters of what I want, hit TAB, and complete it. Similarly, if I want to include an image, the popup with the image previews is awesome, but I'd rather not have to move my mouse to scroll through it and pick it out. Odds are I have some notion of what the name begins with.
  - 16y ago
rbanffy 16y ago
Plugins for Xcode would be great. My first candidate is one that helps you write code that will run under GNUStep. If Macs have 10% market share than being able to port your code to all other Unixes with a simple recompile would increase your market by about 10%. And Mac programmers could help by filling whatever blanks GNUStep may have.

aaronbrethorst 16y ago

You know what would be an awesome Xcode UI improvement? A Find feature that isn't completely broken. Back in Xcode 3.0 (I think), Apple replaced the old single-file Find dialog (i.e. Cmd-F) with one of those newer style inline search bars (like what you see when you do an in-page search in Safari or Firefox). Great in theory, and completely broken in practicality. Setup: Create a UIViewController, go to the implementation file, scroll to the bottom, insert your cursor. - Wrap-around search only works intermittently: Search for initWithNibName. It will tell you at least one match exists, but it won't show it. Hit Cmd-G to try to make it wrap around. It might work, it might not. Who knows?! Weirdly, I found just now that if I switch over to the header file (by pressing Cmd-Option-Up Arrow) and then switch back that wrap-around search magically starts working. - Case-insensitive search only works intermittently: search for initwithnibname. It will, most likely, tell you that no matches were found. - Single-file find and replace requires me to take my hands off the keyboard. It is not possible (at least by default) to enable single-file find and replace without moving the mouse cursor to the drop down on the left side of the Find 'strip' and choosing Find & Replace from the menu.

teaspoon 16y ago
Not to mention that locating the search-in-selection feature is now tantamount to discovering an easter egg. I had to google it.
- aaronbrethorst 16y ago
  I had NO idea that existed. Care to share the trick?
  - teaspoon 16y ago
    Hold the option key and see which button changes!
    - conover 16y ago
      The find feature in Textmate is the same way. I'm not sure how that became prevalent. It's really difficult to notice if you are new to an application.

loveat528hz 16y ago

Please get hired by apple.

watmough 16y ago
Yes, I second this. An absolute tour-de-force article, which I've skimmed and plan to go back an re-read. One point though, successive versions of XCode help have got slower and slooowwwwer. The current 'public' release is wretched compared to even a couple years ago. This is reminiscent of what happened to Visual Studio / Visual C++, in that Visual C++ 4.2 (?) had a fantastic super-speedy help, which basically slowed down to a crawl in later versions, and lost its 'tight' feel. Even if nothing else in XCode got fixed, speeding up the documentation would be a big step forward.

grinich 16y ago

His pixel-by-pixel criticisms are also great. http://emberapp.com/bwalkin http://emberapp.com/bwalkin

petewarden 16y ago

XCode is an awesome IDE, way better than Eclipse, and nicer than Visual Studio+Visual Assist, which was a surprisingly strong combo. But, it keeps getting crippled by its need to do fancy UI stuff to impress Steve. Wheee, pretty iChat bubbles for errors! A find using standard Apple conventions! A per-edit file history! In theory these would be fine, if a bit irrelevant to my daily coding, but inevitably the execution breaks something important that used to work. The find problems are documented elsewhere in this thread, but my personal bug-bear is the file history. You used to be able to cycle back and forth through the files you'd opened in a window, which was an awesome way of building up a working set without having to think. Now if you make an edit, all of your 'forward' history is lost. See the comments here for others bitten by that: http://stackoverflow.com/questions/1724655/xcode-3-2-1-file-history-via-keyboard-shortcut http://stackoverflow.com/questions/1724655/xcode-3-2-1-file-... It's not that the XCode team aren't aware of these bugs, all of Apple's internal developers use it and give feedback, but their priorities seem to be driven by demo-ability not usability.

mirkules 16y ago
I am annoyed by the error bubbles too because they truncate the actual error message - you have to open a whole new window just to see the entire message. In Eclipse, you get a red (X) in the sidebar on which you can click (and a list of problems) so you never have to fight any extraneous windows just to see your error in context. In my opinion, Eclipse is way better than XCode (not to mention more versatile), and Eclipse's code assist (or whatever they call it) is far superior to XCode's precisely for the reason outlined in this article.
sshumaker 16y ago
I disagree entirely. There's a lot of things it does poorly - from managing the list of files in the project (why can't I have it just choose a directory?), it's half-baked implementation of Open Quickly, and it's bad find UI. But all of this wouldn't be an issue if XCode was easily extendable with plugins. And this is where Eclipse and Visual Studio wins out - you can download plugins to do almost anything you need, and to customize it exactly the way you want it. This is the most glaring omission from XCode, and it's really long past due.
16y ago