DesktopVolumeManagement

Differences between revisions 7 and 8
Revision 7 as of 2005-11-05 21:20:27
Size: 7870
Editor: host81-151-158-111
Comment:
Revision 8 as of 2005-11-06 09:21:23
Size: 7956
Editor: host81-151-158-111
Comment:
Deletions are marked like this. Additions are marked like this.
Line 62: Line 62:
A state transition diagram is under construction at DesktopVolumeManagementStates.

Summary

Volume management is not easy enough for new users although the most used parts are easier than Windows - like selecting the right USB device for unplugging. This spec was created to make it easy for everybody to move data around and manage it. It initially covers things like support for long volume labels, uniformity between the drivemount applet and places and more items for volume context menus.

Rationale

Ubuntu has some usability benefits over Microsoft Windows in this area, but there are some important places where Windows is easier. Those are formatting, and setting volume labels. Tasks that should be simple and easy to perform and to discover how to perform are difficult in both Ubuntu and Windows leaving no good option for user. The changes required are small, probably requiring little to no infrastructure changes and only a bit of commandline tool integration.

Use cases

  1. Places (in Nautilus and in panel menu) and desktop only show short volume labels (tested with FAT16 usb drive).
    • User has two USB drives with volume labels set by a knowlegeable friend using mlabel from mtools. These labels are "Bob's USB Drive" and "Bob's USB Drive (the new one)". With both plugged in, Bob expects to see the correct volume labels rather than ones that are hard to distinguish. Suggestion: Support long volume labels in nautilus, places, and on the desktop.
  2. The drivemount applet displays only a manufacturer specified string, and does not display the volume label, making it difficult to identify which volume one is (un)mounting.
    • Bob uses two USB drives with different labels but of the same model. He prefers to use the drivemount applet as it is always available. Bob wants to see which USB drive he is about to unmount if he has both plugged in at the same time. Suggestion: Show the same volume label as places and the desktop in addition to the manufacturer specified string. Discussion: For unmounted devices, the applet could attempt to guess the filesystem type and use a filesystem specific tool to find the volume label whenever the user brings up the menu.
  3. It is non-obvious how to set the volume label of a filesystem on a removable device.
    • Bob has many floppy disks and many USB drives but none of them has a meaningful volume label (since the manufacturer pre-formatted them). Bob didn't format them with volume labels before beginning to use them as he used them for ad-hoc purposes until he worked out how he would organise his data. Now Bob would like to set sensible volume labels so he can see at a glance what volumes are mounted, or plugged in. Suggestion: Add a menu item for volume icons along with the existing mount/unmount items. This menu item should bring up a dialog where it is easy to change the volume label.
  4. main doesn't seem to contain tools to format rewritable DVDs with udf filesystems, nor is there a simple user interface for it.
    • Suggestion: Add a menu item for volume icons along with the existing mount/unmount items. This menu item should bring up a simple dialog where it is easy to trigger a udf filesystem to be made on the cd device. A similar interface could be used to format floppies and USB Drives.

Scope

Design

Note in the below menu item suggestions that the label changing option includes the term "rename" as different user backgrounds will associate different terms with the task.

  • The context menu for floppy drives should include "Open", "Mount" | "Unmount", "Rename/Change Label", "Advanced". If it does not contain a filesystem, the context menu should include "Make Filesystem", "Advanced"
    • JohnNilsson: Why introduce the user to the concept of a filesystem? Open/Mount could just fail gracefully and tell the user that "This unit isn't prepared for use. Do you want to do it now?". Another problem is that it may take time to read the device, thus the context menu would have to wait.

      • TristanWibberley: I would prefer a menuitem to describe what it is doing more accurately. The menu should show "Detect and Open" until the media has been detected - to indicate that it might not open. For auto-detected media, this menu item would do nothing since "Detect and Open" would be already underway. Upon detection, the menu should be fleshed out with appropriate items. I think "Initialise Filesystem" or "Prepare Filesystem" should be used - they are both obvious first steps and introduce the user to the idea that media have filesystems to store files in. I think it is important for users to be able to discover what the computer is doing with their data. Whilst a device is mounted, detection need not be done, but if a device is not mounted then detection should always be redone when accessing the menu - and the menu updated upon completion, unless the device can determine that the media has not been changed (eg USB Drives provide removal notification). Let the tooltip with the label give some sort of "loading" indication for the label while detection is underway.

        TristanWibberley: Perhaps "Detect and Open" should always open a nautilus window straight away (showing an unlabeled drive in places until that particular window is closed - so if the user clicked to a different place by accident, he could still go back to where he meant to be). The window would indicate that detection is underway and would fill in the contents when mounted, or options if no filesystem is present. For CD-ROM drives, if no filesystem is present (or if the CD is multisession) it should open a burn window so files can be dragged in and burned. "Open" on a drive with no filesystem should do the same - open a nautilus window that indicates detection underway, and, upon completion, shows the same items as the context menu would have had if the drive were right-clicked if there is no filesystem to mount.

        • TristanWibberley: Actually, I think you're right, the menu item should just be "Open", and it should mean "Detect and Open" in all cases (since devices can always vanish without warning (even where the media locks). If it has vanished the user can get a nautilus window with the context menu items.

  • The context menu for cd/dvd drives with a cd in should include "Open", "Mount" | "Eject", "Advanced". If it contains an ISO filesystem or audio tracks and is rewritable, the context menu should include "Complete Wipe/Erase/Blank". TODO: detect single vs multisession vs blank disks and decide on appropriate menu items.
  • The context menu for cd/dvd drives with a dvd in should include "Open", "Mount" | "Eject", "Advanced". If it contains an ISO filesystem and is rewritable, the context menu should include "Complete Wipe/Erase/Blank" (which should be relegated to the Advanced dialog if the disk has a UDF filesystem). If the disk has a UDF filesystem and is rewritable, the context menu should include "Rename/Change Label". If it is blank and rewritable the context menu should include "Make Filesystem" - to make a UDF filesystem as the prefered mode of operation. If it is blank and not rewritable, "Open" should be available to get a nautilus burn: window as with writable CDs.
  • The context menu for USB drives should include "Open", "Mount" | "Unmount", "Rename/Change Label", "Advanced". If it does not contain a filesystem, the context menu should include "Make Filesystem"

A state transition diagram is under construction at DesktopVolumeManagementStates.

Implementation

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

DesktopVolumeManagement (last edited 2008-08-06 16:22:15 by localhost)