In Google Maps, it drives me nuts that the scroll wheel zooms the map in and out. I keep expecting it to scroll. Same with the equivalent on my Mac trackpads, the two-fingered vertical swipe. I wonder if a Safari extension could change this behavior?
I came across Kod, a project run by Rasmus Andersson, by way of Daring Fireball:
Kod is a programmers' editor for OS X.
Currently under development, but will soon be available for dare-devil beta testing. "Kod" means "Code" in Swedish.
- Fully concurrent — loading files, syntax highlighting, etc is distributed across available CPU cores. Minimal waiting time.
- Integrated scripting environment based on Node.js.
- Written from scratch with modern OS X 10.6 APIs providing maximum OS integration while avoiding reinvention of the wheel.
- Sports a Chromium-like user interface where tabs can be torn off and moved between windows.
- Allows editing (although not saving, currently) remote files accessible over HTTP or HTTPS.
- Styling of the editor (not only the syntax highlighting) through regular CSS 3.
- Comes with support for over 65 different languages/syntaxes which can easily be edited or extended (Kod uses the same format as GNU Syntax Highlight).
- And more awesome features…
The beta is a real beta, with real flaws, but worth a look. It uses Sparkle for updates, so it's trivial to get new betas as they are released. An interesting UI feature is the use of a browser-like address bar. One use of the address bar is to see a nicely organized, syntax-highlighted change log, which you do by entering "kod:changelog".
When you get a Sparkle update a tab with the address "kod:changelog" automatically appears. Similarly, when you select "About Kod" from the app menu, you get a tab with the address "kod:about" that displays contact and licensing information, and third-party credits.
I didn't realize until I joined the mailing list how frustrated people are over the stagnation of TextMate. Kod is emerging in some people's minds as the answer to that, especially now that it's open source, using GitHub for its repository and Lighthouse for bug tracking.
Offhand I don't know of any Mac desktop app this ambitious that's used this open development model. It's been neat watching the discussions over the last few days. Rasmus seems committed to making the best development decisions he can, and providing the high level of leadership such a project will require. I'm optimistic, and surprised the project hasn't gotten more attention. Maybe after the holidays we'll see more about it in the blogs.
"Kod", by the way, is pronounced roughly like "code" in English. I don't know if I can get that Swedish "o" quite right. It sounds like it has a teeny extra syllable at the end.
Is the open source world big enough for two web-inspired Rasmusses? Stay tuned and see.
I got this idea from a discussion of how to capitalize menu items.
Apple's Human Interface Guidelines tell us how to capitalize labels on user interface elements. For example, menu items should be in title case, which Apple calls title style.
From the section "Capitalization of Interface Element Labels and Text" [1] in the chapter on "Text":
Title style means that you capitalize every word except:
- Articles (a, an, the)
- Coordinating conjunctions (and, or)
- Prepositions of four or fewer letters [2], except when the preposition is part of a verb phrase, as in “Starting Up the Computer.” [3]
In title style, always capitalize the first and last word, even if it is an article, a conjunction, or a preposition of four or fewer letters.
Apple gives examples of correctly capitalized menu items [4]:
Save as Draft
Save As…
Log Out [5]
Make Alias
Go To…
Go to Page…
Outgoing Mail
My idea is is for a script and/or app that would scan your nib files and check that you're using the right capitalization style for your menu items. I'd call it "iblint": "ib" as in "Interface Builder", and "lint" as in lint (which is glorifying it somewhat, but maybe the tool could be extended to perform enough checks to merit the link reference). Ideally it would do the right thing internationalization-wise, but just an English version might be a helpful start.
It would be nice if iblint could also check the UI elements that should be in sentence style, but this is trickier. For one thing, a label might contain proper nouns. For another, labels that are not full sentences should use title style, and it might be tricky for a program to figure out what is a full sentence — though on the other hand there are grammar checkers that can spot sentence fragments, so maybe it's feasible.
There might be too many special cases, and it might not be important enough, for this kind of checking to be built into IB, but I think a third-party script that performs a rough sanity check might be useful, if only a teeny bit so. And it might provide a tiny amount of geek fun to run it against all the nibs in my installed apps to see how well they conform to the capitalization guidelines.
Footnotes [6]:
[1] I'd have linked directly to the section, but I've found sometimes links to internal sections of Apple's docs don't work. The link might work for you.
[2] I was glad to come across this, because I'd been wondering whether it should be "Check For Update…" or "Check for Update…". Since "for" has fewer than four letters, I see now it should be the latter.
[3] I agree with the capitalization, but I don't think "Up" is technically a preposition here. I think it's an adverb. But I'm willing to be corrected, and in any case it's obvious what they mean.
[4] They give examples for other UI elements, like push buttons and dialog messages, but not for toolbar items. Presumably the toolbar should use title style, since toolbar items generally correspond to menu items. But I think it's worth saying so explicitly, and I've submitted feedback to that effect.
[5] Notice that "Log Out" is not one word.
[6] Sorry about the flurry of footnotes. I'm too lazy to weave all these side thoughts into something coherent.
I still call nib files "nib files", even when they're xib files. I wonder if I'll ever get over this.
Speaking of Inside Macintosh, I love this anecdote from Andy Hertzfeld at folklore.org:
The next week I sat down to meet with Caroline for the first time, and she couldn't have been more different than the previous writer. As soon as I began to explain the first routine, she started bombarding me with questions. She didn't mind admitting it when she didn't understand something, and she wouldn't stop badgering me until she comprehended every nuance. She began to ask me questions that I didn't know the answers to, like what happened when certain parameters were invalid. I had to keep the source code open on the screen of my Lisa when I met with her, so I could figure out the answers to her questions while she was there.
Pretty soon, I figured out that if Caroline had trouble understanding something, it probably meant that the design was flawed. On a number of occasions, I told her to come back tomorrow after she asked a penetrating question, and revised the API to fix the flaw that she had pointed out. I began to imagine her questions when I was coding something new, which made me work harder to get things clearer before I went over them with her.
Initially, we distributed the raw documentation to developers piecemeal, as it was written, but eventually we wanted to collect it into one definitive reference called "Inside Macintosh".
I never heard of Caroline Rose until now, but as far as I am concerned she is an unsung hero in the history of Apple and should be a role model for tech writers everywhere.
You can get a PDF of the 1985 edition of Inside Macintosh here. Skimming through, I'm struck not only by the clarity and thoroughness of the writing, but its consistent tone. It's technical but has a human touch that doesn't feel forced or overly casual.