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.
Posts tagged with "chrome"
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.
Chrome’s App Launcher, now available for preview in the latest Chromium build on the Mac, can be found on Chromebooks and is currently available in beta builds on Windows. It’s Google’s take on Jump Lists on Windows or Stacks on OS X: grids of web services are presented to you as grids of apps, with search available for narrowing the available choices.
I recently got annoyed by the fact that Google Chrome couldn’t open iTunes links in the iTunes app on my Mac, so I decided to look for a solution.
I haven’t been following Chrome’s (numerous) updates in quite a while, so I don’t remember when the app got a redesigned Settings page. In spite of the cleaner look, though, there’s still an option to manage “protocol handlers”, which are the settings that determine how Chrome should work with webpages that request to open other applications installed on a computer, such as Apple’s iTunes Preview website and iTunes.
Chrome for iOS was updated yesterday with a couple of new features, and considering it’s become my daily browser on all my devices, I thought I should try them out.
The most notable addition is full-screen viewing for the iPhone version. As you scroll down a page, the Omnibox gets hidden; to view it again, simply swipe down anywhere on a webpage. I like the implementation, and I think Google is doing full-screen browsing better than Apple on iOS. More importantly, the status bar remains visible even with full-screen activated (I wish Rdio would do the same). I hope this initial iPhone-only full-screen mode will evolve into Google finally enabling a bookmarks bar on the iPad.
The other addition of version 26.0.1410.50 (I know, don’t ask) is printing. From the Print menu, you can now print webpages using AirPrint or Google Cloud Print. The changelog also mentions the possibility to save PDFs to Google Drive, and I find it curious that this functionality is hidden inside Google Cloud Print’s menu. MacStories readers know about my preference for PDFs and workflows to archive PDFs of webpages. Unfortunately, Chrome’s Drive integration leaves much to be desired: it kept timing out on my devices, and when it worked, a PDF was considerably reduced in quality (screenshot). I’ll keep using my own scripts to archive PDFs.
For a detailed overview of the update, I recommend reading Dan Moren’s piece for Macworld linked above.
In January, I tried to put together a bookmarklet to send the webpage currently open in Google Chrome for iOS to Apple’s Safari. That turned out to be a surprisingly complex effort as Google didn’t think offering an “Open In Safari” option would be a good idea, and the app’s URL scheme produced some interesting results when opening and closing Chrome.
I was reminded of the bookmarklet this morning by reader @CNWLshadow, and I realized that I never posted the solution I settled with. It consists of a browser bookmarklet and a Pythonista script, and it works with just one tap.
Released earlier today, Google Chrome for iOS has been updated with built-in Messages sharing and a new menu to access previously-visited webpages.
Available from the Share menu in the top toolbar, Messages integration brings up a modal Messages window to send a webpage’s title and URL to someone else. This is a good addition – I’ve long relied on bookmarklets and third-party apps to forward Chrome links to Messages – but unfortunately one I’ll make little use of, as iOS doesn’t let you quickly address a message to a pre-defined group of contacts.1
I find the new History menu much more interesting for my daily Chrome workflow. Similarly to Safari, you can now tap & hold the Back/Forward buttons to show a list of websites you have navigated to; tapping on one will take you back to that page. Like Apple’s implementation, this is a per-tab history; unlike Safari, the list of pages is shown in a dropdown menu rather than a full-screen modal view (on iPhone).