A Roadmap Discussion

[imakewebthings]

I'm looking for any and all thoughts, concerns, and feedback on a number of plans for this project.

1.0

SemVer

The deck.js project currently does not use semantic versioning. There is only a "stable" branch, and "master" serves as an integration branch where I can live with changes for a while before merging into stable. When I initially released it, this was just something I decided to punt on until it became necessary. When the project grew to a point that it made sense, I turned it into an experiment. How long could this thing go until versioning became an issue? I haven't fielded a complaint about it in those two years.

But as you'll see below, going forward without a versioning scheme would be a problem. The only reason it's worked until now is relative stability of the API from Day 1. I want to make some breaking changes to the current API. Before that happens, there needs to be a version to break from. So the first order of business will be to release the 1.0.0 version of deck.js.

Fix (Some) Open Issues

I've created a 1.0 milestone in the issue tracker. It's bug fixes, little style tweaks, documentation improvements, @flavorjones's SCSS improvements, etc. There is only one issue that is technically an API addition, but I don't think the changes it introduces will effect any 3rd-party deck extensions.

1.x, 2.x, beyond

These ideas are in no particular order.

Extensions

I believe extensions could benefit from a little more structure in how they're integrated with deck core. My instincts say that this change can be made without breaking backwards compatability, but I'm 100% willing to break it if needed. I want to expand extend to take an object. The properties of this object would look something like this...

