To begin with, we had to decide what overall structure the file system would take: Do we stick with a traditional, hierarchical, name-based organization, or do we burn our bridges and attempt an attributed, database-style flat file system?

Although I favor hierarchical organization, I like to think that this bias is not without reason or experience: As a graduate CS student, I spent a great deal of time (and wrote a thesis) attempting to prove the concept of an attributed, flat file system in which every file access is expressed as a query. It's an attractive abstraction that, for example, provides a great deal of flexibility for grouping files. Although implementing this architecture wasn't a cake walk, trying to come up with a reasonable interface for the user was a minor nightmare. The biggest problem (for you, the file system user) is that in a flat, query-based system, you not only must specify what you want to see, you often must specify much or all of what you *don't* want to see; your choices are *too* open. In the end, I found that the familiar "restriction" of the traditional hierarchy—a limited number of "choices" (files and directories) within a single domain (names)—was a powerful tool in itself and one that we often take for granted.

The architecture of the new Be file system is a "best of both worlds" solution: The basic organization is hierarchical, but individual files can contain "attributes":

• Because it's hierarchical, the user should have no trouble navigating the file system, whether from a command line or through the Browser.

• The inclusion of attributes within files means that the system can also be accessed through queries.

The hierarchy needs no explanation. Attributes are described below.

Any file can have a collection of "extra information"—such as comments, information about where the file came from, keywords extracted from a document, and so on. These bits of information are called the file's "attributes." Each attribute is represented as a name/value pair, where the name acts as a key to the value. For example,

"Priority=Urgent"

is a an attribute whose name is "Priority" and whose value is "Urgent".

The name of an attribute is always a (short) text string. The value can be data of any type and any length.

If an attribute's value is a string, integer, or floating- point value -- in other words, if the value can be easily compared—you can ask that it be indexed. Values that can't be indexed are stored as raw byte streams on disk. We chose B+Trees as our indexing method for two principal reasons:

• B+Trees offer good performance with large numbers of items.

• The structure is well known and fairly well understood.

In addition to indexing, we also use B+Trees to store the contents of directories (a directory can actually be thought of as a type of index).

Each file is represented by a single "header block"; this is a disk block that contains information such as the time the file was created, when it was last modified, who owns it, and so on. Most importantly, the header can tell you the "primary data stream" of the file (this is the data that, in practice, we think of as being the file itself), and contains pointers to the file's attributes.

The default header information easily fits in a single disk block; the leftover block space is used to store "small" attributes directly. Typically, the most common attributes are stored in the header, so with one disk read (i.e., one look at the header itself) you get a bunch of useful information. The data for "indirect" attributes—attributes that spill out of the header block—become files themselves. In fact, the list of attributes associated with a single file is represented as a separate directory.

Header blocks are created dynamically—you don't have to specify up front how many files your disk can hold. Thus, you don't waste disk space on as-yet-unused headers. The downside to this approach is that the header blocks tend to be scattered around the disk, so access to a logically contiguous group of files (the files in a directory, for example) could send the disk into a searching frenzy. In practice, however, this doesn't really seem to be much of a problem.

A file's data is mapped to actual disk blocks ("data blocks") through a "data stream" structure. The structure contains a list of "block runs"; each block run specifies a starting block number and the number of blocks that are in the run (up to 65,535 blocks per run).

The blocks in a single run are always contiguous. However, the separate runs that make up a file aren't (if two runs happen to be contiguous, the file system will melt them into a single run). Since file-seeking sanity pleads for as much contiguity as possible, we pre-allocate some number of blocks automatically when a new run is asked for. This protects against file fragmentation when you perform a series of small writes (a single large write will be inherently contiguous). The size of the pre-allocation depends on the size of the file that you're writing to: The bigger the current size of the file, the greater the allocation.

The size of a single disk block is settable; the minimum size is 512 bytes, the maximum is 8k. You have to declare the size of your disk blocks when you initialize your disk.

An important new feature of the file system is "journaling." Journaling is a technique for preserving the integrity of on-disk data structures. The basic idea is that the disk blocks that are involved in a disk modification (file creation, deletion, write, and so on) are written to the disk's "journal" *before* they're actually written to their final resting places on the disk. This ensures that your disk's structures will be consistent even if you crash during a disk access:

• If you crash before the journal entry is written for a given operation then the operation will appear to have never happened.

• If you crash while data blocks are being written (that is, after the journal blocks have been written), the system will "replay" the journal entry when you reboot, and the aborted transactions will complete normally.

• If you were to crash after the data blocks were flushed, but before the journal entry was removed, the disk blocks would simply be re-written.

