We’ve been having a bit of a Anaconda custom partitioning UI thrown down the past couple of days in #anaconda to try to make some more progress on it.

You may recall, the direction we’d most recently taken the mockups involved a UI centered around the mount points that are / will be created on the system:

We hashed out some issues to address with this approach. Some we have addressed over the course of our discussion, some we haven’t. Here’s how it broke down:

Issue #1: If you have more than one mount point of the same type on the system, you have an odd name clash.

See, we let you select whatever hard drives / storage devices you want as part of the installation. Now, the drives you select may not be blank / nicely-formatted. Rather, they may have pre-existing OS installations on them, and some of those you might want to keep around – maybe you just want to install in the available empty space on the drive(s). The UI above assumes you’re only displaying mount points for one OS.

• What if I have a Fedora 16 installation on a 1 TB disk that I want to keep around, and I just want to give Fedora 17 a try in my 500GB of free space on the same physical drive? Well, if I have my Fedora 16 partitioned with /, /home, /var, swap, etc., those mount points will show up in the left bar in the mockup right alongside the new /, /home, /var, etc. that I’m creating for my new install. Oops.
• What if I want to blow away that Fedora 16 install and install Fedora 17 fresh in the same space? When those F16 mount points show up, how do I know if they are the F16 ones that I should delete/format, or if autopart already handled that and they are my new Fedora 17 ones?

So we thought through a few ways to accounts for this:

A dropdown between OSes

(Ignore the emblems, we were playing with them for another idea.)

It’s uncluttered since you only see one OS at a time. You know which OS you’re looking at so you know what the mount points are for. It’s not super-discoverable, though; it’s also a tad clunky visually – I’m not sure it’s very common to have a dropdown embedded in the left sidebar of a screen layout like this. Generally I don’t like dropdowns as a main navigation elements like this because I think they are physically harder to target than alternatives (a made more crystal clear to me than ever with spending the past week wearing a brace on the wrist of my primary hand. Sigh.)

So, meh.

A Nested Tree

You know, I’m sure there is a time and place for nested trees, but I try to avoid them like the plague. Depending on the implementation of course, sadly they often depend on targeting an area that is on average 12×12 pixels in size – not cool. Implemented properly, clicking either the [+] or [-] icon will toggle opening up a section of the tree, but this isn’t always possible. For example, in Nautilus’ list view, you can only click the [+] or [-] icon – clicking on the name of the folder opens up that folder fully in an icon view. Ick.

We didn’t bother mocking this one up. Don’t mean to hate on you nested tree luvas out there. If I’m nuts for this attitude, school me (*politely*) in the comments.

Ditching the system vs data labels and using those labels to demarcate OS

This one is pretty clean, but it will likely require a scrollbar. Also! It means the system vs. data slider up at the top will make a lot less sense and probably will need to be ditched as well. :-/

Cell-phone style nav of the mount point list

Yeah. I put this mockup in a subdirectory called ‘crackrock.’ I have actually never seen this done before (have you?) It seems like an interesting way to separate out the different OS mount point listings without using a tree view, but it’s kind of an odd pattern and would probably confuse people.

Accordion-style nav of the mount point list

This is the one that Chris is working on today. (Thanks ebassi for helping figure out how!) The Accordion menu is a common UI design pattern, and while for some installs it will require a scrollbar, I think it maybe solves the problems in the best manner here.

What do you think?

Issue #2: When do we do autopart?

David Lehman and I also talked about in which scenarios do we auto-partition a device for the user vs. let them decide what to do. If you have a disk with a contiguous chunk of space that meets the minimum space required for autopart, we *can* do autopart – it doesn’t require a completely formatted disk/device. We decided that we should allow you to autopart a disk and then customize it; you might want to use the autopart scheme as a guide to start from in your customizations.

One idea on the table is that instead of doing autopart on the free space that’s available by default, we’ll leave it blank and have an ‘empty list message’ that says something like, ‘you have no partitions; create some below or click here to have us create them for you.’

Here is a mockup showing this:

Issue #3: How can we make it less confusing to understand which partitions are getting wiped and which are safe / going to be left alone?

(Not sure on this one.)

I think we should think about what should the default behavior be – wipe it all and opt-in to preserving select partitions, leave everything alone and opt-in to wiping select partitions, or install side-by-side and leave what’s there alone.

One thing to consider is to have a flag users could set when they choose to disk to indicate that if it’s okay to wipe the whole thing, and by default preserve the data. Maybe? Or maybe use the settings (‘gear’ icon) in the custom partitioning screen’s left nav bar’s bottom to let them do this, although at this point we are speaking in terms of mount points/partitions and not devices so I believe this is too late.

Issue #4: Will we support mounting the same mountpoint from different OSes?

I think we decided not to support that since mounting the same home from different OSes is not an advisable thing to do. For example, if you have different versions of the same app sharing the same .config directory, odd things can go down. Mounting simpler stuff than /home, like a /srv across OSes/ is simple to do post-install so there isn’t a lot of advantage of doing it in the install. (And you could always script it if you wanted to in a kickstart post. Remember, at least the plan is to support inheriting settings from detected KS files when you use the Anaconda UI.)

Issue #5: Can people remove devices in the custom partitioning screen?

What if their disk is full and all they want is to reformat a root device and assign some mountpoints — no device removal/creation?

The two cases where someone ends up in custom part are:

• (A) They opted in *before* the disk space reclaiming UI – they already had plenty of space so the space reclaim UI wasn’t offered up to them.
• (B) They did disk reclaiming and still came up short.

Issue #5 here is clearly case B. To reformat a root device and assign mountpoints, they could one-by-one hit the ‘-’ icon in the bottom of the left sidebar in the custom partitioning screen to remove partitions from the device and re-add them. How do we know to format it? Should we always format if all partitions are removed from a device in our custom partitioner?

Issue #6: Is the intention that the interface will be pre-populated with all the filesystems on the devices selected for installation?

Yeh, I think it’s a good idea. If you had a disk/device you wanted to preserve the filesystem of in its entirety, you wouldn’t have selected it on the device selection screen. This means that if a device you selected has a filesystem present on it and you’ve made it as far as the custom partitioning screen, you either want to blow it away or keep it around. If you want to keep it around, you’re likely to be a bit anxious (especially with a re-vamped installer ) about whether or not the data is going to make it, especially if you are lazy like me and don’t do backups in this situation AS WE OF COURSE RECOMMEND THAT YOU ACTUALLY DO! (Do as I say, not as I do!!) To see that the data is there on screen I think maybe helps with this anxiety. Although to be honest, maybe thinking about storage this much has made me focus too much on anxiety-aversion.

But yeah, nobody wants their data to get blown away so I do believe being able to see it there safe and sound (maybe with some further reassuring indicator it won’t be touched – one idea is to grey out the options on it unless you explicitly say yeh I want to blow it away, see mockup below) is a good idea.

Thoughts?

So…

That’s where we’re at right now with the custom partitioning UI. Do note that the custom partitioning UI is opt-in only, except in the case where you don’t have enough space for install and the space reclaim UI wasn’t able to squeeze your filesystems small enough to make room. (And honestly in that case, it is too, although the default option in that scenario is ‘Sorry Charlie, time to quit the installer.’)

