Best way to do slide shows from a Web server?

by philg

http://philip.greenspun.com/images/tools/slide-shows-spec.txt is a spec for the software that I’d like to run on my personal site for doing slide shows.  The core of this requires either some JavaScript or DHTML programming.  I’m looking for advice from those readers experienced with these tools as to the best way of doing this and possibly for some good open-source starting points.


Thanks in advance.

27 thoughts on “Best way to do slide shows from a Web server?”

  2. To me this seems like a bit of a hack. My website now only has the JPEGs and an images.txt, as opposed to having .html or .tcl files for every image page. Even though the “html” pages end in .html, they are in fact generated by a registered proc on the /snaps/ url.

    Request /snaps/malta/9140710-fishing-boat.html and the script will look for images.txt in /snaps/malta, parse it for “9140710-fishing-boat” , grab the real filenames and caption and create the HTML. If the server would get any kind of load, this could easily be cached, obviously.

    Adding your slideshow functionality to this would be trivial.

    Maybe it’s time for a complete overhaul of your (decade?) old way of working?

  3. The fashionable answer would be an AJAX implementation like Google Maps, or you could simply have a generator churn out the necessary JavaScript for displayin all the images in a folder. Flickr seems to have some sort of nice Flash thingie for slideshows.

  5. Bas: Congrats on the server-side scripting and poking around in the file system. I’ve already got lots of code on my server that does that, though. It is the JavaScript and/or DHTML that I don’t know how to do and you don’t seem to make any use of those tools. You say that it is “obvious” and “trivial” to add the browser-side scripting but it would be nice to see an example for those of us who aren’t as clever as you….

  6. Wow, sorry to offend you Dr. Greenspun. I didn’t say it would be trivial to do it browser side either. What I meant to say is that it might be easier to do it without the hassle of client side code and move to an architecture where you could easily do the slideshow server side, with the only “client side” code being a Refresh header to the next slide.

    Even if you wanted nice things like sliding/fading images and seemles transitions for which you need DHTML, there should be no need to do something as ugly as digging the images out of an HTML file.

    Unless there is something I am missing about your spec, nothing reads “this needs to be all client side code”, in fact you hint at that you need server code to do it.

    So why not fix it at the core, rather than hack it in?

  7. You should probably state what you want this DHTML and JS to actualy do, because that really doesn’t seem to be in the spec, and I have gone over it several times.

    If you want it for the reasons I state above (ie: smooth transitions) then all you need is the most basic javascript to, after intervals, dynamicaly change the src of the main image (and maybe pre-load it) and update a couple of text fields (‘div id=”caption”‘) in the DOM.

    A quick google on “dhtml tutorial” and “javascript tutorial” will find you that, and many a tree has lost it’s live to print endless streams of books about this, so those are easy to find too.

    I don’t think you need any available open source tools, unless you all of a sudden want to go for a incredibly fancy looking interface. Hey, there’s a first time for everything! 🙂

  8. Bas: I want the browser to render a “next” button and, when that is pushed, request the next JPEG in the sequence from the server and display it to the reader once it has been completely received from the server. It might be nice to have an “run automatically” button that would show the JPEGs in a sequence, changing them every 5 seconds. I don’t care that much about smooth transitions, though it would be nice to spare the readers seeing half-loaded JPEGs. My main goal is not going back to the server over and over to compute the same info (i.e., which JPEGs should be displayed and in what sequence).

    I do want an open-source skeleton for the Javascript! If I wanted to learn a new computer language and have fun programming, as you seem to suggest, I would pick Haskell and not Javascript.

  9. Phil: do you have any updated thoughts on Lisp? Any hope for Paul Graham’s Arc, perhaps?

  10. Hmmm, that makes it even easier. To be honest, I think that you may need to learn JS anyway to customize any framework to your specific needs, I doubt there is anything that generic out there (Still waiting for “Visual GXR” (Google XML-RPC)) or you’ll have to extract it from some other photo gallery software.

    To not have the half loaded images, there is the good old “pre-load” functionality, as loved by the image-roll-over crowd.

    If you are already a programmer (which we all know you are) JS is really dead easy, there is not much to learn. If you have a spare sunday, I think you can easily knock it up from scratch faster than integrating something existing…

    Or get one of your students to do it. If you want to make the HTML extraction generic, you are looking at a fair bit of AI to decide wether an image is part of the slideshow or not and what the caption is, or at least have to create an interface where you can teach the program by pointing and clicking at parts of a generated page. Could make for an interesting project.

  11. Trevis: No hopes for Arc, though Paul is a nice guy, unless someone writes a ground-breaking must-have open-source application in Arc that others want to modify. Lisp is more tasteful than C or Java but not that dramatic a help unless the programmer is very smart and tasteful him or herself. The average programmer seems to be getting progressively less devoted to taste and quality and therefore I would think that Lisp will continue to dwell in obscurity as things like PHP ascend to popularity. My prediction is that management will get tired of paying for the mistakes of their programmers and devote more attention to static analysis of C and Java code. So that’s my vision of the future: dumber, lower-paid programmers, crummy bug-prone computer languages that don’t allow high-level specification, and really fancy compilers that find the memory leaks and security holes before runtime.

    Bas: I’ll have a “spare Sunday” to devote to writing a Javascript that probably already exists out there as soon as all of my friends and family are dead, New England runs out of aviation fuel, my airplane is in the shop, and the flight school helicopters are all down for maintenance…

  12. Ha, yeah. But you still need that server-side code as well, which sounds like it will take even longer.

    But I know about those Sundays, it is why I am trying to move more and more to standard packages and live with their shortcommings; my photo pages are a bit of a relic of times past when this stuff was a) fun and b) a valuable learning experience. No more.

    Gallery probably does what you need after custom designing some templates (all of theirs are horrible) but it’s a PHP application, moving away from AOLserver.

    So I guess you’ll either have to move to a complete 3rd party package and don’t apply the new functionality to the existing pages, move old stuff to the new package or spend a load of time either coding or integration someone else’s code. (probably requiring lots of coding…)

    Such is life for maintainers of personal websites, I guess.

  13. AJAX – and a javascript timer trigger and/or form control (i.e., go back, go forward, go to specific slide #, etc…). Basically, you’ll use XMLHttpRequest – see an example here – http://azradio.net/XH.js or code library at http://xkr.us/code/javascript/XHConn/.

    At the heart, a JS statement like <tt>document.getElementById(did).innerHTML = xhr.responseText;</tt> where <tt>did</tt> is typically a DIV element.

    Of course you’d need server side scripting to bootload the slide show and want to make it parameter driven – lots of different possible design & implementation schemes, limited only by your imagination.

    The JS + DHTML + Server side scripting (be it Perl, PHP, or God forbid Java…) is a powerful arrangement that is finally allowing the web interface to approximate desktop interfaces – i.e., refreshing parts of the page dynamically or from a JS enabled HTML button (or butcon).

  14. I have no idea if this is cross platform, but it works on the Mac with both safari and firefox. I suspect it works in firefox/windows too but I’ve never tested it–I’m pretty sure it doesn’t work with IE.

    It works like this:
    Backend simply requests photo metadata from the DB and rather than spitting out HTML, spits out XML with a little directive specifying an XSLT document to be used by the browser. You can use whatever API tools you like to do this and use whatever XML format you like, although I’m partial to my own pheed extension for RSS ( http://www.pheed.com/pheed/ ) for describing photo metadata.

    A good modern browser like firefox will look at the XML and use the XSLT document to transform it into pretty HTML with some simple javascript to swap images and captions upon user actions. In the example the javascript is five lines, which is why I think Bas described it as trivial.

    The advantage to this is that it is simple and it clearly breaks the problem into a nice MVC architecture. If for some reason you want to change the backend, you don’t need to change the front–the only constant is the format of the XML. Since you are making the raw XML available it is easy for others to parse if they want to work with your photos in a different way. Also, if you prefer not to use XSLT to handle the interface/html you can build an ajax interface which manually parses the xml file and presents it to the browser. That’s a little more complicated and I don’t have a clean example, but if you were interested I could whip something up.

    Here is an example: http://www.pheed.com/examples/Pheed2XSL.xml
    the XSL document which the above file calls is located here for your perusal: http://www.pheed.com/examples/pheed_preview2.xsl

  15. Remember that JS will in practice require a bit of testing if your users are going to use different browsers due to browser bugs (it’s ironic that UI things done in the 70’s are implemented now in web documents using incredibly heavy solutions). But I hear that JS has a lambda statement. Do you actually know to program in Haskell? This could be done in Haskell, but with no prior experience it will take more than a Sunday… 🙂

  17. Auto-play in JS is simple as calling setInterval( function, timeintervalinms )…

    AJAX works with Safari, Mozilla, NS6+, IE (any modern browser), there is a different protocol but it’s typically buried in the details of the general function library you choose to reference (or cannibalize your own).

Comments are closed.