School – Brain Lint

Hyperopia

The New York Times Magazine had its annual year in ideas issue this past sunday – one of my favorites was Hyperopia, which is the idea that in the short term, one feels guilty for not getting enough “stuff” done, but over the long term, one looks back and wishes he or she had more fun back then.

This is on my mind as I finish off a class (man machine system design) where I really haven’t learned much and the assignments are so long that the professor has to be a sadist of some kind, as I try to figure out what I’ll take next semester (the evening class pickings are lame) and why I’m getting a master’s degree in computer science the first place.

Constraints, friend or foe?

I’ve seen several places that sing the praises of building something under some kind of constraint, including this article at the always excellent Creaating Passionate Users blog. Checking out everyone’s projects in the “lab” session of my class reminded me of this.

The assignment was to build two version of a weather forecast reading tool for a hypothetical phone – one really basic, the other with some better automation features. One just had to be able to enter a zip code and click through seven days of weather. There weren’t many details given, and no requirement on the type of implementation (this is an engineering psychology class so there are lots of non-programmers).

I looked at the assignment and saw the requirement to type in a zip code and immediately discarded the idea of using powerpoint, reasoning that powerpoint faking of entering text via phone button pushes would require hundreds of slides. So I moved to flash; which was good practice, and I got to test out an open source framework in the process (ASAP Framework). The majority of the class turned in perfectly adequate workflow prototypes in powerpoint. How did they do that?

They embraced constraints.

Key constraint: entering an arbitrary zip code isn’t the point because we’re not really finding the weather. This simplifies things tremendously, and I can’t believe that didn’t occur to me. The power point projects only allowed one zip code to be entered (ie the “3” button was the only link active on one slide which would link to the next slide that would show a three entered) which was fine because the usability test task could be given as “find the weather for zipcode 12345”.

Embracing that constraint reduces the complexity tremendously and allowed people to concentrate on the work flow (and in some cases beauty) of their apps, while I was futzing around with flash. I’m able to (and indeed prefer) to prototype in tools more powerful than Powerpoint, so I immediately brought the big guns to bear, never having paused to think about the tradeoffs one might make at little cost to make it possible to do a reasonable fidelity prototype in powerpoint.

I do find building these prototypes in powerpoint incredibly tedious because of the drudgery involved in creating hyperlinks between all the frames as compared to writing some scripts. Good programmers are “lazy” in that they’d rather take time to automate something than do a task manually, but there’s obviously got to be a repetition threshold under which it would actually be faster to do the work manually than invest more time in building a more robust, automated solution. This project probably fell on the keep it manual side of that line.

At least my on screen cursor eased in and out of position. Can’t do that in powerpoint! (or can you?)

Almost time for back to school…

Matt’s post about his first week of grad school reminds me of two things: 1) Class starts for me next week 2) I’m jealous that his program offers an Information Visualization class. That’s something I’m interested in, health system but despite all my lobbying and rounding up quite a few grad students who are also intrested, I can’t get Tufts to offer such a class. I’ll have to look into a directed study or transferring credit from some other school in the area.

I’m bumming in general about my grad program at Tufts because all the interesting classes are offered during the day. They don’t really have a night program, and they try to offer enough classes at or after 4, but this semester the offerings are pretty grim. I’d like to take Computational Bio or Computational Geometry but they’re in the afternoon, twice a week. I could probably get work to let me do that, but the I feel stuck there because a new job isn’t likely to be down with that.

Also a bummer is that it will take forever to finish. I contemplated quitting my job and going to school full time for one semester to knock off a bunch of classes at once, but thought it would be dumb to do that and not actually be done at the end of it. Maybe next fall. If not I need to knuckle down and take more than one class at a time.

Class final project: smoke and mirrors

The presentation of our final project managed to compensate for a complete lack of quantitative data with visual humor and gadgets. I’m still shaking my head.

Note: Beware this post is pretty much rather stream of consciousness, and worse was typed in a couple different sittings, so its not even the same conciousness.

The Project

Our final class project was an interactive prototype of a bike computer / navigation system. We split up into semi-randomly assigned groups of four, where the group consisted of one person who had self identified as a researcher, two people who self identified as good at design, and one who self-identified as a good prototyper. I made the mistake of identifying myself as a prototyper.

Some Pictures

Before the rest of this rather long winded post, I’d better throw up some pictures so you know what the hell I’m talking about. Here’s a couple of screenshots from the flash prototype.

The map and stats screen:

The trip planning wizard:

The team

My teammates were all undergraduates. That presented a problem constantly, because they had a different definition of last minute than I did. The class was on Tuesday night, so at the latest, I needed to get things done Monday night, preferably Sunday afternoon and night. They seemed to love working through monday and tuesday, ignoring this whole job thing of mine. The procrastination thing really did a number on my schedule ultimately.

The schedule

