Author: kcrawford2

Posted on by

Data Visualizations – What’s Missing?

“It’s really just a report.  We’ll put in a table.”

This quote, or a variation of it, has been uttered by countless developers looking to shave some time off their scope-inflated corporate mandated deadline.  This can be translated in UX terms as “All those cool data visualizations that you created now can be collectively categorized as ‘Future Enhancements'”.  Or in other terms, “portfolio creative exercises”, since typically the likelihood of project inclusion falls right around “Photographing a Sasquatch riding a Unicorn emerging from Atlantis”. 

Tabular Data in an application typically generates the knee jerk reaction of beating head against wall for most UX designers/developers.  Cognitively, it’s easier for the human mind to comprehend and absorb useful data when presented in some well designed chart, graph, or other visual display of information, right?

Actually, in my opinion, it’s contextual.  Some research studies show that there isn’t a clear advantage to tabular display of data over charts or graphs, or even support the opposite.

“We found that displaying data in a table lead to more accurate answers than the choice of bar charts or pie charts”

I can cite examples where complex visualizations take longer to comprehend than comparable tabular data, as well as examples to the contrary.  I believe there is enough evidence to demonstrate that contextual elements such as visualization type, context of data, labeling, legends, visual design, aspect ratio, screen resolution, or any other number of variables could influence studies towards one conclusion over another.  That said, I view research on this matter suspect, and potentially contextually biased.

Returning to the original problem, a decision based upon development ease and alternate internal influences that put well designed UX data visualizations at risk, what leverage can a UX professional utilize to overcome opposition to visualizations that can benefit the end user?  Especially if the research on graph/chart comparison to tabular data differs in findings?

Some might argue that tabular data is better than data visualizations.  Others might strongly oppose that view.  Rather than take a divisive position against those tasked with building your designs, I’d propose a more successful alternative that is backed by science.

I’ve found success in promoting a corporate policy that all data visualizations provide a toggle or alternative method of viewing the underlying tabular data that generates the visualization.  Think of Microsoft Excel and how each data visualization links to a set of tabular spreadsheet data points.  Whatever graphic component you use, in code, the data is most likely an array of data points…..data that is most easily displayed in a table.  Providing a toggle from graphic view to tabular view allows users to switch to the view that they can contextually comprehend more quickly.

Visualizations might in some context be superior to tabular data, but clearly superior to providing an either-or proposition is providing both options. 

Users that are visually engaged will be able to comprehend the visualization with user engagement.  Users that are more comfortable with tabular data absorption or visually impaired users will prefer the tabular format. 

It’s been my experience that setting the precedence, either by formal or informal policy, of offering both display view options has a higher likelihood for inclusion of data visualizations, even if it’s only because of the inherent nature of software teams to eradicate inconsistencies within the application.  And if the expectation is that each instance of visual data display will also have a table view, it’s far less likely to be edited from the project scope.

 In addition to having both view options, I’d also encourage that filtering options in one view also be included in the other view.  As a general rule, I view every chart, graph, or other visualization as only one half of what is to be included in the application.  Everything in the visualization is also in its corresponding table.  From a development perspective, tabular data is easy to present.  That’s exactly why it’s so common, a developer can take an array and build a dynamic table with minimal effort.  So defining a visualization AND adding a table to it is not a large development investment.  One could argue that it will speed QA testing by quickly providing an available reference table for the chart/graph.

Ultimately, by providing both options for your users, their comprehension will be faster or equal to providing a lone solution.  And consistency will allow users to anticipate and navigate view options through a learnt process over time.  That’s science that will not only benefit the users but also help keep the internal development focused on UX instead of being tempted to cut corners in the interest of internal development efficiency. 

Software should be built for the efficiency of those using the product as opposed to the convenience of those creating it.

Posted on by

All Buttons Are Not Created Equal

Each Button Element has a Purpose

Yes, it looks like a button.  But honestly any decent UX developer can make just about any HTML element look like a button.  Add a couple lines of JavaScript and they can effectively serve as a functional button.  So why would I want to use one markup type over the other?  Does it matter?

Yes, the definitions are different, and they each have specific purposes and advantages.  It’s good to learn semantically how to use each to its best advantage and know why using them correctly matters.

To begin, let’s look at the definition of each type of what many consider interchangeable buttons.

