Slideshow App

[johntynan]

Hi everyone!

In thinking about the specs for a slideshow app, I have a few
thoughts:

At minimum, a slideshow has a title of the slide, and the body text
(or image) for the slide. This is similar to a blog post (or a wiki
entry). Perhaps it would be good to build upon an existing pinax blog/
wiki application for the slides.

Additionally, if you have pinax, you will likely have docutils
installed as well. It could be possible to enlist reStructuredText
and rst2s5.py:

http://docutils.sourceforge.net/docs/user/slide-shows.html

in that it is a "Docutils front end that outputs HTML for use with S5"

This way, the requirements to make the slideshow would be one thing
(including python, django, docutils, pinax), but the requirements to
present it would be very low (the filesystem and a browser). You
never know what kind of resources that will be on hand at a meeting or
conference, so it would be good to go for a lowest common denominator
here.

Perhaps a script could be written to run through reStructuredText from
a series of blog posts or wiki entries and build an S5 slideshow.

Your thoughts?

JT

[Milan Andric]

Hey John,

I'm totally with you in finding a standards based
(javascript/html/css/) solution for slideshows. I'm sick of flash
slideshows that don't need the flash requirement. But maybe that's
just the web-zeolot speaking. Also the journalism world has a
slightly different definition of what a slideshow is. It always
involves audio. I haven't looked into S5 much but it needs to support
audio and possibly mixed media, which usually means flash.

I see our options like this:

1) just use flash, it works.
it works and is available in 90+% of browsers and makes our job easier.

2) use web standards when possible.
so use javascript when we don't need to use flash so the output is
lighter on the wire and more accessible and easier to develop.

3) give folks an option.
the rendered output has an option to view in "web standards mode" or
"flash mode" and the viewer can choose which works for them best or
the author can choose a default.

4) try to be intelligent.
their is a bit of javascript that does some browser sniffing and
displays either javascript mode or flash mode depending on a bunch of
variables.

So for a non-flash slideshow I would start with jquery. I see jquery's
adoption is quite high and it might be good to just integrate it with
the django-newsroom product just like flash. Though most of the web
dev world hates flash, it's a necessary evil at this point until web
standards can really compete with flash.

The other thing that comes to mind is finding a wysiwyg editor for
text in general. So any text area in our system will need to have a
toolbar for formatting. Normal people/most journalists just won't
accept a markdown/rst type solution for formatting text. We can save
rst or markdown in the db no problem. But I have learned that people
need a wysiwyg editor, even if it's very limited. So now there is a
slightly more involved question about what we want to save to the db
in the case of textarea fields? How do we want to markup our text for
formatting? These days I'm leaning to saving html in the db and
sanitizing it on the way in/out on the backend with an html library
like lxml or beautiful soup. HTML seems like the natural choice, and
I've heard good things about lxml lately.

So there's a couple more pieces to this problem and I'm not sure how S5 fits in.

--
Milan

[John Tynan]

Thanks Milan, I appreciate your mentioning the audio aspect of
slideshows, the different output options, and the need for a wysiwig
editor.

Here is a post that I noticed recently in passing but have yet to
explore more fully:
http://jannisleidel.com/2008/11/wysiwym-editor-widget-django-admin-interface/

In thinking about flash and audio, to get an inspiration for the kinds
of interfaces one might use for syncing up audio with slide
presentations, I remembered that shideshare.com allows you to
"slidecast" audio along with a powerpoint presentation.

Using the instructions here:

http://www.slideshare.net/faqs/slidecast#1g

I was able to match up audio to a recent presentation here:

http://www.slideshare.net/johntynan/npr-simile-timeline-presentation

Here is a screen capture of the "slidecast" interface:

http://www.flickr.com/photos/johntynan/3032282040/sizes/o/

Hope you find some inspiration in this as a way to sync audio and
video using flash.

In following up with your suggestion for jquery can be used to
synchronize audio. I found this resource which looks interesting:

http://malsup.com/jquery/cycle/

One additional thought, it's been awhile since I had worked with SMIL.
I'm not sure how compatible this is with today's browsers and
players.

--
http://johntynan.com
http://openid.johntynan.com/john

[shacker]

Since SlideShow Pro is the current standard-bearer in MM journalism,
it's important to look at all (or nearly all) of SSP's feature set and
be able to match it or improve it. That means whatever you build will
need to have :

- Great ease of use
- Audio track
- Adjustable durations for individual slides (w/graphical UI for this)
- Full-screen playback option
- Lower thirds titling
- Thumbnail creation and navigation
- Auto-image-sizing
- Pan and zoom (Ken Burns effects)
- Canvas colors
- Per-image captioning
- Slideshow credits
- Easy customization of template

