I was recently asked to help out on a new software project related to security. I was told the problem was that “users don’t understand.” I guessed that wasn’t the real issue.
One message the team heard consistently was, “Why is this a ‘risk event’ and not that?” When we dug into the underlying feelings behind the users’ comments we learned they wanted more confidence that the software was doing the right thing but initially they just didn’t trust it.
How do we instill trust in the end user? On this project, the deployment team gets the system up and running and then spends a large portion of their time explaining what is happening behind the scenes.
Why not incorporate the explanations directly into the software? Historically, the software was like the Wizard of Oz, “pay no attention to the man behind the curtain” – in other words, the team designed and delivered a user experience that was deliberately and impenetrably opaque.
The researchers and developers on the projects are incredibly smart and they have invested thousands of hours to create intelligent algorithms, so it’s no wonder they repeated say, “We want all of this to be automatic”.
Automation is good, but only once the user trusts it.
A historically similar situation is spam filtering. In the beginning, spam filters had a habit of false positives and frequent misses. They eventually got better – but never perfect. Two factors made the filters better; one was better algorithms and the other was giving the user some control to mark things as spam and not-spam.
For this project, my advice was to expose some of the software intelligence. Let the user understand why the algorithms identified a risk or why it has dismissed it. Let the user contribute their own assessments by promoting/demoting a risk event. Finally, let the user hide it all when they are not interested – like when they start to trust the system !
New POH Kneeboard with write-on surface
A little less than two years ago, I wrote about creating a combination pilot operations handbook (POH) and kneeboard.
One aspect of the implementation bothered me from the very start – the metal front and back covers could be hazardous in an accident. The military use a polyethylene plastic material which is somewhat flexible and less likely to injure.
A separate problem surfaced when I used the kneeboard – my scratch paper would move around and curl. A fellow pilot had described using an arm band – like [US] football quarterbacks use – and a grease pencil.
I decided I’d address both issues with an update to the kneeboard.
The flexible translucent PE plastic is 1/16″ thick. It has a smooth side and a slightly textured side. Normally the smooth side would be considered back. Since I plan to write directly on the cover, I used the smooth side as the face. This makes it easy to wipe it clean.
For anyone who has worked with Garmin’s prior generation of aircraft avionics, they are all too aware of the challenges of wiring high density D-Sub pin connectors, threading back-shells, and conforming to old standards. So I keep being amazed by the small changes Garmin has made with their latest generation of avionics targeting the amateur home built aircraft community.
I’m very grateful for the switch to standard D-Sub pins and the open top connectors makes the assembly much easier. And here is another example of Garmin thinking like a builder rather than an engineer – mounts which can be switched from the ends to the sides of their new remote mounted radio.
When building a kit plane, everything is up to the builder and this means every airplane is a bit different with hundreds of decisions.
In my RV-8, finding a location for the remote radio was becoming a challenge of compromises. I finally located a suitable space but the radio mounting tabs were in the wrong place to make it work. I was about to concede and build new mounting tabs but when I removed the factory tabs I discovered Garmin had anticipated my need!
With the factory installed mounting tabs at each end of the radio, it can be mounted horizontally or vertically with ease. In my case, the problem was that I needed to mount it across between the RV-8’s forward baggage bulkhead and the Z-brace. Ideally, I wanted those tabs to be on the sides of the radio rather than the ends. Thankfully, Garmin attached the mounting tabs with screws. When I unscrewed the tabs I was delighted to see that Garmin had designed the tabs’ screw locations and the radio’s screw holes (two extra ones hidden under the tabs in their original locations) to rotate 90 degrees and re-attach! All I had to do was unscrew the tabs, turn them 90 degrees and there were nut plates already installed for the alternate orientation.
Garmin had designed the radio to give the builder multiple choices for how to install their radio.
This truly is an example of designing for their end user!
GTR-20 with adjustable mounting rails
big phone in a big hand vs small hand
A friend posted a link to Monday’s “Live with Kelly and Michael” where they are talking about the iPhone 6 Plus.
The interesting visual from the segment is the size of the phone appears to change. With Michael Strahan the phone looks completely normal but with Kelly Ripa, the phone looks huge!
execution order of CSS affects usability
The image in this post is of a website which took approximately 30 seconds to render. It makes heavy use of CSS. As you can see, the developers didn’t consider what happens when their CSS loads slowly. The site is unusable – even confusing – until everything gets loaded and executed.
A good web experience requires a “progressing experience” – one where the user can get value very early and gets additional capability and options as more of the content is loaded. It’s bad design when the “content” is loaded but unusable because the “style” is slow. This type of experience suggests the developers and the owners believe “style over substance”. I doubt they want that to be their slogan.
The front porch will receive Craftsman style columns with stone bases. I’ve taken a real picture of the farmhouse and rendered in the five columns.
The bases will be 30" x 30" x 32" (W x D x H) and the columns will be 6′ tall square tapered with a 16-1/2" cap and a 21-1/2" foot.
The stone bases will be made from the same paver stones used for the patio-porch.
On paper the bases sound massive but given the proportions of the farmhouse, they do not look out of place.
… and yes, there is enough space at the top of the bases for a coffee cup … or to put your feet up !