Category: Web building

Going where no mashup has gone before

dodgiemonk logo

Idea.

So Michael Arrington posted about BillMonk, a hella cool service that lets you keep track of outstanding debts between you and your friends… part of something they refer to as “Social Money“.

Now the first thing me and Tara thought of (before really taking a look) was — hey cool, but wouldn’t it be better if you could be at restaurant or something and SMS your debt to the service… which, duh, it does (okay, we’ll read more closely before jumping to feature ideas next time)!

But the second idea we came up with really has some legs… and will probably make the Attention Trust folks go all squishy in the knees: perhaps the next frontier in mashable services will be the nexus between your cell phone/SMS/remote devices and the range of services previously-reffered-to-as-Web-Two-Dot-Oh that you access through http-type connections (yeah, like the one that your browser made to this blog).

What huh?

Ok, in English 1.0: Behind the scenes, all these services which currently provide some utility separately really start to become incrementally indispensible when you can mash them together to form aggregate services of your own design. But now add in a Firefox-extensions-like model as personal in-betweener web service… kind of like Suprglu meets 43* meets .Mac meets Ning (conceptually). Ok ok, that still doesn’t make it much clearer.

I mean, here’s how it works now: I check in with some friends on Dodgeball somewhere… who cares where, but for example’s sake, let’s say Tantek‘s Lair (aka Crepes on Cole). At some point in the evening, we determine who’s paying for what… split the bill, etc., and if there’s any discrepancy (oops, Chris is out of cash again!) we ping BillMonk with the amount that I owe to so-and-so. Simple, but Dodgeball and BillMonk don’t know jack about each other. So while I’ve just created a checkin and an IOU, I can’t go back in my history of Dodgeball checkins and see where I incurred said IOU. Similarly, I can’t go to BillMonk and see where the IOU originated from. Sure, I can add a description to the IOU, but should I really have to when Dodgeball already knows where I am? See what I’m getting at here?

So let’s see how that fabled Web-Two-Oh open-API-goodness that we’ve all become accustomed with could make both services more valuable… Hell, let’s throw a little Plazes cell-phone action in there too for fun… And let’s see what kind of cake we can bake with the following: 

  • a service to notify friends where you are (Dodgeball)
  • a way to record IOUs (BillMonk)
  • a location-service for identifying and recording where you’ve been (Plazes)

Now, let’s say we merge in some kind of attention stream aggreagator and — presto! — we’ve got a view of where you’ve been, who you’ve told about your whereabouts, and where, with whom and when you incurred (or became the benefactor of a friend’s) debt.

And that’s of course, only the beginning. Toss in some mapping APIs (which Plazes and Dodgeball already support) and you can see watch your debt-accrue as you travel the globe! In fact, you could map your friends’ whereabouts to the same map and play your own mini debt arms race. Fun while watching all your friends go bankrupt! 

Yeh, anyway.

While this is all good and smaht, etc., you’re likely to start throbbing with, “ooo, yay, convergence!”

Okay, eff convergence.

I don’t want one service to collect all this data. I’m not a privacy maven, but even if it were possible to do the one-stop-shop thing, don’t do it, don’t try it, don’t even think about it coz I won’t use it. Nope, I don’t wanna be boxed in and so-help-me-Ford, I won’t let you. You and your proprietary megaservice can kiss my RSS.

BUT, I do however, want an external agnostic service aggregator (which I control and plug stuff into of my own choosing) to help me make sense of all this data… one API/feed at a time. Avoiding convergence allows me choice of services, allows each provider to innovate in their particular domain, and also gives me the freedom to experiment with different combinations of services as they are released and/or improved. Maybe I want to switch from TextPayMe to BillMonk without losing my history of transactions. This proposed third-party service aggregator would allow me to do this smoothly and seemlessly coz the data would be out there and tracked, yet neither BillMonk or TextPayMe would need to know about my prior service history. That’s data for my eyes and my eyes alone.

