Domains 2019 Presentation

domains_community_site.json

Original proposal:

This talk builds upon the outstanding presentation: Just a Community Organizer: Visualizing Community for Domain of One’s Own by Marie Selvanadin, Tom Woodward, & Yianna Vovides given at Domains ’17. Another approach to building a Domains community site will be shown. There will be a quick overview of the technologies used to build Muhlenberg College’s community site (JSON, Isotope.js, Puppeteer). Some of the lesser-used features of cPanel (Cron Jobs, directory privacy, phpMyAdmin) will also be briefly discussed.

We’ll also talk a bit about member opt-in/opt-out strategies for community sites, and how to keep community sites current.


Slides:

Other notes:

This presentation is really a response, or a check-in resulting from the great talk two years back at Domains 2017 entitled, “Just a Community Organizer: Visualizing Community for Domain of One’s Own” by Marie Selvanadin, Tom Woodward, and Yianna Vovides.

We at Muhlenberg began imagining what a community site might resemble for our college.  A solid pedagogical rationale was evident for raising visibility and growing communities of practice across our domains initiative.  But design choices have consequences.

While much of this presentation presents the technologies that comprise the site at community.bergbuilds.domains, the more interesting design considerations focus on:

  • which sites should or should not be included, 
  • how to solicit consent, 
  • how to fairly categorize the work of others, 
  • and how to build a tool that is adaptable to current and future considerations like these.

Some of my personal design considerations are:

  • the community site should be built on a domain
  • it should be “flat”.  In other words, let’s try to build it without a database, account credentials, etc.
  • we should try to feature WordPress, but also other sites (e.g., Omeka ,Scalar, good old-fashioned websites)
  • we should try to have facets, not one-dimensional categories
  • folks should be able to both opt-in and opt-out
  • automation when it makes sense, is helpful

I learned from Tom that Reclaim Hosting can regularly place a file that is a bit like a log file or a report, but also somewhat different.  It is written in a structured data format called JSON that has some neat advantages over building files from databases.

I asked Reclaim Hosting (thanks, Tim Owens!) to generate a similar file for us at Muhlenberg.

I took this file, and wrote a script to extract a WordPress site’s title and tagline for display.  This, along with some other tools like JQuery, Node.js, and Puppeteer allowed me to generate a JSON file that is incorporated into a pretty simple HTML5UP! template.  The result is:

https://community.bergbuilds.domains

Additionally, this site takes advantage of some lesser-used cPanel components like Directory Privacy and cron jobs.  Building this site has been a great way to develop my skills with the tools available within the cPanel.

My colleagues and I also worked to build a juried list of sites to include on our community site.  Presently, we’re using a Google Sheet to share this work, but eventually I would like to accomplish the same with something on our Domain.  Generating a JSON-based export from a Google Sheet is quite simple.  There are also options for hot-sync’ing your Google sheet to a website using tools like Tabletop.JS.  

There were several members of our group — students, staff, and faculty — selecting and categorizing sites.  I personally used a very simple checklist to make the call.  I asked questions like, 

  • did this person change the default theme?
  • did this person change their site’s title and tagline?
  • does this site remove the “Hello World” posts and comments?
  • is there a sense of the person in the work?

Similarly, my colleagues and I had a meeting to determine which categories to apply to the community site.

And here is where it gets really interesting, I believe.  Questions around classification, inclusion and exclusion, privacy, and individual agency need to inform the design choices and the practices of the folks using this software.  Hopefully, there is evidence of a careful consideration of these concerns in the Berg Builds Community site.  There are certainly ways it should be improved.

This is the discussion I hope we can have in the remainder of our short time today.  Or perhaps we might have an ongoing conversation on Twitter, our blogs, and elsewhere.

Over this summer, I will make some improvements and post my code to github.  I also hope to finish a few directional videos showing how I set things up, which I will post to my blog.

Thanks, and please be in touch. 

Leave a Comment

Your email address will not be published. Required fields are marked *