Tag: Flock

On Integrated Feed Reading

Feed IconRyan King pointed me to a post by Tim Bray about how unintuitive feed consumption is in browsers today.

I couldn’t agree more. Indeed, RSS and general feed consumption in browsers have been tacked on, hacked in, and bludgeoned into the UI in inconsistent and narrow ways. Safari‘s got its poorly-named RSS view. Firefox (for now) has its simple toolbar and livemark feature as well as countless third-party add-ons.

We’ve also got some great web-based and desktop tools whose tasks are to deal only with feed content.

But all those are simply not sufficient nor reflect how fundamentally syndicated content is changing the way people interact, publish and share on the web.

To date, we’ve taken mere baby steps towards a truly syndicated web. We’ve tended to stay close to our concrete, static websites because of the familiarity and stability they offer us. We’re used to things existing in one place at a time in real life; on the web, general expectations have stuck to this powerful paradigm (look, I had a talk with my mum about this stuff so I know it’s true! If you already get RSS, you’re excluded from this generalization (notice my use of the word “general“?).

What is becoming increasingly clear, however, is that the old ways of thinking about content and where it should exist (or indeed where it actually does exist) no longer need apply. Consider podcasts, the perfect example of empheral media. You can’t search for podcasts directly; no, instead you have search for text about the podcast unless you go to some visual directory, which still relies on word and image (still not aural search technologies — we need the Riya of podcasting!). On top of that, you typically have to download the “physical” file and play it locally or on your pacemaker, severing the link back to the original source which may be updated or changed later.

The point is this: Tim Bray is not only right but the problem he describes goes deeper than just poor feed integration and workflows in existing browsers. It’s that browsers aren’t moving fast enough to embrace the potential that syndicated content has for radically improving the efficiency, responsiveness and collaborative nature of the web. Think about all the information you consume with feeds already — it’s only going to get worse until browsers fundamentally look at the web as an event stream and less as a library of independent books and pages.

Browsers in particular need to change to address this emerging opportunity and make it both easy and seamless to leverage the benefits of syndicated content. Flock is obviously taking a stab at it, both in the browser and in how we’re architecting our web real estate (or should I say faux estate?). In my view, Flock is an API aggregator that lives and breathes syndicated content. Yeah sure, it’ll load up webpages like any other browser, but it’s how we expose web services and feed content that’s really exciting and new.

So now I’m curious. As hourly Flock builds aren’t terribly stable, I’ve been without an aggregator for some time and so I’ve probably gotten behind in personal aggregation trends. How have you guys been managing your feeds? I notice that I get a lot of traffic from Bloglines and Rojo, so what are the key features you’re dying for in a syndicated content app?

Architecting the Flock Content Platform

The Future of *.flock.com

I had a meeting with Daryl, Vera and a sleepy Lloyd the other day to figure out how to bring the Flock.com website properties forward, in terms of both design and utility as well as towards an architecture for participation (thanks Tim!).

So what’s gong to happen to *.flock.com? Simple: massive syndication, resyndication and the collapse of web development as we know it.

Using Drupal as our core platform enables us to move content back and forth between all the different platforms that we use (and trust me, there’s quite a few (password: flock). It also means that the content building blocks that we’re using to build our site will be available to our community to mashup pretty much however it wants (sticking within some liberal licensing scheme, of course (thanks Larry et al!)).

The implications of moving to such an architecture are significant.

To begin with, it means that besides producing content ourselves, we’ll be able to consume feeds seamlessly that our community produces. Yeah, so we can pull in other people’s blog feeds, Flickr feeds, forum feeds and on and on (thanks for adding RSS to Basecamp, Jason!). If it’s got an API or feed output (password: flock) (or is marked up with microformats) figure that at some point we could use it somewhere on our site. It’s like one big disgusting paste-board exercise. Glorious, glorious!

Roadkill ElmoSo get this: this is where web development is going; this is also where Flock is going. Static websites are a relic of a foregone era. It’s no surprise that when you come upon a prone animal on the side of the road, it’s a good bet that it’s dead. Roadkill or natural causes or radiation sickness. Same thing is true on the web.

Yeah, if this direction sounds like chaos, it’s not. It’s ordered madness, which, you’ll note, has massive amounts of potential energy in its structure. Go ask a physicist what that means coz I have no idea. Fortunately, we’ve got some tricks up our sleeves to tame this beast. Check it out.

One thing that’s important here is being able to 1) navigate your way around the site and 2) get back to where you were many days or weeks ago (in an event stream, how do you hit pause?). Well, for one, tagging. Duh. And rich, full-text search (thanks Google!). And a social network thingamabobber. And favorites. And outgoing feeds. With permalinks.

