Summer Synopsis

As my internship comes to a close I reflect on the highlights of my summer and all of the new things I learned. To start, interning at Industry Dive was a very beneficial experience. The amount I learned about web design as well as the digital media industry and start-up culture was astounding. Here are ten lessons I learned this summer either from the intern program, the design team or from the company. Some of these may seem obvious or cliche but often times you have to experience something before realizing the truth in the statement. If you want more specific technical lessons and the projects I worked on you can find them in the rest of the blog posts.

  1. Office culture matters

    One thing that Industry Dive really brags about is their office culture and the fact they have been selected as a Washington, DC best place to work. I didn’t understand the importance of this until I started working here. Really enjoying where you work and who you work with makes the tasks seem much easier. Feeling comfortable to ask questions and recommend new ideas allows everyone to feel like they are a pivotal part of the team.

    20160721_185230
    Industry Dive employees on the company boat cruise!
  2. Never stop learning

    Our weekly company meetings surprised me in that I didn’t expect to enjoy them as much as I did. The meetings consisted of each department sharing what they were working on and allowed people to celebrate co-workers accomplishments. At the end of the meeting a different department presented what they do on a daily basis. The fact that everyone wanted to learn about each other reflects the overarching collaborative and inquisitive environment.

  3. Coffee is a way to network

    Another company wide event was the coffee challenge. The challenge tasks each new hire to take different co-workers out to coffee. The hope is to encourage all new hires to interact with other departments one-on-one and make personal connections. Since I am typically more of an introverted person this gave me a way to reach out to individuals and push myself out of my comfort zone. This taught me the importance of getting to know different people throughout the office even if they aren’t in your department. It also inadvertently taught me to tolerate coffee.

  4. Group projects will always be hard

    Part of the internship program was the internship project. The challenge was for the five interns to create a data driven featured article. In the end we were very proud of our final product but it wasn’t always a seamless process. Group projects will always face challenges around divvying up roles and solving unanticipated road bumps. The difference compared to school projects was that all of the interns wanted to succeed and contribute to the project. I found working with a group of intelligent individuals on a real-world project was much more satisfying than a grade.

    interns_2016
    Industry Dive 2016 summer interns
  5. Dogs are great work partners

    A fun highlight at Industry Dive was the open dog policy where employees can bring their dog in for the day. Being able to work with a dog at your feet was definitely something new and brought smiles to everyone at the company. I grew up with two dogs so it was great getting to have some canine friends around. I also learned that I would probably never bring a dog in as I personally wouldn’t be able to get anything done.

  6. Resumes don’t have to have everything but the kitchen sink

    Part of the internship program was the resume review. I was given the opportunity to send my resume to my supervisor for feedback. Initially my resume included every accomplishment I had ever achieved since my freshman year. The review helped me focus my resume and set me up for success for when I decide to apply to jobs.

  7. Startups have a lot to offer

    One of the most impactful lessons from this summer was realizing the opportunities that startups hold. The variety and scope of projects I was able to work on wouldn’t be possible at a larger company where roles are much more cut and dry. Seeing just how the design team could offer up new ideas that were implemented in a quick time frame really opened my eyes to the benefits of small companies. While startups may not hold the prestige of working for a household name, being able to make a difference and shape a product is something that I have always considered a career goal.

    corevalues

  8. Career paths are not linear

    Another internship program event was the new hire panel. Note that at Industry Dive “new hire” is relative term since the company has doubled in size in the past year and new hires are abundant. During this event all of the interns were able to hear about how different individuals ended up at the company. The most surprising aspect was the fact that not many of the employees graduated expecting to be in the role they are in now. While I know I am interested in web design I understand I probably can’t predict the exact role I will fill come a few years after graduation.

  9. Gifs are still relevant

    One prominent part of the Industry Dive community were gifs. I quickly learned that my gif knowledge and experience are greatly lacking. While I still have a lot of room for improvement I have learned about making, finding and sending gifs.

  10. There is always a way to improve

    The final lesson I learned from the design department was that you can always be improving and optimizing. While I was here the process for different design team projects was continually being optimized and questioned. Rather than just settling on something that worked the desire to be constantly improving drove all the tech and design decisions. In just my ten weeks a new mobile site was launched, a new mobile application was drafted, a new desktop site was started and a new design workflow was developed.

    giphy (3)

