Two weeks ago, I covered CloudyTabs, a free Mac app to access Safari's iCloud Tabs from the OS X menu bar. For those who wished to have a more integrated solution for Google Chrome on the Mac, Thundercloud is a simple extension that, like CloudyTabs, reads Safari's iCloud Tabs and puts them in a popover. There are a couple of configuration steps to get the extension to work with Chrome, but they're explained upon installation and they're easy to follow.
Dropbox Acquires Loom
Bjango Releases Skala Color, Free Color Picker For OS X
Screens 3 for Mac Review
Reeder 2 for Mac Public Beta Now Available
Thoughts On Dropbox Carousel
My problem: I haven’t installed Flash on my Mac and I sometimes need to watch YouTube videos that require Flash Player in Google Chrome. Google’s browser is my Flash shelter: Safari is my main browser and I only keep Chrome around for Flash videos. I was getting annoyed by the process of copying a URL -> launching Chrome -> pasting the URL, so I made a simple Keyboard Maestro macro to automate everything with a hotkey. I don’t know what took me so long.
The macro checks if Safari is the front window, and, if not, it displays a notification with an error message. I do this to prevent accidental hotkey presses for URLs that I don’t want to open in Google Chrome. If Safari is the front window, however, what required a bunch of steps in AppleScript to open the current Safari URL in Chrome is a single action in Keyboard Maestro: Set Google Chrome URL, using
%SafariURL% as a variable.
The two additional steps — Open Chrome and Wait For Chrome To Finish Loading — were necessary because I discovered that, when launched with a Set URL action, Chrome wouldn’t intercept the URL sent by Keyboard Maestro and would simply display a blank tab. In this way, Chrome is launched, paused for a second as it reloads open tabs or the start tab, and then the Safari URL is opened in the current tab. If you want to open the URL in a new tab, change the Set Chrome URL action to New Google Chrome Tab.
You can download the macro here.
I guess you could say that I was quite the fan of Google Chrome.
Before switching to Chrome last year, I didn’t have a “favorite” browser or “browser of choice”: I just kept jumping between Safari, Chrome, and Firefox, trying out all the features that the three major players had to offer on OS X. I’m pretty sure that, at one point, I even tried to go a full week with using Opera. My browser requirements have always been fairly standard (several open tabs; a lot of reading; sync with mobile devices), so I could afford to change browsers without having to worry about setting up a complex environment from scratch.
As I started using my iPad as my primary computer last year, I was growing increasingly annoyed with the state of iCloud sync in Safari and lack of major overhaul to a design that originally shipped with iPhone OS 1. I don’t frequently abandon systems that work for me due to stagnation, but iOS 6’s Safari exhibited a certain staleness on top of issues with bookmark and tab sync that, for me, were becoming an annoying problem. I liked Safari’s speed and native integrations with iOS, but it was prone to errors and boring.
On the other hand, Google Chrome for iOS was promising, familiar, and power user-friendly. I fell in love with Google’s support for x-callback-url, which I integrated in several workflows of mine as it allowed me to save time when switching between apps on my iPad; sync was nearly perfect; I praised Google’s superior implementation of voice dictation and feedback, although I noted how their Voice Search couldn’t exactly compete with Siri. Google kept pushing updates to Chrome for iOS, making it a capable browser for average and power users alike.
A few weeks after publishing my review of iOS 7, I decided to uninstall Chrome from all my devices and move back to Safari as my main and only browser on my iPhone, iPad, and two Macs.
I’m not looking back. I’m happy with the new Safari – so much, in fact, that I’m even considering Reading List as my “read later” service going forward.
Yesterday saw the release of thousands of apps optimized, enhanced, or, in some cases, completely redesigned for iOS 7. At MacStories, we highlighted several apps that were ready for the OS’ rollout such as Pocket, OmniFocus 2, or Instacast 4, and then we fired up iTunes – or simply waited for automatic updates to do their magic on iOS 7 – and checked out all the other apps that were also released yesterday. In this post, I thought I could offer a quick overview of iOS 7 updates from four big-name companies: Twitter, Facebook, Yahoo, and Google. (more…)
Released earlier today on the App Store, Chrome for iOS version 29.0.1547.11 (according to Google’s release notes) brings various search and navigation improvements, as well as a new white-themed icon that seems to be aimed at making Chrome fit more with the upcoming aesthetic of iOS 7.
The first improvement is better handling of single sign on with other Google apps for iOS, something that the company has been focusing on lately to provide an even tighter integration between its apps for iPhones and iPads.
Alongside bug fixes and stability improvements, Google has added a way to more easily swipe back from a webpage to search results: when you search on Google and choose a result, when you go back to your search query you’ll see a new animation and, more importantly, your previous results instantly appear on screen. Switching back and forth between results was cumbersome in the old Chrome, as it wasn’t fast and often led to problems with the Google Search page reloading again.
Last, Google says that Voice Search has been enhanced with pronoun support for chaining queries like “Who is Barack Obama?” followed by “Who is his wife?”. in my tests, the feature worked as advertised with US English Voice Search, correctly displaying results for the aforementioned person/wife combination, as well as “What is the capital of Italy?” and “What is its population?”. However, improved pronoun support doesn’t seem to be working with Italian yet, which wouldn’t be surprising considering that Google rolled out international versions of Voice Search months after the US launch.
I don’t like it when third-party apps or services force me to share links to articles or webpages using their own custom shortened links. I understand the appeal of personalized short domains – after all, we tweet mcstr.net links with the @macstoriesnet account – as they can provide analytics to track clicks, can save characters, and, at least in theory, they “look cool”. However, I’ve been long considering the idea of dropping our mcstr.net links, but I think the issue is worse (and more annoying) for apps and services that don’t tweet links to their own content (like we do) but that override others’ links with different domains. An example is Pocket, which gives you the clean, original URL when you choose the “Copy Link” action from the sharing menu, but that instead returns pocket.co links when sending text to Drafts (which I do often). I’ve grown tired of this practice (in Pocket and other services), and I’ve put together a workflow based on a Python script that allows me to easily resolve short links without having to open the browser and tap on multiple menus. (more…)
Last week, I wondered whether Google's new data compression feature for Chrome for iOS was partially motivated by the inability to use the Nitro engine to speed up page load times. Today, I have stumbled upon the technical document that details how the data-saving process actually works – in short, it uses Google's proxy to optimize web traffic sent by Chrome.
Of note, the transcoding of images from JPEG and PNG to WebP:
Over 60% of the transferred bytes, for an average page, are images. Hence, the proxy takes great care to optimize and transcode all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy supports the new WebP lossless format for certain images, and also optimizes the perceptual quality of each image based on device screen resolution and pixel density of your device.
I've never been a fan of speed optimization through proxies personally, but I'm curious to try out Google's implementation. The feature is still rolling out for Chrome users on iOS.
Following this morning’s rollout of the Voice Search for desktop, Google has also announced through the official Chrome blog that Chrome for iOS will receive the same feature “over the coming days”.
Voice Search, already available through the standalone Google Search app, will be activated in Google Chrome by tapping on a microphone button above the iOS keyboard:
Over the coming days, we’re rolling out an update for iPhone and iPad as well. You can now speak your searches into the omnibox. Touch the microphone, say your search query aloud and see your results (in some cases spoken back to you), all without typing a single letter.
Interestingly, the screenshot shown by Google displays the microphone button in the same additional keyboard row that’s currently occupied by buttons aimed at enabling users to more easily type URLs. Because Chrome for iOS, unlike Safari, uses a unified address bar for URLs and web searches, the extra keyboard buttons were necessary to let users quickly insert URL-related characters. It’s possible that Google will figure out a way to show both keyboard rows — the buttons and the new microphone — by letting users swipe horizontally above the keyboard.
Alongside performance improvements, Google also notes that “iOS apps can now give you the option to open links in Chrome and then return to the app with just one tap”. Assuming that Google is referring to the Chrome URL scheme with support for x-callback-url, that wouldn’t be new as it is already used by a variety of iOS apps (and as I showed today, users can play with it as well). However, Google has been quite vocal about its existing support for URL schemes lately, and it wouldn’t be surprising to see the company advertising the feature as new again.
Chrome for iOS, free on the App Store, was last updated in April.
Google Now style voice search has just went live in the latest Chrome stable version for the desktop (Version 27.0.1453.93). As far as we can tell from
playing aroundtesting things, the full contextual search isn’t running like we saw in the demo during the Google I/O keynote, but the basic voice search and response is ready to go.
Announced and demoed at I/O last week, Voice Search for the desktop mimics the experience launched on Google’s Search app for iOS last year. Voice Search for the desktop lets you dictate search queries to Google, which will transcribe them in (almost) real-time and take you directly to results, powered by the Knowledge Graph. Like on iOS, certain queries will trigger a voice response by Google itself, whereas others will display cards of information or regular results.
It appears Google is rolling out the feature this morning, as the new voice interface is available in Chrome but leading to frequent “No Internet connection” dialogs; I was able to try Voice Search twice, and it worked as expected.