unity-design team mailing list archive

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

On Sun, Dec 19, 2010 at 21:35, fain182 <fain182@xxxxxxxxx> wrote:

> > Now imagine Jane has a new camera and goes on 4 vacations per year.
> > On each vacation, Jane takes several hundred shots.
> > After 3 years, Jane has 4300 photos she made all by herself, he Uncle's
> 200
> > wedding photos not even included.
> > As she tries to find "that picture with Auntie Mabel on that rock" from
> one
> > of the vacations, she is confronted with 1200 photos to go through.
> > Now she complains: "darn, i wish i could just tell the computer to show
> me
> > photos of Auntie Mabel".
> and in your opinion Jane would tag every of the 4300 photos with all
> the name of the people in the photo?
>

nobody's talking about names. That's facebook, i mean labels, titles,
albums, collections, locations whatever you find useful in identifying the
objects.
since we want the computer to be able to help us retrieve these items later,
we will outfit it with the ability to promote those tags which are most
popular or frequently accessed visually, affording their re-use. If two tags
are similar of content, we will have the option to merge them into one.

An object that fits "2008", "Holiday" and "Grandma" can be sought by someone
picking these attributes from their respective "Places".
"Places" bridges the conceptual gap between navigating to *Somewhere* within
a directory tree symbolic folders / Query based search.

The whole problem imo lies in the way stuff is displayed to the user, not in
the way it is physically stored on the medium.

That's why so many people in this thread meantioned the MVC concept, in
which an underlying technology is abstracted by a much more comprehensible
interface, which is far simpler and easier to use, yet powerful enough to
control fully. It's a bit like Star Trek's "universal translator", or like a
compiler perhaps.. you give it C or Vala, it executes the described sequence
of orders, after translating them into something the executing hardware
speaks.

The user understands what does not confuse, unambiguous metaphors, obvious
symbols, accessible controls (fitt's law), "only way to go" (constraint),
"easiest thing to do" (as mpt points out in his blog), and everything that
is clear per se, one message at a time.

I don't think that manual tagging will be successful, can be an
> overhead more then an help..
>

yeah, manual tagging, as easy and quick as it can be if you select groups of
items via thumbs and previews or folders, is still not the sole solution.
Metadata, in the physical universe, is attached to the respective medium by
the author, not by the recepient.
So if you receive a file from someone, it already *is* tagged.
Only if you receive files from your own "Camera", it is not always geotagged
and date-tagged automatically.
Then you'd use "Photo Manager" to add tags to groups of files you are
importing.
Once you want a specific file to have an individual title, you select it in
its group and simply enter a title for it.

imagine you're in the library trying to retrieve a book, how wrong would it
if you had to read every book first in order to identify it?
Or if you wanted to view a webpage, and you would have to study the markup
before you could begin to imagine what the page is supposed to look like!?!

GNOME (GNU Network Object Model Environment) sports "managers" for Content:
* a web-markup manager for webpages (Epiphany/Webkit)
* a music manager for music files (atm rhythmbox)
* Photo Manager for Photos (Shotwell)
* a connection manager for instant communication services (telepathy mission
control 5)
   ** inside telepathy, there's e.g. Ofono for GSM telephony
* a contact manager for all of our contacts (Telepathy/Folks)
* a message, thread and newsfeed manager (Evolution)

with all of those well fitted and equipped for management of actual content
metainformation, it would be a strong regression to resort back to
"filenames".

All the other apps are either creative suites (OOo, Anjuta, Ardour, Blender,
Inkscape, Gimp etc), games or managers of "special" content types, e.g. star
charts (Celestial) or Themes (e.g. Appearance Settings).

The change we are undergoing is quite simple. Instead of giving a new file a
filename, we give it a title, if it's a batch of files, we might give them a
common descriptor such as an "Album Title" or "Group Title", or simply a
common location, venue or event etc. Not restricting this to any
machine-proposed formats means allowing for free "tagging", all upon
creation. If we open a certain file often, the computer will have a way to
ask us to identify it with a title at some point (e.g. when opened from
"frequently accessed", if it has no title).

It is good to hold on to the folders and files system we have currently,
because that's where our b#lls are. It is only a step forward, to add proper
support for Titles, Tags and Content-type-specific attributes as soon as
possible.

We'll have useful default fields to fill upon "save as" or initial "save",
e.g. Title, Artist, Genre, Album Name, Year, Comment for music library
items.

I think this is all gonna get much better, if the interfaces start getting
design-consistent, e.g. with the Unity Dash.
Once we have a consistent pretty interface, people will nolonger have to
bother about "this app" or "that app", since they are confronted with what
appears as one unified content-adaptive easily learnable since totally
consistent management interface.

Things that break that vision into splinters at the moment are:
* Project CodeName instead of Telling Title (e.g. "Rhythmbox" instead of
"Music Manager")
* product branding instead of semantic symbols
* "app" focused design instead of human centered design

At some point i don't want to do without Metadata anymore, filenames on
their own can hardly be *that* indicative of content.

anyway "fileless paradigm" is a terrible name, for speaking about
> alternatives way to navigate between files.. maybe "pathless" is
> better..
>

Agreed.
I conclude we are talking about managing content and Managed Content here.