Advertisements

UI Makeover – Data Part 2

As the internship project wrapped up, another exciting thing happened in the office this past week: the deployment of the new mobile application. Both the design and tech teams celebrated the successful launch of the new design onto the Utility Dive mobile site. Once the site seems stable and if no large issues arise, then the tech team will deploy it across the other industries. While I was not an integral part of the redesign, I was able to provide user feedback and help with the test of the site across platforms.

With both of these exciting projects coming to a close, I had to start making moves on the data visualization tool (which I introduced in the Internal User Testing post). I left off with the next steps for the internal data tool being to determine the requirements and prioritize them so that I could start implementing them. The first thing I did was take all five user interviews and list out all of the desired features and sort them into front-end or back-end. The front-end issues were the ones that I thought I could address before the end of the internship. I then further divided them into either a priority or reach goal. This allowed for me to show which goals the users had brought up that were good ideas, but were maybe not quite as feasible. I then added all of the goals (both priority and reach) to GitHub as individual issues. I began with around twenty issues but this number fluctuated as I learned more about Shiny applications and R.

Challenge and Approach

My challenge was to take all of the front-end issues and solve them using my HTML/CSS experience, along with learning how to solve them if it were a Shiny specific design issue. The issues I solved can be broken down into two categories: visual and accessibility adjustments. The main focus for the visual challenge was to incorporate an external CSS sheet so that I could have easier access to the design styles. I ended up using the ported SASS for Bootstrap since the Shiny apps are built on top of Bootstrap and Bootstrap is initially built with LESS. Once I had the SASS files I created a custom file to override the Bootstrap styles when necessary. While this is more extensive than just attaching a CSS file, it allows for easier customization in the future.

The visual issues involved not only adding a stylesheet but also figuring out how to responsively size the graphs and tables. I also addressed the complaints concerning the visual hierarchy of the tables versus the graphs and reorganized accordingly. The accessibility adjustments consisted of helping make the tables easier to use as well as indicating when the application was loading. To improve the tables I added default sorting from descending order, changed the labels to be semantic rather than the variable names, and made the sorting arrows more visible. To confront the loading issue (the user couldn’t tell when the page is loading), I added an overlay that appears whenever the application is either initially loading or recalculating. Overall, all of these small changes made a very large difference in the user experience.

Results

Visual Improvements

The main visual improvements were the addition of a stylesheet as well as making the graphs and tables responsive. As you can see in the first screenshot, the graph extended past the edge of the screen.

Screen Shot 2016-08-08 at 5.31.19 PM

Screen Shot 2016-08-08 at 5.31.01 PM

I also updated the Dives page to better reflect the users priorities. Rather than having a table that showed only one data point I instead called out specific values.

Accessibility Improvements

With the addition of a loading screen, the user no longer has to wonder if the application has frozen or if it is just still calculating the results they requested.

loading_screan

As for the tables, the most apparent adjustment is the styles. There are also improvements in the sorting capabilities with clear column names and easy to find sort features as well as the removal of the non-intuitive bottom search feature.

I also added a legend for the graphs to help the user know what each line represents. In the left column I added helper text for the y-axis dropdown and added delete (x) indicators on the multi-select filter.

 

The Intern Project – Part 2

As the month of July came to a close, I continued working on the intern project and finalized the new email blasts. I completed three different designs for the email blasts based off of the original template: webinar, survey and lesson. Each template design borrows from the same premise of being easily customizable and attention grabbing, while remaining unique in style. The webinar template includes speaker profiles, the survey template has a call-to-action above the fold, and the lesson template incorporates iconography. Together, the emails create a consistent message but also allow for the ad operations team to include topic specific details for each email blast.

The rest of the week I focused on the internship project as we prepared for the featured articles to be published. The editorial intern worked hard to finish each of the pieces and have them reviewed by publication editors while the tech intern and I kept busy finalizing the layout and design details. We met multiple times to discuss what the design requirements would be and how the aesthetic would be consistent across the three publications.

Challenge

Previously, I had broken down the project into three parts: design aesthetics, data visualization, and compartmentalized articles. While I drew off of these inspirations for the final iteration, I also had the challenge of recognizing the necessity of stepping away from some of the more intricate ideas. Most of the deviation stemmed from the fact that the content management system restricted the scope of the design customization and also that the article needed to be stylistically consistent with previous featured articles. With that being the case I focused primarily on the pull-quotes, chart design and graph stylization.