Sucks to be a service provider with open APIs you say? Puts them at the mercy of the whims of fickle “consumers”?

No, I don’t think so. Indeed, if you don’t open up, the open source community (or your competitors) will build something that does the same thing as your service and then they’ll open it up and give it away for free. So hey, I’d pay a couple cents per hundred transactions if you’re innovating and providing a really nice user experience… that also spits out data that I can plug in elsewhere, invisible to you (what do you care anyway?). Put your customers in the driver’s seat and I can pretty much guarentee you’ll not only get long term investment from them in what you’re doing, but heck, you might even get new Plazes, Dodgeball and BillMonk buddies with lots of friends who haven’t yet found out about you… and are eager to use whatever it is their friends are using.

Mashing up social networks: oh yeah, now there’s the next killer app. Gimme a way to cross-polinate, cross-aggregate, mix up, re-use, recombine or reinterpret and reshare and you’ve done something interesting.
Something I’ll use, and yes, probably tell my friends about. This is where mashups are going. And I can hardly wait…!

technorati tags: , , , , ,

Build me a distributed LazyWeb!

Microformats LogoSo I’m San Fransocializing with Tantek and Greg Elin, shootin’ the breeze and considering how we can push microformats into new domains and I got this idea for a distributed LazyWeb (I had no idea Hammersley wrote the original… Ben! You lazy bastard!).

If you’re not familiar with LazyWeb, it’s like this: Need something done? Just blog it and trackback to LazyWeb.org’s trackback address. Pretty simple right? In fact, that’s how I’m planning on having extension reviews work on the redesigned Flock site. But that’s down the road.

Anyway, as I was explaining…

I want to publish tasks on my blog and have them get aggregated along with a bunch of other people’s… but it would be crazy useful if you could group like tasks and aggregate them to see other people with the same needs. Who knows, maybe when you find 15 people wanting the same thing, you can start a Fundable project or something. You figure it out.

The geektastic idea I had was this (since, you’ll recall, the topic of conversation was microformats): use the vtodo component of hCalendar to represent your LazyWeb task. You could use the organizer, summary, attendee, categories and even status and priority classes to represent the aspects of the task. The value of the organizer would be a link to your blog using rel=”me” from XFN. If someone accepts the task, you can add an XFN relationship to the attendee link.

And then, through the magic of the intarweb, a spider could be used to seek out these tasks and index by tags in the categories. Subscribe a certain task-tag and voila! — your weekends will never be unproductive again! …and, I’ve got my distributed LazyWeb!

technorati tags: , , , ,

It’s an email, email, email world

I had a very useful and informative call last night with some folks from the Portland Usability group, organized by Frank Spillers of Demystifying Usability (a recording of the event is available for the next month). They had a lot of really useful feedback as they walked through the Developer Preview of Flock, explaining their expectations of certain interface elements and expressing confusion when they couldn’t figure out what terminology like “Star this page” meant or what a “Shelf” might be used for. Feature discoverability was another big problem; for example, they really thought that the history search was an awesome feature… but only once they found it!

On the one hand, a lot of the that I’ve been doing since we launched our Preview Release was validated. Much of the confusion they experienced has been addressed and hopefully resolved, though I look forward to doing more of these events both prior to and after each major release.

And since I was also able to give a high-level overview of where we’re going with Flock and what our vision of the web looks like (more sharing of timely “me-created” content than static-library-lookup-information old skoolness), they were able to point out aspects of Flock that didn’t seem to fit that vision — many areas, again, that we’ve been actively working on.

One thing that I didn’t expect — and this is more due to my own developeresque myopia than anything else — was that sharing to the group implied email! Yeah yeah, I know, what? Of the six people involved (albeit a small sample but nevertheless of fairly technology-familiar folks) only one knew of Del.icio.us… and that was Frank, the organizer. I purposefully chose not to explain what delicious was before we got started, instead interested to see how the group might discover or at some point desire “bookmark sharing”. Well, that never happened. At least in Flock (chalk one up for the Firefox del.icio.us extension).

