top of page

The Painful Question of Pane Management

The following is the second mini case study in a series I’m writing about a single project. You can read the first case study in the series here.

 

Why Panes?

 

Kyle is a typical user of the dashboard I’m designing for my client. His goal is to write a report. He’s been trained on a process that consists of the following phases:

 

Phase 1: Gather useful sources

 

Phase 2: Extract pertinent data from each source

 

Phase 3: Compile data into a report

 

During phase 2, Kyle scans and sometimes reads each of the webpages he’s shortlisted in phase 1. If he finds something he wants to use in his report, like a snippet of text or an image, he copies it and pastes it into a Word document, which we call “the scrapbook”. He also copies and pastes the link to the webpage into the scrapbook, so he can keep track of his sources. To do this, Kyle needs to constantly switch between his Chrome browser and Word. 

 

It looks something like this:

TL;DR
The ask was to figure out a way for users to be in two places at the same time. I proposed an intuitive, if perhaps unusual, solution: drag-and-drop navigation.

Scrapbooking

The end state of the scrapbook is a long Word document interspersed with pasted text, links, images, and some hurried notes. When it’s time to write the report, Kyle closes his browser, opens a new Word document side-by-side with his scrapbook, and starts typing. 

 

My job was to improve Kyle’s process up until he starts typing in the new document. But before I honed in on this task, I had to address a pressing issue.

Pane Management

​

In most digital products, users can be at exactly one place at a time.

 

Therefore, usually the relationship between the user’s current location and the highlighted item in the menu is simple: it’s a one-to-one function.

 

It might look like this:

normal.png

When Kyle is scrapbooking, he has a Chrome window and a Word window open side-by-side. Both of these windows were to get rolled into the dashboard I was building. Naturally, my client wanted users like Kyle to be in at least two places at the same time.

 

This desire reflected several scenarios within Kyle’s workflow, but was most critical for phase 2. Kyle should be able to see and nearly-simultaneously interact with:  

​

  1. The place from which he copies content (e.g. a webpage)

  2. The place into which he pastes content (the scrapbook).

 

This meant the dashboard had to be a multi-paned application. There are precedents for this kind of application -  Microsoft Outlook is a classic one - but in almost all of the examples that I could find, the content of each pane is basically always the same. 

Here’s what I mean: A user might set up her Outlook such that the leftmost pane contains the list of mailboxes, the middle pane contains the list of messages in the selected mailbox, and the rightmost pane contains the selected email thread. See below:

outlook.png

The user is unlikely to want to change this configuration often.

 

Therefore pane management can be handled in the settings, or maybe in some obscure manner that the user would have to search online to figure out - not a big deal for a function that is rarely needed.

But what my client wanted looks like this:

Kyle would be in two places at the same time, a fact that should be reflected in the navigational menu, and he should be able to fluidly determine which two places he wants to be in.

 

What happens when Kyle clicks on “Page 3” in the menu? Where does page 3 open, and which currently open page does it replace?

Multi pane.png

Option 1: Pane behavior is predetermined 

​

When Kyle clicks on a new item, the new page would always appear in the right pane, for example. Maybe this algorithm could be customized in the settings so each user could determine their preference. It would look something like this:

This approach might not be flexible enough, because Kyle’s preference about which pane to keep and which to replace might change depending on the situation. In the example above, if Kyle wanted to open Page 3 and keep Page 4 open, he'd have to switch the locations of Page 2 and Page 4 before clicking on Page 3. If he had to do that more than once a day, it would get annoying.

Option 2: Break the process into 2 steps with a popover

​

When Kyle clicks on a new menu item, a popover menu would let him select one of the two panes. It would look kind of like this:

I was wary of this approach because it places an additional cognitive load on Kyle.

 

To open a page in the intended pane, he would have to successfully map the representations of the panes in the popover menu to the panes themselves, then decide which one to get rid of. Although in principle this doesn’t sound like a complicated mapping, there are some real life examples of stuff like this going wrong (the average stove top comes to mind). 

 

And even if the mapping itself is not a cognitive hurdle, Kyle’s decision tree becomes convoluted: 

DT panes.png

Note that in the last step of this tree, the answer “yes” leads to a decision that starts with “don’t”. That’s confusing.

Option 3: Drag-and-Drop

​

When Kyle clicks on a new menu item, the item would become draggable. Kyle can then drag it over to the desired pane, drop it, and voila:

Menus rarely behave this way (although I've seen some examples of drag-and-drop used to reorder items within a menu-like pane), so this approach would be unfamiliar to users. Additionally, dragging something a long distance might feel awkward and annoying. 

 

At the same time, drag-and-drop in and of itself is a familiar paradigm.

Can We Make This Work?

 

As a designer I have tools to help users with this new and unexpected interaction mode:

​

Affordance

Once clicked, I made the component seem to elevate slightly from the page by moving it up and to the right, as well as giving it a shadow and rounded edges.

​

I used a blue border to indicate suitable drop targets.

 

To prevent hard-to-recover mistakes, if the user drops the component in an ambiguous spot, for example, where it significantly overlaps two different targets, then neither target would be outlined in blue, and the action should fail.

 

Label

A tooltip shaped like a box with an arrow pointing towards the item, with the instruction “DRAG”, helps the user figure out the appropriate interaction.

 

This tooltip could appear only for the first few times a user is interacting with the menu in this way, because we want to guide the beginner user without breaking the flow of the expert user.

 

Accepting that the cost would be a dashboard with a non-zero learning slope, but that this would be the case no matter what I did, I recommended option 3 to my client. User testing will determine whether this was the right call.

What's Next?

 

With the pain of pane management out of the way for now, I focused on the construction of the scrapbook. Read my next case study here.

bottom of page