Placeling

Over the past few months at Placeling we’ve had the opportunity to work with hundreds of WordPress developers and learn how they’re using WordPress to go mobile. They want to use WordPress to create store finders, tourism guides, real estate maps - you name it.

We’ve also met hundreds of local bloggers - foodies, fashionistas, travellers, moms - and they all want their readers to be able to see - on their phone - nearby places they recommend.

But both of these groups are stymied by the fact that WordPress doesn’t support location. There’s no way for WordPress to show you posts or pages based on your current location.

Or rather there wasn’t a way until now.

Our updated plugin makes it effortless to guide people - on their phone - to places you’ve written about.

Here’s a quick overview of what it does:

• You can tag any post or page with a location
• We automatically create a new page in your site and put a map on it
• Click a pin and the corresponding post or page opens
• Click the “arrow” button on the map to see nearby places

Here’s a screenshot of what it looks like on the phone (try it):

The little blue dot is your current location. You can see nearby blog posts and tap to open them. All in WordPress via your web browser.

What do you need to get started?

• A self-hosted WordPress blog (WordPress.com doesn’t work yet. Let them know about Placeling)
• A Placeling account (you can sign up from the plugin)

And is there any cost?

Not for most people. We give you 1,000 map views per day and after that you can upgrade to our $20/month premium version. It also allows you to see the map as a list or a photo view and full CSS control.

So download the plugin and get started today. And once you’ve installed it, send us a note via contact[at]placeling[dot]com so that we can promote your site.

As publishers go mobile, one of the first questions they face is do we build a mobile app or a mobile website?

This question elicits heated opinions from folks. I’ve met people who swear that you should only build apps; others are mobile web only.

So what’s the right answer?

Here’s a simple approach to figuring out what to do - and then a detailed explanation of why we recommend this.

1) Determine if you need a feature that’s only available via a mobile app. If yes, your hand is forced and get building that mobile app!

2) If not, create a mobile website prototype

3) If the prototype is successful, start to migrate it to a native app to improve performance

In order to understand why we recommend this, let’s get into the difference between apps and websites.

Mobile apps are single-purpose apps that are downloaded via a store like the Apple App Store or Google Play. Mobile websites are URLs loaded via a browser (e.g., Safari or Chrome) on a smartphone.

There are a couple of key differences between these:

1) Distribution

2) Functionality

3) Performance

4) Cost

Let’s look at distribution first.

If you have an app, you automatically get an icon that appears on the home screen of a user’s smartphone (also called the “Springboard” on an iPhone). A mobile website can be saved as an icon on the home screen, but your user has to initiate this (and I’ve never seen any data to suggest anyone does this).

The space on the user’s real estate is nice (you stay top of mind) - but it comes at a cost: the whims of the app store. The terms & conditions of each app store requires you to get approval by the app store (if Apple, it’s for every release-not just the first one) and also mean that you have to be “found” in the app store. Plus your app can be yanked at any time and you’re no recourse.

Conversely, a mobile website does not get the automatic benefit of the real estate, but there’s no “toll” to pay:  anyone can type in your URL and they’re at your site. You also can update the app whenever you want; you don’t need to get it approved by the app store.

(Don’t confuse updating the content in the app with updating the app due to a feature change. The New York Times updates its content by serving up HTML in the app; they only need approval if they add a new feature to the app-e.g., social sharing, etc.)

One very important distribution fact as well: content in a mobile app can potentially be difficult to share via 3rd party services like Twitter and Facebook.

Each page you look at on a mobile website has a URL - and this URL can be posted to Twitter and Facebook and others can click a link back to that page.

When you look at a page in an app, there’s not automatically a URL. This means that a user can’t post the content they’re looking at to Twitter and drive someone back to that exact location. Sophisticated publishers do this by making sure that all the content within their apps mirrors what is available on their website (think Instagram or the New York Times); this is hard to do and needs to be considered from day 1.

So that’s distribution; let’s talk functionality.

Mobile apps get access to all the features of a platform whereas mobile websites only get access to a subset that’s exposed to browsers.

If you want to use very specific features of a platform (e.g., Apple’s Passbook), you’ve got to build a mobile app; you’ve no other choice.

Some features - like notifications or the camera - are available across most platforms but not accessible via the browser; if you want to use them you must build an app.

But a browser-based mobile website is capable of doing a lot. The browser can tell you where it is (location) and can access touch gestures to make your content swipeable, zoomable, etc. A mobile website can also store some information on the phone’s handset (e.g., keep recent stories for quick access).

