— Forest and the Trees

Archive
Web 2.0

Kelvin Luck has just released a new version of Flashr 0.5. Flashr is a great tool for integrating the flickr api into Flash. It is used in findr.

I haven’t upgraded yet – but, I will. And anyone starting a new project should definitely use the latest version – lots of new features – most important queues and caching for requests to flickr.

Grab Flashr here (link above doesn’t work.)

Read More

flickr has changed their public api. Unfortunately, it affects everyone who’s made a Flash/Flickr tool. Mario has good summary here.

So, findr users – uh, it might not work. But, I’ll get to it soon.

Damn public apis.

UPDATE: August 20, 2006
I’ve updated findr to the new api location. If you are using flashr 0.4, you only need to change 2 lines in the flickr.as file

private var _AUTH_ENDPOINT:String = "http://flickr.com/services/auth/";
change to...
private var _AUTH_ENDPOINT:String = "http://api.flickr.com/services/auth/";
...and...
_REST_ENDPOINT = "http://www.flickr.com/services/rest/";
change to...
_REST_ENDPOINT = "http://api.flickr.com/services/rest/";

The updated source for flashr is here.

So, small change – but, pain in the ass because I have multiple versions of findr. I did finally get around to upgrading the detection script to swfObject – so you no longer have to click on findr to activate it in MIE. SwfObject is pretty nice, btw. In addition to handling the MIE problem, it easily allows you to pass variables from url addresses to Flash.

Read More

James Suroweicki (Financial Page writer for the New Yorker) wrote a great piece on the dangers of tiered internet service a couple weeks ago. He’s right on (as always). Tiered internet service is a lousy idea that only benefits the big telecoms (and probably only benefits them in the short run). His piece is worth reading – and is still on-line. Here’s my data-viz-programmer-centric take…

What is tiered internet service? The big telecoms (AT&T, etc.) are lobbying Congress to allow them to sell the equivalent of internet express lanes to certain sites. Right now, internet access to findr is just as fast as access to flickr (and political blog access is equal to Fox News). (This is different from hosting – think pipes not servers – like having two connections: high-speed for some sites, dial-up for others.) If the equal access changes, two trends driving Web 2.0 innovation – individuals being able to compete with bigger companies, and small start-up costs – will be affected.

Equal access to broadband matters because the browser is becoming the new desktop (see writely, etc). And it’s that change that is driving innovation. I can’t get people to download and install a program I write – let alone get them to download my constant updates. That’s what Microsoft can do. But, because people have high-speed access and are getting used to web sites that are more application than information, findr gets used all the time. But, if findr, montager, or retrievr, run significantly slower than flickr, a lot less people will use them. And if less people use these experiments, a couple things happen 1. Less innovation: less time will be spent improving these apps/experiments and developing new ones. 2. Less inspiration: fewer people viewing means fewer people thinking “I can do better.” Now, I would still build experiments if less people used findr. But, there’s nothing like a bunch of people using your app to get you to fix a bug – or to make that UI improvement you keep putting off.

The telcoms are just being shortsighted anyway. Sure, no one is signing up for high speed because they want to use findr (my Mom won’t even do that). But… 1. A lot of the big internet success stories today are started by one or two people (e.g., flickr). (For every gmail, there is a digg.) Keeping equal access encourages people to try new things. And the more good things there are on-line, the more people will want high-speed 2. For many, finding new stuff is why you have high-speed. Viewing Related Tag Browser for the first time was inspiring for me. If I’m paying $/month, I want Related Tag Browser (and the next Related Tag Browser) to come into my house just as fast as Fox News.

Read More

hmm.. just noticed that the slide show link doesn’t really work too well in findr. Apparently you can’t use multiple tags and the interesting setting. Findr uses “sort by interesting” to retrieve pics – you do get nice pics that way. The slide show works fine for single tags. And it works in findr personal (where “sort by most recent upload” is used). Looks like I’m going to have to get the slide show working in Flash.

