Posts Tagged ‘Google’

We Still Haven’t Solved Search

Tuesday, June 26th, 2012
Google Search results for "What time is tomorrow's Giants game?"

(click for larger version)

Pictured above is what I see when I search “What time is tomorrow’s Giants game?” on Google.

It’s terrible.

Look at the sidebar on the left. What does it say for location? San Jose, CA. And where are the top two results? New York. Nearly 3000 miles away.

The next two hits have the right team (thankfully), but are both from 2010. I had “tomorrow” right there in my query. This is another missed opportunity.

The next two hits are for the wrong city, again, and rounding out what I saw above the fold is ask.com telling me tomorrow is March 27th. Disappointing.

The bottom three results (the rest of Google’s first page) were equally unhelpful. Beneath that were some ads promoting the Giants, and even mentioning their schedule, which is completely infuriating; why are the targeted ads more relevant than the search results themselves?

So, next time someone tells you that search is a solved problem, or that nobody will ever be able to beat Google, you can remind them that search is hard, and even the Giantest search engine of them all still has a long way to go.

Browser Trivia Tuesday

Tuesday, January 31st, 2012

I haven’t forgotten about that Windows Phone post. It’s coming. This is a small interlude while I get it juuust right.

Every Tuesday for the past four weeks, I’ve written up some super-geeky browser trivia on Google+. If upcoming jQuery releases and Opera are your thing, you should follow along! The posts are public, you don’t need a G+ account or anything.

I think I’m going to keep this up for the foreseeable future. The research-and-report format is surprisingly fun, and it’s filling in all kinds of gaps in my browser history knowledge. I have no idea if anyone is reading the trivia, let alone enjoying it, but sometimes you just have to do something because you want to do it, you know?

Why Google+ is Going to Succeed

Monday, July 11th, 2011

It’s official, I’m making a call: Google+ is going to work out just fine.

I know there are plenty of skeptics out there, so let’s go ahead and address the most common concerns:

Common Concern #1: Google+ can’t compete with Facebook.

The idea: Facebook is too popular, and a new network like Google+ won’t gain enough traction to reach critical mass.

Why that’s dead wrong: Google knows a thing or two about taking on massively-successful competitors. If it can hold its own against Apple and Mozilla, it can hold its own against Facebook.

The long answer:

Google doesn’t try to gain market share in one overwhelming blow. Google prefers slow, steady growth.

Look at Android. When it launched in Q4 of 2008, Apple had already sold nearly 10 million iPhones — and Steve & co. were getting started. Google didn’t try to win these users over immediately; they gradually earned market share one user at a time. Now Android is more popular than iOS, and all signs point to continued, step-by-step growth.

Need more proof? Let’s talk Chrome. At launch in 2008, Google’s browser started out with roughly 1% of the world’s internet users. Since then, Chrome has slowly crawled along, picking up half a percent of the market every month or so (stats). It now owns a whopping 20% of the browsing market, and there’s no reason to believe it’s going anywhere but up. Half a percent at a time.

Google+ isn’t out to crush Facebook all in one go. It’s going to slowly pick up users, little by little, until it’s a force to be reckoned with in the social media space.

Common Concern #2: Google+ is going to end up just like Google Wave.

The idea: Google’s last major product launch failed. Why should Google+ be any different?

Why that’s dead wrong: Google learns from mistakes. It’s a wildly successful company full of incredibly smart people. If anything, Wave’s failure will help the Google+ team overcome similar challenges.

The long answer:

Google Wave failed for a lot of reasons. It was difficult to explain to others, its success relied too much on developers, and invites were a mess. Google+ has fixed all of these problems.

“It’s just like Facebook” is an adequate description of Google+. Everyone knows Facebook, and that begs questions like “well, what is different?”. These conversations show what Google+ is really about: polish. It doesn’t have a bunch of killer new features, it just has a slightly-better version of the features common to most social media tools.

The invite system is much improved as well. Google Wave fed users a meagre handful of invites on an ad-hoc schedule. This meant carefully choosing who to invite, any only inviting a few friends at a time. The invite system for Google+ is more like a valve; when the servers can handle more users, the valve opens, and everyone can invite as many people as they want. When capacity fills, the valve closes, and we take a short break until the next tide.

