Oh, drop downs, you cheeky little things!

Photo of code by Ferenc Almasi on Unsplash

Software screen capture

Why is it? Form elements are fully customizable using simple CSS styling except <select> drop downs. Oh sure, you can tweak colors, sizes, fonts, etc. but I’m talking about overriding the native controls and really making them your own. Of course, you can use jQuery, which is an excellent solution in most cases, but sometimes introducing additional scripts can interfere with what’s going on under the hood.

I recently stumbled upon a neat concept, and after a little wrangling, I was surprised to have found a pretty simple way to override the native <select> drop down. Oh, happy day!


Inching Toward Flatland

graphic image of wireframe

The Flat Design Era

A series of posts touching on elements of UI and Interaction Design that have come through my feed reader recently are really resonating with me to the point that I need to write about them. I’ve written here in the past about my distaste for skeumorphic interfaces. I’ve especially been thinking about this as I’m working on a personal music software project, and that industry was soaking its fingernails in the green goo of skeumorphism before the rest of the software development world had even heard the word. Consider products like Reason from Propellerheads:

Software screen capture

Buttons, knobs, faders and flashing LEDs — Reason’s interface looks and feels like an instrument.


Flip the rack over to access the backside with all the cables and connectors. Here you can manually route anything to anything, just like in a real studio.








Make It So: Book & Blog Alert

Image from movie Prometheus, 20th Century Fox

User Interface from ‘Prometheus’

Nathan Shedroff (from the MBA in Design Strategy program at the California College of the Arts) and Christopher Noessel from the well-known interaction design firm Cooper have recently released a new book analyzing the user interfaces shown in science fiction, as well as an accompanying blog to cover material that wouldn’t fit in the book for space reasons, or came out after the release of the book.

Image of book cover

I’ve been following the blog for a few weeks now, and the more material they put up, the more I think that it’s important that these kinds of discussions are put in front of the eyes of as many software development practitioners as possible, for the reasons they put forth themselves:

Being an interaction designer colors how you watch science fiction. Of course you’re enjoying all of the hyperspacey, laser-flinging, computer-hacking action like everyone else, but you can’t help but evaluate the interfaces when they appear. You are curious if they’ll disable the tractor beam in time, but you also find yourself wondering, “Could it really work that way? Should it work that way? How could it work better? And, of course, Can I get the interfaces I design in my own work to be this cool or even cooler?”

We asked ourselves these questions with each new TV show and each new film we watched, and we realized that for every eye-roll-worthy moment of technological stupidity, there are genuine lessons to be learned—practical lessons to be drawn from the very public, almost outsider-art interfaces that appear in the more than 100 years of sci-fi cinema and television. Then we wondered what we would learn from looking at not just one or even a dozen of them but as many as we could.

As developers, it’s important that we both find ways to expand the potential set of problems that we can address with our software, while making sure that those solutions are based in what researchers in the interaction design and HCI fields instead of just aping the ideas created by Hollywood production designers.

The blog is at http://www.scifiinterfaces.com/

The book (either paperback and digital bundled, or digital only) can be purchased from the publisher, Rosenfeld Media.



Friday Linked List (06/01/12)

Blockly screen capture

Three cheers and a tiger for me — today is my 15th anniversary with Art & Logic, and in lieu of a party I’ve decided to dump some links that have collected in my pinboard account:

First, two different blog posts discussing ideas about user interface design. For me, these two posts have been shifting back and forth between agreeing with each other and disagreeing with each other, like an optical illusion.

Joshua Porter (no relation) gives 20 Principles of User Interface Design. Very clean, very sensible.

…but on the other hand, the always-worth-reading Rands looks to the techniques of progressive disclosure and hypothesis-driven learning that are used in games as a guide to user interface design.

Game designers have a different set of incentives to make their tools easier to learn via sandbox and atomically chunked learning. They may obsessively play test their games looking for user frustration earlier, but whether you’re leaping through a portal or creating masks of transparent elements in Photoshop, both use cases strive for a moment where you can cleverly and unexpected solve a seemingly impossible problem on your own.

Game designers and application designers might exist in different universes, but there is no reason one universe can’t teach the other.

Another list-based link from The Twelve-Factor App:

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

I’ve certainly seen a lot of projects going through various degrees of pain that could have been reduced or eliminated had they implemented these ideas.

Lastly — Blockly:

What is Blockly?

A new programming language made up of “blocks” that look like jigsaw puzzle pieces.

What do I use Blockly for?

First, a programmer needs to integrate Blockly with a web application, like Gmail or Google Docs, that you already use. Then you can use Blockly to write simple programs like macros and scripts that work with the web application.

For example, in Gmail, you can use Blockly to create email filters that do things like, “If Bob emails me three times in less than an hour, and each email contains the word ‘deadline’, delete all his emails except the first one.”

The image at the top of this post is a quick thing I threw together with their Blockly demo. Took me about 5 minutes (where I could have written and tested it in Python in much less). On the other hand, it’s very close to the programming interface used by MIT’s Scratch, which my kids both enjoyed using when they were little. It might prove to be a very easy and useful way to add end-user programmability to a system at some point. Their ‘Code’ demo lets you create a program with the Blockly editor and then export it to working code in any of JavaScript, Dart, Python, or XML.