About a month back I tweeted:
people of the Internet: how do I make Search With Google (Command-Shift-L) use Chrome (my default browser) instead of Safari?
Mark Rowe informed me:
“Search With Google” is a service provided by Safari.app. You’d need to create a new service and bind it to that key equivalent.
Working from Mark’s suggestion, I first disabled Safari’s Service by unchecking System Preferences > Keyboard > Keyboard Shortcuts > Services > Searching > Search With Google.
Then I launched Automator and created a new Service. I added a single Run Shell Script action like so:
Here’s the text of the Ruby script to save you from having to retype it:
require 'cgi'
`open 'http://www.google.com/search?q=#{CGI.escape(STDIN.read.chomp)}'`
When you save your Automator workflow, Automator will ask you for a name for your service. I’ve unimaginatively named mine “Search With Google (Wolf)” to indicate it’s pretty much just like Safari’s built-in service, but tweaked by me.
Automator will automatically save your workflow into ~/Library/Services, but it’s up to you to assign your abandoned Command-Shift-L to your newly created variant.
To do so, find your new Service in System Preferences > Keyboard > Keyboard Shortcuts > Services > Text. Then double-click the column to the right of your Service and type Command-Shift-L set your shortcut.
5. Why doesn’t Handoff work well on some Apple sites?
Apple disables Safari extension access to their site, so we can Handoff the URL but no other information. This causes Handoff of some Apple sites to be more incomplete than we would like.
Interesting.
It appears Apple doesn’t disable Safari Extensions across their entire site, but does block JavaScript injection on their official Safari Extensions site.
Sounds like a good security idea to me.
We’re doing exactly the same as ten years ago. We now say “iPhone” instead of “IE6,” but otherwise nothing’s changed.
No, wait, there’s one more change: the iPhone has far less mobile market share now than IE6 had desktop share back then.
ppk’s overly-bombastic text unfortunately distracts from his message, but he has an excellent point.
Regrettably he reaches for the almost-always-incorrect stupid/lazy/undiciplined argument, delivering only a cursory glance at the foundational issue:
Web developers should take a look at their sites on a Nokia and a BlackBerry and fix whatever’s wrong. It isn’t that hard to get your hands on a testing device. Just ask around or use PerfectoMobile. (I do not trust emulators, so I don’t recommend their use.)
To his credit, Koch directly acknowledges “Safari iPhone” as the best mobile browser.
It’s no surprise that we, in the profession, would like to carry and use the best. We live and breathe this stuff, and pick up on even the little niceties.
And there’s the rub regarding developing for the non-best mobile devices.
We don’t own them.
I have nine versions of four browsers installed on my machine. I keep a Windows VMware running with five instances of different browsers to test against.
I’m firmly in the cross-browser development+testing camp. I talk the progressive enhancement talk and walk the graceful degradation walk.
But I don’t develop for or test against Nokia and RIM devices because it’s more expensive hardware with expensive service plans.
(Plus, all those extra devices clutter the joint.)
Perhaps Koch would argue that as a professional, I should invest in the tools to ensure a great experience for all of my audience.
Well, that leads to the second part of my response: there’s a conspiracy underway.
OK, conspiracy is too strong a word. More like a semiconscious movement.
Mobile web developers, like most developers, are future-focused. We’d rather all mobile phones catch up with the iPhone we have in our pockets today, rather than bend over backwards to accommodate the current majority.
When Koch damns developers for professional hypocrisy and incompetence, I see a quiet revolution of mobile developers waiting for other phones to catch up to the iPhone.
Long-term, I begin moving towards Koch’s position: we do want a robust multi-vendor mobile web marketplace and we don’t just want to assume Safari like a previous generation assumed IE6. Progressive enhancement will serve mobile developers well again, in the future.
But short-term, I think mobile developers intuitively grasp that accommodating the insufficient software+hardware of non-iPhones out there will only prolong the status quo, extending needless suffering for developers and users alike.