Google+ isn’t Wave. It’s not just a different product, it’s a better product. Run by a better team, with a better plan going forward. Why expect anything less from an internet powerhouse with a proven track record?

Even if I’m wrong, I still win.

You know what the best part is about Android vs iOS and Chrome vs Firefox?

Of course you do. Competition.

High-profile technology wars bring major innovation to the market, and that’s always a win for users. Just look at how much smartphones and browsers have advanced in the past three years or so. All of it thanks to increased competition.

Ultimately, it doesn’t matter if Google+ succeeds. The real value is the threat — Facebook, Twitter, LinkedIn, Yammer… they all have to up their game to stay competitive. As a user of these networking tools, we’re certain to benefit for the foreseeable future.

What do you think?

This post also appears on the Macadamian blog.

The Playbook is being Marketed to Fail

Monday, April 25th, 2011

I don’t think this iteration of the BlackBerry Playbook will do very well, and I blame RIM’s marketing team.

If you’re not sure what the Playbook is, let me explain — and thank you for proving my point. The BlackBerry Playbook is a tablet computer released last week by Research In Motion, the company behind BlackBerry phones. It’s chief competitor in the tablet space is the iPad, followed by the handful of Android tablets that are currently available.

It’s a great device. The hardware is plenty powerful, and the software is certainly good enough for a 1.0 release. It supports native apps written in several languages, and web apps that can take advantage of HTML5 and Adobe Flash.

The Playbook has a lot going for it, but the one thing it’s sorely lacking is a marketing strategy. Without this, it will fail.

People need to know you have a product before they can buy it.

I spend a lot of time on this Internet thing. I read too many blogs, I stalk people on Twitter, I waste time on Facebook. As a tech-savvy 20-something year old, you’d think I would be the target market for a sexy new tablet. But alas! Everything I know about the Playbook, I learned from friends that work at RIM. Is that how the marketing team was expecting to reach me?

What’s their plan for everyone else? Let potential customers hear about it through word of mouth — weeks or months after launch — if at all?

That doesn’t work anymore. If you’re going to compete with someone like Apple, you have to be loud about what you’re doing.

And that brings us to an even bigger problem with RIM’s silent strategy:

When you don’t make your product sound great, your customers don’t either.

iPad users don’t need to think to explain why they love their iPads. They need only recite whatever Steve Jobs and the rest of the Apple Marketing Messiahs have told them about it.

What are potential Playbook users going to say when they talk to their iOS brethren?

“It has Flash”?

Fail.

Specs don’t sell products. Potential users want to know which tablet will improve their day-to-day life, not which one has more RAM. And that’s marketing’s job.

We’ve seen this before.

If RIM isn’t convinced that a lack of marketing will kill their product, maybe Google can sway them.

Remember when Google Wave launched? It was going to replace email, and add awesome features, and be everything to everyone!

Not a single person I knew could explain what it was in one sentence. What followed was confusion, lacklustre adoption, and ultimately, termination.

I loved Google Wave. It was a fantastic product that was constantly misunderstood because there was no marketing message to support it.

And as I read article after article, I can’t shake the feeling that I know where the Playbook is headed…

This post also appears on the Macadamian blog.

Ottawa Google Hackathon Wrap-up

Monday, January 31st, 2011

I spent my Saturday with some awesome people, hacking together an HTML5 webapp.

We were at the Ottawa Google Hackathon; a Google-sponsored event held at the University of Ottawa. Here’s a run-down of how it went from my perspective:

Free Bagels!

This was the first thing I (everyone) saw when they walked in: a table full of about a dozen kinds of bagels, with a dozen different cream cheeses. It was heaven. I instantly forgot that it was barely past 8am on a Saturday.

And it was delicious! Serious kudos to the organizers for deciding that this was a good idea, because it absolutely was.

Lightning Talks

Not everyone at the hackathon had the same level of experience with HTML5. The organizers had sent out a survey ahead of time to gauge what the least-known technologies were, and prepared a few quick and simple demonstrations of each.

Here’s what was covered:

  • Web workers
  • Canvas
  • Web sockets

