Webmonkey » APIs

‘Hyperlapse’ Turns Google Street View Into Beautiful Short Movies

Scott Gilbertson — Wed, 10 Apr 2013 14:33:55 +0000

Hyperlapse: turning Google Street View into movies. Image: Screenshot/Webmonkey.

Hyperlapse is quite simply the coolest thing we’ve seen on the web in quite a while. Not only is it creative and beautiful, it’s a great reminder that there are still a few APIs left out there that allow you to make cool stuff.

Hyperlapse is a JavaScript library that stitches together Google Street View imagery to create short “hyper-lapse” movies (time-lapse movies with movement).

The code behind Hyperlapse consists of Hyperlapse.js, Mr Doob’s Three.js and “a modified version of GSVPano.js“. The project is the brainchild of Teehan+Lax, the same design firm that built the interface for Medium.

The site uses WebGL, so you’ll need a modern browser like Firefox or Chrome to see it and create your own.

The only thing Hyperlapse is missing is an easy way to embed your custom Hyperlapses in another page. In lieu of an actual Hyperlapse, here’s a video showing what’s possible.

Thousand of APIs Paint a Bright Future for the Web

Scott Gilbertson — Tue, 08 Mar 2011 16:54:10 +0000

ProgrammableWeb's stat for API protocols and data formats

Once a novel idea that seemed limited to Flickr, the web-based API is now everywhere you turn — Twitter, Foursquare, Google Maps and thousands of other sites offer up their data in the form of an API.

APIs mean that third-party developers can build their own tools and mashups, which in turn helps to fuel the popularity of the web service. It’s hard to imagine where sites like Flickr and Twitter would be today without APIs.

In fact, these days some web services don’t even bother launching websites to go with their APIs — the API is the service. The SimpleGeo API, for example, doesn’t really have a corresponding website, it’s just an API that can be used anywhere, including inside mobile apps.

And APIs aren’t just something for external developers anymore. Increasingly web services are building their own sites and tools around their APIs — after all, why bother with an API if you aren’t going to use it yourself? Twitter is a good example of the “eat your own dog food” approach to APIs; Twitter’s website and its mobile clients are both developed off the same Twitter API that outside developers can tap into.

Former Webmonkey writer Adam DuVander, now Executive Editor at ProgrammableWeb, recently announced that ProgrammableWeb, an API tracking site, now lists some 3000 web-based APIs. To go along with that milestone DuVander breaks down some of the trends in today’s APIs.

It will come as no surprise to those actively developing or using APIs, but the overwhelming trend in APIs is moving toward serving JSON data over a REST interface. As DuVander notes in his post, how many “REST APIs” are truly RESTful is debatable, but certainly SOAP is on its way out and HTTP coupled with OAuth is the future.

When it comes to the data APIs serve up, XML is still the most used format, but JSON is hot on its heels and growing much faster. Even though there are still more XML APIs, the more recent the API, the more likely it’s serving JSON. In many cases — like Twitter’s streaming API and Foursquare’s updated API — companies are rapidly moving from XML to JSON.

The biggest thing that sticks out from ProgrammableWeb’s API trends is that the API, once a sort of “hey, that’s cool” option for progressive websites, is now a first class citizen of the web. Perhaps eventually something better than the REST/OAuth/JSON combo will come along, but the the API and the idea behind it — making data available to the entire web — isn’t going anywhere.

See Also:

Security Flaws Force Firefox, Opera to Turn Off WebSockets

Scott Gilbertson — Thu, 09 Dec 2010 23:43:11 +0000

Firefox and Opera have both disabled support for HTML5 WebSockets in the latest builds of their respective browsers. The move comes on the heels of a protocol vulnerability that could leave thousands of sites harboring malicious code.

New in HTML5, the WebSocket protocol enables a key mechanism found in modern web apps, allowing servers to independently send data to a client browser without the need for page refreshes or complex JavaScript. The most immediate use for WebSockets are apps that rely on full-duplex communication channels, like web-based chat tools and other real-time sharing apps.

Unfortunately, flaws in the WebSockets protocol also make the current spec easy to exploit.

The vulnerability was discovered by Adam Barth, who has demonstrated that a serious attack against the protocol could poison caches that sit in between the browser and the internet. That means, for example, a common JavaScript file like a Google Analytics script, could be replaced on a cache with a malware file.

