Category Archives: internet

Photo 2.0 – Photophlow

3 Replies

Last night, Scoble mentioned Photophlow on Twitter. I went over to see the site and then begged and pleaded for an invite – and got it. Photophlow is kind of like an IRC customized for dealing with Flickr photos. There is a global chat room, each user has his or her own chat room, and there is a chat room for every Flickr group. Within a chatroom, people can search Flickr photos and the room can follow along to see what they are searching. You can select photo out of the search, which will be transmitted to the room. There are some other features, like turning off the following of other people’s searches and turning off people’s ability to see what you searched for.

The Photo 2.0 angle
People like David Hobby and Chase Jarvis have been talking about (and living out) “Photography 2.0”, where there is massive sharing of photographs and photographic information. One of the things that I’ve often wished for is the ability to talk (in real time) to someone to get/do a critique of a photo. I think that this is something that happens best in real time. You could do that via IM and hyperlinks. You might even be able to do that via IM group chats, if all the people in the critique were using the same IM system. (It’s 2008, IM vendors). The value that I see in Photophlow is having a realtime way of talking about photos in a group. It would be even better if there was a way to annotate the photo being broadcast at the moment, so that you could focus attention on particular parts of a photograph. We’ve been doing some interesting group photo stuff here in Seattle lately, and I definitely think that Photophlow is something that could really help with some of the things we have done, as well as some of the things we are thinking of doing. Besides annotation tools, I would also like an easy way to log/archive a whole chat session or parts of a chat session.

The Web 2.0 angle
Photophlow is technically interesting for a number of reasons. It’s an app that’s built entirely on top of another web applications’ API. And it’s pretty substantial. There’s a lot going on here – a lot of AJAX, and API calls to Flickr. The app feels kind of pokey because it’s pushing the limits of what can be done in Javascript. Indeed, if I run Photophlow in Safari 3 instead of Firefox, the performance is noticeably better. This is a situation that we also see in Chandler Server. It’s going to be interesting to see how well this is able to scale up.

Photophlow is also pushing the limits of how some people think of using a web application. It’s designed to be used a lot and in a highly interactive fashion. I know that I would probably keep chat rooms for my personal group, the Seattle Flickr Meetups group, and the Strobist group open all at once if I could. The designers have also built in bridges to IM notification and to allow you to Twitter from within Photophlow. Too bad their isn’t a way to get a Twitter stream instead of an IM notification – but that’s more a limitation of Twitter than of Photophlow.

I bet that you could do some of what Photophlow does with a custom IRC bot. But I also bet that it would be substantially less accessible to people who are photographers first and computer users second (or third, or what have you). Then again, maybe here’s another opportunity for VOIP…

If you haven’t gotten into the beta yet, there’s a short tutorial video.

Technorati Tags: , ,

Caja: Capability Javascript

Leave a reply

Ben Laurie has posted some initial information about the Caja (Capability Javascript) project that he is leading at Google. The code is going to be open sourced under the Apache License (with Ben running it, that’s no surprise). Caja is based on the work that Ben did on CaPerl a few years back. I saw CaPerl when we were looking at how to improve Python security for Chandler Desktop. Ben was interested in doing some capability stuff for Python, but the stars never aligned for it to happen. I’m glad to see that his work will live on – it’s not like JavaScript couldn’t use some security help. People worried about yet another version of Java/ECMAScript should go read Ben’s post before they complain.

Dopplr should be looking over their shoulders

1 Reply

A few days ago I signed up for the new TripIt service. I didn’t have very high expectations, and I’ve already planned the rest of my trips for the year, namely my trip to ApacheCon. That trip was booked by a regular travel agent, and the form in which I got the documents was unlikely to be parseable by Tripit, so I just entered it by hand. I was really impressed by how much Tripit knew about my plane flight. I wish that it was similarly informed about my hotel. The itinerary management is pretty compelling for my uses.

