Posts tagged with "google"

Google Now Coming To iOS?→

Google Now Coming To iOS?

Engadget has posted what they believe is a “leaked” video of Google Now for iOS that was accidentally posted on YouTube and then removed.

Supposedly, Now will be accessible in an upcoming iOS app update simply by swiping up from the main screen. Of course, there’s always the chance that is an impressive fake or even a canceled project that’s only being leaked now. We’ve reached out to Google for comment, but even if the search giant remains silent, we’re confident the truth will be known soon enough.

Two weeks ago, I said this when comparing Google Voice Search to Siri:

Now, four months after Google Voice Search launched, I still think Google’s implementation is, from a user experience standpoint, superior. While it’s nice that Siri says things like “Ok, here you go”, I just want to get results faster. I don’t care if my virtual assistant has manners: I want it to be neutral and efficient. Is Siri’s distinct personality a key element to its success? Does the way Siri is built justify the fact that Google Voice Search is almost twice as fast as Siri? Or are Siri’s manners just a way to give some feedback while the software is working on a process that, in practice, takes more seconds than Google’s?

In that post, I was speculating on the possibility of a Google Assistant that would play by Apple’s rules to mix voice commands with native iOS apps like Reminders and Messages.

However, rather than going through the effort to develop such a Siri clone, it appears Google may be taking the “obvious” approach: porting Google Now to iOS by putting it inside the existing Google Search app. It looks like built-in Twitter and Messages sharing is as “native” as Google will go on iOS.

Engadget’s video may be fake, but I think it’s safe to assume Google is considering Google Now for iOS. Code references were spotted in Google’s Chrome browser and OS, and iOS seems like a logical step considering the nature of the product. Giving the “right information at the right time” is meant for mobile devices – phones and tablets that tend to be always with us.

It used to be that Android was the platform for Google users, but I’d argue that Google has been narrowing the gap between iOS and Android in the past months. With Chrome, Maps, YouTube, Gmail, Search, and (allegedly) Google Now, Google has been building a solid ecosystem inside iOS, and, as a user, I see that as a “best of both worlds” scenario: I can use (what I believe are) Apple’s superior devices, user experience, and third-party ecosystem with (what I believe are) Google’s superior web services.

Permalink

Google Field Trip

Earlier today, Google released Field Trip for iPhone, a tour guide app to alert users through notifications of “cool, hidden, and unique things” that are nearby. Using your location, the app can provide notifications for “your interests” such as Food, Drinks & Fun, Museums, Deals, and more. The app uses various data providers, including their own Zagat, to provide information about places to the user.

Released on Android in the Fall of 2012, Field Trip can “speak” notifications using either a Bluetooth headset or the iPhone’s speaker. A cool thing about Field Trip, in fact, is that you have control over audio output in the Settings: you can choose whether the app should speak the name of an interesting place or also its description, or if you want to enable the app’s audio notifications when device is docked, connected via wired headset, or through a Bluetooth device. This part of the app is really well done. Field Trip can even detect while you’re driving (my guess is through GPS).

The interface and data availability leaves much to be desired. In terms of UI design, my personal taste doesn’t like the choices made by Google: there’s a strange mix of fonts, plus rounded and non-rounded flat buttons that make browsing Field Trip confusing. Furthermore, the app puts buttons to switch between views in the title bar rather than a bottom toolbar – something that is utterly confusing on iOS in my opinion. Read more

Textual Siri→

Textual Siri

NotSiri

NotSiri

Here’s a good article by Rene Ritchie from June 2012 about a textual interface for Siri:

If Spotlight could access Siri’s contextually aware response engine, the same great results could be delivered back, using the same great widget system that already has buttons to touch-confirm or cancel, etc.

I completely agree. Spotlight lets you find apps and data to launch on your device; aside from its “assistant” functionality, Siri lets you search for specific information (either on your device or the web). There’s no reason find and search shouldn’t be together. Siri gained app-launching capabilities, but Spotlight still can’t accept Siri-like text input.

