This term, I customized the transcription page in the virtual workhouse Digital Archive(VWDA) site. I also taught myself Java Script as some of the future customization required knowledge of JS.
With regards to customizing the transcription page, I had three tasks to accomplish. The first one was to set up mediawiki and install Scripto to get the transcription page on the Big Picture theme in Omeka. The second one was to set up the transcription page and the image side by side instead of top-down order(images below). The third one was to change the next previous to respect search results on VWDA. I got help from the Omeka documentation to accomplish these tasks. I had to fix the display-inline block for the side by side transcription display while the search customization involved making new navigation function and then changing the way the search is browsed and showed on the site. I tried not to change the code in the original files as much as possible as new Omeka version updates would otherwise not sync. I was also pushing the customization changes to the DigitalCarleton's theme-bigpicture repository in the GitHub https://github.com/DigitalCarleton/theme-bigpicture . I learnt about making descriptive commit messages and pushing those commits for every major changes in the code.
Towards the end of the term, I learned JavaScript online and tried to understand how it is being used in Omeka. My previous experience with learning new languages/coding for the internship was very helpful in making sure I was learning how to accomplish specific customization tasks in Omeka using Java Script.
1. Previously:- Top-down order

2. Updated:- side by side

INTRODUCTION:

Omeka is an excellent platform for Digital Humanities projects and a potentially great starting point for individuals starting with PHP, Web Development, and Digital Humanities. However, so far my experience trying to work with plugin develop in Omeka using it’s existing documentation has been a struggle. Simpler language and elaboration on basic concepts would have made for an easier experience and let Omeka become more accessible so it may act as a springboard into the realm of Digital Humanities. This blog post overlays this overall impression of the Omeka plugin development tutorials and the general concepts I took away.

 

TUTORIALS:

In an attempt to gain a basic understanding of plugin development in Omeka, I reviewed these following Omeka tutorials:

• Plugin Directory Structure
• Best Practices for Plugin Development
• Understanding Hooks
• Understanding Filters
• Understanding Omeka_Plugin_AbstractPlugin

 

OVERALL IMPRESSIONS

The tutorials taught me how some parts of Omeka works and some plugin design concepts. The examples that the tutorials used were extremely helpful for introducing new concepts. I found the Plugin Directory Structure tutorial with its simple language to be the most understandable of the tutorials, but most of the tutorials seem targeted to people who already possess an intermediate knowledge of Omeka. Thus, as a new user with a limited understanding of Omeka, learning plugin development from the tutorials has been a struggle for me.

The main struggle I experienced with the tutorials came from the numerous unfamiliar terms and topics introduced and left undefined. These terms are either a technical term or Omeka terminology. One example of this is when the Understanding Hooks and Understanding Filters tutorials assume the user is familiar with using callback functions. As someone who just learned the basics of PHP, it took me awhile to wrap my head around the concept of callback functions and until I did, I couldn’t understand much about hooks and filters. A short description of what callback functions are, an example of one being used and a diagram of one in action would have improved the clarity of those two tutorials for new users like me.

When the tutorials include Omeka terminology, such as views, options, forms, saving, and records, I could pick up their general meaning from context, but without a clear understanding of these basic concepts, the learning curve for these tutorials was much higher than needed. An Introduction To Omeka tutorial outlining Omeka’s basic design, describing necessary concepts, and defining key terminology would be invaluable for new users. In addition, a PHP For Omeka tutorial could help those with little PHP experience. Some diagrams showing Omeka’s general structure would be helpful for visual learners. Overall, if a section of the tutorials assumed the reader has minimal knowledge of both PHP and Omeka, new users could learn plugin development in Omeka with greater ease and Omeka would be more accessible as a learning platform for the Digital Humanities community.

 

GENERAL IDEAS FROM TUTORIALS

While not targeted towards new users, these tutorials do contain a surplus of useful information and these are the general ideas I took away from them:

