I was really grateful for Aaron Overton’s very first post on ArtsHacker last week. Aaron is a programmer with a lot of experience in website development for performing arts organizations. (Disclosure: He did some work on the ticketing integration for my day job website.)
In his ArtsHacker post, he talks about how much work goes into making it easy to keep an arts organization website updated and looking good. I had a conversation about that very subject the day before his post appeared. Had I know his piece was coming out, I would have delayed my meeting a day and used the post to bolster my argument.
Because performing arts organizations have an ever changing cycle of events, it can take a lot of work to keep your website current, attractive and put the most relevant information in front of site visitors’ eyes. Publishing platforms like WordPress make creation and maintenance of websites much easier than it was even 5 years ago, but there is still A LOT of coding that has to occur to make the process of adding and removing content quick, painless and in many cases, automatic.
The back end of my day job’s website has a nice set of orderly field that I can plug event information and images in to and everything appears in its proper place on the website. About a year ago, I noticed a less than ideal placement of some information and asked my web guy if he could fix it. I was sitting next to him when he made the fix and even though it was easy to accomplish, I got enough of a look under the hood to realize how much work went into making things so simple.
At the time I even remarked that all those ads for build your own website in minutes services like Wix and Squarespace probably made people underestimate how much work went into making websites work well. Certainly, those sites provide a great service to people and businesses to help them get up and going. But there may come a time in your personal/professional/organizational development where they won’t be enough.
And I made a similar comment in the meeting I had last week.
If you take a look at the first example in Aaron’s post, he mentions desired features that are likely common to many performing arts organizations:
…display headshots of the cast for an event. The set of headshots might have color-tinted photos with the actor’s name displayed on the bottom and some sort of rollover effect that slides in from the bottom when the user hovers or taps.
The client needs to have a pool of actors and be able to build “teams” that can be attached to events. The headshot photos may have many purposes, so they won’t necessarily have a uniform size or aspect ratio.
But to make that happen, he had to consider the following factors:
- Provide a way for a site manager to create team member profiles with a large headshot photo.
- Provide a team builder to group team members into ordered lists and note their roles on that team.
- Create a way to easily place that team on a page for display, along with a few options to allow for different usages.
- Crop the provided headshots to the right size and aspect ratio.
- Style the output to account for converting the photos to tinted grayscale.
- Accommodate different screen sizes and devices so that the final output looks good whether on a desktop or a mobile device.
These are only some of the tasks. During development, many other tasks have revealed themselves as necessary, most of which may have little to do with the final display seen by the site visitor but are necessary to making sure the feature not only works, but is efficient and doesn’t slow down the user experience.
The purpose of Aaron’s post isn’t to tell people to be prepared to pay a lot for a good website. He provides a number of tips about how to approach the design process and conversations you should have with your programmer early on so that you don’t end up paying too much.