Re: Album Support

[Sam Barker <sam quadrocket co uk>]

On Wed, 2006-08-30 at 09:44 -0400, Warren Baird wrote:
> Ben Monnahan wrote:
> > My thoughts
> > 
> > At first during the discussion I was thinking, "But Albums are just 
> > tags, do we really need to separate interface for them"  As Stephane 
> > says, I have them too, under Events.  Then I got to thinking.  Maybe 
> > albums aren't exactly like tags.  I have pictures of "Frank", "Eiffel 
> > Tower",  "Jesse's Bday 2006", and "Roadtrip to Tacoma".  To me "Frank" 
> > or "Eiffel Tower" are tags, whereas "Jesse's Bday 2006" and "Roadtrip to 
> > Tacoma" are Albums.  What's the difference. The album really *defines* 
> > the picture.  It's its most important tag.  Photos can only belong to 
> > one album whereas it can have many tags.  (this make break some others 
> > mental picture of albums)
> 
> Limiting each photo to one album definitely breaks my view of them. 
> using your example, I might also want to have a "Birthdays" album that 
> contains the same photos as "Jesse's Bday 2006" and "Fred's Bday 2006" - 
> and a 'Jesse' album that contains the same photos as "Jesse's Bday 
> 2006", and "Jesse's Housewarming", etc...

> However, I think the key differentiator is what other people have 
> mentioned :  Ordering.   I think usable definitions are:

> Tag:   Identifies an unsorted collection of photos with a common theme
> Album: Identifies a sorted collection of photos with a common theme
> 

Surely the way you describe of using albums is exactly why we have tags,
and what tags are very good at. A tag is just a tag! It doesn't have any
other meaning. An album is a group of photos, this could either be a
physical group i.e. in the same folder on a disk or a logical group that
is a selection of photos with several tags in common i.e sam & emma &
Edinburgh. 

> > Given its importance, I could see how it would be nice to create a 
> > separate way of selecting them.  That could be Johns way, or some other 
> > way, thats still to be decided.
> 
> Agreed.
> 
> > 
> > Another idea I came up with on the train - pushing personal agenda here :)
> > 
> > This seems to help solve another problem I have with F-Spot, the 
> > organization of Photos.  What if, instead of putting the photos in 
> > year/month/day/ we put them in album/ or year-of-earliest-photo/album/ 
> > ?  I never copy to Photos because its nearly useless to have them sorted 
> > by date if you want to browse for them on the disk.  Apart from 
> > birthdays/anniversaries etc I never know the date a photo was taken.  I 
> > surely could find it in album/ though.
> 
> hmm.   Now I see where your one album per photo idea comes from. 
> Unfortunately, I feel pretty strongly that we need the ability to put a 
> photo in multiple albums, but I think that breaks what you are talking 
> about.   Unless we assume the presence of links and put the actual photo 
> in one dir, and then (symbolically or hard) link it into other album dirs.
> 
> I definitely agree that an album based dir structure would be a lot 
> easier to navigate, if we can figure out a way to make it work.
> 
> 
> > To make this work, In addition to  the "Add tag" we would add "Add to 
> > album" in  the import dialog.  There would be the option to leave it as 
> > (No album) or create a new one.  Under the covers it would basically be 
> > implemented by a tag + import dir.  Changing the album would move the 
> > photo to the proper directory.
> > 
> > Issues with this:
> >   * Photos can only belong to one album - For me this isn't a problem, 
> > but could be for others.
> 
> I think this would be a big issue for me...   iPhoto had the concept of 
> multiple albums per photo, and I used it quite a bit...
> 
> >   * Subalbums, would we support them and how?
> 
> Hmm.  Good question.   In general I'm a big fan of heirarchical 
> organization.   This is one of my complaints about iPhoto - it had a 
> flat structure of albums.   As the photo collection grows, I think 
> *some* way to organize and group albums is important.
> 
Support for sub albums is no more complex than albums, define a sub
album as any non YYYY directory under an album.

So the photos directory might look like:

~/Photos
 |-- 2005
 | |-- October
 |-- 2006
 | |-- August
 |-- Birthdays
 | |-- Sam's
 | | |-- 2004
 | | | |-- October
 | | |-- 2005
 | | | |-- October
 | |-- 2006
 | | |-- June
 | | |-- September
 |-- Brian's Stag night
 | |-- 2005


This possibly has some dodgy assumptions but it allows users a clean way
of importing photos e.g. just put them the current year/month directory.
Then they can organise them properly later. 

> 
> >   * For (No album) would we revert to y/m/d/ ? - It could get full if 
> > someone never assigns to albums, also would maybe make the transition 
> > easier, since we all have a bunch of photos that aren't in albums.
> 
> Also a good question.   I think what you describe makes sense.
> 
> I might even be convinced that the y/m/d structure should be used 
> beneath all albums...   for a birthday party album it might not matter 
> too much, but say you had an Album containing all your christmas photos, 
> or *all* birthday photos for a particular person.   Having them 
> organized by year and date could be a good thing...
> 
> Warren

Though the more I think about this the less I see the need for a y/m/d
structure of photos on disk, its a good way to view them within f-spot
but is not very intuitive for use out side of f-spot. 

Sam *turtel* Barker