Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: Simplify workflow for presentation author #511

Closed
docwhat opened this issue Jun 26, 2013 · 12 comments
Closed

Idea: Simplify workflow for presentation author #511

docwhat opened this issue Jun 26, 2013 · 12 comments
Labels

Comments

@docwhat
Copy link

docwhat commented Jun 26, 2013

Currently, the workflow for a new slide deck is a bit of a pain:

  1. Clone the repo.
  2. Edit the index.html
    1. Set the author and description.
    2. Edit the configuration if desired.
    3. Remove all the demo slides.
    4. Reformat if you don't like the HTML indentation.
  3. Remove the .git directory.
  4. git init
  5. Commit your initial state.
  6. Start working on the slides.

Updating reveal.js on a slide deck you've already created is also a pain (because of above).

Ideally, the workflow would be something like:

  1. Install reveal.js (git clone? Or maybe curl http... | bash?)
  2. Run a command to create your new slide deck: reveal-js init myslides
    1. It asks for Author (or uses system values to get it)
    2. Asks for description
  3. cd myslides
  4. $EDITOR slides.html or $EDITOR slides.md

Optionally, the author might:

  • Edit config.js to change Author, Description, or the configuration.

The only files in the myslides directory should be the bare minimum to run the site dynamically. It doesn't have to be efficient to load! If they want efficiency then a static site should be generated.

  • slides.html or slides.md
  • config.js
  • index.html -- a bare template that loads everything else.

If the author wants to make the site static, e.g. for archiving or sharing, there should be a command to do this: reveal-js freeze static-directory-name

I posted this issue because I wasn't sure if it was something that should be reveal.js itself, or if it is something that should be external to reveal.js that consumes reveal.js.

If it is the latter, I might do it myself using ruby.

@tomByrer
Copy link
Contributor

Good idea; I was also hoping things would be easier. There are options:

  • online slid.es for people who don't want to mess around too much
  • use git to make new branches, & bash scripts to configure & package
  • just keep using the same reveal folder & make each .html filename unique
  • I would think a Yoman/Grunt plugin would help if you want to automate, but that also requires setup...

@docwhat
Copy link
Author

docwhat commented Aug 21, 2013

I've started something in docwhat/magic_reveal that helps. I'd love to chat about it.

@docwhat
Copy link
Author

docwhat commented Aug 22, 2013

To clarify, the presentation at http://docwhat.github.io/magic_reveal/ is generated with the ruby gem magic_reveal and https://github.com/docwhat/magic_reveal/blob/master/README.md

@hakimel
Copy link
Owner

hakimel commented Aug 25, 2013

I'm all for making the setup/update process easier. This looks like a good direction, there's also https://github.com/slara/generator-reveal which I haven't tried out yet.

I believe keeping this in a separate repo is the way to go but they should be covered in the readme to make it easier for people to discover.

@berteh
Copy link

berteh commented Sep 5, 2013

Hello. First of all thanks for reveal.js: it's great, nice looking and easy to use!

To me a good workflow includes using reveal as a submodule, not simply forking... and including this single instance of reveal.js as the engine for all the presentations you would create (with a global setting of some kind). (Thus a simple location to update).

I'd typicall suggest to those that want to use github to manage their own presentations to 1) create a new repository, 2) clone it, 3) add reveal.js as a submodule, 4) make a new "blank.html" from from Hakim's index.html with their favorite settings, name and 5) duplicate this template for each of their presentation into a standalone html presentation file.

in code-someting-like (for those wishing to store their own presentation in github)

git clone https://github.com/yourUser/presentationsStockName.git
cd presentationsStockName
git submodule add https://github.com/hakimel/reveal.js.git reveal.js
git submodule init
cp reveal.js/index.html blank.html
edit blank.html 

Put in blank.html your name, favorite settings, typical title, content and conclusion sections, and prepend "reveal.js/" to all "css/" "lib/" "js/" and "plugin/"

every once in a while update your reveal.js engine with a quick git submodule update

And for those who want a quick means to organize their thoughts into a reveal presentation there's the (brand new) option of http://berteh.github.io/mindslide/ that turns a freeplane/freemind mindmap into a reveal html presentation.
(disclaimer; I'm the author of this tool and welcome any comment/suggestion for its improvement)

@bartfeenstra
Copy link

As someone who comes from the PHP world (which has become incredibly strict and progressive over the past few years), I find the official authoring instructions counterproductive, as they require me to modify files that are not mine. I would ideally like to create a presentation as a new project, declare Reveal.js as a dependency, and import the necessary components myself while keeping the ability to update the dependencies (e.g. Reveal.js) regularly and easily.

Writing my own package.json works well, but not for the full install that requires authors to run grunt serve from the Reveal.js project root.

As to the index.html file, a good solution is usually to name these files example files, so index.html becomes index.example.html and it would have to be copied to index.html to work. As index.html is not in the Reveal.js repository, I can easily update the HTML page without modifying my dependencies. However, this only improves the basic installation. The full install needs a more thorough solution.

@anantshri
Copy link

I have attempted to solve a simmilar problem using my limited bash skills. a blog post highlighting what i have done is here http://blog.anantshri.info/automated_revealjs_setup and github repo of the same : https://github.com/anantshri/automated_revealjs/

Basically i am using external-markdown for presentation creation and keeping reveal.js seperately in filesystem and runtime linkage allows for smother workflow.

I am working on a more simpler version where pre cloning of script would also not be required and we can keep stuff much neater and cleaner.

@rparree
Copy link
Contributor

rparree commented Feb 3, 2015

Hi,

Just our approach to this:

  • Installed reveal as a bower package (left untouched)
  • using assemble.io to relief presentations from having the reveal
    boilerplate
  • generate presentations using gulp/assemble.io

I can't share that repo, but have isolated the solution and push it to:
https://github.com/edc4it/revealjs-assemble

@ashneo76
Copy link

ashneo76 commented Feb 7, 2015

Hi,

I have written a python tool that allows you to write the entire presentation as a YAML file. It converts that into the HTML file, just like in the template. All you need to do is drop the generated HTML file in the code checked out from this repo and use 'grunt serve'

YAML source: http://src.ashishshah.net/yaml_reveal
Website source: http://src.ashishshah.net/presentations

@ashneo76
Copy link

ashneo76 commented Feb 7, 2015

I also updated the Gruntfile.js to live reload any .htm file as well. I am working to automatically generate the HTML file when the yaml source changes.

@jonhoo
Copy link

jonhoo commented May 11, 2015

I find that I usually do the same as @berteh, namely "include" reveal as a submodule, and then link to it from an HTML file in the parent directory. The big drawback of this is that speak notes don't work as the Gruntfile expects the presentation to be in the same directory as reveal. My current solution is to

cp -r index.html reveal.js/index.html; cd reveal.js; grunt serve; cd ..

But this is not particularly satisfactory. The ability to grunt serve and pass it a path to the .html file would be much nicer.

@bnjmnt4n
Copy link
Collaborator

bnjmnt4n commented May 2, 2017

Thanks for all the info! I feel that this issue should be closed after 3 years of stagnation, as we want to keep the Reveal core lean, so we want to offload such code to other tools. Any useful tools should be added to this page to be shared with others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants