February 16, 2010
The separate window sucks. Google Chrome has a tab for the download history which definitely is an improvement over the separate window, and it allows you to search downloads.
There are two cases that should IMHO be handled differently:
- downloads that result in the opening of a program (e.g. PDF)
- downloads that just drop a file in a directory
For a) you don’t really need that many visual cues. Add an entry somewhere to the download history so you can find it later, but that’s all. The user doesn’t need to or want to do much else. The file opens in another program, case closed. The b) case, however, often concerns long-running downloads, and they definitely require more user action when they’re done. Here the UI should be as non-intrusive as possible, allowing the user to continue working while still giving feedback on the download’s progress.
Personally I use the Download Statusbar extension. It gets the workflow for b) pretty much right IMHO: There’s non-intrusive visual feedback at the bottom of the screen, so I can continue doing something else. Once the download is done I can come back to it without having to check a separate window or tab. Once I double click on the file to open it, it disappears from the download bar. So it’s gone from my “todo list” of downloads to process (it’s still in the download history, though). This is definitely better than having a manual Clear button.
A really nice feature, particularly for the a) case, would be if the download history was actually put to use. Here’s something that happens to me a lot: I open a scientific paper (PDF) from the web in Preview.app. At some later point I read another paper and it refers to the first one. The hyperlink in the references takes me to some page where, unaware that I downloaded it already, I end up getting a PDF I have on disk already. It would be very cool if Firefox recognised this and, instead of dropping another PDF turd in my directory, just opened the original download. Of course you’d need to check
Last-Modified headers etc., and perhaps there could be a simple enough option to force a re-download.
To summarise, I would do this:
- The download history (née Download Manager) is in a tab, searchable, and there’s no Clear button (much like your page history it could be cleared from Preferences).
- Downloads that open in a program get an entry in the history but no visual cues. If people want to revisit the file, they could simply go to the page they got it from and Firefox would search in its own download history for them. Of course, they can always manually search the download history as well.
- Progress for downloads that are long-running and/or don’t open in a program is shown in a non-intrusive way (e.g. some bar on the bottom). Double clicking or having the file exposed in Finder/Explorer will clear them off this bar, but of course not from download history.
February 12, 2010
This is part 3 in a loosely coupled series of blog posts about improving the browser for the cloud, particularly Firefox. In the first post of the series I made my case for why we need web browsers that are designed for today’s cloud apps. In parts 2a and 2b I have been exploring tabs, particularly how to deal with lots of them. And how a simple change in tab behaviour can allow me to blend the previously separate concepts of bookmarks and tabs (cf. my BarTap extension.)
In this post I’d like to muse a bit about creating tighter integration between the browser and webapps. We’re using a lot of webapps these days and a lot of them we never quit. Hence people came up with the idea of “app tabs” which are tabs in your browser that are always there. There’s an extension for this, and more importantly, app tabs will be an integral part of the future Firefox UI.
Part of the idea is that app tabs don’t need any chrome, which is geek-speek for the browser UI. Think back/forward buttons, URL bar, etc. In a way that’s true because the webapps displayed in these app tabs are typically self-contained and don’t need navigational UI elements. But this got me thinking: Perhaps there are other UI elements that a browser could provide to make the webapp experience easier? As outlined in the first post of the series, I find it a bit worrying that webapps employ so many different UI paradigms, thereby evading the most humane feature a UI can have: consistency.
But as I also said in that post, closed environments like a mobile platform (e.g. the iPhone) have shown that apps like Facebook and WordPress can actually be made to have a similar look and feel. Why not do the same thing, possibly on a smaller scale, in the browser?
Due to a transcontinental flight I had some otherwise unproductive time earlier this week, so I hacked together a small extension called Vanadium that does just that, albeit in a very very primitive way. It basically hides the navigation chrome for app tabs and instead displays the “vanadium”, a toolbar that represents actions for the webapp. Here is Vanadium in action using Gmail:
I’ve also integrated it with Twitter, though of course the Reply button doesn’t make that much sense there:
All in all it was a fun experiment (certainly a nice way to spend a flight) and I think it’s worth pursuing the idea further. Of course not all toolbar buttons make sense in all webapps. And the way the Vanadium toolbar works together with the webapp would definitely have to more sophisticated. I think the most promising item would be the search bar so I’m thinking I’ll be investigating a cross-webapp search bar next.
What do you guys think?
February 10, 2010
Carlos de la Guardia has written a book on Grok, a Python web framework I helped kick off and contributed to quite a lot. I was honoured to be asked to write the foreword for it. Here’s what I wrote:
A little less than a year ago, Zope 4 was released. As the successor of the complex, verbose and certainly not agile Zope 3 (now called BlueBream), it was instantly welcomed with much cheer. Naturally I chimed in and announced without much hesitation that the forthcoming 4th edition of my book would already be based on lean and mean Zope 4.
Sadly these were all just April fool’s jokes.
Sadly? No, I should say luckily. Because something much better came out of Zope land just a few months after we jokingly invented a new Zope version. Grok 1.0 was released. And thanks to Carlos’ tremendous effort, there’s now a book to accompany and celebrate this achievement, too.
There is much to say about this book, but I’m sure you’re eager to get started with your web application. So let me just tell you what I like best about it.
Carlos has managed to capture the Grok spirit in this book. It is concise, not too heavy and doesn’t beat about the bush. Yet it manages to hit all the bases of web development. With a spikey club, of course. It is as smashing as the framework itself and I hope you’ll enjoy both as much as I have.
February 5, 2010
Hi. My name is Philipp and I’m a tab addict.
I treat browser tabs as applications, bookmarks, to do items and many things more. I keep a lot of them open all the time. To organise them I use the excellent Tree Style Tab add-on. But more on that below. First let’s talk about the implications of having lots of open tabs.
Pay now, drink later
The thing is, when you’ve got lots of open tabs, you become reluctant to restart Firefox. Not I want to do that often, but sometimes I have to, e.g. when Firefox is being a memory hog again. Or when you need to restart your computer because of a software update.
So why do you become reluctant? Sure, Firefox’s excellent session restoring facility can bring all tabs back, but having ca. 100 tabs restored sucks up a lot of network traffic and a lot of CPU power. That can effectively render your browser unusable for a minute or more.
Here’s the deal, though. I don’t need all the tabs immediately. As said, a lot of them are just bookmarked as “I want to read that later” or “need to check that out.” That means Firefox shouldn’t need to restore all tabs immediately.
Hence BarTab was born.
BarTab is a Firefox extension that hooks into the tab mechanism. It intercepts when tabs are restored and/or opened in background (this is configurable) and doesn’t load their contents until you actually visit them. When restoring tabs from a previous session, it will even pull the favicon and website title from Firefox’s history service so you won’t have to stare at a URL. This is what it looks like:
There’s a usability lesson in this
Now some of you might give me a perplexed look and wonder why I don’t simply use bookmarks. The answer is pretty simple: tabs are right in front of me. Bookmarks are either in some menu, toolbar or sidebar. And as a concept they are orthogonal to tabs. But why have another concept when one will do?
So BarTab effectively blends bookmarks and tabs into one. In that process the session store service has replaced the bookmark service. That’s good because the session store keeps track of all tabs I have opened and even the ones I’ve recently closed. That makes my interaction with the browser a more humane experience, because not only do I not need to do anything special to make Firefox “bookmark” something, I also get a second chance, or “undo,” if I accidentally close something.
Beautifying tree tabs
As said, I use Tree Style Tabs to organize my various tabs. Two weeks ago I started creating my own custom theme of the tree, modeling it after the trees we find in sidebars of various OS X applications (e.g. Finder, iTunes, Mail.) This effort has now culminated in SidebarStyleTab 1.5 which replicates the OS X experience quite well, including tricky things like resizing the tab bar and drag’n'drop. Here’s what it looks like:
The best news, however, is that thanks to the author of Tree Style Tab, Shimoda “Piro” Hiroshi, most of SidebarStyleTab will be integrated into the next version of Tree Style Tab (0.9). He has also provided some useful insights into the development of SidebarStyleTab and BarTab, so much thanks to him.
February 3, 2010
Chris McDonough has written a book on repoze.bfg! repoze.bfg, or simply BFG, is a web framework written in Python. It’s of Zope pedigree but borrows many ideas from Pylons and Django as well. It’s simple yet powerful, agile, fast, has close to 100% test coverage and is extremely well documented.
Most importantly, however, BFG is true to its motto “pay only for what you eat.” You can use SQLAlchemy, Zope’s object store ZODB, or some other persistence mechanism. You can use Zope-style object traversal, Routes-style URL mapping or a combination of both. You can use Zope Page Templates, Genshi (both through the extremely fast Chameleon engine), Jinja, or your favourite templating language. You can write your application in an extensible manner using declarative configuration, or you can just use the Python API. You can deploy on Google App Engine, Apache and mod_wsgi or anywhere else that supports WSGI. And you needn’t worry about learning about the stuff you’re not using.