Google officially unveils the Plus Box

On the Google Blog there’s an official announcement of the Plus Box feature. This feature allows extra information to be shown next to individual search results. The feature isn’t completely new, as several bloggers, including Google’s own Matt Cutts have written about it (see search engine land’s post with links to a few of them).

There are two types of Plus Box result: Stock information and maps. I don’t find stock information that interesting, but I love the maps Plus Box. If you search for a business and Google knows its address, there will be a map shown next to the search result with a marker where the address is.

At this moment most (all?) of the results are from the US. You can search for restaurants in New York and you’ll see a few examples (at the bottom of the first page). Sadly I haven’t found any business with a Map Plus Box in The Netherlands (or elsewhere in Europe). The only result with a maps Plus Box you’ll get when searching for restaurants in Amsterdam is Amsterdam Restaurant in New York 🙂

The Google Blog says they are working hard to increase the availability and I hope they will add availability of non-US businesses soon.

I’m not sure a lot of people now how they can add their business information to Google so it’ll show up in the Plus Box or in a Google Maps search. You can add your own information by using the Local Business Center. See more information at the Webmaster Help Center.

In The Netherlands most companies are registered in the Chamber of Commerce register (KvK) and this information automatically shows up in a Google Maps search. At the Local Business Center you can change and add your information (images, description, categories, etc). Before these changes will show up in the search results you have to enter a PIN you’ll get by snail mail sent to your business address.

In the Local Business Center you can also see some kind of statistics, I don’t know what kind of stats it’ll show, because I haven’t received the PIN yet. I’ve changed my information on March 8.

According to the Google Blog there will be more Plus Boxes in the future. One has already been spotted, the Video Plus Box, which shows a video in the Plus Box. I’m curious whether this will only show Youtube and Google Video results, or also videos of Google’s competitors?

First Amsterdam OpenCoffee

This morning, after I brought one of my kids to school (the other one had to go to the dentist), I drove my bike to the KoffieSalon. This is a place in Amsterdam where you can get a great cup of coffee, but that wasn’t the main reason I was going there. The ‘KoffieSalon’ was the location where the first Amsterdam OpenCoffee Meetup was held.

OpenCoffee is the name of a weekly event where entrepreneurs, investors, bloggers, developers and other web savvies can meet at the same place and at the same time.

It was a good and interesting meeting. 30 people signed up and I think they were all there. The time frame (one hour) is short, so you can’t talk to everybody. But it’s long enough to meet a few new people and have an interesting conversation. And because it’s weekly next time you can talk to the others 🙂

One thing I learned, while talking to others, is that I have to work om my introduction speech about the project(s) I’m working on.

So if you want a good Thursday morning start, meet like minded people, talk about your startup, find people to work with, or just have a nice cup of coffee, sign up for the next meetup!

Rails and geo plugins

After looking into Cartographer and YM4R I started searching for other geo tools for Ruby.

I found several and started creating a list. My idea was to make a comparison between the features of the different plugins. But I soon found out James Stewart did this already in his Comparing rails geo-plugins post. He moved the information to a wiki, on which the most recent information about the different Geo plugins can be found. On this page you’ll also find some great reviews of the different plugins.

I started looking into GeoKit, acts_as_geocodable and actsaslocateable. The last one isn’t suitable for my application, because it can only deal with US addresses. That’s also true for some of the geocoding services the other two support. The only one1 with support for Dutch addresses is the Google geocoding service, so sadly no fall back mechanism for Dutch addresses when one geocoding service isn’t available.

There are a few differences between the remaining two plugins.

acts_as_geocodable makes use of a gem called Graticule. This gem takes care of the actual geocoding, communicating with external services, etc. The acts_as_geocodable plugin takes care of the Rails specific stuff (extra find methods, etc).

GeoKit has all the functionality in the plugin, but Bill Eisenhauer, one of the authors, said “there’s no reason why this needs to be packaged entirely as a plugin”. So maybe this will change one day.

Another important difference is the way the two plugins store the geocoded information. GeoKit can handle existing models with longitude and latitude columns. You can specify the names of the columns with the column_name parameters (the defaults are ‘lat’ and ‘lng’).

The acts_as_geocodable plugin creates two new tables. The first is called geocodes and stores the longitude and latitude for a given address. The second table links the geocodes into your model in a polymorphic way.

Both plugins als have a feature the other plugin doesn’t have (as far as I can tell).

acts_as_geocodable can update the address fields with the data returned from the geocoding service, just add acts_as_geocodable :normalize_address => true to your model.

