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

Re: [Ayatana] "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.