© ACM

Abstract

FIGURE 1: Starting on the left, the parts of a drag icon are the state indicator, operation indicator, source indicator which together build the drag icon.

There are three parts to a drag icon (see Figure 1). The state indicator tells the user if the drag is valid or invalid. The operation indicator tells the user if the drag operation is a move, copy, or link. The source indicator tells the user what is being dragged. The source indicator is usually the icon the user has selected.

Files, buffers, and text all had special meanings in DND. Text refers to text selections that the user can select and drag to do accelerated cut, copy and paste. Files are literally files that exist in the file system; the user sees these as glyphs or icons in a file manager. Buffers are bits that do not exist independently in the file system but, when dragged, should still be represented as glyphs or icons to the user. Displaying a calendar appointment attached to a e- mail message is one example of a buffer that a user sees. Files and buffers are effectively the same and will be referred to as files, meaning the icons the user sees on the computer screen.

Major Design Issues

Constraints

The Common Desktop Environment project was a highly constrained project from the viewpoint of resources, scheduling, and coordination. The amount and kind of changes we could make to the Motif toolkit were considered carefully before being approved. This should sound familiar to anyone shipping products. The two biggest impacts on the design process were the large amount of time spent coordinating across several companies and the schedule changes.

The entire team had one constraint in common - we were all starting from scratch with regard to Motif knowledge. The first task I had was to familiarize myself with Motif 1.2 DND and determine what changes we could make to improve usability and to integrate the functionality of the new API.

Motif 1.2 DND has a set of bitmaps that it uses to build the text drag icons. There is a bitmap for each state and each operation indicator. We had the option of changing the bitmap designs but not the method of building the drag icons or the size of the bitmaps. The state and operation bitmaps are in black and white; there is no support for color at this time.

Design Process

Since this was a small team we did much of our work in the team leader's office on the white board. Most interactions took place between the two software engineers and the main human interface engineer. We would sketch out problems in the center of the board, API calls on the edges, and to- do lists on the sides. Everything was color coded in purple and green marker colors (the official team colors).

I took copious drawn and written notes. Depending on what was discussed I would re-write the notes as an email and send it around, make copies of the notes for others, or just keep them for my own records.

Since the code was written as a base library, and base libraries have to be done first so other applications can depend on them, the schedule was very tight. For two to three months we met practically everyday for an hour or more.

Initially designs were done on paper and on the white board. A fair amount of time was spent figuring out why Motif did what it did. Understanding the behavior was critical to understanding what could be changed.

I used the CDE Icon Editor to generate the bitmap files. The software engineers developed a test program that could be used to swap in the drag icons as they were designed and would let us try out different parameters for building the drag icons. We used this program to visually evaluate the drag icons on screen and to try out dragging text and icons. This enabled us to do fairly rapid turnaround on drag icon designs.

A word on the metaphor...

Drag icons are a mixed bag of metaphors. The arrow is usually there to represent the mouse on the screen. The operation indicator tells the user if they are making a move or a copy or a link. This is usually done with very abstract icons and few pixels. The source indicator is perhaps the most clear because, if done right, it is the actual icon the user selected. The basic idea is "put arrow on what you want to move and move it".

Moving right along...

One of the first issues we dealt with was the move cursor. Motif 1.2 uses a small document glyph attached to an arrow for the drag icon displayed in a move operation. Most GUIs use a plain arrow pointer for move. Anecdotal evidence from users of Motif indicated most folks thought the move drag icon to be confusing - they were not sure what the little document attached to the arrow meant especially as it is used in the context of moving text, not moving a document.

FIGURE 3: These are the Motif 1.2 text drag icons as per the OSF Motif 1.2 Style Guide.

I proposed to the team that we leave the bitmap for the move operation indicator empty. This would result in a move drag icon that only displayed a plain arrow similar to other GUIs. The response from the team was positive: they had not thought about resolving the issue this way but once they explored this proposal they realized it worked well without breaking any Motif code.

We went ahead and tried this solution and an alternate solution in which I put the arrow head in the valid state indicator bitmap and the tail of the arrow in the move operation bitmap.

