Responsive Images

While the intern project is still in full swing, I have also been working on GitHub issues for the front-facing websites. This was my first time using GitHub for a multiple person, large scale project. While I’ve dabbled in it previously for school projects, I had not used it at its full capacity until this project. The hardest part of getting into GitHub was remembering the terminal commands and knowing when and where to use them. After a couple iterations, I was able to smoothly interact with the version control system. One aspect that I really appreciated while working with the Industry Dive repositories was the streamlined process. All issues and pull requests had templates, creating a consistent bug and solution reporting process. Another thing I was introduced to with these projects was Sass, a CSS extension language. The only adjustment that I had to make when using Sass was making sure that I understood all of the variables and nesting structures.

Two of the issues I was assigned concerned responsively serving images. My only experience with responsive images up until this point was with retina and non-retina images. To fully understand the breadth of options for responsive images I took the Udacity course Responsive Images. This helped me understand possible solutions to make the images responsive. Another great reference that helped after I had taken the course was A List Apart’s article Responsive Images in Practice. Together both of these resources helped me pick the best solutions for my issues.

Screen Shot 2016-07-21 at 12.28.48 PM
The Respsonive Image Udacity Course

Challenge

My task involving serving responsive images was more complicated than I anticipated. Both issues involved three types of images: background images in CSS, fixed size icons, and fluid width images. Each one of these required a slightly different solution given their specific case: the background images needed media queries since they were in CSS; the fixed size icons would just need to have a retina and non-retina option; and the fluid width images would need srcset and sizes. The fixed size icons were the easiest because they just need two sizes and the background images were straightforward as well since I had used media queries before. The most challenging issue was the fluid width images.

Approach

The approach I took for the fluid width images was to first figure out all of my use cases. I ended up boiling it down to five options: small (non-retina), small (retina), medium (non-retina), medium (retina) and large.

Once I determined the options, I then had to figure out what breakpoints the site was using. It turned out there was a specific rem size for a small and medium breakpoint. Then I had to determine the largest image size needed for each option and resize the images accordingly. I then implemented either the media queries for the background-images or the srcset and size for the fluid width. The last step was to test that each device was being served the correct image. I used the Chrome developer tools to test the site on different devices. The one caveat was that I had to make custom non-retina devices to test those use cases.

Results

The results were images being served correctly. Below is the code for an example of one of the fluid width images. The sizes are calculated based off of the grid being used. The .66 is the 66% that the image is taking up of the screen and the 1.875rem is the padding around the image. The final size is 100 because in mobile it takes up the entire screen. I ended up only needing three image sizes for the five use cases since the large (1200) could be used for both large and medium (retina) and the medium (800) could be used for both medium (non-retina) and small (retina).

<img srcset="/brandstudio_600.jpg 600w, 
/brandstudio_800.jpg 800w, /brandstudio_1200.jpg 1200w"
sizes="(min-width: 40.0625em) calc((.66*100vw)-1.875rem),
(min-width: 64.0625em) calc((.66*62.5rem)-1.875rem), 100vw"
src="/brandstudio_800.jpg" alt="Responsive"/>
Advertisements

The Intern Project – Part 1

To start, the first thing I’ve learned this week is that I will take a dry hot day (aka Colorado) over a humid hot day any time during the summer. As the heats been rising this week the design and development teams have stayed inside preparing to start internally pushing out parts of the mobile redesign. While that’s been their main focus, I have been meeting with the other interns to start making real progress on the intern project. The task for the summer interns was to produce a data-driven feature article that is applicable to multiple industries. Some essential tools for this project were examples and inspiration articles. While a data-driven feature sounds straightforward, it helped to see how other news companies have addressed these types of stories. My main resources for research were the Washington Post Graphics, New York Times Graphics and the Brookings Essays.

For this project there are five interns: data analyst, front-end development, editorial, audience development and myself, front-end design. All together we form a miniature editorial company. The project was presented to us broken down into five steps:

  1. Choose the topic
  2. Find data
  3. Build a story plan
  4. Report and design
  5. Build a publicity plan
  6. Present to the company

We are now on step four, as the past few weeks have focused on steps one through three. The hardest part of those three steps was to choose a topic with easily accessible data and a reasonable scope. A lot of our concepts either sounded really good on paper and then didn’t have data readily available, or had readily available data but were very broad and could easily get out of hand. The overall concept we chose to move forward with was the changing demographics of workers in specific industries.

Challenge

