Re: tags vs albums

Sweet!.  Ok first off, I'm really appreciative of the thoughts here, and
I'm very open to changing the current system but I'm not sure simply
replacing the tag metaphor with a virtual album metaphor is a solution.
I'll try to explain as I go.  I'm going to be making the case for tags
as I see them in this mail please don't take it as a rejection of the
"virtual album" concept I just want to make sure you understand where I
am coming from.  

On Wed, 2004-10-20 at 16:32 +0200, Jakub Steiner wrote:
> Hi Folks,
> *food for thought*
> I want to put the concept of tags, as we have them now in F-Spot, in
> question and propose a more natural interface concept. The suggestion
> comes from thinking about various tasks we came up for F-Spot [1],
> taking export functionality in particular consideration [2].
> Tags
> ====
> As it stands, the user has a flat library of photos. Each photo can have
> a set of tags assigned to it, such as what place the image was taken,
> what event that was, who/what appears on the image. 
> Query Logic
> -----------
> Tags enable the user to limit the view to images containing a specific
> tag. The user can also select multiple tags at once. Contrary to my
> point of view, this doesn't limit the query further, but enhances the
> view by adding images containing tags using the OR operand. How many
> times have you queried the library for "Photos from Boston or Tuomas"?
> "Images of Dogs or Favourite Images?".
> With the current interface, it is not possible to query for Event AND
> Person so that one could get images of a person appearing while at an
> Event.

The plan has always been to allow for AND over the group as well as or
as well as NOT.  I haven't gotten that far yet, and to be honest I'm not
sure how I want to proceed in the ui but that doesn't mean it is
impossible.  There are existing implementations of the tag/category
metaphor that allow for just that.

> Human Language
> --------------
> There is no clear metaphoric link to tags. In the physical world, we
> structure our photos in albums or piles. It is not physically possible
> to have one image appear in multiple albums.

The current physical metaphor I want you to think of for tags is colored
sticky notes poking out of a file drawer, with an easy way to pull out
just the photos that match and put them in a pile (an active search).
Photo Albums are a separate metaphor, they are the things you produce to
show people by making prints.  So in this world view albums would the
things you uploaded to the web not your photo file. This seems obvious
to me, although the current code seems to have left plenty of people
baffled so I guess chances are good that I am wrong completely wrong.
The physical impossibility of an image being in multiple albums doesn't
have any relation to this model, it also isn't a problem in the real
world because people make prints.  
Try thinking of a category as the color of the sticky note and the tag
as the label on it.  In this view a tag is a slightly structured keyword
and is orthogonal to a folder drawer or an album.

I think it probably makes sense to allow for multiple drawers. and offer
a simple way to switch between them but I think there should be very few
of these and the interface should encourage slapping a sticky note on
something as opposed to making a drawer for a group.  It seems like a
flat namespace of drawers would be sufficient.

> Reuse
> -----
> With the tag interface to the library is not possible to store a certain
> query. One has to manually deselect the current "filter" and apply a new
> one.

This is absolutely doable with the current backend and honestly I don't
see albums really help us here since real world folders can't store
living searches either.  We just cheat sometimes and call them

> Metadata
> --------
> We do want to have additional metadata associated with an image. It is
> confusing to use this concept for some, and another for the rest (name,
> caption...)

Do you mean that it is strange to have sticky note on an image as well
as an exposure sheet and a description?  I'm trying to understand but I
think you are suffering from the fact that you keep wanting to see tags
as albums not as sticky notes.

Or do you mean that 

> Export Implementation
> ---------------------
> While it is theoretically possible to come up with a dynamic web system
> for exporting photos on the web, retaining the same concepts as applied
> on F-Spot alone with tags, it relies heavily on server side scripting
> and doesn't sound trivial to do. Generating static HTML pages with the
> tag interface is hardly doable with way too many permutations to deal
> with.

There is no possible way to match all the various web gallery structures
and I don't think we want to.  A web gallery is an item unto itself it
is external to your file drawer.  Don't try to make one into the other.

> Proposal - Albums
> =================
> I propose we use a concept of Albums and Virtual Albums (similar to
> vFolders in Evolution) instead of tags.

As an evolution hack I developed a lot of opinions on vfolders few of
them good.  Most of the problems I have with them are related to
implementation details, like speed in switching, but in general I think
they require too much setup and don't offer much.  I end up just doing
quick searches to find mail I'm interested in 99% of the time.  I do
have some mail sorted into actual folders, usually list mail which I
consider separate enough from the rest of my mail that I don't want to
mix them.  I really think having a search history and forward/back
navigation makes more sense than having explicitly saved searches.

> Human Language
> --------------
> Album is a real world object that easy to understand. The term Virtual
> Album clearly exhibits the difference from the physical Album.
> Reuse & Consistency
> -------------------
> The concept of stored queries isn't new. We have them in Evolution and
> hopefully thanks to beagle it will appear in the file-manager, file
> dialogs and elsewhere on the desktop.

I use evolution's search or beast to find messages not vfolders.  And I
use google a lot more than my bookmarks.  Granted I do have a few
bookmarks (as an aside, I'm actually using mostly using tomboy for
bookmarks lately) just like I have mail folders.

I'm having trouble with the valbum metaphor in another place here too.
The way I see it stored searches are live queries on a set of attributes
and so I'm wondering what attributes we can build valbums from.  Are you
saying that we should have two types of album, one that is actual and
one that is virtual? And If so that virtual albums are stored queries on
the combination of actual album and other attributes like time and date?
How would this be represented in the ui?

Or are you saying that we only have one type of album, a virtual one,
and that it is implemented by adding an attribute the image and that
stored searches are something separate from valbums and live in the
search bar/box/ui dingus?  In this case the situation for vablums and
tags/categories is exactly the same and it sounds like we are just
discussing a name change. 

> Metadata
> --------
> Image attributes (including the stuff that's done with tags now) is
> defined at one place in the UI.

I'm not sure what you are getting at here.  If there are multiple album
types there has to be a lot of ui for making the valbum and if there are
only valbums

> Export Implementation
> ---------------------
> Mostly every web image gallery is structured in albums. Even stored
> queries (Virtual Albums) could be generated as static HTML. 

I intended to use active queries further limited by selection for this.
The same way I do slide shows and editing actions.  Is there some value
with linking things at a deeper level that I'm missing?

Like I said this message is mostly intended to show that there is some
logic to the current metaphor, and that I don't completely understand
what you are proposing.  I hope it doesn't seem hostile, I really
appreciate the input.  Now I'm going to go back and chew on the valbum
plans for a while longer and see if I missed something or inspiration

Thanks again Jakub,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]