Design matters--but is not supported

Hello,

I am working on an archive project that has been met with many points of commiseration among my team, but I wanted to give an open discussion to those considering using Omeka–from a designer’s standpoint. We are using Omeka-S CMS with Reclaim Hosting as our file manager.

Omeka sites are assuredly full of content and the ability to add data to that content is of a wonderful caliber. Sites have great organization tactics for items, item sets, collections, etc. From the example list of sites, these are often full of content and delicately planned terminology.

From a VISUAL design standpoint, these sites are not “pretty”. I don’t care who you are, the sites do not look good. They are laden with visual inaccuracies, random visual hierarchy, and follow basic design standards to get the sites to a point of a “working” status. WYSIWYG is a very strong instance here. There is little to no customization in terms of block editing.
Some blocks can have classes, some cannot be targeted at all, some need to be targeted directly in a CSS editor (which is a plugin, btw, not something readily available), or in our case have had to go into the file manager on Reclaim directory and directly edit it there.

I worry for the folks who have hired a back/front-end developer and are “finished” with those sites–A question for you (you, who happens to be the curator of the content, not the developer), have you ever gone back and attempted to change some of the content? Was the interaction of designing with the site easy? Or met with confounding frustration?

An example dilemma:
A wanted to implement a simple two column layout.
One side has text, the other has an image. “I’ll just use a plugin for columns.”–the plugin is an older version and is no longer compatible. “Okay, I’ll just edit the .ini file to make it compatible with my version of Omeka.”–great, but now because of your method, you can no longer edit your page, which means the plugin is not supported, and is yet still on the list of modules I can install…“Okay, so I’ll uninstall the plugin, refresh…and I’m back at square one.”–right! Wait, you didn’t accomplish anything. Now, I can code this by hand in an HTML container to have a div/flex area, and properly implement the image by calling an image source…let’s say I, the developer, am no longer working on this. The site owner now wants to change that image but has no working knowledge of CSS or HTML. There is no “easy” way to swap out this image without having to directly edit the code, or to reupload a new image in it’s place. “What if I want to go back to a previous version in case I mess this up?”–bad news, omeka doesn’t have a version history, I hope you saved your changes to a file elsewhere. Let’s recall our desire, to create a simple two column layout.

In the vein of archiving and digital humanities (as this appears to be the main use for the CMS system) it appears that there is no oversight over the future of using Omeka as an option. As soon as the content is up, it’s up, and that’s it. I’m hoping you aren’t expecting customization, as it is nearly non-existent. I hope you don’t want to use a previous theme that is no longer compatible with the version of Omeka you have, as it will be broken if you do happen to make it compatible. I hope that you are not looking to the theme.jpg example on the github as a jumping point, because changes are not visually updated for the sake of example. Some themes might appear to have options, such a breadcrumbing, from the thumbnail image–not so, and often nowhere to be found in the underlying file structure.

Omeka is open-source. This is an understood fact. But if you are coming into the idea of using it as a design-friendly CMS system that you can customize visuals easily (without HTML/CSS knowledge), you will be met with frustrations. A problem that arises when a CMS system is created by coders/engineers, is that it is only meant for that kind of mindset. This CMS system is not meant for visual designers. I know UI/UX designers that would quit their job if Omeka was mentioned to them as their CMS system to use for a project.

I want this be a warning to you, the visual designer/coder who is working with archiving and digital humanities, that Omeka should not be your first choice from a visual perspective. Archiving, sure.

3 Likes

We agree that design matters (believe it or not).

Particularly with Omeka Classic, but to a significant extent on an ongoing basis, many design aspects were really accomplished by custom themes. Themes are very powerful tools for changing how a site looks, but obviously they require not only HTML and CSS familiarity, but generally also at least some with Omeka itself. So for many users custom themes are really not an option, which is where the provided themes, their options, the page blocks and layouts, and things like the CSS Editor come into play.

Omeka targets a wide range of users and institutions from those with no design support whatsoever to those commissioning elaborate custom themes, to everything in between. Designers work on and contribute to Omeka, but obviously the nature of a project like this is that many more designers work with Omeka, and we don’t always get a good sense of their needs and perspectives.

