The Roy Rosenzweig Center for History and New Media is looking for a new contract developer to join our innovative, energetic, and hilarious team of developers. With guidance from our Lead Developer and Omeka Dev Team Manager, and in collaboration with other developers and members of CHNM, the new team member will work primarily on various aspects of our Omeka content management system. Duties may include helping to resolve issues, building new sites with Omeka, developing plugins and themes, and helping to design and implement future versions of the core Omeka codebase, as well as contributing to other ad-hoc projects within the CHNM ecosystem.

You can see the code at https://github.com/omeka/Omeka. Some other CHNM projects are at https://github.com/chnm.

Required

• Proficiency in PHP and Javascript
• Strong Object-Oriented programming skills
• Familiarity with the MVC design pattern
• Familiarity with Zend Framework
• Excellent communication skills with others at all levels of programming skill, from “Hello World!” novice to seasoned guru
• Ability to balance competing needs and priorities in designing code
• Creativity in problem-solving, and openness to experimenting with unfamiliar approaches

Preferred

• Experience working on open source software projects
• Familiarity with HTML5, CSS3, and graphic design principles
• Experience with Amazon Web Services and other cloud services
• Experience with PHPUnit testing framework
• Background or experience in the Humanities

CHNM is the leading producer of open source tools for humanists and of award-winning history content on the Web (for example: Zotero, Omeka, teachinghistory.org and the Bracero History Archive). Each year CHNM’s many project Web sites receive over 16 million visitors, and over a million people rely on its digital tools to teach, learn and conduct research.

Our preference is for a freelance developer who can join us onsite at George Mason University, which is located 15 miles from Washington DC, and is accessible by public transportation.

Please send a resume and cover letter to jobs@chnm.gmu.edu. We will begin reviewing materials immediately and will close the position on November 15.

The Omeka Team is happy to announce some changes to how we produce our lists of themes and plugins to make it easier for third parties to have their hard work listed there. These changes are intended to support our community of designers and developers, as well as make it easier for users to find help when using third-party addons.

Designers and developers will now be able to create a page about their plugin on omeka.org and upload their addon to share it with the world.

Designers should read the Designing a Theme page, and plugin developers should read the Building a Plugin page. Both designers and developers will also want to read the details about Preparing your addon for the omeka.org addons lists.

We hope that this will help our community expand and learn from each other, while also helping designers and developers publicize their hard work.

Please keep in mind that the system is new, and surprises could happen. Please help us improve the system either by asking about it on our dev list, or by submitting an issue about it on GitHub.

The Omeka team is very happy to announce some new and improved ways to help you get the most out of Omeka.

First, we have done some housekeeping work on our main documentation page. We’ve removed some clutter and added some better developed resources to make it easier for you to find what you need to get started.

Second, for people writing themes or plugins, or just making tweaks and adjustments to existing one, we have done some work to formalize and clarify how to write documentation for functions. We’ll be aiming to revise existing documentation to make it consistent with that template. This will be a community effort. Following a call to help us make Omeka better, we have a documentation working group of active Omeka users to whom we are very grateful for helping with that effort.

Last, we have introduced a new component to our documentation: “recipes” that provide real problems and solutions that the community has encountered. Like the function documentation, we invite anyone to register on the Omeka wiki and contribute. There is also a guide to how to write recipe pages. If you have created a particular effect or solved a small issue, you can help the Omeka community by sharing what you came up with. If you have learned from a thread in the Omeka forums, writing a recipe that distills your new knowledge is a great way to solidify it while you help others.

We are well into our fourth year of the Omeka project and are very pleased that there is a strong community of users and developers working in Omeka.

Thank you to those who already help in a variety of ways:

• helping fellow users on the forums and developers’ group;
• tweaking existing Codex pages that you think need a little love;
• chatting with fellow Omeka developers on the #omekaIRC channel;
• sharing your finished Omeka projects in the Showcase wiki.

In our continued efforts to ensure that this open-source project belongs to and is cared for by the community and not solely by CHNM, we are seeking volunteers from the community to help improve the documentation by forming a new Documentation Working Group.

We convened such a group over a few phone calls in 2009, and as a result we reorganized the Codex and added many more pages and documented many more functions.

This time around, we want the group to identify areas that need attention in theming and plugin development and customization. Such work may include defining helper functions, identifying useful patterns for plugin and theme development, enhancing explanation of the theme API, adding use cases for customizing specific design elements, or contributing other pages and elements to improve the depth and coverage of the documentation. We want members of this group to be active and regular contributor/editors to the codex and to the community, even if this is your first step toward becoming an Omekan.

We plan to conduct most of the working group discussions on the forums in the Documentation Working Group category, and anyone may subscribe to the discussions. While we will appreciate suggestions, we may ask users with many suggestions to help in the process of documenting.

We all benefit from the community’s participation and the variety of ways that you help fellow Omekans. We hope that through this effort to improve the documentation, we can expand the community of participants.

We are excited to announce two new Omeka plugins that were developed by the folks at the University of Virginia’s Scholar’s Lab. Ethan Gruber took the lead and since he knows much more about the EAD Importer and VRA Core plugins than we do, we asked him if we could cross-post his Scholar’s Lab blog entry, Expanding the Capabilities of Omeka here. Ethan is a web application developer for Digital Research and Scholarship, a division of the University of Virginia Library.

Note: Plugins available for check out through SVN for now, but will be available to download as zip files through the plugin directory in the near future.

Because I have a keen interest in the description of cultural heritage artifacts and in doing interesting things with metadata, in recent months I have developed a handful of Omeka plugins to meet these interests. My first foray into plugin development for the application was with the EAD Importer. The EAD Importer, as the name suggests, extracts item-level metadata (along with a bit of collection-level metadata, like rights) from Encoded Archival Description finding aids and generates a CSV file which can be imported through the CSV Import plugin developed by the Omeka crew. The plugin would be useful to archivists who would like to use Omeka to build online exhibits of their collections. I took this framework a step further to create a plugin that is capable of importing any flat XML into Omeka by transforming that file into a CSV file.

Most recently, I have turned my attention to expanding the descriptive abilities of Omeka into the realm of collections of artwork. Omeka items are described with Dublin Core, which is capable of describing anything, though not particularly well. I developed VraCoreElementSet, which incorporates VRA Core fields into the Edit Item form. VRA Core is a much more semantically appropriate schema for describing art and artifacts. Since it was conceived as an XML standard (not strictly a flat list of fields), some elements have hierarchical sub-componenets. For example, a work may have several agents involved in its production, and each agent has a name as well as a role, culture, birth date, and, as the case may be, a death date. The VraCoreElementSet plugin creates a table for agents so that a user may enter this data separately. Then in the Edit Item form, the user may select VRA Core agents from a drop down menu restricted by the records in the agents table. Records may also be exported to schema-compliant VRA Core XML. There is still some work remaining on this plugin, but it is well on its way toward completion.

Now that the Scholars’ Lab has contributed EAD Importer and VRA Core Element Set plugins, Omeka may attract new institutional users from the library, archive, and museum fields, who may have otherwise settled for proprietary applications to disseminate their digital collections.