When the user clicks one of the browse categories (saved search items) on the Browse landing page (#66), they should be shown a results page for that browse category, as shown below.

(See also, #3)

Initial Fields:

• title
• subtitle
• description (plain text only; should sanitize value before storing)
• contact email (multi-valued; could just be a serialized field)

The email field should be syntax-validated.

All(?) facet-eligible fields should be displayed here, with default labels.

User should be able to drag and drop facets to specify desired display order.

In a future sprint, we should add support for e.g. range select facets, single-valued facets, etc.

https://github.com/sul-dlss/spotlight/blob/master/app/assets/stylesheets/spotlight/application.css#L16

(See also, #4 )

The exhibits setting page should be restricted to users with an admin role.

(Wireframes: page 24)

Exhibits setting should be stored somewhere in the database, and displayed where appropriate.

For Sprint 1, we should just support the title, subtitle, contact email, and description.

Need site header so there are links to the Admin and Curator index pages (via the logged in username dropdown menu).

Curator index page is page 27 of wireframes (Items).

Admin index page is page 24 of the wireframes (Settings page with exhibit title, subtitle, etc.).

Main menu navigation should be dynamically created based on characteristics of the exhibit. That is, not every exhibit will necessarily have the same main menu links. If the curator for a given exhibit doesn't create any features pages (or doesn't have any defined feature pages checked to be visible), for example, we shouldn't show the "Curated Feature" link. If the curator has not saved any searches to use as browse categories (or doesn't have any saved searches checked to be visible), there shouldn't be a "Browse" main menu item.

There should always be a Home link.

See below for more details.

Curator should be able to create and title new feature pages.

Feature pages should be sortable and nestable using some javascript-y widget.

Pages only need to be nestable one level deep; parent pages can have zero or more child pages, no further nesting.

The Add New Page button should add a new row to the list (similar to adding a new About page; see screenshot in #27).

Create a widget that takes an item id and displays the image and title (from the indexed title), displayed as a caption) for that item.

Use thumbnail associated with item document.

Ensure reasonable display when image is not available with item, and when the title is not available.

Do we have anything that does that already?

1. Use Add new page button to get new page form
2. Enter a title (or not, doesn't affect error)
3. Click Create page button (without adding a widget)

Curators should be able to choose the fields that are displayed on a search index or search result page.

Mapping solr fields to display labels will be provided (in some ticket yet to be created).

(ignoring sortable, exhibit-specific fields, etc)

The gem itself needs a name other than just "spotlight" because "spotlight" is taken.

Image and Title, for now.

Curator should be able to edit a defined feature page to add or edit available widgets.

(any chance we can get away with third-party libraries here?)

Administrators should be able to find existing users or create new users. If a new user is created or roles are changed, an email should be sent to the user to let them know that their account was created (for Stanford's use case, this does not need to include a password set/reset prompt; maybe for others it will?)

(The screenshot implies usernames vs emails; for Stanford, these can be one and the same.)

Wireframes : Page 25

If the curator has saved searches that are selected to be visible on the Curation: Browse page (#11), those saved searches should be presented on a Browse Exhibit landing page, as shown below.

This page is the index page for the Browse main menu link. If there are no saved searches selected to be visible on the Curation: Browse page, the Browse main menu link should not be displayed (#35).

Blacklight 5.x might drop saved searches from core. Some features here use that behavior, so we should build it out.

Erik and the lucid project may have similar requirements and we should make sure to get their feedback.

The second part of the Curation: About Pages page is a section for capturing details for the contact person(s) for the site. (These details are to be displayed in the About page sidebar; see #40).

A contact is not required. But for each contact that is entered, the Name and E-mail fields should be present; e-mail should be a valid email address.

Clicking the Add additional contact button should add an additional set of name, e-mail, title, and location fields. Each set of fields also has a "Show in sidebar" checkbox associated with it.

All Admin and Curator pages should have a sidebar (3-col) to hold links to the Admin and Curator pages.

As I curator, I should be able to create exhibit-specific fields for items. These fields should (eventually) be indexed as text into Solr.

These exhibit-specific fields will be populated from item edit pages, and will be configured for displayed as in #7.

When a contact email address is added or changed, a validation email should be sent to the email address.

Share and follow links are now in footer. Links here are global; they are for sharing the exhibit title and link to the site itself, not a specific item.

Curator should be able to go to an About Pages page to add and change titles of about pages.

Curator should also be able to reorder the pages to indicate the desired order in the About pages sidebar menu.

Curators should be able to see a compact list of all items in the index.

For Sprint 1, we just need a list (of title, type and date added, I guess). The functionality, included Filter, will happen in a future sprint.

If there is at least one contact defined and checked to be shown in the Curator: About Pages contacts section (#39), show the Contact heading in the About page sidebar with the fields for each contact that has been selected to be shown.

Pages need to be re-orderable.

Pages may have a parent page.

If a page has a parent page (or child pages), the curator may want to show a sidebar with that hierarchy for navigating between pages.

Pages have some administrative configuration (whether having a sidebar is an option, etc)

Tags are created and edited only by curators; they can be used by curators effectively group arbitrary items that can then be saved as a saved search and used as a browse category.

Tags can also be used by end-users to search on all items with a given tag.

All About pages should have a sidebar with links to all About pages that are checked to be visible.

Order of pages in the menu should be based on the order of the pages in the Curator: About Pages page.

(cbeer to fill out)

Search parameters need to be titled and shared for all curator users.

We should pre-generate the Home page and About page features with demo content.

Curator should be able to edit a defined about page and:

a) add text via a text widget
b) add an accompanying image (an external, non-repository image) via a image widget

All About pages should have a sidebar with navigation links to other About pages.

For all About pages that are checked to be visible, create a link in the About page sidebar, using the titles defined in the Curation: About Pages page.

Showing /Users/justin/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/blacklight-5.0.0.pre2/app/views/layouts/blacklight.html.erb where line #17 raised:

undefined method `opensearch_catalog_path' for #<#Class:0x007fb1b4ad9568:0x007fb1b4ef9580>
Extracted source (around line #17):

       <![endif]-->

       <title><%= h(@page_title || application_name) %></title>
       <link href="<%= opensearch_catalog_path(:format => 'xml', :only_path => false) %>" title="<%= application_name%>" type="application/opensearchdescription+xml" rel="search"/>
       <%= favicon_link_tag asset_path('favicon.ico') %>
       <%= stylesheet_link_tag    "application" %>
       <%= javascript_include_tag "application" %>

• Text block
• ZPR

• Text block with image

• 2-up images

• 3-up images

• Multiple image carousel(?)

• Featured Item
• Image Viewer
• Flipbook
• Item Carousel

Spotlight needs to provide a user model and/or mixin to provide access roles for the application. Ideally this would be a mixin (to the extent it does anything?) and migration.

Initially, we expect Spotlight users to be either a "Curator" or an "Administrator".

The application (we expect) will use cancan to provide abilities to check for these roles.

Users may also have a user profile with affiliation, title, etc.

Bootstrap Carousel, with controls to adjust the automatic advance.

On this page, we need to show the list of (curator) saved searches (from #12).