As Mozilla’s Hacks Blog notes, the exploit doesn’t just affect browsers implementing WebSockets, but also Flash and Java. As the blog post says, “to avoid a lot of malware showing up without being easily traceable, we need to fix the protocol.”

Details of the exploit can be found in Barth’s paper [PDF link] and a series of messages to the Internet Engineering Task Force mailing list. Fortunately there appears to be a solution, but it will require rewriting some of the WebSockets spec.

However, until that solution is implemented both Mozilla and Opera have disabled support for WebSockets. Mozilla expects other browser to follow suit, though so far Opera is the only other browser to disable support. WebSocket support isn’t just a feature in desktop browsers either, the recent Mobile Safari upgrade in iOS 4.2 added support for WebSockets.

So far neither Adobe, which makes the Flash Player plug-in, nor Oracle, which oversees Java, have addressed the issue.

If you’ve been experimenting with WebSockets, be aware that the as of Firefox 4 Beta 8 (due in the next few days), Mozilla will no longer support your code. Neither will Opera 11. We really don’t expect this to be a long-term issue, so if you want to continue testing apps based on the nascent protocol, you can re-enable the features by changing a hidden preference in Firefox and Opera.

Photo by Andy Butkaj/Flickr/CC

See Also:

Open Data’s Access Problem, and How to Solve it

Scott Gilbertson — Wed, 22 Sep 2010 19:05:34 +0000

The recent Gov 2.0 summit in Washington D.C. saw several promising new announcements which will help government agencies share code and best practices for making public data available to developers.

The idea behind new projects like Challenge.gov, the FCC’s new developer tools and the Civic Commons is that by giving developers access to data previously stored in dusty filing cabinets, they can create tools to give ordinary citizens greater access to that data.

Unfortunately, not everything open data project leads to good things. It is critical that if open data is made available on the web, it must be accompanied by some effort to ensure everyone can access it.

We’ve seen an explosion in creative hacks that use this newly available data to provide excellent online resources. Public data sites like EveryBlock, or the Sunlight Foundation’s Design for America contest have highlighted some of the amazing ways open data can make our lives better. Whether it’s finding out crime stats, real estate values, health hazards and business license statuses in your neighborhood, or visualizing how the government is spending your tax dollars through innovative maps, open data and what you can do with it is the current hotness among web developers.

Most of the benefits are close to home — in the U.S., just about everyone has access to online government resources thanks to web-enabled computers in free public libraries.

But extend that argument to the rest of the world and the number of people that really have access to the data drops significantly. If you don’t have an easy way to get online, you can’t benefit from open data.

Michael Gurstein, Executive Director of the Center for Community Informatics Research, recently highlighted some of the problems with open data accessibility.

Gurstein points out a number of assumptions about open data that are often overlooked by those most enthusiastic about making such data publicly available.

Worse, he shows how such data can be used against you.

Gurstein’s example of the dark side of open data is Bangalore, India’s digitization of land records, which gives every citizen a way to see who owns what in Bangalgore. On the surface, it seems like a good thing, but the upper classes and corporations have been using the land records data to gain ownership of land from the unknowing poor.

The data, writes Gurstein, allowed the well-to-do to instruct surveyors and lawyers how to most effectively “challenge titles, exploit gaps in title, take advantage of mistakes in documentation, identify opportunities and targets for bribery” among other things. Details are in this PDF.

It isn’t necessary to go all the way to India to find examples of open data leading to unintended consequences.

In an e-mail exchange, Gurstein told me of a similar case in Nova Scotia where efforts to make titles, deeds and other land data led to very same situation — companies pouring over 19th century deeds, ancient maps and other newly available data, finding oversights, misfiled papers and other means to seize land from owners.

Of course unintended consequences aren’t a reason to stop making data available. For Gurstein, the solution is to make sure that open data isn’t just thrown onto the web, but that universal accessibility is built in so it can really benefit everyone.

How that is done will vary considerably by location and the type of data in question, but without such efforts Gurstein worries that “the outcome of ‘open data’ may be quite the opposite to that which is anticipated (and presumably desired) by its strongest proponents.”

It might come as a shock to some of the more enthusiastic open data proponents, but there is more to open data than just dredging it out of the Indiana Jones-style warehouses where it currently gathers dust. Putting it online for “anyone” access and just walking away isn’t necessarily a recipe for good things.

Gurstien also pointed out several solutions to me, which he lists in a follow-up blog post. These solutions would help ensure that what happened in Nova Scotia and Bangalore won’t happen elsewhere. Among the things he believes governments and other data providers need to take into account are:

Advocacy — Perhaps the most important of Gurstein’s guidelines is to ensure that everyone knows the data is available, making sure that a community’s resources are sufficient for turning the data into some kind of project with local benefits.
Internet access — Especially a concern in rural areas, the level of internet access is the cornerstone to open data. Just because data is on the web does not mean everyone can get to it. And if not everyone has access, then your data isn’t “open.”
Content and formatting — If the data just a raw GIS database that most people won’t understand, then even internet access doesn’t matter because only those with specific skills (or the money to hire them) will be able to do anything with the data.
Computer/software skills — Similar to content and formatting issues is having access to GIS tools and other specialty software. As Gurstein says “techies know how to do the visualization stuff, university and professional types know how to use the analytical software but ordinary community people might not know how to do either.”

It’s also worth pointing out that Gurstein has several examples of open data being used in constructive ways. He isn’t arguing that we shouldn’t put government and other data online, just that we should keep in mind that the data isn’t necessarily useful to everyone in its most raw forms.

As Tim O’Reilly notes in conjunction with Gurstein’s post, “we need to think deeply about the future” — to consider all the consequences of open data, not just the ones we’d like to see.

Punchcard scan by Steve Collins/Flickr/CC

See Also:

Test Drive Your Type With Google Font Preview

Michael Calore — Thu, 29 Jul 2010 19:13:22 +0000

Google launched a new web-based tool Wednesday that helps you configure, test and easily embed one of the company’s free fonts into your web pages.

The Font Previewer lets you pick one of the open source fonts from Google’s Font Library, then tweak the size, spacing and decorations using simple sliders and buttons. Once you have the type the way you like it, just copy the provided code and paste it into the CSS.

It’s so ridiculously easy, even I was able to use it to change the h1 style on my personal site in about 2 minutes. I chose Pablo Impallari’s Lobster.

Google first took the web font plunge back in May by releasing the Google Font API and publishing a collection of free, open source fonts anyone can use in their designs for free. It also joined up with Typekit (who released an API today) to put together a JavaScript library for designers to control how and when their fonts are loaded.

The fonts in the Font Previewer are the same ones available through the Google Font API. They are quite nice, with a range of script, serif, sans-serif and monospace typefaces. The various typefaces used on the Android devices (Droid), and the old-timey one from Mark Pilgrim’s Dive Into HTML5 site (IM Fell) are part of the package.

Here’s Google’s announcement with some more info.

See also:

Typekit Gets an API

Michael Calore — Thu, 29 Jul 2010 17:54:27 +0000

Font startup Typekit introduced an API Thursday that lets web programmers generate kits from the Typekit library behind the scenes.

The company has previously only offered the option of picking fonts and generating kits using the web-based tool on its site. But by releasing an API, it’s giving people the option of building Typekit into their own apps or simply extending the way they use the service.

Writing on the Typekit blog, Paul Hammond says: “The Typekit API gives you the ability to programmatically create, modify and publish kits. It also allows them to fetch metadata about all the fonts in the Typekit library.”

Here are the documentation pages. As you can see, the Typekit API returns data in a few different flavors (JSON, XML and YAML)

There’s an example page set up on Github, and while there isn’t much there yet (just a kit generator for Ruby) we can expect more soon.

If you haven’t yet explored Typekit’s service for including fancy fonts in your site designs, you should. Especially handy is the WebFont Loader, an open source library of scripts that Typekit developed to help eliminate the “flash of unstyled text” that happens when a page loads. The WebFont Loader offers a number of JavaScript events which allow developers more control over when and how their fonts are loaded onto the page.

See Also:

Twitter Switches on @Anywhere

Michael Calore — Wed, 14 Apr 2010 22:09:03 +0000

This is an @anywhere hovercard

SAN FRANCISCO, California — Twitter’s @anywhere features are now live for developers to start using, the company has announced.

Developers can begin using the system to integrate different kinds of Twitter engagement directly into their sites or apps. You can find details about it at the new Twitter developer site (which also launched Wednesday) at dev.twitter.com.

@Anywhere basically provides a way to let Twitter users follow other people and send tweets directly from within your web page or app.

The key component is the “hovercard” — you’ve seen them on the Twitter website for the last month or so. Any time you see somebody’s Twitter handle mentioned, you can hover over that person’s handle and a little window pops up showing their profile photo, location, short bio, number of followers, and — the key part — a “Follow” button you can click and add them to your follow list right there, without leaving the page.