First week a two page research doc plus a conceptual map and a ui structure was due. Week two screen templates and renderings are due. Week three a prototype and presentation are due, along with usability testing. I looked at that and immediately knew that life as a prototyper was going to be rough unless we got ahead of the curve. Did that happen?

Not so much. I don’t know that it would have anyway, but any dreams I harbored of getting ahead were fucked because two people went away for passover. One from wednesday to sunday, the other like thursday to monday night. Hows that for a kick in the pants.

Week one

This week we met briefly a couple of times to get research going. We did have some really good ideas, some of which ultimately fell through the cracks (which i was reminded of later in other team’s presentations) – but the conceptual diagram and structure map were pretty much phoned in because no real meeting of the minds had happened yet. Not a good start.

Week two

This is a little fuzzy, but I don’t recall getting off to a good start. I think there was a little spurt of design before everyone disappeared, and there was a lot of design generated and shared through email and the dreaded blackboard system, but I still feel like things would have been easier and the results better if we were in the same place. There were some good ideas floating around, as well as some not so good ones. The design was always a little too frilly for an embedded device that should have been centered around simple information delivery.

I spent quite a bit of that easter/passover weekend designing the visual identity of our team, creating a rendering of our hardware and creating a splash movie in flash before finally jumping in to redesign our stats screen (things like speed, heart rate, etc), which as the time was this hard to read muddle of data – it was in rows and columns, but it wasn’t chunked well and the units and category labels had as much weight as the actual data, which clearly would be more important to see as the labels should melt away for an experienced user.

As I both expected and feared, the visual design deliverable was “finished” minutes before class on Tuesday night, leaving no time to get a head start on the prototype. To make matters worse, there weren’t nearly enough screens designed, there was no real concept of how the workflow would proceed within each screen and how the user would move from screen to screen. I also saw the visual design as far from finished.

Week three

Now it’s white knuckle time just a bit. Need to develop a prototype in Flash in under a week so it can be usability tested – and I’m refining the team’s design on the fly. Terrific. Suffice it to say that I spent a lot of time in Flash and Fireworks that week, and not nearly as much time sleeping.

My biggest regret of the prototyping effort was misallocating resources from visual fidelity to functional fidelity. (the prototype was supposed to be higher visual fideility than functional) I had made the same mistake on the previous prototyping project where I had cutesy windows sliding in and out rather than polishing the visual design; I made the same mistake again in actually implementing our trip planner screen which acted as a wizard so the user could set any one or more of 5 ride parameters (distance, end point, terrain type, etc) and then be guided through choosing a route based on those parameters (see the second screen shot above). I had argued against it in a design meeting, but somehow suckered myself into giving it a try. Oops, that took about 6 hours – and of course it was almost there after just half that time.

This is where some conflict started arising among the team. Okay mostly between me and the rest – my prototype was visually more simple than what their designs had (loosely) specified. It was fun to dance around that by pointing out that their designs didn’t even agree with each other.

During this week, usability testing is happening in parallel as much as possible with my prototype development – which is the crux of the problem with the schedule…

The Presentation

Come the deadline, the team has put together a slide deck for our presentation, and we’ve very briefly rehearsed the presentation. We’re going fourth out of five teams, so we got to get a feel for how ours stacked up against the rest, which was good and bad. Bad because the teams presenting before us actually gathered and presented quantitative usability results – that didn’t even occur to me or the team, so we don’t have anything to show on that front. A little annoying seeing some of the really good ideas that we either didn’t come up with or more often had in early brainstorming but let slide through the cracks at some point. Good because I’m starting to feel better about our design; the prototypes we see are vindicating my resistance to needless glitter like background images. At least for me, working on something flat out like this totally breeds contempt; I could see all the flaws in our design and not how it might actually not be so bad after all.

I insisted on going with pictures rather than bulleted lists as much as possible, and I think that turned out for the best. Instead of presenting usability test results against the backdrop of ugly excel charts, we did some hand waving in front of a picture of a team member with a notebook wearing flip flops in hot pursuit of someone riding a bike, and more pictures of a mockup of the device taped to a bike. We even had a color printout attached to cardboard to pass around the room (this was fun to watch. I’d designed the device with a curve so that it would be easy to pivot the thumb between buttons, so a lot of people actually tried that on the mockup) We had the Queen song “Bicycle Race” playing behind a list of acknowledgements. If I remember correctly we got applause before even taking questions.

I have no idea what grade we got on the project, but one of the “bicycle experts” brought in to be part of a panel of judges said we had “the best presentation so far”

All’s well that ends well I guess.

Another class complete…

I’m so glad my final project for Applied Design of Software User Interfaces (ENP166) is over; indeed the class as well. The class sessions were awesome to sit in: the teacher, Michael Wiklund and ta Allison work together at the teacher’s design firm so they had all sorts of real world stories to draw upon. Much better than the dry academic stuff a “real” professor usually would have to share.

