This is Part 2 of a 3-part blog series; this post builds on materials featured in an earlier post called DevAssistant Heuristic Review Part 1: Use Case Walkthroughs.
In this part of the DevAssistant heuristic review, we’ll walk through an itemized list of the issues uncovered by the use case-based walkthrough we did in part 1.
Since this is essentially just a list of issues, let me preface it by explaining how I came up with this list. Basically, I combed through the walkthrough and noted any issues that were encountered and mentioned in it, large and small. The result of this was a flat list of issues. Next, I went through the list and tried to determine a set of categories to organize them under by grouping together issues that seemed related. (You could do this in a group setting via a technique called “affinity mapping” – another fancy UX term that in essence just basically means writing everything out on post-its and sticking related post-it notes together. Fancy name for playing with sticky pieces of paper 🙂 )
Breaking the issues into categories serves a few purposes:

• It makes the list easier to read through and understand, since related issues are adjacent to each other.
• It breaks up the list so you can review it in chunks – if you’re only interested in a certain area of the UI, for example, you can hone in on just the items relevant to you.
• It tends to expose weak areas in great need of attention – e.g., if you have 5 categories and one of them is attached to a particular screen and the other 4 are more generic, you know that one screen needs attention (and should probably be a high priority for redesign.)

All right, so here is the list!

Base UI Design

These issues apply not to specific dialogs or screens, but more to the basic mechanics of the UI and the mental model it creates for users.

1. Takes time to get situated: When I first look at this UI, I’m not sure where to get started. Because the first tab says “Create Project” and the second says “Modify Project,” I get the impression that you might progress through the tabs in order from left-to-right. From poking around, though, this doesn’t appear to be the case. So at initial glance, it’s hard for me to understand the overall flow or direction I’m meant to go in through the interface.
2. Projects created/imported feel very disconnected from DevAssistant: It feels like there is no follow-up once you create or import a project via DevAssistant. I expected to be able to browse a list of the projects I’d imported/created using DevAssistant after doing so, but there doesn’t appear to be any link to them. DevAssistant seems to forget about them or not recognize them afterwards. Sure, they live on the file system, but they may live in all different places, and I may need some reminders / instruction about how to work with them – the filesystem doesn’t provide any context on that front.
3. Little user guidance after project creation / import: After the user creates a project, all they really get is a green “Done” notification on the setup wizard window. I think there’s a lost opportunity here to guide the user through everything you set up for them so they know how to take advantage of it. Maybe have a little guide (easily dismissed or optional) that walks the user through the options they selected? For example, if they chose the vim option, have a section that activates on the post-project creation screen that talks about how DevAssistant customizes vim and how they can make use of it in their workflow. Basically, nudge the users towards what they need to do next! Offer to open up Eclipse or vim for them? Offer to open up the project in their file manager? Etc. etc.

Clarity / Context

These are issues where the UI isn’t clear about what information it needs or what is happening or why the user would pick a specific option. The cop-out fix for these types of issues is to write a lot of documentation; the right way to fix them is to redesign! If an option is confusing to explain and benefits all users, just turn it on by default if it’s not harmful instead of putting the burden of selecting it on the user. If the pros/cons of a config option aren’t clear, explain them – add some contextual documentation right into the app via tool tips or more clear text in the UI.

