This term I started my work as the back-end development intern. I dove into plugin development for content management systems, specifically WordPress and Omeka. I was able to gain lots of experience learning and coding in PHP, and better understand the capabilities of the language as a back-end development tool. Before starting plugin development, I had to familiarize myself with both WordPress and Omeka, which involved installing and setting up instances of both on my local MAMP environment, and playing around with the admin sides of both sites. Halfway through the term, I was also able to upgrade our omeka-development server to the latest version of Omeka so that we could test the new AccessibilityPlus features, which was great server administration experience for me. I also watched lots of tutorials on how to build websites with WordPress, and to learn how the WordPress code itself is structured and how plugins fit into it.

Once I was prepared to start coding, I learned that plugin development for content management systems is a fun and rewarding process, after an initial learning curve. Understanding how plugins fit into the regular processing of a CMS like WordPress using hooks and filters was a new kind of programming for me, and definitely took some getting used to. It was disorienting but also refreshing to not have to code every piece of functionality from scratch, but rather just use all of the functions and variables that already exist within the plugin’s environment. It makes the plugin code seem deceptively simple, because the real work is figuring out exactly which hooks or filters you want to use, which arguments you want to modify, and how built-in functions can make your life easier.

I created a simple heads up display that appears on the dashboard of your Omeka site and displays information about the number of exhibits and pages on the site.

WordPress and Omeka are, at a high level, very similar in the way that they integrate plugins into the regular processing, and the environment they create for them. For background, the way plugin development for content management systems works is roughly as follows: The CMS itself is code written in PHP, parts of which are called every time that a request is made to the server. While the system is processing the request, it periodically makes checks to all the plugins that are installed to see if they have registered any hooks or filters. Hooks are events that fire at specific points during the system’s processing, and they are used by the plugins to perform additional processing at those points. For example, if your plugin adds metadata to every item that is saved to the database, you would register it with a filter that fires whenever data is being set to the database. Your plugin can then take that data, modify it by adding the metadata, and then send it back to the regular processing. Hooks work similarly, but they do not need to pass any data along. They can be used to add content to a page or create additional database entries. WordPress and Omeka both follow this general structure, but there are syntactical differences in the ways that they expect plugins to be formatted and functions to be named. Learning those was pretty straightforward once I understood the basic structure of how plugins work.

The single biggest difference I’ve noticed between WordPress and Omeka plugin development is the level of documentation. WordPress is incredibly well documented, and perhaps more importantly, Stack Overflow questions and answers about common development issues abound. Plugin development for Omeka, especially at a beginner level, is substantially slowed by the lack of effective documentation for built-in functions, hooks, filters, and classes. The Omeka developer documentation provides a minimal reference of the objects that exist, but detailed descriptions and examples on how to use them are lacking. When developing for WordPress, it was easy always easy to Google an issue and quickly find either a section of the WordPress Codex, a forum post or some other resource that answered my question. When working on the Omeka plugins, on the other hand, usually I had to answer my own questions with extensive var_dumps and echo statements. Luckily, it seems as though the core plugin functionality of Omeka, once you understand the MVC structure and some of the quirky hook/filter mechanisms, is fairly consistent and straightforward, so it was usually not terribly difficult to figure out what a function did or what kinds of data were contained in an object.

Over the course of the term, I created a simple heads-up display plugin for both WordPress and Omeka, that each display relevant information about your site. Coding a similar plugin for each CMS side by side allowed me to compare the structure, environment, and documentation surrounding plugin development for both WordPress and Omeka. I also fixed bugs for and extended the functionality of our AccessibilityPlus Omeka plugin. With these changes in place, AccessibilityPlus works with Omeka 2.7, and we should be able to move forward with our contacts at NYU who are putting the plugin to use.

This is the new AccessibilityPlus settings page that I updated to manage the new features for the plugin.