The reason we tried this was that we had theorized that the drag icon was built by drawing the state indicator on top of the operation indicator on top of the source indicator. This made logical sense to us. If this were true then separating the two pieces into different bitmaps should have resulted in a better looking drag icon.

FIGURE 4: The top row shows the order in which we thought the drag icons were built. The bottom row shows the actual order in which they are built.

In the process of testing with the sample program, we discovered that Motif 1.2 builds the drag icon in a different order than we had originally theorized. The operation indicator is drawn on top of the state indicator on top of the source indicator. This ordering is hard-coded and cannot be changed (however illogical it appeared to us). Given that the drag icon was built in this order, it meant that the operation indicator always overwrote what was under it. So, the proposal in which the arrow and its tail were separate bitmaps was not necessary. We put the arrow with its tail into the valid state indicator bitmap and left the move operation bitmap empty. Though the state indicator is always overwritten with the operation indicator, in the move case it is an empty bitmap so the arrow and tail appear as they should.

The main point is that I had to understand the design of the drag icons from the perspective of a software engineer as well as a human interface engineer. It is less likely that the final solution would have come out as well had I only looked at this problem as a visual design issue. And because I had taken the time to understand the engineering issues that affected the drag icon design, the team was more receptive to my proposals.

What is that you have there?

The chart shows some of the various drag icons in our desktop. Different drag icons result depending on what the user has selected. There were two basic drag icon types, one for text and one for files. In this section we discuss the design of the file drag icons.

The source indicator bitmap for files is handed off to the DND Convenience API by the application. This is optional: if the application does not supply a source indicator then the DND Convenience API uses the default source indicator shown as the plain document icon.

FIGURE 5:This chart shows examples of the final drag icons. Since we cannot do screen shots of the actual drag icons, this artwork is approximate.

The file drag icons presented an interesting design difficulty in that the design had to work regardless of what the source indicator bitmap design or size was.

Optimally, the source indicator is the actual icon the user selected. In the case of the CDE File Manager, the file manager icons were used directly as source indicators. Icons could be 16X16 or 32X32 pixels. An icon is created within a "bounding box". The file manager icons in our desktop do not always use the entire bounding box for the actual icon design. Typically the rest of the bounding box is filled up with a transparent color.

The DND Convenience API could have figured out the size of the icon being passed in, but it was too expensive in terms of performance to figure out what actual bits were being used in the bitmap. Knowing the actual bits used would have enabled us to crop the source bitmap used in the drag icon and would have facilitated better placement of the state and operation indicators.

Given the trade-off of exact placement of the state and operation indicators versus immediate feedback when the user starts dragging, immediate feedback is more critical. If users can't tell they are dragging something, they will never get to the point of dropping it. So making a change that might seriously degrade system response time was not an option.

All of this meant that the file drag icons had to be designed so that they worked with 16X16 and 32X32 sized bitmaps regardless of where the actual bits were or what size icon was passed in.

We altered the 32X32 icons used in the file manager so that icons would be left bottom justified in their bounding boxes. The 16X16 icons typically use the full bounding box. This gave us a starting point for determining placement. We began user testing with the arrow placed at the top left corner of the source indicator, regardless of size.

Drag 20 pixels to the left, then...

The act of DND cannot be tested on paper. The very nature of dragging and dropping requires that it be tested interactively. If DND is working correctly, users never notice the drag icons or have any problems with them. To actually point out the drag icons to the user and ask their opinion would be akin to pointing out the engine of a car and asking a user how they liked the design. Unless the user is techno-literate, they don't care about the engine, they just want the car to start in the morning.

I did run an early paper study on the operation indicator bitmap designs for copy and link. Ten users were asked what the various designs meant and which one they would use for copy. We got clear feedback on which icon meant copy and which meant link. This feedback determined the icon design we chose.

The drag icons were all tested interactively. We compared the Motif 1.2 text drag icons and the file drag icons from early versions of the CDE File Manager to the new designs of the text and file drag icons in two rounds of user testing.

We had a very limited amount of time to do user testing of the drag icons. At one point we didn't think we would be able to run any testing as no applications were using the library yet. Thankfully, the engineering team produced a 'hack' to the Motif library that allowed us to swap back and forth between the Motif drag icons and the new drag icons when we restarted the system. The hack worked with only two applications: early versions of the text editor and the file manager.

