MobileRead Forums - View Single Post

daubnet · 10-11-2011, 08:54 PM

A "document-centric application" is one where you open a file that you work on. It is not important that the file contains text.

Examples of document-centric applications:

Wordprocessors
Spreadsheets
Image Manipulation Applications

Common theme: The concept of where things are stored is simple. The program works with one file at any time (let's ignore the flawed MDI here), and the user decides which file they work on. The File menu pertains to that one file, being the current document.

Not every application is document centric, examples of non-document centric apps are:

process-managers (no files, whatsoever)
e-mail clients (storage is a database, which usually is never changed by the user)
file system explorers (yes, it works on files and folders, but not with its contents, so it never "open"s them)
Minesweeper

Common theme: A "File" menu either doesn't exist at all, or doesn't fulfill the same function as in a document-centric application. The File menu does not pertain to a current document. Some UI Guidelines even state when the File menu could be renamed.

IDEs, such as Eclipse, Qt Creator, Visual Studio or even Dreamweaver fall into a third category. They do not work on a single file, but on a number of files. So many in fact, that there are systems such as GIT to keep track of changes, which files are added, changed and removed. The differences are sometimes subtle, but nevertheless game changing:
I can open a C++ source file from the File menu, but I could also open the project file first, and then go to the linked C++ file from there, skipping any commend in the File menu. The file I'm editing will be the same, but in a totally different context. This context must be visualized and there must be commands to manipulate it.
Some IDEs create a new menu called "Project" to handle some of the additional management, some keep all in the File menu.
Either way, such systems need more advanced commands, a different menu structure, and have a steeper learning curve. The File menu mostly pertains to the current project, not to the actual file being edited, but it is usually a mix of both, which is a complex concept.

Even though an EPUB is a ZIP file with a number of files, those are all contained *within* the ZIP, similar to an ODF or DOCX. So it will be always one document that Sigil is working on. This allows us to stick with the simpler, document centric approach.

10-11-2011, 08:54 PM	#15
daubnet Member Posts: 18 Karma: 1314 Join Date: Sep 2011 Location: Hamburg, Germany Device: iPad	A "document-centric application" is one where you open a file that you work on. It is not important that the file contains text. Examples of document-centric applications: Wordprocessors Spreadsheets Image Manipulation Applications Common theme: The concept of where things are stored is simple. The program works with one file at any time (let's ignore the flawed MDI here), and the user decides which file they work on. The File menu pertains to that one file, being the current document. Not every application is document centric, examples of non-document centric apps are: process-managers (no files, whatsoever) e-mail clients (storage is a database, which usually is never changed by the user) file system explorers (yes, it works on files and folders, but not with its contents, so it never "open"s them) Minesweeper Common theme: A "File" menu either doesn't exist at all, or doesn't fulfill the same function as in a document-centric application. The File menu does not pertain to a current document. Some UI Guidelines even state when the File menu could be renamed. IDEs, such as Eclipse, Qt Creator, Visual Studio or even Dreamweaver fall into a third category. They do not work on a single file, but on a number of files. So many in fact, that there are systems such as GIT to keep track of changes, which files are added, changed and removed. The differences are sometimes subtle, but nevertheless game changing: I can open a C++ source file from the File menu, but I could also open the project file first, and then go to the linked C++ file from there, skipping any commend in the File menu. The file I'm editing will be the same, but in a totally different context. This context must be visualized and there must be commands to manipulate it. Some IDEs create a new menu called "Project" to handle some of the additional management, some keep all in the File menu. Either way, such systems need more advanced commands, a different menu structure, and have a steeper learning curve. The File menu mostly pertains to the current project, not to the actual file being edited, but it is usually a mix of both, which is a complex concept. Even though an EPUB is a ZIP file with a number of files, those are all contained within the ZIP, similar to an ODF or DOCX. So it will be always one document that Sigil is working on. This allows us to stick with the simpler, document centric approach.