1. Tab names unclear: The names of the tabs across the top don’t give me a good idea of what I can actually do. What does “prepare environment” mean? Looking at the interface, I think that going through one of the wizards under “Create Project,” would prepare an environment for the selected type of project, so why would I click on “Prepare Environment?”
2. Prepare Environment options confusing: When I look at the options under “Prepare Environment,” I see “Custom Project” (what does this mean vs. the “Custom Task” tab?) and “DevAssistant.” These options don’t help me understand what “Prepare Environment” means. :-/
3. DevAssistant button under Prepare Environment confusing: Why would I want to set up the environment for DevAssistant and checkout sources? Is the “Dev Assistant” button under “Prepare Environment” meant specifically for developers who work on DevAssistant itself?
4. Some options could use more explanation / optimization: Some of the options in the dialogs could use more explanation but they don’t have any tooltips or anything. For example, why would I choose Python 2 vs. Python 3 when creating a new project? What are the pros/cons? How do I take advantange of the customizations offered for vim so I can determine if they’re worth setting up? (Or why wouldn’t I want to set them up? If it doesn’t take up much disk space and it’s a good value add why not just do it if I have a vimrc?)
5. Not sure what “deps only” means: This could be my ignorance not being a real developer, but most if not all of the config dialogs I ran into had a ‘Deps-Only’ option and it’s still unclear to me what that actually means. I get depenencies in the context of yum/RPM, and I get them in the context of specific stacks, but I’m not sure how DevAssistant would generically determine them? Also, what happens if I don’t check off ‘Only install dependencies’ and check off everything else? Do the dependencies get installed or not? If I check off ‘Only install dependencies’ and also check off everything else, does that mean none of the other things I checked off happen because I checked off ‘Only install dependencies?’ The grammar of the string makes it ambiguous and the option itself could use some wordsmithing to be a bit clearer.
6. What happens if you choose an option that requires something not installed? It’s not clear to me what happens if you pick vim or Eclipse, for example, in one of the options dialogs on a system that does not have them installed. Does it project setup fail, or does it pull in those apps? Maybe DevAssistant could check what development environments it supports that you already have installed and gray out the ones you don’t have installed, with a way to select them while explicitly choosing to install the development environment as well?
7. Users need appropriate context for the information you’re asking them: There were a few cases, particularly related to connecting to github accounts, where the user is asked for their name and email address. It isn’t clear why this information is being asked for, and how it’s going to be used. For example, when you ask for my name, are you looking for my full name (Máirín Duffy,) just my first name (Máirín,) or my nick (mizmo?) (And can you support fadas? Or should I type “Mairin” instead of “Máirín”?)

Human Factors

This is a bucket for issues that put unnecessary burden / inconvenience on the user. A good example of this in web application design is a 3 levels deep javascript tiered dropdown menu that disappears if you mouse off of it. 🙂 It makes the user physically have to take action or go through more steps than necessary to complete a task.

1. Hover help text not easily discovered / pain to access: After a while of poking around, I notice that there are nice explanations of what each button under each tab means in a hover. My initial thought – putting this valuable information under a hover makes it more challenging to access, especially since you can only read the description for one item at a time. (This makes it hard to compare items when you’re trying to figure out which one is the right one for you.)

   

2. Window Jumps – This happens when clicking on buttons in the main setup wizard window and new windows are launched. For example, go to “Modify Project” tab. Click on Eclipse Import or Vim Setup. It moves the DevAssistant up and to the right. Click back. The window remains up and to the right. Why did it move the window? It should remember where the user placed the window and stay there I think.
3. Project directory creation defaults to user’s homedir: I think a lot of users try to keep their home directory neat and orderly – defaulting to creating / importing projects to users’ home directories seems the wrong approach. One thing to try would be to make a devassistant directory during the first run of the application, and defaulting to creating and importing projects to there. Another option, which could be done in conjunction with defaulting to a ~/devassistant directory, could be to ask the user during first run or have a configuration item somewhere so that the user can set their preferred repository directory in one place, rather than every time they create/import a project.
4. No way to create new project directory in file chooser for project directory selection: In a lot of the specific project creation dialogs, there’s an option to specify a project directory other than the user’s home. However, the file chooser that pops up when you click on “Browse” doesn’t allow you to create a new directory. This makes it more of a hassle (you have to go outside the DevAssistant application) to create a fresh directory to store your projects in.
5. Holy modal dialogs, Batman! I encountered a few modal dialogs during the process that made interactions with the application a bit awkward. Some examples:
   • There was a very large Java error dialog that was hidden under another window on my desktop, and it made buttons on the main progress/setup window unclickable so I couldn’t dismiss the main window without dismissing the Java error window. (And the Java error window didn’t have any button, not even an ‘X’ in the upper right corner, to dismiss it.) (See Use Case 2 for more details on this specific scenario.)
     

     

   • During the Django setup process (Use Case 1) and during the C project use case (Use Case 2), there was a small modal dialog that popped up a little after the setup process began, asking for permission to install 20 RPM packages. It halted the progress being made – similar to how old Anaconda would pop up little dialogs during the install process. It’s better to ask questions like this up-front.
     
   • Another time during the Django setup process (Use Case 1), there was a tiny modal dialog that aligned to the upper left corner of the screen. I completely missed it, and this halted the project creation process. (It was a dialog asking for my name, related to Github account connection.)
     http://blog.linuxgrrl.com/wp-content/uploads/2014/08/Screenshot-from-2014-08-30-215454-1024×576.png