Button has the following attributes (w3c)

  •  autofocus
  • disabled
  • form
  • formaction
  • formenctype
  • formmethod
  • formnovalidate
  • formtarget
  • name
  • type
  • value

The Anchor tag  has the following attributes (w3c)

  • charset    
  • type       
  • name       
  • href   
  • hreflang   
  • rel        
  • rev        
  • accesskey  
  • shape      
  • coords     
  • tabindex   

Input type=submit has the following attributes (w3c)

  • formaction
  • formenctype
  • formmethod
  • formnovalidate
  • formtarget
  • name
  • value

Input type=reset has the following attributes (w3c)

  • name
  • value

Input type=button has the following attributes (w3c)

  • name
  • value

As you are able to see, these definitions are pretty distinct, and that’s by thoughtful design.  There are advantages to using the best choice.

But That’s Code and I Only Care if it LOOKS Like a Button

As the advocate for the User Experience, it is your responsibility to pay attention to these code decisions that can adversely affect the product users.  Anymore, just about every website or application will at some point impact accessibility.  If you serve the government in any capacity, it’s even mandated by legislation. 

Sightless users that utilize a JAWS screen reader to access the web are going to be at best inconvenienced and at worst hindered by the wrong decision.  For example, a JAWS user can navigate through all the links on a page by pressing the TAB key.  It helps them traverse to other content pages quickly.  Imagine the frustration if they have to tab through a styled button bar of action buttons defined as links that don’t lead to further content.  Similarly in forms mode, they can immediately jump to the next button by pressing the ‘B’ key.  If that button is defined as a link, the shortcut won’t work and you force the user to move through every form element individually.  Using the element that is best served for the context is not just good coding practice, it also lends itself to the best user experience.

So When and Why Would I Use These?

I’m not going to delve into all the reasons why you should or shouldn’t use each of these in this post.  The point of this is not to deliver a comprehensive thesis on each of the HTML element button types.  Ideally, it’s to inform you of their primary designed purpose so you are able to utilize the best solution.

The Anchor Tag – This markup element was intended to be a link to another URL resource.  Notice that one of the attributes is not ‘disabled’.   If you want your button to have a disabled state, the anchor tag is not your best element to use.  Generally, links to another URL should rarely look like a button, but there are instances where a large button call to action on a page will lead to another URL.

The Input Buttons, Submit, Reset, and Button – These were intended to be used with Forms, when the use is to collect a set of form data from a user.  Submit is specifically designed to submit the form action to the server for validation and storage.  Reset is designed to reset the form data…., only.  The input button type is designed for button actions within the form.  An example of this would be an employee selector button that opens a common modal window component to offer tools that allow a user to search a large employee database using filtered criteria.  As a general rule, only use these types in the context of a form.

The Button Tag – If it looks like a button, acts like a button, and triggers events like a button….., it should most likely be a button.  The Button element has several advantages to hyperlink buttons.  The disabled property allows a quick and effective way to disable a button that can be directly referenced in the CSS without adding a separate class to the element.  It also has attributes for handling form actions and is accessible.  I’ve found the 80/20 rule to be pretty close in real world usage that most of the time, the button tag is the best tag to use for a button element.  There are exceptions, but the better practice is to use the designed element for the task…….for the task.

Any other button styled HTML element – A span tag can look like a button.  So can a Div.  Or just about any other tag as well.  With JavaScript listeners attached, they can also function like one.  But UNLESS THERE IS A REALLY GOOD REASON, why would anyone want to go to strange coding to do something that the Button tag already does well?  Typically, these are just poor coding practices.  I personally have used them, but the coder in me cringes when I have.  Best practice is to avoid these options as much as possible.

The Bottom Line

There are no code police running around the internet looking for code infringements. So why worry about using the ‘best’ option in the application.

  1. To make YOUR LIFE EASIER.  Using the best option can solve some problems with less effort on your part.
  2. To help those that edit your code after you move on to that next great opportunity make changes without cursing you.
  3. To help the UX be more accessible
  4. To keep the code concise,…… and fast.
  5. To keep the CSS clean and efficient. (The more one off styles you have, the larger your CSS files)
  6. Credibility.  The developers already hold a marginal respect for UX team members.  Eroding it further with poor code practices will be detrimental on future battles.

That said, UX is not the only stakeholder in the game.  If product or the development team need to define it differently, break the rules for the greater good of the finished product.