Gee, a website that mirrors Flock’s featureset? Eeeenteresting.

No but seriously, back in the days of Round Two we were building both a browser and a web service. Why? Well, it’s actually pretty interesting when you’re designing both the content source and the user agent. It’s like choosing both the bread and the cheese for your fondue. Or chocolate and fruits. Um yeah ok, but why? Because intimate knowledge of both sides of the equation helps you fill in other variables that much faster!

Consider: 1 + x = 3.

Easy right?

So try this one on: APIs + Feeds + Drupal + Microformats + Flock + mojo, baby = you figure it out.

But I’ll tell you one thing, it’s going to kick ass.

Flock landing in China

Bart Decrem talks to BokeeFlock’s crossed the Pacific and is landing in China, the land of free speech and civil liberties!

No but seriously, the sun doesn’t set where Flock is going, so China had better get ready. Bloggers know no boundaries and sure as hell aren’t polite. When the Bokee edition of Flock comes out, proponents of democracy can breathe a sigh of satisfaction; we are taking back the web and talking about it every step of the way. And you can’t stop us. You won’t stop us.

Podcasting means everyone can be a celebrity

Factory RockstarSo in my other life as a fake celebrity, I get interviewed a lot or end up in OPML (other people’s media and links).

I thought I’d post a bunch a these for reference, more to promote the enterprising work of these kindred spirits than for any self-gratifying purposes (yeah right). But no, seriously, I’m totally honored that any of these amazing folks would take the time to chat with me and have me ramble on and on about changing the world and such nonsense. I don’t know why you’d listen necessarily either, but if you’re into sadomasochism, here’s hours of pleasure for ya:

And I might be appearing on Irina and Eddie’s fabulous Geek Entertainment TV soon… And then, well, there’s the incredibly embarrassing drunken stuck-in-an-elevator-in-Paris vidcast that I really shouldn’t be linking to. Eh, c’est la vie.

Offline Extension Development for Flock

Proposed Round Two Offline Action Syncing UII had an interesting discussion with Freeman Murray at SHDH last night about offline apps for use in remote areas where network latency can sometimes stretch from days into weeks for access to a “network”.

In such circumstances, you’ll have folks driving around on mopeds or busses with wifi antennae, USB drives or CD-ROMs delivering email and providing a means to getting “online”, admittedly asynchronously. Thought 28.8 was slow? Try email by bike messenger. It’s only one step above message delivery a la Paul Revere.

But in some cases, this is the best they’ve got and you can’t expect Google to trot around the world setting up mesh wifi networks for these folks (not in the near future anyway). And while some folks are working on this project and it is getting better, nevertheless, we must constantly be aware of and design for a rich offline experience.

This is especially close to me, considering I’m writing this on BART without connectivity as I head to the airport. Yes, even in industrialized areas connectivity is still not guaranteed (let alone free).

So an idea I’ve been playing with for some time is how Flock can support offline browsing and interaction, beyond pulling simple content from your cache or downloaded feeds. In the old model of the static web, the permalink model made sense and was perfectly useful — indeed, it’s still nice to be able to pull up that bar’s website when you’re wandering around Paris at 9pm, an hour late for the meetup that you helped coordinate and you’ve got no idea where it is except for the micromap saved in your browser’s cache.

But the problem is that we’ve divorced the data from the interaction layer. It’s like having your Halo saved games without having the game engine to play them. Boy, that’s a whole truckload of fun.

So anyway, Freeman and I were discussing how Flock could help with this problem. One idea that has some legs, I think, combines data delivery in microformatted XHTML pages (you’re caching it already, might as well make the data semantic and thus useful) and then allow basic interactivity with that data through extensions that are designed for both online and offline use. Thus, in the event that you’re offline, well, instead of pulling unsuccessfully from the server, it would pull from your local cache and allow you to do certain basic things, queueing your actions to be performed when you have connectivity again.

Indeed you could even use a P2P architecture for this, sharing encrypted offline action-scripts across a mesh network. When any one of those nodes reconnects, it could upload those instructions to the final destination where they’d be executed in batch. This would have the added benefit of spreading the need for connectivity across many nodes, instead of just one (like a USB drive which could get lost, stolen, confiscated or otherwise compromised). Should the actions have already been performed when the “message in a bottle” arrives, the commands would be simply ignored. There are technical details in here that are beyond my comprehension, but be that as it may, the idea is promising.