As you can see, we have a number of open issues or directions we’re starting to explore, so if you have thoughts, (polite) admonitions, or brilliant ideas, let us know in the comments! We also have these discussions very informally in #anaconda on irc.freenode.net, and your (polite) participation is certainly welcomed there.

OMG you’re redesigning the anaconda installer?

Yes!

• Why oh why are we doing this? Learn here.
• You can read lots more of my scribblings about the project in this blog’s ‘anaconda’ category.
• We also have a Fedora wiki page for the project.
• Drop by #anaconda on irc.freenode.net if you’d like to get involved or simply voice your opinions.

(Polite Panda for Fedora 19?)

So with some great feedback and great suggestions from you, I’ve been iterating more on the partition resize screen for Anaconda.

I started out by poking around with the visual design of the drag handles, and Robin had the idea to make the space between partitions draggable and to use a model where you only drag between two partitions at a time. I think it will make more sense to do it that way, at least in this iteration. Initially I wanted there to be a free bucket on the right side that would grow as you shrank the partitions, but I think that makes it a little confusing as to how you would re-grow that partition if you changed your mind. Non-intuitive in the manner that the affect of your dragging can be displaced by more than just the next box over and it might not be immediately apparent to you that you can grow your partition even though it isn’t immediately adjacent to a block of free space.

Smooge had the idea that there should be a clear indicator of how much you can squeeze down a given partition, so now the partitions have a lightly-colored graph to indicate their relative fullness (white means free space.)

Nicolas suggested a pie chart rather than a bar graph to get users out of the mindset that this is meant to be an accurate representation of how space is laid out on-disk: I will be exploring that in another round but decided not to try it this time.

Puppy Dog’s Tails brought up the point that not displaying partitions based on whether or not their resizing is supported might not be the best idea. I do agree with his rationale and have found myself in the trap he described many times (“Hmm, it’s gone! Is it a bug, or was that intentional, or what?”) so I put an un-supported VFAT partition (yes, I forgot to label it ‘VFAT’ in the mockup, oops) in this round of mockups to represent that. Another concern Puppy Dog’s Tails brought up was “Disks need some free space to operate efficiently. Perhaps some naive user will take all the free space and allocate it to Fedora and be surprised when they boot back into Windows and it complains or runs slowly.” To answer that, the intention here (as achievable as it may or may not be, David Lehman will probably know the answer to that ) is to not let the users put themselves in that situation. I’m thinking a 500 MB buffer or so might be reasonable but David will probably know best there; the main point is we shouldn’t allow users to shoot themselves in the foot like that and absolutely shouldn’t take every last drop of free space since it’s probably not practical in most situations.

Okay, so here’s the thinking in this round:

Display partitions that we can’t resize

Here we’re showing a tiny EFI partition that can’t be resized. It’s small enough it doesn’t have a label on the graph, so you must click it to get a little label to pop up below it.

Display details on resizeable partition

Here we’ve clicked on the ‘BOOTCAMP’ partition and get a little extra information displayed about it below: the max we can make it right now is 50 GB, the smallest we can make it is 30 GB. That max 50 GB comes from the free space available; would it be useful to give it a max based on all free space on the drive (would be roughly 54 GB since there’s about 4 GB free on the ‘Macintosh HD’ partition, it appears.) What do you think? Is the ‘max you could do *right now*’ or ‘max you could do if you squeezed everything else’ more useful (noting this is a UI for making space for an installation of Fedora, not a generic partition manager)?

Deleting a partition

The best way to make space is to delete, delete, delete! This screen is already a lightbox though, and as misguided / foolish as it may be, one of my goals for the Anaconda redesign is that there shall be no more than one level of lightbox or pop-up here. (The current Anaconda suffers from some crazy nested pop-uppage.) But it seems a bit rash to let someone wipe an entire partition in one click without warning when they click that little ‘x’ in the partition’s upper left corner. So why not have a confirm button nested inside the partition’s box with a warning below?

Well, I’ll tell you why not. It’s a bit of a squeeze for smaller partitions. This is where I want to explore Puppy Dog’s Tail’s idea of having two vertical bars – then the graphs will be constrained horizontally, meaning I’ll have consistent horizontal space for a button like this. Maybe…. Maybe…. We’ll see if it works out, that’ll be round 3.

Do note the model here (at least, the intention!) is that you’re queueing up changes to the partition layout, none of which will be committed until you click ‘Reclaim space.’ This means you don’t really delete that partition until you click ‘Reclaim space.’ So maybe the confirm button is overkill. Maybe it’d be better to have a ‘Reset partitions’ button or something to restore the original layout?

What do you think?

Deleting a partition with no room to breathe

Here’s what I mean: the button doesn’t really have enough space… oh and by the way, the stuff under ’160GB Hard Disk’ in the left list are just me puttering around, I’m not sure if it makes sense to list the partitions there as well (current thinking on that is no, it’s redundant.)

Okay, again, these are all rough and just my current thinking after playing around in Inkscape and reading through your comments for an afternoon. Your feedback on the last couple of posts was incredibly helpful so if you’re willing to give it another go to help fuel this onward, please feel free in the comments!

(Note on the sources for this: the sources for these screens and the earlier ones are in the main Anaconda index.svg, in the ‘screen-destination-reclaim-*’ layers. )

So there’s a path in the storage flow of the Fedora installer redesign where if you don’t have enough free disk space to complete an install right now, but you have enough latent space available in your partitions if you were to shrink them. We offer to let you shrink them to continue the install in this situation. (This is highlighted in yellow in the flow chart above.) A partition should be considered shrinkable if it has at least one 500 MB+ of contiguous space within a shrinkable partition (not HFS journaled, not VFAT, not EFI, etc. etc.).

Here’s the screen you get should you end up in that situation:

So we’ve been talking about what happens when you click on that ‘Reclaim space’ button.

Tree list approach

First I took a tree list approach. While I hate tree lists, my brain was hurting around the concept that the general ‘list of parent items on the left, click on one, and details about its children are present on the right’ pattern that I find everywhere in the GNOME UI is typically only used for viewing details and not acting on them. There are some cases where you can act on them, but not in this, ‘check off the partitions you want to shrink across disks to get a grand total you shrink in one go’ shopping cart kind of pattern. If that makes sense. I got hung up on this, so I fell back on old reliable tree list.

“There must be a better way,” I told myself. This tree-list thing looks very 1998, and I think that’s being kind.

Click-and-drag approach

We had poked around with draggable partition blocks early on in the mockups for custom partitioning, so I thought maybe revisiting a clicky-draggy interface here might make some sense.

One issue here is when Chris looked at this, he assumed it was meant to represent the layout on disk. See I was thinking the ‘Free’ block could represent all free, unpartitioned space on the disk, and it would grow as you dragged the Firefox-textbox-style drag handles inward on any partition that was shrinkable. Is it a big problem if the diagram doesn’t represent the physical layout of space on the disk? I’m wondering if there’s some way to make it look, um, less ‘accurate’ or representative in that way so we don’t have any kind of cognitive dissonance screwing up how folks read this screen.

Click-and-drag approach with more block data

I think Chris very rightly classified this one as TMI. However, the idea here is you click on a block in the diagram and you get extended information about it below, in this case, that there are 3 blocks of particular sizes contained in the ‘free’ category.

Click-and-drag approach with less block data than before

