Warning: Use of undefined constant user_level - assumed 'user_level' (this will throw an Error in a future version of PHP) in /home/commons/public_html/wp-content/plugins/ultimate-google-analytics/ultimate_ga.php on line 524
My inspiration this week comes from a comment made by my fiancee about her new work team’s homepage.
Her complaint had to do with the uninviting nature of a webpage meant to serve as a landing page for Global Specialty Markets, featuring picture after picture of white men. The displaying of a white man’s headshot as the featured image for an article about a WaterAid project in Rwanda seemed at best tone deaf to socio-cultural expectations, and a bit too in line with stereotypes of the insurance industry.
To her, a standard user of the web based interfaces, this looked like a pretty glaring failure on the part of the marketing department. The degree of tone-deafness by the presumably capable marketing and communications team made me wonder what obstacles might lay in their path to amend these photos to more representative images.
The Website Architecture
Having been involved in the design of a new website featuring employee news articles for my last company, I remember learning about one of the key constraints put on us by our web design contractors. All articles were fundamentally linked to individual user accounts who were designated as Authors, these author accounts were incorporated into the metadata of the published pieces. Visitors to the page could search for pieces by particular authors and would see their name under the article heading, which would serve to as a link to their author profile.
The Socio-Cultural History of News
This whole system as an outsider seems very simple to work with and aligned well with what we expected based on our consumption of traditional print newspapers. Authors are always listed along with articles and inform our understanding of the point of view of the article. Their history as an author can be illuminating to the article at hand. As our employees were authors who could publish their articles through the website management portal, it made sense to tie their employee information, including their photos, to their user/author profile. This photo and biographical data would also be included in the About Us section of our website.
Well Thought Out Affordances
Thankfully for my team, we made abundantly clear with the builders of our website that we would like to have control over the photos that appeared with the articles. What we learned once we started using the system, however, is that appropriately accessing, storing, and displaying photos is not as easy as we had imagined. My fiancee’s employer seems to have made the decision to simply display the author photos with their particular publications, avoiding some of the complexities of managing a website.
Media Storage, Attribution, and Compatibility
The headshots of the employees are tied directly to their author profiles which then automatically are attached to their articles. The website engineers who designed this function simply take the corporate headshots, for which the company would have full licensing for use and would have stored in a company repository of owned images, and resizes each of them uniformly to fit into the allocated dimensions of the article boxes in the website architecture. This manual resizing step would only need to be performed once for each new photo. The resized photo would then be duplicated from the company servers and loaded onto the servers that host the website. These photos would take up space on the hosting servers. When a visitor accesses the website, these photos are sent as a sub-group of the data packets that inform the visitor’s computer what to display at that particular website address. The photos will appear as intended with perhaps slight alterations based on the size of screen/window the viewer is using. This is all a relatively contained system. But what if the marketing team wanted to display a more appropriate image?
While the company may own a set of either stock photos or company produced photos, let’s imagine they receive the photos from a 3rd party or find them online. Now each photo will need to be formatted and resized to match the receiving space within the website framework. This process is becoming easier as website management platforms improve their user friendliness, but for a complex corporate website this task will likely need to be done by a member of the website management team. Given that, this is the likely process for each additional photo:
- Marketing team selects photo based on internet search of usable photos.
- Image is downloaded as a group of data packets to the storage system on their individual computer from whichever website’s servers the image taker has selected to store and display their photo.
- The employee’s computer translates the data packet from origination to understandable format for the employee system.
- Image is transferred to company server by marketing employee, or is emailed to website IT team who then save it to the company server.
- The marketing employee also communicates the attribution requirements for the image (a step removed if the company owns the rights to the image).
- The IT team resizes the image and links it with the appropriate article, and publishes article to the website, hosted on yet another server.
- Viewer sees final product through their computer, including attribution information.
While all of this certainly adds more step to the article publishing process than currently exist with the use of the authors photo, that may be acceptable for the benefits. However, what if during the design of the website, the decision was made to always display whatever photo was tied to the author’s profile? If so, then doing this would require a redesign of this particular website feature, making this a much more significant demand on the IT process. While it may be a simple change, there is always a risk with integrated website design that something else breaks in the process.
The design of the features of the larger internet provide us with many apparent affordances. We often feel that if we can imagine how something should look, implementing it should be as simple as drawing it out on a piece of paper. However, on top of the various rules in place at a base level that enable so much freedom, there are rules computer engineers place on websites, software, and hardware that limit this blank space of options. Just because I can imagine displaying a different image for the article header doesn’t mean I can just snap my fingers and make that change, even if I had access. Because design inherently must provide various limitations and parameters on the affordances of the product, it is important to think about the larger ramifications of those design choices. In addition, designing systems for modularity helps improve the ability to make changes to systems and products after realizing the initial design was flawed.