The announcement was made by Twitter’s head of platform Ryan Sarver at Chirp, the company’s developer conference happening here.

You can start dropping hovercards onto your site using “a few lines of JavaScript” (outlined on the documentation page at Twitter’s development site).

It’s interesting to see so much excitement around hovercards, which have a lot in common with hCards, the microformat standard for publishing and sharing contact information on the web. Microformats have been around for a while but they haven’t really been widely adopted, and it will be interesting to see if rebooting the idea on top of the Twitter platform — a social layer that makes them more accessible and relevant– will give new life to the concept.

The other components of @anywhere are the “Connect with Twitter” (a remote sign-in system) and the Tweetbox, which you can embed in your page and let people send tweets directly from the page.

Sarver brought out some media partners to talk about how they’re deploying @anywhere features. There were some impressive presentations from The New York Times, Yahoo and MSNBC News. If you’re reading a story on one of their websites, you can see a hovercard when you hover over a journalist’s name and start following them immediately.

One other announcement from Sarver: Twitter is turning on an as-yet-undocumented feature called Annotations this week. It allows developers to add any kinds of metadata they want to tweets. The obvious one is content-specific tags, but we should see other implementations of Annotations when developers start playing with them at the Chirp Hack Day taking place tonight and Thursday.

Twitter Launches ‘Points of Interest’ Pages for Locations

Michael Calore — Wed, 14 Apr 2010 17:37:18 +0000

SAN FRANCISCO, California — Twitter is adding location-based place pages to its website, the company has announced.

The new feature is called Points of Interest. Starting soon, users will be able to click on a place name (or a location tag, if one exists) in a tweet and see that place on a map. Next to the map, they’ll also be able to see what people are saying about that place in a search results view. From what we’ve seen, it’s a convenient entry point into the current Twitter chatter about a certain place or city.

There will be an API for developers, which we’ll learn more about later today. The API will let developers build this feature into client apps, so it will be accessible from more places than just the Twitter website soon enough.

The announcement was made by Twitter CEO Evan Williams at the company’s Chirp developer conference taking place here Wednesday.

There are several hundred developers here at Chirp, and the announcement drew a round of applause from the audience.

“I think it’s a big step forward for the Twitter platform,” says Andy Gadiel, founder and president of JamBase, a social website for finding live music shows and events in cities worldwide. “Location is all about relevancy. Not just where you are in terms of a latitude and longitude point, but a real place in the world.”

We’ve seen huge growth around location-based services lately, especially on mobiles, where it’s become central to the user experience of almost every search-based or social app. Late last year, Twitter added the ability for users to add location to tweets, something that made tweets more relevant for search applications. The location tags are basically geotags indicating latitude and longitude, or latlongs. Also, Facebook recently added location-sharing for its users’ status updates as well.

Just after the announcement, Williams fielded a question from the audience: Will Twitter have a check-in behavior around Points of Interest, a la Foursquare?

His response:

“We’re not looking to duplicate the functionality of Foursquare or Gowalla. We want to make those services work better with Twitter. If you’re writing a tweet about a place and you type the name of that place, that’s sort of a check-in. But what we’re really interested in is what you’re saying about that place.”

See also:

Using the Google Maps API

Webmonkey Staff — Tue, 16 Feb 2010 01:45:47 +0000

Google Maps is perhaps the biggest and most useful of all the common web APIs. Who doesn’t love clicking and dragging those sleek, clean maps? But it’s also one of the more complex APIs, which can be intimidating for newcomers. It’s also somewhat difficult to immediately recognize all the possibilities of the Google Maps API since there are literally hundreds of ways to use it.

We’re going to dive right in. But to keep things simple, we’ll start with a very common use: Adding a map to your site and displaying some markers.

Getting Started
Adding in the Map
Adding Markers
Where to Go From Here

Getting Started

The first thing you need to do is apply for a Google Maps key. Just head over to the API key signup page and log in to your Google account. Once you have the key, create an html file with this basic code:





	



		My Map

		

	

	



		My Map

Remember to paste your map key into the JavaScript tag and you’re all set. Well, almost. WE need to add one more little thing so that Google will go ahead and initialize the map. Change the body tag to include the following handlers:

Adding in the Map

