Slideshow Service via nbviewer

[damianavila]

Ok, this issue is mainly to discuss how we will deal with a service such as nbviewer2, but for reveal-based slideshow...

Some time ago with @Carreau and @ellisonbg we discuss a little bit about that...

Now, that we have nbviewer2 going strong, I came up to discuss about this issue... before implementing some things ;-)

What do you think about that? I would be easy to add a button (and the functionality to render...) for slideshows in the current nbviewer2, but maybe we want to keep it isolate, just nbviewer2, and get another domain with a twin "slideviewer".

Cheers.

Damián.

[minrk]

I would think it belongs in nbviewer, just under a different url, e.g.

http://nbviewer.ipython.org/slideshow/url/etc.

[ellisonbg]

I agree with Min - it doesn't make sense to have different domains for each output type. URLs are great for that

On Sun, Mar 10, 2013 at 3:52 PM, Min RK notifications@github.com wrote:

I would think it belongs in nbviewer, just under a different url, e.g.

http://nbviewer.ipython.org/slideshow/url/etc.

— Reply to this email directly or view it on GitHubhttps://github.com/ipython/nbviewer/issues/52#issuecomment-14691320 .

Brian E. Granger Cal Poly State University, San Luis Obispo bgranger@calpoly.edu and ellisonbg@gmail.com

[damianavila]

OK, I agree with you...I will do some experiments with the current nbviewer2 and maybe I can come up with a preliminary PR ;-)

Damián.

[Carreau]

I just want to point at that spreading across multiple domain would allow to use more free dynos and addons. And with the current rate ar which nbconvert is growing and the number of request/sec it can handle, scaling will be all but cheap.

Add to that the fact that you might want to add "download as md/rst/tex..."

I know that we have money from the grant, but it is not unlimited. Le 11 mars 2013 00:24, "Damián Avila" notifications@github.com a écrit :

OK, I agree with you...I will do some experiments with the current nbviewer2 and maybe I can come up with a preliminary PR ;-)

Damián.

— Reply to this email directly or view it on GitHubhttps://github.com/ipython/nbviewer/issues/52#issuecomment-14691898 .

[damianavila]

El 11/03/13 03:52, Matthias Bussonnier escribió:

I just want to point at that spreading across multiple domain would allow to use more free dynos and addons. And with the current rate ar which nbconvert is growing and the number of request/sec it can handle, scaling will be all but cheap.

Add to that the fact that you might want to add "download as md/rst/tex..."

I know that we have money from the grant, but it is not unlimited. Le 11 mars 2013 00:24, "Damián Avila" notifications@github.com a écrit : —

Reply to this email directly or view it on GitHub https://github.com/ipython/nbviewer/issues/52#issuecomment-14699692.

You also are right! I have forgotten the details about dynos and addons. And if we later want to add another formats... mmm... As a plus, with multiple domains would be easier to maintain each one... and make it more independent from the other, because each converter has their own specificities and needs. Now I am more in the other side of the "force"... What do you think?

[Carreau]

I would like to have time to look at blueprints that might help. Let's try to focus on merging jinja templates and nbviewer2 then move toward slideshow mode/ other converter in general.

I would also like to try a pure tornado version which would have the big advantage of beeing asynchronous and not wait on every external request that the json is fetched before processing next request.

I know you don't have acces to statistics, but we are around 2500 page view/day, so in average we are at third to half what current nbviewer can hold, so it definitively can't sustain peeks.

[damianavila]

OK, coming back here...

We have nbconvert2 working strong in the new nbviewer... and I also know that nbconvert2 is currrently in a big rewritten procedure (and I pretend to help with this in any task I can), but I would like go forward in the implementation of a kind of "slideviewer" using reveal-based slideshows...

I will be at SciPy 2013 in Texas with two talks ( I get the student sponsorship, so I will be there all the week! ;-) I hope we can meet you there again!):

1) reveal-based slideshows: https://conference.scipy.org/scipy2013/presentation_detail.php?id=130

2) vIPer: https://conference.scipy.org/scipy2013/presentation_detail.php?id=168

and I would like to have a site like "slideviewer" functional for those days...

I can build an unofficial "slideviewer", but I would like to have it under the IPython "umbrella".

What do you think about that? Any feedback will be appreciate!

Cheers,

PS: Adding @fperez and @jdfreder to the discussion...

[damianavila]

Any thoughts here? I know you are busy, just a yes, no, maybe or "don't bother me" would be right... he he... joke aside, any feedback would be great!

Cheers.

[Carreau]

Oh, sorry for the delay. Totally forgot.

I would say that if you have it working and hosted somewhere we can just have a subdomain pointing on it.

I would not mind if this was part of the main codebase, and was just a config option. I guess it would mainly be a question of template, and profile on nbconvert.

If I had to implement it, I would wait for nbconvert to be merged into IPython itself.

[damianavila]

I would like to have a functional site in the following weeks... maybe a subdomain would be great... The idea is to give the same functionality of nbviewer, so we can update it later when nbviewer changes to incorporate the new nbconvert as a base system...

[rgbkrk]