6. If the user fills something out incorrectly, it’s not possible to recover in some cases. This is just another vote to ask users needed information up front and avoiding modal dialogs – I filled out the wrong email address in one of the pop up modals during the project creation process and realized too late I used the wrong email address.
7. Git name / email address very sticky and not easily fixed: During Use Case 1, I was prompted for my name and didn’t realize it was the name that would be attached to my git commits. Once it’s input though, there’s no way to update it. It’s unclear where it’s stored – I blew away the project I was creating when I input it, thinking it was stored in the .git/config file, but DevAssistant still remembered it. Configuration items like this that apply to all projects should be editable within the UI if they can be input in the UI.
8. Text fields for inputting long paths are unnecessarily short: This is pointed out specifically in Use Case 2, but I think all the setup dialogs were affected by it. The text dialog for putting the path to your project in, for example, was only long enough in my case for “/home/duffy/Repo” to be visible. The field should be longer than that by default.

Status / Transactional

These are issues that revolve around the current status of the task the user is trying to complete. An example of a common issue related to this in UIs in general is lack of progress bars for long-running tasks.

1. When main window is waiting on user input, it should be made clear: During the Django setup process in Use Case 1, I had opted to use Github for the new project I was creating. After filling out the config screen and pressing ‘Run,’ it looked like the project creation process was going to be a while so I multi-tasked and worked on something else. I checked on the main window a few times – at a certain point, it said “In progress” but it wasn’t actually doing anything – a tiny little window popped up in the upper-left corner, halting the whole process. It would have been better to ask me for that information up front, as to not halt the process. But it also would have been good, if the main window is waiting on something, for it to let the user know it’s waiting and isn’t “In progress.” (Maybe it could say, “Paused, waiting on user input?”)
   

2. Ask users all of the information you need up front, so they can walk away from the computer while you set things up: Speaking of that last point – this was an issue we had in the old Anaconda, too. During the installation process, sometimes error messages or dialogs would pop up during the install process and they would halt install progress. So the user may have gone to get a coffee, come back, and everything wasn’t done because anaconda sat there a lot of the time asking if it was okay to import some GPG key. When you have a long-running process (a git repo sync, for example,) I think it’s better to ask the user for everything you need up front rather than as the application needs it. It’s akin to someone coming up to your desk to ask a question, going away for a couple of minutes, then tapping you on the shoulder and asking you another question, then coming back 3 minutes later to ask another one – people like that are annoying, right?! (Well, small children get away with this though, being as cute as they are. 🙂 )
3. Transaction status unclear after errors or even after completion: When I canceled the Django project creation in Use Case 1 because I input the wrong email address, I wasn’t sure of the state of the project and how to proceed cleanly. What directories had been created on my system? What packages had been installed? Etc. I would have liked to clean up if possible, but it wasn’t clear to me what had happened and it didn’t seem like there was an easy way to undo it. Ideally, after hitting cancel, the application would have explained to me something about the state of the system and recommended a forward course of action (is it better to blow everything away and start over? Or re-run the command using the same parameters?)
4. Little/Vague progress indication: There’s a yellow “in progress” string on the wizard screen after you hit run, and the cursor goes into spinner mode if you focus on that dialog, but there could be better progress indication. A spinner built into the window (here’s an example) is a good option if it’s not possible to do a progress bar. Progress bars are a little better in that they give the user an indication of how much time it might take to complete.

Layout / Aesthetics

These are issues around the actual layout, typography, padding, arrangement of widgets, widget choices in a given screen or dialog. They tend to be surface issues, and usually it’s a better use of time to rethink and redesign a dialog completely rather than fix these kinds of issues only on the surface (which could be akin to putting a different shade of lipstick on.)

