Playing with Patchblocks Synth Modules — or: Lessons in User Experience

7,700 words • 40 minutes reading time

TL/DR: Detailing my frustrating user experience with a new Patchblocks synth module and the editor software that comes with it. Many suggestions and ideas on how to fix the issues. Using Patchblocks as an example, because the experience is very fresh, but my observations and advice apply to lots of products, both hard- and software. I think there are a number of generally useful take-aways in this post, particularly if you’re new to user interface/user experience design.

A few months ago, I bought a patchblocks synth module. Here it is, next to its box, on my desk:



What’s patchblocks about?

Patchblocks modules are programmable little boxes that can do all kinds of sound/synth/audio generation and processing tasks. You can chain several of them together to build more complex setups. There is a cross-platform graphical user-interface (GUI) application with which you can edit the patches that can be uploaded to the patchblocks.

Patches remain on the modules even when they are disconnected from the host computer (or from their power supply). That is, you use the editor software to program the modules, and then you’re free to take them somewhere to make music or manipulate sound — no computer connection needed.

The concept is very similar to that of Arduino, but designed to produce or manipulate sound, to be chainable, and with two buttons and knobs each to get your hands on.

If you, like me, like to play both with programmable devices of this kind, and with synthesizers (or sound and music, in general), Patchblocks are a great idea. The hardware is nicely designed and quite affordable. You basically get a tiny, but fully capable synth and audio processor for about 50 €.



I was prompted to write this post when I had a very frustrating user experience trying to use a Patchblocks module and the editing software that goes with it.

I’d like to point out that I’m not trying to blame Patchblocks in particular for any of the things I write about in this post. They apply to many products and services.

In fact, Patchblocks is a small company run by people that I can relate to. I like what they are doing and have no reason or incentive whatsoever to point them out specifically for any particular problem.

It just so happened that I decided to write about typical user experience issues after I failed getting this product to properly work, using it as an example.

Initially, I published this post before talking to Patchblocks about these issues. That was a bad move, and I apologise (though I would have written this post anyway). I have notified the Patchblocks team about the post on 2017-02-17.

Also, the post was originally much more of a rant, written in a tone that was often inappropriate. I have rewritten it several times into what is now, I believe, mostly neutral and constructive criticism.

If you have any kind of feedback, I’d love to hear it. Please simply leave a comment below. Thanks for reading!


Diving Right in — and Hitting the Ground

Once unpacked, I wanted to get some sound out of the module right away. So I connected the USB cable to my Mac (for power supply) and plugged the (presumed) audio-out into my audio mixer using the supplied mini-jack cable — and got … no sound.

Hmm. I’m twisting the knobs and pushing the buttons. Do I just have to turn the volume up? (I realise that the hardware controls are programmable, so they may not do what I think they do, but I’m just fiddling around, trying to get sound.)

Aha! There are two mini-jack connectors on the board. Both are unlabeled, which is strange, because everything else on the board is labeled, down to the tiniest surface-mount components, except those two jacks. (Why?)

So, which one is right? Are they both audio-out, or is one a line-in? Do they even carry audio signals at all?

At this point, I would already have needed to check a manual or look at videos or google for information. I hate checking manuals (as most people do). Frustration sets in. I’m even wondering if my patchblock is defective.

The only indication as to the module’s health is its power LED, which is alight, so the circuit is apparently getting power. I’m concluding that it’s not totally dead. Everything else is left for me to guess. (By the way, my model is a Macaque 1.2.)

UI/UX (user interface/user experience) suggestion: Label the connectors to make it obvious where the audio comes out.

UI/UX suggestion: Add some kind of indicator (another LED?) to the device to signal to the user that the device is producing sound right now. In this way, users can be sure that they should be getting sound.

Then, if the indicator is on, but there is no sound, there must be something wrong with cabling, or the signal path outside of the device. Without such a guide, users are forced to do more in-depth troubleshooting.

I tried different combinations and kept twisting knobs and pushing buttons, but I never got any sound out of it.

My next guess was that maybe you first have to upload a sound patch to the device, via USB, using the free Patchblocks editor software. That would be a huge missed opportunity: why not upload a demo patch to the device as a factory setting, so people can play with it right away and have fun?

UI/UX suggestion: Provide a demo patch, so people can play with the patchblocks module without first needing to hook it up to the editor software.

