Redesigned Breadcrumbs

We recently shipped some updates to our breadcrumbs navigation. In this post, I’d like to walk you through the changes and discuss some of the design thinking behind the improvements.

Redesigned Breadcrumbs

Determining What was Most Important

When updating a frequently used piece of the interface, it is important to keep existing users in mind. One of the advantages of every Onehub employee, being Onehub users ourselves, is that it keeps all of us in touch with our users’ experience – allowing us to think through changes from an empathetic place. Armed with this empathy and some additional user research, our first step was to outline the most common user scenarios: breadcrumb navigation. To do this, we worked backwards from the following question:

“As a user, what is the most important function of the breadcrumbs?”

The immediate answer was being able to see the name of the folder/file you are currently looking at. Whether you’re looking at a file as a Viewer or Administrator, being reminded of which file you’re actually working with is a no-brainer.

A close second was the ability to quickly return to the root folder. Two of the most common actions taken in Onehub are one, quickly creating folders and uploading files; and two, hopping in to a file to add a comment/task, then hopping back up to the Workspace level to do something completely different.

Lastly, there are certainly times when you need to move through and collaborate on a handful of files at a time. In this scenario, being able to quickly jump back to the immediate parent folder and in to another file is important.

With these scenarios in mind, we set the following design goals for the redesign:

  1. Prioritize the current folder/file name.
  2. Always provide a link back to the root folder.
  3. Provide links to parent folders, exposing the immediate parent whenever possible.

Prioritizing the Current Folder/File Name

Now you always see as much of the name as we can possibly show you. If a folder/file name is too long to fit within the available space, we truncate it.

Breadcrumbs Truncation

Maintaining Access to the Root Folder

With this redesign the root folder continues to always be present, allowing you to quickly jump back to the top-level of your folder tree at any time.

Breadcrumbs Root

The “…” Crumb

The final piece of the redesign is the new “more” crumb, signified by an ellipsis (…). This crumb fulfills the final design requirement dynamically. Depending on the available space around it, the more crumb may contain every parent folder or be non-existent. As space allows, we will pop folders out of the more crumb (starting with the closest parent) and display them inline with the current folder/file name.

Breadcrumbs More

I sincerely hope you find the redesigned breadcrumbs to be a wonderful enhancement. You can see them in action by visiting any of your Workspaces. As always, if you have any feedback, we’d love to hear it — tweet @onehub or send an email to

Create and Edit Files from Onehub with Google Drive

We are happy to announce the release of our new Google Drive integration. Starting today, you can now create and edit files directly within Onehub. The next time you sign in, you’ll see the following two new buttons in your Workspaces…


You’ll find the Create button on the toolbar of the Files page inside your Workspaces. This button displays a modal that contains a button for each of the Google Drive file types along with the existing Create Folder button. The very first time you attempt to create a file, you will be asked to connect your Onehub and Google accounts. After that, you’ll be able to seamlessly create documents, spreadsheets, presentations, or drawings with one click. Created files will be added to your Workspace in the corresponding file formats – DOCX, XLSX, PPTX, PNG.


In addition to creating files in Onehub, you can now edit files as well. The Edit button can be found on the preview page of any supported file type, including files that you previously uploaded (not created via Google Drive). If the file you’re editing is not a format that Google Drive can create, your updates will be saved back to Onehub in the corresponding format. For example, if you edit Filename.doc, that file will become Filename.docx. Rest assured, your entire version history will be kept intact, only the file extension will be modified. In addition, we fully support Google Drive’s collaborative editing feature. This allows multiple Workspace users to edit the exact same document collaboratively, in real-time. When the last editor saves, all of the group’s changes will be saved back to Onehub.

For more information on this feature including browser requirements and file support, please read our Google Drive support articles. As always, if you have any feedback, we’d love to hear it – post a comment below or email

Google Drive Integration Beta

Creating and editing documents is something we have always envisioned for Onehub. In fact, we actually attempted to add this capability to the product nearly 2 years ago; cancelling the feature at the time because we weren’t satisfied with the results.

So, we were beyond excited when Google released the Drive API – providing a fast and reliable way for us to do something we’ve always wanted to do.


We’ve been testing things out internally for a couple of weeks and have already stumbled across some really interesting use cases. For example, want to collaborate with someone on a single document in one of your Workspaces? Simply generate a secure link to that file, set the role to Creator, and send the link to your colleague; they’ll be taken directly to the preview where they can make edits to your file.

We’re looking forward to seeing all of the other interesting scenarios that our customers discover. If you’re interested in becoming a Onehub Beta tester, please send an email to and let us know.

