Designing the right solution for a Lean Artist
A case study for the DiasporaX’s website
Introduction
I recently had the great pleasure of working with Famous New Media Artist Jeremy Bailey on his latest artistic endeavor, Lean Artist Chicago, a project commissioned by the Museum of Contemporary Art Chicago (MCA). Before going into details of my involvement in this project, you may be wondering who this Famous New Media Artist is, and also what is Lean Artist?
Who is Famous New Media Artist Jeremy Bailey?
Jeremy Bailey is an internationally exhibited performance artist. Under the alter-ego moniker Famous New Media Artist Jeremy Bailey, Bailey’s work explores the use of emerging technology, usually in comedic fashion, through performances using video, software and the internet as mediums.
What is Lean Artist?
Started by Bailey in 2016, Lean Artist is “the world’s first seed accelerator for artists.” Bailey takes on the role of an investor and mentor, while each participating artist is much like a start-up. The intent is that each artist creates a product/service to help better their community. At the time of this case study’s publication, there are two Lean Artist chapters: Hamburg, and Chicago.
My Involvement in Lean Artist Chicago
The Chicago chapter of Lean Artist had a total of four participants. I developed and designed websites for three of the participants. The three sites are:
- clumzy — a unique communication device created by Jon Chambers.
- STRAPP — a harness designed by shawné michaelain.
- DiasporaX — a meetup-series initiated by Oscar González-Diaz.
All three sites needed to be live in a month to coincide with the opening of the “offline” art exhibit, I Was Raised On The Internet.
DiasporaX’s Website
Unlike the first two websites mentioned above, the DiasporaX website is a hub for its visitors to signup for upcoming events in the Chicago area. Chicago-based artist Gonzalez-Diaz wants to update the site in order to:
- Announce any upcoming DiasporaX events.
- Showcase the poster of the next DiasporaX events.
- Have the capability to archive all past events.
- Update any information regarding current and future DiasporaX events.
- Deploy those changes via File Transfer Protocol (FTP).
Purpose
The purpose of this case study was to find the right tool that can easily allow González-Diaz to update the DiasporaX website.
How Did I Go About Solving It
I employed the Design Thinking methodology to find the right tool for González-Diaz.
According to the d.school, the Design Thinking process is divided into five stages:
- Empathize
- Define The Problem
- Ideate
- Prototype
- Test
It’s also important to note that the five stages above are non-linear since there will be moments where it is required to go back a stage or even multiple stages. Spoiler Alert! In doing so, it will lead to the right solution for the problem being solved.
Empathy For The End-User
During this process, I began asking González-Diaz a series of questions on Slack. Throughout this conversation, I learned that he is happy to use any web service if the onboarding and setup experience are both easy to follow and complete. He did also add that he prefers that there be no “heavy” coding/programming during either process, as it complicates his experience and pushes him away from using said web service in future.
Defining The Problem
The task of updating and deploying changes to the DiasporaX website must be simple and non-technical in order for Gonzalez-Diaz to do the changes without any assistance.
Ideation A
The initial idea was having González-Diaz update the site’s content through the HTML file itself. This idea was quickly shot down because:
- I cannot assume he has extensive knowledge of updating content in an HTML file.
- There are a few steps and components involved when updating content via an HTML file. If any of those components are non-operational, he won’t be able to update the content.
- It is also important to note that there is a higher risk when editing an HTML file because if a wrong line of code were removed or altered the site could break.
Ideation B
The second idea was connecting Eventbrite to the website by using Eventbrite’s application programming interface (API). The general idea is whenever Oscar uses Eventbrite to create an event it will then automatically display on the website. However, the plans of using EventBrite’s API was scrapped because it will be the hosting venue’s responsibility managing tickets for the event.
Ideation C
The last idea is to use a Content Management System (CMS) like Wordpress. Although Wordpress is the most recognizable CMS, and powers 30% of the Internet, CMS reliant on a database (Wordpress, Drupal or Joomla) are not only performance hogs and are prone to security attacks, they are also a pain to manage and configure. Lastly, using Wordpress is a bit excessive for a single page website, as is the case for DiasporaX’s site. Thus, an alternative is using a static site generator.
First and foremost, there is no database involved with a static site generator; thus, none of the pain points mentioned earlier. Secondly, they are compatible with a cloud CMS, so it will be easy for the end-user to update a website’s content.
After timeboxing an hour of research, Jekyll looked to be the ideal candidate because of its high user base, and it also happens to be compatible with many online CMS services.
Prototyping Jekyll
Although being my first time using Jekyll, I quickly became accustomed to its syntax after watching a few tutorials on YouTube. With little to no effort, I was able to convert the current code base of the DiasporaX’s website to work within the Jekyll framework.
Since Jekyll works with many online CMS services, I needed to find one that is not only easy-to-use but was also affordable (ideally free).
Prototyping Jekyll & CloudCannon
First up was CloudCannon from New Zealand. I came across this service in an online post on CSS Tricks while researching about Jekyll. Testing CloudCannon involved updating and deploying changes to a local prototype of the site. Even though everything worked, something else was brought to my and Bailey’s attention.
While CloudCannon was a valiant candidate, Bailey and I both shared similar concerns. Scalability being the first. If González-Diaz decided to include additional users his only option to do so would be to upgrade to a paid plan. The second factor is in regards to CloudCannon’s technical support. When I inquired about set up, I had to wait a day before I got a response from support, a scenario I wouldn’t want to see González-Diaz in.
Back To The Ideation Stage
With CloudCannon out, and limited time available, I was in a bind. The last option would be to hard-code the content for the time being. However, I instead searched Google using the search query: Jekyll online CMS. Although CloudCannon ranked higher, immediately below it was another online CMS service, Forestry.
Prototyping Jekyll & Forestry
Based in Charlottetown, Prince Edward Island, Forestry works with websites built using Jekyll. Forestry has numerous types of input fields to use to update a website’s content. Regarding updating content, it went without a hitch since it can deploy via FTP. Regarding scalability, Forestry’s free-tier allows up to three users, as opposed to the former. Aside from the support page on its website, Forestry has their very own Slack channel, which is a great way to connect with other users, especially when in need of help.
Testing and Always Iterating
Although Bailey and I believe Forestry’s CMS is ideal for DiasporaX’s website, the real test was whether this solution worked for González-Diaz. Since he is in Chicago and I am in Toronto, we decided to do a video call with screen sharing.
Although the video call resembles an onboarding experience, it was also an opportunity to get feedback from González-Diaz. He not only learned how to use the site’s back-end, but we both made adjustments to it as well by:
- Rearranging the order of input fields.
- Using different kinds of input fields (i.e. text field or a text area field).
- Adding a description of each input field describing how the content will be presented on the page.
Final Outcome
Once González-Diaz and I felt confident with the improvements we made, and he was comfortable with updating and deploying changes to the website without any assistance, I then pushed that version of the site to the production server days before the exhibit opened to the public.
Conclusion
Even though I was working under a tight schedule, I didn’t default to using my initial idea of updating the site via the HTML. By using Design Thinking, which encourages iterating, I eventually found the right solution for González-Diaz to update the DiasporaX website by using a static site generator working along with an online CMS system. Although the initial CMS system did not work, eventually the right system was found.
Regardless of being live and accessible to visit, I expect the site to continuously be iterated because there will always be room for improvements.