I’ve always found talks or blog posts about canvas to be especially boring because there’s really nothing to learn. It’s a canvas. You can draw on it. You’re going to have to look up the API to do any real work with it anyway, a Hello World in canvas isn’t going to teach you anything. But alas, it’s what the people demanded.

That’s not to say it was a bad talk. The speaker (someone from Google) was very entertaining. In fact, all three presentations were easy to absorb and fun to watch. The highlight was when one Google employee was explaining what to do if you get stuck on an HTML5 problem: Just do a Bing-search, he said. We all had a good laugh.

Not much Twitter action.

I always tell people that conferences are about the only time that I become an average Twitter user. I’m not around much most of the time, but at any sort of large techie gathering, I’m all over the event’s hashtag.

This time around, though, it seemed like only a handful of us had Twitter accounts. I’m not sure if that’s due to the demographic (hardcore programmers are too anti-social media?) or simply because everyone was super-busy trying to bring their apps to fruition (we’ll get to that in a sec). Anyway, just something I wanted to see more of.

Take Tetris, and turn it on its side.

After the lightning talks, everyone kind of broke up into groups and started talking about ideas for a fun app. That heading up there was my pitch; I wanted to make a Tetris game where pieces come from the left and right, and two players have to work together to build lines in the middle of the screen.

Sounds pretty awesome, right? Yeah. It does. But “we” decided to make a LightCycle game instead. Not that I was bitter, it was still a fun idea.

The premise for our LightCycle game was that there’s no real reason why it must be restricted to two players, and no reason why the players can only move in straight lines. We decided to make the board a circle, and have the left/right arrows control rotation, so the cycles travel in curves. Neat, eh?

Anyway, the fancy HTML5 technologies we needed here were web sockets for the multiplayer, and canvas for the drawing. We also needed a lightweight server (we chose NodeJS) and some basic HTML/CSS/Javascript to tie it all together.

Time to git us some source control!

(sorry)

About half the table was in love with git, and the other half had never used it before. I was pretty adamant about git, because I was one of the git-versions git-virgins, and I wanted to see the light. So our team spent a solid 45 minutes unlocking it’s gitsteries.

You know… Mysteries. Regarding git.

Yeah, I’ll stop.

Ad-hoc Organization

Have you ever seen seven developers with little-to-no management experience self-organize on a seven-hour project? That’s one developer for each hour in the project schedule. Clearly, we had no time to waste on overhead.

Since we were all sitting at the same table, discussions were held aloud with participants drifting in and out as needed. We also had a Google Doc set up for things that were hard to remember, or things that we copy/pasted a lot. And I think at one point we drew something on an actual sheet of paper, so that was cool too.

This worked remarkably well. We were all very focused, and at no point did I ever feel like the tools at our disposal were insufficient or in the way. It was nothing short of ideal collaboration.

Final Products

I’m sad to say that our game didn’t quite make it to the finish line. We had some trouble with our web sockets; the connection would arbitrarily drop every now and then, but far too often to ignore. This seriously hampered our efforts, but we all resolved to continue the project after the fact. So we’ll see how that goes.

Most of the other groups were at about the same point we were: an hour or two away from being able to demo. A couple of teams did make it to the final stage, though, the most notable being this awesome HTML5 pong implementation.

There was also an Angry Birds parody. Apparently we all made games.

Oh, and the swag!

No sponsored event is complete without a bunch of awesome free stuff.

The coolest thing we all got was a pad of absolutely epic graph paper, marked as 768 pixels wide and with a little Chrome browser heading. It even came with a ruler that measured in pixels!

They also gave away some books during a brief trivia period (I forget which one/s, something about HTML5 and CSS3) and a few shirts (I got one!) and some remarkable posters (we scored one for the office).

All in all, it was a really fun day. A huge thanks to the volunteers, especially event organizer extraordinaire @mohamedmansour for actually referring to me as a VIP while we were in line. And of course my team, working with whom was the highlight of the event.

LightCycle forever! And all that jazz.

HackOTT

If this all sounded very appealing to you, you’re in luck: there will be a similar event in town in February. HackOTT promises to be “an awesome gathering of the very best of Ottawa’s technology hackers and developers”. I’ll be there, and so will a lot of other really cool people!