If you don't provide all of that, users will probably just go around
whatever system you build and insert SSP slideshows anyway :(

[johntynan]

Scot, you make a good point in talking about user's behavior. It may
be useful to talk about the intended audience for this application as
well as the impetus for writing this app. Is this a need that the
knight foundation is looking to fill? What kinds of use cases can be
made for a slideshow app?

I could see if a person or group of people were already were blogging
and building stories around a specific topic as part of their daily
reporting, if there was an option to "assemble a slideshow" from
photos and text across multiple posts and authors, they could gain
some speed and convenience over what might be done in a dedicated,
desktop-based slidehow app.

[Milan Andric]

Thanks for this feature list Scot. Building a web version of SSP is
quite attainable. I can see a web app built using semantic html,
javascript, css and a python backend. It would be more accessible,
more feature-full and seamless from desktop to web experience. Also I
imagine an export feature that would create the same public_to_web.zip
file that SSP does. Overall, I don't see any real implementation
issues, just takes focus and determination to get it done right.

The implementation phases might be :

1) Write the base of the app, which is semantic html/css frontend with
python/django backend that is very accessible and can be used on
mobile. Not fancy but should run on almost anything.

2) Write the javascript features/UI components which are completely
optional/on by default if you have support.

3) Add flash slideshow player/component for full screen and other
things we can't do with javascript.

4) Feedback, iterate ... focus on the web app.

5) Port the web app to the desktop so one can download an executable
and run the app locally in a browser.

I also like the idea of defining a spec for the html, similar to S5.
http://meyerweb.com/eric/tools/s5/structure-min.html

So all of the frontends (javascript, flash, ...) would parse the html
that we standardize on. But it starts with defining the slideshow in
semantic html. We could use S5 and add some "extensions" to it, but I
like the idea of Journalism defining their own specs since Journalism
has separate goals/needs/purposes.

--
Milan

[Jeremy Rue]

I think the key is ease of use.

Sometimes I think we fall in the trap of focusing too much on the back-
end and all of the logistics to make it work, that we forget about the
end-user experience. I think it's best to work backwards. Start with
the finished product, then figure out what is required to build that
on the back-end.

If we are to truly create something that can serve the community and
become ubiquitous, it has to be absurdly easy to use. I'm talking drag-
and-drop.

I'm thinking:

1) A simple way to upload multiple images at once, either a folder of
images or by selecting multiple photos

2) Dragging the images into a proper order

3) Adding a soundtrack with a simple upload form

4) Specifying the transitions by stretching photos in a visual way

5) Adding a title/captions

Now, doing something like this in Flash is not too hard (except for
the multiple photo upload part -- that would be a server side thing),
but I agree on the Web standards idea. My thought would be to have a
Flash interface that creates the slidesshow, and it could output an
XML file with the photo order/transition times. Then using some custom
jQuery, we could parse it -- output a javascript slideshow. This would
also solve the mobile issue (flash doesn't run on many mobile devices
today)

Essentially, I guess we would be creating a Web version of
SlideshowPro/SoundSlides, and I think that is great. The more we can
integrate the publishing tools into the CMS, the easier and more rich
that user experience would be in my opinion. For a journalist to even
publish a SoundSlides project is a complete hassle. If they could do
it via a Web form, then you've won half the battle.

[Brad Flora]

Puts on evil publisher hat for a second:

The #1 reason I like slideshows is because they send pageviews through the roof.

Would this app generate a page refresh with each new image?  It sounds like it would not.

-Brad

[Jeremy Rue]

Good point. That can be done with AJAX so that the whole page wouldn't
have to refresh each time a new photo shows... only the ads and the
slideshow would update.

Space for advertisements should definitely be integrated as a part of
the package. And by confining it to a particular inconspicuous area,
we can avoid the pitfalls of these annoying floater ads that many
newspapers are naively using. (i.e. fresnobee.com roll over page peel)

Milan, here is how we could make the javascript/flash portion work:
http://weblogs.macromedia.com/flashjavascript/

On Nov 19, 2:59 pm, "Brad Flora" <bradfl...@gmail.com> wrote:
> Puts on evil publisher hat for a second:
>
> The #1 reason I like slideshows is because they send pageviews through the
> roof.
>
> Would this app generate a page refresh with each new image?  It sounds like
> it would not.
>
> -Brad
>

[John Tynan]

If Google Analytics is used to measure site traffic, the
_trackPageview function can track (flash and javascript) events that
do not generate a pageview:

http://www.google.com/support/analytics/bin/answer.py?answer=55597

[Brad Flora]

The question for me would be whether this app would make more more money than doing slideshows some other way.  Notwithstanding arguments about putting users first and so forth, every big name news organization and magazine relies on photo slideshows to make their web sites earn their keep.

