Re: tags vs albums

[Jakub Steiner <jimmac ximian com>]

On Fri, 2004-10-22 at 14:04 -0500, Larry Ewing wrote:

> 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.

I was probably quite confusing when I talked about ditching the tag
concept. I was really talking about the implemented tag _interface_. I
am by no mean proposing to stop being able to assign keywords/tags to
images and not being able to query the library based on these. I
proposed replacing the tag interface where it is in the UI with albums.
The assignment of this metadata would go to the metadata editor sidebar
and the search functionality would consist of a quicksearch entrybox
(http://primates.ximian.com/~glesage/wiki/doku.php?
id=f-spot:quicksearch), advanced query editor with a chance to save the
query as a virtual album.


> > 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 

I mean in terms of workflow. User wants to classify his images. With the
current interface I would use the tag assignment interface to classify
my pictures and then go to the metadata editor to assign additional. 

The tag interface would also somehow need to hold the information that
sucha tag is "standard", ie contained in a metadata spec such as
IPTC/XMP (usable for export -
http://primates.ximian.com/~glesage/wiki/doku.php?id=f-spot:web_export,
see use case) or an arbitrary keyword.


> > 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.

I'm not sure I follow here on this one. Are you saying that moving the
F-Spot interface onto the web for consistent look and feel isn't a goal
to aim to?

> 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.

As noted above, The quicksearch functionality isn't to be ditched, but I
propose using the simple entry-box than the structured tag interface.

> > 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.

The google interface is very much more similar to the quicksearch
described above than the tag interface.

> 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?

You are in fact right that the album would in fact be implemented
exactly the same way as the virtual album (a query for property
album="foo"). However a simple interface would be used to define this
(drag a selection of photos onto the album sidepane, choosing "new
album" etc.)

The difference between album and virtual album would be that album is a
single property and and thus the "physical" links (one album per image)
and virtual album is a stored query (can contain images independent of
their album property).


> > 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

Again, this is from the workflow perspective. When one classifies
images, the metadata editing sidepane would be the only place to do this
in. 

The tag interface combines assignment (classficiation) and query into
one. However classification can be quite complex if we want to make the
metainfo usable outside F-Spot and make the interface for querying
rather complex and it's not very scalable in a asense that you have to
navigate a fairly complex tree or tags to do a search query.

Hope this clarifies my proposal a bit more.