All posts by minoblogger

Day 2 – How Have You Changed In the Past Two Years

FacebookTwitterGoogle+PinterestShare

I suppose I HAVE changed in the past couple years. Lots of things have changed around me, and to a degree we are what we do, what we surround ourselves with and what we spend time thinking about.

I have changed jobs and employers twice over the past two years.

in 2014 I was learning to be a dedicated software developer – reluctantly learning the basics of JAVA, a couple different fairly robust modern content management systems (CMS), an aging database and more decrepit CMS , and basically figuring out how to tread water among a large team of seriously talented developers who could breath underwater.

In 2015 I became a UX designer for a company  in the healthcare B2B space, applying what I’d been learning the last couple years through reading, conferences, writing, schooling and outright leaps of faith. I was learning a new domain (Healthcare/hospitals), suffering withdrawal from leaving a great company with fun people with whom i had significant investment and learning to make do with a much smaller company’s practices.

I was learning to get over my fear of public speaking

I’ve never been fond of public speaking – to put it mildly. You could measure my pulse, temperature and degree of perspiration before and after being asked to contemplate getting up in front of people and saying something meaningful – and it would be obvious which was which.

A couple years ago I became aware of an opportunity for any old schmoe off the street to talk at CodeStock, a local developer conference in Knoxville.  I signed up for a lightning talk – a 15 minute stretch to talk about whatever you want and see what kind of interest was garnered by how many showed up.   No pressure, right? HA!  Getting prepared for that, and fighting through a sinus infection & sore throat to deliver the talk was one of the hardest things I’ve done… but guess what? The next time I had a chance to talk, it was easier to convince myself I could do it, and I was a TINY BIT less anxious about it.

So now that I know that treating public speaking like a vaccine is effective (small dose to trigger my natural defenses, capiche?), I’ve jumped at chances to talk in front of people since…

  • I’ve MC’d and help run conference events
  • I’ve led training events within several companies
  • I’ve presented project summaries and strategic plans to executive boards
  • I’ve given a 1-hour presentation to several hundred people (omg)
  • I’m doing more of the same later this year – glutton for punishment I guess

My daughter is 2 years older

I enjoy spending time with my kid.  Earlier in her life we had to keep the activities pretty simple, playing blocks or dolls or engaging in epic tickle fights… But now she’s getting pretty darned smart, and her creativity and attention span are growing in leaps and bounds.

I’ve really enjoyed teaching her the basics of art, now days she’s taken to joining me in the studio for some father/daughter drawing board time…

We have fun talks in the car – almost a Mr. Wizard experience… One of us will notice something and point it out – and I’ll provide some context for her and ask if she knows what something means, or why it is the way it is…. “No!” she’ll say – and we’re off to the races with questions and answers until we’ve reached the point at which a 5 year old or 42 year old will bail and change the subject or grow quiet.

I’ve become my preparation-centric parents

I’ve always been the type to say ‘we’ll be ok, bad stuff never happens anyway’ or ‘I’m careful, accidents won’t happen’ – throwing caution to the wind and just going about my days with minimal.

I suppose it’s partly a function of having farming/rural living in my family background, partly just getting older a smidge of healthy paranoia…. but in the last couple years I undertook to learn more about how we could become more prepared for a wide variety of circumstances.  Be it a power outage, contamination of the public water supply, or just bad weather.  Safety at home, in our vehicles and whilst out enjoying the natural world camping or hiking… these things have been on my mind the last couple years and not much beforehand.

I won’t say we’re 100% prepared for everything all the time, but we’re a good bit MORE prepared now than in previous years, and that’s something.

 

Enough for now…

Day 1 – Weird Things You Do When You’re Alone

As my lovely wife likes to say, I’m somewhat codependent. She works on cleaning out her office, I find myself drawn to tidying up as well, and so on. In this spirit I embark on a 30 day challenge to blog (just like she did), based on this list. Since I’ve never done that many entries in a row I suspect I’m doomed to failure – but it should be interesting nonetheless.


 

Day 1 – Weird Things You Do When You’re Alone

When I’m alone at home, I go one of two ways:

  1. I treat the house like my own personal Fortress of Solitude. I’m sensitive to noises, distractions, etc. and so sometimes when the house is empty I find myself able to focus more effectively.  Be it reading a book (particularly ones that take serious mental effort to follow), working on a project, or even just relaxing with television on the DVR or Netflix queue – the silence makes it easier to keep a higher fidelity mental model intact in my head and more fulfilling to experience.
  2. I dive into a frenzy of activity with no concern for potentially falling ladders, wet paint, sharp tools and implements lying around, hot beverages perched in inadvisable locations and music blaring loudly.  A fly on the wall might see me sprinting up and down the stairs, from one project to another in rapid fashion…(because who works on one project at a time, really?!? – ADD sufferer)

