Admin

Context

Aloompa makes mobile apps and web embeds for large events like music festivals and conferences. At their core, all of these apps feature a list of events (schedule) and a list of performers (lineup). In order to maintain the schedule and lineup in their app, event organizers must familiarize themselves with the Admin content management system.

While a visual design refresh was a big part of this project, my primary focus was to help event organizers release their schedule and lineup information, carefully considering all of the possible scenarios they wanted. To inform my decisions, I observed how event organizers were using the previous iteration of the CMS to get their desired results, and identifying points where they were experiencing problems or places where the model in their mind did not match up with the actual product offering.

Research

Luckily, Aloompa has several local customers just a few minutes from our office. I was able to join in on sales check-ins for several of them and get some dedicated time to talk about their experiences with the existing iteration of the content management system before creating a new one.

Problems observed in the previous iteration of the CMS:

• The CMS was designed specifically for music festivals. An “event” was comprised of a performer, a time, and a stage. All of these elements were required to be published in order for an event to appear in an Aloompa app or web embed. While this combination makes sense for music festivals, it doesn’t make sense for a conference with a “breakfast” event, which has no performer.
• For events like “breakfast”, which have no performer, the CMS had a workaround which required the event organizer to create a “breakfast” performer which was published, but then manually hidden by the client using a checkbox option in the UI. The performer was then in a confusing state of being simultaneously published and hidden. Event organizers frequently ended up with undesired “dummy” performers in their apps or web embeds because they didn’t understand the workaround required to hide them.
• If an event had multiple performers associated with it, the event organizer created a “multi-performer event” which functioned the same as the other events, except there was an interface for selecting multiple performers from a list. When a multi-performer event was created, a new dummy performer was created with the same name. Since events did not have images associated with them, they had to inherit their images from their performers. So event organizers had to manage the image and the data for multi-performer events in two different places.
• Event organizers often release information to the public in phases to create buzz and stay at the top of people’s minds in the months leading up to an event. For instance, they might begin vaguely and release a list of just a few performers early on in the marketing process. As the event draws nearer, they will reveal more performers and begin adding a few specifics, often wanting to announce them by stage (without a date or time) or by date (without a stage or time). Since the CMS required stage, date, and time to be published for all events, the Aloompa team had to do risky work by asking the client to publish false information in the CMS. Then we manually hid any undesired details in our apps and web embeds, so that the client might be able to use a few key data components of an event to announce their performers.
• Similarly, event organizers often want to announce their performers using data which has nothing to do with date, time, or stage. They simply want to break the performers into phases or categories like music, speakers, comedy, and art. However, performers did not have any data like this associated with them, but events did. So again, in order to group our performers in a specific way, clients had to rely on an associated event being published.
• All performer, event, and point of interest description fields allowed the event organizer to add HTML formatting. This ability had provided a lot of flexibility when clients asked us to add features which didn’t apply to the product as a whole. We could often make them an HTML button or header that they could add to their descriptions, helping them solve a few problems. The problem that arose quite often with these description fields is that event organizers often pasted the descriptions from miscellaneous documents and websites which all had their own formatting. By the time they’d entered all of their information and received a build of their app or web embed, event organizers realized that the fonts, line-heights and colors looked inconsistent from one performer to the next. At this point they would complain, and an Aloompa developer would have to painstakingly override any styles which had unintentionally been added.
• Alooma's app is essentially a collection of lists. Performers, points of interest, and events all appear in some form of list or another and sometimes the default sorting of the items in these lists can be problematic for our clients. Events are sorted chronologically, which is a nice intuitive way to view information when time is a factor, but the other two models were sorted alphabetically. Take performers for example: you might assume that an alphabetical list would be the obvious way to display a list of performers, and you wouldn’t be totally wrong. However, many event organizers have billing orders that they have to respect, and some artists have made deals to appear at the top of the list. Similarly, many of the points of interest at events are temporarily installed, and as an attendee you probably have no familiarity with them to begin looking them up by name in a list. In this case, a list of “food trucks” in a curated order might actually be more appealing to an attendee than scrolling through an entire alphabetical listing of food trucks.

Solutions

While the solutions to many of the problems mentioned above were not visual in nature, it was extremely enlightening to discuss them with the Aloompa engineering team, most of whom rarely get to hear directly from clients about their reasons for wanting feature refinements. The knowledge collected in the client interviews above afforded me the opportunity to approach the engineering team with a set of real scenarios to be resolved, rather than simply dictating a set of features to be executed. I believe that this approach fostered some extremely productive conversations, allowing everyone to be sure refinements were completed in the best way possible.

Event details now feature some very helpful functionality behind the scenes, as well as some interface updates.

Refinements:

• Events no longer require performers, so there’s no need to worry about a performer named “breakfast” appearing in a list of speakers at a conference.
• All events can support as many performers as an event organizer would like to add, so there’s no reason so separate events into “single performer” and “multi-performer” models. Event organizers simply search, add, and delete performers as needed.
• Event organizers can now upload an image directly to an event. However, if the user arrives on this screen from the context of a performer detail (by clicking the “Add Event” button on that screen), then that performer’s image and bio will be inherited by the event, but can be replaced or deleted if desired.
• Event details are no longer required to be complete in order to publish an event. The only data required for an event to be published are the event name and the event category. Everything else can be added and revealed as needed. The associated screens in the client’s mobile app and web embeds will display a simple “To Be Determined” message for any incomplete information.

Refinements to categories were a major enhancement to the Aloompa product. In the past, event organizers have asked to group and display information from the CMS in unsupported ways. These updates help Aloompa clients to shape the data however they wish.

Refinements:

• Performer categories were introduced, allowing event organizers to create groups of performers without having to associate them with events, which may not be desired.
• All categories feature the ability to set a sorting preference. Currently event organizers can select to either sort alphabetically or set a custom order for their contents. Other ways of sorting, such as “by rating” or “distance from the attendee” will be introduced in future iterations.
• Some categories are more important than others to event organizers, so categories can be sorted as their own objects. This allows control over what order the categories themselves appear in their apps and web embeds through a simple drag-and-drop interface.

I worked with Aloompa developers to define and strip any undesired HTML formatting from pasted text in the CMS description fields. The description fields accept hyperlinks, ordered/unordered lists, and bold/italic text. Colors, line-heights, fonts and sizes are removed from the formatting upon pasting. However, additional formatting can be included after the text is pasted, because after pasting we can be certain that the formatting is intended, rather than accidental.