Everytime they thought of sharing, they instantly turned to email (only Frank had previously blogged as well). So we’d get flows like this: Create a collection… Ok, want to share? “Oh, right click and email it!” Create a snippet in the shelf… Ok, want to share? “Oh, right click and email it!” And so on.

This was fascinating feedback. Apparently we have much to do to evangelize blogging, favorites sharing and similar socially-centric web services (Flickr had no traction with the group either) if we’re going to bring the benefits of Flock to folks who haven’t yet discovered that there’s a rich social social social world awaiting them!

…and yes, this really gave me even more enthusiasm for the direction that Flock is heading. We’re just a couple years ahead of the curve for the quote-unquote longtail, which honestly is a very very good place to be right now.

Improving composition in browsers

Blog QuillSo a bunch of us at the newly opened up Flock HQ were discussing the Performancing extension today, wondering how we could both support and benefit from their work… It’s clear that we need to improve the quality of composition tools available in browsers, period. Doing this by elevating the experience and smoothing out the behavior of the Mozilla editor (which both Flock and Performancing use) seems like the way to go, creating value for the open source, Flock and Firefox communities.

As it is, Firefox ships with this editor built-in. Thunderbird uses it too, as does NVU (though I believe that they forked awhile back). You can imagine that refocused effort on this editor could potentially lead to an alternative to plain textarea that’s both stable and adequately featured (as opposed to hacking on an embedded solution).

So the thing is, how do we go about defining and building out the specs for the next generation Mozilla editor? How do we better collaborate with folks like Performancing to make this a reality?

As for Flock, well, this effort really needs to exist as a community-wide project. We’re all already pretty focused on other aspects of the browser and while making changes the editor are essential long term, it’s not in our immediate roadmap. Sure, Anthony makes incremental changes here and there (replacing the span tags, for example), but we just don’t have full time resources to allocate at the moment.

And that’s where the work that the Performancing community is doing comes in. Ideally if we can collaborate and coordinate on the needs we both have, we can begin to craft a list of user experience and development requirements to support our comingled goals of bringing blogging to Firefox and Flock users.

Ajaxian recently posted an Ajax Office Roundup that provides us some insights into how people are trying to use editing in browsers. The reality is, we don’t need Word for the web, especially when it comes to blogging, but we do need some established basics, like bolding, italics, blockquoting, linking and so on. And while those are already fairly well accounted for in the existing editor, we’ve got to look beyond formatting to natively supporting rich metadata in microformats and other forms of structured blogging.

I’ll be pinging the Performancing folks to see if they’re down for working together somehow. Maybe we start be cross-polinating each other’s forums.

After all, this is about choice and working on building awesome tools. This is what open source is all about. So hey now, here’s a quintessential opportunity for us to get some benefit and promotion for the work we’re doing anyway.

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.

The Out of Towner Meetup

Net2 Logo So tomorrow night is only the second ever Net Tuesday event, being put on by CompuMentor slash TechSoup. Reposting the details:

On December 13th, join Bay Area web innovators and social change agents for demos, discussions and drinks at Net Tuesday!

Ed Batista, Executive Director of Attention Trust, will show you how to stand up for your attention rights, while Seth Sternberg will demo web-based IM app Meebo.

Doors open at 6pm at Balazo Gallery at 2183 Mission St. (Mission & 18th)

Net Tuesdays are held on the second Tuesday of every month, and are part of TechSoup’s NetSquared project. Email net2@techsoup.org or visit the NetSquared site for more details on how to join the movement to remix the web for social change.

So that’s great and all, but the interesting thing (well, besides the event itself) will be the post-Net Tuesday Out of Towner meetup, being organized by yours truly for a few out of town friends. I’m thinking that once the Net2 event is over, we’ll mosey on over to Medjool for drinks, food and general tomfoolery. San Fransocializing will likely occur, but that’s up to the individual attendees.

Anyway, go sign up and bring your friends!

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?