I always enjoy time alone at home, but after a while the quiet becomes TOO quiet.  The space becomes TOO empty, and I miss my gals.

When they come back though, I end up having to be all civilized – wearing pants and speaking out loud in complete sentences. Some days that’s asking a lot.

It’s Users All The Way Down

https://creativecommons.org/licenses/by/3.0/

Sometimes in the process of defining your users, you’ll discover that, much like turtles, there are layers upon layers of them just waiting for their stories to be told.

Background

Joining a company late in 2014 as their new UX professional (and founding member of a growing team) has been an eye opening experience. Not only have I been able to finally practice what I’ve been preaching and learning the last few years, but I’ve been exposed to the healthcare industry – which is entirely new to me. Tons to learn = tons of fun.

Anyone in experience design must carefully consider their users’ goals, circumstances, capabilities and habits. This is one way for us to get out of our own heads and as far into our users’ heads as possible – avoiding the trap of designing for the users we’re most familiar with: ourselves.

Identify the users we’re serving is a great place to start. This sounds simple and it can be – but it can also be a complex puzzle (with all the edge pieces hiding and the corner pieces eaten by your dog.)

What my company does

At a high level, we provide a secure and efficient communication platform for the healthcare industry. The platform helps patients, practice staff and hospital staff efficiently contact physicians.

The problems we solve:

  1. handling the bazillion ways that physicians within a hospital or practice setting need to be contacted depending on situational context.
  2. sending information to a physician in a way that is secure and does not violate laws around the privacy of protected healthcare information (PHI).
  3. maintaining a fine balance between the needs for privacy and accessibility on the part of the physician.

Who are our users?

User (Turtle) #1: Our external users

This group includes doctors, nurses, acute care staff and hospital / practice management. They’re the obvious answer to the ‘who is our user’ question – the system was designed to meet their needs and everything revolves around maintaining and enhancing the capabilities that our platform extends to them.

If we push out a buggy feature or misjudge the utility of an enhancement and sacrifice something more vital, these are the people who feel it the most. We should be in close contact with representative members of this group, testing things out and gathering feedback constantly. This group will (and should!) receive the highest prioritization when it comes to evaluating features, to doing user research and to planning and executing usability testing. That said, don’t stop here!

User (Turtle) #2: Patients

Our healthcare professionals are themselves serving another group of users: their patients at member hospitals and practices across the country. These are the folks that our external users are under oath to care for, and who they went to school for a dozen years to serve.

This is the group who pays the price for inefficient communication practices. It’s the folks who have seen their premiums and deductibles climb year after year and who in too many cases don’t have insurance at all. They pay dearly for any healthcare they receive. This is you and me, when we visit our family doctor or when we land in the emergency room after falling off the roof in an ill-advised attempt to save money on chimney repair.

While we can’t prioritize designing for this group over the others, we should always consider the impact of our decisions on these people.

User (Turtle)#3: Internal Users

We have another group of users not immediately obvious to the naked eye: our internal users. These are the folks that use a suite of applications to onboard new external users and that support their needs on a 24/7 basis, 365 days a year.

They don’t use the exact same set of tools as our external customers, but they’re touching the same data and hitting the same systems. Their needs are also much more diverse since they service every type of external user and must become experts in the task flows for those users. This is no small feat, as the training required for these folks to become proficient runs from a full week to a staggering 3 months.

When considering the needs of this user group, striving to avoid introducing further complexity is a big priority. Beyond that, a large part of your backlog might revolve around taking steps to reduce that complexity even further (and therefore lighten the cognitive load of using the system).

If you’re in this situation, your company’s bottom line could be affected nearly as much by internal facing changes as it is by changes that affect your external users.

User (Turtle) #4: Executive Team

You’d think we had all the bases covered, but there’s actually one more group of users to touch on. Let’s call it the owner/executive team, made up of company ownership and senior leadership in both your external users’ companies and your own organization.

The goals and tasks of this group tend to be pretty straightforward, and sometimes seem pretty far removed from what the other three groups of users are concerned with. That said, while I don’t recommend placing too much weight on designing for this group, I do believe it’s a mistake not to consider their needs. Pulling off a win-win effort that enables this group to hit their goals tends to be a self-reinforcing success for a company.

Wrap Up

If you only take one thing from this article, know that accommodating anything less than every group of users in your designs is a Bad Thing.