GeoKit has the ability to look up a location based on the user’s IP-address.

Which of the two is better? I don’t know. They almost have the same feature set, GeoKit does IP-based location lookups, while acts_as_geocodable separates its functionality between the plugin and the gem and has the ability to normalise addresses.

I think it’s a matter of taste, which one to choose. Or is there any difference in performance? I guess I have to test this.

For now, I think I’ll start with GeoKit for my application. I really like the ability to keep my own models with the longitudes and latitudes.

1 Maybe someday I’ll write a post about addresses and zip codes in The Netherlands and why the aren’t available for free.

Book: “Beginning Google Maps Applications with Rails and Ajax”

Previous post I mentioned a new book about Google Maps and Rails: Beginning Google Maps Applications with Rails and Ajax.

I haven’t read the book, but I’ve download chapter 7 and I think it’s an awesome book. A recommendation for everybody who’s building Google Maps Mashups with Rails.

You can even get it for free. There’s a contest where you can win a copy of the book, they are giving away 3 free copies. They call it a ‘contest’, but all you have to do is leave your name and email address. You have to hurry, because they’ll randomly draw three entries on March 15th, 2007 (deadline is midnight March 14th EDT).

If you haven’t won a copy on the 15th, you could always order a hard-copy (also available as an ebook)

All the examples of the book can be viewed online and the sourcecode can be downloaded.

Google Maps and Ruby on Rails

For a new project I’m working on, I will make extensive use of Google Maps. At this moment I’m doing some research to find out what the best practices are to use Google Maps in Rails applications. I also want to find out what tools there are.

The first projects I ran into are the tools which simplify the creation of a map: Cartographer and YM4R. These two projects give the user a Ruby based approach for building maps. According to Andre Lewis in his Google Talk about Ruby and Google Maps you’ll run into the limitations of these projects very soon if you’re building complex applications. Andre is one of the writers of the new book about Google Maps and Rails, called “Beginning Google Maps Applications with Rails and Ajax: From Novice to Professional”.

These tools can be very useful if you want to build a Google Maps application fast or if you don’t want to make your hands dirty on the Javascript (or maybe you just don’t have the knowledge).

The application I’m building will be rather complex and I don’t mind programming in Javascript. So I’m not going to make use of this kind of tools. The next category of tools you can use in building maps, are the geocoding tools. These will be the subject of a future post.

B.t.w. It looks like the cartographer project is dead, so if you want to use this way of building maps, there’s only one solution left, YM4R.

About this blog (4): English or Dutch

This is the fourth post in the ‘about this blog’ series and is a follow up of the previous one about decisions. It’s about the decisions whether to write in English or Dutch.

As you may have noticed, the main language on this website is Dutch, while I’m writing this blog in English. Why not stick to one language for everything? Or translate the site as a whole?

First of all, I’m Dutch, so my native language is Dutch. Because of this writing in Dutch is more easily for me than writing in English. There are a few reasons why I chose to write this blog in English:

  • To improve my English writing skills. I’m using English a lot for communicating with others. When I’m writing an email, sometimes I can’t find the words to express myself. By writing in English on this blog, I hope it’ll be more easily for me to express myself and not to make stupid mistakes we Dutch sometimes make.
  • I hope sometimes I have something to write about that’s interesting for a broader audience than only the Dutch-speaking.

The main reason why only the blog is written in English is that most of my customers are Dutch and I didn’t have time to translate everything. Maybe someday I’ll have a complete bilingual website.

I won’t say I’ll never write in Dutch on this blog, because I can imagine that sometimes I want to write about something that’s only interesting for Dutch speaking. But I’ll have to find out what the best way will be to do this.

About this blog (3): Decisions

This is the third post in the ‘about this blog’ series: Decisions.

Before starting this blog I had to make a few decisions. Some of them were easy to make, others were not so easy to make.

The first decision was which blogging sofware to use. I already wrote about this one in the first post of this series: About this blog (1): Custom Made

During the development of the blogging software I ran into a rather difficult decision: what kind of URL schema am I going to use? There’s been written a lot about this subject, so I started reading.

One of the most important things about URL design is to keep URLs simple and human readable. If these two are true for your URLs a search engine won’t have problems crawling your blog.

I started looking at other blogs and noticed there are many different ways to design an url. Here are a few (random) examples:

/blog/2007/02/16/Recreational-SVG

/yyyy/mm/dd/Title-without-Spaces

/2007/03/web-20-borrel-een-succes-open-coffee-meet-coming-up/

