anaconda / nbpresent

next generation slides for Jupyter Notebooks
BSD 3-Clause "New" or "Revised" License
162 stars 23 forks source link

Themes #34

Closed bollwyvl closed 8 years ago

bollwyvl commented 8 years ago

This is more of a placeholder/discussion than an actual issue.

Lessons Learned

revealjs themes are not customizable enough unless the user is a CSS/SCSS/HTML/JS ninja.

The nbpresent theming UX will need to be basically an in-browser design suite with access to fonts, colors and metrics all stored in metadata, scaling from "style all h1, h2, h3 with Lato" to "the font size should be increased until an optimal reading width of 45-75 characters is acheived for this block".

Theme Composability

"A Theme" is probably composed of a number of design rules (themelets? effects?) that apply to different regions. At the deck, slide or region level, the active rules can be enabled. disabled, tweaked or reordered.

Theme Reversability

When switching between notebook editing (i.e. working) and slide designing and presenting, the slide themes must not "leak" into the normal authoring experience. For css, this means we can't just dump the whole css, a la reveal.

Deck Theming

A presentation will have one or more base themes that all slides and regions inherit. Thus, you can set the "title font" and have all titles get that styling. Among the only things that would be only at the deck level would be, if desirable, the "remote" that lets you switch cells, etc. Moving this to, say, an SVG would be nice.

Slide Theming

Separate from the deck, each slide should be able to specify its own theme, defaulting to the deck theme. Among the things here would be backgrounds and gross transitions a la reveal/ppt.

Region Theming

The things that actually get colors, fonts, etc. These might also have per-state-change transitions.

Theme vs Layout

There will be an interplay between themes and layout: the size of a piece of text may drive how large it appears in the layout. This might have to wait until we have a layout solver (i.e. kiwijs) but there are probably some simple things that can be done. Typography should drive this interplay, which will be expensive to calculate, probably, but absolutely critical to actually building better presentations.

Shipped vs Standalone Theme

We will want to ship/maintain a very limited number of themes (like 2) so that there is something to look at. Beyond the "unthemed" default (inheriting the notebook theme), probably a "dark" theme, and a "boring" theme. While limited and boring, they will set the stage for additional themes, establishing the metadata conventions so that users don't have to rearchitect their content when they change their themes.

Standalone themes would (at first) probably by other python modules that we can discover, but eventually would be npm modules.

Cross-Theme Consistency

When switching between two themes (or selecting them to start with), there should be good correspondence. Doing this with good URIs, with useful descriptions will help.

bollwyvl commented 8 years ago

Released as v1.0.0 after merging #41!