WordPress and Omeka are, at a high level, very similar in the way that they integrate plugins into the regular processing, and the environment they create for them. For background, the way plugin development for content management systems works is roughly as follows: The CMS itself is code written in PHP, parts of which are called every time that a request is made to the server. While the system is processing the request, it periodically makes checks to all the plugins that are installed to see if they have registered any hooks or filters. Filters are events that fire at specific points during the system’s processing, and they are used by the plugins to modify data that is moving through the system at those points. Each filter corresponds to a specific stream of data. For example, if your plugin adds metadata to every item that is saved to the database, you would register it with a filter that fires whenever data is being set to the database. Your plugin can then take that data, modify it by adding the metadata, and then send it back to the regular processing. Hooks work similarly, but they do not need to pass any data along. Instead, they fire at certain points during the systems processing and allow plugins to perform their own processing and make changes at those specific points. They can be used to add content to a page as it is being generated or create additional database entries. WordPress and Omeka both follow this general structure, but there are syntactical differences in the ways that they expect plugins to be formatted and functions to be named. Learning those is pretty straightforward once you understand the basic structure of how plugins work in both cases.

The above images illustrate some of the syntactical differences between WordPress and Omeka, specifically the way in which functions are registered with hooks.

The single biggest difference I’ve noticed between WordPress and Omeka plugin development is the level of documentation. WordPress is incredibly well documented, and perhaps more importantly, Stack Overflow questions and answers about common development issues abound. Plugin development for Omeka, especially at a beginner level, is substantially slowed by the lack of effective documentation for built-in functions, hooks, filters, and classes. The Omeka developer documentation provides a minimal reference of the objects that exist, but detailed descriptions and examples on how to use them are lacking. Often you merely find confirmation that a function you are trying to use exists, without finding any guiding information on how it actually works. When developing for WordPress, it is typically easy to Google an issue and quickly find either a section of the WordPress Codex, a forum post or some other resource that answers your question. When working on the Omeka plugins, on the other hand, you seem to usually end up answering your own questions with extensive var_dumps and echo statements. Luckily, it seems as though the core plugin functionality of Omeka, once you understand the MVC structure and some of the quirky hook/filter mechanisms, is fairly consistent and straightforward, so it is usually not terribly difficult to figure out what a function does or what kinds of data are contained in an object, you just need to be prepared to use a lot of trial and error.

This year I have covered a lot of ground, researching a variety of different fascinating subjects and learning important technical skills. In the fall, I learned how the basic infrastructure of the internet functions, while the intern cohort conducted an investigation into the specs, usability, accessibility, and ethics of popular content management systems and static site generators. With the research I conducted in the fall, I was able to write a blog post surveying some of the ethical and security issues surrounding web development as a whole. As a part of this blog post, I created infographics that model the information exchange that happens when a web browser requests a resource from a dynamic content management system, vs. a static site generator.

As a part of learning how the infrastructure of the internet works, I became familiar with basic HTML, CSS, and JavaScript. This familiarity helped me dive into a winter break externship project designing web-based scheduling software for a non-profit equine facilitated psychotherapy facility, which is a project I’ve been working on ever since. As a final group project at the end of fall term, the other interns and I migrated the Digital Scholarship Interns blog from WordPress to the static site generator Jekyll. Although we never ended up fully adopting the new system, it was a valuable experience to fully and successfully migrate the blog from one platform to another, and document the whole process so that it could be repeated if necessary by future interns.

When winter came along, I started diving into learning about security and ethics in digital systems. Although this is still a field I hope to learn a lot more about, I started gaining exposure and familiarity to security principals in Linux and web servers. For the first group project of the term, I drafted and finalized a project proposal with Chris Tordi to revitalize a faculty member’s website that had outgrown its original design. Once that was done, Chris and I began exploring the exciting field of AR, and brainstorming ways we could get involved with AR development on campus. At the end of winter term and into the spring, I developed my project proposal for the “Ethical Considerations for AR/VR Apps” report, which became a central focus of mine during the spring.

This spring, I finished my augmented reality report, during which time I also conducted plenty of research into virtual reality uses in police training, augmented reality development platforms, and, separately, some of the rights and policies laid out in the EU by the GDPR.

