Use the gridlist layout with UJS to browse templates.

When content is edited it should be set to the pending state on any feed it has already been approved / denied on.

As an example:
Upload Slide 1 to feed 1
Content requires moderation on feed 1
Content gets approved on feed 1
Edit piece of content changing name
Content requires moderation on feed 1 again

The sidebar actions (such as moderation controls) look terrible and should be fixed up pronto.

Create layout for screens#show view

Right now, the creation of feeds is only seem to be available via guessing the right URL. These probably deserve a place in the UI somewhere.

Make it work like Github's tree browser - always update the URL shown inside the web browser to the current view and also allow a user to use the back button within her browser to navigate to URLs previously stored on the stack.

Blocked by #15.

Finish the conceptual design for screens#index and screens#show. This issue will not require a working implementation yet, just a conceptual design that we're happy with.

We want to have the ability to quick-filter lists of feeds and other types of lists based on a filter string. Take a look at the "assignee" dropdown on Github Issues for inspiration - it allows the user to start typing to quick-filter the list of people associated with the project. We'll want to be able to use this type of filter control in multiple places and with multiple types of lists, including lists of users, groups, feeds, and screens. We should figure out a good way to abstract this functionality (jQuery plugin, perhaps?) so that we can leverage it pretty easily across the application.

This will consists of documenting an algorithm (see Concerto Frontend in the wiki) and then implementing it either in a model or library class.

Concent#new date and time pickers aren't working for me in Chrome.

JS Console is throwing some errors:
application.js:9831Uncaught TypeError: Cannot read property 'selectDate' of undefined
jquery-ui-timepicker-addon.js:572Uncaught TypeError: Cannot read property 'selectDate' of undefined
jquery-ui-timepicker-addon.js:64Uncaught TypeError: Cannot read property 'defaults' of undefined

To be used inside the submissions#index view when a user is browsing a particular feed - the user should be able to click the "Jump to Feed..." button and receive a filterable feed hierarchy inside a dropdown panel.

Use bootstrap's dropdown plugin or roll your own.

Create a component that can be called by the user inside a dropdown panel on any feed browsing page to quickly jump to any other feed in the system. When the user clicks on the trigger, the panel should present a hierarchical feed tree with the current feed highlighted and the ability to quick-filter the list by feed name. All of the feed links should be URLs to the submissions#index view centered on the selected feed.

This might consist of a button that opens templates#new in a new tab for now. Consider integrating an AJAX remote form to allow the user to directly add a new template without ever leaving the screens#edit view.

Submodules confuse people, this should be a gem.

The template import code is poorly unit tested and there are no functional tests.

Add filtering capability to hierarchical lists of feeds in contents#add and submissions#index (the main browse feed mode). This should allow the user to quickly filter the list of feeds by text string.

Ensure common use of comments and structure throughout our SCSS tree.

Currently gridlists (the matrix-esque layouts for browsing content and other visual objects like screens and templates) all look the same no matter which type of content is being rendered within. We should add a visual indicator of some sort (an icon, perhaps) to denote different content types from one another in the same gridlist. This indicator could be incorporated inside the thumbnail preview of the content, or it could be placed in the corner of each gridlist item.

Bump the Gemfile and update configs / generated code like 126cd50.

PDF files should be uploaded and converted to images. We should handle multipage PDF uploads if possible, but the first page would be feature-on-par with Concerto V1.

Reduce the vertical height of the topbar and give it overflow (multiple lines of menu items) and auto-hide capabilities.

To support shuffling as described in the Concerto Frontend wiki page, excluding multi-page content, a few things must happen to the tables and actions relating to the involved models.

1. Add ordered/shuffled option to feed model
2. Add an auto-incrementing order field to the submission model
3. Add segmented/interleaved option to field model
4. Add an auto-incrementing order field to the subscription model

I'm using different names for the header and body partials that get loaded by the index and show actions within these three controllers (_list, _content, _feed). They should be renamed to be consistent.

When a user navigates through a remote-loading JS view and then over to a plain old HTML view, using the browser back button results in plain JS being shown without being properly rendered. For example, navigate to /feeds/1/submissions with JavaScript turned on, then go over to /screens - when you click the browser back button you should see plain, unrendered JavaScript.