An attempt at less TMI.

Where to go from here?

Well, what do you think? Is this approach generally the right one? Have any ideas on how to make the graph feel less like it’s representational of the actual layout of blocks on disk? Overall impressions?

We’ll probably be discussing this in #anaconda on Freenode tomorrow.

Partitioning personas

Redesigning the UI for something as complex as an OS installer has the potential to be disruptive to some classes of users, so in designing and re-designing and re-re-designing the partitioning screens for Fedora’s installer, we’d like to make sure you’re going to be covered.

Do any of these cases describe you, and if not, can you let me know how you use the partitioning functionality of Anaconda or really any OS installer so I can account for your use case?

The partitioning UI thus far

What are we doing to the installer’s partitioning UI to bring us to ask such questions? What is all this redesigning that’s going on? Well, let’s talk about partitioning as it works today in Anaconda.

Note that this is a screenshot of Red Hat Linux 8.0 from 2002, almost 10 years ago now. Aside from the online help / release notes pane on the left which has long since been dropped, this partitioning screen does not look much different today.

Our partitioning UI is currently very technology-centric. I suspect users care a lot more about the mountpoint layout of their OS with the technology underneath having a less primary role for them. (What the technology does for them, such as give them redundancy for their data via mirroring or increased performance via striping, I think they *do* care about, though.) Above is a screenshot from Fedora 15 showing part of the workflow in creating a partition. Before you can create a mountpoint layout or configure your filesystems, you have to create partitions and choose what technology to use with them.

Creating partitions is a means to an end of staking out some space for your files; if what the users really want to do is arrange their filesystem as they’d like it, why don’t we let them do that first, and guide them amongst the technology choices based on what it will do for them and their files later on?

“Wait,” you may ask, “are you trying to say that the goal of a user in a partitioning UI isn’t to create partitions?” Yep, basically I am. An illustration of how configuring RAID in the current UI may help explain:

Say I did a bit of reading and decided that for me, the best way to store the data in my home directory would be to set up RAID mirroring and striping between two physical disks (AKA RAID 10). If I set out to do this, what kind of workflow would seem most natural? Would it make sense to create my home directory, dictate the (when-all-is-said-and-done) capacity I want for it (let’s say 100GB), and apply the appropriate RAID level to it afterwards?

That’s what I thought. That’s not how it works in our UI right now, though. Right now, here’s the basic convoluted workflow:

1. Delete the auto-part layout since it’s all LVM and you want to use RAID on top of physical partitions. Click click click click click click click!
2. Create a RAID Partition; Give it the capacity you ultimately want (100 GB). Make sure it’s on hard disk #1.
3. Create another RAID Partition, identical to the other, 100GB. Make sure it is *not* on hard disk #1 but is on hard disk #2.
4. Create a ‘RAID device’, and add the two RAID partitions you just created to it.
5. Set ‘/home’ as the mount point of your ‘RAID device’ and set the RAID level you’d like.

That seems a little backwards to me. You create the partitions first, then the device. Why can’t the partition manager create the partitions for me based on my specifications for the device? It also seems a bit error prone, because I think it’s pretty easy to forget to create the two partitions on two separate disks. If you don’t, your mirroring doesn’t make sense since if the hard disk fails (what mirroring is meant to protect against), both of your copies are dust in the wind! The RAID device creation UI doesn’t state which physical disk each partition is in, either, so it’s easy to miss if you did make the mistake. The other thing this doesn’t protect against is that you could quite easily, without any complaint from the interface, mirror RAID together a 1 MB partition with a 1 TB partition, and lose 1 TB – 1 MB worth of space since the partition with the least capacity dictates the capacity for the device in mirroring. Sigh.

So a while back I went over in detail our buffet-style, technology-based mockups for partitioning – we had a sense that it was not the right approach but had whiteboarded and wireframed the mockups so I thought posting them would generate some feedback on a better way. And it did, of course, because the folks who find the time to read this and provide feedback are smart and helpful. Here’s a quick snapshot of one of those mockups as a refresher (the technology-focused tabs across the top is what I consider a ‘buffet’):

A new, mount point-based hope?

This is kind of what we’re leaning-towards now. After a few iterations, I call it the RPG partitioning UI. On the left, we give you a sane default mount point set up (dictated by either your particular spin or the install class, so if you’re using a desktop you get a desktop-focused one; for a server, a server-focused one; etc.) and let you modify as you like. By default for Fedora, we’ll have a btrfs set up (not reflected here.)

Notice how there’s selectors for each mount point where you can choose the partition type (physical, btr, LVM) and you can add on options, choosing the technology you’d like for each. RAID and LVM both offer mirroring. If you have a preference as to which one you’d like to use, there’s a spot for you to dig into that. However, we present mirroring as the feature you can opt into; we don’t present the technology at a primary level anymore here.

There’s also a cost associated with some options. If you choose to mirror a 100 GB home directory, for example, you’re going to need 100 GB x 2 or 200 GB to have that 100 GB mirrored. So there’s a ‘cost’ in terms of capacity for different options. What makes this the ‘RPG’ design is that as you add or remove features from how your file system is set up, the cost (or savings) in capacity are outlined right next to each option.

The general idea we have here is that if you don’t have sufficient hardware / capacity to choose a particular option, it will not be presented to you at all. No bait ‘n switch by offering it up front and then erroring out later.

Where this mockup needs work is how we allow the user to hook up their mount point setup and filesystem configuration to physical drives in their system. And that is why I’m showing the personas to anybody who will listen to try to make sure we understand where users are coming from when they do that hook up, so we don’t lock anyone out of essential functionality they need.

So that’s that.

OMG you’re redesigning the anaconda installer?

Yes!

• Why oh why are we doing this? Learn here.
• You can read lots more of my scribblings about the project in this blog’s ‘anaconda’ category.
• We also have a Fedora wiki page for the project.
• Drop by #anaconda on irc.freenode.net if you’d like to get involved or simply voice your opinions.

Peace & pandas everybody!

Over the past couple of months I have been working with Thomas Woerner on some enhancements to and new UI for Fedora’s firewall controls. These additions are part of Thomas’s work in adding the concept of firewall ‘zones’ to Fedora to simplify firewall configuration and help make it easier for folks to keep their computers safe.

Today, we provide users with a lot of control over their firewall in the system-config-firewall, but the problem with our current model is that with a laptop, you may connect to multiple different networks during the course of the day, and firewall rules that make sense for one network might not make much sense or may even be dangerous on another network. An example of this is if you’re sitting at home or at the office, you can pretty much trust the other systems on your network (well, at least if you’re at my office where we don’t have Windows systems ), so you might want to have your httpd service running if you’re a web developer and want to show others working links to web application code running on your laptop. However, when you’re at a coffeeshop with other systems on the network that you don’t know much about, you might not want to be serving up a web application that’s in development and not fully hardened / tested for security flaws since that would leave your system open to attack. Right now, though, to handle your location changes from a UI perspective, you’d have to open up system-config-firewall manually every time you changed networks and set up every little bit of configuration you’d like for that network, every time. There’s no concept of saving profiles that you can recall later (see screenshot below).