There is also a social networking component to TripIt, which allows you to coordinate travel with other people, and you can generate a location stream and calendar feed. If TripIt can do what Doppr does, which is tell me who else will be in a location during the same time range, then I’d say that Dopplr should be pretty worried. Actually according to the TripIt blog, they are planning to do just that. They are also planning to do restaurants, which means that they might be able to act as a kind of evite/renkoo for groups of people looking for restaurants to eat at while traveling together. Yow. Call that the “Greg Stein feature”.

Another victory for full feeds

Leave a reply

During the bar conversation after the Saturday Seattle Strobist Seminar, a bunch of including James Duncan Davidson and Eric Soroos were talking to David Hobby about full feeds on the Strobist site. In particular, we pointed him to John Gruber’s experiment with full feeds on Daring Fireball (preliminary report on John’s experience). So I was very happy to read that David has decided to try a full feed for Strobist as well.

Since David wanted some more power user full feed info, here’s my take on David’s situation.

The argument for full feeds is that it allows a reader to be more efficient because they can digest more information per unit time. At least that is true for me. The other big benefit is that it allows people who want / need to read offline to do so. The question is, “Doesn’t reader efficiency come at the expense of the publisher”? My answer is, no, not if your content is good. In fact, if your content is good, reader efficiency works in your favor. If your content is good, then you as the publisher doen’t want me to have to break my workflow (by switching to a browser, browser tab, or NetNewsWire tab) to determine that the content is good. If I have to break the flow, there’s much less chance that I will do command-shift-P (in NetNewsWire) to pop the your post into Ecto where I can quote it as part of my post (which ought to generate some additional traffic for you). There’s less chance that I will hit command-1 to pop your post’s title and permalink into Twitterific, where it can get pumped into the realtime information junkie network. And there’s less chance that I will hit command-control-‘ to pop your post’s permalink into Pukka where I can quickly tag it and stick it into del.icio.us, where it can be immortalized as important, seen by my del.icio.us network, and pumped into my blog and tumblog. In other words, you make it hard for people like me to help you. Now you might not care about that, and that’s a completely rational choice. But since just about everything in the blogosphere (after your good original content) is about getting flow (which doesn’t just mean inbound clicks) from other people, it seems like a short sighted thing to make it hard for flow to happen.

There are a few other dynamics which I think are relevant to Strobist, which don’t apply to all blogs.

1. Strobist is not just a blog, it is a source of reference materials. If you metered my accesses to the Strobist site, you would see that I access the site much more as a reference site than as a daily blog. I read the daily blogs, but since I am learning something that requires practice, trial and error, and so forth, I am always pulling up old posts (and those Lighting 101 and 102 pulldown menus) are a godsend for that. Which you have to go the site for. Dropping the 1 click that you would have gotten by forcing me to follow from the partial feed is just noise compared to the other volume

2. The advertisers on Strobist aren’t getting the value from the ads. If you make me go to Strobist in Firefox, Adblock pwns you. I never even see your ads. If you want to get value from Strobist, do something that works with what David is doing. Nonetheless, I’ve ordered several times from the Midwest Photo Exchange, not because they advertise on the site, but because they are doing something that works with what David is doing – so well that David actually writes about it. You might think you need an ad, but what you really need is to do something that will get David to write about you. Strobist is becoming a community, and the advertisers / sponsors of the site will get the most value by being a part of the community (see yesterday’s post on Nikon for tips). And that means more than just doing ads.

3. I was less vehement about full feeds that night (and I do love my full feeds) because I don’t think that David’s audience is an RSS enabled audience. The small sample size at the bar bore that out. So full vs partial doesn’t make that much difference, really. I’ve been reading the blogs of some wedding photographers because I think that maybe someday I might like to take a crack at that. But one thing I’ve noticed is that the word on Strobist is out. I see the techniques being mentioned. People see off camera flash pictures and want to know how to do that. And the answer that invariably comes back is Strobist (or occasionally, the OneLight). You can be sure that this is happening in real life, maybe even more so than on line. So the flow net for Strobist has expanded beyond the RSS savvy crowd and into the real world. No amount of full vs partial RSS feed is gonna change that.