At the time, I had lots of other things to do, and I wasn’t in the mood to install and setup new software. I had a module that apparently wasn’t working properly, and no obvious way to find out what’s wrong.

I put the module back into its box and shelved it. That was about three months ago.


Trying … and Failing Again

Fast forward to February 13, 2017 — I unpacked my patchblocks synth again. This time, I downloaded the editor software and installed it. That was easy enough.

For macOS, it comes in a standard disk image that auto-mounts after finishing the download, with a symbolic link to the macOS Applications folder, where you just drag the app so that it’s copied, and that’s it for installation. This is a best practice on macOS.

A digression (it’s really minor): there are two readme-type text files included in the mounted installation disk image as well. From my experience, barely anyone reads them or even looks at them.

I took a quick peek — there didn’t appear to be anything that would require reading in order to launch or start using the app. (Which is too often the case, explaining why people would tend to ignore these files.)

UI/UX suggestion: If you provide readme-type files next to your installation files, they should contain stuff users absolutely need to read before installing or launching the app. (That text should be as concise as possible.) If they don’t, get rid of them. You can put any such info in the app itself, where users can look it up if they so desire.

UI/UX suggestion: The best option is if users don’t have to read anything before they can start using your app.

When I tried to launch the app, I got a warning message saying that launching was prevented because it’s an unverified application (this means that it was not code-signed with Apple).

This is mentioned on the download page, with a short note about having to unblock it to get it to launch. But it doesn’t say how.

I know how because I’ve done it many times before. But many users may not, so there’s another stumbling block. Those users are forced to find it out themselves. Why not provide this help?

UI/UX suggestion: Provide simple instructions on how to bypass Apple’s security lock and get the app to launch. All it takes is a few lines of text and maybe two screenshots as guidance.

(This is how: you need to launch the System Preferences app, go to the Security pane, switch to the first tab, and there’s a bit that says Application XYZ has been blocked from launching due to blah-blah, next to a button labeled Launch it anyway. Just click that button; that’s it.)


Exploring the Application’s User Interface

The app launched into a small window with just two huge buttons:


Ah! Nice and simple. But what do the buttons do?

The text labels are descriptive enough — even though they imply that a preset and a patch are two different things, which, it seems, they aren’t (more about this below) —, but the illustrations are weird.

The Load Preset button shows a stylised drawing of a patchblocks module. What’s that supposed to mean? It’s like putting an image of a car next to the button that starts the engine.

It seems to say I wanted to put some kind of image here, but I didn’t really want to think about what would be a good choice, so I just used… anything.

The wrench on the right is more indicative of what’s behind that button, even though a wrench is something that you’d normally use to fasten or fix something. I wouldn’t associate a wrench with creating a patch.

Also, the wrench image is only ever used on this button. The related New Patch toolbar function in the patch editor interface (see below) uses a completely different icon. Again, it seems really arbitrary.

Maybe the drawings are just for fun. They’re not meant to be good, self-explanatory icons. Maybe they’re decorative. But it’s mentally distracting that I have to think about this, even just subliminally.

The question that settles it is: Does the user interface profit from using these images at all?

These are the kinds of little things that start off thoughts in users’ heads, and if those thoughts add to the confusion instead of clarity, it hurts the experience. You’re distracting the user instead of guiding them.

As for this interface, I am pretty sure it would have been better to leave those two illustrations out entirely. If they’re mostly decorative or humorous, I’d expect that style to be repeated across all of the application, but in this case it isn’t.

(Yes, this is really sweating the details. These details can make the difference between a mediocre user interface and a good one.)

An alternative: Use a more generally accepted and understood pictogram or icon. For example, loading a preset would map to the notion of opening a document, whereas creating a patch would map to creating a document. (Those icon examples aren’t too great, either, but they’d be less startling.)

UI/UX lession: If you want to add illustrative or descriptive imagery (icons, pictograms) to interface elements, make sure that they are meaningful, that they actually convey the intended meaning, and that using them is advantageous over not using them.

If you can’t find a well-matching image, it’s preferable to use no image at all. Purely decorative imagery has a tendency to increase visual clutter — the presence of too much (or too dense) visual information that makes it hard to maintain focus — and there is a good chance you’ll end up distracting or even confusing your users.

I’m still very unsure as to why these two buttons are there at all. There must be a fundamental difference between loading presets and editing patches, otherwise I wouldn’t have to make this choice at this point.

I have no idea what that difference could be, and there is no explanation. I’m left to guess.

