Eric Rochester

Hey, This is all awesome. This week has also been crazy, so I have had a chance to do more than glance at your pull requests. I'll check them out...

This is related to #48. Each exhibit gets its own record type, don't try to mix them. - schema change; - migration; - config form change; - change the search...

There are a variety of filters that we'll need to hook into for this: - [search_form_default_action](http://omeka.readthedocs.org/en/latest/Reference/filters/search_form_default_action.html) - [search_query_types](http://omeka.readthedocs.org/en/latest/Reference/filters/search_query_types.html) I'd like to spend a couple of weeks figuring this out, since...

The problems with making this bigger suggest perhaps having the bubble cover the timeline completely. For this, we'll need to do some testing and experimentation with different modals and transition...

Still need to check it out on Travis and get it fixed there.

This would mean just paying attention to the setting using `get_option`.

This would involve: - schema change; - migration; - admin config form; - passing the setting to the browser; and - changes in the timeline component.

We'd also probably want first/last buttons. To break it down: - add storing and tracking the current item; - pane for the items; - create position buttons; and - handlers.

This seems really interesting for changing the way omeka operates. Might need to hook into: - [admin_collections_form_tabs filter](http://omeka.readthedocs.org/en/latest/Reference/filters/admin_collections_form_tabs.html); or - [admin_items_browse hook](http://omeka.readthedocs.org/en/latest/Reference/hooks/admin_items_browse.html). And on the backend, it would be handled...

This would entail: - need to add a pane of widgets; - need to create and position the buttons; and - handler.