Overall, a large theme of this year for me has been learning how to conduct internet research into new, volatile, and sometimes controversial topics. From Gamergate to cybersecurity to augmented reality and beyond, I’ve gained valuable knowledge of current technology issues, and gained experience with drafting research proposals, documenting sources, and synthesizing information into concise and coherent reports. This experience combined with the new technological literacy and coding skills I’ve learned has made this year incredibly productive and beneficial for me.

This annotated bibliography represents a summary of the various topics that I have researched and engaged with this term.

This term, I began to engage with cyber-security. My biggest takeaway so far has been that security is so much more than a software program, or a password, or any supposed safeguard from attack. Security is about analyzing an entire system of threats, risks and vulnerabilities, and learning how you can leverage available tools and experience to try and minimize likely damages as much as possible. There is an entire mindset associated with security, that revolves around breaking down systems, analyzing weak points, and constantly thinking about what could go wrong. I find it fascinating that many of the most common attacks, such as phishing, don’t even attempt to bypass the sophisticated firewalls that are expected to be in place, but simply trick a different part of the system to leaving the door wide open. I look forward to continuing my research and building experience in this riveting field.

So far this term I have begun to familiarize myself with the world of digital security and personal privacy. I have conducted informational interviews with people who work in fields that are deeply intertwined with both privacy and security, and I have done several research dives into the underbelly of the hacking world, exploring topics such as Gamergate, identity theft, and how to safeguard your personal information. I’ve learned that as a society we have progressed to a point where in order to live comfortably and “normally,” it is almost necessary to sell your personal information (particularly to the “Big Five” tech companies, Apple, Microsoft, Amazon, Google, and Facebook) for convenient services. Being accustomed to giving up personal information all the time leads to a culture in which we don’t treat private information as private, and adopt an “I’ve got nothing to hide” mentality. This can lead to huge personal issues such as identity theft, because the worry is not really about hiding, but rather about controlling your digital presence, and who can be you.

Aside from the research, I am also pursuing technical knowledge of cybersecurity, by following the online syllabus for Carleton’s cybersecurity course, and completing Lynda tutorials on web, server, and application security. I hope to use these skills moving forward to contribute to assessments of CMSs for our comparison project, and leverage these skills into professional opportunities in which I can learn more about the field and industry of security.

Over the long winter break, I began thinking and learning about digital privacy and security. After being exposed to the surface-level issues of corporate data-mining, social engineering, and personal digital privacy, I decided that one of my goals for this term would be to deepen my understanding of how privacy works in the digital world, and more broadly just in modern life.

You don’t have to look too far to find guides written by obsessive, privacy-minded techies with titles like “Hiding from the Internet.” There are people out there who will go to extremes to be completely concealed from the public eye, going so far as to buy cars with cash through fake LLCs, using temporary, preloaded visa gift cards for purchases, and never giving out their home address to anybody. On the other end of the spectrum are people who will happily trade privacy for convenience, who enjoy the luxury of services provided by Google, Amazon, and others, who don’t care that “their data” (whatever that may mean) is being stored in the elusive “cloud” and is being sold by companies to each other so that you see personalized ads.

Privacy seems like something that is intuitively desirable, and obviously provides some measures of personal security. On the other hand, barring instances of targeted attacks, there is certainly a case to be made from the “I don’t care” point of view — it could well be worth the potentially painless loss of privacy for some people to have access to all the free services, discounts, and other conveniences made available to us when we buy in to the system. Furthermore, there are plenty of people who don’t have the privileges (be it lack of time, money, or freedom in the workplace) to pursue complete digital privacy. What happens to them? What are the implications?

This term I hope to investigate this area, learn about how our data is being used in the public and corporate sphere, and determine how much control we have over it. With a thorough understanding of the business models, cultures, and processes in place that contribute to the widespread privacy violations we see today, I will be able to critically assess the risks and advantages associated with different personal privacy strategies.

