Jon Udell on Flickr: Search and Spam
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.
Folksonomy + Intersection = Taxonomy
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.
Flex Enterprise Services Talk
Boston Flash Platform User Group Talk
Begins: Wed, 18 Jan 2006 at 6:30 PM
Ends: Wed, 18 Jan 2006 at 9:00 PM
Location:
Adobe 275 Grove Street Newton, MA USA
Link: Flex Enterprise Services Talk
- Structured Post -
From the BFPUG…
We have a very cool speaker lined up for next Wednesday: William Wechtenhiser, Director, Flex Enterprise at Adobe.
The subject is “Flex Enterprise Services Overview�. William explains what Flex Enterprise Services is and how it is different from Flex 1.5. He will cover the new programming model and features available to application developers with reference to the kinds of applications that can be built using these features.
The presentation will start at 7:00 p.m. and go about an hour. Come by a little earlier - 6:30 - for pizza and drinks (soda, etc.). After that we’ll have an hour or so to mingle, network, whatever.
Tags: Flex Flash Talk Presentation
Flex Enterprise Services Talk
Yes - duplicate posts - I removed this one to try structured blogging. Seems to work fine. And there’s a big calendar behind the post. Check the post above and “view source” - the semantic-ness starts with “xml -structured-blog-entry”.
The xml is cool. I would have no way to visualize a regular post - uhh… the “p” tag means time? But, the structured blogging gives nice time stamps and address nodes. Not sure how the aggregation would work yet. But, assuming it does - I could easily visualize all events posted on this blog on a timeline - or in a calendar. Nice.
Public APIs - Arghh Are Great
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.
Public APIs - Arghh
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.
FlashForward Finalist
Findr is a FlashForward Finalist in the Application category. Wow.
I’ve actually been doing a bunch of work on Findr. I am adding a couple search features and should be open sourcing it really soon (finally). The source is kind of a mess, but, I’ve now gotten 2 emails requesting it, so I’m feeling the pressure. (Thanks for the requests btw.) I just uploaded another version (0.7). It has a couple performance enhancements and some bug fixes. Thumbs load by row now, so, if you click on another tag before all the thumbs are loaded, all 99 thumbs will not load in background and suck up all your bandwidth. Also, Kelvin Luck updated Flashr (again) and it now has caching. I’ve done some testing and this seems pretty great - basically, you don’t need to re-query Flickr for the same request. Caching might cause some memory problems. If you have any, please let me know. It’s very easy to go back to the non-cached version.
Anyway, I’m flattered to get the nomination. But really, both Kelvin, for building Flashr, and Flickr, for putting out a comprehensive API, deserve as much credit as I do. Findr’s kind of buggy and experimental (it’s certainly not up to “client work” standards) - and the other apps look pretty great and solid - but, Findr is the only one developed using a public API and a 3rd party open source tool - and I’m assuming that that was one of the reasons it was chosen. I’m psyched about that. (I’ll blog about why soon.) And I’d love to see “using public APIs” as a FF category in the future. For other Flash apps using public APIs, please check the links page.
Oh yeah - vote for Findr here. All the finalists are here.
(Usage is sure up. Check my mochibot findr stats. Cool.)