Click on an item title to open an edit form. Then, click on the title again to hide the form. Open again, and this time click twice in fast succession on the title. Even though the form closes and does not reopen, the title will pop back up to the larger font size as if the form were open.

Either the title size change should be blocked, or the whole form should move in unison with the title. I prefer the latter.

If the first click action that takes place on the page is on one of the feature vectors, the click selection clams up and will not execute any further selection or deselection clicks. If there is a click on any of the item listings or any of the timeline events, this bug is not present.

Simile requires a history.html resource (e.g., at http://neatline.dev/admin/neatline-exhibits/editor/__history__.html?0). It can be a mostly empty file. See http://groups.google.com/group/simile-widgets/browse_thread/thread/a4ada2cfd3b7e1ce?pli=1

Items can be saved individually, but the user should also be able to save all pending changes at once.

Date entry for items consists of two text inputs that currently are blank and without any explanation of what formats are valid. The left field is for the date, and can accommodate any of these formats:

2011
June 2011
June 25, 2011

Commas are irrelevant. The second field is for time. Any of these formats are recognized:

3:00
3:00 am
3:00am
3:00 AM
3:00AM
3:00 pm
3:00pm
3:00 PM
3:00PM
13:00

There should be tooltips that appear when the user focuses on the inputs that explain this.

When the user types in a search string in the item search box, the queried text should be bolded in the listings that appear.

Currently, Simile Timeline is styled with the default css. This looks bad.

I wrote an application in the item edit form to create a date ambiguity gradient that gets applied to the intervals spans by the javascript (this can't be done with static css). This improves the situation, but we need to create a separate base stylesheet for the timeline that, ideally, makes Simile look less like Simile and more like the rest of Neatline.

This stylesheet should be queued as a static application asset on NL editor/public page load.

If the item has an active and extant time or space record, focus on the record data in the display blocks.

Bizarrely, the stylesheet that makes the Omeka admin look Neatilne-y is getting randomly loaded into other views, including the main item edit view, the settings administration, and some other plugin admins. This appears to be because the conditional code that checks the current module/controller is not specific enough, and it loading the NL css when it shouldn't.

We need Jenkins tests set up to run

The Javascript code needs to be checked out with jshint

In the topbar, there should be an option to shrink the editor so that the administrator can temporarily see the exhibit as an end user would see it. This would cause the item editor block to slide off of the screen to the left, and the top bar would shrink down to a very minimal size, just enough space for a "back to normal" button of some sort, which would reverse the action.

A quick / dramatic resize of the window can break the width sliding functionality of the item editor. Usually, after shrinking the size of the window quickly, the drag will still work in that state, but the dotted handle indicator will not display when the cursor hovers on the region. Then, if the window is dragged back open to a larger state, the drag will not work at all.

So that you don't lose the location of data that you've entered but unchecked as active.

When text is typed into the search box in the item browser, an ajax call is fired to fetch item results on keyup. In some situations when the latency hangs on one or another of the calls, you can have the situation when results populate for a completed word, but then one of the queries initiated by one of the previous keystrokes takes longer than the final query, returns null results, and overwrites the new list of results.

Each of these requests should cancel any other running requests to prevent this.

The code that auto-scrolls the edit forms to the top of the item browser in the editor relies on a $.data parameter attached to each of the item title listings that records the item's top offset relative to the item editor block. When the items listings are ajaxed in, the code walks the new list of table row elements and glosses on the event bindings for the form open, edit, etc. As it hits each element, it also computes the top offset relative to the whole div, and then when there is a click on the element the code scrolls the container to that vertical position so as to align the form at the top of the block.

This works for the initial items ajax load, some sorting/filtering/search actions break the code and cause the forms to not align properly at the top of the block. It seems as if the top offsets are either (a) not being recomputed, or (b) not being overwritten in the elements' data registries successfully. This bug can be hard to replicate, but it can be significant, since when things go bad it can cause the item edit forms to zoom way down out of the visible area on click, and a user likely would not even realize that the form is expanded below.

Needs ant tests for building, testing, etc.

Say an item form is open. If you activate one or more of the editing modes, and then select a feature, the modes should apply to the new selection.

This needs tests...

Jeremy made this change in the Maps plugin, but that change needs to be pushed over to the NL plugin.

• Pop the API call out of the NL templates.
• Have NL ping the maps code for the files.

Make the block layout editor available inside of the Neatline editor via a dropdown option in the top bar.

When an exhibit is deleted in the plugin admin, all association records for the exhibit in record_statuses, records, and time_records should be deleted as well.

Say that you have an item called "Test." In the items editor search bar, if you type "Te," there will be zero results. If you type "Test," you get the item as a result. This is because the server code currently relies on the baked-in Omeka search filtering code, which does not match partial results.

This is not intuitive, especially in an ajax content (think Google instant). I worry that people will see that partial strings do not return results, and not know that the full string would get matches. We should change this code to match partials.

Really, the best place for this would be in Omeka core.

In the item editor, hover the cursor on one of the S block for a given item listing. It turns orange. Then, move the mouse either left so that it leaves the S block and enters the item title block, or right so that it enters the T block. As the cursor leaves the S block, the S block should drop back to the blue highlighted color, since that is the base background for a highlighted row element. Instead, it goes to the true default yellow, which is the color for an un-highlighted row.

When the cursor leaves one of the S/T cells, the code should check to see if the row is still highlighted and push to the correct color. It may be necessary to bind a mouseleave event onto the whole row, as opposed to just the individual cell divs, and only push back to the yellow when the row div fires mouseleave.

The Space/Time column header blocks ("S" and "T") are clearing down out of their proper positions in Firefox (not in Chrome or Safari).

Right now, the item edit forms just open up below the item listing and the listing scrolls to the top of the region. This works fine now, since the forms are small and it's rare that they would be taller than the height of the window.

Since it's likely that more options will be added to these forms, though (configuration options for the appearance of the timeline entry, etc.) these forms will probably eventually become tall enough that it's conceivable that they could exceed the height of the items editor block.

This is not a huge problem, since you can always just scroll the whole container div with the items to see more of the form. But, this can be unwieldy if there are lots of items - going down just a little bit can be hard if the total scroll height of the region is really large.

On form open, (a) the other items listings should fade out to emphasize the fact that the edit form is the area of focus, and (b) if the form is higher than the item editor block, the form should only be as tall as the block, and smallscroll() should be added to the form itself so that the form can be scrolled independently of the container.

The neatline-editor.css file is large and difficult to work with. Starting with the layout-builder and gradient-builder widgets, I've started doing individual stylesheets for each widget. We need to go back and split out the neatline-editor.css and nealtine.css files into these stylesheets, each of which corresponds to a NL widget:

(Editor styles - should go in views/admin/css):

• edit-geometry.css
• item-filter.css
• small-scroll.css
• item-editor.css

(Public-facing styles - should go in views/shared/css):

• neatline.css
• neatline-map.css
• nealtine-time.css
• maybe neatline-undated-items.css, depending on how we decide to handle the matter of what should be displayed in that block, and if it should be materially different from the item browser in the editor.

Tearing out the correct styles should be a easy - the large stylesheets are clearly divided into sections that correspond to the widgets.

The fields on the Neatline admin input elements need the placeholder attribute on the input elements to prompt the user for their use (e.g. date vs time fields)

Right now, you can add features to the map, but not remove or edit them. Add these controls to the editor instantiation when an item edit form is opened and add icons to the toolbar that appears in the top right of the map.

The UDI displays items that have an active spatial record by no time record. It works essentially like the item browser tray, but without the editing functionality. On click on the items, focus map on item.

The backend/ajax structure for this is set up, but the JavaScript to do the display and wire-up with the other widgets needs to be implemented.

smallscroll() is a standalone widget that adds the scrollbar to the item filter drop down (and in the future to long item edit forms and popup description bubbles). If the cursor is on the scroll element for a smallscroll() instantiation, scrolling the mousewheel should cause the div to scroll accordingly.

The features to draw on the maps and save the information needs to be pulled into a separate Omeka plugin that can be installed separately.

The problem the right slider is statically set to have a higher z-index, so when the left slider is pulled all the way to the left is gets slipped beneath the right slider. But then the right slider can't be pulled righwards "off" of the slider track, so neither slider can be moved at all.

To fix, on mousedown on either of the sliders set that slider's z-index to 2 (or whatever) and the other slider to 1 (or whatever). Do that toggle on each mousedown, and the most recently dragger slider will always be accessible to the cursor, meaning that any action can always be undone.

When the window is resized, the timeline should shift the heights and positions of the two bands to stay aligned in the timeline block. Right now, this kind of happens, but (a) when the window gets too squat, the bottom numbers on the bottom band get truncated by the bottom of the window, and (b) if the screen gets too tall relative to its starting size the bottom band floats up off the bottom of the block.

Since occlusion is impossible to avoid beyond a certain point (part (a) above), the bigger issues is the small-to-large movement - the resize should always accommodate more space.

The administrator should be able to change the relative heights and widths of all display elements (map, timeline, undated) by just clicking and dragging on handles, like how the item editor width works now.

• Open an item that does not have an active spatial record.
• Add vectors.
• Click save.

When the vector data reloads, it double-loads on top of the extant vectors - for some reason the vectors that are there before the save are not removed before the new ones are layered on.

Right now the save buttons are the Twitter bootstrap default blue. This looks bad. They should be the Neatline default purple, with a vertical light-to-darker gradient (like the top bar in the editor). This isn't as easy as just making the color change, because the bootstrap styles on buttons are kind of leveraged with the specific colors they choose, and making changes to the hexes without also tweaking the gradients / :hover animations causes ugliness.

• Define a /neatline/id route.
• Write a separate instantiation script that omits editing callbacks.
• Add template for public display.

.

Currently, NL data gets saved like this:

• At the start, the code check to see if there is an extant DC field that makes sense in the context of the NL exhibit.
• If so, that data gets defaulted into the item edit form.
• If the user saves the form with that data, NL creates an association record that ties the extant element text in question to the exhibit id.
• If the use changes the default values, NL detects the change, creates a new element text on the item for that DC field, and then creates the association.
• Because of the multi-part structure of the time data (start date, start time, end date, end time), the associations table for the time data is separate, although it still write all new data as stacked DC Date elements on the item record.

In order to move the data stores off of the DC records, we need to create a series of Neatline-specific tables across the plugins to house the data. We need to nail down the specific structure of this. There are various difficulties and conceptual kinks - for example, does it make sense to store vector data on the Maps plugin, even though, taken individually, the maps plugin never has anything to do with feature data (only features and NL proper do).

Right now, you can only add existing items to the Neatline. What if you wanted to add totally new data? You would have to go back to vanilla Omeka, create the item, and then go back into Neatline and add it to the exhibit. This is unnecessary.

We should add an option, accessible through the top bar, that lets users add new items right in the Neatline editor. When you click on it, a new listing gets added to the top of the items listings block and a form expands below the item with all of the DC fields, like what you would see in the normal item add view. The form is styled just like the standard NL item edit forms.

When you save the new item, the form shrinks to be the normal edit form that you would see for any other existing item.

Item filtering has some odd behavior that I do not totally understand. Right now, when the All / None option is toggled, the code retrieves all items no matter what, and they all display. But, if you start filtering down the list - say, uncheck a single tag - the code then branches differently and just retrieves items that fall into one of the checked buckets (one of the tags, types, or collections).

Then, though, if you re-check the item that you unchecked, the full list of items does not reappear in its entirety (since the code is still checking for membership in the groups individually and not fetching all regardless of membership, as it would if the All / None were toggled). It is as if there are some items that are not selected when the code fetches all items that appear in any extant tag, collection, or type, which seems to be impossible. Theoretically, getting all items of all extant types should get all items, but it doesn't.

Either way, the behavior of the server code here is not intuitive, and the UX for the filterer should be improved.

Items search filtering fires an ajax request to fetch a new items listing on keyup. Each successful string-results combination should be cached, and duplicate string queries should be intercepted on the way out.

When an item form is saved, the map vector data should reload from the server, so that the new vectors are immediately coupled with the TL and editor.

Right now, the timeline popups are fairly small. Since these could conceivably used to present fairly in-depth and lengthy interpretive / descriptive prose, they should be able to accomodate larger amounts of text.

If the auto height of the boxes is above a certain constant (say, 400px), smallscroll() the content divs.

There should be a button, accessible via a menu/dropdown in the topbar, that, when clicked will record the current focus and zoom settings of the map and timeline and the current height/width percentages and make them the default settings when a user hits the exhibit.

When items get loaded into the Neatline editor item browser pane, four things need to happen for each item:

1. Check to see if the item has an active NL record for the timeline.
2. Check to see if the item has an active NL record for the map.
3. Check to see if the item has an extant DC element text that COULD be used out-of-the-box for the map.
4. Check to see if the item has an extant DC element text that COULD be used out-of-the-box for the timeline.

3 and 4 are important, especially when there are a lot of items. When I started using the editor, I immediately ran into the situation where I would enter time data for an item, add it to the exhibit, and then take it back off, and then have no idea which item it was that I added the data to.

Anyway, checking those four things for each of the items is currently done in a raw, enumerative way that triggers a large number of database queries for each item listings load, and causes noticeable slowdown when the editor loads (and whenever the items list is re-queried, like when the user filters the list by taxonomy or search string).

In the native-Omeka Neatline exhibit browser view, the "Edit" and "Delete" buttons clear so that they are vertically stacked on top of one another in Firefox. They should be side-by-side, as they are in Chrome and Safari.

If you try to create a Neatline exhibit without actually having an existing Map or Timeline in your database, you get the following error:

Before you can start a Neatline exhibit, create at least one map or one timeline.

Seems like you should still be able to create a Neatline exhibit without actually creating a separate timeline or uploading maps. You could just using any existing items, for example, and draw features on the base layer. Items themselves could also have date information that could appear on the Neatline exhibit's timeline.

If this isn't ideal, we should at least hide the create buttons until the user has the necessary Map and/or Timeline, with some explanation that they need to do that.

There is a suite of bugs triggered by the core vectoring edit tasks that appear to be related to a series of OpenLayers callbacks that get automatically called when map "controls" are added, removed, activated, and deactivated. Any/all of these produce bugs:

• Open an edit item form, add a feature, and click save.
  (If this doesn't produce a OL error, close the form and then try to open any other edit form)
• Open an item form and toggle the space record for that item on and off.

I am pretty sure that the essence of the problem is this: when a controls is added, you have to specify the layers that the control acts on. So, when I add modifyFeatures, I pass in the array of _currentVectorLayers. But then the code makes changes to that stack of layers - it might get totally replaced if a save is made and the stack is rebuilt from scratch; if an item edit form is opened for an item without an existing spatial record, a new vector layer is added.

Once these changes occur, it appears that OL chokes when virtually anything at all happens to the old control - if any method is called on it, even if the control is just destroyed. Once these errors get thrown, the whole JavaScript application shuts down.

My current approach to just aggressively destroy and re-instantiate these controls before and after any conceivable change to the layers stack. This has not worked so far.