verbal sketch of UI design
data preservation/migration; BoF agenda
|Deletions are marked like this.||Additions are marked like this.|
|Line 61:||Line 61:|
|== Implementation ==
=== Code ===
|Line 67:||Line 63:|
|== Outstanding issues ==||Partitioners involve an inherent risk to data, which must be mitigated as far as possible. Errors raised by partman will generally be presented to the user and may include an option to continue or go back. Steps will be taken to ensure that partman cannot proceed past its confirmation question to commit changes to disk unless the user has positively confirmed the changes.|
|Line 71:||Line 67:|
| * Settle on UI design; concrete sketches; make sure to gather input from both GNOME and KDE people.
Packages affected: ubiquity, partman-*
Rewrite Ubiquity's advanced partitioner, concentrating on usability and commonality of code.
The use of gparted/qtparted in Dapper's live CD installer (Ubiquity) was expedient in terms of developer time, but it wasn't the long-term right answer. Using an external partition editor has many inherent problems, such as complex communication requirements with the rest of the installer, UI inconsistency between frontends, and behavioural inconsistency with the text-based installer and with autopartitioning. Furthermore, both gparted and qtparted are complex independently-designed C++ programs which require complicated patches to work in both standalone and installer mode; updating them has become a risky and time-consuming business, and fixing bugs can require investigating the design of both programs from the ground up.
To replace this, we will write a simple Python frontend to partman using ubiquity's standard debconffilter framework, with relatively small PyGTK/PyQt shims. The UI will be designed from scratch with an eye to usability, and will be sufficiently similar between the GTK and KDE frontends to offer familiarity.
- Judith has been using Unix for some time, and wants to install Ubuntu using a custom partition layout with separate /, /usr, and /var filesystems. She wants reasonably fine control over the sizes of these partitions, and wants to choose which filesystems to use for each.
- Eugene has a number of different operating systems installed for experimentation, and wants to add Kubuntu to the list. To make room, he will resize one of his existing partitions and delete another.
- Chris has been trying out both Ubuntu and Kubuntu, and is confused by the way the advanced partitioners are so different in each. He would like to be able to transfer his experience from one to the other.
- James has a system with two hard drives that mirror each other using RAID1, to reduce the risk of data loss from drive failures; the hard drives are both much larger than he needs right now, so he uses LVM on these so that he can extend filesystems easily without having to set up the partition table perfectly first time. He would like to use Ubiquity to install Ubuntu on this system.
A successful implementation will provide a working and reliable advanced partitioner for both Ubiquity's GTK and KDE frontends that behaves similarly to that of the text-based installer but has a more attractive and better-designed UI, properly integrated into Ubiquity. LVM and RAID functionality is not required in a first iteration, but may be added later if time permits.
partman, the partitioner used in the text-based installer, is a debconf application whose main control flow features a basic UI revolving around a select widget with one line per partition ([http://shots.osdir.com/slideshows/658/13.gif screenshot]). On selecting each partition, a submenu of information and operations that can be applied to that partition is presented, including method (use a filesystem, don't use, swap, other specialised uses), flags (e.g. boot), create (when selecting free space), resize, delete, and others. Some of these operations cause further prompts to be presented, while others present the submenu anew with updated information and perhaps different operations.
partman's backend has been polished by use in one Debian and three Ubuntu releases, and while it certainly still has bugs they are generally relatively minor. partman's UI, on the other hand, while reasonably effective as far as it goes, is basic and can be confusing. Much of the confusion arises from the fact that it is not possible to cram all the available useful information into a single screen of text, and from limitations in cdebconf and its newt user interface that require partman to present select lists where in some cases buttons or other widgets would be more appropriate. Fortunately, these limitations do not apply to a graphical interface, and we already have the technology required to transform debconf protocol requests into a pretty good graphical user interface.
Any graphical user interface to partman is likely to require presenting information from the partition submenus up-front. As such, the Ubiquity partman component will on occasion (certainly on startup) need to navigate internally through all the available partition submenus and cache information about all of them; this can easily be done with the aid of a state machine. When the user performs an action in the user interface, the partman component will navigate to the proper partition submenu and select the requested action. When partman's update.d scripts are called for a particular partition, as happens following certain operations, the cache of information for that partition will be invalidated, and the partman component will need to reload it as soon as possible; some operations (such as deleting a partition) will update all partitions and so the cache will need to be reloaded from scratch.
While cache updates will take a little time to complete, the author expects that this can be optimised at need, and that the benefits of caching will render update times not generally a problem.
A quick screenshot survey of some other major distributions' advanced partitioners (please don't get offended if I've left one out!):
[http://shots.osdir.com/slideshows/588/9.gif Gentoo 2006.0]
Mandriva 2006: [http://www.howtoforge.com/images/perfect_setup_mandriva_2006/6.jpg 1] [http://www.howtoforge.com/images/perfect_setup_mandriva_2006/7.jpg 2] [http://www.howtoforge.com/images/perfect_setup_mandriva_2006/8.jpg 3] [http://www.howtoforge.com/images/perfect_setup_mandriva_2006/9.jpg 4] [http://www.howtoforge.com/images/perfect_setup_mandriva_2006/10.jpg 5] [http://www.howtoforge.com/images/perfect_setup_mandriva_2006/11.jpg 6]
SuSE 10.1: [http://www.howtoforge.com/images/perfect_setup_suse10.1/13.png 1] [http://www.howtoforge.com/images/perfect_setup_suse10.1/14.png 2] [http://www.howtoforge.com/images/perfect_setup_suse10.1/15.png 3] [http://www.howtoforge.com/images/perfect_setup_suse10.1/16.png 4] [http://www.howtoforge.com/images/perfect_setup_suse10.1/17.png 5] [http://www.howtoforge.com/images/perfect_setup_suse10.1/18.png 6]
The coloured graphical view of the disk presented by Gentoo and Mandriva (and by RHEL without colours) is a useful visual cue. I don't think it's wise to rely on it entirely as Gentoo appears to; that has obvious accessibility problems and doesn't present much in the way of detailed information up-front. The RHEL display is visually plainer and in particular makes no use of colour, but it strikes a reasonable balance between visual cues and presentation of information up-front. SuSE's detailed view crams in lots of information without looking too cluttered, which I like. We should be able to borrow ideas from all of these.
I suggest that the UI should start at the top with a horizontal bar-chart representation of each disk on the system, and immediately below that a list of all partitions (and chunks of free space between or around partitions) with the following information for each: name (for some partition table types), partitioning method (filesystem, don't use, swap, etc.), mountpoint, label, bootable flag (and others?), and size. (Start and end positions could be added but are probably unnecessary with the bar chart and with inclusion of sizes for free space chunks.)
Across the bottom of the page there should be at least the following buttons, some of which may be greyed out depending on the selected partition list item: Create, Edit, Delete, Undo. The Create and Edit buttons will present a dialog that allows changing all of the items of information displayed for the partition, with the possible exception of size depending on external constraints. The Delete button will schedule a partition for deletion immediately without asking for confirmation; this sounds scary, but Undo is available and text on the UI will indicate that changes will not be committed until the user selects Next.
Due to some technical constraints in partman, resizing a partition must be committed immediately and cannot be undone. (It may be possible to lift this restriction some day.) Resizing a partition will present a message box that indicates this clearly. Given this unusual behaviour, it may make sense to add a Resize button in addition to Edit.
Data preservation and migration
Partitioners involve an inherent risk to data, which must be mitigated as far as possible. Errors raised by partman will generally be presented to the user and may include an option to continue or go back. Steps will be taken to ensure that partman cannot proceed past its confirmation question to commit changes to disk unless the user has positively confirmed the changes.
BoF agenda and discussion
- Settle on UI design; concrete sketches; make sure to gather input from both GNOME and KDE people.