Journaling ensures integrity, but it can't guarantee that the file system will always be 100% up to date. That is, because disk blocks get buffered in memory, a crash may prevent some of them from making it to the journal. Thus, when you reboot you won't see the transactions that died in the cache. So, for example, that would mean that you might not see the last file that was created before a power failure—but your hard disk wouldn't be corrupted.

We're working day and night (really) to make the file system robust and fast. Hopefully, it will weather all the abuse that it's surely going to be subjected to. Our testing methodology includes running stress programs that create and delete many files, checking data integrity, and we have plans for our intern George to thrash the file system thoroughly with respect to multiprocessor access to the file system. We have already survived some 24-hour stress tests that created and deleted many hundreds of thousands of files and we plan on beating on the system until we'd trust it even with our own most treasured code and love letters.

And that brings to a close this 80,000 foot overview of the new Be file system.

All of an application's features should be visible as menu items or as buttons or other controls in windows or panels. Avoid implementing features that require users to hold down keys on the keyboard, use the secondary or tertiary mouse buttons, or type commands they have to remember: These techniques are great for shortcuts and they may become the preferred techniques for users experienced with an application, but you should allow users to perform each action in a more obvious way first.

Don't hide your application's features or users won't find them. Most users refer to documentation when they have a question. If users don't stumble on a feature, they won't think to look up the details in the documentation, no matter how clearly written it is.

Make every context clear: For example, it should be obvious what application every panel belongs to and what users can or should do in it. If a panel asks for information, make it clear what application is asking and what part of that application is affected.

Users find and remember features best if they perform them by directly manipulating objects on the screen—selecting tools, dragging objects to move or alter their attributes, and so on, rather then by selecting an object and then finding a command to perform a function. For example, it's easier and more natural-feeling for a user to rotate an object by dragging a handle, than by selecting the object and choosing a Rotate command or* entering settings in a panel.

Use similar UI for similar features, from application to application, and within an application. Users will often guess how to do something new if the UI looks and works like other UI they already know.

When inventing new UI, try to build on existing UI rather than invent from whole cloth: This gives users a leg up. And never create UI that behaves opposite to other well- known UI—that's an easy way to create a feature that users will trip on every time.

Make it obvious to users that what they're trying to do is working—or not working. Users are often unsure whether they're doing something right, or whether they've done it at all. Help them by providing feedback for each user action.

If a task will take more than a moment, open a status panel that shows the progress of the action. Put the user in control by providing the panel with a Cancel (and maybe a Pause) button. Users don't know how long a new activity will take, and often think actions that take longer than expected simply haven't started at all.

When users manipulate graphical controls, tools, and so on, show them that their actions are having an effect. If different parts of your application's UI react differently when clicked, dragged, or pressed, change the shape of the cursor or provide some other visual clue to inform users that something different will happen. For example, when a user selects an on-screen object, highlight it. It's also helpful to change the shape of the cursor when it's over editable text or when a modal tool is selected.

Provide feedback throughout the steps of dragging and dropping: Show that the object is selected for dragging, consider changing the cursor to provide a clue as to what action the drag-and-drop will perform, and highlight or in some other way indicate that the target of the drag-and-drop will receive the object when the mouse button is released.

When a user changes a setting, apply the new value immediately if possible. A second-best approach is to apply a setting when the user clicks a Set or Apply button. Avoid forcing users to restart an application to make a new setting take effect.

Users become confident in an application (and thus learn it more quickly) if they know they're in control—that is, if it performs only actions that a user initiates. Resist the temptation to help out users by changing information or the state of controls behind their backs. It's good to try to learn from a user's habits and remember preferred settings in panels, arrangements of windows, and other state they've set in the past, but don't "improve on" what the user has done if the reason isn't obvious and the improvement wouldn't be expected.

Maintain the state users set in windows even when they switch to other windows or applications. For example, if text is selected in a panel, don't unselect it when a user makes another window active; be sure the highlighting is restored when the panel is made active again.

The BeOS makes it easy for many applications to work simultaneously, and for each application to perform many tasks at once. Structure your application so that when activities in one area will take a while or must pause to request information from the user, activities in other areas of the application and in other applications continue uninterrupted.

Users make mistakes, but they shouldn't be punished for them. Try to alert users if their action risks losing data, and try to make it easy for them to undo actions they might regret.

The BeOS is a new world, with plenty of room to invent new ways of working and playing. Feel free to violate these UI guidelines if you have new ideas, but violate them for a deliberate and clear purpose. Users may come to love your new way to copy text, but if your new technique is only subtly or arbitrarily different than what they're used to in other applications, they'll simply be annoyed. Innovate boldly!