Let’s try Load preset. It takes you to a second interface:


The Preset Loader


Okay! Clicking on the presets, I expected — hoped — finally to hear some sound out of the little device. But nothing happens.

There’s a Play button at the top. I guess I need to click it. (Why? Isn’t it obvious that, when you click on a preset, the first thing you’d want to do is listen to it?)

UI/UX lession: Anticipate what the user is most likely trying to do, and make that as easy and obvious as possible. Avoid making the user do more than what absolutely needs to be done. In general, avoid making the user think.

Finally, I can hear sound!

It takes me a while until I realise that the sound is not actually coming out of the patchblocks device. It’s coming from the editor software and playing through my Mac’s audio-out. The module is still mute. Bummer! What am I doing wrong?

Also, why do I have to check my audio mixer to find out where the sound is coming from? Wouldn’t it be helpful if the interface made that explicit? If sound is coming out of both software as well as the module (I can’t tell), that may need pointing out as well, because it’s not that obvious.

Ok, so maybe I need to upload a preset (patch?) to the device first. If that’s so, why doesn’t the interface provide a hint about it, and instead lets me guess what I need to do?

UI/UX lession: Provide explicit information to the user about any functionality that does not immediately explain itself.

A good method is to place yourself in the position of someone who sees your interface for the very first time and has no idea what’s going on. Would you know what you need to do? If not, change the interface, or be explicit by providing some kind of guide.

Right, there’s a Load to Block button.

Why load, not upload? Why is the synth module called a block here? The package says Synthesizer Module, but the application keeps talking about blocks. Are they the same thing? If not, what’s the difference? Why use different names? (I’ll get back to consistent terminology.)

And why does the icon show the outline of a patchblocks module with an arrow pointing downward, which I’d associate with download?

Anyway, I click it. I get an error message that the device could not be found. How so? It’s connected via USB, and the module’s (block’s?) power LED is on, so it’s not a trivial connection issue. What is it?

It would be helpful to get some kind of hint what to do about this issue. As it is, all I can do, once more, is guess. (Sure, I could find help elsewhere, but then you’re making me do work that I shouldn’t have to be doing.)

UI/UX suggestion: Provide guidance on how to properly connect the module with the host computer.

You’d think how hard can it be to connect a USB cable? Does that really need explanation? But consider that some USB devices must be connected to the main USB hub and don’t work properly when they’re connected to, say, the USB connectors on a keyboard. Be explicit.

Why does this have to be so frustrating? It’s not so much that there are issues — these things happen. It’s that I’m not getting any help whatsoever; I’m left to figure these things out myself. If I need a manual to figure out even basic setup, something’s not right.

I try the classic fix-it-all: I unplug the patchblock from the USB and plug it back in. Nothing happens.

UI/UX suggestion: Provide some means for the user to tell if and when the device is properly connected to the host computer, and accessible to the editor software.

Without such a guide, users are forced to guess what’s going on. It could be faulty cabling. It could be a problem on the USB driver level. It could be a problem with a configuration setting. Basically, it could be anything.

(It’s easy to overlook the most likely reason: The user hasn’t actually plugged their module in. People make stupid mistakes all the time. We’re only humans.)

When you’re leaving your users on their own to figure out the problem, you’re sending implicit messages about your attitude towards the design of your application:

  • We didn’t anticipate this sort of issue (because we did not think about it enough?), and
  • We didn’t perform any user testing to check for it, or
  • We did these things, but we didn’t bother to do anything about what we found.

The take-away is this: do you care about the experience your users will have with your product? (If you don’t care, what does this say about your business?)

Ok, now when I click on Load to Block, I get a Firmware updated! message. Apparently, the software recognised the patchblock after all — though I’m still only guessing, as there’s no way to tell.

That message is confusing, too. I’m not sure what kind of firmware it’s talking about. (By the way, are you sure that all of your users know what firmware even means? My hunch would be yes, but that could be an incorrect assumption.)

So did the app just run an update of the module’s basic firmware — i.e. its operating system? That was actually my initial thought. I was pretty sure that if it meant to say it uploaded a preset, it would have said so. Again, I’m left to guess what is really meant.

UI/UX lession: Provide explicit feedback to the user, using straightforward language. (In particular, avoid assuming that your users already know your internal terminology. New users almost never do. They cannot learn it by guessing, either.)

