SynapticNulship

As I said in the last post, I appreciate the power of GUI prototyping tools.  And I will definitely use them when appropriate.

However, I still stand by my philosophy that in many cases a good choice is to make a prototype or mockup with the actual visual development environment that the developers use.  For instance, the UX person or GUI designer can mock-up things up with Qt’s Creator without knowing anything about programming.  Likewise with Microsoft tools and pretty much any visual GUI designer.  Then, the developers can immediately use the saved files for the actual development, and no prototyping or GUI design effort is wasted or duplicated.  It’s also a method of communication back and forth between designers and developers.

The downside is that you might not have enough dynamic interactions as you can achieve with a prototyping tool.  Of course, you could use both—mock it up with a developer’s visual IDE, and then use screenshots of that to achieve the dynamic flow in a prototyping tool.

I discussed this with a few of the UX people at the seminar and they did not seem to have though of using developer tools.  It’s as if UX people assume that programmer’s tools can only be used by programmers.  Fortunately, I’m a Renaissance Man so I can (ab)use any tool I want to.

But What about Non-Standard GUIs?

Although I sometimes deal with desktop/WIMP style GUIs, a lot of my GUI design has used an approach similar to many video games, which is to reject any common GUI elements that aren’t appropriate and make custom ones.  I layer and overlap whatever is best for the design, as opposed to being limited to what default widgets and/or a particular GUI framework / editor can do.

For instance, on multiple occasions in the past I have made applications where video is the main focus of the user.  But I wanted various types of widgets rendered over the video.  So, being in the position of a GUI designer and a programmer, on these various programs I made my own OpenGL view which renders a frame of video and renders whatever sprites, etc. are needed for whatever overlayed widgets/graphics are present.

I did sometimes photoshop mockups for these apps.  You could call them “prototypes,” but they weren’t very dynamic since I could only present a small series of mocked-up screenshots.    However, now that there are more prototyping tools (and I’m more aware of their existence), I would consider using them in combination with Photoshop.

In other words, photoshop the custom widgets and/or graphics, and then use the prototype tool to put it all together and to set up the “script”—the dynamic narrative that you will demonstrate with the prototype.

On Friday I attended BostonCHI’s seminar Tools of the Trade: User Experience Research and Design Skills. Since all courses were day-long, I had to choose only one.  My choice was Prototyping Tips and Tools for Effective UX Design.

Here is an embedding of the instructor’s Prezi used during the course.  It’s pretty good, except for the right-brain/left-brain crap, which is a myth.

A few things I learned:

• (meta) Prezi seems to be an extremely useful tool for presentations and/or videos
• CaseComplete appears to be a very useful tool for managing use cases and requirements and traceability between everything, even to test plans.
• FlairBuilder is a pretty good tool for prototyping. You can also use it for wireframing.  Unfortunately, it still has some major bugs (it crashed several times for everybody in the class).  The file format use XML; it’s simple enough to read it manually and I messed around with a bit and reloaded that modified file (the program didn’t choke with my hacked files, even when I purposely did weird things).  Anyway, I like the fact that somebody else could easily write a program or script to reuse one’s Flair files, for instance creating visualizations of how all the elements are connected or activity diagrams.
• FlairBuilder card stacks are very useful.  For some, it’s a new concept; for me, I had fond memories of card stack apps I’ve used in the distant past such as HyperStudio and one I made myself in high school with QuickBasic.
• Prototyping tools like FlairBuilder and Axure are worth using if you need to demonstrate a GUI with lots of transitions, etc. that would take a long time to actually code.

Prototyping may be more associated with web design but I have found it to be useful for other kinds of GUIs.  Indeed, I am not a web designer at all.  But I have no problem stealing good ideas from web design.  In my experience, a working demo is better, but if you can’t do that in time (or if it would be a waste of effort) then prototype or at least make static mockups.

I noticed today that Kyle Munkittrick posted about Sherry Turkle’s concerns about people having emotional attachments to machines (The Turkle Test).

Love at first sight?

Turkle, who’s been at MIT for a long time, is not against machines or emotional machines. She’s skeptical of taking advantage of the human tendency to be social and have emotional attachments to machines which merely pretend to be social or pretend to have other emotional capabilities.

As Kyle says:

Yet these lovable mechanoids are not what Turkle is critiquing. Turkle is no Luddite, and does not strike me as a speciesist. What Turkle is critiquing is contentless performed emotion. Robots like Kisemet and Cog are representative of a group of robots where the brains are second to bonding. Humans have evolved to react to subtle emotional cues that allow us to recognize other minds, other persons. Kisemet and Cog have rather rudimentary A.I., but very advanced mimicking and response abilities. The result is they seem to understand us. Part of what makes HAL-9000 terrifying is that we cannot see it emote. HAL simply processes and acts.

Kyle’s post was apparently triggered by this recent article: Programmed for Love (The Chronicle of Higher Education). Turkle has a new book out called Alone Together: Why We Expect More From Technology and Less From Each Other.