Approach and Results

Pull Quotes

The approach for the pull-quotes was to look at pull-quote styling throughout other publications and see what made them successful. Using my inspirations, I decided that I wanted a headshot of the speaker to incorporate more photography throughout the piece. I also wanted to include a little bit of red to make it stand out more.

Screen Shot 2016-07-20 at 10.28.51 AM.png

Tables

The table took a few iterations before the design successfully supported the data. The challenge here was that while I wanted to incorporate color, at first it caused more confusion rather than helping the message. By removing the strong color from the first iteration and emphasizing the US data over the state data I found the chart to be more successful.

Graphs

Finally I tackled the graph stylization. The first challenge for the graphs was that the data itself was not what we had anticipated. Initially, we wanted to use line graphs to show the difference over time of worker populations. However, we soon realized that the difference was not significant enough to show visually in this manner as it was often less than 1%. I then tried different ways of communicating the same idea such as the percent difference. While this was interesting to look at it, the graph was even more confusing. Finally I decided on a donut chart; though this chart is less powerful due to less data, it is more direct in its purpose. The chart now allowed the user to see the worker profile of the current year in a clear way.

Check us out!

Utility Dive

Construction Dive

Education Dive

 

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"/>

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.

Mobile Application Sprints

Leading up to the Fourth of July in Washington DC, energy was high throughout the city. While the design team was mainly focused on timely issues, we were also looking ahead to design a new mobile application.I came on board during the middle of the process, after they had discussed initial requirements and created very rough wireframes, but there were still a few more steps to get through. The first was to create high fidelity mockups to use when pitching the new application to the founders. Our process for making these mockups was to have two applications sprints: one for the on-boarding process and one for a potential newsfeed design.

Having interned at a creative company before, I had heard the terms used in agile development like “sprint” and “scrum” but I hadn’t done sprints exactly like these. Generally, a sprint requires that a specific task be completed and ready to review in a short amount of time. How our sprint worked was to define specific design requirements and then have each creative member design a possible mockup in a short set timeframe. Important resources I used for this process were Keynote, Appealing and Mobile Patterns. Keynote was used for the actual creation of the mockups and, having never owned a Mac, this was my first time using it. The difference between Keynote and PowerPoint (and the reason it was our program of choice) is the magic move feature. This allows you to animate the mockup to mimic how the transitions would look after development. Appealing was used as inspiration for these animations because it provided examples of transitions that people have used in design. Mobile Patterns was used for general inspiration concerning mockup design to show the different ways common mobile app features have been designed.

Screen Shot 2016-06-30 at 5.20.43 PM
Screenshot of Appealing – Used for transition inspiration

Challenge

There were two different app sprints that we went through for design development. The first was the on-boarding process which involved how to create an account and create a personalized news feed. The second was to design the actual news feed with filter options. For both of these sprints, we were given only an hour and a half to create the mockups from scratch. The only thing we were provided with ahead of time were styled buttons, form elements and Android/iOS standard features. The limited time frame would be the biggest challenge, but learning how to use Keynote magic move and creating clean designs quickly would also be tough.

Approach

My process for these two sprints varied slightly as I learned from the first one and made changes to my process for the second. I realized after my first try that I should have looked at more inspiration for the animations and mockups. My first sprint design was very standard and did not push the envelope in terms of design and aesthetics. I also learned that I should go for quality over quantity. I tried to achieve all of the requirements in the first sprint rather than doing a bit less and having better looking designs. When designing, I also had a tendency to get caught up in insignificant details which is not ideal when working on a very short deadline. For my second sprint, I took more time looking at inspiration and made sure that each slide looked well formatted before moving onto the next. I also cut out the features that could be designed later. The biggest challenge for the second sprint was conceptualizing how the sorting and filtering features would work for the news feed.

Results

Overall both of my sprint mockups were helpful for the team in deciding where we wanted to go with the designs. Small things like including a “skip” button or a “select all” feature are the key take-aways we were hoping to find from these sprints. While the actual app will not look like my designs, it will borrow from their ideas and the challenges they overcome.

Sprint #1

Sprint #2