So. Many. Questions.
So. Many. Questions.
The Grid image service allows very fast search across our library of over 3 million pictures. Illustration: The Guardian
I’m currently in the midst of architecting and designing an image “management” tool for users to be able to upload, tens, if not hundreds, of images for the purposes of matching them to products to sell online, once the images have been submitted through an internal workflow (yet another tool – but not on my plate).
A fellow co-worker suggested that I look into the Guardian’s case study of the Grid; the Guardian’s now open-source image management system tool.
I’m in LOVE. L-O-V-E. with the approach.
Not only does has the Guardian open-sourced the tool, they’ve shared the methodology behind it’s creation (Programmer Anarchy), and presented insights from the UX perspective on how the entire team was able to get on the same page, at the same time, and work together to champion all the users–an actual shared Vision complete with succinct goals and KPIs.
Not to mention, a drool-worthy short
video sizzle reel of the Guardian’s UX Studios.
A very interesting article from the online magazine the Verge regarding the company that created and supplies the software alert system that was responsible for the near disastrous incoming BM warning issued to residents and visitors in Hawaii earlier this week.
When considering how our brains function, or don’t, during extreme conditions (an incoming missile being one of them), it’s rather unfathomable that there is no visual differentiation or confirmation between a “test” message and a “real” message.
The company has confirmed that, if creating a message from scratch, there are eight steps involved; if creating from a template: three steps. So users technically can’t just click a button and issue an alert – there are at least three steps. (I personally can’t imagine being able to keep my sh*t together to get through three steps, but then again, what we imagine we’ll do in an emergency situation is often not the case.)
What surprises me is that there is NO FINAL CONFIRMATION messaging when sending out a “live” message. As in, “Are you really sure you want to send an entire state into panic?” Or, “Are you really sure you want to start a war?” Maybe even a second one (a final final confirmation message) just in case cognitively the person isn’t thinking clearly, possibly adding bells, whistles and starbursts. (Studies show the same thing happens to pilots in crash scenarios. The brain can only handle so much at once.)
Word of the day: Confirmation.
Are you sure you want to start a war? Really sure? This action cannot be undone.
Ah, indicators, notifications, validations. A virtual soup of icons, color, and text that either lead to minor panic attacks or promote procrastination. Those visual nuances that tell us through color, icon, text, motion or a combination thereof, that something needs attention: immediately or later or FYI. Sometimes accompanied with fear-of-God messaging, sometimes not; “(!) Please provide a first name” or “(!) Required.”
However, not all notifications are necessarily equal. Notifications may and will have varying levels of importance to the user or to the system. Failure to see and take action may have serious consequences, while others can be put off – i.e., remind me later.
Nielsen Norman Group (NNG) has, as usual, an informative article on indicator types, “Indicators, Validations, and Notifications: Pick the Correct Communication Option.”
I’m in the midst of a project where there are four to five potential levels of notifications with possibly more to appear. Yes, it’s a cringe-worthy, but sometimes you show up and the only thing you get is lemons. So you do your best to manage the experience for the end user. In this case: not confuse the hell out of her (the user) by having to decipher different color notifications w/ or wo/ indicators (e.g., icons) and messages (at the same time), try to prioritize them (correctly), and then act on them (or not).
You know, “Do no harm.”
The project is the display of a specific set of categories (approximately seven) with corresponding attributes and data. Oh so much data. The UI is a grid display (think Excel), and therefore imperative that the user be able to quickly orient herself, interpret what she reads/sees, and locate things she needs to attend to: immediately, soon, or whenever. (Literal definitions.)
In order of priority:
The key to managing this potential carnival will come down to business rules.
Without business rules in place the user will undoubtedly be hit over the head numerous times with numerous messages, and most likely experience inaction (freeze) because it will be difficult to know where to start.
Biz rule #1: Critical information is king – bow down
Obviously, the most critical information needs to be top dog; if it’s missing, the user needs to supply it ASAP. This is notification should, when applicable, be highlighted above all other notifications to allow the user quickly focus and take action. In other words: red.
While other notifications may have messaging, color and icon elements, if there is a “blocker” on the page, the other notifications are downplayed to let the blocker notification stand out.
Biz rule #2: Nice to have, plays nice with others
Though not critical, “nice to have” information is still necessary. In this case, I’m following the NNG recommendations for a passive action notification and indicator. Meaning, in absence missing critical information, cells may be highlighted per section
However, if a blocker is identified on the same screen as “nice to have” then the prompt will be suppressed to allow the user to focus on the most critical missing information, but a secondary configuration for “nice to have” may remain.
Biz rule #3: Optional is neutral territory
Optional is exactly that, optional. A user doesn’t have to supply it, and if they do, good for them. I’ve chosen to leave these cells status quo, meaning no notification or indicator. The only thing the user will see is an edit icon if she taps or clicks into the cell. This is a pattern used on previous internal UIs accessed by the vendor, as well as a common image for edibility. Having it appear on click or tap is to reduce visual noise, because there is A LOT of data on these screens.
Biz rule #4 Search – make results obvious amongst other indicators
Obviously, with a lot of data, having the search highlight the data that matches the search query assists the user, as there’s not traditional “search results” screen. However, there may be times when cells may be highlighted as “nice to have” prior to and after the search query. Since the search function is a temporal situation, the cells may be highlighted while “nice to have” may be suppressed in order to reduce visual noise and maintain focus.
What’s the old saying, “looks good in theory but how does it look in practice?” Hopefully there will be an opportunity to test the rules soon with real users of the system, and see if I can direct them to react and act appropriately. Time and use will tell if I’ve dialed in the appropriate levels of color, messaging and iconography at the proper times and in the right context.
For those who look at time stamps and time in-between posts, you undoubtedly notice that there are few posts in 2016 and 2017–maybe four or five total.
It’s not that I’ve forgotten to write, or become bored with writing, or fell off the planet.
Sometimes you make plans and then life gets in the way.
Well, I think I’m back.
You just gotta go wonder sometimes.
Recently, when exiting the parking garage, I noticed some signage updates to the new payment system installed by the garage. Since I’m a monthly card holder, I just have to flash my card and the gate automatically opens. Based on the labels and dialog windows, my guess is that the process for paying to get out of the garage is not intuitive.
Take a good look at the photo below and tell me how absolutely genius this set up is.
For starters, the smaller item on the far right with the slick rounded top is an electronic parking meter. You put in money or a credit card, select how much time you want to pay for, and it spits out a little piece of paper you stick on your dashboard.
Note that the parking meter has a solar panel on top of it, presumably to keep it powered or partially powered.
Now take notice of the larger “thing” to the left of the electronic parking meter. This is signage informing the would-be parker about parking rates, instructions on how to pay for parking, and undoubtedly some language that says something about the parking company takes no responsibility for lost, damaged or stolen stuff. Aka, fine print.
The designers of said signage thoughtfully included an awning over the signage, presumably to shelter is reading the instructions from the rain (this is Seattle, after all.) The awning manages to stretch over the a portion if not all of the solar panel on top of the parking meter. Again, I’m sure, to keep the Seattle downpour off of whomever while the parking people get their money.
Both of the signage and electronic parking meter are situated somewhat under a very large tree, the branches of which create a leafy canopy.
Now, I get that solar power has come a LONG way, but this is genius.
I have no IDEA why I’ve been thinking about “Norman Doors” lately; it may have been while watching an older episode from Modern Family where Claire gives herself a shiner while being boss for the day at her dad’s closet company.
Most in the UX community are familiar with the phenomenon, but for those unaware it’s relative simple. A “Norman Door” is simply a door that one simply cannot determine exactly if it is meant to be pushed open or pulled open. (The title is named after the well-known Donald Norman.) Conflicting handle design (vertical or horizontal) and signage (“Push” or “Pull”) may often be at odds with one another.
I found a nifty little blog post with great examples of Norman Doors at 703 Creative.
The post has some great examples that will generally leave you head scratching, but hopefully wary next time you approach the entrance to your local shopping mall.
Luke W (a.k.a. Luke Wrobleski) gives us a brief and informative breakdown of the Apple Watch UI and interaction model, with recommendations for improvement. I really like his take on the suggested model of use: notifications, glances, apps.
Not an owner of an Apple Watch, yet, I can appreciate how iPhone owners (myself included) would look for a similar interaction model to access information. It only makes sense, right?