So – two things I’d like changed to flickr - 1. an option to return photos’ tags on photo search – that would make findr personal usable – i.e., get rid of that initial wait. 2. slide show: multiple tags + interesting; photo number to start – e.g., start with the 10th most interesting photo.

Other than those problems, that flickr api’s pretty nice. And I love those easy to understand urls. That’s all that’s going on for the slide show – just calculate the url based on the tags clicked and open a new page. Unfortunately, I should have tested a bit more.

Read More

I made a new version of findr – findr personal. It loads all of a single flickr user’s pictures and creates a tag structure. Unfortunately, the initial load is painfully slow (a separate query is called to get each pic’s tags). But, there are advantages to having all the data – for example, you know how many pictures relate to each tag.

I also fixed some bugs and added a couple features, including a link to flickr’s slide show player. In certain situations, the slide player may not exactly match what you are viewing in findr but usually it will work just fine. (flickr’s slide player doesn’t load 99 pics at once, support all type of sorting, or allow for a startPage param – or maybe it does, but I couldn’t figure it out).

Also – just to confuse matters, I’ve set up a new site, tagtree.net, for all of these tag based experiments. (I’m calling the tag navigation part of findr a tagtree.) I updated findr and findr advanced on this site, but, findr personal only lives on tagtree. Eventually, I’ll probably just set up a re-direct from here. I’m not positive starting a new site is a good idea, but whatever.

tagtree.net
findr personal
findr
findr advanced

Read More

I put up a new version of findr that has two advanced controls.

  1. You can return photos in any order – the default is “interesting”, but now you can retrieve by “latest upload” and more.
  2. Added a rather slow “noise reduction” or “tag spam blocker” feature. What am I talking about? If you drill down far enough in findr you always end up with this lion. It shows up because it has so many tags. Now you can eliminate pics that have too many tags. Open Advanced Controls. Check “noise reduction”. Use the slider to set the tag threshold. Unfortunately, it is slow. So beware. Flickr does not return tags with photos on a multi-photo query. So, you need to loop through a list of photos and grab tags for each one. That said, you do get rid of the lions. To see it work try: dog –> golden retriever –> family.

I am leaving the original version of findr up as well. The advanced controls are interesting as an experiment. But — they’re not really necessary; I don’t love how they look (need to skin that combo box); they’re slow; and, most of the time, simple is better.

Read More

Jon Udell posted about advanced tag searching on flickr yesterday. He posted about tag spam today, mentioning findr, tagnautica, and flappr. Definitely worth a read.

Read More

Well, I’m reaching a bit with that title. But, hey it’s a blog. First, definitions…

Folksonomy – user described data. E.g., users tagging their photos on Flickr.

Intersection – The common elements in sets. E.g., two sets [1,2,3,4,5] and [1,5,6,7,8] intersect to become [1,5]

Taxonomy – A hierarchical data structure. E.g., Computers –> Software –> Web Development Tools –> Front-end –> Flash.

What you really want on the web is a taxonomy that you understand. You shouldn’t have to know exactly what you are looking for, just have a general idea – more of a Sunday paper and less of a dictionary. Obviously, you need a dictionary, and the web does that well. But, think about going to a movie. You don’t always know what movie you want to see. Sometimes you want to look at the movie section of the paper – see what’s playing close, at a good time, that’s getting good reviews. Searching for “King Kong” isn’t going to give you that. (This type of movie browsing is done very well at boston.com btw. Check out the movie map.)

