Serious functional (and design) issue of Edit/New issue

Omeka S
1

Hello, the more I dig into Omeka S the more I appreciate the work behind it and the potential of using such a great tool. In parallel, I am discovering some issues as well, which, I mention them directly to the module creators and I even try to contribute to some of them. Today I’ve discovered a critical problem which seems to be part of the Omeka S “core”.

In my case, I have (at the moment) almost 3000 item-sets with title, description and some of them (around 400) with a thumbnail. Loading the form of an item-set takes some time (but it’s nothing to make you feel the system is slow). That’s OK.

I also have 20 items (which is literally nothing comparing to around 350000 which I am going to import).
The problem is when you edit an item or you click to create a new item, the form takes almost 7.5 seconds (among them 6.75 seconds if for the page waiting for server response ). Also, the size of the produced HTML source is way too big (~46000 lines of source code about 3.6MB in size)… !!!

So imagine you have to load 3.6MB in any single edit and that for just 3000 item-sets (I cannot imagine what will happen on 40-50K). Takes too long, causes problems… and actually is a bottleneck, making omeka almost non-usable.

Reading for possible solutions in the forum, I have tried to deactivate all modules (that didn’t helped). I tried to remove any extra vocabularies (that didn’t help as well). I have increased innodb_buffer_pool_size to 4GB (that didn’t help). I am pretty sure these are not the problem (as editing items-sets loads the form much much quicker).

I truly believe the problem relies on the third tab Item sets where ALL item-sets are preloaded in the sidebar without pagination (in order for the user to select 'em). On top of that the list of item-sets contains the description of each item-set (besides title) to be displayed on icon hover (that’s OK but at least keep just few words… in my case the descriptions are too big and not even fit in the hover bubble).

I would appreciate if you could deal with this issue as soon as possible, as having just 3K item-sets to cause such lag is very problematic. I will do my best to dig in the code as well but I am still at the very early learning phase so it will take me forever to have some tangible results.

Also, speaking of assigning item-sets to an item, my suggestion is (closely related to the aforementioned problem) to add a button in the sidebar next to the item-set edit form (where you can see the number of items belonging to that item-set) to allow you to create an item directly (so to pre-populated the item-set). I have watched closely end-users to go firstly in the item-set and then try to add an item in that “group”.

The latter is just a suggestion and a very low priority of course, but the former issue is quite serious in my opinion. I believe adding a pagination and a search field will fix the problem.

Thank you in advance

2

I confirm the problem is indeed the item-set list preload.

I have commented out the for loop inside ./application/view/common/item-set-selector.phtml and loading times dropped to 1.5 second. So, if someone who is confident with omeka framework could add the pagination in this it would be great

Hope that helps

3

Yes, the item set interface here (and some other places) is based on an assumption that there won’t be a very large number of sets and therefore that seeing them “all at once” won’t be an issue.

A modification here to solve this scaling issue is going to be somewhat involved: that whole interface for the item sets tab will have to be modified, with the sidebar that gives choices of sets working more like the one for items. There are other problem areas where the replacement isn’t so straightforward also, like search form elements that include a simple dropdown with all sets as choices.

3,000 isn’t such a large number, I agree. There are probably some smaller improvements to be made within the existing framework here that could help at a smaller scale (like possibly length limitation of the descriptions, as you mention).

1 Like
4

Hello,
yes, I understand the concept behind having all item-sets in “one-go” but in my case (and I am pretty sure in other cases) item-sets are heavily used. My project consists of about 80.000 item-sets so automatically makes omeka non-usable. At the moment, for about 3000 of them (while in testing mode), removing the description totally (including the icon) reduces the time load by 40% so that’s a big gain.

In my opinion this drawback should be put in a very high (if not urgent) priority in the development cycle (after all creating/editing items is where users spend 80% of their time in Omeka S). I am also trying to learn the framework but I believe for a newcomer, as I am, it takes X5 more time comparing to an experienced omeka developer.

I am really looking forward for any action on this (I realise this is an open source project based on its community members but this one is really a blocking factor)

I must say that is not more than a month to have my hands on omeka S and I am really impressed, so I am really willing to use omeka in this big project I manage and to generally promote omeka as well.

Best

1 Like