Instead of saying something technical and ambiguous like Firmware updated!, you could say Success! The patch/preset was uploaded to your patchblocks module. That would be so much more obvious, and it just takes a bit of thought and a few more words.

Clicking around in the preset loader UI, I find out that I get sound — out of my Mac, not out of the patchblocks module — for some of the presets, but nothing happens for some of the others. There’s no apparent reason why, and no indication to tell.

By now, I’m aware that the Patchblocks software has some major conceptual and design issues, as well as what appear to be significant bugs, so I’m kind of ignoring this issue for the moment. I realise that I’m already expecting things not to work by now. That is a pretty bad road to be going down as a new user.

When changing a preset, I was expecting to hear a different sound immediately. Instead, I had to click on the play button twice. Once, to turn off the previous preset. A second time, to turn on the newly selected preset.

That is, to check out a new preset, a user is forced to do three clicks where one would suffice. If there’s a legitimate reason for this behaviour, it’s definitely not obvious.

UI/UX suggestion: Auto-play a new preset on change. If there is a reason that presets have to be stopped and started after change, it’s not immediately clear, so it needs explaining.

You may have noticed in the screenshot that there is a preset selected, but that selection is not highlighted in the preset list. (This is probably simply a bug, but I’ll mention it for completeness’ sake.)

UI/UX lession: If an interface element has a state, such a selection, it’s a good idea to visually represent that state as feedback to the user — for instance, using a change of colour.


My Impression so Far

Meh. I haven’t even seen most of the application yet, and there was already so much to stumble over. A lot of things don’t look like they have been thought through very much, if at all.

Is this application even finished, or is it in a non-final stage of development? Did the developers perform any kind of user testing?

At this point, I’m frustrated enough to give up, but the fact that at least I got some interesting sound out keeps me going.

I click on the top right button that says Switch to editor. This takes me to…


The Patch Editor


Holy cow! That’s a big window. On first glance, there is a lot going on, but why are there all these sections with nothing in them?

The screenshot shows its contents after I loaded an example patch. Initially, there is no patch loaded, so you’ll see a big window that’s even more empty, leaving you wondering what’s happening.

UI/UX suggestion: On switching to the patch editor, pre-load a simple patch to make it obvious how to use the interface. One of the tutorials would appear to be a good choice.

Glancing around in the patch editor UI, most of it is sufficiently self-explanatory, but I’ve used similar graph-based patch-editing software before, so it takes me only a few minutes of playing around until I get it.

For other users, this experience may be very different. How do you find out if users will understand your interface? The best way is to test it as much as possible, with real users, preferably ones who haven’t seen it before and don’t know anything about it.

UI/UX lession: Perform user testing to find out if a user interface will work.

Hoping for an interface to be successful is almost guaranteed to fail for all but the most elementary interfaces. (I’ve learned this the hard way.)

Improving the Patch Editor Interface

There are many things to improve upon in the patch editor, but they are rather minor compared to the other issues.

Reduce clutter

Right from the start, the user is presented with no less than seven sections or panels:

  • a toolbar,
  • a nodes browser,
  • the editing workspace,
  • an inspector,
  • an emulator,
  • a console,
  • and a help area.

While it becomes obvious rather quickly what each of them are for, a suggestion would be to hide/show editor panels based on the current editing context.

For example, there is no need to show the console until there is actually console output. Likewise, there is no need for the inspector or help while there is no active selection in the workspace.

As you can see in the above screenshot, many panels are completely empty, not only wasting space, but consuming a part of the user’s attention before it’s necessary.

Give the Window the Room it Needs

The patch editor window appears to open up to a fixed size, which is too small to see all of the workspace, so users have to pan around. While this can’t be avoided on smaller screens, an easy optimisation would be to let the window grab as much space as it can.

It’s a sensible default used by almost all productivity software — that is, anything that entails some notion of a document workspace. There’s nothing to lose. Users can always make the window smaller if they so desire.

I’d recommend not to go truly full-screen (i.e. make the window contents fill all of the screen, hiding the operating system chrome) — this would only be acceptable for immersive applications such as games.

Center All Windows on First Launch

All of the app’s windows initially open up somewhere near the top left corner of the screen, apparently with a fixed offset. On large monitors in particular, this is distracting. A much better choice for initial window placement is to simply center the windows onscreen.

Use Self-Explanatory Icons