But just in case, click here to convince David of the value of a full RSS feed. 🙂

Thoughts from the Seattle Adobe AIR stop

Leave a reply

Here are some thought from Adobe’s AIR Bus Tour in Seattle yesterday.

First, is that Adobe is laying out some serious money to promote AIR – they got a (literally) rock star bus, complete with beds, loads of electronics, and tour paint scheme. The event yesterday was at a nice restaurant which they rented for the day, and Adobe was very generous with food and drink, which was of a higher than average quality for a conference.

On the whole, the sessions were informative, although I wished that there had been a little more detail presented. There’s already been lots written about Flex and AIR/Apollo, so I’m not going to rehash any of that. Here are some of the more interesting tidbits that I picked up.

  • Kevin Lynch mentioned that when they opened the native code portion of shockwave, they only got extensions for Windows. It was pretty clear that they want to reach platforms besides Windows.
  • Mike Chambers reemphasized that point when he said that the amenability of WebKit to mobile (ported to Series 60 by Nokia, and now, of course, on iPhone) was one of the big reasons for their choice.
  • There’s some of sample code based on hacks that involve the GPS sensors, cameras, and other gadgets on the bus
  • Aptana is supporting AIR developement in their Eclipse plugin.

I also learned a new term from Lee Brimelow of Frog Design: a “deviner”, a person who has training as both a designer and programmer. I had never heard the term before, but it’s relevant to the content of the talk that Mimi Yin and I are giving at OSCON in a few weeks.

Ryan Stewart persuaded me to do a talk for the Ignite the Web sessions in the evening. I thought it fitting to give a presentation on “Openness and the Web”, based on the content of that string of blog posts that started my dialogue with the Adobe folks. The Ignite format (5 minutes, 20 slides switched at exactly 15 second intervals) is pretty demanding of speakers. I’d consider myself an experienced public speaker, but doing the Ignite talk had me pretty nervous. The delivery went well – I only had one gap where I got out of sync with the slides. Afterwards, John Dowdell, and Ted Patrick, as well as a few others, came to talk about the content of the talk. John and I traded thoughts and clarifications sporadically during the rest of the evening, and he told me that it definitely helped to have heard more from me in person. On the whole, it seemed worthwhile. The only downside is that now Ryan is trying to get me to sign up for the next Ignite Seattle.

Social Networks, Small Worlds, Bainbridge Island

1 Reply

Yesterday I had lunch with Annette Moser-Wellman, who lives on Bainbridge Island and is interested in innovation, creativity, and leadership. One of the great things about Bainbridge is that there are lots of people here who are doing interesting stuff. The hard part is connecting with the people that are doing things that you might find interesting. Of course, this is a problem in the wider world, but on an island of 25,000 people, with a decidedly small town feel, it seems reasonable to expect that it might be easier than normal to make those connections. The interesting thing about my conversation with Annette, other than the content – which spanned open source, innovation, education, and the Singularity – was how it came about. Annette had read Scott Rosenberg’s Dreaming in Code and noticed that I lived on Bainbridge Island. From there, she hopped onto LinkedIn, which led to our lunch.

That morning, In anticipation of the lunch meeting, I was reflecting on the value of the various social networking sites, when Anne Zelenka twittered:

LinkedIn attracts all sorts of people who would never blog or join Facebook or use Twitter, so it adds a ton of value to online life.

A timely tweet, to be sure. The key insight, I think is that one way of measuring value of particular social networks is the groupings of people that they “reach”. My Firefox bookmarks toolbar has a growing pulldown for social networking sites: Flickr, LinkedIn, Twitter, Dopplr, Upcoming, Facebook, and Pownce.

The ones that I’ve gotten actual value out of have been Flickr, LinkedIn, and Twitter. Flickr is completely an affinity group thing, so no surprises there. LinkedIn has a huge reach, as Anne points out, and perhaps because of its professional billing, has yielded several interesting meetings, and friendships. Not to mention job opportunities. There some interdisciplinary crossover, which I think is a plus. Twitter is very “hipster geek” focused, and has yielded new relationships with people like Ryan Stewart and Anne Zelenka, as well as being the impetus for the series of posts on Rich Internet Applications earlier this year.

