

Xcode UI Improvements - jpedroso
http://www.brandonwalkin.com/blog/2010/06/03/xcode-ui-improvements/

======
aaronbrethorst
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
Not to mention that locating the search-in-selection feature is now tantamount
to discovering an easter egg. I had to google it.

~~~
aaronbrethorst
I had NO idea that existed. Care to share the trick?

~~~
teaspoon
Hold the option key and see which button changes!

~~~
mortenjorck
Yeah, that's always been a bit of a usability problem. Hidden gestures are
really just the new "hold a random modifier key and watch what happens!"

------
bokchoi
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
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.

------
grinich
His pixel-by-pixel criticisms are also great.

<http://emberapp.com/bwalkin>

------
jpedroso
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?

~~~
potatolicious
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
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
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.

------
loveat528hz
Please get hired by apple.

~~~
watmough
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.

------
petewarden
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-...](http://stackoverflow.com/questions/1724655/xcode-3-2-1-file-
history-via-keyboard-shortcut)

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.

~~~
statictype
Maybe it's because I'm relatively new to OS X but I find Visual Studio and its
single-window interface vastly more efficient and usable than Xcode+IB and
it's plethora of open windows.

~~~
krevis
Have you tried the "All-in-one" layout in Xcode? (Look in the "General"
preferences section.) I find it a lot more usable than the default lots-of-
windows setting, especially if you have more than one project open.

~~~
statictype
Never tried. Thanks for the tip.