Looking at the toolbar, it’s not immediately clear what at least half of the buttons do. New Patch and Play are pretty obvious; Open and Save a little less so. (How many people nowadays still associate saving with the image of a 3,5″ disk? That technology disappeared about 15 to 20 years ago!)

Helpfully and thankfully, the developers provided tooltips that appear on hovering the mouse pointer over the icons. But why would you use icons that force your users to do work to find out what they mean? Doesn’t that kind of defy the point of having icons in the first place?

Suggestion: Use icons that explain themselves immediately.

Alternative suggestion: Use icons with text labels next to them, and allow users to hide the text labels once they learned what the icons mean.

(By the way, you used icons with text labels in the preset loader, so why not in the patch editor? Not only would that be more consistent, it would also solve this issue.)

I can see why you’d remove the text labels in the patch editor’s toolbar: to save space. But you’re not very space-conscious about the rest of the window’s contents, and letting users guess what the icons mean — so you can save space in the toolbar — seems a bad trade-off.

A solution for the space problem would be to allow the toolbar to wrap into two — or more — rows, if the UI framework provides this. That’s not very elegant, either, but I think there’s a way to avoid the problem entirely:

Move Login Fields Somewhere Else

Why are there login fields in the toolbar? They’re not tool functions. Is it necessary for the user to see them all the time? Wouldn’t a user either be logged in or out? But if they don’t want to login yet, does it help if they permanently see those login fields?

Suggestion: Move login fields to a separate dialog/window/panel, and replace the Login label with a login/logout button.

Not only would this save lots of space, it would also make the interface much cleaner. With their white background colour, the login fields are quite distracting. The high contrast causes them to get much more visual focus than what seems appropriate.

Strive for a More Native Look-and-Feel

The app is built using some cross-platform UI framework or environment (my guess would be Java) that feels somewhat alien. Personally, I’m probably overly sensitive to this; other users may not care much.

Anyway, this is tough to solve. It’s very challenging to build cross-platform GUI apps in such a way that they feel at home and elegant on each platform.

Once an app is built, there is no strong business case and thus very little incentive to change the foundation on which it was built — it would likely require a re-write of large parts of the code.

Maybe there was a good reason for choosing that foundation; maybe it was the only realistically available choice. There’s no point in arguing for or against any such choice now.

(I wrote a post about the problems with cross-platform UI layers and ideas about how to write a new platform-independent UI layer from scratch.)

Simplify Editing Text Frame Content

When editing a text frame in the workspace, the text turns into HTML.

I’d always prefer editing HTML over rich text, because HTML is more open and standardised. But there are no editing controls, and having to write HTML by hand is probably less than user-friendly:

  • Users have to know HTML.
  • They have to type HTML code manually, which is inefficient and inconvenient.
  • HTML is much richer than it needs to be — you’ll probably have to do quite a bit of post-processing of the input to filter out things that shouldn’t go into those text frames.

From the patches I’ve looked at, it appears that you’d need at most the following structural options for those text frames:

  • Plain body text
  • Two kinds of text emphasis (bold, italics)
  • One to three levels of headlines
  • Possibly bulleted/numbered lists
  • Links

If you add code sections, blockquotes and images to this, you have exactly the expressive power of Markdown. It’s a very simple text markup language that looks very much like regular plaintext, but can be transparently and efficiently converted to HTML.

(An implementation in PHP using only basic string handling and regular expressions — no external dependencies — takes about 40 kB of code.)

That HTML can then be styled using CSS, as before, but Markdown is much more approachable for your users, and you’ll probably need less code to handle it. Seems like a double-win.

Use a More Elegant Typeface

This is more a matter of taste than a UI issue in any sense, so I’ll just add it as a remark. There’s nothing wrong with geometric sans-serif typefaces such as Futura, but I think they look very awkward and clumsy when used for application interfaces.

I’d bet that most professional [user interface] designers would agree with me on that. Futura was designed in the 1920s — maybe that explains why it feels so out of place.

However, Patchblocks (the company) use Futura as a corporate typeface, and it’s generally a good idea to be consistent and use it everywhere.


Trying to Make Things Better, but Ultimately Making them Worse

Scanning the patch editor UI, I wonder what that strange button in the very top right of the toolbar is for. The icon hints at some kind of exchange.

Ok, the tooltip says it takes me back to the preset loader interface, and now I remember where I’ve seen it before.

So, there are actually three interfaces, in three separate windows:

  1. An initial small window to select between the low-complexity preset loader interface and the high-complexity patch editor.
  2. The preset loader.
  3. The patch editor.


