Daryl’s Flock Blog

This is just a test entry so that I can see if Flock’s news thingie updates correctly. It hasn’t been updating for me in an earlier build. So I’ve subscribed to my feed, marked all read, and will post this to see if it triggers an update. Cross your fingers.

I picked up the latest Flock milestone build (read: blessed by QA for testing by a broader community audience) this morning and am impressed. I have some beefs and some very positive impressions.

I don’t find the “web snippets” terribly useful anymore for a couple of reasons. First, I’m not a mousing type of guy, and when I do use the mouse, it’s generally in the top half of my screen, where one typically finds application buttons and where I tend to do much of my reading (I scroll down as my eye nears the bottom third or quarter of a screen of text). So having to drag things down to the bottom of the screen is a liability for me. It might not be as much of a liability if I weren’t primarily a laptop/scrollpad user, and if I were a Mac user accustomed to darting my mouse down to the dock at the bottom of the screen, this might be more usable to me. A couple of months ago, I blogged about how the shelf was making blogging easier for me and had increased my output. It had plenty of warts and boils even then, but I frequently found myself adding snippets to it as little pre-drafts for blog posts, quick notes to capture thoughts I wanted to get at later. I find that I’m not doing this as much lately, though it’s quite possible that’s thanks to my own sloth rather than attributable to changes in the shelf/snippet area.

My other big beef with the web snippets thing is that it seems to force an icon view even for snippets. Consistency of ui is important, but it’s not terribly useful to me to see only the first word of a bunch of snippets that are supposed to help inspire or remind me to write longer blog entries. So I’d love to see that changed. Unfortunately, I don’t know how best to change it. A horizontal view simply isn’t well suited to display of multiple snippets of text. The web snippets area also seems like a bit of a departure from the topbar paradigm, though one I can understand. It would have been weird to have an area between the browser buttons and content area that displays a snippets bar when you mouse over it, so the bottom bar made good sense originally.  Unfortunately, I think it contributes to an increasing potential for confusion about Flock’s user interface. It adds one more piece of ui in a different area of the browser that one must interact with. We now have topbars, bottom bars, and the reintroduction in the feed reader (about which more in a moment) of the sidebar. My vote would be to limit our interaction areas to two, moving the shelf into a sidebar that slides out under predictable circumstances. This solves the horizontal text problem and the ui schizophrenia problem.

Blogging

Performancing should put me on their payroll, I give them so much credit for their blog editor. Our editor is now faster and sleeker than ever, and I’m finding it more pleasant to compose in, with the controls down the right side gone and the update to the less crufty Midas editor. The source view also feels better, though it still needs some improvements that are underway. But I’m still not keen on having it in a window. I love the way Performancing has their editor in a collapsible area at the bottom of the screen. This runs contrary, I know, to my statements above that using the bottom of the screen doesn’t please me. Here’s the difference: I can have Performancing filling the half of the screen I don’t use and interact with it while using the top half of the screen I am accustomed to using. They make the bottom real estate useful, where the web snippets area sprawls out down there with big icons and little information. Performancing enhances my productivity rather than fragmenting it. I swapped some email with Perry in response to his reaction to one of our recent daily builds, and we decided that the way categories work isn’t ideal either. At present, you don’t get a categories dialog until after you try to publish. Meanwhile, you’ve worried that you’d have to go back in and re-edit your post on the server to add your categories, and imposing this sort of uncertainty on users simply won’t do. I’m hoping that as Erwan iterates on the blog editor itself, the engineering crew will make some small changes to the editing process as well. Even a little note saying “Hey, you can add categories in the next step” would be an improvement. Reportedly, the blog editor will soon be always on top for Windows and Linux users. This in part solves the problem of the blog editor that disappears behind the main browser when you change focus, but it introduces other issues, such as your browser window’s being obscured in a not-terribly-graceful or toggleable way by the always-on-top blog editor window. I might be ok or even downright pleased with having the blog editor in a separate window if there were UI in the main browser chrome that allowed me to toggle focus easily. It’s not the fact that Performancing is in a bottom bar that makes it appealing to me, but is rather the fact that it’s very usable.

From the beginning — way way before Flock was even Flock and before we ever dreamed we’d be creating a browser — one of our goals has been to facilitate the two-way web. The idea was that you could post something to share with your friends very easily and that you could see effortlessly what your friends were posting. Back in October, we wrote a web service to facilitate this process with bookmarks, and we’ve more recently done this using del.icio.us and Shadows rather than our own service.

The photo topbar has also feinted in the two-way-web direction, but it hasn’t been terribly useful as a communication tool to date. It has been primarily a way to look at your own photos and drag them into blog posts. This is a valuable feature, but it helps achieve only the publishing half of the two-way web concept. In the latest builds, Flock has made improvements to the consumption part of the photos topbar. You can add Flickr users as friends, and when they upload new photos, the photos toolbar button goes orange to let you know. No more clicking through to Flickr to check and see if your sister has uploaded new pictures of her new baby. When she uploads them, the button goes orange, you activate the topbar, you click the new button, and you’re gazing at pictures of your niece. This is a great time saver for those of us who might like to keep up with a few friends’ photos but who aren’t interested in browsing through a visual buffet of photos every day.

