I'm looking for any and all thoughts, concerns, and feedback on a number of plans for this project.
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.
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.
These ideas are in no particular order.
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...
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.
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.
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.
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.
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???).
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:
I'd like to change a deck in the same state to...
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.
Probably more work than all of the above changes combined...
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.
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
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.
@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.
@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.
@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.
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), ...
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:
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.
@twitwi For the points not in the etherpad:
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.
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.
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.
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.
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.
@twitwi Correct that $.browser was removed and good riddance.
1.0 is released.
Cool! Good job.
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.
@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.
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?
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:
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.