• You start building a plugin by creating the folder that will contain your plugin ini file, which contains general information about your plugin, and the other plugin files.
• When building a plugin you use hooks and filters.
  • Hooks are a set of functions that send messages up through different parts of Omeka (see Understanding Hooks). They are activated at regular points in the Omeka code and you can add your own functions onto a preexisting hook so it will be called at those regular points in the code.
  • Filters modify information and like hooks are activated at regular points in the code (see Understanding Filters).
• You can add your own functions calls in a filter to add data, such as adding an additional link to the navigation link array.
• When building a plugin, you’ll want to use Omeka’s AbstractPlugin class that keeps hooks and filters in sets of arrays and allows for different sets of options to customize the plugin class.
• To query Omeka’s databases, you can use the Omeka_DB_Table class that returns the data as Omeka’s Record objects.

In short, Omeka uses on sets of functions called hooks and filters that are activated throughout the program. You can modify these for custom functionality. Omeka also has predesigned classes for its plugins, records, and database querying that you can use.

 

GOING DEEPER: BEST PRACTICES

Omeka lists a number of best practices in its best practices in Omeka plugin development tutorial. While the first couple of these are easy to understand for those with the briefest exposure to coding, they become more and more complex as you continue through the tutorial. This is what I took away when reading it.

Some best practices in Omeka plugin development include:

1. Make methods camelCase and start private and protected methods with an underscore.
2. Be careful to not change standard Omeka behavior when overwriting methods.
3. Use View Helpers, which are helper methods for the view class, instead of global functions, which pertain to the whole of the class.
4. Send all processes that may run longer than a typical web process to a job by creating a class that extends Omeka_Job_AbstractJob and running a function from it. Either run using default or long-running depending on how long it’ll take.
5. Set up your plugin’s configuration page using the framework Omeka provides for you. When a user installs or upgrades your plugin, Omeka redirects the user to the configuration page. The data the user submits on that page is sent as a POST (an array of data from the submitted form). You can use the config_form hook to handle that POST and update the options or other settings. You can keep the code to do this in a config_form.php include file.
6. Omeka lets you build forms for records with different options available.
7. Use Omeka’s search_query_types filter and the search_sql hook to add a new search type to Omeka’s search form. This can make your record full-text searchable and customize it with three search query types: keyword (full text), boolean, and exact match.

Overall, it seems to say that one ought to become familiar with classes and tools that Omeka provides and work with them in ways that are efficient and won’t disrupt the normal process of Omeka.

 

ENDING SUMMARY

Omeka is a powerful content management system for Digital Humanities project and could be a great starting point for those beginning Digital Humanities work with a slight shift in intended audience in the documentation. Currently it uses advanced language and it assumes a familiarity with programming concepts and Omeka terminology, but with a chance of language, elaboration on new concepts, and more references to other resources it could become much more accessible for new users. For those who are new users, the current tutorials do contain useful content even if they have a high learning curve. They explain the sets of functions called hooks and filters that Omeka activates throughout its files. They also introduce you to Omeka’s plugin, record, and database querying classes that you can use. In terms of best practices, one wants to become familiar with classes and tools that Omeka provides and use them efficiently while not disrupting Omeka’s the normal running process. Overall, it would be helpful for new users if the tutorial were more accessible, but even if they’re hard to comprehend, they still contain useful information.

Alec Wang

This term, I have been learning the principles of inclusive design and using accessibility tools to evaluate a few projects the Digital Scholarship program is managing. In this post, I want to talk about the knowledge I've gained through analyzing Religious Diversity in Minnesota.

Most of the accessibility-related assessments are generated after running WAVE, one of the most popular and comprehensive web accessibility evaluation tools in the market (you can install it as a browser extension too!). A seemingly perfect website for users who do not require accessibility features, this site actually contains many areas of improvement!

[caption id="attachment_9" align="aligncenter" width="264"] Out of all the elements detected, some - especially errors, alerts and contrast errors - require immediate fix, whereas for categories like features and structural elements, the engineers should check for correct use[/caption]

Don't be intimidated by the huge numbers though! Some errors/areas calling for attention occur throughout the site and are counted repeatedly. This should serve as a reminder for web content creators and designers to be extra careful while writing the code, especially when we have multiple recurring elements - messing up one could mean messing up 50/60!

