← Back to team overview

unity-design team mailing list archive

Re: Some impressions about the current status of Unity

 

On Sun, Feb 26, 2012 at 21:10, Jo-Erlend Schinstad
<joerlend.schinstad@xxxxxxxxx> wrote:
> On 26. feb. 2012 19:23, Adrian Maier wrote:
>>
>> On Sun, Feb 26, 2012 at 20:02, Michael Hall<mhall119@xxxxxxxxxx>  wrote:
>>>>
>>>> The hierachical directories is concept too deeply used in all
>>>> operating systems .   It will not go away just because many users use
>>>> their computers only for web and searching  photos/videos/music .
>>>>
>>> Phones and Tablets don't expose a hierarchical filesystem, which proves
>>> that
>>> users can easily adapt to a metaphor that don't use folders.
>>
>> Yet they still have a hierarchical filesystem .
>
> That's debatable. It's perfectly possible for the same file or folder to
> belong in two different subtrees at the same time. That's not hierarchical.
> All modern operating systems support that. And when I say modern, I mean
> newer than 1993 or so. I use the term rather loosely. However, when a file
> does exist in many places at the same time, using a hierarchical navigation
> scheme becomes cumbersome.

Come on ...    a filesystem that has hardlinks/symlinks   is still a
directory tree .


>> A smartphone deals with a very limited range of files , which makes it
>> possible to :  save photos in a predetermined directory , save videos
>> in a predetermined directory ,  play music from a predetermined
>> directory   ,  and  store the ebooks in a predetermined  directory ,
>> and so on  .
>>
>> I don't see such a scheme working on a general-purpose computer.
>
> Files doesn't have to be saved in a predetermined directory. They probably
> shouldn't be saved in directories at all. It is an ancient and completely
> outdated way of locating stuff.


Locating/searching is one thing .   And the actual storage of the
files is another thing .

Let's not mix those two things together.




> There's really no reason why a file should belong in a hierarchy at all,
> really. The only reason it is that way, is because it's been that way for
> thousands of years. Literally. You've needed to use paths in order for the
> human librarian to remember how to find stuff. Because when there are
> thousands of books, it is difficult to remember where each book is at any
> moment unless you follow some predetermined ordering system. Then, in the
> early days of computing, you needed a way to tell the computer how to find
> stuff. Since the compute power was so extremely limited, you needed a direct
> path. That's no longer the case, and I really think single-path navigation
> to be a thing of the past.
>
> For instance, let's say you have a photograph from your wedding, with your
> wife, your friends and family. What is the right path to that photograph?
>
> /media/photos/friends
> /media/photos/family
> /media/photos/wedding
> ...

So basically the idea is to generalize the idea of "photo album
management using labels"    to any kind of file.    It could be
interesting.


However it's hard to imagine how could someone backup the photos if
the files are stored "nobody knows where"   and are accessible with
multiple search paths .  This sounds like chaos .


> There should be no fixed number of ways to access that photograph, of
> course. It's "location" should depend on what you're looking for. Let's say
> you have Bluetooth and everyone uses that on their mobile devices, which
> they obviously always carry with them. Then your system should recognize
> who's present and you should have "People nearby" category in your Photos
> lens which would always display photographs of the people who are in the
> room with you.
>
> You may think that sounds like fantasy, but it's actually quite easy to do,
> though it obviously requires some work. Doing that using hierarchical
> structures, would be much more difficult. Using metadata to describe data
> content instead of just referring to a location, makes it possible to do
> extremely cool things with relative ease.
>
> That's what the semantic desktop is all about.

So you are thinking to have the metadata stored in a small database.
And integrate into the desktop the ability to manage the files with
labels , and search for them.

What about the actual files ?   They still have to be stored somewhere
:  in a real filesystem   ,  or in some kind of database.

Using a database would be a really bad option :  the access to the
file would be possible only from within the special "semantic" file
manager .   Inaccessible from command line .   And inaccessible from
other file managers or  desktop environments  .

If the files are stored in a real filesystem,   there will be problems
with keeping the metadata in sync with the actual files.


So I would take this idea much more seriously if i had heard you guys
speaking of designing a new modern filesystem that adds support for
file metadata , file tagging , and advanced search capabilities .
So it would be a backwards-compatible filesystem usable from any
already existing application ,   but adding some new ground-breaking
features  .




-- 
Adrian M


Follow ups

References