> I actually find presentations like this to be an easier way of obtaining information than long blog posts.
I have little issue with presentations in and of themselves, although generally speaking either the presentation is missing most of the relevant information or it's just a more annoying format for a blog post.
I do have an issue with reveal.js which is the epitome of "style over substance" presentations full of pointless rotations and intractable multi-dimensional navigations, and with overuse of image macros which are the lowest common denominator of the modern web and the most information-free way to waste time and bandwidth.
> "WHO WROTE THE 'DEATH NOTE' SCRIPT?" released on HN earlier this week was very interesting but I kept losing my place down the page.
A bigger difference is that this piece happens to have actual content. And dense one at that. It's not trivial to read let alone skim.
I agree with you. Do you think presentations like this have any place, perhaps more to large groups of people at HN London rather than a singular user?
Oh yes, the format is OK as a support for a talk (although this one precisely has way too much text crammed in some of the slides), and of course the navigation is not an issue when the creator is the one showing the deck.
I also think presentations could work better as a single-consumer format if "presentation notes" were available alongside, expanding on the slide itself with what the presenter would usually talk about. Essentially a slide becomes a "hook", a header for a page of content. And the presentation itself becomes a sectioned/paginated post. But I don't know any presentation site which provides a good interface for that (I don't believe speakerdeck does anyway).
Interesting, I think you could take that further for group presentations. Say when you are actually in a presentation - the 'presentation notes' are sent in real-time to mobile devices.
Could you explain further as to what the interface would be like? If the presentation is full screen, where would the notes be? Somewhere off-page that you could pull in if needed?
> Interesting, I think you could take that further for group presentations. Say when you are actually in a presentation - the 'presentation notes' are sent in real-time to mobile devices.
That's a pretty interesting idea, and it could help e.g. non-native or disabled audience follow the talk.
If the on-device UI is done well-enough, it could also help with the usual "ask questions at the end" format: tap the text and jot down a quick reminder, and at the end of the presentation the things you tapped can be displayed for review or questioning.
> If the presentation is full screen, where would the notes be? Somewhere off-page that you could pull in if needed?
Sure, but I think it'd work better if the interface was closer to "presenter view", with the slides taking only part of the screen (say half) and the notes/accompanying text taking the rest. Then you could have something similar to e.g. Reeder/Mac's interface, using the spacebar to read "the next thing", either scrolling down the text (if not all of it can be displayed) or switching to the next slide (if the text is under a page or its end has been reached)
I don't really know why everybody is crazy about Backbone, when Qooxdoo (http://qooxdoo.org/) it's a lot better than it. You don't even have to know/touch html/css. You also have an automated generated page (that contains all of your js files or 1 big file if is min), OOP classes 'like' in Java, and full UI library.
Well, why in the world you would want to do the same thing 2 or more and to check in every single browser to know it's pixel perfect? This is the HTM+CSS way. In Qooxdoo, it's pixel perfect in every browser, that's the difference. If you make a view for a component with HTML+CSS you should take care of each browser.
Ps. I really think it's a bad idea coupling your client side to the server side. Imagine you want to go to node.js someday..?
There are a lot of different ways to do Javascript and people are very opinionated. Not every client-rich website is a single page app, and the types of operations from familiar CRUD manipulation to complex workflows. In the wild people often have existing code bases.
Backbone serves all these interests by providing only a very minimal framework for model/view binding. How you structure the app and what supporting libraries you use are completely up to you. It also makes it very easy to port existing code into Backbone which is quite a strong evolutionary trait for a javascript framework these days.
Long term I think Backbone will lose the popularity contest to richer solutions, but similar to HTTP and the web itself, sometimes less is more.
Are you seriously suggesting wikipedia becomes a single page app?
No really, I realize you say that server refreshes work for wikipedia, but you really seem to be suggesting that all websites should be single page apps.
I'm with you on this. mv* Javascript frameworks just don't make a lot of sense on a primarily "document" (and I use that term loosely) based site, like Wikipedia. Things like backbone have their place, but it isn't on every site every made.
26 comments
[ 3.0 ms ] story [ 77.2 ms ] threadwell, technically PP wasn't used here, but the unnecessary transition effect makes me feel like it was.
Welcome to PP 2.0, browserdeath edition.
"WHO WROTE THE 'DEATH NOTE' SCRIPT?" released on HN earlier this week was very interesting but I kept losing my place down the page.
http://www.gwern.net/Death%20Note%20script
I have little issue with presentations in and of themselves, although generally speaking either the presentation is missing most of the relevant information or it's just a more annoying format for a blog post.
I do have an issue with reveal.js which is the epitome of "style over substance" presentations full of pointless rotations and intractable multi-dimensional navigations, and with overuse of image macros which are the lowest common denominator of the modern web and the most information-free way to waste time and bandwidth.
> "WHO WROTE THE 'DEATH NOTE' SCRIPT?" released on HN earlier this week was very interesting but I kept losing my place down the page.
A bigger difference is that this piece happens to have actual content. And dense one at that. It's not trivial to read let alone skim.
I also think presentations could work better as a single-consumer format if "presentation notes" were available alongside, expanding on the slide itself with what the presenter would usually talk about. Essentially a slide becomes a "hook", a header for a page of content. And the presentation itself becomes a sectioned/paginated post. But I don't know any presentation site which provides a good interface for that (I don't believe speakerdeck does anyway).
Could you explain further as to what the interface would be like? If the presentation is full screen, where would the notes be? Somewhere off-page that you could pull in if needed?
That's a pretty interesting idea, and it could help e.g. non-native or disabled audience follow the talk.
If the on-device UI is done well-enough, it could also help with the usual "ask questions at the end" format: tap the text and jot down a quick reminder, and at the end of the presentation the things you tapped can be displayed for review or questioning.
> If the presentation is full screen, where would the notes be? Somewhere off-page that you could pull in if needed?
Sure, but I think it'd work better if the interface was closer to "presenter view", with the slides taking only part of the screen (say half) and the notes/accompanying text taking the rest. Then you could have something similar to e.g. Reeder/Mac's interface, using the spacebar to read "the next thing", either scrolling down the text (if not all of it can be displayed) or switching to the next slide (if the text is under a page or its end has been reached)
I don't need a long blog post, but my eyes can jump from paragraph to paragraph much faster than (apparently reveal.js's?) slidey animation thing.
me too. I had to close my eyes for the spin after a few times.
Most people here know and prefer html/css to magic.
> You also have an automated generated page (that contains all of your js files or 1 big file if is min)
Easy with Rails. A lot of backbone apps are running on rails.
Ps. I really think it's a bad idea coupling your client side to the server side. Imagine you want to go to node.js someday..?
Backbone serves all these interests by providing only a very minimal framework for model/view binding. How you structure the app and what supporting libraries you use are completely up to you. It also makes it very easy to port existing code into Backbone which is quite a strong evolutionary trait for a javascript framework these days.
Long term I think Backbone will lose the popularity contest to richer solutions, but similar to HTTP and the web itself, sometimes less is more.
No really, I realize you say that server refreshes work for wikipedia, but you really seem to be suggesting that all websites should be single page apps.