With the firewall zones concept, we’ll pre-define a set of generally useful zones (‘Home’, ‘Work’, ‘Public’, etc.) and configure them out-of-the-box to have sane default settings for each particular type of network. We’ll also allow you to tweak these settings to your personal taste and create new, additional zones to accommodate your particular network environments. Finally, we’ll let you recall these just by selecting a profile when you’re on a given network, we’ll let you set a default zone for networks that are new to your system, and hopefully will eventually allow you to set a default on a per-network basis so you don’t have to manually set which firewall zone you want to use every time you connect to a given network.

That’s the basic concept behind firewall zones.

Managing Firewall Zones

So Thomas first came to me, gave me some of the back story above, and described the components of this application he would need UI mockups for (my notes from that conversation):

• A dialog for creating / editing / deleting firewall zones.
• An applet which:
  • Gave you a quick way to jump to the Firewall Zone dialog above
  • Provided a panic mode functionality to completely wall the computer off from the network in case of a suspected attack
  • An ‘About’ item where you could get more information about the applet

Since I didn’t have a lot of time at the time, I proposed doing the mockup sketches with pen and paper and Thomas seemed cool with that, so you’re going to see my scribblin’ by hand below rather than the usual Inkscape-designed artifacts. (I used the Gimp Difference of Gaussians trick that Garrett taught me a while back to clean these up; they were originally on yellow ruled legal pads. Cool, right?)

Round 1: First mockups

I designed the applet in the context of the GNOME 3 panel. I know yet another applet won’t be popular. Hopefully it won’t be needed long-term; I think it would be nice to have one applet icon for all security & trouble-related items (ABRT, SELinux alerts, Firewall, etc.) so those things, as necessary during crisis situations, are readily accessible but cumulatively don’t land grab a larger swath of real estate on-screen than is really called for given the infrequency of crisis situations. We’re sadly not there yet though, and needed a way to access the dialog, so we thought an applet would serve the purpose for now. (It wouldn’t be unreasonable to add it to the NetworkManager applet, but since that applet is already a bit crowded, it’s probably not the best approach.)

The applet is extremely simple, as you can see in the mockup above: it tells you what your current firewall zone is, and gives you a button to press to open up the full Firewall Zones dialog. The ‘About’ item Thomas requested I don’t think is really necessary – we could have an about in the full dialog if needed.

I wasn’t really sure about the panic mode use case at this point in time, so I dropped it from this first mockup attempt.

As far as the dialog itself goes, in this first sketch, the idea was to drive the UI from the zones themselves, and across services, ports, and interfaces, offer notebook tabs to customize each zone. For example: I want to stream audio from my media device at home when I’m at home. That requires UPNP access, so I’ll go to this dialog, select my home zone, and go to the port tab to open up the UPNP port while I’m at home. Perhaps I’ll set my coffeeshop zone to disable the UPNP port since my home media device isn’t available in the coffeeshop and I don’t want that open port sitting around as a possible way for someone to attack my system.

Round 2: Applet + Dialog Mockups, Improved

Multiple network interface support: the assignments tab

After looking over my first set of mockups, Thomas pointed out one fatal flaw – a system may have multiple network interfaces (especially in a server context), and those network interfaces may need to be set to different firewall zones. Maybe one example of this is a publicly-facing webserver with one network interface that openly serves content out to the public, and another network interface that faces its internal network that has a very locked-down firewall configuration to protect the internal network from outside attack. (For example, this web server may need to get software updates and patches from the internal network, and its firewall may be configured so that no network traffic can flow from the web server into the internal network; only from the internal network out to the web server.)

So we added a top-level ‘Assignments’ tab that provides a list of the network interfaces present on the system on the left, and per network interface you can turn the firewall off or on and assign a particular firewall zone to it on the right.

Minor improvements to the zones tab

The ‘Zones’ tab is essentially the design from round 1. However, more complex configuration might be needed (for example, a port or service we don’t know about), so there is now a ‘custom’ button in the lower right that could work similarly to the current ‘other ports’ dialog in system-config-firewall – you can set up a custom service or port to include in your firewall rules.

Updating applet to accommodate multiple network connections and add a panic button

Finally, the applet dialog has gotten a bit beefier after the multiple network interface use case discussion we had. It’s modeled very much after NetworkManager’s applet. Each network interface / connection is listed alongside its current firewall zone, so at a glance you can see the firewall status for all of your network interfaces & connections. Below this list is a separator that provides you the link to the full firewall zones dialog, as well as the previously-discussed panic button to block a suspected network attack.

Setting a default zone

Initial designs and discussion

So last week Thomas came back to me after he’d put together some glade mockups. He was afraid the initial design (see screenshot above) that he’d done up in glade was overly complicated, and there must be a more simple / elegant way to offer a default firewall zone for users. This would be the default zone unknown / new networks would be assigned; it would appear during firstboot after installation since it would be nice to know before you start up your system how you would like the firewall to treat networks as they are encountered.

After a bit of discussion on the screen, I came up with the following goals for it:

• Enable users to easily select their default network zone.
• Provide users a basic understanding of what the default network zone is and what the implications of selecting it are.
• Help users make an informed choice as to which zone might work best for them, out of what may potentially be a long list.

While this initial glade mockup makes it appear as if there may be four ‘buckets’ or ‘categories’ of firewall zones because of the four vertical sections of buttons, there weren’t, really, and visually it’s a bit of a toss-up whether it’s intentional or not because the alignment of the buttons is a bit haphazard within the rows. There were no titles or names or descriptions for the various categories. Also, high vs. low wasn’t labeled – it actually denotes the level of trust you’re placing in your network, not the level of security you’re getting out of the choice! Finally, each zone has a simple name without any kind of description to help the user figure out which one would meet their needs – even if they decided they wanted to be somewhere in the middle in terms of security & trust level, picking a choice across the columns of the row they selected would be difficult without more information.

So over IRC we talked through an alternate way of arranging the screen, where we created four distinct buckets (‘Very high trust,’ ‘High trust’, ‘Medium trust’, ‘Low trust’) and had the user select the trust level they felt appropriate first, then within the trust level, use the drop down to select the particular zone in that level. While I think the explicit categorization helped a little, this arrangement combines radio buttons and dropdowns, which I think physically is a little clunky. It also suffers the same issue as the first mockup – we’re limited to only a simple label for distinguishing between zones within a category. High/low is also not really clear – I still felt as if someone might assume it’s security level, not trust level.

More detailed descriptions

So I came up with a quick Inkscape mockup showing what the dialog might look like if we provided some more details on each individual zone. The name’s in the upper left of each list entry, the description below that, and the general category in the upper right. The main way this UI works is you have one list of all of the zones available, and you could filter it down using the dropdown in the upper right to only see zones with the security level you’re interested in and compare them within that category using the fuller description.

The weakness of this mockup is that it’s geared for a large set of zones to choose from. However, users won’t have a large initial set of zones, and it could be confusing when they filter and only see one zone to choose from unless we default to showing all available zones in the filter dropdown. Also, what if you wanted to compare across ‘High’ and ‘Very high’ security zones? You couldn’t unless you viewed all zones, including medium and low.

So then we tried this toggle idea. You’ll see a listing of the various categories along the top of the list, and you can click once to see those zones included in the list below, click again to ‘turn off’ that category. After doing this mockup though, I definitely felt like it needed more thinking. Is this on/off button-based filtering really common enough for users to follow? I liked that we could set the list to, by default, display the zones we felt most useful for basic users but still enable more advanced users to get to what they needed, but I’m not sure as a UI pattern it’s common enough to be intuitive.