1. Package install confirmation dialog layout issues: So this is pretty surface-level critique – but there’s a few issues with the layout of the dialog asking the user if it’s okay to install packages via Yum. Here’s what it looks like initially:
   
   Usually the button that moves you forward is the farthest to the right, and the cancel is to the left. Here, the ‘Show packages’ button is on the right. I think maybe, ‘show packages’ should not be on the same line as ‘Ok’ and ‘Cancel,’ but instead maybe it should be a link above the buttons that expands into the full list (limited to a specific max vertical height of course, as to not make the buttons disappear so they are not clickable!) The list itself, has numbers, ‘1’ and ‘2’ before some of the package names – it’s unclear to me why they are there. Also, the list is very long but there’s no way to filter or search through it, so that might be a nice thing to offer. What are people concerned about when evaluating a list of packages to be installed on their system? The number of packages and total size might be useful – the size isn’t listed so that could be a good piece of information to add. I could go on and on about this dialog, but hopefully this demonstrates that the dialog could use some more iteration.
2. Layout of options via linear checkbox list can cause confusion about relationship between options: In several cases during the walkthrough, I became unsure of how to fill out the setup wizard for various project types because I wasn’t sure how the different checkbox options would work. In one case, it seemed as if particular selections of checkboxes could never result in success (e.g., in use case 4 when I tried to create a custom project with only the ‘deps only’ checkbox selected.) In other cases, some of the options seemed to be vaguely related to each other (Eclipse or vim) and others seemed less related (github vs python 3 or 2.) I think probably each screen needs to be reviewed and potentially rearranged a bit to better represent the dependencies between the checkboxes, base requirements, etc. For example, categorizing the options – put Eclipse and VIM under a “Development Environment” category, put git / github / etc. options under a “Version Control” category, etc.
   

Feature Set

These issues are around the features that are available (whether or not they are appropriate / useful or accessible / placed correctly) as well as features that might be needed that are missing.

1. No way to import pre-existing project that wasn’t created with DevAssistant? This one seems like a bit of a show stopper. I tried to import a project that wasn’t created using DevAssistant (which is the majority of upstream projects at this point,) and it didn’t work. It bailed out after detecting there’s no .devassistant in the repo. If there is a way to do this, it’s not clear to me having gone through the UI. It would be nice if it could import an existing project and create a .devassistant for it and help manage it.
2. The button to create a github project is under the ‘Modify Project’ tab, not the ‘Create Project’ tab: This is a bit of an oddity – the create project tab is more focused on languages / frameworks… creating a new project in GitHub is definitely creating a new project though, so it doesn’t make sense for it to be under “Modify Project.”

Bugs

These are just outright bugs that don’t have so much to do with the UI specifically.

1. Screen went black during root authentication during Django setup: I think this was some kind of bug, and wasn’t necessarily DevAssistant’s fault.
2. Could not create a Django project on development version of Fedora: My Django project creation failed. The error message I got was “Package python-django-bash-completion-1.6.6-1.fc21.noarch.rpm is not signed. Failed to install dependencies, exiting.” Now, while this is a little unfair to point out since I was using F21 Alpha TC4 – DevAssistant should probably be able to fail more gracefully when the repos are messed up. When errors happen, the best error messages explain what happened and what the user could try to do to move forward. There’s no suggestion here for what to do. I tried both the “Back” and “Main window” buttons. Probably, at the least, it should offer to report the bug for me, and give me explicit suggestions, e.g., “You can click ‘Back’ to try again in case this is a temporary issue, or you may click ‘Main Window’ to work on a different project.” It probably could offer a link to the documentation or maybe some other help places (ask.fedoraproject.org questions tagged DevAssistant maybe?)
3. Unable to pull from or push to github: During the Use Case 1 walkthrough, I was left with a repo that I couldn’t pull from or push to github. It looks like DevAssistant created a new RSA key, successfully hooked it up to my Github account, but for some reason the system was left in a state that couldn’t interact with github.
4. C project / Eclipse project creation didn’t work: There was a Java/Eclipse error message pop up and an error with simple_threads.c. Seems like a bug? (Full error log)
5. Tooltip for Eclipse import talks about running it in the projects directory: This seems like a bug – the string is written specifically for the command line interface. It should be more generic.

Up Next

Next, we’ll talk about some ways to address some of these issues, and hopefully walk through some sketchy mockups. This one might take a bit longer because I haven’t sketched anything out yet. If I’m not able to post Part 3 this week, expect it sometime next week.