UX/UI case study: Choosing website media to provide an optimal user experience
In this article, I provide a summary of a case study I created to test media quality in a real-world scenario: a hand-coded website. Specifically, I was looking for answers to the following questions:
1. What are the effects of file size on page load times?
2. Do any differences in media quality exist on different browsers?
3. What are the effects of screen size on media quality?
4. How do questions 1–3, above, affect the overall user experience?
I wanted to use this information to make better decisions as to the file type and size I would integrate into websites. I also wondered when it was appropriate to use algorithms such as lazy load and srcset in my code, and when it would not be necessary. Finally and perhaps most importantly, I wanted the answers to these questions so that I would have data to back up my reasoning when discussing options for website design with a stakeholder.
Preliminary research: Browser support of various CODECs
Audio
To summarize the table above:
- All four major browsers (Chrome, Edge, Firefox, and Safari) support AAC, FLAC, MP3, and Opus.
- Chrome, Edge (17 and above), and Firefox support Vorbis. Safari does not.
- Safari is the only browser to support ALAC.
- IE supports only AAC and MP3.
(Source: MDN web docs. https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Audio_codecs)
Video
Summary of the table:
- All four major browsers support H.264. Additionally, IE 9 supports H.264.
- Edge, IE 11, and Safari 11 support H.265. Chrome and Firefox do not.
(Source: MDN web docs. https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs)
Adding the images to the website
Calculating image size. I set a breakpoint at 35rem for mobile/desktop and set a desktop max-width to 64rem. This means mobile images were cropped at width: 560px and desktop hero image was width:1024px. I planned for the images to run three across on the desktop layout, meaning each gallery image needed to be 325px wide.
Choosing a compression method. Because the completed site would be image- and video-heavy, I wanted the images to be as small as possible without a noticeable decrease in quality. GIF files are small, but noticeably inferior. PNG files are top-quality, but also larger, and the increased quality is most noticeable in images that include text or sharp lines. My photographs did not include either, nor did they need transparency, so I felt confident in compressing the images as JPGs. Because JPGs are lossy, I compressed each image only once, from the original file.
Adding the video to the website
Choosing the CODEC. I chose h.264 because it is supported by all four major browsers: Chrome, Edge, Firefox, and Safari. Neither Firefox nor Chrome support h.265.
Choosing an Adobe ME preset. I planned to include no videos over a minute long, so I decided that file size was more important than users’ bandwidth. In previous testing of video compression I had learned that the medium bitrate preset resulted in the smallest file sizes, so that was the compression preset I chose for this case study.
Testing images across browsers
The desktop view
The mobile view
Some Observations. I set up my scenario to look for differences in the images as they were displayed on different devices. Because I was looking only at the image quality and not page layout, I did not take the time to make the web page responsive. The mobile screenshots show this mistake. In fact, the scenario perhaps does a better job of illustrating the need for responsive design than the need for choosing one file type over another. The iPad, particularly, needs a different layout.
Testing video across browsers
The desktop view
The video displayed consistently between Chrome, Edge, and Firefox. The user experience of watching the video, however, differed because of the different ways the three browsers handle the default UI of the HTML 5 video tag. Chrome and Edge had identical user interfaces, probably because Edge is based on Chromium, but the user interface in Firefox differed significantly. I preferred using Firefox, because Chrome and Edge display a heavy font-weight border around the video container when the video is clicked, and I found this distracting. In the future I will embed a video previously uploaded to YouTube or Vimeo to ensure that the user experience remains consistent.
The mobile view
From browser to browser, and device to device, What stayed the same?
Image quality. I did not see differences in the images themselves between the different browsers or between devices. I also did not notice any slowdown in page load while loading the videos.
Video quality. Playback remained the same no matter the browser or the device. The video was short enough that no browser or device struggled to load the video.
From browser to browser, and device to device, What changed?
Page layout. As I set up the case study, I wanted to remove all variables other than the browsers and the devices. To accomplish this, I used almost no CSS. I also decided to use the same size and resolution images no matter the device: in other words, I did not use srcset. This resulted in the unintended consequence of different user experiences from device to device.
How will I change my web design and development practices?
When I set up my experiment, I was looking for the answers to four specific questions. The answers were as follows:
1. What are the effects of file size on page load times? All of the browsers and devices appeared to load the page immediately. This result likely occurred because I had taken the time beforehand to size and compress the images appropriately. Had I not done so I might have noticed longer loading times. Further testing could clarify this.
2. Do any differences in media quality exist on different browsers? I found no difference in quality between the browsers I tested. On desktop, Chrome, Edge and Firefox displayed the images and the video equally well. Safari displayed the image well on the iPad Pro.
3. What are the effects of screen size on media quality? I tested the website on the iPad Pro, the Samsung Galaxy Note 8, and the Pixel 3XL. I did not notice differences in image or video quality on these different devices.
4. How do questions 1–3, above, affect the overall user experience? I am satisfied to know that appropriately sized and compressed media will not slow down loading times enough to adversely affect the user experience. I am dissatisfied with the differences in video player UI between browsers when using the HTML 5 video tag.
I learned that using the HTML 5 video tag will give users an inconsistent UI. The differences in user interface for playing video means that users would have slightly different experiences depending on their browser choice. I will avoid this in the future by embedding YouTube or Vimeo videos in my code instead of using the video tag.
I learned that responsive design is not optional. In the past, I have tended to view responsive design practices as the ideal, but not the standard. With this experiment, however, I saw that when a design for mobile is viewed on a desktop, it breaks, completely. While I did not design this scenario to investigate what happens when a design is viewed on a device it was not designed for, the scenario did answer that question. This was the biggest takeaway for me personally.
I also learned that I need a breakpoint for tablet. The iPad Pro did not display the mobile layouts any better than the desktop did. Breakpoints should be set for both tablet and phone.
Anna Abbott is a student in the Digital Media program at Utah Valley University, Orem Utah, studying Web & App Development. The article above relates to the DGM 2341 Course and is representative of the skills learned.
