So I’ve decided to take a more aggressive approach to the interface and interaction design of Flock. It’s risky, a bit unorthodox and is something that will take some practice, but since it worked fairly well while I was working on Spread Firefox, it seems only logical that I pursue a more transparent, collaborative and inclusive design process.
So what does this means? Well, basically a whole lotta Flickr!
I’ve already posted a couple screenshots of what the Flock Photo Uploader should look like (compared with how it’s been looking in recent builds). This accomplishes a bunch of things, beyond getting the design process out in the open.
For one thing, it allows me to communicate the intended appearance of features to many developers at once (instead of having my designs vanish on one of the nine levels of Bugzilla hell). I can add notes, a description and all that other good stuff that your typical Flickr photos have, but I can also link them to actual bugs in our system with tagging. For example, flockbug1655. This means that if other people have uploaded mockups to Flickr as well about the same bug, we can all see and compare each other’s work and, going one step further, if anyone has blogged about that bug, we’ll be able to discover that content with Technorati. Truly distributed bug squashing!
Now, obviously we’ve already got groups on Flickr for Flockbugs and Flock Experience Design. Those are the two obvious places to go to see discussions on these topics. The problem becomes very quickly, however, that all this information is in Flickr and not shared in our developers’ native environs. So I’ll be working with Daryl to add a feature in Drupal that will aggregate this information (primarily based on tags). We’ll obviously be able to show full mockups as well using the Flickr API and then hook in data directly from the bugzilla bug (that’s the hope anyway).
Finally, I’ll be working with Gandalf on a Flockzilla Contributor Dashboard — designed from the ground up to make it easy to keep tabs not only on what’s going on in Flock development, but also on your own task list. This will again aggregate information from all kinds of disparate sources and will support your involvement based on custom community roles (designer, bug killer, developer, interested blogger and so on). This tool will of course feature into the planning for CivicForge but for now it makes sense to address our internal use cases. But at least we’re starting somewhere and trying to find new ways of opening up open source design to a wider pool of eyes!
Factory Joe 
Hi Chris, I understand the need to simplify web services/apps with Flock, but from what you’re saying appears a lot more like Flock catering to specific services instead of enabling a general connect (to those services that are open with apis or end points of sorts to connect). In a couple of months, years down the line, there may be a lot more services that could be used via Flock. So, may be Flock should have a connecting end to begin with rather than supporting them, because browser is the first contact to the user, not the other way around. Do what I say makes any sense?
Chetan, what I like about Chris and Flock developing a Flickr uploader is that the Flickr API is published and robust. There is nothing stopping Drupal, Joomla and WordPress from implementing the API as Flickr defines it (in fact, this should already have been done by now, imo). Once that has happened, the Flock image uploader will upload to whatever service implements the API. Designing to the interface is always a good decision, and I think this is a really good step. Sites like Ourmedia.org and NowPublic.com would benefit loads from Flock and the FlickrAPI uploader.
-Robert
It’s always great to learn from a blog post that you’ve got work entering your queue. 😉
Robert’s got it right. In fact, I put a call out a short while ago asking that folks take up the task of reimplementing the Flickr API in Drupal, WordPress or other open source publishing tools. A fundamental goal with Flock is to promote choice on the web — and we fully intend to build our tools to interoperate with as many open source systems as possible. It just so happens that Flickr is the best (and for me, most familiar) photo sharing/design tool that we have right now. And I’ve also got much work to do on building Flock itself, so I can’t get obsessively caught up in the tools right now so long as they allow me to be more productive, efficient and open (we use Basecamp internally which is a shame — because I would love for a lot of that content to get out!).
Again, if Bugzilla had Flickr’s simple but robust set of image manipulation and annotation tools built in with an API for me to use for uploading, I would be using that. But it doesn’t, so for now, I want to lead by the example of what I want and need to get my work done and hope that the open source community gains something from these new workflows. Ideally we’ll be moving towards cycles that are heavy on design and interface up front with engineering coming in as an the essential ingredient to make these things possible, better built, or interoperably streamlined.
And yes, Daryl, this is a little new, but I’m hoping to just extend the awesome work you’ve done on the new PR tool for this purpose!
Robert, Chris: Well, that’s a great idea, using Flickr API, I mean. Why didn’t you say so?
May be it’s a good idea to announce it publicly that you will be using Flickr API. So, developers of software and services would start in parallel working with the available API won’t lag behind. When Flock goes mature, so will all the apps, instantly transforming Flock into an all in one app of sorts.