Imagine that your executive team has seen the effect that your team’s UX design and development work has had on the bottom line – and so they foster a culture that values and encourages such efforts on an ongoing basis. This belief is folded into the company’s core values, and soon the sales, support and product development teams are all on the same page.

Your external users consistently see improvements, enjoy using your product and feel that their feedback is valued and acted upon. Inevitably these happy professionals pass those benefits on to their own customers . For our patients user group that manifested through cost savings, less time in the waiting room or waiting on a surgery date, and better quality of care.

Your internal users don’t have to jump through hoops to support the customers since the support tools they have been given are performant, intuitive and easy to use.

Wouldn’t that be a beautiful place to work? Are you ready to make it happen?

Thoughts On Proprioceptive Feedback

The literature:
Spatial Updating Of Self-Position And Orientation During Real, Imagined, And Virtual Locomotion (1998)

For efficient navigational search humans require full physical movement but not a rich visual scene.

The research done by Klatzky, Loomis, et al. as well as that of Ruddle and Lessels both indicate that proprioceptive feedback is a crucial factor in our ability to accurately gauge distance, size, heading and rate of movement. While my own experience echoes their findings, the reading left me with a couple questions.

First, what are the differentiating factors that separate those of us with what appears to be a more developed innate sense of direction (or perhaps a more advanced and accurate sense of place) from those who have difficulty with even the most rudimentary way finding operations when removed from familiar environments? Are there biological factors at play, or are the differences primarily acquired through life experience? Can we train to be more receptive to proprioceptive feedback, learn to interpret it more accurately, or are we consigned to our genetically disposed navigational fates, as it were?

Second, what are the implications of this kind of research on purely digital mediums, in which physical feedback is minimal or nonexistent? Are there natural corollaries between physical locomotion or visual perception and our navigation of pages on the web or through various states of an application? Could connections between these modes of ‘navigation’ be yoked more efficiently, enhancing a user’s innate ability to find their way about within a complex application?

What do you think?

Design Constraints Are Awesome

While reading some material recently I was particularly struck by a correlation between the sentiment of “designing for monochrome first” (for color deficient users) and the design movement termed “Mobile First”.

In both cases, the designer aims to build their interface elements such that the largest % possible of users will have accessibility to the data, based on the real and perceived limitations of the environmental factors imposed. After baseline accessibility and usability you can worry about nuances and aesthetics.

Monochromatic vision strips the designer of color-based tools and techniques, forcing you to fallback to the use of shape, contour, contrast and pattern. The Mobile First design sensibility forces the designer to carefully prioritize what elements of the design are truly needed to accomplish the goal(s) of the product, framed within the limits imposed by a smaller display. You also have to consider the contextual differences in usage between a mobile device and a desktop computer, and within the vastly different feature sets of modern devices.

I often hear about project constraints in terms of drawbacks, of obstacles to building the perfect widget. It’s much more helpful to think of constraints as helpful wayfinding elements on the road to successful project definition. If you know what they are, you won’t waste time in rabbit holes and you’ll be able to focus your time and attention on crafting the best product possible – one that will meet the unique needs of your users, whether or not they can see colors and regardless of what they’re using to access your offerings.

Thoughts On Medical Decision Making

Original article by Jerome Groopman

We all fall victim to habitual behaviors, and more so when we are unable to focus sufficient attention on tasks at hand, believing (consciously or unconsciously) that we can accomplish some process or task without conscious thought, instead thinking about ‘more pressing’ matters.

What is more difficult to detect are those biases not based on habit, but instead on other factors. Groopman’s article on medical decision making explored this issue in the light of decisions made every day by physicians in practices and hospitals across the world.

Several types of errors were explored, including Representativeness error (thinking that is overly influenced by what is typically true), Availability error (the tendency to judge likelihood of an event by how easy relevant examples come to mind), confirmation bias error (cognitive cherry picking – confirming what you expect to find by selectively accepting or ignoring information) and affective error (making decisions based on what you wish to be true).

The stories he shared demonstrate how a very skilled and educated doctor can make incredibly dangerous mistakes, due in some cases to the fast-paced world of medicine but in other in reaction to common human urges such as the desire to be merciful and spare a patient embarrassment or further fatiguing tests.

At my workplace we are tasked with making medical industry communication more secure and much more efficient – resulting in better patient care and increased physician and clinician satisfaction. After reading this article and having learned a great deal about how complex the communication needs of a hospital or practice have become, I have to wonder how many mistakes are made due to the very real problems of workflow dissolution and workplace communication breakdowns. How many errors of the classes described by Groopman could be avoided or reduced in severity through more frequent and higher quality peer-to-peer interactions in the medical industry?

GapMinder Data Analysis