Designing a Drag & Drop Experience for the Web

The Art of Drag & Drop Uploading – Part 1

Last week, we launched our new HTML5 drag & drop uploader. This week and next, Leigh and I are writing about how we did it. A few days ago, Leigh broke the ice with a post on building our drag and drop uploader. In this post, I’m going to discuss the creative process behind the user experience.

Approaching shiny, new features

When designing new features (especially those involving new technology), I design them for the person who has never used the service before. I do this for two reasons. First, it frees me from any expectations I might be aware of from existing customers. This allows me to focus on how the feature should be, rather than how it could be. Second, when I design for new users first, I’m less likely to forget about them during my creative process. Once I’ve isolated what I think is the best idea for new users, I go back and connect the dots for existing customers.

I imagined a new drag & drop files widget and tackled the most obvious and important question that came to mind.

Where do I drop my files?

The drop target not only dictates how someone initiates a drag & drop upload, it also influences the rest of the user experience. I sketched several ideas and ended up with four options for consideration.

  • Drop the files on to the menu bar
  • Drop the files on to a new, unique location
  • Drop files anywhere on the file list and/or in to a folder
  • Drop files anywhere on the file list

Option B. The first to go. The most intuitive place to create a unique target for adding files would be below the other files (in a footer); however, that would require a ton of scrolling if you had lots of files. Moving the target further up solved the scrolling issue, but was less intuitive and wasted screen real estate when not in use.

Option A. Next off the list. It made contextual sense because it was close to the current Upload button, but that was about it. I anticipated dragging files from the bottom and side of the browser window. Hitting the target on this option could require a lot of mouse movement. Additionally, the drop target felt fairly small.

Option C. The early favorite. A few team members really liked the idea that you could drop a file directly in to a subfolder. This approach was more complicated though because it actually consisted of multiple drop targets. After sitting with this option for a bit, dragging in to a subfolder didn’t seem to be very useful either. Anything more than a single nested folder still required traditional navigation. The real killer for me though was that the targets were even smaller than in Option A. It would be easy to accidentally drop files in to a subfolder and/or into the wrong folder. The cool factor wasn’t worth the increased risk of error.

Option D. The winner. It was intuitive and very accident-proof. It also had the largest drop target which I felt would be the most engaging and easiest to use. Other than not being able to drop files in to folders, we couldn’t find anything that we didn’t like about this approach at first glance. It was time to prototype.

Early prototype gets the bugs

At Onehub, we prototype as early as possible. Playing around with prototypes, no matter how basic, gets you thinking like an actual user. Also, this is typically where the largest number of changes occur in my designs. The earlier I reach the prototype phase, the quicker I become confident in the feature.

While using the prototype, I noticed that we weren’t conveying one very important detail about the uploader – you shouldn’t touch the files widget during an upload. With Option D, the menu bar and sort headers were still available during an upload. The widget did not appear to be fully ‘locked’. You could easily click any button in the menu, including the ‘Upload’ button. Ironic.

The solution was easy – expand the drop target to surround the entire files widget. The entire widget became one huge drop target and the experience of dropping files felt right.

Keeping feedback simple, Stupid

I felt strongly that the most important thing to get right was going to be feedback. One thing I learned from our original uploader was that the interface quickly became cluttered when displaying data & progress for individual files. So, I wanted to see if I could keep feedback comprehensive without displaying too much information.

It is easy to add things; harder to take them away. So, before showing the prototype to the rest of the team for the first time, I removed anything I didn’t absolutely need to know about a given upload. I made a list of all the data at my disposal and started pruning.

I ditched overall size for two reasons. One, your brain automatically figures out the ‘size’ of an upload by combining the number of files with how fast the progress bar is moving. Two, most users don’t know/care how much bigger 3.6 MB is than 3,600 KB.

Next, I axed all information pertaining to individual files for the reasons stated above, with the exception of filename. This was necessary for informative error handling. If there was an issue with one or more files, Leigh and I had decided to continue, successfully uploading everything else. Given that scenario, it would be nice to know which files didn’t get uploaded so you could try them again.

As it turns out, uploading files via drag & drop happens concurrently. At any given moment, three or more files are in transit. To provide accurate feedback on individual files we would either need to disable concurrent uploads (slow down the uploader) or show progress bars for all of the files in transit (clutter the interface). If my intuition was sound, we wouldn’t need to do either of these. Bonus.

In the end, I settled on state, number of files and overall progress. Minimal and meaningful. If anyone on the team felt something was missing, I was confident it would eventually work its way back in.

The rest was easy

