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?

IamCaltrain.com launches on new Yahoo Maps API

Flickr Photo Download: IamCaltrain Launches on new Yahoo Maps APICal and I teamed up on IamCaltrain, the easiest way to plot your daily Caltrain trip and figure out when the next train is coming. I’m really pysched about this little app and hope to continue to improve it over the next couple weeks (and at the upcoming SHDH).

Mashing up the APIs

Of course this is only yet another example of what is becoming the de facto standard behavior towards remixable web apps. Just check out Yahoo’s Maps API Application Gallery. Even the New York Times are picking up on this trend, writing about a recent Pew study that claims that 57 percent of all teenagers between 12 and 17 who are active online – about 12 million – create digital content, from building Web pages to sharing original artwork, photos and stories to remixing content found elsewhere on the Web. (emphasis mine)

In discussing Yahoo’s new pretty maps, Robert Scoble brings up another idea that I think is worth mentioning… mashing up the design of other APIs. While he cites a number of reasons Google’s maps are going to win the coming advertising war (think Minority Report on the web), there’s a far more interesting aspect to this story that I also hope to explore at this Saturday’s SHDH:  that of reusing the design of popular APIs to push the adoption and use of open source tools.

While some might argue that this is commonplace in open source already (for a pertinent example, AGPL’d CiviCRM has both an API for Drupal and Mambo/Joomla and makes use of the Google Maps API), I’m suggesting that there are new opportunities to build publishing apps that use existing, working APIs to publish to open source content management backends. The primary example I have in mind would use the Flickr API to publish media (primarily photos) to Drupal or WordPress using existing tools.

While the goal is not to necessarily achieve the same socially rich experience that Flickr offers, it would be quite useful to jumpstart the wider behavior of publishing photos to open systems — bypassing Flickr when you have more mundane or private image hosting needs.

So what I want is Gallery, the Drupal Image module (walkah, you listening?), or a WordPress plugin to reimplement the Flickr API and allow me to use 1001 to upload my photos to any of the sites that I participate in. This would be a boon for sites like DeviantArt or even print shops Zazzle, but also my humble little blog. Rasmus went and wrapped the API in PHP, but what I want is something that actually allows me to publish to any site — not just Flickr’s. Any takers?

technorati tags: , , , , ,

On designing in ambiguity

Bala Pillai, a friend of mine from Malaysia, sent me an interesting post that spurred a thought on the design work that I’ve been doing lately on Flock.
As an advocate for Asian economic development, he proposes that Asia is no longer “the producer of quantum inventions” because of “Good vs. Devil” religions that measure in quantities of right and wrong or black and white, which, he suggests, have lead to a certain intellectual inertness.

“…folks in Malaysia for example, don’t even realise that nearly anything significant we use, is conceived, designed or created overseas. And it is in conceiving, designing and creating that the most fun, the greatest bucks, the best jobs are. (And the shame of it is that Malays who are overall known for their creativity and imagination pay heavily for this.)”

In essense, because of this rigidity of thought, it is harder to achieve an objective perspective, especially about oneself or one’s work. Therefore, self-appraisals tend to favor those aspects which reenforce the ways in which your actions are consistent with your dominant beliefs. If this were not the case, the cognitive dissonance between objective fact and your subjective fiction would become overwhelming!
However, Bala makes an astute observation about the recent capitalist successes of the Chinese:

“If not for non-religious Chinese risk-taking and entrepreneurship in ambiguity, [Asia would] be in lots more worse shape then we are.”

What’s so curious about this is how embracing ambiguity encourages a certain kind of creative acuity that leads to intellectual dexterity to see around problems in novel ways. It dawned on me that some of the struggles I’ve had recently with design decisions in Flock have stemmed from my failure to use the ambiguity of the problems as opportunities to do something new or interesting. With limited time, I would float back to known or established solutions that didn’t always feel right but would seem to follow existing design paradigms sufficiently.

Consider, for example, Flock’s initial blog manager. I followed Thunderbird or Outlook’s models of having the accounts on the left, messages listed on the right and the composition area in what is normally reading area. This design was fundamentally weak because it relied on an existing solution grafted onto an entirely different problem. Once I accepted the ambiguity of the situation — exacerbated by the numerous solutions available for blogging — I realized that what we needed was something that didn’t encourage the management of your blog, but rather the act of composing and creating.
And with that, a solution emerged which will make it into the next iteration of our browser. One closing thought, again by way of Bala:

“Great work is done by people who are not afraid to be great,” Flores says.

The World According to Flores exists in three realms. The first is the smallest — and the most self-limiting: What You Know You Know. It is a self-contained world, in which people are unwilling to risk their identity in order to take on new challenges. A richer realm is What You Don’t Know — the realm of uncertainty, which manifests itself as anxiety or boredom. Most things in life belong to this realm: what you don’t know about your future, your health, your family. People are always trying to merge this second area into the realm of What You Know You Know — in order to avoid uncertainty, anxiety, and boredom. But it is the third realm of Flores’s taxonomy to which people should aspire: What You Don’t Know You Don’t Know. To live in this realm is to notice opportunities that have the power to reinvent your company, opportunities that we’re normally too blind to see. In this third realm, you see without bias: You’re not weighed down with information. The language of this realm is the language of truth, which requires trust.

