Multiple vs single album viewers

1 files changed, 60 insertions, 3 deletions

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index a8779e279..70fcf4924 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -650,7 +650,18 @@ My wishlist for the plugin would include:
 >>> created to go alongside the pictures are basically stand-ins for the
 >>> pictures, as far as metadata, wikilinks, tags and other "first-class
 >>> wiki page" things are concerned.
->>>
+
+>>>> I can see why it's important to keep these models simple and have figured out
+>>>> that the viewer pages are stand-ins for the image. Just as a tought though. If 
+>>>> this relationship was made more explicit ie. the viewer pages *are the content*
+>>>> just initially generated from the image metadata with a link to the image. Then 
+>>>> the mental model would stay intact and more in line with how html and the 
+>>>> implementation works.
+>>>>
+>>>> One thing to point out is that last time I tried pages can be members of 
+>>>> arbitrary numbers of trails/albums. You just get multiple rows of navigation, one
+>>>> for each trail. This doesn't quite work as it's hard to know which one to click.
+
 >>> If there are to be viewer pages elsewhere in the wiki, I don't think
 >>> inheriting the picture's metadata is desired. Suppose you have a
 >>> picture of Alice and Bob in the album "holiday in Exampleton, 2010",
@@ -661,14 +672,18 @@ My wishlist for the plugin would include:
 >>> times - once is enough, there's only one actual photo after all. So
 >>> I think the "main" viewer page should be the only one that has
 >>> the taglinks for people/alice, people/bob, places/exampleton.
->>>
+
+>>>> The problem exposed by the tag page issue is very tricky. As you'd
+>>>> probably want the exif info, captions and titles to transfer. Just not 
+>>>> necessarily the tags.
+
 >>> My next question is, should the viewer page representing that
 >>> particular picture in its context of "pictures near Exampleton"
 >>> (i.e. its "next" and "previous" links go to the next and
 >>> previous picture near Exampleton, regardless of whether it was
 >>> on an earlier or later visit) be a first-class wiki page
 >>> at all?
->>>
+
 >>> * Does it make any sense to comment on "this picture in this
 >>>   context", if your wiki has comments, or should the only
 >>>   place you can comment on it be its "main" viewer page?
@@ -697,6 +712,48 @@ My wishlist for the plugin would include:
 >>> and one of the side-effects of the albumviewer directive should be to
 >>> replace [[plugins/comments]] with a link to the original? --s
 
+>>>> One thing to consider is the built in difference between the original and 
+>>>> the secondary inferred by the fact that the first is an `album` the second
+>>>> an `inline`
+
+>>>> ### Single viewer 
+>>>> For my own usecase what you describe makes sense. I see the content of an inline object
+>>>> (struggling a bit with what terms to user here) as a particular composition of
+>>>> viewers. Perhaps comments should only be possible on the page with the inline rather 
+>>>> than the secondary viewer pages as the inline page not the image viewer is 
+>>>> the first-class page in this scenario? The inline page would also be the page you tag 
+>>>> etc. to make it show up in various contexts such as the tag page.
+>>>>
+>>>> With the thinking outlined above I'd say that the secondary viewer should be a 
+>>>> non editable clone of the original viewer without any source. Just html output with 
+>>>> backlinks to the original page. This means that there are limitations to how these 
+>>>> secondary viewers can be used as the title, caption etc might fit some contexts 
+>>>> better than others. Personally this is fine as I see these inline based albums as 
+>>>> compositions or views on existing content.
+>>>>
+>>>> ###Multiple viewers alternative
+>>>> The alternative is having a page say in `/story/album.mdwn` with the following directive
+>>>> \[[!inline  pages="/01/IMGP6494 or /02/IMGP6601 or /04/IMGP6922" sort="title"  show="0" template="albumitem"]]
+>>>> that creates new fully fledged editable viewers for each image in `/story/album/'
+>>>> without tags being auto populated but backlinks to the original album viewer.
+>>>> 
+>>>> This would make the viewers completely independent allowing for unique titles, captions and comments
+>>>> depending on context. Very useful when creating powerpoint like slideshows where you might need 
+>>>> different captions depending on the context. In your example wiki with photos from gigs this would allow 
+>>>> a page with an album inline about stage lighting with a selections of images and captions that highlight
+>>>> relevant things in the image as well as a separate inline album page, with some of the same images, 
+>>>> about drumming styles and posture/grip of drummers.
+>>>>
+>>>> I started writing all this supporting your single page case but looking at it now from my limited
+>>>> understanding of how ikiwiki works it seems the multiple viewers option is conceptually cleaner 
+>>>> and more flexible. It relies on three things:
+
+>>>> * A mental model where the viewer page is the content not the image
+>>>> * That tags aren't automatically transferred from the original context. This doesn't seem that critical however.
+>>>> * Backlinks to the other places the image is used.
+>>>>
+>>>> --[[kjs]]
+
 ----
 
 ## cbaines' CSS changes