Once we got to step four I had to start finding inspiration and developing a game plan for the design of the story. Since the time frame for the reporting of the story is so short, we have found that all the interns have to simultaneously work on the project. The challenge for myself and the front-end developer intern is that we have to try and anticipate the types of things that will be needed to help support the articles.

Approach

Our process began with the front-end developer intern and myself sitting down and analyzing the current state of the project. We realized that while we knew the article topics we didn’t have a ton of specific information to go off of just yet. During our meeting we agreed on our expectation for what we could produce in the time frame and the goals for the articles. The second time we met we brought inspiration we had found and specific ideas concerning the article. I contributed ideas concerning: overall design aesthetic, data visualization inspiration, and examples of compartmentalized articles.

Results

My results are the examples and inspirations that I have found for the design concept.

Design aesthetic: The examples I found for aesthetic inspiration helped show the rest of the team what I am envisioning and what I felt was manageable in our time frame. I found that I was leaning towards examples with large usage of white space, vector based graphics and minimal color.

Screen Shot 2016-07-14 at 3.09.46 PM

Courtesy of NY Times

Data Visualization: The aspects I focused on when looking for data visualization inspiration were examples with clear purpose and easy to scan. I also tried to find examples that were consistent with my intended design aesthetic.

Screen Shot 2016-07-14 at 3.14.32 PM

Courtesy of NPR

Compartmentalized articles: These inspirations were helpful to show how to break up stories and have a consistent design across different ideas. Since the project consists of three articles with three parts, making each story unique yet still consistent within an overall design theme will be important.

Screen Shot 2016-07-14 at 3.16.10 PM

Courtesy of Washington Post

Internal User Testing – Data Part 1

With a short timeframe due to the holiday, this week was a mix of finishing up dwindling projects and starting new ones. One project that has been consistent over the past few weeks is an internal project for the data team. The project concerns a web application for data visualizations of the company’s subscriber population. Though it is mostly the data team’s assignment, the design team was now tasked with improving the overall user experience (UX).

This internal site is written in R and uses Shiny to create a web application; R is a programming language for statistical computing and data analysis and Shiny is an open source R package that lets you create visual web applications. While our data team had taken the time to layout the application so that it was usable, they did not have the time to customize or optimize the framework. While I have never worked with R or Shiny, there is extensive documentation about customizing the appearance of the applications but that will be a challenge for another week). The task for this week was to have the application undergo usability testing to see how our internal teams use this data to find what they need to know. Usability testing is part of UX design and tests to make sure that the site is successful in letting the user achieve their goals.  

Screen Shot 2016-07-07 at 5.34.24 PM
An example Shiny application UI

Challenge

The task for this project was to bring in different internal users and see how they use the site. The first step was to make sure that all potential users were being tested, so the final interview list consisted of Sales, Editorial and C-level executives. My job was to then take an example usability test script and apply it to these interviews to make sure that we were answering all the questions needed for the redesign. The challenge for these interviews was to actually conduct them and effectively follow the script. I had to cover all of the necessary questions but also draw on past interviews by bringing in new questions that people had brought up. For example, the idea of an email alert had been discussed and I needed to adjust the script so that we could see if that would be helpful for other users.

Approach

For the interviews I followed a 5 step interview process:


icons-051. Explain the purpose of the meeting – 
The key was to make sure that the user understood the product but also didn’t have too much information. If I explained too much then they wouldn’t be able to make their own assessments or judgements.


icons-012. Ask the user about his/her goals – 
I found this to be a very important part of the process because it brought to light new requirements. While I had a general idea of user goals, their answers always had a few things I hadn’t considered.


icons-023. Find out how the user is currently trying to obtain these goals – 
This step allowed for me to understand how often the user would be using the system and which pieces needed to be more easily accessible if they were used frequently.


icons-034. Test UI of tool – 
Testing the UI tool was the meat of the interview. It showed how the user currently uses the tool and where they run into problems. It also allowed for the interviewee to critique the currently layout and verbalize their thought process when using the interface.


icons-045. Find out if anyone else should be interviewed – 
This question helped with defining the users to be tested and let me know who they thought might have a different take on the application.

Results

While there are still a few more interviews to go, each interview so far has brought to light new issues and goals. The next step after user interviews is determining the requirements for the new design and prioritizing each requirement as needed. After that it is to start either mocking up pages, if the changes are dramatic, or start implementing the actual adjustments.

As for the interviews so far, some large takeaways include:

  • Minimizing the graph sizes because users want data first and foremost.
  • Summary statistics can be more powerful than all of the data at once.
  • Some features may seem intuitive, but without direction details can be overlooked.