Computers & Tech posts page 13

in finder: create new file by hitting command-n. type in name with extension, opens editor of that extension set in preferences with new file with that name. also enter in keywords describing new files contents. based on setup, system will know “where” to put file: example – create a new file, type in keywords Lizard Bobson; system knows file is for Bobson account in work ‘folder’.

for every file extension, there is a systemwide set default editor and default viewer. If file opened for viewing, opened in view mode, in which viewing tools are available, editing tools generally disabled. If opened for editing, editing tools are made available and viewing tools are hidden/made less available.

Example: text editor viewing mode – up down left right arrows move view (up, down, page up, page down). character keystrokes do find for typed characters.

text editing mode – up down left right move input/editing cursor. keystrokes type text.

database/image app that allows one to drag images into it, have it automatically file as regular images (with tags as extra data in file) in file system based on user set fields. defaul fields simply image and image name and image type(jpeg, etc.), but can add any fields, any number of them, and create personal organization system.set what organization system is used for filing files. has folder style interface type deal, allowing images to be grouped togethor in folders, then subfolders, etc., but the folders can be created on the fly based on criteria. related images of the same thing can be grouped togethor.

to user, related information given togethor, but is really stored in most efficient means possible, best balance of factors such as access time (search, sort, etc), modification time (change data and append), new item time, storage space, number of accesses to storage media.

all instances of data in any format should be able to be looked at from ‘finder’ level and relatable

redundant and inconsistant data can be eliminated using spare cpu time during idle time

relatable in hierarchial type view, getting more specifically related as go deeper in hierarchy, very generally related near top.

search time reduced using hierarchy by eliminating items in unrelated branches: searching for a friend named Amy would search through a friends subdir before/instead of business partner dir.

file browser (like finder) has built-in/plug-in capabilities to read and work with basic document formats. Images would appear as thumbnails, with preferences, that can be easily viewed at full size in a self controlled slide show type thing by folder. Movies would be viewable full size in the browser as well. audio files would be listenable toable, including being able to leave them play while doing other browsing. Text files would be completely viewable, possible editable. PDF’s would be viewable. Other formats would have plugins available from the maker of the app that produces them.

Allows viewing of files while still maintaining a file-browser like appearance and functionality at all times.

Controls would be provide when necessary from an easily accessible location, such as at the top of the window or in a floating window that disappears with no mouse movement. Proper controls would appear for the proper file-type.

All files would be able to be given tags, including user created tags, that are simply data about the file for informative and searching use. For example mp3 tags would be editable from the browser, as well as JPEG EXIF data.

Files could be organized in multiple directory setups without the use of aliases or anything, just an additional centrally located database directory file. Each media type would or could be given its own database so that one could look at all images at once in the image database while still have those images grouped with related other media in the regular directory system. This could perhaps be automated, having all images automatically put into the image database, which would then be able to be queried by its tags to show categories or specific dates or what-have-you.

All controls would be easily navigable and accessible with the keyboard as well as with the mouse, allowing speed and flexibility. This would include at least the major preference settings.

The browser would be very customizable to fit most peoples needs and tastes.

The browser would be designed to be slim and fast, taking up as little disk space, memory, and processor power as possible.

It would also be very plug-inable, so that users who don’t want certain features could easily remove them to save resources. Plug-ins would be able to be developed by third parties, so that alternatives for each file-type or function could be provided. If someone doesn’t like, say, the regular image browser, they could remove it and install a third party one easily that would integrate with the browser.

/****** the following is sort of a reworded, newer, and a bit different version of the above *****/

The independent application that handles specific document types is generally no longer needed, in my opinion. All files can be handled from within a single application, allowing the difference in file types to not affect the similarity in content (one should be able to view both text files and images relating to a given subject without having to change applications).

Plug-ins would provide the capabilities for multiple file-types: a plugin would essentially be the application for viewing and editing a given file-type, but would be opened within the ‘finder’ instead of separately. Each plugin would be loaded when opened, and taken back out of memory when no longer needed, possibly a specified time after the last opening of that doc type, with the amount of time weighted based upon the frequency of opening that given doc type.

Each document would be stored in the database like an object of an inherited class in an object oriented programming language. Every file would have certain attributes, such as disk location, creation and modification dates, name, user, group, as well as functions, such as rename, modifyContent, view. These would be part of the ‘file’ class. General categories of files may have more attributes and functions than that: ex ‘media’ category may contain author, date media was created. The ‘media’ category would contain some specific file types, or perhaps more specific of categories, such as pictures, movies, music. Each specific file type, what would be the instances created in the database, would have the most specific attributes and functions. A photo might have attributes size, color profile, shutter speed, and functions resize, contrast. Each specific file type, like in any OO inherited object, would have all attributes and functions of the more general categories of file type in addition to its own.

With standard setting, the document by default is opened in viewing mode. In this mode, no changes can be made to the file. All commands are designed to aid in the viewing of the file. A certain command would enter editing mode (likewise in editing mode, a certain command would bring you to view mode). In editing mode, all commands are set-up for editing. As an example, for a text document, typing ‘apple’ might put ‘apple where the cursor is currently when editing, but live-search for that text when viewing (another entry has more on this).

If anyone is interested in helping me build such a thing, contact me at public@tobymackenzie.com. I have only a little programming experience and have done almost nothing towards creating this project. I plan to start by making an application for Mac OS X that is like any other application and doesn’t affect the finder or its database, instead having an additional database that is its own and working through/with the systems database.

related thought

folders are not really files. they are used only for organization, so would not exist if there was no organization. files containing your content are a different kind of file from the organizing folders.