The class ended up being pretty grueling in terms of workload – the first three or four weeks had a project every week; there was the pet adoption web site design, the art museum tablet pc like guide book design, the airline in-flight entertainment system design and prototype, capped off by the bicycle computer/navigation system team project. Lots of practical experience with the phases of UI design working through conceptual models, ui structure maps, templating, visual design and prototyping meant lots of time in front of computers using omnigraffle, free mind, fireworks, the gimp, and flash.

Even given all the experience gained using the tools, I’m afraid I didn’t learn all that much. I don’t know if I’m in an in one ear, out the other rut right now, or I was just usually so tired for class having been up late the night before finishing projects – I can’t rattle off some of the buzzwords like some other people in class can. Hopefully $3000 worth of stuff stuck upstairs somewhere.

My team’s logo

At some point I’ll make a lengthier update praising Macromedia Fireworks capabilities – the more I learn about how to use it, the better it gets (especially the pen tool!), but for now I wanted to ~~show off~~ share this logo I created for my class project team. (For some context the project is to design the interface of a bike computer that would include GPS maps as well as all the usual bike computer stuff)

Tireless Logo

Adventures In ActionScript

Once again, post work nap out of the way, I resumed doing my homework project and learning flash in the process. It seems (like most things) there are many different ways to use flash. On one extreme you can use the timeline along with automagic tweening functionality and very minimal scripts to lash things together, or you can go to the other extreme and use it as a visual programming environment, using object-oriented (well as OO as JS/AS get) externally defined scripts for everything. Being a programmer, I chose the latter.

One of the problem’s I’ve had is resolving fields in the various namespaces, particularly finding one “movieclip” from another. Its odd that everything useful has to be a movieclip or a button, and that you can only apply certain graphic filters to those type of objects. Back to the namespace issue – now that I seem to be able to properly find objects from one another, I encountered the problem that function objects in JS/AS don’t know what object instances they’re associated with like they would in Python. So setting a button’s event handler to call one of the functions in either approach below won’t work: (I wish I new why the editor in WordPress is effectively double spacing the text below by inserting break tags)

/* approach one : * fails because doSomething will not be bound to this instance */ this.myButton.onRollOver = this.doSomething; /* approach two: * fails because this is not pointing to the right thing when it is executed */ this.myButton.onRollOver = function() { this.doSomething(); };

At this point I picked my roommate Phil’s brain because he’s always crawling around the obscure guts of languages like this, and found out some of these strange consequences of Javascript not really being OO – that the this pointer sucks and the above facts about the capabilities of function references.

Big thanks to him for pointing out this simple way to fix the problem using a closure:

var a = this; this.myButton.onRollOver = function() { a.doSomething(); };

And for reminding me that you can do something like MochiKit does in their bind function to make “real” function pointers that know what instance they belong to (in a really stripped down form below)

class BindUtil { static function bind(obj,func,args) { return function() { if (args != 'undefined') func.apply(obj,args); else func.apply(obj); }; } }

Because that function makes it possible to pass arguments, one can easily define one handler to use for various buttons inline like this:

this.tempMinusBtn.onPress = BindUtil.bind(this,this.changeTemp,[-1]); this.tempPlusBtn.onPress = BindUtil.bind(this,this.changeTemp,[1]);

So I’ve got one working dialog for my prototype due on Tuesday, but this is more functional that a lot of the rest will be. Its a screen from a inflight entertainment system we’re prototyping. The screen linked below is the climate control dialog that will fly in from the side to adjust temperature etc. The close button does nothing.

Flash Demo (Requires Flash Player 8 )

Only now do I notice that the control areas aren’t centered. I guess I’ll fix that later.

Fun with design tools!

My Applied Design of Software User Interfaces class is lots of fun, but turns out to be a lot more work than I had anticipated (No programming or math, this can’t take much time!). I’ve spent hours learning Fireworks and Illustrator, and gotten much better at mocking up user interfaces in the process. I’ve also found that staring at the screen for hours tweaking pictures seems to be a different level of eye stress than programming, presumably due to having to focus on the slightly bigger picture than a line of code at a time.

We’ve had three weekly assignments to mock up user interfaces (including preliminary conceptual designs, affinity designs, and user profiles) which are given in the form of project for our mock design companies, and the deliverables must be color printed and bound, which makes one take an extra level of pride in the work – more of the same pride that keeps one up way too late making final design fixes.

I thought I’d share one of my designs from the last homework assignment: it was to mock up a design for a handheld, touchscreen computer (tablet) that would assist users in their tour of an art museum. The screen at the right (click to enlarge) uses the device’s ability to know fairly precisely where it is to present only the art nearest the user, from which the user can select one for more information. There’s some things I don’t love about the design now that I’ve had more time to reflect, but I still like it. I learned a lot about Adobe Illustrator in creating the icons for the nav buttons on the left (even though they still look like they were drawn by a Quailtard) – I also learned that Illustrator can’t do angular gradients like that I had in mind for the radar button, so I had to resort to the Gimp for that.