← Back to team overview

unity-design team mailing list archive

Re: "fileless" paradigm

 

On Tue, Nov 23, 2010 at 7:48 PM, frederik.nnaji@xxxxxxxxx <
frederik.nnaji@xxxxxxxxx> wrote:

> Thanks for the excellent material guys!
> While this work was mainly about folders and not about files, i've been
> able to extract some insights, that might be of relevant to this thread..
>
> On Wed, Nov 24, 2010 at 01:14, Kevin Godby <godbyk@xxxxxxxxx> wrote:
>
>>
>> You can (freely) download a PDF of this paper from
>> <
>> https://digital.lib.washington.edu/dspace/bitstream/handle/1773/2031/Don%27t%20take%20my%20folders%20away,%20current.pdf?sequence=2
>> >.
>>
>>
> above document portrays folder hierarchies as an independent type of
> information, right beside "files", "folders" and "meta information"..
> This means ultimately:
> A hierarchy presents a tree structure mapping of simple object
> relationships..
>
> Tree structures are used all over nature and science to present simple
> relationships.
> But they can't present how two subprojects merge back into one.
>
> Folders allow for the presentation of simple object relationships:
> * serial inheritance (breadcrumbs)
> * affiliation ("inside" and "outside" a folder)
>
> In order to fix the problem with folder merging mentioned above, a
> subfolder would have to be able to appear within multiple conatining folders
> simultaneously, as far as our archaic tree view is concerned.
> Imagine having several simultaneous hardlinks to a file/folder, that should
> nearly describe it to some of the CLI veterans on this list ;)
>
> To see what a tree looks like, some of us might wanna try a "sudo apt-get
> install tree" and a subsequent "tree -d" afterwards..
> That was very refreshing to me.
>
> We'll be "fileless", once we allow for a more advanced way of merging
> branches of tree folders with both automatic and customizable selection
> routines(filters).
>
> thoughts, comments, criticism?
>

+1

At first, I too expressed some doubt about doing away with managing files in
folders. However, now that I think about it, I think that a well implemented
project system is actually better. One, it will allow just as much
organization as folders, and two, it allows the same file to span multiple
projects, which folders currently don't allow (disregarding symlinks, which
are too complicated for an average user to understand.)

If a new method was used, a user would have two main questions:*How can I
find the file I'm looking for?* and *How can I organize a file that I've
made*.

First, *How can I organize files that I've made?*
For me, I try my best to save files in the proper folder, whether it be in
real life with a real folder, or on my computer. When I do, it allows me to
stay organized. However, many times I'm in a rush, and I need a place to put
papers/files temporarily. A good file managing tool would allow for both
types of saving: organizational and temporary. Thus, I propose that when
saving a file, a treeview is shown, with projects and subprojects shown,
allowing the user to check the one(s) that apply to the file. In addition,
the user should be able to easily start a new project. There is also a
textbox shown, allowing the user to type the name of the file. By default,
the name should be "Untitiled [Type of File]." Furthermore, if no projects
are selected, the file would be saved under the "To Be Organized" heading.

When organizing files that have already been saved, the user should be able
to select a file, and immediately, in a sidepane, see what project(s) it
belongs to, with an edit button allow it to be organized into a specific
project. If possible, related files (via zeitgeist) should be shown.

In this way, copy/pasting of files/folders is made obsolete.

Second, *How can I find the file that I'm looking for?*
That is, what should the file manager show for me?
When starting the file manager, a home screen is shown. This home screen
uses zeitgeist to show recently used files, files to be organized, and
projects. Like a unity places view, a grid/list of projects/files is shown.
Double Clicking on a project shows the files and subprojects inside.
Overall, this works just like a file browser, but instead of a tree
structure, it uses a tag structure, allowing some files to be found in
multiple projects.

Furthermore, a simple search-as-you type structure would allow you to find
files.

When looking inside a particular project, the files are organized by type.
Each type can have its own organizing tools. For example, documents can be
arranged by author, recency, frequency, length, etc.


tl;dr: Overall, I think a system like this would allow quick and easy access
to files, and remove the need to copy and paste: everything would be in
terms of assigning or removing a file from projects.

I feel this gives more flexibility and is simpler to use and understand,
removing the hassle of navingating long trees of folders.

I'll see if I can make a visual mockup of this idea.

Follow ups

References