Now that I’ve seen the patch editor, I realise that the preset loader doesn’t do anything that the patch editor doesn’t do as well, it just does less of it. Why do you need the preset loader, then? Is it not redundant?

Maybe I’m misguided, because until now, I’ve silently assumed that a preset and a patch are actually the same thing. At least there is nothing in the user interface that makes a difference explicit, so I have reason to believe my assumption is correct.

If patches and presets are the same thing, why use different names?

UI/UX lession: Use consistent terminology. The same kind of thing should always be identified by the same name. If you use different names, but don’t make it explicit what the difference is (is there any?), you’re causing confusion.

Earlier, I’ve stumbled over the apparent difference between a module and a block. It looks like they’re both the same — why not choose one name and use it consistently? The same applies to patches vs. presets.

Assuming that patches and presets are indeed the same thing, the application provides two separate interfaces that operate on the same object. And it’s not at all clear why, other than that one is simpler. It’s simpler because it only provides a subset of the possibilities of the other, but it still duplicates all of those possibilities.

Why would you choose to do that? My guess it that the designers of the Patchblocks app tried to make things easy by initially hiding complexity. While that’s generally a good idea, in this case, I think, it backfired — it made things worse.

When the app is launched, the user has to choose between the preset loader and the patch editor — but at this point, it’s not at all clear what the difference is. The user is forced to make a choice between either interface before they have the knowledge required to make that choice.

But even after seeing both interfaces, the difference isn’t obvious.

I may be overlooking something important, but if I’m not, there is no need for a separate preset loader at all. If that’s true, there’s no need for the initial two-button window either. Finally, there’s no need for a button to switch interfaces.


Good Riddance

UI/UX suggestion: Get rid of both the initial two-button chooser and the preset chooser interface, and instead just keep the patch editor.

The advantages are immediately obvious:

Users aren’t confused by initially having to choose between two separate interfaces before they even understand why those two separate interfaces exist. Win.

Instead of having a separate interface for patch loading, add a patch selector to the patch editor. (It already exists, by the way, but it’s hidden in the menu. More on this below.)

The single biggest missed opportunity is this: When selecting a patch (or preset), the patch would be loaded into the editing workspace. Users could immediately make a mental connection and see how the patch was built, and more quickly get an idea of how the patch editor works. Huge double-win.

You can get rid of an entire interface window — the preset loader — that confuses users and duplicates some parts of the patch editor interface. Much less confusion, much less code. Major double-win.

You can get rid of the now redundant two-button interface chooser window. Less confusion, less code. Mid-sized double-win.

You can now also get rid of the Switch Interfaces button in the patch editor. Again, less confusion, less code. Small after-dinner snack double-win.


Selecting Patches

It would seem that choosing patches is likely the most frequently-used operation in all of the application. It would have to be, if the separate preset loader interface was dropped.

However, to select a patch from within the patch editor, you have to click a menu — one of two menus, actually — containing sub-menus that contain the selectable patches.

This is bad in several ways:

  • Menus hide interface options — you have to click on a menu before you can see its contents.
  • Sub-menus make it worse — they hide content even deeper, and you need more clicks or mouse interactions to navigate the menu structure.
  • Having two separate menus implies that they contain fundamentally different items, but they are actually just two categories of patches — examples and tutorials.

(The last point looks like this was an attempt to avoid having a patch selector menu with two levels of nested sub-menus, but it’s still inconsistent and confusing.)

So, users are forced to dig through an intransparent menu structure that is effectively hiding something they would likely need quite often. At the same time, the patch editor window permanently shows interface sections that seem much less important (login fields, console, help).

That doesn’t make any sense.

If we have seven panels in the patch editor already, another one wouldn’t hurt much. Why not add a patch selector panel, so patch selection is the first thing users see in the patch editor?

UI/UX suggestion: Move the patch selector out of the menu into an a new panel within the editor window. I can imagine that a full-height vertical panel at the left edge of the window makes the most sense.

To replicate the menu hierarchy, you could re-use the accordion-like control that you used for the nodes browser — it’s a good choice to present sub-selections.


The Workspace is Fun (The Good Parts)

There are a lot of very unfortunate choices in the application’s user interface. It’s time to mention what works well.

I really enjoyed the workspace. If you’ve ever used a graph-based interface like this before, you’ll be able to work with it almost immediately. The node-graph metaphor is already well established and very intuitive.