Once satisfied with the drop target and the feedback requirements, the rest of the interface fell in to place. I opted for an overlay, which provided a consistent minimum width & height, and designed unique panes for each of the five interaction states – ready, drop, uploading, success & error.

A better experience is always the best new feature

I didn’t want there to be any question as to why you should use our new uploader over existing options and I think we succeeded. The drag & drop uploader is faster and more reliable, doesn’t require a single mouse click or browser plugin, looks beautiful and is fun to use.

If you’re using Chrome, Safari or Firefox please give the new uploader a try and let us know what you think. If not, it is definitely time for an upgrade. The future is coming!

In my next post, I’ll document how we built our progress bar without a single image using CSS3.

Why We Chose for Our CSS Framework

A few months back, we redesigned to coincide with the public launch of the Onehub service. There were a ton of goals to achieve with the new design from education, sales and marketing perspectives. I also had my own hidden agenda which resulted in us implementing a CSS framework.

Leading up to the public launch, the breadth and depth of the site had started growing at a pretty good clip. The design and messaging of were already incredibly important to me and their importance was only going to increase post-launch. That being said, the amount of time it was going to take to maintain the site, was just as important to me. After all, if given the choice, I would much rather spend my time on the Onehub service – designing new features and improving existing ones for our customers.

I knew that maintaining in it’s current state was going to start pulling me away from the product. Something was going to have to give. Or was it?

What I wanted to accomplish

I needed to make much easier to maintain but wanted to do it without sacrificing style and flexibility. I was not specifically looking for a CSS framework in the beginning. In fact, I understood at face value why you might actually want to avoid them. However, after realizing that it wouldn’t make sense to leverage the existing Onehub CSS framework, I drafted a simple list of requirements (based on the typical cons of CSS frameworks) and went on the hunt.

Our requirements

  • Should be easy to learn
  • Should be easy to maintain
  • Should have a small footprint
  • Should be as semantic as possible

The frameworks that were considered

There are a bunch. I tried most of them and immediately narrowed the list down to, Boilerplate, Tripoli, Blueprint and YUI. From here, the only one I immediately disliked was YUI – thanks to crazy naming conventions and some overkill. Of the remaining 4, it mostly came down to personal preference. Blueprint and Tripoli did more than what I was looking for. Boilerplate did less. emerged as the framework that I felt had the potential to be most useful most often. Here is why it worked particularly well for us.

Easy to learn

Quite frankly, the learning curve for is almost non-existent. If you already understand the concept of grids and the necessity for having access to the first and last items in a given collection – understanding the syntax is a piece of cake.

You’ve got two grids to choose from. One that allows for 12 columns and one for 16. Want a 3 column layout? Create a 12 column container and fill it with 3 elements, each 4 columns wide:

<div class="container_12">
    <div id="blog" class="grid_4"></div>
    <div id="photos" class=grid_4"></div>
    <div id="links" class="grid_4"></div>

No really. It’s that easy.

Easy to maintain

Because is so easy to learn, it is naturally easier to maintain. Getting multiple designers on the same page can be as simple as showing them the code snippet above and having them go to town. If you buy in to the conventions, you can immediately begin taking advantage of it in your work flow.

Furthermore, is browser compliant all the way down to IE6. Now, you can certainly mess that up if you try, but it is absolutely killer to be able to rely on a bulletproof grid out of the gates.

Has a small footprint

I didn’t use the text.css file from as everything it covered was going to be redone anyway. That left us with Eric Meyer’s CSS Reset and the main 960.css file which is a mere (3.6 KB) when compressed. It is brilliantly small. See for yourself:

The only tweaks that I made, were in implementing some snazzy, automatic float clearing to the containers and .alpha classes. Everything else is custom CSS on top of for the design.

As semantic as possible

Let’s be honest. In order to make a CSS framework useful, you’re going to have to make some sacrifices when it comes to semantics and naming conventions. I think Nathan Smith, the guy behind, made some incredibly smart ones.

Most of us use something like container or wrapper for classing our containing elements. If you want a container that allows for 16 columns using, you’d use:

<div class="container_16"></div>

Are you mixing some structure in to your class names with the 16? Sure. Is it worth it? I’ll say. It doesn’t make the class any less descriptive. In fact, depending on how you see it, one could argue that it adds clarity. If another designer were to see this HTML they now know it is a container element and contains 16 columns.

Remember, the underlying purpose of being semantic is to avoid having to revisit the structure of your site as often as you revisit the style of your site. Adding the 16 in this particular case does not make it any more or less likely that you’ll need to revisit that code.

Point being, choose your battles wisely. In the time you could argue the relevance of naming conventions like these – I just built a 16-column layout.