• name: Required. A string to identify this extension.
• methods: Optional. A hash containing new methods. The equivalent of using the current extend.
• options: Optional. A hash of options to add to the deck options object. Extension options will live in their own namespace, but if there are multiple extensions with the same option the user can use an "all" option during init to pass those options to all extensions. If a user wants to disable an included extension, they can pass "false" to the namespace of that extension on init.
• events: Optional. A hash of callbacks for deck events.
• keys: Optional. A hash where keys are the keyboard keys (using something like keymaster and values are an object that says what method to call and a brief description of what that method does. The hope is that this will resolve key conflicts between extensions that we cannot deal with using the current each-extension-deals-with-its-own-key-binding approach. It also allows for API expansion to get a list of all the available key shortcuts. And this.

Here is a sample of what the goto extension might look like. I believe the current extend with a method name and function arguments could be deprecated but still used, and removed in a later major release.

Stop officially supporting integrated decks

By integrated decks I mean embedding the deck container into any arbitrary page. The CSS in particular jumps through some hoops to avoid stepping on any styles that may exist elsewhere on the page. It will be simpler all around to expect the deck to be the only thing on the page using a standard boilerplate. If users want to embed decks into a page, they would be encouraged to create them as a separate resource and embed them as an iframe.

Less jQuery plugin, More classes utilizing jQuery

I want to move away from $.deck(...) towards new Deck(...). This would be the first step of a few towards framework agnosticism using the adapter pattern.

Move some extensions into core, move other extensions to external projects

Hash needs to become part of core. It's integral to other extensions and I can't think of a downside to including it. This is already a ticket. This ARIA ticket should also be worked into core and the default extensions. I want to move menu and goto extensions out of the main project into external extensions. I feel they're less useful to the general public.

End support for "complex" slide configuration

When this thing was first created I conjured up some ridiculous use case for non-traditional slide configurations. You can see an example of this in the complex.html fixture in the test suite. Slides that are out of order, nested in reverse, elements that are more than one slide, etc. Nobody utilizes this flexibility and I don't blame them. It's not very useful.

Supporting only the typical heirarchical slide/subslide/step form of presentation may allow for simpler code and some useful API additions (getTopLevelSlides???).

Rework CSS states

Restricting to a normal heirarchy should allow for fewer slide state classes and applying them differently. Right now you may have a deck in the following state:

.slide.deck-before
.slide.deck-before.deck-child-current
  .slide.deck-before
  .slide.deck-previous
  .slide.deck-current
  .slide.deck-next
  .slide.deck-after
.slide.deck-after

I'd like to change a deck in the same state to...

.slide.deck-previous
.slide.deck-current
  .slide.deck-current
  .slide.deck-current
  .slide.deck-current
  .slide.deck-next
  .slide.deck-after
.slide.deck-next

This state application recognizes subslides as what they are, steps, and removes the necessity for the deck-child-current class. It would also allow this issue to be easily solved in core CSS without bolting on the deck.horizon gist/extension mentioned in the ticket.

New Correlated Projects

Probably more work than all of the above changes combined...

Extension Discovery (and more)

The wiki is cool and all, but I'd like to create a real project to track extensions/themes/related-projects and help people find them. Perhaps something in the same vein as Grunt and its plugin page? Perhaps these plugins and themes could be selected, built, and downloaded in a ready-to-go boilerplate zip for the user? If anyone has any suggestions for other useful functions this site could include, I'd love to hear them.

Component Toolkit

There's already a ticket open on this. I imagine this project being CSS only and containing mainly slide layout related styles. This vcenter class is the only one that exists in core so far but I'm excited to sit down and put thought into other layout patterns commonly used in presentations.

CC @infews @mikeharris100 @iros @cykod @barraq @nemec @flavorjones @twitwi

[nemec]

It all sounds pretty good to me. I like the idea of extension discovery, especially if we build upon an existing package management solution (like Grunt does with npm).

One thing that would be nice (but probably is not worth it) would be the ability to dynamically insert slides (sub-slides) during the presentation without re-initializing the entire deck. It may be possible with some voodoo, but at the moment my lazyload extension produces some ugly effects when it adds a new slide into the deck.

[imakewebthings]

@nemec Yes on both counts. I'm leaning toward the keyword-in-npm approach (with a blacklist in case of maliciousness) unless somebody can convince me of significant advantages to something else. And I originally in my outline of this stuff included a section titled "API additions" but figured that's always an ongoing discussion of any project. But I agree that an add method or at least something to update the slide list without going through the whole init process is a win.

This brings up something related. Such an API addition would make even more sense if the init is guaranteed to only run once. I'm all for making that guarantee even if the only gain is not having to call unbind before every bind. Because that's an abomination.

[twitwi]

@imakewebthings I won't be very available until next week but I don't want to slow down the discussion. What's your expected timeline for the discussion? Depending on that, I'll either put my comments quickly (and dirtily) or I'll spend some time thinking and describing it more.

[imakewebthings]

@twitwi I've already started on the 1.0 milestone issues, but I don't think there's any objection to that. They're all old tickets that should be fixed anyway. I don't expect to reach the new stuff until at least mid-November, so you have time to form your thoughts.

[twitwi]

Hi @imakewebthings, Hi all,

I love what I see here, (almost) every single point is very good to take in my opinion.

My only "objection" is with the "stop officially supporting integrated decks". I'm considering the use case of having a single slide deck in page (not multiple decks), but having embedded nicely (I think the iframe solution might be limiting in some cases). Also, I feel that the core CSS will end up cleaner if we don't suppose the deck is fullscreen. We can still provide a CSS that puts it fullscreen (or do it when the body is the container) (or do it when the container has also the full-screen class), ...

More follows.

[twitwi]

For 1.0, I found these changes that might possibly be interesting. Feel free to integrate them directly or to let me know if you want me to pull-request them:

• https://github.com/twitwi/deck.js/commits/master/extensions/hash
• https://github.com/twitwi/deck.js/commits/master/extensions/menu
• https://github.com/twitwi/deck.js/commits/master/extensions/status

[twitwi]

I imagine a "few" more things to discuss and the issue tracker is not convenient in my opinion.

I put my comments in an etherpad: http://piratepad.net/Kh3L2McaPk

I'd be grateful If anyone that is interested can have a look and put comments. Feel free to say "WAT?" if some points are unclear.

[imakewebthings]

@twitwi For the points not in the etherpad:

• I think the non-fullscreen support drop is a smaller change than my headline suggests, given that it takes up the same amount of space in the ticket as extension discovery. Actually most of it is taking place now in the 1.0 push. The majority of it is to stop scoping every selector inside of .deck-container, which made theme authoring and overrides annoyingly verbose. Currently in stable there's like a whole stripped down version of normalize.css inside .deck-container, because I didn't want to reset people's styles when they embed. Similarly .slide styles were .deck-container .slide to prevent stepping on any styles in say, a carousel on somebody's blog that used the same common class name. Currently that reset styling is being moved completely out of core.css and into each of the individual themes. I don't plan on adding styles that make assumptions that it is full screen. Just not going extra steps to sandbox all the styles in certain cases. Also, it's not like embedded decks "just work" right now as-is. The user already has to do stuff to get it to show, like set a height on the container or else they see nothing.
• I'm all for the hash and menu changes you made being pulled into 1.0. Especially the hash one, which takes care of the biggest source order bug and I don't know how that doesn't have a ticket. A couple pull requests would be welcome. 👍
• Could you explain what's going on with the status change? Thanks.

[twitwi]

Ok for the fullscreen thing.

About the change on status. My use case is a presentation where I have more slides after the main body of my presentation (slides to show in case of questions etc). Imagine I have 50 slides but my last real slide (the "thank you for your attention" slide) is slide number 35. I want to show the slide counter as n/35 (rather than n/50). And I don't want to update manually the "35" when I add slides.

[imakewebthings]

The 1.0 milestone is complete in master. The remaining three open issues are either issues with the gh-pages project page branch or require an update to the documentation there. I would love it if anyone in this thread could try out the master branch for a bit and let me know if any red flags come up. Thanks.

[twitwi]

Hi, I'll have a quick try with a presentation of mine. But I was not always using the core css and default themes so much so I'm not the best for backward compatibility tests.

[twitwi]

First "problem". I'm using jquerysvg which uses $.browser (http://api.jquery.com/jQuery.browser/) which got remove in jquery 1.9. I will have to patch jquerysvg as the author is not so active if I remember well.

[twitwi]

All seems to be fine with my presentations. I'd even say that the default theme is properly less-intrusive as I could switch my core.css with the new one with almost no changes (with the old one, it would have made it ugly).
Thanks for the new version, I'll try to merge it as soon as I get jquerysvg fixed.

[imakewebthings]

@twitwi Correct that $.browser was removed and good riddance.

[imakewebthings]

1.0 is released.

[twitwi]

Cool! Good job.

[imakewebthings]

Now that 1.0 is released I'm going to close this in favor of a pile of new tickets I created for each of these items.

#146, #147, #148, #149, #150, #151, #152, #153, #154

Milestones for 1.1 and 2.0 have been created as well.

[barraq]

@imakewebthings i've been quite busy lately but I followed the discussion the best as I could.

I guess the discussion is now going on at http://piratepad.net/Kh3L2McaPk right? If yes i'll put some remarks there.

Regarding deck.js, I started an opensource project with @moy and students from Ensimag (an engineering school from Grenoble where @twitwi used to teach and where @moy and I still teach) that aims to provide a nice editor for creating screencast. The editor is written in pure javascript and is embedded as a cross plateforme native app with JavaFx2 webview. While the first year was about proof of concept and only focused on screencasting I believe that the app can also be improved to, more generally, support the generation of deck.js presentations. This year then we are going to make some improvement to the app and switch to deck.js as the core engine for rendering the screencast (and hope extend it to render html5 presentation). For that nevertheless we are going to rely on extensions outside the ones from the core: most of them will be the exts that @twitwi and I developed.

First of all what do you think about having such an editor? Did you ever thought about it? If yes do you have any ideas, thought to share? Regarding the extensions developed by the community did you decide how to handle them? Will there be some kind of tool to fetch the extensions? Regarding this point, I'm a user of Homebrew https://github.com/mxcl/homebrew and they are using git as "extensions" manager and management. Could this be an approach for handling deck.js extension to?

Best,
Rémi

[imakewebthings]

I guess the discussion is now going on at http://piratepad.net/Kh3L2McaPk right? If yes i'll put some remarks there.

Those are a whole bunch of points of discussion brought up by @twitwi that have been talked through and some of them worked into the roadmap. You could comment there but I have stopped reading it.

For extensions, I mentioned here that something similar to Grunt would make sense. Let me elaborate a little bit on how that works in practice and how it differs from the way Homebrew handles their formulas.

An extension author would have their own self-maintained repository. This repo would be published to npm with a certain tag (let's say "deck-extension" because that's what it will be.) The package.json file will also contain some metadata to indicate which file is the theme CSS.

Brew formulas are a bit different in that they are all kept in the main homebrew repo.

The extension discovery site that is #154 will operate much like Grunt's plugin search. It looks for npm modules with the deck-extension tag and lets you search for them. Where I would like to get a bit crazier is to also let a user from this search page:

• Add the extension to a "build list".
• Preview all their build list extensions in realtime on the page with a sample deck.
• Download a built zip with their extension list + core to be used as a boilerplate. JS/CSS would be optimized at this point as well.

As for a deck authoring tool, I'd have to be crazy to have never thought about it. I briefly started developing one. I believe I stopped because I have no personal interest in it. It feels like a tremendous amount of effort where the end goal is to be half as good as a too like Keynote, PPT, Impress, et al. It's only my opinion, but I think folks who want a visual editor are best served by these tools. slide.es easily has the best evidence against me - it's not that you can't make a good visual editor - I just have no desire to write it.

That said, I'm very interested in making a good build target for a visual editor. As I see it most of the visual editor problems to be solved don't have much to do with the presentation software underneath it, they're their own problems, but I wouldn't want to do anything to get in the way. So if you ever do go down that path and run into situations where the framework gets in the way I'd love for you to let me know. Issues like #151 should help in this regard.

Thanks for the response, @barraq. And you can absolutely keep talking here about this stuff, the issue is only closed because I've created the 1.1 and 2.0 milestones in GitHub and that was basically the end goal here.