A very small core team works on Omeka which means that there are always more competing priorities and things to work on than there are people to work on them (though of course as open source software we often receive features and help from the community of users, developers and designers). On the plus side, it means that when you come to somewhere like these forums, you’re talking directly to the people who can make the change or fix the bug or add the feature you’re looking for. We really encourage people to come to us rather than treat problems as unsolvable; even if we don’t have an immediate solution for something, a problem we don’t see is a problem we’re probably not going to fix even in the future.

I’d be interested in hearing more specific information about the issues you’ve run into: which modules, which themes, which blocks, and so on. The simple example of something like a theme thumbnail not matching up with what the theme does, we should be able to clear up where (if anywhere) that functionality exists, update the thumbnail if it’s inaccurate, or whatever else. Even more wide-ranging problems or just general frustrations… it certainly helps us much more, and hopefully you as well, if we hear about them.

3 Likes

I just wanted to chime in here briefly, and say that our institution has used Omeka Classic and is now migrating to Omeka-S and as the designer and developer for these projects, I’ve never really felt constrained in any way design-wise. I would agree that out-of-the-box the themes and interfaces are somewhat generic, but I think that’s probably to be expected to a degree. Every time we’ve used Wordpress for projects we’ve also built custom themes, so I don’t find the idea of needing to build new themes/modules with Omeka as out of the ordinary or as a downside. In fact, I almost find it more exciting because you’re working with more of a blank canvas and not constrained by an overriding design aesthetic. But yeah, a lot of that probably depends on the amount of time you’re able to commit to developing these things for your particular project and the amount of coding you want to or can do.

-Joseph Anderson

1 Like

My 2 cents:
For years I used Omeka Classic to build audiotours and touchscreens and simplified content management.
However I restricted myself to using the RESTFUL API in combination with VueJS.
No restrictions in creating user interfaces!
The migration to the Omeka S version of the API was a bit of a pain, but it certainly pays of.
By using the API instead of the public site functionality of Omeka (S or Classic) you open Omeka for use with other presentation applications.
For instance I use Omeka with Pixilab Blocks.
Just create a user (and api credentials) who has read-only access to the API.

Hans Ruedisueli

2 Likes

I just wanted to commiserate a little, except my organization is using omeka.net, so I have even less access to its innards. Granted, I’m only a couple weeks in and still in learning curve mode, but it’s frustrating to know what I want to happen and then trying to find the workarounds and hacks that might accomplish that. It’s like – I know how to do this in the time it takes to type the code, if I were coding it, but then I spend a whole day figuring out how, if at all, it can happen in Omeka.net. On the other hand, I’ve worked in CMSes before, and this dilemma is not new to me. And, while some things are not as flexible or transparent as I’d like, it’s still way better than MediaWiki when it comes to visual design and enduser usability.

BTW, is there a forum dedicated to omeka.net users?

1 Like

Thanks for your thoughts here. Omeka.net is certainly a particular case because as a hosted solution, users don’t have access to the core files for editing. All of the customization has to happen through the CSSEditor, which is available for all users.

As John nicely outlined above, we are certainly interested in hearing about what you’d like to do and we are here to help. For Omeka Classic and Omeka S, that help can be found right here in these forums.

For Omeka.net, the assistance gets channeled through a web form that goes directly to the Omeka Team: Contact That support is provided as part of the hosting service, and should be your first stop if you’re stuck or if something isn’t working the way you expect it to.

I have used Omeka from the first year it came out and I have found that if you want to use Omeka effectively, you need to work with both the theme (php, css and html) and with plugins. Nearly every site I have worked on I have had to make fairly extensive modifications to css and to the various pages which display items, search, browse, etc. In addition, I have often found it easier to create new plugins or modify existing plugins in order to enhance the page layout, both in the theme and in exhibits. The creation of the various sites have also involved working with designers. In one case the designer worked independently from the team and basically created the website from scratch with the input of the principal lead on the project. I then had to take that layout and translate it into Omeka, making changes to css and html in a basic theme to get it to look like the designer’s idea or at least, as close as I could get. In another case, the designer was part of the team and we worked together with the php code, css and html to create a theme that worked for the project.