Thankfully Thomas did some brainstorming on his own after I sent him this mockup, and came up with this glade design:

While interacting with this glade file felt more natural than the button-based filtering one before it, the problem is that spreading the categories across notebook tabs means you’ll have one zone list per tab, and there is no unified list. So if I pick a zone in the first tab, then a different one in the second tab – which zone is the selected zone? It’s an instant apply dialog, sure, so some folks would assume their last-selected zone is the one that’s actively selected. Alternatively, though, I think a different user might think they had to pick one zone per tab. We could work around this in the design by having some central (outside of the notebook tabs) indicator to say what the currently selected default zone is. It might make the screen more cluttered. Some more IRC discussion and thinking later, thankfully spurred by this design, and we came up with the next mockup…

The winner… so far?

This is kind of a rip-off of how the GNOME control center’s keyboard layout tab works. By default, you have the three zones that would be the most useful for desktop users to work with in a list. Whichever zone is highlighted is the selected zone. As you click on zones in the list, you get a full description of that zone in the pane on the right. Now, this makes it more difficult to compare across many zones, but I anticipate that many Fedora desktop users are just going to pick from the base set of three or so that we offer by default and not worry too much about the others. If you’d like to explore additional firewall zones, you can click the “+” button at the bottom of the list and select from others we’ve made available by default.

If this was a control center module, it would not have the ‘Choose selected zone’ button on the bottom-right, because it would be an instant-apply window. However, for firstboot it needs a button to progress forward (or backwards to the hub, as the case may be.)

(And now I see an inconsistency in the mockups “Firewall Zone” in the window title, but “Network zone” in the dialog content!)

What do you think?

This is a little something Thomas and I have been working on over the past couple of months. Let us know what you think or if we missed anything!

Shameless plug

This is cool, right? Think you or someone you know could do this kind of design work and really enjoy it? We’re looking to hire a great interaction designer to work on projects like this, so if you or someone you know are interested, please apply!

So, last time we chatted about Fedora’s installer redesign, we walked through how users would select which disks they’d like to be part of the install.

Once our intrepid installer users have selected disks to install to, they should be set and the install will just work. (Okay, there’s the case where they have to squeeze space out of existing filesystems owned by another OS, and that’s in the plan, but not for this blog post.) In either case, these folks will not have to encounter screens like these at all. Some users, though, prefer to review and/or manually modify the disk partitioning, so this set of screens is what those users opt-in to see. So, most users simply trying to install Fedora on their laptop won’t ever have to bother with these screens unless they really want to.

The way it’s mocked up now, they are tabs across a single screen. Serving up partitioning buffet-style like this is not ideal in my opinion, because then we’ll be enabling users to do things like btrfs raid on top of md raid which can, if I understand correctly, eliminate some of the advantages of having RAID in the first place. Buffet-style partitioning also enables a scenario in which you create an md raid device that you then put in an LVM volume group that has a logical volume which you place into a btrfs volume… Is there a point to that? If not, then why make it so easily achieved?

So, what we talked about in #anaconda today is that we could change these mockups to include some screen where you choose one of the following four options:

• Physical partitions only
• mdraid partitions only
• LVM only (with raid option that uses mdraid under-the-covers on the physical volumes)
• btrfs only (with raid option that uses mdraid under-the-covers… btrfs raid doesn’t support raid 5 and is also not as stable as mdraid; this also avoids layering raid on top of raid in counter-productive ways.)

dlehman referred to this approach as being the python (‘there’s only one right way’) philosophy instead of the current perl (‘there’s more than one way’) philosophy. I have to say as a designer I really like the python approach better as it seems less error-prone and more focused on the end solution; the more meanderings we support, the more pits of snakes we set up for users to potentially fall into.

But maybe restricting users to those four partitioning flavors doesn’t make sense. What if I want my root filesystem to be physical partitions only, but I want my homedirs to be raided btrfs? Is this sensible? I don’t know. I don’t know why I would want to do that, really. Maybe we could offer a fifth, “you’re on your own, buddy” option that enables the full buffet. Oh and ouch. What do you do if you have a little smorgasbord of a partitioning scheme pre-existing on your disks…?

Well, in any case, if I want a complicated setup, I could always create it via kickstart, which is perhaps some solace.

Okay, so let’s get to the screens already now that I’ve undermined them with worrisome hemming and hawing. I have been staring at them far too long and need your unbiased, untainted, sensible opinions to move forward, I think.

How do I get here?

In the previous set of mockups for disk selection, the terminal screen of the 2 flows where you have enough disk space give you a checkbox to opt-in to see advanced partitioning:

So you check off the checkbox and hit continue, and you end up on this lovely little (terrifying) partitioning path shown in the diagram below under the 9-3-x box.

Physical partitioning

We had 7-8 variations on this that we worked through before we arrived at this; a custom accordion-style widget with an entry per-disk. When a row is expanded, a draggable-graph for the physical disk is displayed with an options panel underneath that is attached to individual partitions via a speech bubble tail.

There are two main cases here: you’ve got a pre-existing partitions you’re looking at, or you’ve got blank space on a disk that you’ve clicked on. (by default the options bubble is displayed for the first partition on the disk.)

Pre-existing partition

Since you may have data on a partition that you don’t want compromised, there’s a notion here of a ‘protect data’ lock. By default, we were thinking we’d apply it to all pre-existing partitions. If a partition is protected, than destructive operations such as changing the filesystem or capacity will be greyed out in the options pane; you could change the mount point for protected partitions though, since that shouldn’t hurt it.

Free space on a disk

So if you happen to select free space in the graph, you’ll be given the option to create a new partition out of it, or distribute it across other existing partitions (either proportionally or evenly… maybe icons would help illustrate the difference. Proportionally by default.) If there are no other partitions, you’ll also get an ‘other options’ link that, if you really want, will enable you to create an unpartitioned filesystem.

Creating a new physical partition

So if you click on ‘add partition’ from the free space options panel above, or if you clicked the ‘add partition’ button in the top right of the graph for a disk, this is the screen you’ll get. You can optionally drag out space for your new partition in a graph of the disk or just use the slider widget below it.

Redundant arrays of inexpensive disks (via mdraid)

Next up is the software RAID tab. The general layout here, which you’ll see in the LVM and BTRFS tabs as well, is that there’s a pane on the left that lists out the devices and a details pane on the right specific to the currently-selected device / volume / etc.

Raid device details

We’ve got a departure from the current Anaconda way of doing things here. Today, if you want to create a raid device, we first require that you create RAID partitions individually. Once you have enough free RAID partitions, we ungrey-out the create RAID device option and let you put them together.

• Problem: The current way will let me RAID together a 1 MB RAID partition with a 1 GB RAID partition, which will literally waste 1 GB – 1 MB worth of disk. No warnings or anything, either.
• Solution: You won’t have to be in the business of creating individual RAID partitions anymore. Tell us the RAID features you want (mirror, stripe, parity, etc.), and tell us how much disk capacity you want in the end, and we’ll handle creating the RAID partitions for you, making sure they are the right size and are also equal sizes so no disk space is wasted.

Maybe. Does it work for you?