And that’s where performance comes in. All things being equal, mobile websites will usually run slower than a mobile app. This is because the mobile apps are written specifically for the platform they run on; they’re “closer to the metal” and run faster.

If you need the fastest experience possible, you should build a mobile app. Just make sure that the limiting factor for speed isn’t a network connection. If you send lots of data across the cellular network it’s going to take a long time-the amount of time your app or website spends displaying the content will be trivial compared to the time for downloading it.

Finally, let’s look at cost.

For most organizations, it’s faster to build a mobile website. Your developers know how to create HTML whereas if you build a native app they’ll have to learn iOS and Android. Plus writing iOS or Android is tougher than writing HTML apps: the ecosystem of developer tools is not as rich as those web developers have and mobile apps are just more complex - so there’s more opportunity to introduce bugs.

Plus, building a mobile website can be a stepping stone to using frameworks like Apache Cordova or Titanium to create apps that are hybrids between native code and HTML.

Another cost: experienced iOS and Android developers also tend to be more expensive than “traditional” web developers.

There’s also a hidden cost to using mobile apps. If you offer in-app purchases of digital goods (e.g., buy a subscription), the app store will take 30%. And you have to use their payment system (note that this only applies to digital goods: EBay doesn’t pay Apple 30% if you buy a pez dispenser via their iPhone app); if you don’t, your app will disappear from the store. FYI, this explains why you can’t buy a Kindle ebook via any Amazon app. They don’t want to pay Apple the 30%.

So there you go: a detailed overview of mobiles apps vs. mobile websites. You’ll have to decide which one works right for you; feel free to contact us if you need any advice.

One of the things that’s still too hard to do in 2012 is recommend a place to a person and make it easy for them to store it for later.

It’s easy to say “you should go to Revolver in Gastown for a good coffee”; it’s a lot harder to get people to remember and act on that.

Why is that?

Well, you need a way to actually send “Revolver” to someone.

Then, your friend needs a way to store it for later - and make it appear later.

At Placeling, we’ve worked hard to make this easy to do; here’s how.

Let’s talk first about how to send Revolver to someone.

You can go to Placeling.com, type “Revolver” into the search box and you’ll instantly see it:

Just click on the name and you’ll be at page showing all we know about it:

Just copy the URL of the page and send it to your friend (or tweet it, share it on Facebook - whatever you want).

All your friend has to do is click “Placemark It” and it’ll be added to their map.

You can also do this in our iPhone app.

Search for Revolver and then click the paper plane button:

You can email or tweet the place (just like you could the URL) but there’s 3rd option called “Suggest It”.

Tap this and you’ll be prompted for which Placeling member you want to suggest the place to. Type in the name of your friend and add a custom message.

When you send it, they’ll receive a notification on their phone; with one tap they can add the place and your note to their phone.

Sharing a place has never been so easy.

Plus, now it’s on your phone so we’ve got the ability to see what’s nearby.

Now if only there was a way to create a “to-do list” of places we want to visit. Oh wait, we talked about how to do that two weeks ago!

Happy exploring.

One of the miracles of the early 21st century is the relatively banal fact that you can pull out your phone and see a list telling you that there’s a Starbucks nearby.

Google, Foursquare, Yelp, Placeling - all these services can do this millions of times a day. But your average local paper or magazine or blogger can’t.

In order to understand why they can’t, it helps to know how the Yelps of the world find nearby places.

First, your phone has to know where you are and share this. Whether you’re using an app or a mobile website, it can request your location. Through the miracle combination of GPS, cell phone triangulation and wifi strength mapping, your phone can figure out its latitude and longitude (you don’t need to worry about which combination it uses; you just care about the accuracy of the result).

The phone can pass this on to another service via a native API (like iOS’s CoreLocation) or the W3C Geolocation API (for web browsers).

This is the first place where your local publisher can’t yet execute: they haven’t ever requested your location so they can’t search based on it.

So let’s assume that your phone knows and is sharing its location. Your app or website can now call a web service, passing the latitude and longitude and accuracy as a result.

This is literally just like opening up a webpage; it’s a URL like https://someservice.com/nearby?lat=49.2&lng=-123.2&radius=100 except it’s going to return data (in JSON or XML format) rather than normal HTML.

To get the right data, the web service will then do what’s called a geospatial search. They’ve got a database that matches place names to latitude and longitudes and they’ll organize it based on what’s nearby to your phone’s location.

This is the next spot where your local publisher struggles.

Adding the correct latitude and longitude to a place based on address is tough (pop quiz: what’s your current latitude and longitude, accurate to 4 decimal places? Of course you don’t know). The process is called geocoding and you typically have to pay for it or worry about strict licensing concerns (consider Google Maps for Business).