For the interior elements, Nathan also chose to avoid the common practice of repeatedly typing a class name like column as well as a number designator. Rather, he combined them in to one. Furthermore, using grid in the name further reinforces the idea of making multiple designers aware of the grid when they go in to edit the HTML.

I’m also a fan of the alpha/omega classes in place of a traditional first/last. Though it doesn’t seem like a big deal at first, I think it is a clever way of conveying the meaning of first/last while adding back a tiny bit of flexibility. It is also a life saver for the handful of times when you decide to break up your grid and nest grid elements inside each other. gets you on a grid and then gets out of your way

Converting all of our mockups for the Onehub redesign to working layouts took a single day. Integrating our existing content took another day. After that, it was all polish.

After launch, rolling on has allowed us to continue to design and maintain faster, with fewer mistakes and without having to worry about IE for the majority of our layout issues. This allows us to spend the majority of our time on the creative aspects and the messaging of

Most importantly, it gives me more time to spend on the product. This makes me and our customers happier and I simply can’t argue with that.

Simple Logo Swapping

I’ll be the first to admit it. As a Web Professional, it is nearly impossible to account for every user scenario, every browser, every configuration. And yet, if you’re like me, you’re constantly on the look out for ways to improve and simplify your code without sacrificing flexibility or accessibility.

There is a simple but effective logo swapping technique that I utilize on that does both of these things. Before we jump in to the code, let’s examine a few situations that dictate the necessity for logo swapping.

For starters, not everyone accesses your site via modern browsers.

Some users visit sites on mobile phones, PDAs, accessibility devices and the like. Their numbers might not look like much on your monthly stats right now, but you can expect those numbers (particularly mobile phones) to increase dramatically in the next 2-3 years.

Were you thinking of using that awesome, transparent .PNG version of your logo? Well then you can go ahead and add IE6 and all other legacy browsers to that list as well.

These are all potential entry points to your site that should be taken in to consideration.

Second, some people still insist on printing web pages.

Site logos are one the most important visual aspects of any brand. Because of this, they are also a common source of debate among Web Professionals. One of those debates surrounds printed versions of sites.

Some designers believe that a site logo is purely a design element and should not be displayed with the content when printed. Others argue that the logo is a contextual element and therefore needs to be included.

It’s all semantics. Literally. While I can certainly appreciate the validity of both of these opinions in certain contexts, I’ll argue that most clients don’t care. If someone is printing out their site, most site owners want their logo to be at the top of that page.

Assuming you have the same request, you’ll need to place the logo inline with your HTML because the majority of users aren’t sending background images through to their printer.

Last but not least, some times it just looks better.

Sometimes a design calls for placing a light logo on a dark background – because it looks awesome. The reversed Onehub logo at the top of this page is a perfect example. If we served only the reversed logo, users browsing with handheld devices would see this:


Kind of hard to see that light text on a white background, eh? A solid logo swapping technique is especially useful in these cases.

Alright, let’s walk through the technique.

A tale of two images.

We start with two slightly different logos – the standard positive Onehub logo (black text) and the reversed Onehub logo (white text).

Simple Logo Swapping

Now, let’s take a look at the HTML:

<div id="logo">
    <h1><a href="/"><img src="/images/logo_onehub_pos205x54.png" alt="Onehub" width="205" height="54" /></a></h1>

Nothing fancy. In fact, without any corresponding CSS it is nothing more than a standard image implementation, right? Look closer, you’ll notice that we’re actually calling the positive version of the logo – the version that we want to serve to everything but modern browsers. So how does the reverse logo end up there?

It’s all in the CSS:

#header #logo a {
    display: block;
    background: transparent url("/images/logo_onehub_rev205x54.png") no-repeat;
    width: 205px;
    height: 54px;
    margin: 36px 0;

#header #logo img {
    display: block;
    width: 0;

Focus on the second declaration first. We set the width of the inline image to 0. This hides it from CSS-enabled devices while retaining the alt text for screen readers and users browsing with images off. The display property is only necessary if you’re using a strict doctype for your markup.

Going back to the first declaration. We match the width and height of the containing element to that of the inline image and set the display property to block so that it fills the space we provided. Ignore the margin property as that is strictly for this design.

Lastly, we pull the reversed logo in as the background image of the containing element, essentially swapping it in place for the (now hidden) inline image.

That’s it!

So there you have it. By placing the image inline, we have made the image available to printers and the alt text available to screen readers. Then, with very minimal HTML and CSS, we were able to use whichever logo best fit our design while ensuring that an appropriate alternate version was also served in other situations.