(Another note: we’ll read linear RAID on pre-existing RAID disks but we won’t let you create it since LVM & btrfs are available.)

Add a new physical member to a RAID device

If you want to add another physical member to a pre-existing RAID device, you click on the ‘+’ button at the bottom left of the physical member list on the RAID device’s details pane, and you’re offered potential slices of unpartitioned disk space to choose from. When you add it, we’ll automagically make the new RAID partition the correct size to match the other members of the RAID device.

Creating a new raid device

If you want to create a completely new RAID device, you click on the ‘+’ button in the bottom left of the left pane, and you’ll get this lovingly complex dialog that offers up in human terms, not RAID level numbers, the various possible RAID features you might want with the rationale for each (why stripe? better performance.) Depending on what options you pick, you’ll end up with a different RAID level… we’ll display the raid level in a status area above the buttons along the bottom of the dialog.

If there is no way, no how you could reach particular RAID levels because you don’t have enough physical disks selected, the appropriate RAID options will be greyed out. If you only have one physical disk, for example, no mirroring (nor a false sense of security) for you.

LVM

The LVM tab follows a similar pattern to Software RAID, and you’ll see it under the BTRFS tab as well. One difference in the left pane is we now have a tree-like view, where the parent items are volume groups. You can select either volume groups or individual volumes in the left pane. Depending on what you’ve selected on the left, you’ll see details for it on the right.

LVM logical volume details

Here’s the details pane for the lv_home logical volume. As mocked up now, the striping and mirror options are those built into LVM itself, not any kind of mdraid layered underneath.

When adding physical members to a logical volume, you can, if you want, switch volume groups or create a new volume group. (Maybe this is weird and awkward. It’s inspired by how the RAID works – you don’t deal in RAID partitions, only RAID devices. Here, you don’t deal in volume groups, just logical volumes; you only deal with volume groups in a way that supports logical volumes. I’d rather users not have to deal with volume groups at all unless they really wanted to.)

LVM volume group details

If you click on a volume group in the left pane, then you get the following details pane. You can create a logical volume under the selected volume group with the button in the upper right; you can edit the physical members; you can change the label, change the extent size, or reserve space for later logical volume growth.

Create a logical volume

So here you create a new logical volume, and by default it’ll become a member of the volume group over whichever logical volume was selected when you pressed the “+” button to add a new one. However, in the dropdown next to ‘physical members’, you can pick a different volume group for it to be a member of or create a new volume group for it.

Create a new volume group

This is actually just the previous screen still, but it shows you what happens when you decide to create your new logical volume in a new volume group. A text field for the group’s label appears below.

Add a new physical volume

Need more capacity in your volume group / logical volume? Add a new physical member to it. This is the dialog you’ll see if you do that. Although I’m not sure it’s entirely valid to exclude physical partitions now that I think about it.

BTRFS

The BTRFS tab has a full-blown treeview in the lefthand pane, but this is solely because BTRFS supports nested subvolumes. We won’t be allowing the creating of nested subvolumes, but we will have to read them if they exist. I think it would be nice if there are no nested subvolumes on disk that we could use a non-treeview widget here since reading pre-existing nested subvolumes is really an edge case. (Alternatively, always show a flat list in the left pane, but if a given subvolume has nested subvolume children have a list in the details right pane that displays all the children.)

BTRFS volumes

This first mockup shows the details for a BTRFS volume. As mocked up it’s RAID options for BTRFS not mdraid underneath.

BTRFS subvolumes

Now we have a subvolume selected. Subvolumes don’t have labels so that field is taken out.

Adding a BTRFS volume

When you press the “+” button in the lower left of the lefthand pane in the BTRFS tab, you could add either a BTRFS volume or a BTRFS subvolume. The first choice in this simplified creation lightbox is either volume or subvolume. The philosophy here, which is a bit different than adding new logical volumes or new RAID devices, is to ask the bare minimum of details and allow the user to fill in optional stuff after the new volume is created. Is this inconsistency horrible? Maybe!

Adding a BTRFS subvolume

In the previous screen, if I selected “sub-volume” from the first dropdown, the dialog would change slightly for me.

Adding a new physical member to BTRFS

Need more space? Then you need to add more disks/devices. This is what it looks like if you press “+” on the list of physical members of a BTRFS volume or subvolume. This is the most permissive of the ‘add new physical member’ dialogs; it’ll show LVM logical volumes, RAID devices, partitions, etc.

These all need more work…

…for sure, but hopefully this is a decent start. What do you think?

We are making some great progress on Anaconda’s UI revamp mockups after last week’s Anaconda team meetings. Here’s the storage flow diagram, now annotated with the screen #’s from the mockups:

So let’s dive into the screens as they look so far. These are hot-of-the-press and may suck, so of course we’re posting them here for your perusal, critique, and feedback so we can make them better! I’ve tried to highlight areas where we’d like the most feedback just like this.

9-1-1 / Install Destination Simple

So the deal with this screen is that it’s the main / default interface for selecting disks connected to your system for installation. As mocked up here, you could say we’ve got a laptop with a blank SSD and some other smaller peripheral storage devices plugged in.

Local / Standard Drives

The top half shows your run-of-the-mill laptop hard drives, external USB drives, etc.:

• There’s a small piechart in the upper right that roughly & quickly shows how much space is taken up (filled in) and how much is free (unpartitioned + free on fs).
• If you hover over any of these standard drives, you’ll get a tooltip breaking down how much free space there is exactly, and what type is chunk is.
• The disks in this widget are listed from largest capacity to smallest capacity.
• If necessary, the list will scroll horizontally.

Specialized & Network disks

Most folks won’t need to use this at all, but this is how you’d go about adding ‘special’ disks such as iscsi/fibre, multipath/otherwise SANs or DASDs or things like that. For Fedora installations, we may, just may, hide this widget using an install class since Fedora’s main target is desktop. (If this would break your heart please let us know.)

Status bar area

Maybe it’s a bit heavy-handed, but we thought for some sticky situations between the selected software requiring ridiculous amounts of space vs there not being possibly enough disk space available for installation it might be good to have a status area that lets you know how you’re doing in terms of readiness for kicking off the install. So here we see a little note that says we haven’t selected any disks and we really need to! We don’t want this area to be chatty; it should just explicitly list out any items that need to be done before the install can be started. What do you think about the status bar?

There’s also a little summary above it, a link-style line of text that gives a summary of the current selections. In this mockup there are no selections, but if you click on it you’ll get a full summary of any selections you might have.

9-1-2 / Install Destination with Pre-existing OS

Here we’ve got the same screen as earlier, showing what the screen might look like with a desktop that has multiple hard disks installed and another OS (Windows 7) already installed to one of them.

Not too much to add here except that we’ll be running osprobe immediately preceding entry to this screen in which case we’ll seek out any OSes we know about and display them here. I’m a bit torn over this, because on the one hand it is helpful to know which drive is which, and knowing which OS is installed on which can help identifying disks. However, it might also scare folks away from using a drive because they assume selecting a drive that has Windows or whatever else on it means it’ll get blown away (it doesn’t.) So… I’ve been stewing on this. Any ideas?

9-1-3 / Install Destination plot thickens

Now we see:

• We’ve got some network disks in the list (you get whisked away to a different UI to select them then taken back to this screen to summarize the selections. We’ll not review those screens in this post.)
• We also see selected disks in the local/standard area. Is this clunky? I’m thinking ctrl+click to select but maybe that’s not obvious enough. Maybe they could have little checkboxes in the corner too and rather than be shift+click they’d just be click once to select, click one more time to deselect?
• If you hover over a ‘special’ disk, then you get some extended ‘special’ information about it. (WWPN, LUN, etc)

9-1-4 / Disk shopping cart

If you click on the summary link in the lower left, you’ll get a nice summary of the disks you’ve got selected for install here. Note that this screen would only have the top two disks in the list in it according to the selections on screen 9-1-3 just before this.

9-1-5 / You’ve got space!

So if you already cleared off space on your drives, added and selected a new drive, or simply had enough unpartitioned space lying around on your selected disks, you are good to go. On this screen, you can select the checkbox to go to advanced partitioning anyway, or you can avoid clicking on it and hit continue to go back to the main pre-install hub. Or you can cancel and add more disks.

9-1-6 / You could scrounge some space together…

You’ve got enough space, you really do. It’s just that it lay wasted within pre-existing filesystems at the moment. We can guide you through squeezing it out (mockup not covered in this post), or you can check off the advanced partitioning checkbox and shrink/delete partitions by yourself (again mockup not covered in this post. But wait until you see it. It’s… different!)

So we offer you some choices here:

• Reclaim your space, we’ll guide you through shrinking your filesystems.
• Reclaim your space through the advanced partitioning screen.
• Modify your software selection so it doesn’t require so much darn space!
• Go back and add more disks and come back later.

Make sense?

9-1-7 / Gimme more, gimme gimme more

Well, even if you deleted all of those photos of your cat, Britney and LadyGaga albums, and your KVM disk images… you’re just not going to have enough space at all, sorry.

We’ll still try to offer constructive solutions though:

• Back out and add more disks.
• Select a smaller version of Fedora to install.
• Quit the installer, and come back after you drop by BestBuy or order a new hard drive from newegg.com.

There’s more!

I promised mockups earlier this week so I hope these please you. There are more, I promise; I am prepping them for your perusal. If you cannot wait I advise you click below and turn up your speakers:

I took some time today to translate some of last week’s Anaconda whiteboards to cleaned up flow charts of the screens involved. I used Inkscape and Jesse James Garrett’s visual vocabulary templates to make these.

Full screen flow diagram

(click to download PDF)

Storage screen flow diagram

(click to download PDF)

Whiteboards from late Friday

I also uploaded some whiteboards from late last Friday:

Software Selection

Well…

Did we miss anything? Did I miss anything in transcription? Overall, what do you think?

David Lehman and Will Woods are in the Boston area this week so along with Chris Lumens, Peter Jones, and David Cantrell we’ve all been whiteboarding away, planning and refinement on the upcoming Anaconda UI redesign that is scheduled to land in Fedora 17.

These are just whiteboards; I’m hoping we’ll have a more detailed post after our brains cool off from the gears churning so intensely Most of the discussion so far has been about the (opt-in) partitioning screens, and overall flow.

Overall Flow

Bootloader Config and Install Use Cases

What We Can Detect / What We Can Resize

BTRFS partitioning

LVM partitioning

Shrink-o-Matic

Yeah, these might not make much sense until I get a chance to Inkscape-ify. We do have some mockups out of this too; more later!

The story up ’till recently

So you may have heard about Fedora Community, a web application we developed and launched in 2009. Or, maybe not. From the wiki planning page for the project:

Fedora Community is a web portal designed to make it easier for package maintainers to do their job. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.

Well, the project wasn’t the resounding success Spot, J5, Luke, and I were hoping it might be. We’d set out to make life easier for Fedora package maintainers, which of course benefits everyone who uses Fedora. We did run a usability test of Fedora Community at FUDcon Toronto in December 2009 after it had been available for a couple months. There’s some detailed testing analysis here, but in short we identified the following issues during testing:

• The testers had never heard of it before, and were confused as to what it was for.
• The application runs pretty slowly.
• The navigation was confusing.
• Search results weren’t always great.

Because of various commitments / new projects on each of our plates, however, after the usability test the site pretty much remained the same for a while. We never did a huge marketing push for it, and around the same timeframe we launched fedoracommunity.org which kind of confused matters: it is a completely different site with the same name! (It’s a portal for world-wide, region-specific Fedora websites and teams.)

The plot thickens

As you may already be aware, the Fedora infrastructure team has been evaluating the services they provide and shutting down services that aren’t in active use that expend resources that could be better used for Fedora in other ways. For example, recently the Fedora WordPress MU server was shut down for a number of good reasons. (Please check out the full rationale for more backstory.)

In this spirit, Smooge started a thread about Fedora Community and what future plans for it are on the Fedora infrastructure mailing list a couple of week ago. Here’s a summary of the points that came up in the thread:

• It’s aimed at contributors, not users.
• It’s AGPL so it may pose a burden other apps in Fedora’s infrastructure don’t, so the license may be an issue.
• If it’s meant to be used, it needs to be advertised more.
• It’s not built for RHEL 6 which limits the servers it can be deployed to.
• There was one user of the app (Thomas Spura) who spoke up in its favor, saying it enabled him to view information across infrastructure apps without having to dig into multiple apps individually to get the same data.
• Smooge put together some usage statistics: “Currently we are seeing 380->420 unique ip addresses per month who are not bots or not referrals from other sites. Most go to /community/ but ~100 of them made queries beyond standard page data (images, javascript, and /community/). While it doesn’t sound a lot… for a site that doesn’t have a lot of advertising it is an audience.”

So last week the Fedora Community team (Spot, J5, Luke, me) got together to figure out what we should do. We grabbed a couple of whiteboards and discussed a bit about Fedora Community’s fate!

Whiteboard time!

In short, we basically started talking through the issues we’d need to fix to make the application more awesome, which involved some great expansion ideas, but then receded back to ‘let’s fix the core first,’ which then ended in ‘let’s get a new, clean, minimal front-end going, really get it right, and expand carefully from there.’ Okay, so, let me see if I can walk you through how the discussion went so you can understand this train of thought:

Ideas for more features

I think we started out talking about cool new features we could add on to it. Luke’s initial post to the Fedora infrastructure list thread covers a lot of these ideas, as does his summary of the ‘Next Big Fedora Engineering Project’ session at FUDcon Tempe earlier this year. Here’s an at least partial summary in case you’re lazy like me and don’t click on all the links:

• Real-time Infrastructure
• Meeting app
• Improved upstream monitoring
• Discussions app
• Spin Master
• Source-level package diff viewer
• SIG dashboards, with action items, SOPs, packages, people, meetings, etc
• Package review app

(Want more details? Check this link and this link for them!)

Ideas are great, but…

I think we talked about some of these awesome ideas, but then came to the realization that our scope was too big, and while all of the ideas rocked, it might take us a really long time and a lot of effort to do them right, and we should probably focus on fixing what we’ve got before adding more stuff.

Okay, what should we fix in what we’ve already got?

So we then started coming up with a list of the issues in the current site that we wanted to address, and went into some detail about how we might fix them:

• Performance issues: it takes a long time to get data back from some of the other infrastructure apps that Fedora Community queries. Some sub-topics we branched out into:
  • Real-time enablement reliability: (pardon my less-technical take) We built Fedora Community with the idea of being able to display real-time updates via an underlying message bus infrastructure to which all of the various components of the infrastructure providing notification data (koji, bodhi, FAS, etc.) are hooked up. Any notifications could be displayed live in the UI without a page refresh. However, we’re still doing some static queries and the live messaging isn’t fully hooked up yet. There were concerns that flipping the switch, turning off the old system, and enabling only messaging would mean we’d get a performance hit on various servers and messages might get lost. So I think Spot or J5 said we could just leave the normal email notifications on and the messaging queue-backed new live stream on at the same time, and diff the new system to the old system to see if any messages had dropped.
  • Real-time enablement performance hits: there was a concern raised that enabling real time messaging everywhere would slow down the web app, but the conclusion seemed to be it would actually make a lot of systems more efficient and would help performance.
  • Benchmarking: some benchmarking tools should be built into the Moksha stack (the middleware that Fedora Community is built on to of). Then we should do some benchmarking of queries between the Fedora Community app and the various infrastructure apps it talks to so we have some data on which apps are slowing down Fedora Community because the queries are taking too long. These benchmarks should be query-level, not just app-level so we can isolate specific queries as the cause of pokiness and have them fixed.
• Feature re-evaluation: As my sad little cartoon guy kind of shows, having too many features that aren’t quite there yet can be an overwhelming position. What do you fix first? What do you focus on? Spot suggested, in a similar manner to what the infrastructure team is doing with hosted services, that we evaluate the features Fedora Community has today and consider paring it down to a core. The core he proposed was to not support packagers per se, but to just be a useful source of package data. So the focus would be packages, not packagers. (See crossed out ‘packagers’ in upper leftish area). Using this as a mantra, could we go through feature-by-feature and pare things down?
• UI issues: As the main designer of the UI I will be the first to tell you, it is not great and could be much better.
  • Navigation complexity: We built it to be something that, depending on your role in Fedora, would have a very different interface. For example, if you’re a packager you’d see builds, updates, package info, etc. If you’re an ambassador, you might see an ambassador roster widget where you could view ambassadors by region, and an events calendar to see what events are coming up that you could help out with. We designed it so that we could give users different tools based on their needs, but we only partially implemented tools for one target user – Fedora packagers – and never really realized that vision of different flavors for different user needs. The navigation suffers a lot from this; we may have been better off making a finely honed packager tool, and making a completely separate tool for each other user and maybe loosely tying them together with an optional global navbar (kind of like the new Google accounts one? But I kind of also hate that toolbar too…)
  • Search: The search functionality in the UI needs work. Some of the query times in the usability test were pretty bad. Search is a hard problem technically, though.
  • Mobile UI: The UI doesn’t have a mobile stylesheet to render it nicely on a mobile device.
  • URL ickiness: The url for the app is not short and not memorable: “http://admin.fedoraproject.org/community. The URLs we display for various pages are not predictable and kind of ugly. These are symptoms of a security system in place because we have Fedora account logins on the site. We use the user’s account information to provide personalized data (e.g., we’ll give you information on packages you own) and also to give you access to user information on other folks in the system.

  This last point was fodder for the next phase of the conversation, which I’ll call the Zen phase.

  Everything Zen

  
  Nirvana by ePi.Longo on Flickr. Used under a CC-BY 2.0 license.

  “Well, why do we require login in the first place?” I think Spot asked when we were trying to figure out how to rememedy the ugly URL issues.

  “Personalization in presenting packages!” I think Luke said. (Maybe he didn’t. But doesn’t dialog make the blog post so much more interesting to read?)

  “It allows you to search users and get details about them,” said J5.

  “I can get those details about users from a bot in IRC without being logged in,” I said.

  Spot also pointed out, “You can also look up the packages someone owns without having to log in as them.”

  !

  WHY DO WE NEED LOGIN IN THE FIRST PLACE?

  Turns out maybe we didn’t. Simplification idea! We continued on this track of minimalism. J5 brought up what I think was a pretty cool idea, “design the interface as if it was for a mobile phone, to keep it clean and minimal and to only have the essentials.”

  So they talked for a bit and I started drawing what I thought such a (gentle) beast may look like:

  

  There’s a user track along the bottom where you can, read-only:

  • Search or browse for packages in Fedora.
  • Search or browse for users in Fedora.
  • View a list of the latest package updates (with filter?)
  • View a list of the latest builds (with filter?)

  This is the simplest plan. Next, there’s a track for packagers (ones not present above highlighted):

  • View your packages.
  • Search or browse for packages in Fedora.
  • Search or browse for users in Fedora.
  • View your updates.
  • View a list of the latest package updates (with filter?)
  • View your builds.
  • View a list of the latest builds (with filter?)
  • View your bugs.

  We talked about how you shouldn’t have to log in to get the above personalized features, but that people might get creeped out if we ask for their FAS username without a password, so we need to figure out a way to do that without scaring people.

  From those scribbles above, we pared things down some more into an initial first cut feature set:

  • Search packages
    • Search interface
    • Package results list:
      • First precedence: exact match in name of package
      • Second precedence: partial match in name of package
      • Third precedence: match in package tags
      • Fourth precedence: match in package summary
      • Fifth precedence: match in package description
    • We should be able to pull results for both packages as they are named in Fedora, and packages as they are named in Debian and any other distros that provide a way to correlate packages cross-distro.
    • We will not list subpackages as separate packages. If a subpackage has name unique to the package that generated it, we’ll show the parent as being the package but also highlight that the match was in a subpackage.
    • Other package types that will be children of their parent and not treated as separate packages include debuginfo, devel, and specific binary packages.
  • Browse packages: by default you’ll get a search box though. We’ll let you opt into a browsing interface. Maybe not based on comps.
  • Packages I own
  • Package details page: we talked about this being kind of like a facebook profile for a package. It should show the full family of the package: its binaries, sub pages, devel package, debuginfo package, source, spec… but at least initially, no dep list or dep browsing interface.

  We ended this discussion by talking about how we should see what features users ask for and implement them if there is enough demand, and to be careful not to take on too much and expand the scope too wide and have it become an unruly garden to tend again. (This is kind of the 37signals approach, isn’t it?)

  Okay, cool. Sounds like a plan. Does it make sense how we got to this point now?

  The contract

  

  So here’s what we agreed on from this exercise:

  • We’re going to try this Zen approach read-only to start.
  • No logins. We’ll get the data without having you log in to get it.
  • We’re focusing on packages, not the packager.
  • We’re going for minimalism, both in look, feel, and feature set.
  • We will not base this new Fedora Community on the UI we have now. It’ll be a fresh start (but of course we’ll make use of pre-existing research, backend, and other components in enabling the new UI.)
  • This thing is gonna be fast so strap on your seat belts!
  • We need a re-branding. ‘Fedora Community’ is too vague and non-distinctive. Ideas?

  Homework

  Here’s our homework! (Note ‘next week’ on this whiteboard means Thursday this week. Eep!)

  

  What do you think?

  Well? Comments are open. Do you use Fedora Community? Do you have an amazing idea for a new name for it? Are you down with the Zen approach or have we taken minimalism to the extreme here? Are you terrified by what we are proposing? Or overjoyed? Let’s hear it.