Screen JS - concerto/concerto GitHub Wiki

Essential Questions:

  • Should we support plugins made up of HTML, JS, and CSS as content types?

-- I think we'd need to flush out what we define as a plugin here, but if you're talking about different ways to format / render a piece of content my vote is yes. ~BAM

  • Will the screen frontend be part of the Rails app?

-- Since the frontend is mainly static HTML (the JS does all the heavy lifting) I don't see why not. The bulk of the traffic would be getting JSON from the frontend controller, and we can fix a scaling problem when we have one, We can also make the system appear to load faster if we integrate the frontend into the Rails app (I've got a few tricks up my sleeve now). ~BAM

  • If not, how will it access the JS and CSS assets that accompany the HTML it loads?

Related Questions:

  • Should we consider using WebGL?

-- I'd love to see someone test it, but I'm not volunteering yet. ~BAM

  1. What browser spec will be required / recommended to run the screen front end? If we standardize on some advanced browser like the latest Chrome, we could use fancy CSS3 animations, WebGL, and other smarmy, hoity-toity garbage.

-- My vote is with support for all "modern" browsers which includes recent Chrome, Firefox, Safari, and maybe Opera? The specific versions likely depend on what the hardware system uses, but I'd like to take advantage of HTML5 hoity-toity whenever possible, falling back to dumber techniques when needed. ~BAM

  1. Modular support for transitions? (Can plug-ins add new transition functionality: fades)

-- This ties nicely in with the above, we could probably improve the performance of the system on certain devices by using different transitions (CSS3 vs WebGL vs current stuff) and some low end devices may want to avoid fading all together. I've always wondered if wipes/slides would look smoother or not. ~BAM

##Types of JS interactivity on frontend:

  • Graphical transitions
  • Custom HTML5/JS/CSS animations
  • Group of text panels (interactive and non-interactive)
  • Touch-based UI elements:
  • Web View (iFrame-esque.....BUT NOT THOSE RUDDY iFRAMES) for Google Maps, anything else we might want to show
  • Hardware-based input (buttons, Kinect, etc)