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.

This is a snowglobe featuring a sculpture of the robot Genghis.

I just rediscovered some photos of a robot I threw together in about an hour back in 2003.

Mini-Me v.1

Mini-Me v.1

This was made out of an Innovation First educational robot kit which came with the official FIRST robotics kit (which also had parts made by Innovation First). The small edu kit later evolved into the VEX robotics kit. They also make a cool little toy called Hexbug.

Hexbug

I had been spending a lot of time in a basement laboratory at Northeastern University, primarily to advise the FIRST team hosted there (the NU-Trons). This little robot had the same computer as the real competition robot, so it was useful as a programming testbed. Eventually it was dubbed “Mini-Me.”

Mini-Me (Verne Troyer) from Austin Powers 2

The photos of the Mini-Me robot only show the original configuration.  Later on, the infrared sensors on the front were turned downward and I programmed it to be a simple line follower, as we were thinking about having the big FIRST robot do that as well.

Simple linetracking finite state machine diagram

Illustrating a line tracking robot's potentially zig-zag path during a competition

Of course, being an optimistic college student, I designed a more complicated program of which the line tracker was one component.

Subsumption architecture diagram for a FIRST robot

Program flowchart

But we never finished that on the final system (the big robot) as we spent most of our time on less glamorous tasks like soldering.

The NU-Trons robot (#125) from 2003 (here it is being teleoperated)

It was a good lesson in systems though—the amount of time for testing and integration is massive. With robots, most people never get to the interesting programming because it takes so long to make anything work at all. These robot kits help though, at least for programmers, because you don’t have to waste as much time reinventing the wheel.

Later on I used some of those Innovation First edu kit mechanical parts as part of my MicroMouse robot. Unfortunately I don’t think any photos were ever taken of that. Just imagine something awesome.