The problem might be caused by the popstate binding inside application.js:

      $.getScript(location.href);
    });

Instead of always rendering the 'original' Graphic, we should render the 'processed' one if it exists.

Processed Graphics could be the result of conversions from formats that can't be displayed in browsers (see #4) or other tweaks / filters to optimize the original upload (perhaps dropping quality to 90%).

The top bar is large and should be hidden on views where it makes sense to focus the user into the main content area of the page (for example, when zooming into a piece of content and viewing the submissions#show view for that content inside a particular feed). When the user goes to these pages, the top bar should slide up and only appear when the user either backs out of that view or moves the mouse up to the top area of the screen where the top bar usually resides.

When there are no feeds available to serve as a parent feed the parent feed drop down shouldn't so up at all on the feeds#new form.

As an example, wipe you database and go to create a feed. The parent feed selector just takes up space.

We need to support 1 Content with multiple pieces of media behind it. This should probably be a new Content Type, like MultiGraphic or something like that.

Templates don't have height and width information right now. Was this intentional? Should we be storing pixels, ratios, or something else?

Build a form partial that can be used for each screen field within screens#show. This partial should include the mechanism for finding a certain feed in the database (using the filter plugin from Brian M), adding it as a new subscription, and assigning it a weight (weight column inside the subscriptions table schemata, which is an integer). Basic controls should be provided to edit and delete subscriptions for a given screen field.

A fresh install requires the following to get up and running, we should provide seed data for folks:

1. Group
2. Feed (requires a group to own it)
3. Fields
4. [If feasible] Template + Positions (requires field for each postion)

Users should be able to join groups with the Pending membership level if they do not have an existing membership in the group.

Create the applicable plugins and ujs js.erb views for the contents controller and submissions controller to enable AJAX content browsing.

A group admin should be able to change the level of a member, including the ability to place them in the Reject (-1) state. The reject state doesn't exist right now, so it should be added.

is_admin is not an accessible field in the user model.

Rails gets angry and throws an error when trying to make a user an admin.

Design layout for front page of Browse

Right now the gridlist selector simply lists the name and author for a template - it should also show a mini thumbnail image of the template background.

This should be the view / controller / whatever that screens talk to. We can add functionality after we get a URL and some code in place.

Currently I'm using a placeholder thumbnail image for all graphical content in the Browse Content grid (view code found in submissions controller, #index method for .html.erb and .js.erb files). We need to display similarly sized thumbnail images of graphical content in the grid.

Right now, the creation of templates is only available via guessing the right URL. These probably deserve a place in the UI somewhere.

There was a security vulnerability, we should get the fix for it.

Bump when the build isn't hot / no one is working.

These are devise defaults ATM....

Find all available templates and display them inside a listing to allow the user to select one for the screen. The current categories (based on screen dimensions compared to the template dimensions) seem to work pretty well - by default, hide the templates that will not work well for the current screen.

Add a CSS3 fade transition to the frontend in addition to the current JavaScript opacity transition.

http://css3.bradshawenterprises.com/cfimg/ has some useful implementation ideas.

Investigate different ways of displaying content in a responsive nature based on the default viewing size of the browser (as with different mobile devices) and browser resizing. Twitter Bootstrap 2 uses some interesting HTML5-backed strategies for doing this.

This should not be considered a high priority until after the launch of Concerto 2.0.

I wonder if WebGL transitions would render better in the Frontend since the browser might pass the work directly to an OpenGL-friendly GPU. We should benchmark some image and text fading and weight the implementation cost.

Create the mechanism for browsing content: a tabular view by default that shows thumbnails and basic details, and a zoomed-in view that fills most of the screen with the content and also includes controls relevant to the current view (for example, moderation of content).

We will plan to use this system for browsing content, moderation, and possibly screen lists/viewing.

We may want to use some spiffy CSS3 transitions to navigate the Browse Content views (for example, some kind of swipe or slide for navigating from one feed grid view to another or a zoom-in animation for when the user goes to look at a particular piece of content).

Investigate the incorporation of such animations for feasibility and consider implementing them (this is a nice-to-have).