I would agree that the out-of-the-box themes are not “pretty” but usually, highly functional. I also don’t like the block style of most of the themes but that is largely due to the nature of the work that needs to be done, the display and discovery of a large number of differently styled items of many different kinds. While some on this forum may disagree with me, I have found over time that Omeka is not an out-of-the-box solution to creating a website but rather requires both good design and good coding to create “interesting” sites that go beyond the norm for Omeka. And it’s not easy. Many times Omeka had me wishing I could just build the site from scratch but then I would lose all that database and administration functionality that comes with Omeka. Through the years, I have learned to work within the constraints of Omeka and found that over time I cursed it less and less but I don’t know that I have stopped cursing it completely. Good luck.

Thanks for your thoughts, @wmcowan. As you and others suggest there is a remarkable amount of custom design going on both for Omeka Classic and Omeka S. We love that and want to support that work.

The Omeka Team has some constraints on the ways that we have to make our themes. The primary one is that the themes have to function well with each and every plugin or module that we make and support for the software. We know that no user is going to install and use 45 plugins, but we can’t anticipate which combination any given users will want. So, the base themes work with everything, and as a result are less visually distinctive out of the box.

Individual designers, on the other hand, do not have those constraints, and you’re making wonderful themes that are optimized for the smaller number of plugins/modules you have at work in your installations. Unfortunately, over the last 15 years, very few designers have been willing to package and release their work for community use.

We would love if you would do that – and just indicate in the README file that the theme is optimized for use with particular addons.

You can share your theme by registering it with us and then following the instructions for packaging your release on GitHub.

Thanks for your response. I agree with you about the plug-ins. I have half dozen or so plugins that I have developed that are available on the plugin page.

1 Like

I just wanted to chime in here, because I’ve felt @Olsen 's pain a little here and I don’t think you’re actually touching on what the problem is.

I enjoy creating custom themes - I think it makes each site look unique and you can make the sites very nice looking. I think the problem @Olsen is referring to is not with plugins themselves or theming in general - it’s creating different layouts in page content. The closest thing I can thing of in Omeka is in Omeka Classic you have the exhibit builder for creating different layouts with item in a collection and building different layouts.

In Omeka S, the page builder allows you to add blocks linearly, but not place blocks side-by-side in columns. When you look at a WordPress page editor you can add many types of blocks, one of these include a column layout. It would be nice if the Page editor could be improved to allow for this type of page building - with the end goal of making it easier for end users to edit pages with a variety of layouts (after the theme has been created and handed off) without having to know a lot of HTML and CSS.

@fackrellj Thanks for the feedback.

What kinds of blocks are you thinking of in Classic’s Exhibit Builder that you can’t replicate in S? The “page” system in S really is very similar to Exhibit Builder’s, but obviously the specific blocks vary a little bit.

We purposely decided to split up Exhibit Builder’s “File with text” block into a block that inserts a floating embedded file and one that outputs text/HTML. The idea was to allow something Exhibit Builder didn’t really: text that wraps closely around images, and potentially some more modular interaction with other blocks, so images could be floated with things other than manual text.

What this lost though was Exhibit Builder’s more fixed layout of file-with-text that results in a more columnar layout. You already get something approaching this in S with the floating “Media embed” block (the media embed is designed to float against an HTML block of body text, and attaching multiple files to one of those “floating” media embed blocks will have them stack on top of each other within the float, giving a column/sidebar effect).

S’s page block system could equally have a “side-by-side” block added that works like Exhibit Builder’s file-with-text, if that’s what you’re thinking of as missing. I’m not totally convinced of the utility of a more generic “columns” feature (for one, whether our existing blocks would really work well constrained to a column’s width), but I’d be interested to see the kinds of things you’d want to do with that.

