The GNOME Development Site

GNOME Usability Study Report :: File Management Tasks

July 2001
table of contents | << previous | next >>

File Management Tasks

Participants were given the name of a file, proposal.txt and were asked to find and open it, but were not told how or where to find the file. They were not told that they had a file manager or that this file manager was called Nautilus. After opening the text file, they were asked to view the web page referenced in the text file, edit the text file and save it with a new name. Participants tried different approaches to find the file, including clicking on the Nautilus 'home' icon and looking for a Find option in the main menu. Participants overwhelmingly wanted to use a search to find the file rather find it through exploration.

Participants were unsure of how or where to begin looking for a specific file on the new system. We heard the following comments:

"I'm used to using a find menu or find key." (P2)
"It was tricky navigating, I wasn't sure where to start." (P4)
"It took me a while to look for words that I'm used to that would guide me to areas to do work." (P8)
"Hitting on the right choices was difficult, [my] expectations were not met when applying experiences with other operating systems." (P2)

Users did not immediately click on Pat's Home icon (Nautilus) to search for a file in their home directory.

Nautilus Home icon

The house icon seemed to make users think of their location in relation to the web as opposed to their own files or data. Perhaps people are more accustomed to a literal hardware icon used to represent their home directory. For example, the Macintosh has an image of a hard drive and Windows has an image of a computer.

We heard the following responses when participants were asked what they thought Pat's Home was:

"I don't know, a web browser? My favorite place on the web?" (P2)
"It goes to a homepage?" (P1)
"A hard drive? A folder for a hard drive?" (P3)

One user who opened Nautilus did not think she could search for files there. She closed the window and went instead to the Foot menu.

GNOME Main Menu:

Relevant Usability Principle: Match between system and real world.
Roughly half of the participants tried first to use a Find menu. In fact, 5 out of 12 participants went straight to the Foot [GNOME Main] Menu first to look for a Find menu. One participant kept looking in Foot > Utilities for a Find menu. None of these people discovered the find tool that does exist a couple levels down: GNOME Main Menu > Programs > Utilities > GNOME Search Tool.

A frustrated user commented,

"How do you find a Find [tool]?!" (P9)

Design Recommendation: We recommend moving the Programs > Utilities > GNOME Search Tool menu item to the top level of the GNOME Main Menu, as illustrated in the following screen mock-up:

GNOME Search Tool added to Main Menu

Most users ended up in Nautilus, although some needed hints to get them there. Users first reactions to Nautilus included many comments that it was not what they expected:

"I expected a home page or company page." (P1)
"This is not what I expected. I expected more text, fewer icons." (P6)
"I didn't expect this...I didn't know what to expect." (P9)
"I expected a list instead of a bunch of icons." (P10)

As users explored Nautilus further, they discovered that it was a browser:

"This whole interface, Nautilus, looks like a browser. Pretty cool." (P9)
"This is a hard drive browser. It allows me to go to the net." (P3)
"Its a browser-type thing." (P5)
"It has a desktop file system feel and a web feel, from the icons and the throbber." (P4)
"This is apparently a browser." (P11)

Users commented that they liked the integrated functionality of a combined file manager and web browser:

"I liked how everything was in the browser. Its very integrated, [it takes me] from the desktop to the web" (P5)
"I like it, I don't have to open so many windows." (P3)
"Its pretty cool. Very convenient." (P9)
"The integration is cool." (P10)

Once in Nautilus, most users successfully searched for the text file with the Nautilus Find tool. However they ran into problems with confusing terminology and misleading feedback.

Nautilus Find Tool Menu Terminology:

Relevant Usability Principle: Match between system and real world.
Users who explored the Find tool menus were confused by the menu items 'matches glob' and 'matches regexp' in the second pulldown menu.

Nautilus Find pulldown with confusing terminology

Design Recommendation: We recommend spelling out the terms 'glob' and 'regexp'. For example, instead of 'regexp', we suggest 'regular expression', as shown in the following illustration:

Nautilus Find pulldown with expanded terminology

Users should also be able to access online Help that will provide explanations of menu items and how to use the search syntax.

Again, we recommend following the GNOME Documentation Style Guide. We encourage developers to involve a technical writer in the review of any terminology, error messages, or other on-screen text delivered into GNOME. Developers are encouraged to ask terminology questions on the gnome-doc-list@gnome.org mailing list or the #docs channel on IRC.

"Red Pencil" Icon in Nautilus Search Results:

Relevant Usability Principle: Feedback.

8 out of 12 participants were confused by the red icon that appeared in the sidebar while their search was processing in Nautilus.

Confusing icon in Nautilus Search Results