We came up with a series of tasks: selecting text and dropping it in a new location, selecting file icons and moving the icons inside a folder window, dragging them to a printer. We had participants try out both types of layout (As Placed, Use Grid) in the file manager using both sizes of icons (16X16, 32X32).

There were 4 participants in the first round and 6 participants in the second round. In each test participants were asked to do the tasks in one environment and then the other. The test was counter-balanced.

The results of the first round of testing showed that users had trouble positioning with the file icons. We had used file drag icons that were built similar to the text drag icons where the arrow was in the top left corner. When the user dropped an icon however it did not place exactly where the user dropped it. One participant stated, with regard to placing icons versus text positioning, "visually I prefer the arrow in the middle better, but for positioning I prefer it to be in the outer edge."

FIGURE 6:The top row shows the drag icons used in Round 1 of user testing. The bottom row shows the redesigned drag icons used in Round 2.

When the user drags a piece of selected text to a new place in a document, the user has to position the text very exactly because the text is effectively pasted where it is dropped. There is no highlighting or other visual indicator of the drop site because only the user knows where they are going to drop the text. Conversely, when the user drags a document icon typically the icon is either being re-positioned in a window or getting dropped on a large drop site. The amount of precision needed to be successful is what makes the two tasks different.

To aid users in these two tasks, we ended up designing two different sets of drag icons. In the text drag icon the arrow is placed in the top left corner of the text source indicator. In the file drag icon, we placed the arrow pointer more in the center of the source indicator. Placing the arrows in the two drag icons in these two positions allowed users to more accurately predict where something would get dropped or placed when they released the mouse button.

In the second round of user testing participants preferred the new drag icons and their error rates were better using the new drag icons. (We did not put a large emphasis on the error rates for either study as users were not given much training and it was impossible to differentiate whether errors were due to a new desktop GUI or specifically due to DND.)

Drop Point versus Insertion Point

We realized early on that we had two very different tasks that had to be accommodated by the drag icons. We thought we had designed the two varieties of drag icons to match the tasks the user would be doing across the desktop. But then, in the course of implementing functionality in the CDE Mailer and Text Editor applications, we realized we had a problem.

This unfortunately fell very late in the development schedule. An unfortunate circumstance of working on an API is that this type of code must be stable and frozen very early on in the project so that other applications can then write code using it. One implication of this is that the DND API was frozen before any application had fully integrated it. While the plan is to cover all possible uses of an API, reality does not always match the plan no matter how good your team is.

As the CDE Mailer team was implementing the ability to drag and drop files/buffers, we realized that we needed to support dropping files onto the text editor window with the end result that the file was inserted into the document open in the text editor. The question was where should it be inserted: at the drop point or the insertion point?

We had designed the drop behavior for the text drag icon such that text was always inserted at the drop point, not at the insertion point. This matched users expectations for a task that mirrored cut, copy and paste. At first it seemed obvious that we should insert file at the drop point. The problem was that we had designed the text drag icons to work for inserting at the drop point, but the file drag icons were not designed to work for inserting at the drop point.

Redesigning the file drag icons was not an option as the DND library was frozen. I had to have a recommendation within two days. We did not have time or resources for running a user test. So, I did the next best thing I could think of: I went back to the Open Windows Mail Tool application which supported the same functionality and reviewed the human interface design and the user testing reports. I went around and asked current users what they thought of the functionality. I brought the issue up in the joint company human interface conference call and reviewed my ideas and findings.

What I found was that dragging and dropping a file or buffer onto a mailer compose window or onto a text editor window was really an accelerator for File: Include operation. The File: Include menu item brings up a File Selection Box which allows the user to choose a file to include in the current document. File: Include always inserts the chosen file at the insertion point.

This behavior had never been documented as a problem: it appeared to match users expectations. From informal questioning, most Open Windows users were very comfortable with this behavior and with the difference between text drags and file drags. Most responded by saying things like, "it does what it's supposed to do."

Given the information I gathered, I proposed that we implement file drags such that they always insert at the insertion point, not the drop point. So far, this appears to be the right decision.

If I had time to do it right?

References