In the end, for me it’s still all about finding your tribe. If physical book to virtual social network to real world lunch is what it takes, then I am game.

Open source peeps and Dopplr

4 Replies

People working in open source have limited opportunities to meet each other in person. My own experience is that meeting someone in person, even if it is only once, can be a help in working with them in the virtual world. The Dopplr service is a social networking application oriented towards people who travel. I’m already using it to find out who is going to at OSCON and ApacheCon US later this year. Meeting folks from various open source communities in person has been an enriching experience for me, and I’m glad to have help at making that easier.

Let me know if you want a Dopplr invite.

Silverlight and the DLR

17 Replies

Microsoft has announced that it is embedding a version of the CLR into their Silverlight RIA technology. Blogging machine Ryan Stewart had some of the initial details, and Sam Gentile has a good pile of links. The CLR enabled version of Silverlight will run inside Firefox (both on Windows and OS X) and inside Safari. This is a good step at cross platform support, but the omission of Linux, while not surprising, reduces the reach of Silverlight versus Flash or regular AJAX. Also, it appears that there are no Mac development tools for Silverlight, although presumably there is always text editors.

DLR
The most interesting part of the whole business is the Dynamic Language Runtime, which is the project that Jim Huginin has been working on since he arrived at Microsoft. The DLR currently supports JavaScript, a dynamic version of Visual Basic, IronPython, and IronRuby. John Lam’s work at Microsoft also appears to be paying off. eWeek had three good articles on DLR technology, and all three articles include conversations with Jim and John. It’s nice / interesting to see that two people could have a large impact on Microsoft. The DLR is being made available under a BSD style license. While I have to give props to Microsoft for choosing an unrestrictive license, I’d point out that a license is not a governance system, and while the DLR might technically be open source, the “Core CLR” definitely is not, and neither is the XAML portion of the Silverlight runtime — no surprise there. I wonder if we will be seeing a port of the DLR on top of Mono. I also wonder if IronRuby can run Rails, although that seems like a weird thing to want to do inside of Silverlight.

Linq
Another part which I find interesting is the inclusion of Linq as part of the Core CLR. I like Linq, and if Microsoft is going to try to define a new platform for inside the browser, I’m happy that they’re including Linq as part of the core.

Impacts
Here are some of the potential impacts of this announcement:

Since Silverlight will include the CLR, it will benefit from the CLR JIT and garbage collector, which together with Mozilla’s Tamarin, will raise the bar for JavaScript performance in the browser. It’s unclear whether regular AJAX apps running in a Silverlight enhanced browser would beneft from CLR acceleration of Javascript. I’m in favor of the browser vendors getting into a Javascript performance race with each other.

Allowing people to write browser side applications in multiple languages fragments the technology on the browser side. You could argue that the benefits of either IronPython or IronRuby are sufficiently large over Javascript that such fragmentation is ok. I’m not as sure that this is a good thing.

If there is significant uptake of IronPython or IronRuby for Silverlight development, that could have interesting impacts on the Python and Ruby communities. The Ruby community is already dealing with a proliferation of different Ruby runtimes, so there probably isn’t much new there other than a change in the mix of adoption of the various runtimes. On the Python side, its less clear, since the CPython implementation is the most heavily used.

The inclusion of facilities like Linq will boost the semantic level of the platform running in the browser. Granted, it only does that for Silverlight, but I hope that this puts some pressure on the other players to provide more leverage in the platform. If we are going to be building much richer applications inside the browser, we are going to need all the help that we can get.

So what?
In the end, though, I probably won’t be doing much with Silverlight, for the same reasons that I’ve written about before. The technology has definitely gotten stronger, but the other issues haven’t really changed much: there are no tools for the Mac or Linux, and as far as influencing the technology, you’re just standing outside the Big House, pressing your nose up against the window.