[caption id="attachment_10" align="aligncenter" width="201"] Redundant title texts and alternative texts show up for many times![/caption]

On a more serious note, out of the 6 fatal errors found, 5 are related to missing form labels/empty buttons. Although the missing labels/descriptive texts in buttons would not affect the functionality at all, it makes it impossible for screen reader users to navigate to the corresponding elements, therefore creating a huge inconvenience and even injustice for them.

WAVE also has a section dedicated to color contrasts. On Religious Diversity in Minnesota, there are 33(!) very low contrasts, all of which will contribute to an increased difficulty in understanding the contents for our color-blinded users.

[caption id="attachment_11" align="aligncenter" width="258"] We want all sizes of normal texts and large texts to pass the contrast test - WAVE has an imbedded contrast testing system that could make editing much simpler[/caption]

 

[caption id="attachment_12" align="aligncenter" width="213"] Simply by pressing darker and lighter until all cases pass, we can know which colors to adjust the background & foreground to[/caption]

Another great tool to for checking color contrast is the Colorblind Web Page Filter. Unlike the contrast tool in WAVE that's used more while developing the site, Colorblind Web Page Filter enables the owners to take a look at how the site performs overall, after having all the elements settled. It can apply four different kinds of filters for distinct types of color-blindedness.

Whereas WAVE and Colorblind Web Page Filter are fairly easy to work with for me, someone who had no experience with accessibility issues before this internship, ChromeVox - a screen reader that brings speed, simplicity and security to visually impaired users - requires a longer adjustment period. It takes some time to understand how to navigate the websites with only keys and remember the keyboard shortcuts. Besides, to have a more authentic experience of using ChromeVox, it is essential to pretend that I was a user with visual impairment myself, an unintuitive and frankly frustrating process. Out of everything, the ChromeVox testing and development stage made me genuinely appreciate being a user with a myriad of abilities.

Speaking of abilities, I want to share something I've learnt from Microsoft's Inclusive Design earlier this term. It completely changed my perspective on accessibility! Here you go - we often consider disability as a personal attribute or a personal health condition; the term disability only applies to people who are blind, in a wheelchair, or with other visible form of permanent disability. However, the need for additional assistance is really more context dependent and reflects mismatched human conditions. The same abled people can move through different environments and have their abilities change drastically. For example, we can't hear well in the dining halls at 6pm, we have to hit the "open door" button when we are carrying too much stuff, we can't really see the path when there's a snowstorm... To give a better illustration of the impact - in the United States, 26,000 people a year experience loss of upper extremities. But when we include people with temporary and situational impairments, the number grows exponentially to greater than 20M! This shows how important all this accessibility work is!

Sarah and Celeste's team made a really awesome poster for a Digital Humanities project:

As informative and interesting as the poster is, I personally feel like there are also areas for improvement. To begin with, as someone with short attention span and a dislike of dense materials, this poster simply contains too many words! Navigating through the poster to sift important information requires a lot of effort. It would've been cleaner and more straight-forward if some paragraphs are shortened or presented in alternative manners, which brings me to my next point - the development timeline could've been represented by a line, with marks indicating progress. Similarly, the research questions and results could be possibly connected by elements of graphics with short explanations by the side.

From examining this poster and trying to identify potential areas for improvement, I have learnt that giving criticism gracefully is tied to making concrete, meaningful suggestions, without which criticism could face the danger of turning into useless rant.

Criticism of the poster: https://goo.gl/vh1SuQ

This poster is very informative with concise bullet points. However, providing more explanation of some terms, such as UX and contextual temporalities, mentioned in the poster would enhance the understanding of readers lacking background in religious studies and augmented reality. While there isn’t much space left on the poster, adding definitions to the back is an option.

What I learned about generous feedback:

• Positive, specific suggestions can be seen as helpful and are often taken well. When expressed correctly, they offer a clear path to self-improvement.
• Use empathy when giving suggestions: “Would I like to hear that about myself?”
• Never criticize the individual. Always point your criticisms at the actions.
• Don’t attack attack, insult, or be mean in any way.
• Don’t tell the person that they’re wrong. Tell them how they could do better