Participants' eyes were drawn right to it and most interpreted it as something negative about their search results. Some were so distracted by the icon, and convinced that it meant their search was unsuccessful, that they didn't realize there were search results displayed in the list! When asked what they thought the icon meant and why it appeared, they responded:

"There are no items called proposal.txt?" (P2)
"It means I could probably read but not edit?" (P5)
"I have nothing? This really confused me." (P7)
"Don't write? It is unclear if it means 'don't do anything' or that it didn't find anything." (P9)
"I can't edit? Was it there before? I don't know why it is there." (P10)
and our favorite response,
"It means 'No Pencils'! Good question. No writing? Why would I want to write there? (P11)

Design Recommendation: Remove the red pencil icon. It is unclear why it appears in the sidebar or what it means. If it does mean the user can't edit a file, then for consistency it should remain in the sidebar when the file is double clicked and opened into a Nautilus viewer.

No Cursor Change:

Relevant Usability Principle: Feedback.
Some users were also unsure of the success of their search because the cursor didn't change while a search was in progress in Nautilus.
Design Recommendation: It is important to communicate to users that the system is busy and to provide feedback indicating that the system has received the users' input and is operating on it. During a lengthy search operation, when users must wait until the operation is complete, change the shape of the cursor. Because users are still able to click elsewhere in Nautilus while a search is in progress, we recommend changing the cursor to a combo cursor (arrow + hourglass), such as the combo cursor seen in xalf when an application is launched. However, this combo cursor only applies to the active Nautilus window with a search in progress. If the user clicks elsewhere, for example invokes a terminal or opens the Control Center, the cursor should return to the normal arrow cursor within those applications.

Indistinctive Throbber:

Relevant Usability Principle: Feedback.
Users missed the subtle throbber animation in the upper left corner of the Nautilus window.

The inactive state of the throbber.

A snapshot of the in-progress state of the throbber.

Design Recommendation: We recommend designing a more distinctive Nautilus throbber that provides better visual feedback to the user that the system is busy. To be effective, the inactive state of a throbber must be easily distinguishable from its in-progress state. The following is an example of an effective throbber animation, with an inactive state that is distinct from the in-progress state.

An effective inactive state.

An effective in-progress state.

Users double-clicked the text file in the search results and were able to view the text file. Next we asked them to go to the web page specified in the text file. Users tried several ways to get to the web. Some used the Location field in Nautilus, some opened a Netscape window, and others tried to click on the URL in the text document.

Non-Active URLs:

Relevant Usability Principle: Consistency and standards.
Users were quickly frustrated when they discovered that the URL was not active in the Nautilus viewer and that and clicking it would not take them directly to the web. We heard the following comments:

"I can't click on an active URL...That's not easy." (Pilot)
"The possiblility for human error [when typing] made it tough." (Pilot)
"Other software does that...There should be a shorter way to do this." (P1)
"It would have been nice to have that as a live link." (P11)

Two users were so convinced it would be a live link that they highlighted the URL, double clicked it, and right clicked it before giving up.

Design Recommendation: Users expect the ability to click on live links and be taken to the web. We recommend supporting live links and implementing appropriate cursor changes over live links in the Nautilus viewer. The cursor used over a live link in the Nautilus viewer should be the one that Mozilla uses for live links if Nautilus has been compiled with Mozilla support to render its HTML pages, or the cursor that GtkHTML uses if Nautilus has been compiled with GtkHTML support to render its HTML pages. This will ensure that the same cursor is used for live links whether Nautilus is used to look at a text file or a web page.

Carriage Return Symbols:

Relevant Usability Principle: Aesthetic and minimalist design.
People commented on the carriage return symbols that appeared in both gedit and the Nautilus viewer window.

Awkward carriage returns

"I'm not a big fan of how it is wrapping." (P11)
"Those are weird, would make it hard to read out loud, I don't care for it." (Pilot)

"Is it an active link to a website?" (P2)

Design Recommendation: The carriage return symbols are an awkward way to represent line wraps. It is fairly standard to just wrap the lines without symbols. We suggest removing the symbols entirely and wrapping lines at word breaks.

We asked users to look at the web page and then return to the text file to answer some questions about an image on the web page. Now, with Nautilus acting as many users' web browser, we saw people confused while trying to navigate back to their original text document. As they moved between file management and web browsing tasks, users with earlier praise for the combined file manager and web browser, began to voice confusion. Users became confused about whether they were looking at their file system or the web and there was confusion around the Nautilus navigation buttons (Up, Forward, Back, Home). Comments included:

"Is this an OS or an app? Is it more than web browsing? It acts like a browser. The menus look like a browser..." (P2)
"I had to get used to seeing stuff like a browser, [it] gives the impression of a browser; even though I'm not surfing I have bookmarks." (P7)
"I was surprised I could open a text file and a web page in the same window." (P9)
"I was confused when the text file opened in a browser type thing." (P5)
"Its unclear if Find is for the web or the desktop. It took me from the desktop to the internet, handy. Then I clicked on Home, and it took me out of the web. Is Home on or off the web?" (P4)
"It is confusing between the Up, Back and Forward buttons." (P4)

Nautilus Viewer Mode:

Relevant Usability Principle: Feedback.
Once users returned to their text document, they tried to type in the answers the questions. We witnessed various levels of frustration and confusion as users discovered they couldn't edit the text file. Reactions included:

"I would expect to be able to write once the file is opened...I'm not sure [what is happening] exactly." (P6)
"I'm trying to think of why I would need to go somewhere else to open the file...it's just text, why can't I edit it?" (P8)
"I can't work..." (P4)
"I don't know that I like that." (P7)

"I can't change it because I am not in a text program?" (P9)
"It looks like the document is read-only. I expected [this to be] a word processing application." (P2)
"Okay, I'm in read-only mode as opposed to edit." (P1)
"It looks like I am in viewer mode maybe." (P3)
"Its not the full document, just a representation. I can highlight but not edit. Is this a viewing window?" (P4)

"Maybe [the read-only view] is the original file, so you can't overwrite it?" (P4)
"Does it protect the original version of the file and the Open With... buttons open a new version of the file to edit? (P1)

"I was expecting a word processing app to open [the file]...weird." (P9)
"It was not obvious that the viewer was read-only." (Pilot, P8)
"It was letting me look but not edit, that is not what I am used to. I don't know if I like it." (P6)
"It should say 'preview' so that you know it is [not the editable document]." (P4)
"You should put something around the document to indicate that it is read-only." (P6)

Design Recommendation: We recommend providing more visual indication that the user is in viewer mode and cannot edit. One possible approach is to present the file surrounded by a gray border, to imply that the user is not looking at the actual file but at a view of the file. Adobe Acrobat Reader uses a similar approach successfully to indicate that files are read-only. In addition to displaying the file within a gray border, we recommend adding help text to the top of the view pane and above the Open With... buttons in the Nautilus sidebar. These ideas are depicted in the following illustration.

Possible approach to representing read-only views in Nautilus

Other alternatives might include popping up a tooltip if the mouse is hovered over the read-only view, with a message like "Read-only view. Use "Open with" buttons in sidebar to open the original"; or popping up a warning dialog with a similar message if the user tries to type into the read-only view.

We recommend involving a user interface designer when redesigning how Nautilus views are visually presented. Developers are also encouraged to ask UI design questions or solicit feedback on the usability@gnome.org mailing list or the #usability channel on IRC.

For any on-screen text, we recommend following the GNOME Documentation Style Guide. We encourage developers to involve a technical writer and to ask terminology questions on the gnome-doc-list@gnome.org mailing list or the #docs channel on IRC.

Open With... buttons:

Relevant Usability Principles: Feedback. Match between system and real world.
Users had to be pointed to the Open With buttons and some were not immediately sure how they would help accomplish the current task of editing the text file. Many users found the application names meaningless.

Open With... Buttons

"Open With... buttons application names made no sense. It was not obvious that they are applications." (P1)
"What's the difference between gedit and GNU Emacs?" (P4)
"Open With...GNU Emacs...gedit...that means nothing." (P8)

Users did not recognize the applications so they often clicked on the general Open With... button. Clicking this invoked a chooser dialog which they found even more confusing. One user commented,

"I'm not sure what program or environment to use to open the file....there's too many choices." (P2, P4)

The Open With [application] buttons, which were no doubt meant to be helpful defaults, were not helpful to new GNOME users. One user completely missed the Open With buttons because he had the Tree tab expanded on the sidebar. Needless to say, he became very frustrated trying to find a way to open the text file for editing.

Design Recommendation: We recommend adding a text string above the Open With... buttons that reads, "Click a button below to open the file in an appropriate application." We also recommend that, if possible, tooltips be implemented for the buttons that show the descriptive comment from that application's .desktop file, if it has one. To be consistent, though, tooltips must be implemented for all buttons, otherwise the application may just appear to the user to be broken. So for applications without a .desktop file comment, a generic tooltip should be used-- this could just duplicate the text on the button, to avoid extra translation effort. The proposed text string and tooltips will help novice GNOME users, unfamiliar with GNOME application names, to recognize that the buttons will launch applications. Both the text string and a sample tooltip are depicted in the following illustration.

Open With... buttons with helpful on-screen text and tooltips

table of contents | << previous | next >>

Send feedback to Sun-GNOME-HCI@sun.com