The truth is, I think using Siri in public is still awkward. My main use of Siri is adding calendar events or quick alarms when I’m a) cooking or b) driving my car. When I’m working in front of an iPad, I just don’t see the point of using voice input when I have a keyboard and the speech recognition software is still failing at recognizing moderately complex Italian queries. When I’m waiting for my doctor or in line at the grocery store, I just don’t want to be that guy who pulls out his phone and starts talking with a robotic assistant. Ten years after my first smartphone, I still prefer avoiding phone calls in public because a) other people don’t need to know my business and b) I was taught that talking on the phone in public can be rude. How am I supposed to tell Siri to “read me” my schedule when I have 10 people around me?

I think a textual Siri, capable of accepting written input instead of spoken commands, would provide a great middle ground for those situations when you don’t want to/can’t talk in public. Like Rene, I think putting the functionality in Spotlight would be a fine choice; apps like Fantastical have shown that “natural language input” with text can still be a modern, useful addition to our devices.

Text input brings different challenges: how would Siri handle typos? Would it wait until you’ve finished writing a sentence or refresh with results as-you-type? Would Siri lose its “conversational” approach, or provide butttons to reply with “Yes” or “No” to its further questions?

Text, however, has also its advantages: text is universal, free of voice alterations (think accents and dialects), independent from surrounding noise and/or microphone proximity. With a textual Siri, Apple could keep its users within its control by letting them ask for restaurant suggestions, weather information, unit conversions, or sports results without having to open other apps and/or launch Google.

It’s just absurd to think semantic search integration can only be applied to voice recognition, especially in the current version of Siri. I agree with Kontra: Siri isn’t really about voice.

More importantly: if Google can do it, why can’t Apple?

Permalink

Siri Vs. Google Voice Search, Four Months Later→

Siri Vs. Google Voice Search, Four Months Later

Rob Griffiths, comparing Siri to Google Voice Search at Macworld:

Because of the speed, accuracy, and usefulness of Google’s search results, I’ve pretty much stopped using Siri. Sure, it takes a bit of extra effort to get started, but for me, that effort is worth it. Google has taken a key feature of the iOS ecosystem and made it seem more than a little antiquated. When your main competitor is shipping something that works better, faster, and more intuitively than your built-in solution, I’d hope that’d drive you to improve your built-in solution.

When the Google Search app was updated with Voice Search in October 2012, I concluded saying:

Right now, the new Voice Search won’t give smarter results to international users, and it would be unfair to compare it to Siri, because they are two different products. Perhaps Google’s intention is to make Voice Search a more Siri-like product with Google Now, but that’s another platform, another product, and, ultimately, pure speculation.

When Clark Goble posted his comparison of Siri Vs. Google Voice Search in November, I summed up my thoughts on the “usefulness” of both voice input solutions:

I’m always around a computer or iOS device, and the only times when I can’t directly manipulate a UI with my hands is when I’m driving or cooking. I want to know how Siri compares to Google in letting me complete tasks such as converting pounds to grams and texting my girlfriend, not showing me pictures of the Eiffel Tower.

From my interview with John Siracusa:

And yet the one part of Google voice search that Google can control without Apple’s interference — the part where it listens to your speech and converts it to words — has much better perceptual performance than Siri. Is that just a UI choice, where Apple went with a black box that you speak into and wait to see what Siri thinks you said? Or is it because Google’s speech-to-text service is so much more responsive than Apple’s that Google could afford to provide much more granular feedback? I suspect it’s the latter, and that’s bad for Apple. (And, honestly, if it’s the former, then Apple made a bad call there too.)

Now, four months after Google Voice Search launched, I still think Google’s implementation is, from a user experience standpoint, superior. While it’s nice that Siri says things like “Ok, here you go”, I just want to get results faster. I don’t care if my virtual assistant has manners: I want it to be neutral and efficient. Is Siri’s distinct personality a key element to its success? Does the way Siri is built justify the fact that Google Voice Search is almost twice as fast as Siri? Or are Siri’s manners just a way to give some feedback while the software is working on a process that, in practice, takes more seconds than Google’s?

I still believe that Siri’s biggest advantage remains its deep connection with the operating system. Siri is faster to invoke and it can directly plug into apps like Reminders, Calendar, Mail, or Clock. Google can’t parse your upcoming schedule or create new calendar events for you. It’s safe to assume Apple’s policy will always preclude Google from having that kind of automatic, invisible, seamless integration with iOS.

But I have been wondering whether Google could ever take the midway approach and offer a voice-based “assistant” that also plays by Apple’s rules.

