trms / cablecast-public-site Goto Github PK

This would allow you to turn off different show stub properties with CSS. Right now you can only turn them all off, because there is no other way to target them.

If you do a search and then go to page 2 and do another search, you'll still be on page 2.

Facebook and Twitter set the x-frame header that prevents their sites from loading in an iframe. This means that if someone embeds this site in an iframe, the twitter and facebook links will not work.

See: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options for more info.

We can probably work around this by adding target=_blank to the twitter / facbook links in the footer to make them open in a new tab.

We've received some feedback that the initial load of the site is too slow. This is expected since we never got around to profiling / optimizing for performance before the 6.0 release. Additionally most of our testing was done against internal servers where internet latency isn't really a factor. Plus our usual DB, tighty.tv is pretty small, and therefore fast.

I did a bit of profiling and a some investigating and have some ideas on how we can make the site feel faster, probably much faster. The TLDR of some things we do is below followed my more details.

• Serve index file with colors CSS already defined
• Provide skeleton UI in index and hide on ember app boot
• Coalesce thumbnail requests
• Don't block initial render on search requests

Serve index file with colors CSS already defined

We currently block the application's first render on waiting for the custom css to load. This is because if we render first, the user will get a weird flash of the default color scheme. The best way around this is to change how the pages are served, and place a style tag with the colors css in the served html. This would allow the colors css to apply to the skeleton UI I'm proposing below.

Provide skeleton UI in index and hide on ember app boot

This is just a good practice that we forgot todo. We basically don't show anything while the JS downloads since we are a js app :) What we could do is provide a minimal layout with an SVG loading spinner or something to at least provide an initial UI. Then when the JS has processed we can hide this UI and render the full site.

Coalesce thumbnail requests

We are currently doing individual api request to get the thumbnail records. On the main site this can be 50 requests between the gallery and the slide show. This was just an oversight that was fixed in the API in 6.0.2. We just need to take advantage of it by using thumbnail when requesting the show records.

Don't block render on search requests

Currently the we block on loading basically all the data for the main page in the application route in order to load the saved searches. We also do the same thing for the search page. We should instead not return promises from the model hooks and just use the promise properties to render loading indicators where the gallery / slide show / search results go. This would allow us to render much more quickly, and give some feedback that we are waiting on API data.

https://getsatisfaction.com/trms/topics/how-to-get-comments-category-producer-and-project-information-to-show-in-new-vod

The show-stubs display most of the data referenced above, not sure why it didn't make it to the show-details screen.

This would require an api change, but is additive, so can be done in a maintenance release... Basically the /shows endpoint should take a channels array so it can filter by shows that appear on a channel for example: /shows?channel=2 would only return shows that aired on channel 2.

This is tricky though because do customers want to be able to allow searching for shows that haven't aired.

If you have a lower-third graphic in the thumbnail, the show's title text overruns it in the Slideshow and makes it impossible to read either one.