Goals for web interface

• Ease of use – the site should be as simple and easy to use as possible. Artists and curators are the main users of the backend. It should only include options which are relevant to them and those options should be presented simply and in familiar terms (i.e. curator instead of admin, artist instead of author, etc)
• Curators can add new curators
• Curators schedule shows on the calendar themselves
• Each new show creates an xml file that can interface with the plugin
• The site has a main rss feed of current shows.
  • A show has 1 or many artists each of whom has at least 1 image

Proposed Workflow

1. Curator adds a show by setting the artist for the show, putting in information, then puts in the art as a series of files.
2. Curator sets a start and end date for the show.
3. Start date arrives
4. Add-art.org show rss now displays this show as the newest in a list of shows.
5. add-art extension checks the feed, downloads the latest show art locally, removes shows that are no longer in the feed from local storage.
6. When user goes to a page, add-art extension picks a random current show, then replaces ads with refs to appropriately sized pieces from current show.

Drupal

Danielle Palladino and Steve Lambert built the original site using Drupal. We chose drupal because it seemed the most flexible. Initially Steve tried to build a custom CMS with a developer, but the project died on the vine.

Advantages

• Drupal allows the ability to create roles like curator and artist.
• Curators can create artists and other curators (double check to be true)
• Relatively easy to create a custom module that could serve the Add-Art plugin images

Images

• each image is a node
• each image dimension has a specific content type (i.e. image_120×240)
• standard Image Gallery module doesn’t work because we’re creating image content types. The image gallery pull down menu is not available on these custom content types, only in the standard image content type.
• the max resolution of the image is limited to the proper dimension of the image. So the max size of image_120×240 is 120px wide and 240px tall. Any larger size will be rejected. Smaller sizes, unfortunately, are accepted. Although this is a better problem than accepting oversize images.
• all images can be uploaded at once through an upload interface, rather than cycling through pages uploading one image at a time.

Publishing and Calendar

• Within the drupal admin there is a calendar for curators to book shows in advance.
• Artists submit work to curators and curators mark them as published with a date. When the date arrives, the show is published.
• The site keeps an archive of shows with the most current at the top and past shows listed below in chronological order.

Mistakes

• Tried to write a custom application. Spent weeks working on it and then realized we could do a Drupal install and accomplish nearly what we wanted. With custom modules, we could get even closer. It was faster to develop and there is (obviously) way more support, easier to make changes in future.
• Didn’t know about Django earlier. It may have been a good solution. However no one involved had any experience with it and we found it late. Might be worth using later because it seems like it is developed for publishing and the architecture of the Add-Art site is much like newspaper or magazine content. Articles=Artists, Curators=Editors, Issues=Shows.