We’ve got our script set up and it’s loading, now we just need to tell the API where to draw the map. To do that we’re going to write a little JavaScript. Let’s get started by inserting this code inside the head tags of your HTML file:

Now load your HTML file in your browser and you should see a map centered on the Wired News offices. Did you feel that tingle of excitement? We did.

Adding Markers

Let’s add in marker so users have something to interact with. To do that we’ll extend our initialize function. Add these lines just below the map.setCenter bit:

	markerOptions = {clickable:true, draggable:false };

	marker = new GMarker(point, markerOptions);

	map.addOverlay(marker);

	marker.info_window_content = 'Wired News
Home of Monkeys'

	marker.bindInfoWindowHtml(marker.info_window_content, {maxWidth:350});

	GEvent.addListener(marker, "click", function() {

	  map.panTo(point, 2);

	});

Reload your page in the browser and you should now see a little red pin. When you click it, you should see our little info window.

And that’s all there is to it.

Where to Go From Here

Obviously, the GMaps API is far more powerful than this simple example. By itself, the Google Maps API might not be the most exciting web service. But when you start mashing it together with other data, it can turn boring address tables into map-plotted, location-aware information for your visitors.

Here are a few ideas to get you started exploring some other Google Maps options.

Include driving directions – To get the handy “directions to here” links that you’ll find on a normal Google map, see the GDirections class

Include map controls – There are a variety of different GMap controls for your users to pan and zoom. Try adding this line just above the initialize function:

map.addControl(new GSmallZoomControl());

Batch Add Markers – The best way to add markers is to pull info from your database and loop through it when you output the HTML. Just nestle the code from the “Adding Markers” section inside a loop and make the marker names dynamic.

Custom Markers – There’s no need to stick with the default red pin. You can use any image you want. See the docs for more details.

Hide the Google logo and map image credits – Most definitely against the TOS, but if you’re so inclined, add this to your stylesheet:

img[src="http://maps.google.com/intl/en_us/mapfiles/poweredby.png"],

#map-canvas>div:first-child+div>*,

a[href="http://www.google.com/intl/en_us/help/terms_maps.html"]

Discover Cool Photo Apps With Flickr’s New ‘App Garden’

Scott Gilbertson — Wed, 04 Nov 2009 15:54:35 +0000

Everyone has an app store these days. But of course, for Flickr, the photo sharing site that brought you rainbow vomiting Panda Bears, “store” is far too pedestrian. Which is why Flickr has launched a new App Garden.

The new Flickr App Garden consists of mobile, desktop, and online widgets that interact with Flickr and help you get more out of the site. Flickr already had an extensive list of such apps in its “Services” area, but the new App Garden is considerably simpler and makes find cool Flickr apps much easier.

Unlike the former app directory, which was a simple list, Flickr’s App Garden gives each app its own page where users can leave comments, tag apps and mark them as favorites. The ability to favorite an app means users now have a way to promote their favorites in the App Garden showcase. The app pages also look and feel just like a Flickr photo pages, which makes App Garden feel more like a part of Flickr than the old services directory ever did.

To make it even easier to discover cool apps, Flickr has also included tags on user’s photos which tell you what app the image was uploaded with, and then link back to that app in the new App Garden. If you don’t want others to know how you upload your photos, you can turn off the new tags in your account settings.

The result is that you can stumble across some very cool stuff like Suggestify, an app that allows you to geotag other people’s photos by suggesting a location to the photo’s owner. Following the tag “geotag” then led us to an interesting iPhone app, FlickrUp, which lets you geotag photos uploaded from the iPhone.

So far there’s no way for developers to charge for applications through the Flickr App Garden, though there are some non-free apps listed. Since actually download the apps you want — whether free or not — requires at trip to the developer’s own page, it seems that, at least for now, the App Garden is more a place to browse, not buy apps.

See Also:

Webmonkey » APIs

‘Hyperlapse’ Turns Google Street View Into Beautiful Short Movies

Thousand of APIs Paint a Bright Future for the Web

Security Flaws Force Firefox, Opera to Turn Off WebSockets

Open Data’s Access Problem, and How to Solve it

Test Drive Your Type With Google Font Preview

Typekit Gets an API

Twitter Switches on @Anywhere

Twitter Launches ‘Points of Interest’ Pages for Locations

Using the Google Maps API

Contents

Getting Started

My Map

Adding in the Map

Adding Markers

Wired News

Where to Go From Here

Discover Cool Photo Apps With Flickr’s New ‘App Garden’