My dream would be a free web app that let me create EW.com-style embeddable slideshows.

Like this: http://www.ew.com/ew/gallery/0,,20152943_20153287_20240558,00.html?iid=top25-20081119-10+breakout+stars+of+2008

I realize that's a bit different than the sort of slideshows you're talking about, but it's something I'd definitely use.  Wordpress has a plugin called NextGen gallery that's pretty close to this.  Drupal has nothing and it's a big problem.  A drop-in solution would be a godsend.

/evil publisher hat

-Brad

[Milan Andric]

On Wed, Nov 19, 2008 at 5:33 PM, Brad Flora <brad...@gmail.com> wrote:
> The question for me would be whether this app would make more more money
> than doing slideshows some other way. Notwithstanding arguments about
> putting users first and so forth, every big name news organization and
> magazine relies on photo slideshows to make their web sites earn their keep.
>
> My dream would be a free web app that let me create EW.com-style embeddable
> slideshows.
>
> Like this:
> http://www.ew.com/ew/gallery/0,,20152943_20153287_20240558,00.html?iid=top25-20081119-10+breakout+stars+of+2008
>

Evil publisher, that is hideous! And genius.

Noted:
Option to display slideshow on one page or across many pages.

I do see a problem with doing an audio slideshow like this, as I
imagine it would lessen the experience because of the break in audio.
But I do like the idea of having a unique URL/location for each slide
so you could link someone to some destination within the slideshow.
Similar with video that you see nowadays where the URL can link to a
video at a specific second.

--
Milan

[Brad Flora]

<puts on mefi-account-holding developer hat>

Yeah, audio wouldn't work.

But the idea of being able to link to a specific slide...that's pretty cool.

It's kind of a different use case I'm laying out.  I acknowledge that.  But when I hear slideshows, as a publisher, that's what I think about.

-Brad

[Scot Hacker]

On Nov 19, 2008, at 2:49 PM, Jeremy Rue wrote:
>
> If we are to truly create something that can serve the community and
> become ubiquitous, it has to be absurdly easy to use. I'm talking
> drag-
> and-drop.

Thinking aloud and building on Jeremy's thoughts: The challenge of
building a CMS that's simple to use and yet very powerful/flexible is
two-fold: A great back-end (database structure, logic, information
processing) and a great front-end (talking here about the editorial
interface, not the public-facing view). Django provides a great back-
end foundation, but doesn't solve the whole problem django newsroom
wants to address. A whizzy interface for slideshow creation is one
big problem to solve. Prepping video could be another. Creating
infographics from datasets could be another. Map mashups could be
another. All tasks that need whizzy editorial tools in order to be
easy and foolproof and not painful for authors and editors.

It's really hard to do desktop-quality admin UI on the web. Ajax is a
start but isn't good enough. It seems to me that if django newsroom
wants to change the game, it might want to completely re-think how a
CMS back-end works. To get desktop app functionality and quality,
maybe it all has to be built in Flash or Flex. Or... another option
might be to build an AIR app that talks to the back end through
xmlrpc. Rather than authors and editors logging into a web site to
post content, they could do everything from an AIR desktop client
(hopefully not Java).

Again, just thinking out loud.

./s

[Amy Jeffries]

Hey all,

I'm just catching up with the slideshow app discussion. The online
international news start-up that I am now working for, globalpost.com,
is certainly an ideal candidate to adopt django newsroom. GlobalPost
is web based and is looking to embrace open source and engage the
Internet community. We're launching in January and wrangling with a
drupal based CMS right now. The CMS allows a user to upload photos
and populate galleries, but does not accommodate audio. We are
planning an audio slideshow series to feature photographers from
around the world, but since our photo gallery app does not accommodate
audio we will be rendering audio slideshows as video for now and
publishing them through our video player. This is by no means a user-
friendly solution.

All of the attributes you have been discussing would certainly be
important. Our correspondents who will be uploading content from the
field are not necessarily tech savvy, they will want to be able to
drag and drop images and audio to layout a slideshow (as Jeremy
described), and they will want the aesthetics of the published
slideshow to compliment their work (photographers love black and 18%
gray backgrounds). The sales department will want the ability to
integrate advertising. The brand police will want to make sure the
skin is customizable to match the look of our site (as Scot laid
out). The director of multimedia (hey, that's me!) will want the
slideshow player to give the end-user autoplay and click through
options, and the ability to go full screen (or at least go big), and
yet be light enough for low band-with users to enjoy. The director of
multimedia will also want the published slideshow to be embeddable, so
that bloggers and syndication partners can use the content too.

So, that's my wishlist. Make my dreams come true! And if you need a
beta tester, I'm here for you.

- Amy