So back to offline extensions development… Freeman proposed an architecture in which Flock would ask the web app for a locally-run “servlet” that would provide similar offline interactivity when not connected. Autodiscovery would happen in the way that sites provide favicons or perhaps through a rel=”offline” link. The question though, is whether the user would need to take explicit action to install the servlet extension outright, or if, by visiting a web app (like Gmail or Basecamp), you’re implicitly expressing your interest in using the functionality of the app, whether on or offline.

I think the latter reflects a reality that I want. Installing apps on the desktop doesn’t make sense anymore, what with all my data being hosted in the cloud. So being to access and manipulate my data when I’m offline is going to become a requirement that the browser can tackle. I mean, this is the problem with solar power. You need to use your car whether it’s sunny or not, and so we’ve got rechargeable batteries, right?

Well, I think you get the point. Here’s the high-level description of the proposed solution (which I may or may not have communicated effectively):

  • microformatted XHTML cached as your local datastore
  • locally-run servlets that offer data interactivity simulating the remote data store
  • offline actions supported in extensions
  • queueing mechanism in the browser to synchronize via XML-RPC or p2p encrypted action file when connectivity is available

I probably got a bunch of the technical details wrong, but whaddya think of the general concept? Does this already exist in some other form somewhere?

Towards real bookmarks/favorites

A Bookmark

It occurs to me that bookmarks would actually be useful if they acted like real bookmarks and helped you get back to somewhere specific — somewhere more precise, for example, than a URL. Bookmarks like we know them today aren’t bookmarks at all, and indeed that’s why we renamed them in Flock. Favorites imply interest or attraction: it’s how you express “this is interesting or important to me; I’d like to be able to return to it or share it with others.”

But up until now, and this is most likely due to technical limitations, bookmarks have classically referred to a specifc URL or URI — some place on the web that you presumably want to go back to, sometimes often. But that’s more like marking the corner of the chapter you’re on than specifically helping you get back to the head space you were in, the thread of the discussion you were participating in or to a specific moment in a multi-step process.

Think about it like this: Favorites should be used to express interest, Bookmarks should be used to help you resume whatever it was you were doing before (reading, writing, browsing). Bookmarks should be stateful; they should remember not only the X and Y coordinates of a webpage but geographically where you were sitting when you were looking at the page. Bookmarks should retain temporal data about when you accessed the page first, last, most recently, for how long, for how long over time and whether your view has remotely changed since you last made a visit.

Bookmarks should be tools for getting things done; the task of remembering or restoring state should not lie with the user, but with the bookmark capturing tool. So if I want to bookmark the way I’ve setup my browser tabs, sidebars, topbars, input fields, textareas, video playback status, and so forth, I should be able to do this. OmniWeb partially offers this with their Workspaces feature. If I want to bookmark a workflow or series of actions that I take repeatedly, that should be possible. Obviously, I should be able to bookmark people, events, reading lists or other sources of syndicated content to be aggregated later.

While I’ve got a lot of ideas about how Flock is going to do all this, I’ve been watching with eager interest Mozilla’s plans for Places and Bookmarks in Firefox 2.0+. Frankly, the designs look a lot like what’s in Flock already, as well as where we’ve already been planning on going with Favorites. Firefox will be removing hierarchical management and adding Labels (not suprisingly in line with Picasa’s labels interface). Who knows, there might be a great opportunity for Flock and Firefox to begin collaborating on feature design here?

Regardless, it’s becoming more and more clear to me what a bookmark should be and what a favorite should do. I’d be interested to hear what other people think of this distinction and how this might help you get things done. Remember, Favorites are like starred emails in Gmail or fav’d photos in Flickr. Bookmarks should be more stateful — like resuming a computer that’s been put to sleep. Does this idea have legs?

Paris Meetup Details

Lizard LoungeLooks like we got ourselves a venue for the all-in-one Les Blogs/Flock/Bar Camp/Word Press/Riya Meetup! So, tonight, Sunday, December 4, 2005 @ 19h05 at the Lizard Lounge (18, rue du Bourg-Tibourg, 75004 Paris). Should be a pretty good crowd, so if you’re in the area stop on by!

technorati tags: , , , , ,