Archive for the ‘Design’ Category

Shopping List Balsamiq

Sunday, May 4th, 2014

With the release of Angular 1.2 and a desire to keep practicing my web programming skills, I’m working on an upgrade to our Shopping List AJAX app to allow switching between lists. The use case is the need to have a succinct list for each store we visit, since we often have to sequence trips in parallel for various reasons. Having just a single list breaks down pretty quickly in that workflow due to lots of scrolling, or being unable to hit ‘clear’ without wiping out items from the other store.

Through lots of design time at work I’m starting to get passable at making mockups in Balsamiq, so I thought it would be a useful exercise to try taking the skill home. Here’s where I’m at so far (only have a few minutes here and there to work on it).

Still need a solution to the question of how to see all the items at once, which is an unusual UI interaction that seems like it would suggest some sort of “filtering” concept. Maybe a design with a single master list and a filter for each store (including a default filter) is the next one to explore.

On the technical side, I am still figuring out whether this is a good time to tackle switching the backend over from PHP to something a little bit newer and flashier. Simple file I/O was fine initially, but having two layers of tables seems like it will be a huge pain to do without a real database, and I’m not sure spending a bunch of time hacking together PHP + MySQL is really the thing to be doing in 2014. Looking instead for something that integrates nicely with the Angular $resource model, which I haven’t found yet.

Reset the Swing Timer

Thursday, October 10th, 2013

Last week we took a family road trip, and as a result I spent a lot of time driving the van through beautiful weather… but also a lot of time driving the van through rain. Owego, NY is a nice quaint town which we discovered has the tiny little downside of actually being buried in water for part of each day. We also hit the remains of something apparently called “thundersnow” on the way out of Pennsylvania.

What struck me while fiddling with the windshield wipers was a cool feature that I haven’t seen on any car I’ve owned before: when I turned the dial to increase the intermittent speed, the wipers always immediately swing (even if they weren’t due to swing yet). This is a subtle thing and it only makes a second or two of difference, but it seems to me a brilliant example of thoughtful design. The only real reason anybody would turn the dial is because they need more wiping, and they need it now, so why not oblige with not just a faster interval, but an immediate wipe?

As soon as I thought about this I was reminded of video games – it’s fairly common in Action RPGs to have an ability that temporarily increases the potency of your weapon swings, and some of these abilities actually do the same thing: they reset the swing timer so that as soon as you hit the button, you immediately get to see an attack with the new ability. It’s a nice visceral effect that gives an increased sense of control and feedback.

A similar scenario comes up in software development occasionally – I’ve seen a particular case where there’s a setting that allows changes on a web page to be immediately “auto-applied” (vs. having to queue them up and click Accept later on). If a particular user prefers the auto-apply feel, they almost certainly want any changes already queued up to be applied immediately when they turn on auto-apply. Having to turn on auto-apply but then still go click Accept is unnecessary extra work.

I’m not sure if there’s a term for this design principle of tacking on an immediate effect to a rate-modifying adjustment. I couldn’t find any references online, but without Google keywords it’s hard to know what to look for. In any case, it’s a good one to consider whenever you’re designing a switch or dial that impacts future state or user actions – is there any way to give the user an immediate effect that they likely want? Furnace manufacturers already have this figured out; they make very sure that when you crank up the heat on the thermostat there’s some kind of immediate reassuring audible or tactile feedback.

 

 

Designing Around User Interface ‘Flicker’

Monday, August 19th, 2013

A few months ago I rolled out a total overhaul of my Shopping List web app using AngularJS, which was a lot of fun and has in general been a success from a programming/tinkering perspective. It was not, however, a success in user happiness, as we found out the hard way the first trip to the grocery store using version 2.0.

The problem? As part of the overhaul I had patched a data integrity bug where two delete requests are sent in quick succession and it’s ambiguous to the server which line to delete (that’s an architecture problem for another day).  I thought this was a nice change which prevented a rare scenario of accidentally deleting the wrong list item. It turned out, however, that this actually created a workflow where the server update message can come back and can subtly shift the client UI a second or two after the user expects that it’s already done updating, restoring the entry that the server believed to have been deleted in error.

