Jamie Bullock

The Pure Data GUI — a UX study

There has been some recent discussion on the Pd mailing list about rewriting Pd’s GUI using a new framework. This was triggered by my announcement of the Integra Live audio processing tool, followed by a number of people on the list commenting on how good the Integra Live GUI looks.

Integra Live makes use of certain visual effects: gradient filters, glow, anti-aliasing, bezier curves and so on. The line of thinking on the list seemed to be that these things made the UI look good, and that in order to make Pd’s UI look good, it needed to be rewritten using a different framework, as Tcl/Tk doesn’t have good graphics support.

Whilst it’s encouraging that people feel the Integra Live GUI looks appealing and want to emulate aspects of it, I think that focusing on the graphic effects is missing the point about the nature of good design.

Specifically:

• User interface design is primarily about how things work
• Visual appearance should be used to enhance function and user experience

I think there are basic problems about the Pd UI that could be addressed without a new framework and code rewrite. I have therefore conducted a brief user experience study on Pure Data partly as a personal exercise, partly to illustrate how much could be done without rewriting the application. My method was to simply download Pd and identify as many user experience issues as I could in 30 minutes.

The results…

Download and launch

• The website is very text heavy, and I’m confused about the difference between “Downloads” and “Featured Downloads”
• Clicking “Downloads” — I’m presented with “Pd-extended” and “Pure Data”. I’m not sure which one to pick, but go for “Pd-extended” since it is at the top, is bigger and claims to be “easy-to-install”
• When I download the DMG I get big intimidating license to read — I just click “agree” without reading it
• When I double-click the app, I get a warning:

I know a way around this, so I ctrl-click and select open…

In Use

• There is no initial call to action when I launch the application

Menus

• When I launch the About dialog, the window appears on top of the Pd console, obscuring the Pd Console title bar

• The Preferences panel also appears on top of the Pd Console, but this time, up and to the left, obscuring the Console title bar:

• The Preferences dialog itself is not clearly laid out. Due to the placement of buttons and checkboxes, I’m not clear which controls relate to “Startup flags” and which relate to “Paths”

• It is unclear why the dialog has “Apply” and “OK” and when I would need to click each one
• When I click “Reset to Defaults” the dialog just closes. When I reopen, a number of paths have been added to the dialog. I wonder if these are the defaults, why they weren’t there in the first place. Also, I’m not clear as to why I need to know about these paths.

• When I select “New” from the “File” menu, I get an empty window, which again obscures the Console title bar, this time the Window is positioned in the top-left of my screen
• Again, there is no call to action

• Experimenting, I discover that windows always appear in the top-left corner of the screen regardless of where the previous window was. This causes frustration because I’m constantly moving windows to compensate and resizing as the default size is too small. A quick look through the Pd help files suggests the average Pd patch size is far larger than the default patcher window size
• I notice neither the Pd console nor the patcher window respond to double-click on their title bar by minimising (the standard behaviour on Mac OS)
• Selecting “Media” and “Test Audio and MIDI”, a patch loads, but it looks jumbled, and I notice the Pd Console fills up with errors:

• The “Audio settings…” dialog is unclearly laid out (no vertical alignment?), and I’m unclear what “use callbacks” and “Delay” mean

• The Audio and MIDI settings dialogs have two buttons at the far left of the window title bar, but they are greyed out and not-clickable
• I’m again confused by the function of “Apply” vs “OK” buttons
• The font size dialog is not a native font picker, and I’m confused by the meaning of the “Stretch” function

• All of the settings dialogs seem to be non-modal, but I’m not sure why I’d want a settings dialog open whilst operating the main application
• Selecting the “Help” menu, I get a native “Search” field, but I can’t type in it
• Selecting “Help Browser”, I get a non-native help browser

• The Help system itself is confounding. Selecting “Manuals” then “+ Start Here” then “+start-here.pd”, I get Pd patch with some errors in

Patching

• I decide to make a test patch to confirm Pd is actually working
• I create an object, type in the object name and hit enter. I expect the object to be created, but enter inserts a newline instead. I wonder if any objects make of this newline feature…
• Adding a [dac~] object doesn’t work, I get an error. So I restart Pd

• This time dac~ works and I create a test patch with an simple oscillator and amplitude control
• My patch is a little messy, so I select “Edit” -> “Tidy Up”. This does nothing except throw the error: “best vertical distance 4” in the Pd Console

• I wonder why there isn’t a keyboard shortcut for “Tidy Up” when it may be a common operation
• I arrange my patch until it is nearly tidy, and try “Tidy Up” again

Before:

After:

TIME UP!

Conclusions

I’m sure there are many more UI issues than the ones I’ve outlined here. This hasn’t been an in depth study, but a rather haphazard one. It is also a matter of subjective judgement as to whether some of the points I’ve raised are good design, bad design, or simply bugs.

I’d wager at least half of these points are a matter of frustration and / or confusion for the majority of users, and are simply a matter of bad design, or just a lack of design. Many of the issues I’ve raised may also seem rather minor, but this all adds up.

There are also many good things about the design of Pd’s GUI. It’s clean, concise, simple and portable. I think significant work has probably gone into it.

Which leads me to my conclusion: it takes a lot of work to write a UI, and it is certainly easier to improve an existing UI than start a new one from scratch. So, if the Pd community is seriously going to embark on another GUI rewrite, they need to make sure that they get the design details right. And by that I don’t mean fancy bezier curves and gradient fills, I mean making sure the basic user flow is good and that everything is clear and purposeful.

There are also user experience issues to consider. There are already two versions of Pd (Vanilla, Extended) on the main website, and a bunch of UI plugins. I don’t think adding another alternative will improve user experience, so if a GUI rewrite is undertaken, for good UX, it needs to become the Pd GUI.

Final Words

Building software is fun, but doing it well is really really difficult. Any attempt to rewrite the Pd GUI needs to be certain that it will actually be an improvement and not just an equally unusable version with rounded corners and gradient fills. Its important for those involved to understand that simply adding visual effects to Pd’s GUI isn’t going to improve the design. The design will only improve if issues of user flow, clarity, learnability and discoverability are addressed and aesthetics are employed to enhance meaning and improve experience rather than simply being a veneer. By contrast, there are many many design issues that can be addressed in Pd without rewriting the GUI at all.