So, I do think what we have does allow you to do some pretty similar things already, but we do absolutely always want to hear about it when people are hitting roadblocks on the page-building tools in accomplishing what they want. The whole point of those tools is to allow making the page you want without digging into the code, so when that’s not working it’s something we’d want to improve on, whether that means adding blocks, improving text, documentation and examples to explain how to build some things in the current system, or even bigger features or changes.

So there isn’t anything specific in the Exhibit Builder, I was just trying to think of an existing tool in Omeka that was similar to the what we are talking about.

My understanding, and what I have experienced, is that it would be nice to have page building tools that don’t necessarily try to incorporate other blocks. For example, if the HTML block worked more like the WordPress editor (not the whole page builder just that block.) I would like to just be able to easily make that part of the page a little prettier with different layouts: multiple columns, text beside images, etc.

I guess I’m just trying to figure out what you want to do with columns (or similar) in the HTML block. Text beside images for example is something the page editor is set up for doing with the blocks; that’s what they’re for. The page builder wants you to write your text in the HTML block and then add a “Media embed” block which will float the image/media to one side and have the text wrap around.

We could give you for example two/multiple spaces to put text/HTML within the HTML block and have it do them in columns but I don’t think that’s what you’re imagining?

I’ve been thinking about this problem since before @Olsen first created this post, but it inspired me to start working on a new module. For those who don’t know me, I am a librarian and web developer. I have worked with Omeka and Omeka S for both libraries that I work at and consulted for. One of the pain points has always been handing off the site to the stakeholder and trying to help them create great looking pages for their sites.

This module adds a new block to Omeka that can be added to a page and enables drag-n-drop editing content from a set of predefined templates. Users can then easily edit content, dive into the HTML, or use the interface to modify properties. It incorporates an existing drag-n-drop page builder called ContentBuild.js which is super powerful, but not free. You can check out a working demo on their site https://demo.innovastudio.com/contentbuilder/. As such, I can’t distribute the module in its entirety with that script, I’m still trying to figure out how to make it available to others.

I recorded this video just quickly demonstrating how the module works: Advanced Page Builder

I’d love to get your feedback and hear from anyone that would be interested in the module. I’ve tried to answer a few questions you might have below.

The module is added to any page just like any other block.
You can add multiple instances of the block to any page and as you can see in the video you can also include other blocks on the page with this one.
It should work with any template and doesn’t rely on an external CSS framework like Bootstrap.
I’m hoping to continue developing the module to enable front-end editing and add asset and media selection for the images.

5 Likes

Hi all - late for the thread, but I still want to add a few words.

I very much understand @Olsen’s frustration, as I’m also stuck on the same issues that they are stuck at.

The many replies above address very particular points, and they are important, but Olsen’s point is a larger one. There’s a UX design language consistency that is missing from Omeka S’s design. I will continue with the example provided:

I want to design pages with some very heavy customization, a kind of scrolly-telling approach. That is currently very difficult to get done using the tools of Omeka, and it forces me to use the ecosystem of PHP, instead of the much more robust ecosystem of modern Javascript.

What my projects have opted for is to use Omeka to store items, add pages using the blocks system, then build a modern interface using VueJS that consumes the API and renders it the way I want. But I run into another problem:

I still want to use Omeka to edit pages. So I use the blocks system. But, while the HTML block has a css class option, the item show case does not. This kind of inconsistency means that I have to write PHP code instead of sticking to the Javascript system that I have invested significant amount of time building for my needs.

I used to be extremely frustrated with Omeka, but the more I get used to its design quirks, the more it “grew” on me. So I’ve found workarounds to the parts that frustrate me, and I stuck with the parts that I like. I know that the project is growing in the right direction, e.g. the value annotation feature in 3.2 was super interesting and useful. And that is what keeps me sticking around and using it.

To move forward, I would say that a public community road map would help alleviate a lot of the frustration that people feel. If I knew what to expect in the future, I would be able to adjust my expectations to align with it.

All of that said, I appreciate the enormous amount of effort that the small-yet-powerful team has been putting into the project for years and years. Keep up the great work!