@damianavila Any status on this? I feel like most people use nbconvert to create their reveal.js powered slideshows (thanks to you+team), or add some CSS to their notebooks. What do you think now?

[Carreau]

I think we would need a general way of using many converter through nbconvert. I would love an autodetection of the language metadata field that is able to send the notebook to the right converter.

[damianavila]

Regarding the issue, I have working on this with the new tornado nbviewer infrastructure, but I have problem when I try to deploy it to heroku... I follow the step in the readme but without too much success. Do you have a new recipe to make the deploy, because I want to test it live before making the PR...

BTW, my solution is not general, it is slideshow specific, a clone of nbviewer suited for reveal.js... but it can be a beginning after we achieve something more general...

[rgbkrk]

We're about to flip this on its head, letting users make a PR that we then can deploy automatically (after being manually off by a member of the team).

As for recipe, currently everything is deployed via these salt states. I haven't worked with the heroku setup in a while.

What would be easiest for people to deploy with? Honestly, I could make a vagrantfile that pulls straight from those same salt states to deploy whatever fork (local or remote) of nbviewer you want. Would that be overkill or would it be useful?

[damianavila]

What would be easiest for people to deploy with? Honestly, I could make a vagrantfile that pulls straight from those same salt states to deploy whatever fork (local or remote) of nbviewer you want. Would that be overkill or would it be useful?

If I have a way to look a deployed version of my branch, it does not matter to me if it is heroku or something else... I just need a deployed version to begin with the debugging steps, to check if everything work as I expect...

[damianavila]

OK, I have a working and nice version of IPython Slides Viewer... you can see it in action here: http://www.youtube.com/watch?v=K3tLBgNxMus

The question is what we do next...

I submitted a WIP PR #150 you can test here (in fact, it is a fully functional version, ready to deploy after some changes in the index)

The implementation is simple, I added reveal.js inside static folder and modified the app.py to call the SlideExporter instead of the HTMLExporter. Also, I have change the notebook.tpl to render the slideshow structure (as the reveal_slide.tpl inside nbconvert).

So, I see two options from here:

• Integrate the changes in nbviewer and have some sort of config file to call the proper exporter and templates (or other way to config the app: open to suggestions).
• Keep nbviewer and slidesviewer separated... in two synchronized branch (with synchronize, I mean rebased vs the nbviewer master to keep it update) and with separated domains.

I saw pros and cons with both possibilities, so I would like to know your opinions.

[ruffsl]

@damianavila, great demo by the way!

Just wanted to ask how you think the options of the default theme or color or font could be specified by the notebook author? It looked like they were currently changed afterwards within the URL.

Would that involve more meta data option drop downs during authoring the notebook? Or could one imbed more detailed reveal.js inductions inside a hidden cell. Could this be customized to allow for changing background colors or transition types in mid-presentation like that in the demo slides for reveal.js?

This really is a neat direction to extend research to shared coding, to publication, all the way to presentation.

Thanks for your work.

[damianavila]

@ruffsl Thanks!

Just wanted to ask how you think the options of the default theme or color or font could be specified by the notebook author? It looked like they were currently changed afterwards within the URL.

Yes, you can change themes and transitions (and other properties) querying the url, as with the "typical" reveal demo slideshow.

Would that involve more meta data option drop downs during authoring the notebook? Or could one imbed more detailed reveal.js inductions inside a hidden cell. Could this be customized to allow for changing background colors or transition types in mid-presentation like that in the demo slides for reveal.js?

There are a lot of possibilities... probably using additional metadata we can change a lot of things... and probably we will develop a way to let the author changes these properties. The notebook currently support metadata at the cell level, but also at the notebook level, so we have places where to add useful information. Just we need to develop the proper infrastructure inside nbviewer (and by extension, inside slideviewer) to read this additional info...

This really is a neat direction to extend research to shared coding, to publication, all the way to presentation.

I think in the same direction... presenting your data is probably the final step of your research... and if we can provide a tool to make this step better, we are on the right path.

Thanks for your work.

Thanks for your comments!

[bollwyvl]

Took a stab at implementing /slides/ today: https://github.com/bollwyvl/nbviewer/tree/slides

The changes are really quite minimal. I think going to named groups would be a little more consistent, but this seems to work... i ran out of API hits before taking a screenshot, but it seemed pretty good for the example I found: https://github.com/damianavila/vIPer/blob/master/IPython-powered_Slideshow_Reveal-ed.ipynb

Hopefully not too far away from being able to make this happen!

[damianavila]

Hey @bollwyvl, nice! thanks for took an stab on this!! Can you make it official, I mean... make a PR so we can start discussing on it...

Thank you very much!!

[mlovci]

Hi @bollwyvl and @damianavila ... this is very timely, I hope that these updates fix latex rendering issues soon (before Tuesday :smile:) so I can use the slideviewer to distribute slides for a talk I'm preparing.

[bollwyvl]

@damianavila: created #359! @mlovci: I don't know when this would land, you might want to have another plan for Tuesday!

[mlovci]

ok. Thanks!

[damianavila]

yep, this could take some days... so please use nbconvert to make your slides as a backup option...

[bollwyvl]

Fixed with #390.