Update: It seems Safari 5.1+ together with OSX Lion’s “All My Files” Finder view implements something similar as I suggested. Funny!
Update 2: It seems Apple added the animation for the downloaded file swooshing down to the download folder with OSX Mountain Lion. Double fun.
After a recent discussion on @twitter with @limi and @philikon on the difference between the Firefox and Chrome Internet browsers, I started thinking about why I still find both browsers lacking in the download experience department.
For an excellent primer on how the different Internet browsers currently handle downloads I highly recommend reading @Limi’s blog post and come back to revisit this post.
I do not know about you, but I hate the Firefox Downloads window like the redheaded stepchild it is. The web-page-in-a-tab solution from Chrome (yeah, yeah, yeah – I know Opera did the tab thing first, but who uses that browser besides you?) doesn’t quite jive with me either.
Thus I decided to do this quick & dirty mockup of how the download experience in the browser could be improved.
Introducing the Browser Downloads Docking Menu
I would think a slide in/out dock menu for downloads would be a better solution. This way you’ll always know where your downloads are and it enables context (page and download file viewable simultaneously, guaranteed) and visual/ spatial cues (e.g. in an OSX version you should animate the download file flying into the downloads dock menu).
Visual / Spatial Cues
I think it’s important to visually show that the user’s intent to download has been registered, where the download can be expected to be found and what you can do next. If the dock menu is not out/showing already, it should slide out first, showing the user how and where.
Filtering & Recovery
Some sort of parameters to adjust list view of downloads should be added, but not visible to the normal user as default. Should be extremely easy to understand and use for normal people. Should change and filter view live/realtime. The big fat “Show all” button is there to secure that the user can feel confident that she’s seeing everything and that all filters are off/reset.
What do you think? Are you happy about the current download experience in your browser? How would you make it better?
UPDATE 2013: Problem (mostly) solved today. Multiple rounds of shortening still tend to garble the original url address.
In software development you’ll – unfortunately – sooner or later end up having to compromise between usability and functionality. These compromises are often a result of either financial, time or technological constraints. However, the wonderful thing with software is that you can always improve, add and modify after the fact.
Services like jaiku and twitter enables you to let the world know every novel, quaint or painfully inane activity that you are up to at any time, through almost every thinkable mode of communication, save semaphores and smoke signals. One mode being sending and receiving updates per SMS via your mobile phone. A standard SMS text message is limited to 160 characters. As twitter and Jaiku also supports the sending and receiving updates via SMS, they have implemented the limitation set by this lowest common denominator. For instance twitter even keeps 20 characters for itself and you get to play with a remaining 140 characters per update.
I’ll leave it to others to ponder the consequences on the language and communication – if any. I wanted to bring the attention to a usability issue brought about by this technological constraint, not start a discussion about the evolution or devolution of language and communication, although interesting in itself.
To be able to post links (URLs) to pages on the Internet in their updates on twitter and Jaiku, people are using additional services like urlTea and tinyurl to help reduce the numbers of characters to transmit the address, but leaving it functional. Those services take a potentially long address like ‘https://www.cia.gov/library/publications/the-world-factbook/ index.html’ and truncate it to ‘http://tinyurl.com/2b2kg9’, leaving more characters to write a personal message to go with the link with. However, any identity or clue as to where that address may lead has now been removed. (Not to mention the additional burden the use of those additional services places on the poor user. I’ll leave that discussion for later posts.)
I’ve illustrated how this looks when using the web interface of twitter below:
Notice that there are no clues in that address as to what to expect when you click on it. The clever twitterer might suggest that if you’ve been following Chris Pirillo for a little while you’d expect the link to be leading to one of his web casts on his site, but then again there is no information in that address to tell you at a glance what to expect. You can’t know if it’s linking to the story you already read two weeks ago, if it’s self promotion if it’s linking to a site you know and trust – it could even link to an address that would get you in trouble at work.
Enter ‘The Gulf of Evaluation’:
“Does the system provide a physical representation that can be directly perceived and that is directly interpretable in terms of the intention and expectations of the person?The Gulf of Evaluation reflects the amount of effort that the person must exert to interpret the physical state of the system and to determine how well the expectations and intentions have been met. The gulf is small when the system provides information its state in a form that is easy to get, is easy to interpret, and matches the way the person thinks about the system.” – Donald Norman in ‘The Design of Everyday Things‘, Doubleday 1990.
I’ll argue that the gulf of evaluation is light years wide in the case in question. I’d like to have some transparency please. Show me a proper address!
Of course it could be argued that some users of the mentioned services would actually support the extra layer of obscurity afforded by the use of nameless addresses – that it actually generates more traffic from people clicking blindly than it would if people could see the real address and source. I do not have a firm opinion about that, however.
There are of course ways to alleviate for this unfortunate loss of information, letting us know where we’re going before wasting our time or getting fired (if using Jaiku and/or twitter hasn’t already gotten you fired) by clicking on the wrong links anywhere but the SMS’. I’ll propose two modes of improvement. One involves internal changes to the services themselves, and the other external additions with no need for involvement from the Jaiku or twitter development team. They both have advantages and disadvantages.
I’ll start with the blatantly obvious one; Jaiku and twitter should look up the truncated addresses before they are rendered and parse them. That is to say a truncated address would be shown in full when using all web based interfaces. Why on earth should we be limited and constrained to the lowest common denominator on the web? We can have gazillions of characters! Heck, keep the limit to 140 characters displayed on the web , just like the current solution, but show those URLs in full in addition to those 140 characters. However this would require the time and attention from the official development teams that are probably already preoccupied with other challenges, fixes and policies.
The second and almost as obvious one would be to develop a plug in for e.g. Firefox that would identify addresses from services like tinyurl and urlTEA, look them up and show the complete address in the status bar below left and as a tool tip when hovering with the pointer over the link. I’ve illustrated how this may look below:
The two immediate advantages of this solution would be that it require no commitment from an internal development team and that it would work with any web page, not only with the content coming out from twitter or Jaiku.