When I made findr, I was thinking about it in terms of refining a search. But, the underlying concept of refining your search is taxonomy. You can’t refine unless you give structure to your data. E.g., I can’t ignore lousy movies in the paper without a system that rates them. And what findr does is create a structure. You want a funny dog picture. You start with dog, then you see chihuaha, then costumes – you are creating a taxonomy. The intersection keeps the costume within chihuaha. And the related tags (until you drill down deep) means you will have results. Now findr’s a good example, but, delicious is great – because it has more ways to interesect. I can look through my own tags and choose “flash–> data visualization”, and get the results. I can also look at a link and find other users who have bookmarked it and look at their links (which is a great way to find new sites). I’ve created a “me –> similar users –> flash” structure. It’s a different slice and it provides a different service – surfing, vs. retrieving.

Read More

Last week they drove me crazy, but, the benefits of public APIs vastly outweigh the disadvantages. Richard MacManus has a good summary here of why public APIs, and the trends they are driving (Web 2.0), are so interesting: mash-ups, web as platform, the importance of letting go of your data, etc.. It’s all great stuff – and any one of those reasons should be enough to stop you from giving up on flickr. But the trend I’m most interested in is front-end innovation and data visualization. Nothing is enabling the development of interesting interfaces more than the availability of public data. The initial front-end innovations were the emergence of Ajax and mash-ups. But now Flash is playing a bigger role. And while mash-ups still get most of the press, and certainly housingmaps will forever be the Web 2.0 poster child (deservedly so), you don’t need to mash to innovate.

Building dBases with appropriate middleware (e.g. PHP) is a big effort. Most Flash developers don’t know how to build a dBase, and with only a certain amount of free time to experiment, don’t want to spend it learning mySQL. Plus, even if you made your own dBase, the data won’t be as interesting as flickr or Amazon. There were always a couple guys who were scraping – or building visualizations from a “kind of public” dataset. But, the opening up of APIs has everyone jumping in. There have probably been more Flash based flickr tools built in the last month than any previous month – and things just seem to be getting busier. As more applications get built, more people see them and get interested, more source is opened, the tools become more robust, and the integration gets easier. All those changes result in more applications being built and the cycle continues. It’s positive feedback. There have been similar periods of Flash experimentation in the past. A few years ago, everyone was building sites with Flash animations and experimental layouts. But, there’s a difference now. Because we’re using the same data, we’re tackling similar problems. And we’re tackling the same problems as the Ajax folks. More people working on the same problems lead to quicker and better solutions.

Also, even though many of the front-ends this month use one specific API (flickr), because all the interfaces are tied to an API that is trying to adhere to (or maybe create) an API standard, interface ideas and code should more easily port to other APIs – like delicious or lastFM. I am reaching a bit here as I have only worked with flickr. But, interface ideas around tags should work well with other tag based APIs. And code for accessing one API should be adaptable to accommodate another.

I won’t go back on my post from last week. Public APIs aren’t perfect. But, they are great. And they’re starting to have a big impact on Flash data visualization.

Read More

Yesterday:
1. More hits on this website than all other days combined.
2. Worst day ever for Flickr API – really slow, and at least one API call no longer works (get pictures by interesting with multiple tags*).
3. So, all these people came to check out Findr, FlashForward finalist, and it wasn’t working. And even when it was/is working, it’s running so slow that it’s really not fun to use anyway – which is really the point. (And it’s still running really slow.)

This is the problem with working with Public APIs. It’s great to get your hands on public data. And, you don’t have to maintain a dBase – but, if you control the data (this blog runs on mySql), you can control the problems.

I had similar problems with when delicious went down a month ago. All the links on this site are saved as delicious bookmarks, and when delicious went down, so did the links. In that case, I could store the links locally, but I’m sacrificing control for convenience by using delicious.

It’s just a, kind of backward, change. We all get so used to everything working – and working fast. And things basically continue to work better and run faster. But with public APIs, you are letting go of control and sometimes that means letting go of performance. Letting go of control – your data, your source code – is a great trend – leads to more innovation, results in more user- vs. company-centric applications, but, it has consequences.

I still love flickr. I just wish they would have upgraded their API on different day than the FF nominations.

*I went back to “most recent”, which is too bad, interesting really does return interesting photos.

Read More