In my HCI cognitive science class we’ve been studying visualization and how a given interface can enhance our mental processing power, bringing more of our wits to bear on a challenge. Here’s a look at comparing a few layers of data as reported by two very different nations.

Denmark vs. USA – Charitable giving related to income & life expectancy

I chose to compare the nations of Denmark and the United States, examining their respective records of charitable giving and comparing that to each nations’ income per person and their life expectancy. The data available ran from 1960 to 2008, and so it’s worth noting that the period studied spanned several wars with worldwide impact, numerous financial recessions and a gradual but accelerating trend of climate change.

The United States
The United States in 1960 was quite a charitable one, donating 0.54% of the gross national income (GNI) while only reporting $18,175 in income per person. We had a change of heart it would seem, as the % of GNI given to charity fell steadily for 37 years before finally ending at 0.18% of GNI in 2008.

During this period, while our incomes rose by $24k and our life expectancy by 8 years we gave 0.54% less to charities.

Denmark
Denmark in 1960 was a hard place, donating only 0.09% of their GNI while reporting only $11,569 in income per person. They seem to have buckled down and gotten industrious, as the % of GNI given to charity rose for 21 years to 1.03%, with a high of 1.06% before finally ending at 0.82% of GNI in 2008.

During this period, their incomes rose by $20k and their life expectancy by 6 years. In the end Danes increased their charitable giving by a staggering 0.97% over the period.

Reflections
An interesting measure to add to this comparison would be an index of reported happiness & contentment – does charity or income have a greater effect on happiness?

I would also have enjoyed seeing an overlay of world events across political, economic and climate scopes, relating those factors into the changes in life expectancy, income and charitable giving.

The animation was quite helpful, and illustrated the rate of change between compared parameters over the lengthy collection of data ranging over 48 years, clearly calling out the rapid rise of Denmark’s charity while the USA gave away less and less each year.

It’s purely correlative, but it appears that given the much larger percentage they gave to charity (from their noticeably lower income) the Danish were not overly burdened and lived to nearly the same age. Many factors could have been at play, but I’m given to lean towards the old adage that money CAN bring happiness as long as you spend it on others.

Using Vision To Think (a nod to Stuart Card)

In an HCI class I’m taking currently, we’re studying the cognitive science behind the long human history of visual-spatial displays. We’re talking caveman drawings up to the latest in Minority Report-style virtual interactive displays – fun stuff!!

Here’s an article to soak up if you’re interested in this kind of stuff: The Cognitive Science of Visual-Spatial Displays: Implications for Design

And here’s some thoughts of my own about that article:

More than anything else, this week’s reading of Mary Hegarty’s paper on the science of visual displays made me realize why it’s much easier for visually-minded folks like myself to understand something best when we’re able to interact with a subject on a visual level.

“Representations that are informationally equivalent (contain the same information) are not necessarily computationally equivalent”…
“task performance can be dramatically different with different visual displays of the same information”…

These are dead on. Whenever I’ve encountered a complex problem, whether facing it alone or in a small group (or mentorship, etc.) I often kick off the process or discussion with something along the lines of “Are there other ways I/we can look at the issue?” This is helpful in many cases because in representing the object or process with an iconic, relational or complex display allows us to augment our thinking, to enhance our understanding and to bring additional inferences or insights to bear.

Displays allow us to externalize both the storage and the organization of a massive amount of data, freeing up our fragile and limited minds to process that data in different ways. It also lets us explore the relationships between groupings of related elements, i.e. chunking – freeing us to a degree from the limitations of short term memory by compressing these complex associations or concepts into a fewer number comprehensible objects.

I understand the world through my visualizations of it, both in reality and in my internalized efforts to understand the world around me, so my favorite blurb by far was the author’s reference to Stuart Card’s sentiment “Using vision to think”.

Notes from CodeStock 2014′s “Regular Expressions” presentation

Brian Friesen’s talk on Regular Expressions was probably my favorite of the conference. You gotta admire a guy who builds a regular expression engine to properly demo and train folks up on the ‘devil’s language’ (as I and others I’ve known have called it)… Folks that hate regex and those that live and breathe the stuff all got something from the session. Good stuff.

Regular Expressions – now you have two problems

Brian Friesen
@brianfriesen

Works at Quicken Loans (side note, I used QL last year – hands down the best UX I’ve ever seen in a mortgage product/service)

github.com/QuickenLoans/RegExpose

Regexper.com

Regular-expressions.info

The Bible:
Mastering Regular Expressions by Jeffery Friedl
– can read the first 2/5 of the book and you have enough
———————————————————————–

1. RegEx are hierarchical

Root node = the whole expression