I spent quite some time just moving things around in the workspace, and looking at all the different node types and their parameters. It seems a lot of work has been put into this, and from what I can tell, the system is enormously flexible and powerful.

Other than suggesting to use Markdown (or something else that is simpler than HTML) to represent text frame contents, I can’t see how the workspace could be significantly improved.

I did come across a small bug in the graph rendering code: When moving a node very quickly past the edge of the workspace, the connecting line gets stuck outside of the screen, while the node keeps moving with the mouse pointer. (The graph is correctly redrawn once you let go of the node.)

Most patches come with quite a bit of text to read, and could be cleaned up a little. I don’t recall if the workspace provides a grid to which nodes and text frames could snap. Grids are a very efficient and intuitive way to help users clean up their graphical documents.


Patchblocks Still Mute

I still didn’t get sound out of my Patchblocks module, and the patch editor did not help me find the problem either.

As I tried different things to get it to work, I came across two problems that eventually made me give up trying to use the app.


Showstopper Bug Number One

Every time I load a patch into the editor, I get this error message:


Ouch. This looks like a setup issue where the initial setting was bad, rather than an actual bug. It’s probably easy to fix if I look it up online. (Nevertheless, it shouldn’t happen.)

But this is only what I think is going on, from my experience using software and a hunch about what those things it’s talking about could be. I have no clue what the actual message text means, literally.

What is a local block description? How is it different from the one used in this patch? What is it about the audio output that every single patch I load seems to have this problem?

What does it mean that these blocks won’t operate as expected? Does it mean that my module is broken? How? Can I fix it? Why blocks (plural) — can’t the app tell that there is only one module connected?

I don’t mind the issue itself so much as the fact that the error message is so utterly useless, it’s actually insulting. Why didn’t you even make an attempt at allowing a new user to understand what’s going on?

Not only do I not have a chance at solving the issue from reading that error message — it seems to imply that there is something more serious going on. This message is so confusing and irritating, it’s making me feel stupid.

That is you — the developer — making me do your work. It should be your responsibility to make error messages comprehensible without having prior technical knowledge about the internals of a system I am using for the first time.


Intermission: Language Issues

There is a missing period at the end of the last sentence in the error message above. That’s nitpicking, of course. But I’ve only looked at part of the user interface and a small part of the website contents, and I saw at least a handful of spelling and punctuation mistakes.

Those mistakes leave a bad impression. I would never judge someone because they personally make language mistakes. (I make a lot of mistakes in a lot of areas, and I don’t like people judging me for any of them. Nobody does.)

But it’s something else if the content represents a business. Again, you’re sending implicit messages: We’re not seeing these errors (bad), or We’re seeing them, but  we don’t bother to fix them (worse).

The basic message you’re repeatedly sending by not paying attention to any of this is that you don’t care. If you send that message even subconsciously, you’re hurting your business.

UI/UX lession: It’s a good idea to get someone to proofread all of your text content. It’s best to have all text written by professional writers who know the language at a native-speaker level.


Showstopper Bug Number Two (Probably an Edge Case)

I came across another problem soon: The console would suddenly tell me something about having to re-run the app as root (or using sudo) to acknowledge some license restrictions.

Double-ouch! Why is there suddenly a license requirement, and why isn’t there a more user-friendly way to deal with it? (Do your users know how to run an app as root? Do they know how to use sudo?)

But wait — I’ve seen this message before. It comes from outside of the Patchblocks app.

A developer on macOS, who is almost certainly using Apple’s Developers Tools, will probably rarely see it, which is why I think this could have slipped through.

The message originates with said Developer Tools, and it’s only shown if a) you happen to have said Tools installed, b) you’ve installed an update of the Tools, and c) you haven’t used the Tools after that update.

That’s very unlikely for a macOS developer — or probably most people who have downloaded the Tools —, but it was the case on my system.

The fix is easy enough and takes about ten seconds: launch Xcode, and you’ll be asked to agree to the software license, which entails entering your login password.

What I don’t understand is why it would show up in the Patchblocks app’s console. This would mean that the app is internally running some tool — or accessing some system service — that happens to be part of the Dev Tools.

It would imply in turn that the Patchblocks app relies on the Tools being installed. That can’t be right, and there is no mention about it on the website (as far as I could tell from a glance), so this points to some other non-obvious issue.

Even though Patchblocks isn’t (directly) to blame, at this point, I had enough.