Thinking About SEO Makes Me Dizzy

Monday, October 18th, 2010

You know what I find confusing? Search engine optimization (SEO). Let me explain what that is in case you don’t already know:

A brief introduction to search engines.

Say you run a website that sells aprons. When you first publish your website online, it automatically gets indexed by search engines like Google and Bing, and then your website will show up in their search result pages (SERPs). So when someone punches “buy aprons online!” into Google, your website might come up. A couple of important factors here:

  • You want your website to show up near the top of the list.
  • Google wants to order the results it shows by how relevant they are.

These two “wants” don’t always line up. So, one day someone realized that by tweaking how content is organized online, you can change how it ranks in Google’s results. This is called SEO, since you are optimizing your website (the one that sells aprons) so that it looks as attractive as possible to search engines like Google.

(Of course, there are good and bad ways to do this. I’m not going to discuss ethics here. What I’m more interested in is simply making sense of it all.)

What does Google do?

Should Google assign more or less weight to sites that are trying harder to get noticed? Well, it depends. Remember that Google’s job, which it takes very seriously, is to rank the most relevant links first. So Google is constantly tweaking its algorithm to find better and more accurate ways to identify the best results for any given query.

You could almost say that Google is optimizing its search algorithm for finding the most relevant content.

So, who’s optimizing for who?

Now we have SEO-types that are optimizing apron sites so that they rank better in Google, and Google constantly optimizing its search algorithm to find the best apron sites. Since the criteria for what defines the most relevant apron site is set by Google, and constantly changing, SEO-types are always aiming for a moving target (and likewise for Google, since new websites, some of which are bound to be about aprons, pop up every day).

Part of me thinks that SEO and search algorithms should converge. If SEO-types are working to get pages better recognition and Google is working to recognize pages more easily, shouldn’t they someday bridge that gap from opposite sides? But then who really wins? The user is getting the best-optimized pages in Google’s best-optimized algorithm, which still might not be the most relevant matches — best-optimized is not guaranteed to be most relevant.

And what about Bing?

Bing has it’s own search algorithm, and it’s picking up a bit of market share. Are SEO-types going to start optimizing their pages specifically for Internet Explorer Bing? And how does Bing tweak it’s algorithm? If all the SEO-types are already optimizing for Google’s search anyway, wouldn’t it be in Bing’s best interest to aim for picking up pages matching that style of optimization?

Then what’s the end-game? Returning the same results as Google? I mean, if Google is working to return the best possible results and Bing is also trying to do that, aren’t they sort of shooting for the same goal? You can get into how Google and Bing might have different definitions of “best”, but is that really true? It’s the same users they’re fighting over, and they’re indexing the same content; logically there is only one truly ideal way to order their results.

The whole thing is a giant mess to me.

I have a lot of respect for what SEO-types do, and obviously I’m very thankful for the work search engines are doing to make my life easier, but what a fascinating and perplexing industry! I can’t really tell who’s on who’s side, and it seems like everything (the tactics, the goals, the products) is perpetually changing. Does anyone really understand how it all works?

What’s your take on all this? Am I the only one that finds SEO kind of crazy?

Modern YouTube meets Retro Firefox

Friday, July 9th, 2010

A quick bonus-Friday-post to help get your Friday rolling:

I’m doing some web development at my day job for a site that simply must work in Firefox 1. It’s not as bad as it sounds (we’re also supporting IE6, which is a far bigger hassle) and every once in a while using a really old browser provides a bit of comic relief. For example, when I accidentally opened a YouTube video using Firefox 1, here is what I saw:




(click image to enlarge)

The text reads: “Hey there, this is not a commercial interruption. You’re using an outdated browser, which YouTube no longer supports. Some features on YouTube may not work.”

How ironic that the outdated-browser warning message is nearly unreadable in outdated browsers! It looks like even the brilliant minds at Google occasionally struggle with legacy-browser support, just like the rest of us ;)

Have a good weekend!

Bears, Skittles and Google Buzz

Monday, March 15th, 2010

Google Buzz is like a laser gun that turns bears into Skittles.