This term was my first term working as the Digital Scholarship Ethics intern at Carleton. After learning the ropes, I was able to dive into research in fascinating and applicable fields. This term I learned how the web works, which was an important piece of groundwork for my research into digital ethics. As part of that research, I explored topics including web accessibility, personal/consumer data privacy, and large-scale algorithmic bias.

Web Development

My primary technical focus this term was to learn, broadly speaking, how websites work. I wanted to learn how a website is constructed and displayed in browsers, how it is accessed and used by the public, and what infrastructure is involved in hosting websites of various levels of complexity. After ten weeks, I can say that I have built four websites from the ground up: a database driven web application, a third-party hosted static site, a Drupal site, and a dynamic LAPP stack site. Through these projects, I feel as though I have gained a thorough understanding of the different methods and layers of web development, although there is always more to learn. I created the following diagrams to illustrate the technological processes behind what I perceive to be the two prominent models of web development.

Digital Ethics

My research into digital ethics this term focused on two primary areas: potentially unethical behavior unintentionally baked into popular software, and data privacy and ownership. As part of a project with the other interns, I conducted a survey of four popular content management systems, and attempted to establish standards for ethical comparison amongst them. We learned that depending on which aspect of ethics a particular organization focused on, their software would manifest itself with different advantages and disadvantages. For instance, WordPress, whose mission is to make web publishing available to as many people as possible, is incredibly widespread, and user-friendly. However, while there are options available to make WordPress accessible and secure, it takes a more advanced user to implement these changes. As such, for a more novice user, WordPress sites can be more vulnerable to security breaches and may not be as accessible out-of-the-box as Drupal. Drupal, on the other hand, whose focus is explicitly on high quality software, routinely rolls out patches to fix bugs and security vulnerabilities. Mukurtu is concerned with the ethical sharing and publicizing of heritage objects, and as a result, they have a very sophisticated permissions management system that regulates exactly which visitors to the site can view and edit particular items. The strengths of any software turn out to be directly related to the values and priorities of the organization that creates it.

The negative end of this spectrum is what happens when companies are most concerned with developing and distributing cutting-edge technology quickly. Fake news being surfaced by the search algorithms of Google and Facebook, algorithmic bias in machine learning, and racist computer vision are all results of development teams rushing to deploy features without thinking deeply enough about the ethical potentials of their software.

Of at least equal concern to the ethical grey areas being coded into our software is the collection and use of personal data. This term I have researched the intersection between corporations, individuals, and governments. Some corporations view personal data as a kind of currency; Individuals view it, at best, as a bargaining chip that can be exchanged for convenience, and at worst, as an aspect of our lives that we are rapidly losing control over. Governments are playing catch-up, trying to understand the best approach to business regulation that both ensures a certain level of individual privacy (which also needs to be determined) and is actually enforceable. It is fascinating to read about this conflict playing out in real time, as corporations try to self-regulate, governments try to figure out what to do, and individuals are all over the place in their beliefs about what should be the standards for privacy and government regulation.

Usability Conference

The other interns and I all attended World Usability Day on November 8th at the University of Minnesota. Presentation topics ranged from the fundamentals of accessible web design, to analyses of algorithmic bias, to the ethics of corporate data collection. It was my first time attending a conference of this kind, and it was a great experience. Many of the presentations and discussions motivated me to continue thinking and learning about the responsibilities corporations have (or should have) to their customers in terms of privacy, data protection, and social engineering. In addition to these questions about the future of our digital world, I also left the conference with a concrete set of guidelines for designing websites with accessibility in mind.

One thing that all of us interns noticed about the conference was the difference in style from a more academic conference, or a college course. The conference was much more industry focused than we were expecting, which rendered some of the information in the talks not very useful to us for the next few years. For example, one of the talks I attended was about how to conduct user testing in the most effective way. It was interesting to hear the ethical side of this discussion, (how to avoid abusing user data) but since I will not be conducting a focus group in the immediate future, that aspect of the talk was not very relevant to me. Knowing this about professional conferences will certainly help me in the future to decide which talks to attend at my next conference.