Example: users can’t set a default browser on iOS but Google shipped Chrome as an app; the Gmail app has push notifications; Google Maps was pulled from iOS 6 and Google released it as a standalone app. What’s stopping Google from applying the same concept to a Google Now app? Of course, such app would be a “watered down” version of Google Now for Android, but it could still request access to your local Calendar and Reminders like other apps can; it would be able to look into your Contacts and location; it would obviously push Google+ as an additional sharing service (alongside the built-in Twitter and Facebook). It would use the Google Maps SDK and offer users to open web links in Google Chrome. Search commands would be based on Voice Search technology, but results wouldn’t appear in a web view under a search box – it would be a native app. The app would be able to create new events with or without showing Apple’s UI; for Mail.app and Messages integration, it would work just like Google Chrome’s Mail sharing: it’d bring up a Mail panel with the transcribed version of your voice command.

Technically, I believe this is possible – not because I am assuming it, but because other apps are doing the exact same thing, only with regular text input. See: Drafts. What I don’t know is whether this would be in Google’s interest, or if Apple would ever approve it (although, if based on publicly-available APIs and considering Voice Search was approved, I don’t see why not).

If such an app ever comes out, how many people would, like Rob, “pretty much stop using Siri”? How many would accept the trade-off of a less integrated solution in return of speed and more reliability?

An earlier version of this post stated that calendar events can’t be created programmatically on iOS. That is possible without having to show Apple’s UI, like apps such as Agenda and Fantastical have shown .

Permalink

Instapaper Text Bookmarklet As Safari Reader Replacement On Chrome for iOS→

Instapaper Text Bookmarklet As Safari Reader Replacement On Chrome for iOS

Ever since I switched to Chrome as my primary browser on OS X and iOS, several readers asked me if I was missing the Reader functionality of Safari. Not really, because it was an easily fixable problem for me.

I use Instapaper to save articles for later. I like the app and like its text parser. However, few people know that the Instapaper Mobilizer – used by apps like Tweetbot – can also be used as a bookmarklet in any modern browser. Simply head over this page and install the Text bookmarklet; running the bookmarklet on a webpage will display it using Instapaper’s parser, but it won’t add it to your Instapaper account.

When I’m on Chrome for iOS and I stumble across a webpage I want to read without other elements besides text, I type “text” in the address bar and tap the Text bookmarklet (remember, you have to type bookmarklet names in Chrome). The nice thing about the Instapaper bookmarklet is that it’s fast, accurate, and because it returns a regular URL, the Chrome tab showing the parsed text will also be synced back to the desktop.

Last, a quick tip: when reading with Instapaper’s text view, you can tap & hold the top bar showing a webpage’s title to copy its URL (something that Chrome makes ridiculously hard to accomplish).

Permalink

Gmail for iOS URL Scheme→

Gmail for iOS URL Scheme

Tom Scogland figured out the complete URL scheme for Gmail 2.0, Google’s official Gmail app for the iPhone and iPad. As documented on his blog, the Gmail app allows you to compose an entire message using the following template:

googlegmail:///co?subject=<subject text>&body=<body text>

As I’ve also found out, you can add a to= parameter to pass a URL-encoded email address to which an email will be sent to. Unfortunately, my tests also confirmed that a similar from= parameter isn’t supported, and that this undocumented URL scheme doesn’t support x-callback-url, unlike Chrome. So, it’s not possible to return to a “calling” app after an email has been sent or the compose screen dismissed. I’ve also noticed how this URL scheme isn’t particularly reliable at bringing up the compose screen if the app wasn’t paused in the background (such as in a cold start); this is probably the reason Google isn’t publicizing this URL scheme – it’s not ready yet.

I’ve still made some stuff for it, though. Here’s a JavaScript bookmarklet that will open Gmail using a webpage’s title as Subject and URL as body:

javascript:window.location='googlegmail:///co?subject='+encodeURIComponent(document.title)+'&body='+encodeURIComponent(location.href);

Here’s an action for Launch Center Pro:

googlegmail:///co?subject=[prompt]&body=[prompt]

And an action for Drafts:

googlegmail:///co?subject=[[title]]&body=[[body]]

Keep in mind that the URL scheme may fail if Gmail wasn’t paused in the background (it’ll show a splash screen when loading again). I’m looking forward to improvements to the URL scheme, as Google has been doing a great job with these lately.

