Platform Assessment - DIGH 501, Week 4

[taylorcate]

taken from the DIGH 501 Syllabus

If you are working with an existing platform, tool, or content management system (CMS) such as Omeka, Scalar, Drupal, WordPress, Joomla!, Mukurtu, Jekyll, or Django, you’ll need to think about its affordances and possible limitations. A CMS is a system that allows an author publish content to the web via tools like a backend, with buttons and text editors. The “content” — the text, images, and other media you upload — is stored in a database, separate from instructions for styling and displaying the site.

Consider the following questions in your analysis:

• How does this platform distinguish itself from others?

• Who built (builds) the platform?

• For whom is the platform intended?

• What language(s) is (are) it written in?

• What kinds of sites or projects currently use this platform?

• What possibilities does it offer for display? For example, how easy is it to reconfigure the form of a project? How many options are configurable?

• Does the platform seem to assume that you want to display content in a certain configuration? If so, what is it?

• How easy is it for a layperson to install this platform? To use it?

• Who can modify the platform’s source code?

• What kind of database does the CMS use? Can you tell anything about the format of data contained in the database?

• Can you attach metadata to the content you enter? If so, what kind?

Once you’ve answered these questions, let’s think about some ethical and intellectual implications for doing scholarly work within your platform. A framing question might be, “If we chose this platform for our project, what would our implicit message be?” You might consider:

• the philosophy of the platform toward the relationship of form and content

• the attitude the CMS adopts toward the flow of information

• the ethical implications of the platform’s assumptions about organizing (or not organizing) content

• its assumptions about who should have access to and modify information****

[taylorcate]

Platform Assessment: GitHub Pages with Jekyll Theme

When I first opened this project repo, I deployed a GitHub Pages site by selecting a Jekyll theme. Since then, my only modifications to this site have been made by altering the repo's main README.md file. I have begun researching how to add pages and posts to the site and I'm compiling those resources here. Below I have answered the questions associated with the Platform Assessment to further my understanding of the CMS I'm using to host and deploy my project.

How does this platform distinguish itself from others?

GitHub pages is inherently linked to public and, sometimes, private GitHub repositories. In addition, with the Jekyll static site generator enabled, users can easily deploy and modify their websites right from the command line. The Jekyll framework has built in styling that makes it easy to replicate headers and footers across pages. Jekyll is also compatible with markdown, so users unfamiliar with HTML can achieve aesthetically interesting webpages.

Who built (builds) the platform?

GitHub Pages was created by GitHub to enable users to convert existing project, organization, and personal repositories into websites using the functions already familiar to those working in a Git flow.

For whom is the platform intended?

Anyone who uses GitHub for their projects and wishes to convert that content into a static website. Though traditionally intended for developer use, GitHub Pages is simple enough to appeal to novice coders and intuitive enough for even the most non-tech savvy, humanist to tackle.

What language(s) is (are) it written in?

Using the Jekyll framework, the site content can be written in simple Markdown. Alternatively, HTML can be used to customize the site.

What possibilities does it offer for display? For example, how easy is it to reconfigure the form of a project? How many options are configurable?

From what I understand, nearly all elements of a GitHub Pages site are customizable because an external CSS can always be linked. It's not like working in a traditional CMS with almost no access to the backend. If you are courageous enough to research and learn the coding involved, you can achieve pretty much anything.

How easy is it for a layperson to install this platform? To use it?

I deployed a GitHub Pages site almost without even realizing it—that's how easy it is to install. Once the site was created, however, it took me a long time to conceptualize how its content could be edited and altered. Since then, I've read a good deal about Jekyll and now I think adding pages and content will be relatively simple.

Ethical and Intellectual Implications for Choosing this Platform:

Because I am subscribing to a model which prioritizes the necessity for version-control, I think running my site through GitHub Pages is exactly the right move. It allows me to have control over the back-end of my website while not inundating me in coding complexity. I am not limited by the presumptions of a CMS, but rather by my own imagination and will to persevere in unfamiliar territory. Ethically, this decision reflects my desire to create a truly open-source project because all of the code will be as accessible as the site content. Intellectually, striving to create a fully linked GitHub Pages site pushes me to acquire technical skills I don't currently have. While I could easily use a CMS like WordPress or Wix to host my edition, it would disrupt the connection between the repo and the site—this is exactly the predicament I found myself in with Iteration 1.0. By deploying my site on GitHub Pages, I am bringing myself even closer to my device's raw power and up to the level of understanding a developer has. This was the task I set for myself and I intend to succeed.