Screen Shot 2013-05-13 at 1.54.17 PM

When the red X is clicked, that row will be deleted… usually. Sometimes it will go away, and then pop back unexpectedly. What a ‘nice’ feature!

This meant that just about the time the user goes to tap the next item to mark it done or deleted, the server rudely shoves a new item into the list and jumbles up the tap targets. This behavior and its unfortunate timing makes it very, very easy to click on the wrong thing. In practice this is just as bad as the bug I had meant to fix, because it manifests in the same behavior of an accidentally lost entry.

Trying to solve this design issue got me thinking about this interesting class of bugs: cases where a user interface updates just before you try to click or tap an element, causing you to hit the wrong one. It comes up somewhat often in web browsing if you’re loading a page with lots of images and trying to click a link towards the bottom of the page. As each image above you loads, the link you’re trying to click can shift. This creates a frustrating race where you have to chase the click target down the page. You can also see this in iOS when you’re looking at a single image in Photos, and you get stuck in loop between tapping the HUDless screen to bring up the “Back” button and trying to actually tap “Back”. For me personally, my brain->finger pathway seems to have exactly the same timing as the UI delay on hiding/showing the HUD, so I can never quite tap on the button I want to until I force myself to stop and break the loop.

I don’t really have a great solution to this problem. One technique I’ve seen applied in mission-critical professional software is the use of a ‘shield’ which blocks all user input when the application knows that a server refresh is pending. This seems to work ok, but it’s tricky to get the user experience right because it’s replacing a rare misclick/mistap scenario with frequent appearance of unresponsiveness. As long as the UI both indicates the reason for the lack of response (maybe with a ‘Loading’ icon) and allows the user to somehow read data underneath if necessary, it seems like a viable path. This only stretches so far, though: after a couple seconds of loading I would expect users to abandon the screen rather than continue to wait. It’s also potentially making the 95% case a worse user experience for the sake of the 5%, which is probably a mistake in most software.

For this particular shopping list application, my solution was to consolidate all workflows that cause row insertion/deletion outside the list itself, so that the risk of a race condition between ambiguous server commands is mostly eliminated, and there aren’t destructive buttons shifting up and down anyway. It seems to work ok for now, but even here it feels like we lost functionality to deal with a bug that, while frustrating when it does manifest, is only relevant a percentage of the time. Here the timing of the server requests made this percentage high enough for a change to be worthwhile, but I’m not sure that’s often the case in other applications.

Hair Space (U+200A)

Wednesday, June 5th, 2013

I’m working my way through HackDesign.org’s nice design tutorials for developers, and running into a whole world of letter design that I didn’t even know existed. I’ve always found typography interesting and have participated in the cute “which is the best programming font” discussions (I’m a PragmataPro die-hard), but haven’t dug much deeper into all the variations as they apply to digital content.

Many wonderful links on this particular topic here, although I would certainly recommend starting the course from the beginning. My particular favorite today is from Yves Peters:

The non-breaking space is not the only special space character available in HTML. An em space is as wide as the type size, creating a perfectly square separator. The en space is half its width. Very useful in tabular material is the figure space, which takes up as much room as the numerals in the font, while the punctuation space is as wide as the dot or comma. Thin spaces can be used between the dot and the next letter in abbreviated names, and hair spaces to detach em dashes from the neighboring characters. And then there’s the three-per-em space, the four-per-em space, the six-per-em space …

I had sort of a vague notion in my head that &nbsp might have a different effect than tapping the spacebar, but had only really considered it from an encoding and string parsing standpoint. I suppose all these quirky types of spaces must be used all over the web and having subliminal effects on me without me truly understanding the difference between a tabular space and a hair space. I did take care to make sure to <strong> those space names and not <b> them, as well!