I haven’t read it yet, but it supposedly expands her ideas into the modern world of social technologies. As for the robots such as the aforementioned Kismet and Cog, Turkle’s been talking about them since at least 2006 if not earlier, and Kismet and Cog are ancient history (from the 90s). The Programmed for Love article says Turkle was using Kismet in 2001; it wouldn’t surprise me if that was Kismet’s last experiment before being put in the MIT museum.

Kismet

I mentioned Turkle’s point of view in my article “Would You Still Love Me If I Was A Robot?” that was published in the Journal of Evolution and Technology (it was originally written in 2006 but didn’t get published until 2008).

Image credits:
1. Contra Costa Times
2. Jared C. Benedict

Now published on h+ magazine: my article “Five Ways Machines Could Fix Themselves.” Check it out!

As I see cooling fans die and chips fry, as I see half the machines in a laundry room decay into despondent malfunctioning relics, as my car invents new threats every day along the theme of catastrophic failure, and as I hear the horrific clunk of a “smart” phone diving into the sidewalk with a wonderful chance of breakage, I wonder why we put up with it. And why can’t this junk fix itself?

Design guru and psychologist Donald A. Norman has pointed out how most modern machines hide their internal workings from users. Any natural indicators, such as mechanical sounds, and certainly the view of mechanical parts, are muffled and covered. As much machinery as possible has been replaced by electronics which are silent except for the sound of fans whirring. And electronics are even more mysterious to most users than mechanical systems are.

Our interfaces to machines are primarily composed of various kinds of transducers (like buttons), LEDs (those little glowing lights), and display screens. We are, at the very least, one—if not a dozen—degrees removed from the implementation model. As someone who listens to user feedback, I can assure you that a user’s imagining of how a system works is often radically different than how it really works.

Yet with all this hiding away of the dirty reality of machinery, we have not had a proportional increase in machine self support.

Argument: Software, in some cases, does fix itself. Specifically I am thinking about automatic or pushed software updates. And, because that software runs on a box, it is by default also fixing a machine. For instance, console game platforms like XBox 360 and Playstation 3 receive numerous updates for bug fixes, enhancements, and game specific updates. Likewise, with some manual effort from the user, smart phones and even cars can have their firmware updated to get bug fixes and new features (or third-party hacks).

Counterargument: Most machines don’t update their software anywhere close to “automatically.” And none of those software updates actually fix physical problems. Software updates also require a minimal subset of the system to be operational, which is not always the case. The famous Red Ring of Death on the early XBox 360 units could not be fixed except via replacement of hardware. You might be able to flash your car’s engine control unit with new software, but that won’t fix mechanical parts that are already broken. And so on.

Another argument: Many programs and machines can “fail gracefully.” This phrase comforts a user like the phrase “controlled descent into the terrain” comforts the passenger of an airplane. However, it’s certainly the minimum bar that our contraptions should aim for. For example, if the software fails in your car, it should not default to maximum throttle, and preferably it would be able to limp to the nearest garage just in case your cell phone is dead. Another example: I expect my laptop to warn me, and then shutdown, if the internal temperature is too hot, as opposed to igniting the battery into a fireball.

The extreme solution to our modern mechatronic woes is to turn everything into software. If we made our machines out of programmable matter or nanobots that might be possible. Or we could all move into virtual realities, in which we have hooks for the meta—so a software update would actually update the code and data used to generate the representation of a machine (or any object) in our virtual world.

However, even if those technologies become mature, there won’t necessarily be one that is a monopoly or ubiquitous. A solution that is closer and could be integrated into current culture would be a drop-in replacement that utilizes existing infrastructures.

Some ideas that come close:

1. The device fixes itself without any external help. This has the shortcoming that it might be too broken to fix itself, or might not realize it’s broken. In some cases, we already have this in the form of redundant systems as used in aircraft, the Segway, etc.

2. Software updating (via the Internet) combined with 3D printing machines: the 3D printers would produce replacement parts. However, the printer of course needs the raw material but that could be as easy as putting paper in a printer. Perhaps in the future, that raw printer material will become some kind of basic utility, like water and Internet access.

3. Telepresence combined with built-in repair arms (aka “waldoes”). Many companies are currently trying to productize office-compatible telepresence robots. Doctors already use teleoperated robots such as Da Vinci to do remote, minimally-invasive surgery. Why not operate on machines? How to embed this into a room and/or within a machine is another—quite major—problem. Fortunately, with miniaturization of electronics, there might be room for new repair devices embedded in some products. And certainly not all products need general purpose manipulator arms. They could be machine specific devices, designed to repair the highest probability failures.

4. Autonomous telepresence combined with built-in repair arms: A remote server connects to the local machine via the Internet, using the built-in repair arms or device-specific repair mechanism. However, we also might need an automatic meta-repair mechanism. In other words, the fixer itself might break, or the remote server might crash. Now we enter endless recursions. However, this need not go on infinitely. It’s just a matter of having enough self-repair capacity to achieve some threshold of reliability.

5. Nothing is ever repaired, just installed. A FedEx robot appears within fifteen minutes with a replacement device and for an extra fee will set it up for you.