Designers are developers

It’s common in the web and app development industry for stakeholders to make a distinction between “designers” and “developers”. One of the things I’ve noted about this distinction is that it opens the door to antagonistic perceptions and even behaviors between the two camps. At a conference a few years ago, in the presence of developers expressing disparaging views regarding designers, I suggested that, “Designers are developers.” The deafening silence suggested I had to explain what I meant:

Continue reading “Designers are developers”

What is a single-ended amplifier?

Single-ended amplifiers, whether made with triodes (as in the single-ended triode, or SET, amplifier), pentodes, or solid state devices, entered the high-end consumer audio consciousness a couple decades ago, and they continue to have a particular pull for a certain camp of audiophiles. This may lead some of us to wonder whether these folks are onto something that we should pay attention to.

However, there seems to be some confusion regarding what exactly single-ended amplifier are. So I thought I’d try to clear things up a little.

Continue reading “What is a single-ended amplifier?”

Displays for classic Arduinos

Arduino driving TFT display

You often hear that to work with graphic displays on the Arduino platform you need to use a Mega or other high-performance board. I got curious about how much you can actually get done on an a measly Uno and similar boards based on the classic ATmega328P. You can find the ongoing results on my wiki.

The story so far: 128×64 and smaller monochrome displays are usable. The smallest TFT displays much less so.

Open source for equitable futures

neon open sign

With the mainstream shift away from desktop to mobile devices, it seems the relevance of open source ecosystems is diminishing. The two major mobile OSes have a very effective grip on the mobile OS space, and they have engendered app models that do little to encourage or motivate open source designers and developers. So now might be a good time to remind ourselves of some of the benefits that open source confers. Continue reading “Open source for equitable futures”

AVA preamp chassis

AVA “SLR” remote controlled preamplifier chassis

A recent chassis redesign project I undertook for Audio by Van Alstine is now in production.

This project pushed “constraints as creative resource” to the limit. The client specified that the design language and elements from the product’s predecessor be maintained—down to the knobs, faceplate treatments, and typography.

The project brief revolved around electronic and industrial design work to bring the client’s preamplifer platform up to functional parity with current market offerings within a framework that fits with the client’s existing manufacturing capabilities. The result is a platform that is significantly more capable than what it replaces yet easier for the client to manufacture. It is also amenable to comprehensive appearance changes if and when the client deems the timing is right.

So while it might not seem there’s much innovation on the outside, there is a lot of innovation for the client on the inside.

HTTP API apps: Part 1

code screenshot

Way back near the turn of the century, Winamp was one of the coolest things around. One of the things that made it cool was plugins, and one of the coolest plugins was one that provided a Web interface. Not only did it let you control your Winamp remotely, but it also had decent interactivity, like a nice indicator of remaining track time, etc. To get the client-side job done, it used plain old HTML, CSS, and JavaScript rather than Flash. And this got me thinking: Why not use HTML, CSS, and JavaScript for the UI for apps in general?

Now I’m sure I wasn’t the first or only person to think this, but the idea of using Web technologies to build desktop apps didn’t really begin to gain much traction until fairly recently. Frameworks like NW.js and Electron, on which GitHub’s Atom and Microsoft’s Visual Code are built, do just that. But they’re not not quite the same thing as what I had in mind: implementing an app as a server that all sorts of different kinds of UI clients might interact with, including those built with Web front end technologies.

Here’s what I mean. Below is a diagram of what Electron and similar frameworks do:

Conventional hybrid app architecture

In this model, the user interface is rendered inside a dedicated environment provided by the framework using whatever HTML, CSS, and front-end JS frameworks you desire. The UI is tightly bound in a one-to-one relationship with the app engine. The app engine is implemented with a Web back-end language, typically Node.js, and it makes system calls through the engine’s baked-in features or, if the baked-in features don’t do what you need, through generic child_process.exec()-like calls that then invoke custom functions written on the host.

What I’ve got in mind looks like this:

Alternative hybrid app architecture

In this model, the tight UI↔app engine binding is replaced by a flexible REST API binding, and the app engine is simply a REST server embellished with whatever libraries are needed for accessing the required host resources.

The UI can be implemented with any kind of client that can speak the API, including HTML/CSS/JS clients, native mobile clients, terminal clients, etc. The REST server can be implemented in any language on which a REST server can be built. Thus the language the “app” is written in can be one that most easily supports the necessary system interactions or is otherwise best-suited to the app’s requirements. Also, unlike the conventional architecture, the client need not be local, which makes remote-controlled apps almost trivial to implement. As with any network-based communication, adequate measures must be taken to assure secure communication with the REST server.

So a few vacations ago, I set out to see whether this approach was actually workable. Because I have a high threshold of abuse, my test case wasn’t going to be some self-contained desktop app. Instead, I created a mini research project to study this architecture in the context of  real-time control of a physical appliance. (In reality, this was relevant to some other research I was doing. My tolerance of abuse had little to do with it.) The appliance I decided to prototype was an audio preamp with screen-based control.

This is where I ended up:

It’s not much to look at, but there’s a fair amount going on under the hood — which I’ll talk about in a future post.

But for now, that’s all my stories.

Update: An updated description of the system architecture is available in my wiki.

I write therefore I’m improving

According to Fast Company, John Madea is positing that writing skills are important for design because many interactions still depend on text. I’d like to approach this from a different angle. What I’ve found in my personal development is that the better command I develop over my natural languages, the better everything becomes. Visual thinking, musical thinking, engineering thinking … everything.

Some people have described my approach to design as linguistic. In addition, I think of coding primarily as an extension of linguistic skills. So the apparent close relationship between natural language skills and other skills might just be me. But since language is such a core part of how the human mind works, it could very well be universal.

So, yeah, writing.