Fernando Flores, The Power of Words

Technorati Tags: , , ,

Geeky Things

I’ve had a couple things cross my radar recently that I’d like to see be improved somehow… either in Flock (or browsers in general), RSS aggregators or blogging tools.

Better Reading through Columnization

Web reading vs. TofuWhich do you prefer? I think it’s quite apparent that Tofu makes reading webpages and blog posts infinitely easier and more enjoyable. So where’s the Firefox extension? Huh huh? I guarentee you this will get into Flock eventually… if not my next RSS aggregator. Or both…?

Well, looks like the recent Firefox betas already have this. Now to just see some smart Tofu-like uses of this feature!

DOM state in history

With all the hoopla about AJAX-based interfaces, it’s about time that browsers get keen to the fact that the DOM state is part of your history. It’s not some scripty side-effect — no, when I use the back button, I expect the page to be in the same state that I left it. This should be the case whether I navigate off to some other page or close the window or tab. The only way to restore the state of a page back to its original state should occur if I clear my history or exit out of my browser (or somehow reset the DOM through some other intentional mechanism).

And this should exist in the browser because it’s the thing that’s storing my path history. So what does it mean when the browser adds DOM state to my history? For example, when I use Gmail and navigate off to some other page and then return, I would no longer lose the email I was reading or composing. In fact, I could even load up Gmail in a new tab or window and find myself in the same place where I left off. Which is exactly what I want.

So the effect would be in effect to maintain your session state across tabs, windows… no matter where you are or what you’re doing, the browser would be staying with you, never skipping a beat, making sure that every little action you took was recorded and there for you to return to until you decided to start afresh.

It’s time the browser got wise to the current state of web application design. If not to encourage the further development of fast webapps like Basecamp or Flickr, but to make the browser reflect user expectations about the purpose of the back button!

Blogbars

BlogbarsThe last thing on my list concerns a rather recent feature that Matt just launched on WordPress.com. It’s just like the Blogger toolbar, except that his bar applies to WordPress.com account holders instead of general visitors. It’s a good start, but I think it can be better. He’s open to ideas — as am I. How can this tool help you blog better?

Hmm, if only the browser could facilitate blogging somehow… heh.

Technorati Tags: , , , ,

Why microformats are the glue between web content and a richer online experience

Why microformats are the glue between web content and a richer online experience In response to my introduction, Andy Hume asked me on the Microformats-discuss list:

What kind of microformat support are you looking to get in to these publishing tools? Obviously wordpress has built in support for XFN. What else are you trying to get happening?

So now it’s time for me to put on my visionary cap and mention a couple ideas I’ve been stewing on about why microformats make good sense for web publishers and web tool builders. I won’t get too pedantic or preach to the choir. Rather, I’m just gunna outline some of the obvious things to me that make creating the lowercase “semantic web” worthwhile, assuming, of course, that certain enabling technologies and innovations occur.

First, let me point out that the cost of implementing microformats is less than minimal and in fact, in some cases, can give you a net gain given the reduction on time spent figuring out what CSS classes to use. As a former-web-developer-junkie, it was my job to come up with unoriginal ways of identity bits of content on webpages so that I or someone else could come back later and figure out what the heck I was doing.

This lead to me to do things like code lists of people with a container that specified that, indeed, I was working with a list of people and not dates, dogs or envelopes. Why would this be useful? Well, what if you wanted to use a different icon to denote a person, date, dog or envelope? You’d need to know what class of object you were working with. (Just bear with me here.) This becomes a pain when you have to do this over and over again and or work on someone else’s code. However, with a sufficient store of standard microformats at our disposal, such situations could theoretically be avoided. Rather than having to reinvent a classing system everytime, I could simply turn to the related microformat standard and call it a day.

So that’s great and all, but why do you bother touching code anymore anyway with such able CMS and blog tools available? Why not just bake it into those publishing tools and be done with it?

The short answer is that that’s happening, and we need to see more of this work get done. The problem seems to be related to chickens, eggs, carts and horses, in no particular order. And until they all get sorted out, there’s a great deal of developer apathy best captured in lines like, “Why should I care?”

Well, better than just spouting out about the practical benefits for web developers, there are functional benefits which I expect to see available in the coming months. As a prelimary example, check this out:

I created a Greasemonkey user script that will find those hCalendar events and provide a link to import them into any calendar program that supports the iCalendar format (most notably Apple’s iCal and Mozilla’s Sunbird). What does this mean? Well any time you see an event on the web that has hCalendar information, you can click a link and it’ll be added to your calendar so you don’t have to copy the information by hand.

unmediated: Greasemonkey and Microformats

So just imagine once this kind of support becomes native in the browser… that’s when really interesting things start to become possible. And soon, I’ll outline just how I see this happening.