I quit the app and put the synth module back in the box. Instead of trying to fix any more problems or understand confusing user interfaces, I decided to write this very long post.


Why not Talk to the Developers?

Why did I not submit an issue report, but write a blog article instead? It’s a fair point. I’ll try to keep it brief:

It’s not my responsibility. Developers or businesses should ship products that work. Waiting for your users to point out and fix issues is an unhealthy business attitude that I reject (as should you).

It’s often futile, or I’m expected to invest additional work, for free. My experience with reporting issues is that they are ignored half of the time anyway, and businesses often expect me to do their work when dealing with issues, such as opening tickets on their issue trackers, or registering for and posting to some forum to get help.

I refuse. This is not an open-source or community effort; it’s a commercial product. I paid for it, and I expect it to work. I refuse to perform troubleshooting, debugging, testing or issue reporting before I can use a product that I paid for.

That said, picking out Patchblocks to make an example out of these kinds of problems seems really inappropriate. It is.

They are a small company that hasn’t been around for long. They probably don’t have the resources or the experience that larger companies have — and I have had much, much worse user experiences with much more expensive products from much larger companies.

If you work for Patchblocks and you’re reading this, let me restate that I don’t mean to pick out your business specifically, and I don’t mean to hurt your business. On the other hand, if you had provided me with a product that worked, I would not have written this post.



The product has serious problems in the user experience area.

As to the editor software, I’d have to say that it’s not production-ready. It appears to be in more of a beta stage of development.

I have no problem at all with using products that are in beta, but if so, I’d like to know ahead of time. There is no such information on their website — or it was too easy to overlook —, so I was led to believe I’m using a finished product.

As a customer and user-to-be, I feel somewhat betrayed, maybe disrespected, possibly both. The issues I encountered are significant enough that I could probably lawfully argue to return the product and request my money back.

It’s true that I did not actually pay any money for the editor software — it’s a free download. But the software is required to actually use Patchblocks modules, so I consider it part of the product that I paid for.

As to my module — maybe it really is defective, which could explain why I’m not getting any sound, or why it’s not reliably recognised by the editor app. Unfortunately, there is no obvious way to tell.

Assuming the module is bricked, how is it possible that faulty modules can reach end users? Do you not perform hardware tests before shipping?

Could it be that I did something to break my module inadvertently? If so, should there not have been an obvious warning to prevent such accidents?

I wish I didn’t have to guess all these things all the time.


About the Author

I’m a designer and developer from Germany, with a focus on user interfaces and user experience. I’m professionally trained in Visual Communications and received a Diploma in that field from Bauhaus University in 2001.

I’ve spent six years abroad while at public schools — three years in Port Elizabeth, South Africa, and another three years in Brussels, Belgium. I currently live in Northwestern Germany.

I’m self-taught in writing, software development and hardware tinkering. I’m also a musician who plays keyboards, some drums and a little bass. My other areas of interest include chemistry, pharmacology, physics, psychology and philosophy.

Currently, I’m teaching myself various fields of programming, including 2D and 3D graphics, game development, user interfaces and operating systems.

Unwilling to submit to bloated and proprietary systems that try to lock in their users, I’m always looking for ways to make things more lightweight, efficient, open and accessible.


Edit history:

  • 2017-02-13, 18:40 CET — Initially published.
  • 2017-02-13, 19:50 CET — Updated to make it clear I’m not critical of Patchblocks specifically, but using their product platform to illustrate some points about user experience.
  • 2017-02-14, 13:10 CET — Updated again to stress some points and add some details.
  • 2017-02-14, 16:05 CET — Updated once again, re-writing some sections to tighten the focus, and adding some more observations.
  • 2017-02-14, 20:30 CET — Fixed some details, re-wrote most of the later parts of the post.
  • 2017-02-14, 22:00 CET — Another edit; trying to make many points clearer, but probably just adding words.
  • 2017-02-18, 00:00 CET — Almost completely rewritten. Changed from a rant to a more constructive criticism. Removed some entire sections that didn’t really belong here. Reduced from 8,000 to 6,500 words. (So far, anything between 25 and 30 hours went into this post. I wanted to spend a maximum of 1 to 2 hours on this, but for some reason I can’t stop working on it.)
  • 2017-02-18, 17:20 CET — Re-wrote large parts once again. Back up to 7,700 words (unfortunately); at least 30 hours of work in total. I think it’s done now.