The feeds have also been updated to be significantly more robust and useful. They come with a sidebar that gives you a tree view of your feeds (optionally categorized). They maintain a read/unread status (per feed, at least — as far as I can tell, there’s no per-item status; this is fine for me, as it mirrors the bloglines functionality I’m accustomed to). If you’re at a site that has feeds, you just click the livemark icon in the urlbar to get a list of feeds and then click one of the feeds to add it to your subscriptions. You can then add folders and drag around to organize everything. And the kicker for me is once again the automatic notification of updates. I no longer have to go to bloglines a few times a day to see when the sites I read have updated their content. The browser chrome itself will tell me by lighting up a button. And in yet another instance, instead of facilitating only the push of data (via blogging and photo uploading), Flock comes to the rescue by pulling me to the content I’ve expressed an interest in monitoring. Seeing these features this morning absolutely made my day. There’s lots of room for improvement yet (for example, although all my items are marked read, the top-level tree item is showing a count of 20 unread items and thus keeps my toolbar button lit up), but this is a significant positive iteration.

Flock gets better just about every time I download a new build.

technorati tags: flockblog, flock, ui

Six months or so ago, I wrote the current version of Flock’s extensions site. It’s pretty simple and was intended to be simple. It wound up being even simpler than originally planned and has plenty of functionality hidden because we haven’t had a need for it or the ability to support it. We’ve thought a lot about various approaches to making extensions available, and I blogged some of those thoughts a few months ago. The quick summary is that we were waffling over whether to enforce quality for Flock extensions by officially hosting only a few or whether to have a free-for-all, or whether to blend the approaches. We ultimately decided on a blended approach, and we planned to launch a new extensions site in early February with the launch of the 0.5 release of Flock. For various reasons, that didn’t pan out.

I visited Flock HQ last week, and we revisited the subject. The result? I’ve burned some midnight oil over the last few days and have built a draft of Flock’s new extensions site. It’s a Drupal module that I anticipate ultimately making public in the event that any community sites or similar projects wish to host extensions. Here’s what you can expect to see when it launches in (unless history’s a good indicator) a couple of weeks.

• Search by (at least) keyword, locale, platform, and category.
• See what Flock staffers recommend
• Find extensions that get high ratings from the community, which presupposes…
• One-click extensions ratings
• Comment on extensions
• Convert extensions that don’t already work in Flock

This last one was a fun little piece of code to write, and I want to talk about it for a minute because I’m frankly a little proud of the way it solves a few problems both on the community side and the administration side.

Converting extensions is nothing new. I wrote a command-line utility six months ago that was handy for batch-converting extensions, though not especially suitable for broad public use. I also started work on a web converter, but I never got a chance to finish it. Luckily, the community stood up and filled the need by writing various server and desktop programs to help individuals make extensions work in Flock and discover what extensions had already been converted. Further, for the would-have-been February launch of a new Flock web site (complete with extensions site), John Vandenberg did a lot of work and provided lots of valuable input for an extensions module in particular and on extensions conversion and management generally. So my building a module to convert extensions isn’t exactly trail-blazing. The module nevertheless solves several problems in a way that blends some of these approaches and that I think will add lots of value both for Flock users and for our staff.

So, how does it work? Say you’ve done a quick search for an extension and can’t find it on our site. You’ll be prompted to go to the extension conversion page, where you can either upload or paste the url for the extension you’re looking for. The site then fetches the extension and reads in its meta-data. If it’s already in our database, the site updates a few fields. For example, it looks for locales and platforms the extension reports itself to be compatible with. So let’s say that someone else has previously uploaded the extension, but the version you upload supports more locales. Your action will update our record for the extension, making our meta-information that much more accurate. We also try to automatically figure out from the extension configuration who the author of the extension is, and, where possible, we provide “also by” information to help people find other extensions we’ve catalogued by a given author. It’s not perfect yet, but we’re heading in the right direction. And finally (among the goodies that give me a little thrill), we do some very basic security checks and provide a warning for extensions that do things that could potentially be dangerous. This merits some elaboration.

Over a year ago, I blogged about a major but necessary flaw in the Firefox extensions framework that makes is possible for extensions authors to write extensions that appear to be nice but that can morph over time into malicious extensions. All it takes is writing an extension that makes an XMLHttpRequest call to a remote server and evaluates the javascript string returned. Say I write an extension with broad appeal, and it makes such a call, and during the first week of deployment, the javascript returned by the server does useful and expected and non-malicious things. But after a week of gathering users, say I change the javascript returned by the server so that it reads your cookies and sends them to me or performs some other potentially nasty tasks. This is entirely possible, and it’s long fueled wariness on my part about installing extensions. The browser tells you only to install trusted extensions, but how many of us have even noticed that warning, much less paid it very much attention?

I don’t know of a way to address this issue fully, short of disabling extensions capability, which obviously won’t do. In order to help raise the security bar a little bit (not much, but every little bit helps), the new extensions catalog does a few rudimentary security checks. It looks for some potentially exploitable strings in extensions and produces a warning if they exist. In most cases, these will probably be false positives. For example, it’s perfectly valid and necessary for a del.icio.us extension to make XMLHttpRequest calls so that it can send and retrieve data to and from your del.icio.us account. Pretty much any extension that contacts a web service (read: every social networking extension) will cause the security flags to be raised. And it’s distinctly possible that users of our catalog will begin to ignore these warnings as readily as they ignore the browser’s warning about installing extensions. Every little flag or barrier to installing potentially malicious extensions helps, though, I think.

So, there’s a preview of what should be coming soon at a revamped Flock site. We’ll recommend a few extensions, and others will be pretty easily browsable. As we begin to accumulate ratings and comments, we’ll try to expose better and better ways of finding the best extensions. The catalog we’ll be releasing will in some ways be a very rough draft with its various hiccups and sputters, but it should be an improvement on what’s out there now, and it will empower the community to port most extensions to work with Flock even if we don’t publish all ported extensions. The process will also be streamlined for Flock staffers, and I think we’re heading down a good path for all of us. Stay tuned.

technorati tags: flockblog, community, extend