A preview of the National Enquirer Indexing project

National Enquirer Index

Overview

There are a handful of major libraries, including the Library of Congress (LC), which hold microfilm copies of the sensational tabloid, The National Enquirer. However, there is no digital index to this content. Researchers interested in searching the issues must travel to a holding library, and then search the microfilm frame-by-frame in the hope of finding an article of interest.

A small group of retired LC staff, National Library of Medicine (NLM) and other volunteers are interested in providing access to this valuable research material as a gift to LC. They developed a system to allow for volunteers working at home to create the index, and to date, they have indexed entries for nearly two years worth of issues. This index is available online to researchers in LC reading rooms.

The site where the indexers were working was experiencing data loss, which was not only damaging to the index, but discouraging to the users as well. When I heard that they were in need of a new site, I didn't just volunteer to build a more stable site for them. I saw this as an opportunity to use my skills as a designer to help enhance the site's design and user experience.

Responsibilities

  • Research
  • Information Architecture
  • Visual Design
  • Development
  • Testing
  • Database Administrator

Tools Used

  • HTML
  • CSS5
  • Javascript
  • jQuery
  • PHP
  • Balsamiq
  • AWS Lightsail
  • LAMP
  • MySQL

Problem

This project has two main components: the administrative site where volunteers can index National Enquirer issues to enter into the database, and a public search site, where researchers in the LC reading rooms can look up articles by keyword.



Indexing

In the indexing system, a National Enquirer issue will go through the following 6 stages:

  • An administrator assigns an issue to an indexer
  • The indexer will index the issue
  • The indexer will submit the issue for review
  • Another volunteer will review the issue, and make any comments as necessary
  • The indexer will receive the reviewed issue, and correct any problems
  • The indexer will submit the issue into the database, where it will appear in the public search site.



When volunteers index issues to the database, there are 6 important fields:

  • Title
  • Page numbers
  • Authors
  • Notable people or entities mentioned in the article
  • What the article is about
  • Any other notes or details the indexer thinks is relevant

NE Index's original homepage

Adding a title and page number in the old system.



NE Index's original homepage part 2

Filling out other fields in the old system.


Searching

Once issues are indexed, researchers visiting the Library of Congress can then search this database.

NE Index's original search page

Searching a term in the old system



NE Index's original search page part 2

Search results in the old system.

Research

I actually had worked as an indexer before, so I was very familiar with the users and work flow. I knew what users' expectations were for the system.

Additionally, I had also conducted interviews with users to see what was working with the current system, and what changes they would like to see made. I perfomed interviews both in person and through video calls.

However, it wasn't always possible to conduct an interview in person. Some indexers don't live in the area, and conflicting schedules seemed to be a regular problem. So another way I did testing was by having users record their screens, so I could see and hear how they were interacting with the system. It was a bit of an unconventional approach, but it still worked, regardless.

Once I collected all the data, I created user stories in order to keep the system user-focused.



User stories


Researcher

"As a researcher, I would like to find metadata about National Enquirer articles relevant to my search topic."

Components needed:

  • A search page
  • Intuitive way of viewing the information



Indexer

"As an indexer, I would like an intuitive way to quickly and efficiently index issues."

In addition to the components listed above, an indexer also needs:

  • A page to view all issues that have been assigned to them
  • A page to either add a new article or edit an existing article
  • A page to index an article
  • A way to conduct reviews of issues indexed by others
  • A way to fix comments on their issue
  • A way to submit an issue once indexing has been quality controlled and completed

Conditions of satisfaction:

  • Creating a website flow which mimics the lifecycle of an issue to be indexed
  • Forms fields are presented in a way which is intuitive, which in turn will minimize the time spent inputting information into the form fields
  • Take advantage of dynamic elements such as auto-complete and suggestions in order to reduce duplicate work needed by the indexer



Administrator

"As an administrator, I would like to be able to assign articles to indexers, have direct access to the database, and reassign any issue at any stage in the process."

In addition to the components listed above, an administrator also needs:

  • Summary of all issues
  • A place to assign and/or reassign issues to indexers

Conditions of satisfaction:

  • Administrator can successfully assign an issue to an indexer
  • Administrator can successfully assign a reviewer to an issue
  • Administrator can successfully reassign an issue's indexer or reviewer

Wireframes for each role:


Administrator


NE admin page wireframe


Admin's page where they can see an overview of issues, and assign issues.


Indexer


NE admin page wireframe

The page where volunteers will index their assigned issues


NE admin page wireframe

The page where volunteers will review others' issues


NE admin page wireframe

The page where volunteers will address reviewer's comments


Researcher


NE admin page wireframe

The public search site


NE admin page wireframe

Search results page


Feedback and Iteration

When I did testing and gathered feedback from the group, I received the following feedback:

  • Users liked the "spreadsheet-like" feel of the indexing page. They thought that this would help them index issues more efficiently
  • The font was too small in places to comfortably see
  • Some users were unsure of how to efficiently use some tools, such as a multiselect
  • Users generally wanted fewer colors on the site. Otherwise, they felt that it would be too distracting


As I was going over the feedback I had gotten, I realized that there was a fundamental flaw in my design. I had inadvertantly designed the site for someone who had no problem reading screens, and was just generally comfortable with computers-- aka, me. These traits, however, could not necessarily be applied to the target users I was working with. I needed to rework my designs so that they were accomodating to the age and technological literacy of the users.

Final design

Administrator

Admin dashboard


The NE index's admin page
  • It is very clear how many issues are in which stage of the lifecycle.
  • It is easy for the administrator to assign issues to volunteers (volunteers' names have been blocked out for privacy)


Indexer

Indexing page


  • Indexers liked the row layout of the page. It mimicked an Excel sheet, which makes repetitive data entry much easier.
  • While the multiselect for about terms was a bit confusing at first, once indexers were taught how to use it efficiently, they really liked the ability to so easily select multiple about terms for the article.


Reviewing page


  • The reviewing page ended up being the one I revamped the most from my initial design.
  • Users wanted there to be a "top-level" note, in case there were any comments that applied to the article at large-- not just regarding an individual field.
  • As a result, I allowed an option to create an article note, which was on the left side of the page. Not attaching this note to any particular field helped remind users that this note is to be used if there is a general comment about the article.


Fixing page


  • Reviewer notes are highlighted in a bright yellow so that indexers cannot miss the comment.
  • To acknowledge a comment, indexers must click "Okay". The reviewer note will be grayed out, and the "Okay" button will turn into a checkmark. This provides multiple signals to the user that the comment has been acknowledged.
  • Issues cannot be marked as complete until all reviewer comments have been acknowledged.


Researcher

Search page


  • Seeing the number of articles available to search signals to the user that there in an abundance of information waiting to be discovered.


Search results page


Search results page
  • Did you know that the color green can actually boost your concentration?
  • This is why I chose a green color scheme for the public search pages. Researchers will potentially be looking through dozens of articles. It can easily be a repetitive task, which is why I think a boost in concentration is helpful.
  • Search results were listed as cards. As one librarian put it during testing:

    "I like the shadow boxes used to display search results. It suggests a metaphorical 3x5 card, long the stable of researchers... I think [the search results page] has the look and feel of a researchers' work space."

Takeaways

This project is amazing in so many ways. Not only did I gain experience developing a system from the ground up, I also learned a very valuable lesson. As designers, it is not our job to design for ourselves. Just because a design was intuitive for me, does not mean the same holds true for the users. I got to work very closely with users from a totally opposite demographic from me, and I learned a lot about designing for them.

Fortunately, this is still an ongoing project. I look forward to the many future iterations that the design process will bring!