Permalink

The Verge: Redesigning Google→

The Verge: Redesigning Google

Excellent story by Dieter Bohn and Ellis Hamburger at The Verge on Google’s efforts to find a new design consistency across its apps, services, and platforms. Make sure to watch the video (as usual with The Verge, their video material is top-notch).

The central design metaphor that Duarte and the team eventually landed on was one he’d used before in webOS: cards. The cards in Google Now also show up in Google search, when it displays “Knowledge Graph” results on the web. In both cases, cards seem to represent the information Google gives you directly instead of through a list of blue links. Cards are like a digital equivalent to the traditional architectural concept of marrying form and function — so that the way a thing looks is inseparable from what the thing is. “These are objects,” Duarte says, “They feel, not necessarily real, but they feel virtual. They’re not trying to be fake things, not … fake leather, fake wood, fake brushed aluminum.”

Right now, I can count three Google apps on my Home screen: Chrome, Gmail, and Google Maps. I’ve always been a fan of Google’s Search app – the one that was actually well designed and intuitive before Google started redesigning its other apps – but I keep that on my second screen.

I like the design choices Google made in the past months, but I primarily use Google’s new apps for another reason: they work better than Apple’s apps for me. It takes seconds for Google Chrome to sync a bookmark or an open tab; I wish I could say the same for Safari and iCloud. Google Maps works better than Apple Maps in my area. The Gmail app isn’t perfect, but it makes going through Gmail faster than dealing with Apple’s Mail app.

It used to be that if you liked Google’s apps more than Apple’s ones and if you relied heavily on Google services, then you should have considered switching to Android. But I don’t want to switch to Android: I use some Google web services, but I like Apple devices and iOS for everything else. The iOS third-party ecosystem is thriving and a source of continuous inspiration and workflow improvements. iOS is my platform of choice, but Google is behind many of the services that I prefer.

For this reason, I’m glad Google found its design voice on iOS.

Permalink

Open Google Maps Directions With Siri or Launch Center Pro

Here’s a fun experiment to launch the Google Maps app via URL scheme directly into a new Directions view.

As I detailed this morning, the new Google Maps app for iPhone lets you launch specific views and modes using a URL scheme. You don’t need to be a developer to use the URL scheme; this means you’ll be able to launch the Google Maps app from Safari, Launch Center Pro, or any other launcher using the base comgooglemaps:// URL.

Google’s URL has a scheme for directions with addresses and transportation parameters. It lets you specific a starting address with the saddr parameter, and a destination address with daddr.

Further, you can instruct the URL to open a specific directionsmode, such as driving or transit.

With these parameters, it becomes possible to set up a nice automated workflow to launch directions using Siri or Launch Center Pro. Read more

Google Maps SDK For iOS And URL Scheme→

Google Maps SDK For iOS And URL Scheme

Alongside the launch of its official Maps app for iPhone, Google has also released a developer SDK to let third-party apps embed Google Maps directly. As detailed by Andrew Foster at the Google Geo Developers blog, the SDK – which requires signing up for API access – will allow developers to integrate Google Maps with their own apps, displaying embedded 2D or 3D Maps views with markers and info windows. The blog post also confirms that the SDK will work on the iPad; Google has confirmed to The New York Times that a native iPad version of Maps is indeed coming.

The SDK features vector-based maps that load quickly, allowing users to easily navigate 2D and 3D views, rotating and tilting the map with simple gestures inside your app. Developers can also change the Google maps view to include information such as traffic conditions, and control camera positions in 3D.

In the SDK documentation, Google says that the appearance of Maps embedded through the SDK is the same of the Google Maps apps, and that the SDK “exposes many of the same features”.

However, the SDK isn’t the only way for developers to integrate with Google Maps. Using a URL scheme, developers can point to the Google Maps app and launch it from their app into a specific view or map object. Documentation for the URL scheme is available here. Developers can link to Google Maps with specific views, modes (standard or Street View), set zoom levels, and pass directions with the URL scheme.

It’ll be interesting to see how and when Google Maps-compatible apps such as AroundMe or WhereTo will support the new Google Maps SDK. The addition of a URL scheme shouldn’t be underestimated either, as it’ll enable regular users to launch the app using tools like Launch Center Pro.

Permalink