Plus, once you’ve geocoded all your info, you need a way to search it. Sadly, most off the shelf content management systems don’t support geospatial searches (a very important exception is MongoDB; that’s one reason it’s so popular amongst location-based startups). Your typical publisher is using their own content management system or Wordpress and even if they could add a location to a piece of content, they can’t search for what’s nearby without upgrading their databases (and that’s never fun).

That, in a nutshell, is why your local paper/blogger/publisher can show you a list of restaurants on your phone but can’t show you which one is nearby.

So what’s a publisher to do? Well, at Placeling we help publishers do all of this in the cloud. If you want to plug location into your app, drop us a line: contact@placeling.com.

Last week Team Placeling read several articles about unique restaurants around the world. We thought we’d summarize the best and bring them to you as this week’s instalment of Travel Tuesday. As always, if you’re a Placeling member, you’ll get all these places on your phone.

First stop is Bangkok, Thailand. Cabbages & Condoms is a Thai restaurant that promotes sex ed. When not serving top notch Thai food, they’re creating dioramas out of condoms.

Here’s an F1 race car driver:

Elsewhere in the city you’ll find the Hajime Robot Restaurant, where a robot prepare and serves your Japanese Shabu Shabu food. He’s got googly eyes, smiles and dances while cooking.

Gimmicky?

Absolutely, but one we can get behind.

Photo courtesy of Hajime Restaurant

We’re now going to jump 2,500 km to Taipei which is home to its share of unique themed restaurants.

The misnomerically-named DS Music Restaurant is actually hospital-themed. The staff dress as doctors and nurses; you can expect a drink from serve from an IV unit.

The idea apparently was inspired by the great care the owner received in a hospital.

The city is also home several Hello Kitty cafes. The most famous one is Hello Kitty Sweets which explodes with pink and cat-themed cuteness.

Photo courtesy of KayOne73

And now let’s skip over to America, home to many a unique restaurant.

Working from Pacific to Atlantic, you’ll find Opaque, a dining in the dark experience, taking place at the V Lounge in Santa Monica.

In Lakewood, Colorado, you’ll Cartman’s (of South Park) favorite restaurant. It’s the Acapulco-themed Casa Bonita. As you visit the buffet line, don’t be surprised to see a high diver plunge into the pool.

Photo courtesy of Casa Bonita

Further east in Richland, Missouri is the aptly named The Cave. It’s what you’d expect from the name: you eat in a cave. Surf and turf plus Italian on the menu.

Image courtesy of The Cave

And our final stop is Atlanta’s The Varsity. It’s the largest drive-in in the world, sitting on 2 acres and capable of holding 600 cars outside and a further 800 people inside.

Apparently when the local Georgia Tech football team plays they get over 30,000 visitors in a day. It’s also the world’s largest single outlet for Coca Cola.

Photo courtesy of Chris Yunker

Happy eating & exploring!

It’s been five years since the iPhone launched. The introduction of iOS 2 over four years ago meant that we could write apps that took advantage of a reader’s current location.

Yet today most publishers don’t have locally-enabled content. You can’t easily walk down the street and read an excerpt of a novel describing a nearby place. You can’t effortlessly see the nearby restaurants recommended by your favourite magazine. And you probably still buy a tour guide before you travel.

Why is this?

Because location is still too hard.

It’s hard to work location into your publishing flow. You need to build a way of saying “this piece of content corresponds to this place called x at  latitude y & longitude z.” That means you’ve got to be able to do this inside your CMS. Only in the past 18 months have APIs (e.g., Google Places and Facebook Open Graph) become available to make this relatively easy to do.

Plus, you frequently have situations where the place you’re writing about isn’t in the API’s database. So now you’ve got to add it - and this is actually quite tricky. You’ve got to build a complex UI that can either convert a text address into a latitude/longitude or show an interactive map that gives you a latitude/longitude pair (Google’s Maps API can help).

Moreover, these APIs you’re integrating come with strict licensing terms. Attribute the place the wrong way? You’re out. And don’t even think of showing a Google place on a Nokia map.

All this and you haven’t even written one piece of content yet.

Once you’ve written your first piece, tagged it and published it, the question becomes: so what? So the restaurant “Eleven Madison Park” is at the location 40.741612, -73.987338. Why does this matter to your readers?

You now need to build another application that can actually make this location-based info useful.

And it’s not clear what the killer app is.

Location-based listing services are the bare minimum you can offer, but we’re at the early stage of defining what else is possible. Can readers create personalized, shareable tours? A concierge service that recommends places? What about showing the most popular places nearby based on time of day?

