Mac Text Editors and Navigation
inessential.com
inessential.com
The most basic web page development exercise - 1 browser window and 2 editor windows for html and css - is ruined because I can no longer MRU cycle the 3 windows.
I would say this is one of the biggest usability mistakes on the Mac. Sadly, Unity & Gnome 3 have both copied this. Meanwhile, I don't fight the platform but use it the way it was meant to be - keyboard + mouse. But I'll be shifting back to Linux or Windows for all non Mac/iOS development.
Update: thanks to comments pointing me to Witch. However, I still stand by my criticism of the built-in Mac desktop behavior.
I'm finding the list style still has high mental overhead compared to the Windows/Linux style of bringing the target window (or it's outline) transiently forward.
Still, looks like it's 80/20 enough that I'll be parting with $14 soon!
I have it bound to alt+tab. Super customizable, I have things like ignore all minimized applications, only windows in this space and ignore any window from adium.
Lets me easily switch between terminals, vim windows and browsers that are on the same space. Highly recommend.
I get a warning that some apps might not like command-tab being taken by Witch - have you faced any issues?
Whatever the reason, they're wrong for us power users. And possibly for intermediate & beginners users as well.
Then again, I'm not doing web development, so I'm not trying to cycle between my editor and one particular browser window.
I don't think it's a power-user vs. beginner issue; it's more of a workflow style issue.
For example, chat is mostly fine. I'm either switching between multiple chat windows or mentally switching from chat to another task in which case I have no problem switching out of the whole chat app.
The same setup goes wrong when one chat window is for work, and I'm going back and forth with another non-chat work window.
For me, it's a better default to switch entire applications than windows. There are edge cases, sure, like the chat one you mention, or different browser windows, but I'd rather just switch from Excel to IE to Outlook than have to tab through my history of open documents and browser tabs (curse you IE) to get back to my Outlook window.
It sounds like for you, it's the opposite: the better default would be to switch windows, not apps.
The question then is which is the most common pattern, but I don't know of any actual research on this. You can't generalize from personal experience, plural of anecdote and all that.
As an added bonus, the input line disappears if you press Ctrl-G again, hit <esc>, or press enter without entering anything. So, fast and easy to get into, fast and easy to get out of.
So I have to constantly do the sequence: swear out loud - press escape - Cmd-C - Cmd-F again - Cmd-V.
That's just dumb.
With all due respect, what is just dumb is not reading the manual of the powertools you use every day and blaming them for your lazyness.
>With all due respect, what is just dumb is not reading the manual of the powertools you use every day and blaming them for your lazyness.
I thought the point of Mac was that you didn't have to read the manual ;)
But yes, in this case, mea culpa.
You don't have to read the manual to perform the most common tasks. But if you want to perform more advanced/specific tasks, reading the manual is necessary.
Cmd-F searching for the highlighted text involves one key-press. What you describe requires two key-presses.
The former is quicker and easier, and I think that makes it preferable.
Pretty much everything to do with computers, from Operating System features, to program and UI features, are ultimately about making it quicker and easier to perform tasks.
Wanting more convenience is not laziness. The goal of computer systems should be to provide more convenience.
However, binding two different actions to one trigger is pushing the logic too far.
It could happen that I have some text selected and I want to search for something within that text, or that I've selected something by mistake and I want to search something else… In that kind of situation having the search field populated by the content of the selection by default would obviously lead to a less than ideal experience.
I believe the people behind these choices actually ran extensive usability tests and decided to compromise on what they found to be the most common use case: poping a search window and inputing the search term.
I agree this system is maybe a little dumb but I think that is what makes it robust and dependable. Which is in my opinion the single more important attribute of any system.
I don't think the parent wanting more convenience is lazy. But I think that not reading the manual and complaining about the absence of an obviously present feature is proof of lazyness. That's very different and so very common. And I wasn't mocking him, just improvising a pun based on his last line.
The feature you're talking about is not the same as that.
-
What benefits do you think are provided by software that don't ultimately come down to making things quicker and easier to do?
My point was: the parent wants a different behaviour for Cmd-F but it turns out the different behaviour he asks for is already provided by another shortcut.
Yours is: it sucks and these different behaviours should be triggered by the same shortcut for the sake of "quicker and easier".
I think that such a move would actually go the opposite of "quicker and easier".
The most basic case for which the "Find" feature provided by Mac OS X is this: you need to locate a word in some text. This can happen if you want to jump quickly to a specific paragraph or if you want to read the definition of a word or the address of a person or if you want to bypass the LOC… Cmd-F is the way to go: it pops up a window with a textfield and a "Find" button. Exactly what you need to achieve your goal.
The case addressed by the Cmd-E Cmd-F combo has different predicate: you already have the word highlighted and you want to jump to another instance of the same word in the document. This may happen in fewer situations than the above case. In such a situation, comparatively rare, I believe, Mac OS X provides another shortcut.
Different actions -> different triggers.
-
I expect of course any software to go as far as possible on the road to "quicker and easier" but such a goal shouldn't impede clarity, simplicity and robustness. Making all of these requirements work together is what makes good software.
You (and others) prefer Cmd-E Cmd-F? Fine, I'm happy with that.
For your needs, that is quicker and easier.
But for other people's needs, Cmd-F using selected text may be quicker and easier.
I hope we can all agree on that.
My point was that: if someone wants to be able to achieve a goal G by some a particular means X (because the nature of X is helpful for them), it's not a valid point to say "but you can already achieve G by means Y" (where Y is not as helpful for them and their needs).
Imagine if the Cmd-E Cmd-F feature didn't exist and you said it'd be good if it did, and I responded that the behavior you want is already provided by another shortcut: by typing Cmd-F and then typing in the highlighted term.
EDIT: actually, I think a better analogy would be if you had said it'd be good if there was the Cmd-E Cmd-F feature and I responded that there's already shortcuts for the behavior you want: typing Cmd-C Cmd-F Cmd-V
--
I think clarity, simplicity and robustness are means of making it quicker and easier to achieve tasks.
I agree.
I don't think your analogy applies here: the parent doesn't ask if feature X exists, he complains about the fact that feature Y doesn't work like an hypothetical feature X and concludes that Mac text editors don't have feature X.
My answer is that feature X is in fact available but that you don't access it like you access feature Y.
Different features accessed by different means.
Here, the features are not "Cmd-F" or "Cmd-E - Cmd-F", these are only interfaces or triggers or proxys or whatever you want to call it.
The features are "searching for some arbitrary text" or "searching for the highlighted text". They are both different, present in the system without any hacks, accessible via shortcuts. If you want to use one you use it's shortcut, if you want to use the other you use its shortcut.
Easy.
If the end is to search for arbitrary text there is a mean: Cmd-F.
If the end is to search for another instance of the selected text there is a mean: Cmd-E - Cmd-F.
There are actually more means for each end: the edit menu, right click, buttons in the toolbar…
I'm not confused about them.
Confusion happens when you think, wrongly, that one mean (Cmd-F) allows to reach another end than the one it's designed for.
Confusion happens when you don't know the full capabilities of your tool and you use the most readily available mean, Cmd-F, to reach every conceptually related ends. Such a strategy is neither efficient nor sustainable at all.
Confusion happens when you keep doing the same mistake over and over without searching for a better way and complain about the dumbness of your tool and by extension of its authors.
But I think we are going to stick to our guns.
Parent commenter here. Some points:
1. Just because it's buried in a submenu doesn't make it obviously present.
2. When a user notices that something doesn't behave as it's expected, he/she won't think: "oh, let's look in the manual, maybe there's some way to do this". He'll just think the software is broken.
3. Another very true example of this is cut and paste of files. For years you could not cut and paste a file on Mac like in any other OS. Lion adds this, but instead of the simple and obvious Cmd-X, Cmd-V, you have to do Cmd-C, Cmd-Option-V.
When a user tries Cmd-X to move a file and discover it doesn't work, you can say he's lazy for not looking up in the manual. Or you can agree that some things are just badly designed, period. And I believe Cmd-F to search for selected text falls in that category too, despite of you arguing it's more robust.
And no, they don't always run "extensive usability tests". It's not because it's Apple that they get _everything_ right. They're humans, too.
I answered curtly to you calling me lazy, but I think now you're a bit biased here.
2. How did you create such an expectation? Searching the selected text on Cmd-F is not and has never been the default behaviour on Mac. Cmd-F not working as expected would be "the textfield is already populated by some random text and I have to delete it to input the text I want to search for".
You simply hit a well defined and stable and robust shortcut expecting it to do something different than what it has been designed for. Of course you are wrong.
When I moved to Mac OS X (leopard, I took my time) from Mac OS 9 I fell in love with Cmd-H but it didn't work in Photoshop where it was bound to something related but different. My mind was conflicted between my long time hardwired photoshop shortcuts and the new ones I used intensively.
Who sucked more? Adobe for not following the OS's guidelines and default or Apple for hijacking shortcuts used for years by their most loyal customers?
3. Totally agree, it's extremely stupid.
I do agree that some things are badly designed (coverflow, your cut & paste example, window/app switching…). I don't agree that Cmd-F is badly designed.
I'm not at all an Apple-lover (no iPod/iPad/iPhone - my dumbphone is great, thanks - Ubuntu at home since 1 year after 14 or 15 years of Mac OS and Mac OS X). Not everything they do is right, obviously. But they have to make compromises for their software to work well.
Cmd-F is an example of such a compromise where they make the feature good enough for most but too dumb for some while providing an easy alternative.
The Cut & pate fiasco is another example where they completely fuck up their belated attempt at adding a feature wanted by all the Windows switchers they managed to bring in.
Also I'm extremely sorry for calling you lazy. I was writing my reply and didn't notice the implications.
Different people have different work flows, and impossible to make everyone happy. However, in this case the extra-key press (which is easy as same modifier key and the E,F & G keys are all nearby) allows for greater flexibility and doesn't do unexpected stuff for newbie users.
Horses for courses.
Muscle memory dies hard.
/rant
The rationale for choosing this behavior in the Macintosh human interface guidelines was one of consistency: the keys simulate clicking the page up area, and clicking there does not move the cursor.
The keys _had_ to emulate mouse behavior because not all users had page up/down keys. The original Mac keyboard did not even have cursor keys.
I also think Apple that way avoided the difficult choice of what to do with the cursor. Should it stay at the same screen position, move to the top of the window, or something else? What if scrolling hits the top/bottom of the document? What if one hits page up while already scrolled upwards as far as possible? Should the cursor move within the document?
Finally, there is consistency with other programs. Drawing programs, photoshop, file explorers, etc, typically do not move the selection on page up/down.
I think they made the best choice for that time. It may no longer be the best choice in today's world where six year olds have six years of experience working with GUIs, but the eighties were quite different.
E-mail is so often reformatted, munged and quoted that depending on line numbers being the same on the sender's side seems foolish.
PS. I use Emacs for virtually everything so C-N, C-P and M-N, M-P get used for that kind of navigation.
That's how I do it anyway. The only reasons I can come up with off the top of my head to do otherwise is if someone is doing heavy TDD or banging code into a Smalltalk debugger instead of a browser.
How do you do it? (Genuine question. I almost always code by myself and have never been around anyone while they are productively working with an editor.)
Getting quick at line up/line down (C-N, C-P) and page up/page down (M-P, M-V in Emacs) seems to be a more common way of navigation. (C-S for quick search in Emacs being the other)
I use "Go-to-line" almost exclusively to jump to the line where a stack trace is telling me there's an error. (TDD or not, stack traces are a way of life)
> I use "Go-to-line" almost exclusively to jump to the line where a stack trace is telling me there's an error.
yes that's pretty much it: use external tool to find some row (diff tells you this is where a chunk was changed, grep or ack tells you what you're looking for is there, ...), jump straight to row.
Although usually I'll open the file directly at the right line in emacs (`e +line file`[0]), goto-line is only for the IDE.
[0] where `e` is an alias for `emacsclient -n`
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
I totally agree with the article by the way. Selecting the line is idiotic. While programming, you never ever want it to select the whole line - in fact, I don't think I have in fact ever selected a line at all.