ABC would tree out like this:

ABC – root
A – character literal
B – character literal
C – character literal

2. RegEx do their thing sequentially

A RegEx will match if each of its child nodes matches in sequence
After a match, the RegEx engine will continue trying to find further matches until it has covered the entire string.

RegEx are by default case-sensitive

Character classes are surrounded by square brackets
– for a range, use a dash.
– if you need a dash in the match, put it at the beginning of your set within square brackets
– you can also include specific characters or numbers to match against
– can include a-z and A-Z, or you can pass an additional param to ignore case
– a negated character class = add a “^” carat character before a match. ie [^a-f0-9] would ignore a-f

Shorthand matches
– \d is the same as [0-9]
– \D is the same as [^0-9]
– \s matches whitespace chars
– \w is the same as any word character, meaning [A-Za-z0-9_]
– . matches any character, depending on options (ie except for new line character)

Alternation
(it’s a pipe dream)

| character means “or”
– linos|tigers|bears ‘lions’ would match, but regExp doesn’t know if its the BEST match, so it saves state (a breadcrumb) and moves to check the other choices.
– if a match hits on the last option in a set of choices, no state will be saved, no breadcrumbs etc.

Quantifiers (quantifiers are always AFTER)
(Because sometimes, quantity trumps quality)

Greedy Quantifiers (greedy means quantifier always wants more, ie. will keep going)
——————
– ? = optional
– * = will match zero, will match many
– PO*P would match “PP” as well as “POOP”
– + = must match at least once to succeed
– NO+! would match “NO!” as well as “NOOOOOOOOOOO!”
– {} = match a specific number of things
– \d{3} = this means match exactly 3 digits
– \d{3,15} = this means match at least 3, but up to 15
– \d{3,} = this means match at least 3 with no high end limit

Ultimate lazy quantifier: .*

Causion against using “*.” – can lead to a match failing since the greedy ‘any character as many as possible’ matching could lead to skipping more specific matches after the *.

Lazy Quantifiers – will only match as much as is needed, without going overboard
Once a match is made it will pass control to the next match paramater until it’s needed again…
—————-
.*? = Lazy
{3,5}? = also Lazy (in this case, once 3 digits were matched, the next node in regexp would be matched)

– ab.*?cd would match “abc12345cd” with the lazy quantifier returning to the ‘c’ character repeatedly before going back to the next number character

More alternation
—————-
(?:white|dog|brick) house
– match against “dog house”

Quantifers + grouping
———————
(?:NaN)+
– match against “NaNNaNNaNNaNNaN”

Notes from CodeStock 2014′s “Angular Is Awesome” presentation

Josh walked us through building a simple Angular app, using the lessons learned from Wintellect’s recent dev and launch of a global enterprise software app.

Angular is for AWESOME!
Josh Carroll
@jwcarroll
technofattie.com

The code
github.com/jwcarroll.ng-contacts

directives – typically an attribute on an element

————————————————-
ng-app
ng-init (used to inject a title in his demo)
– ng-init=”contacts=[bob1,bob2,bob3]”
– plugged it in with {{title}}
ng-model
– he bound an input to the ‘title’ var he had leveraged in the injected title
– ng-model=’title’
ng-repeat
-ng-repeat=”contact in contacts”>{{contact}}
ng-search
– “searching by ‘{{search}}'”
ng-if
– truthy comparison results in rendering the stuff
– empty string resolves to 0 so nothing would render

ng-controller – find the controller, and hand off DOM control to the controller by adding ng-controller to an element (ie a containing element)
– ng-controller contactListCtrl as ctrl (do a one time all inclusive effort to make $scope aware of all your controller’s functionality)

ng-view (a new html tag by virtue of angular)
– ala

ng-animate – a way to harness css3 animations

General
pipes (|) are filters. (think gulp)
– takes in something and returns something
– example was var AgeFilter (which returned a function as the filter)

$http as a param passed to function
– this.$http.prop etc.
– _this.$http.get(){
.success(callback) //this is a promise
}
– same for delete, etc

Modules
– used an IFFE function
– a module is a container holding the stuff related to the application

Controllers – just a JS object
$inject = a way to tell NG you need a component (used with $scope)
– $scope being where the data binding happens

Lodash (_. prefix)

Services
– must register a service
– can inject a service into a controller

Routing
– ngRoute (out of the box routing within angular)
– colon (:) is a routing parameter
– as in /contact/:contactId?
– routing as SPA method.. each route can be passed a different controllers (essentially a path-specific template) etc.

Handling when a route fails (ie error handling)
– he made a new js file: routeError.js (again, directive is a new html tag)
– which contained a new directive