Thanks for the links - I read all that and it seems there is quite a controversy between those newbies to computers who think you can do useful work without a file management system, and those more experienced content creators who know why we have one and how fundamentally important it is.
There is a move afoot in the industry to try to control what users can do with their devices, and to dumb them down, not for any useful purpose, simply to aid their own motives to control an increasingly centralised industry. The best example of this is the ipad and the apple store. It's now virtually impossible to find anything on that monstrosity and the search facility is geared toward making money out of that fact. The gnome community should be very wary of these false ideas being spread about the apple community and avoid copying these errors of judgement. It's time now to build a better file management system than anything that anyone has ever done before, and the reason for it is because it is now sorely needed. With the revolution in the self- publishing industries, of books, music, photographs, videos and software applications, everyone is potentially becoming a content creator. As experienced professionals we should be finding ways to educate and lead the general public into a simple and effective way of organising themselves on a computer. and that has always been "file and directory system". There are those people who will never do anything more than sit on a couch, consume their stuff and allow their ipad to fill up with junk until they need to buy the next new one. Apple is targeting those and I feel it would be in the best interests of all of humanity if the free and open community took it upon themselves to find a good solution to the other type - the content creator and manager, communicator and developer, self-empowered and helping mentor others to become the same. So, having summarised the two points of view, it is necessary to define what a good content creation system needs in the way of file management. PROJECTS At the top level (the trunk, so to speak) we have our projects. Gnome might be one of these. another might be Nautilus, or some other new idea that one of you here might create. When we start to work on a new project we start to accumulate object which need filing. This brings us to our next level ... CONTENT As most of us have digital cameras these days, often this is the start of a project. I believe that it is very important to make any decent file system do photographs best and first. If it can handle these well it will do most of the others with little modification. To come back to projects, we would normally create a folder to hold our project, and this would involve us making some decision about where we want to locate it, how we are going to handle the workflow of our content reaching the main folder, how it is to be backed up so we don't lose it and, HORROR OF HORRORS, if we are going to try to synch it with multiple copies on multiple (gulp) machines. With a camera you already have this problem, and most of us have solved this by copying all files once from the camera and immediately wiping the camera. Anything more complex than this is a very big headache indeed. Having learned this from cameras, one is wary of it when it comes to the next device in the chain - could be the ipad (I'm using this loosely to refer to any pad type device) or could be a full blown PC of any type. Which way is best? At the moment I am experimenting with both devices as next in the chain and have not yet decided on the best solution. The ipad is a fantastic place to review and catalogue and rate the photos, and it is probably going to be the unit of choice for no 2 in the chain. At the moment, because of the crazy way everything is implemented in apple the only safe way to do it is to put the photos directly onto the PC and then let them synch back to the ipad. this is terrible really and needs to be fully understood so that GNOME can do it right. It is not easy, and hard decisions will need to be made, more about what cannot be allowed to happen rather than on what is the best way. The number one thing that cannot be allowed to happen with content is that you have more than one file with the same or different name on the system and you cannot then tell which is the latest version. This is the current state of the design of the ipad system, and of a philosophy which says you don't need a file system let the app do it. The file is sent to one app to do one thing to it, then to another app to do something else, and before you know it you have this problem. It is not sustainable. With photos, there is a tendency to allow the camera to do the naming of the files. This works well because photos are naturally identified by what they look like, and the order they were taken in is a good order to view them in. Some people to a lot of photo editing and this produces versions of the same photo. It is necessary to be able to rate photos and to filter the view so only photos of a certain rating show. Otherwise we have folders full of thousands of pictures which are mostly not of any great interest. In a modern OS, this should now be handled generically and not have to have each app do this. Where we have multiple images for one photo it is generally handled that a folder is created automatically by the file management system and the file naming system then appends some numbering scheme to the images within the folder, showing the latest image as the thumbnail for the folder. The fact that an image has become a folder is generally indicated by a stack of images as a folder icon. This versioning system is probably good for video editing, sound recording editing, and possibly even for document editing too. With photos it is absolutely imperative that we do not lose the original because some effect we apply can destroy the image completely. With source code files this is not so tragic yet could prove very useful if, whenever we edited the file, the old file was renamed and a new file created with a copy of the original and with the original name. In any case, this is one way it has been done in the past, and others may have better ideas of how to achieve this. MIXING FILES OF DIFFERENT TYPES Typically our project contains files of a number of different type. There could be downloaded html, PDF files, epubs, movies, doc files and a whole lot more. It is not practicable to file them in any other way than together within the project folder. If we are trying to become tidy, we may decide, once we have many photos, to move them to a separate photo folder, yet all of this needs to be done on the fly and for small projects its best to keep the directory (folder) structure flat if we can for simplicity. This means when we look in our folder we want to see, sometimes images of the cover sheet of our content, sometimes the file names and details are more useful. When we start to work on our project, generally the project name is the first thing that enters our head, and it would be useful to have our main projects in some easily accessible place maybe on the desktop, or at least the highest level or root level of all our folders, so it was easy to get to our most used content. Once we are in our project folder we can see all of the various objects we need to work with and we typically perform actions directly on the objects. We might open them in certain applications, wish to move them around, rename them, delete them, etc. LAUNCHING APPS Increasingly it is becoming necessary to be able to open documents or photos in a number of different apps, due to the simplification of the app market. No longer do we seem to have program's that do it all. There is a trend towards multiple apps doing specialised things with the same file types. It's necessary for the OS to know what apps work with what files and provide a full choice to execute the app using the currently selected file. Upon completion, the focus is returned to the project window for the next operation, or some other project may need to be invoked. VIEWS Each app that we launch creates a view into our data, and we need to be able to maintain separate multiple views so that we can work with different content at the same time. We might also need to launch a view of an app which does not create content (a web server configuration / start / stop app for example) and we need a place to do this from. This is provided currently as the desktop of GNOME. We need to switch between views and be able to copy and paste content. It would be very useful to be able to split the screen so we can see two views at the same time and select which app is in which view. I do not wish to see a return to windows open all over the place and this is a compromise idea that could allow for cross window functionality without all of the other window resizing and moving about you get with windows. I don't personally have a need for resizable and overlapping windows but others might. This is something which really only became a problem in windows after ODBC 2. Before that in ODBC windows were opened maximised and the interface was 100 percent better for it. HEAVY FILE SYSTEM MANAGEMENT TASKS Sometimes it is necessary to completely change how we organise our data, or to set up new equipment from scratch, and we need to be able to copy lots of files from one place to another. The best tool I can remember for doing this was a fast wire transfer software running MSDOS in character mode. Since then nobody has seemed to get it any better. It was good once upon a time in Windows but it has become so dangerous now it is easy for users to drag and drop their stuff into oblivion. Even happened to me recently with a Dropbox I managed to drop inside of itself and somehow made a Dropbox within its own self. Still haven't figured out how to undo that mess. So it's good to consider why things were better once before, and how it was achieved. Fastwire had two side by side or one above the other window areas showing a target source and destination. Each window area had an ability to drill down into the file system and it was possible to click on one or more files or folders in the source. Then there were a series of buttons in the middle between the two window areas which had arrows on them showing the direction of the move, or delete, or rename and so on. It was very intuitive to use and did not have any drag and drop dangers. You could see what you were going to do before you hit the action button. What has happened with windows systems is they seem to have become smaller over time as the screen resolution has increased and the drag and drop functionality has become less accurate with each increase. ABOUT TOUCH vs MOUSE BASED SYSTEMS I have been using the new ipad for the past three months and have come to some definite ideas about how best to handle the problem of screen resolution changes with changing devices. How we are managing with these touch type devices best at the moment, is to enlarge parts of the screen we are working with. This is done with a two finger gesture. Say we have a component box which has a series of options one under the other, yet too small to accurately touch on, then we enlarge that are to fill the screen and touch easily that particular line we require. This works very well because we can see what we are doing very well and here is complete accuracy, even more so than with a mouse. So, how can we use his idea to build a great system for navigating our desktop just as easily on a littler phone or a big ipad or some future inbuilt desktop model? I suggest the following: We break our screen design up into logical separate and related pieces. we might make three or four pieces of toolbar at the top, any combo box or set of html links could be held in a separate div container. And then in the top left hand corner we place a spiral symbol, counterclockwise like an @ sign, big enough to be hit by the fingertip. When the user touches this or clicks with the mouse, the area of the form selected is made to fill the screen at a magnified viewpoint, and be centred within it. After the user clicks on one of the functions within the area, the view is returned to normal. What this does is it allows the user to drill down to the functionality in the application and back out to the wider context. This could be very nice used throughout GNOME and could be implemented quite easily as a generic function of the operating system. it is a fairly simply yet completely powerful change. I'm going to leave it there. I hope this message inspires you to think outside the square and to find solutions which will help us all move into a better world. Thanks for reading this long post. all the best Adam On 17 Apr 2013, at 15:11, António Fernandes <antoniojpfernan...@gmail.com> wrote: > Hi. > > I would also suggest reading the following pages, in order to get familiar > with the design direction: > > The "Files" design wiki page: https://live.gnome.org/Design/Apps/Files > A blog post on the most recent redesign implementation: > http://blogs.gnome.org/mccann/2012/08/01/cross-cut/ > Also related, this blog post on the (declining?) role of files and the file > system as an user interface for content: > http://blogs.gnome.org/mccann/2011/06/08/new-pony/ > > > 2013/4/17 Adam Essene <adamess...@icloud.com> >> Thanks for the quick response. I will study the existing documentation and >> direct my request to the design team. >> >> Integration of the file system at the highest level means that the user >> experience is the file system as far as the user is concerned. It is this >> final presentation design which I would like to contribute some ideas >> towards, leaving the lower level implementation to those expert at this. >> >> Thanks again. >> >> Adam >> >> On 17 Apr 2013, at 02:21, Hashem Nasarat <hnasa...@gmail.com> wrote: >> >>> Thanks for the introduction. >>> >>> We're not all men here, and GNOME works against discrimination, so >>> "gentlemen" while polite, is inappropriate. >>> >>> In terms of computers, filesystem has a very specific meaning. Perhaps you >>> mean operating system with the best file manager? I'm not sure. >>> >>> Regardless, I don't know if there is very active UI related work being done >>> on nautilus. Before nautilus is made touch friendly, GNOME as a community >>> needs to solve a few fundamental issues regarding how best to support touch >>> devices. This page documents some preliminary efforts, and that might be a >>> good place to get involved. >>> >>> Also, you might be interested in getting involved with the design team. >>> >>> Best of luck. >>> On 04/16/2013 05:41 PM, Adam Essene wrote: >>>> Gentlemen >>>> >>>> I wish to introduce myself to the team working together on the GNOME OS. >>>> I am not sure if this is the right place for that. My particular area of >>>> expertise is file system design and so I am interested to specialise in >>>> this area. I understand that Nautilus is the file management component of >>>> GNOME OS and if this is not the case, please direct me elsewhere. >>>> >>>> My vision for GNOME is the best file system for any computer in the world >>>> for the individual. I am leaving Apple to join the GNOME effort because >>>> it is not possible to do anything on their Ipad and that is simply not >>>> good enough for the hardware type which holds the future for all of us. >>>> The move away from the PC to the ipad is fuelled by the tactile experience >>>> which, once sampled, it is not possible for Content Creators to return to >>>> the old environment, especially when working with text and photos, which >>>> is the dawn of electronic publishing. >>>> >>>> I have in excess of 40 years experience at the highest level of systems >>>> design and wish to apply that to the problem of file system integration >>>> between a mouse type and a surface type environment and in particular to >>>> the photographic and publishing workflow. Initially I would like to >>>> stimulate the design team members with my unique perspective, being also >>>> an artist, writer and content creator for new media yet to be invented and >>>> deployed on operating systems now being considered. >>>> >>>> If I fit in here, please let me know, or tell me to go somewhere else you >>>> might consider more appropriate. >>>> >>>> best wishes >>>> Adam >>> >> >>> -- >>> nautilus-list mailing list >>> nautilus-list@gnome.org >>> https://mail.gnome.org/mailman/listinfo/nautilus-list >> >> -- >> nautilus-list mailing list >> nautilus-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/nautilus-list >
-- nautilus-list mailing list nautilus-list@gnome.org https://mail.gnome.org/mailman/listinfo/nautilus-list