/yyyy/mm/title-without-spaces

/amigo/customer-service-tips

/tagname/titile-with-spaces

/svn/posts/302-preview-5-highrise-tasks

/id-of-post-plus-title-without-spaces

Because I’m using Ruby on Rails the last example would be the easiest to build. But I like /yyyy/mm/title-without-spaces better.

Does it really matter which one you choose? I don’t think so. All of the above URLs are SEO friendly. Some people argue you should not add dates to your URLs, while others think it’s good for your permalink structure to do so.

I decided to use dates in my weblog URLs although it’s slightly more complex to implement with my Restful weblog controller. I did it because I like the resulting structure of URLs which can be used as an archive: ”/weblog/2007/” gives all posts from 2007, ”/weblog/2007/01/” gives all posts from january 2007, etc. I left the day out of the URL, because I don’t think it’s very useful (I’m not planning on writing tens of posts every day).

Next decision was more easy to decide: Use full or partial text feeds. It was more easy, because I personally like reading blogs which use full text feeds, so I’m using a full text feed.

The final decision was a difficult one: which language to use, english or dutch. This will be the subject of the next post in this series.

Google Coop

Today I’ve been experimenting with Google Coop. It’s very easy to create your own custom search engine and add it to your website. You can take a look at my experiments (sorry only dutch).

I can think of many situations where Google Coop can be handy. For example:

  • Only add sites to the searchlist which you think are trustworthy about the subject
  • Add sites which are interesting for the community of your website. You could even allow others to add sites to the searchengine. This way you can build it together.
  • Create a local searchengine by only adding websites about a certain location (e.g. only sites you know about Amsterdam)

The resulting searchengine can also be added to your personalized Google Homepage.

Google Maps API feature request

Through this article at the geonames blog I found the ‘API Feature Requests’ page.

This page lists feature requests for the Google Maps API. If you like a feature and it’s already listed, you can write your name next to it to. If it’s not listed you can append it to the list.

There are a few very interesting feature requests.

‘Compatibility with other map APIs’. This is the feature request the article at the Geonames weblog talks about. Indeed it would be very nice if there’s a common API which is shared between all the Map vendors. There can be different reasons why you want to switch between different maps, eg the license changes, the area your application is about is covered better in a different map, etc. One problem I can think of with this approach is the that the feature set is not the same for every Map. So this common API can only cover the basics, but maybe that’s enough?

If you want a common API right away you have to take a look at projects like myMap, or Mapstraction. These projects are adding an extra layer on top of the major Map APIs from Google, Microsoft and Yahoo. You could also use the Open Layers API which also supports the APIs of these vendors.

Another nice feature request is ‘Ability to restrict geocoder to a particular region, country’. If this would be possible and your application is about a specific region you even could create an auto completion search on addresses.

If you’re using the Google Maps API a lot, take a look at the list and add your name or feature request to it.

About this blog (2): Status

This is the second post in a series I’m writing about this blog, a sort of “The making of….”. This time the status of this blog.

The main thing I can say about the status of this blog is “It works!”.

When building this blog I used the some of the guidelines from the great book Getting Real by 37signals:

  • “Build half a product, not a half-ass product”: This blog’s main purpose is to help me to write. That’s why I started with building the Posts functionality, not with the comments, tagging, etc. These can be added later on (tagging is already implemented).
  • “Don’t wast time on problems you don’t have”: At the moment I started writing this blog, all the posts fitted on one page (and they still do). So why worry about pagination and creating next/previous links? That’s something I have to take care of before the list of posts grows too big to fit on one page.

At this moment a part of this website is still static, e.g. the homepage. After I’ve written a new blog entry I have to manually add it to the homepage (a list of the three latest posts is shown on the homepage). Is this a problem? No! Would it be nice to have the three latests posts show up on the homepage automatically? Absolutely!

Another example, there’s no automatic ping build in right now. After a post has been added I go to the Technorati website and press the ping button. Is this a problem? No! Would it be nice if the blogging software did this automatically? Absolutely!

Because of the things I have to do manually it takes a little more time to publish an entry, but it’s not impossible.

My css is not complete, not every Textile markup element has a customized style. I just use them and when something isn’t displayed the way I want it to, I’ll add it to the css.

In the near future I’m planning to add the following features:

  1. Comments
  2. Pagination
  3. Ping
  4. Trackback
  5. Everything else I come up with

“Start with what you really need and add everything else later”, that’s something I’m planning on doing in my other projects also.