We all know what works to drive engagement in web publishing (slideshows!) Nobody knows what the equivalent of the slideshow is for local content.

Once you’ve built these apps you also need to deploy them to readers on the go. Do you build an app? Do you build a website? What’s the difference and how do you make sure you accurately get a reader’s location?

Get it wrong and everything you did until now is useless.

And we haven’t even talked about monetization yet.

No wonder that despite the rapid increase of mobile usage we don’t see a corresponding increase in location-based content by publishers. Instead, “location” has been left for pure-plays like Yelp and Foursquare.

The good news is that there are solutions to you. At Placeling we’ve white labelled our platform to give publishers a way to location-enable your content and deploy it across mobile, web and tablet.

We’ve built a suite of tools to showcase and monetize local content - and remove all the pain points mentioned in this article. Let us show you how we can mobilize and monetize your local content: mobilize@placeling.com.

Last week Disney bought Lucasfilm and the Star Wars franchise. The twitterverse has gone berserk over what this means for the future of the series, but we’re not going to take sides.

Instead, we’re going to take you on a journey to where the original movies were shot. And, as always, if you join Placeling you’ll automatically get all these locations on your phone.

George Lucas loved shooting desert scenes in Tunisia. You can literally sleep where Luke Skywalker slept by visiting the Hotel Sidi Driss.

Photo courtesy Jean-Marc Matthey

Elsewhere in Tunisia you’ll find Star Wars Canyon - which was also used to shoot Raiders of the Lost Ark and The English Patient.

Photo courtesy Roger Nogeura Arnau

And you can see Luke’s old house (actually, technically his uncle’s) further south at the Lars Homestead Exterior.

Photo courtesy of Hoylen Sue

Best visited at sunset:

Photo courtesy of Konczol Gabor

The crew then jetted off to Guatemala’s Tikal to shoot about 30 seconds of footage. You might recognize this as the place where the rebels launch their final attack on the Death Star.

Photo courtesy of Wikipedia

Later movies were also shot in exotic locales. The Empire Strikes back opens up on Norway’s remote Hardangerokulen glacier.

Photo courtesy of Wikipedia

And Lucas did shoot some exterior shots in North America. Return of the Jedi’s Endor (where the Ewoks lived) was actually Redwood National Park in California.

Photo courtesy of Steve Dunleavy

Hopefully one of these will inspire a future trip!

H/T to WebUrbanist for the inspiration.

It’s November and with the weather getting colder, we find ourselves thinking of…Hawaii.

Photo courtesy of Justin Ornellas.

Placeling user Steena recently went there with her family and created the ultimate Oahu tour for traveling with kids.

In fact, Steena’s got two guides: one just for Honolulu and another for the rest of the island. Where to go. What to do. Where to eat. It’s all there.

So, if you’re planning a trip to Oahu with the family, check out Steena’s tours; she’s done the legwork for you.

A few months back I walked into a local cooking store and picked up a recent copy of The Art of Eating. It was all about Austin BBQ.

Photo courtesy of Barron

Now, I live in Vancouver and have absolutely no idea when - if ever - I’ll be in Austin. But reading the story, the places were coming alive. The pepper in the rub at Louie Mueller BBQ; the almost 90 years of heritage at Smitty’s Market; the mesquite at Cooper’s Old Time Pit Bar-B-Que.

I found my mouth salivating and I was resisting the urge to pack the entire family in the car for a no notice, 24 hour road trip south.

I had to remember these places so that one day I can visit them all.

And that’s one of the reasons we built Placeling, to make it effortlessly easy to do exactly that (and keep families together).

Here’s how I did it:

1. I opened up Placeling on my iPhone and hit the “Placemark It” button

2. In the search box I typed in the name of each place in the article. The fact that I’m in Vancouver and Cooper’s is several thousand kilometers away?

Not an issue:

3. I added some notes about the place and saved it.

But I wanted to flag it as somewhere I haven’t been so I could remember to visit it.

For that, there’s the highlight button - the star that sits next to your notes and photos about a place:

After I highlight a place, it appears differently on my map - “normal” places don’t get that golden bar:

I do this every time I hear of an interesting place. Maybe someone tells me about it. Maybe I read about it in the newspaper or a magazine (in-flight magazines are basically lists of interesting places…). Maybe it’s a blog.

I just whip out my iPhone, add the location in Placeling and highlight it.

And we’re going to figure out how to make this even easier.

Ideally you should be able to read a review on a blog and add it to Placeling with one tap.

We’re not there yet, but we wanted to share with you a simple way to make sure that you never forget an interesting place.