That’s what I tell people when they ask me about Google Buzz. Much to my surprise, even without any further explanation they’re often less confused than they were to begin with. That alone tells you something about Buzz (it’s purpose is murky at best) and something about me (I’m clearly great with similes). Once you get past that, though, there’s some truth to it (really!).

The basic idea is that you can think of specific instances where it would be really useful (such as: you’re about to get mauled by a bear), but in general it’s completely useless. You can go way out of your way to find a good use case for Buzz, much like you can drive out to a forest inhabited by bears and spend all afternoon tracking one down, but that’s not how I like to spend my afternoons or my time online.

The problem I see with Buzz right now, is that it’s not as powerful as Google Reader, Twitter, or any other social tool, and it doesn’t offer any compelling features to help early adopters attract the masses. I’d simply rather read status updates and find neat links through other web venues. That’s not to say that Google got everything wrong here, and it’s not to say it has no potential — there’s just not a whole lot to like about Buzz right now.

What I would do with Buzz.

I think Buzz should aggregate everything from all my existing web communities, and let me filter it per-person.

If I’m wondering what my friend davefp is up to today, I should be able to pop into Buzz and instantly see any content of his that I can access in any of our mutual online spaces. His Twitter, Tumblr, Google Reader, blog; anything he’s got going on that I could check in each of those tools individually, right in one place. That’s when I would start Buzzing like a bee (again with the similes — sorry).

Obviously, it’s not easy to set up that sort of scenario, and you could argue that this is what Buzz is trying to do and that it’s just a few (light)years away — but the APIs exist for this! It’s just a matter of stitching them together in a way that’s coherent and seamless, and doesn’t take very long to set up, even if I have a lot of contacts on a lot of networks.

So that’s my take on Buzz. Now if you’ll excuse me, I have 8 different networks to dip in to, and some Skittles to snack on…

Aside: have you seen skittles.com lately? You should check it out — we need more designs like this.

Software is all about Context

Monday, February 22nd, 2010

Context is a very important factor in software development. Knowing the conditions under which your software will be used is an integral part of crafting a positive experience for your users. Many companies take this to heart and create truly engaging software that really connects with its users, but the vast majority miss the mark. While I’m sure I’d have no trouble pointing out a myriad of context-related issues in software made by Average Joe Developer, today’s focus will be on showing that even the top names in software aren’t perfect.

Exhibit A: The iPhone’s Clock.app

Let me tell you a story. A few weeks ago, the fiancée and I were scheduled to meet with a potential wedding venue early Saturday morning. Given that it was a bit out of the way and we tend to oversleep, we thought we’d be smart and set an alarm using the iPhone’s default clock app.

So Friday night, we set an alarm thinking it would wake us up Saturday morning. It did not; it turns out the alarm we set was for weekdays only! While this was entirely our fault, I’m still going to call Apple out on not taking context fully into account: when we set the alarm, why didn’t the app warn us that the alarm wouldn’t go off the next morning? I would imagine it’s very rare that anyone sets an alarm more than a day in advance. It’s much more likely that when someone sets an alarm at night, they expect it to wake them up the next day. This is a case where a neat feature is actually an annoyance because context isn’t handled as well as it could be.

Exhibit B: Google Maps

Continuing our story, while I was frantically trying to get ready I was loading Google Maps to get directions to our appointment. After punching in the address and asking it to route us there, Google Maps told me the trip would take over 9 hours. I freaked out! We don’t have 9 hours, we have 30 minutes; is this the right address? Did we accidentally book an appointment at a venue 9 hours out of Ottawa?

Actually, it turns out I had Google Maps set to give walking directions. Again, my fault, but again, where were the developers on this one? Did they really think I wanted to walk over 9 hours to get somewhere? Why not recognize that I was probably looking for driving directions and put a message at the top of the screen asking if that’s what I meant?

(For the curious, this story did have a happy ending: we made it there a slight 15 minutes late, and this was the venue we eventually chose for our wedding.)

Exhibit C: Firefox’s Spell-Check

Firefox is an incredible piece of software. It is currently the browser of choice for about one quarter of all internet users, and in many ways helped to revolutionize the web browser market. But one area where it hasn’t really advanced as far as it could have is its built-in spell checker. I don’t have a fancy story for this one; the data speaks for itself. Here is a list of words that show up as spelling errors in Firefox 3.6:

Some of the internet’s most popular websites:

  • YouTube
  • Facebook
  • Myspace
  • Flickr

Well-known web technologies:

  • Skype
  • Silverlight
  • Webkit
  • WordPress, CMS
  • PHP, CSS (it gets HTML)

Very common computer words:

  • Inbox
  • USB

Extremely successful desktop software:

  • Photoshop
  • PowerPoint

Apple products:

  • iPod, iPhone, iPad
  • Macbook
  • iMac
  • OSX (it gets Linux and UNIX)

These are all very common words in internet parlance, and it’s ridiculous that they are highlighted as possible spelling errors. Why not add them to the dictionary? A simple white-list that could be crowd-sourced to the community seems right up Firefox’s alley; I wouldn’t be at all surprised to see this addressed in a future release.

What can we learn from this?

My main take-away here is that context is a big factor in software development, and one of the hardest to get right. Even the big guns have room for improvement, which means the rest of us likely do as well.

An Excellent Use-Case for Google Wave

Friday, January 29th, 2010

Yes, another post about being engaged (it’s kind of this week’s theme). I promise this will be the last one, at least for a while; there are just a lot of interesting thoughts coming out of planning a wedding. We’ll resume our regular totally-non-marital posts at one per week on Monday.

I’ve been meaning to write up a good post regarding my take on Google Wave pretty much since I launched this blog in October ’09. The trouble was, I could never find a really good use-case that demonstrated how powerful and useful Wave is — until now. So without further ado:

I don’t understand how people planned weddings before there was Google Wave.

My fiancée and I are both the type to do a lot of research and planning before a big financial decision. So when it came to booking a venue, with so many different options and associated costs, we both dove right in. The only problem was that we had a really hard time staying in sync; we would both research the same venue or lose track of contact information for a place we really liked — it was a disaster. We tried ad-hoc discussions in person (this didn’t work; human memory is far too fallible) and a mess of emails (I had to scrub my inbox with a sponge after that one) but we found we were still stepping on each others’ toes. Then it dawned on me:

What we really needed was a wiki.

We needed someplace where we could both see and add and edit information, highlight important dates or phone numbers, and easily compare venues to one another. Nothing huge (a CRM would have been way overkill), just a light-weight wiki that would be approachable for my not-very-geeky soulmate.

So I fired up Google Wave and spent a couple of minutes explaining it to her. Now we have a wave for wedding venues, where each wavelet (that’s what the posts in a wave are called) is about one venue. When either of us comes across a cool-looking venue, we can quickly scan the wave to see if it’s already there, and if it isn’t we can add it and fill in some quick details. If we want to contact them, we highlight the contact info, and if we make an appointment to visit a venue, we highlight the date as well; this way even at a quick glance we can quickly see when our appointments are and if there are any left to make. If either of us have comments about a venue, we can reply to its wavelet; this takes care of the usual meta-discussion in an informal but persisted way (the indent makes it easy to ignore when skimming).

So far, this is working incredibly well. We’re both completely in sync all the time, and it’s easy to find key information by quickly looking in one place. We’re already starting to add new waves for other things we’ll both want input on, like the photographer, the DJ and the cake. I have no idea how else we could be doing this as efficiently as we are; Wave is suddenly crucial to our planning process.

What went right?

I’d like to touch briefly on why this has worked out so much better than my previous experiences with Wave. I think one of the big problems with Wave is that information tends to get scattered — it’s easy to lose something in a mountain of replies, and the inability to hide or mass-delete old content causes a lot of unnecessary and frustrating sifting. What I did differently this time was enforce some basic rules about how the wave should be structured: one venue per wavelet, replies are allowed for discussion if required. This way there’s no checking to see if that golf course with the gorgeous gazebo is nested somewhere in a chain of replies, or deciding what depth to add that maple farm that four different people have recommended. They’re both easy decisions, and sticking to these informal rules really pays off in terms of keeping the wave easy to read and update.

Have you found a good use for Wave?

I’m curious to know what other creative uses people have found for Wave. If you’ve got something good, please share!