Usability

Feature Wishlist

Posted Sun, 2006-08-13 15:25 by admin

This article was started by myself, but it was extended by our users when it was placed on our wiki. The development team will have to review and discuss all suggestions.

Multi-User

something similar to what Win2k does, where you try to do something and it says "you don't have permission to do that. If you are an admin, click here to enter the admin password for permission."
multiple users - One or many at a time? Security for many at a time?

New Kits

vector math library to use MMX/SSE/SSE2/3/4/5
What about having a synthesized speech kit. Applications would send text (possibly with special marks) to the kit. Particular languages could be available as plug-ins.
Voice recognition
Should we have help system? Pocket PC has very handy one, it's HTML-based. There's a folder somewhere, where your help files are (for example, StyledEdit.htm). When you have StyledEdit opened and you open help, it goes directly to the StyledEdit.htm file. When there's just an empty desktop and you open help, it goes to index (automatically updated links to files in help folder). So, whenever you install a program, the install script or package manager copies just one HTML file to the help folder. It's so easy to use, that OBOS should have it too. And there could be a simple search capability within the help files
synchronization kit - some sort of way to notify and automatically update subscribers when data changes
im kit
XML - possibly methods for BMessage to transform to and from XML, possibly a whole different kit
Encryption - a plug in architecture for encryption/decryption. Probably public/private key. With a key manager of some sort, so that it is easy for users. Also with a tie-in to the Mail Kit of some sort so that mail programs can quickly and easily encrypt and decrypt messages. Also a cache of public keys with methods to refresh them (via Networking Kit)
Database Kit - access for SQL databases will be a large sticking point to getting on the corporate desktop. The sooner the better. Look at SQLAlchemy for inspiration.
Fax support (kit?)
RPC (SOAP, XML, Web services etc.)
SpellCheckAPI
Reference kit (dictionaries, thesaurus)

Media/MIDI

a BSound class that adds effects? Mute, slide, reverb, echo, etc. All, again, as plug ins.
subtitles
audio tracks for different languages
interactive menus (e.g.: DVD)
support more sources (HTTP, CD/DVD, TV)
integrate Media and MIDI kits into one kit. there was an RFC at GlassElevator about this
DRM modules (with TPM support), so we can use iTunes and the other services. see gstreamer for an example of how to add support for this
take a look at Infopipes concept

Printing

Vastly improved printing is needed. Color management is huge, now, with digital photography. Additionally, more functionality is needed. Watermarks, more margin control, etc. All of those "extras" that you have on Windows and use once a year.

Device Kit

Why does serial port deserve a class but not BParallel? Or BAudioCD? Or BVideoCD? Or Scanners, Cameras, PDAs, etc? Every "thing" that you plug into your Haiku machine should have a class to access it.

Game Kit

Sprites, Backgrounds, collision handling, parallax, 3d, scrolling, tiling, AI, controllers (joysticks, etc) and more.
Translation Kit
How about 3D objects? Or vectors (structured drawing)? HTML read/write?

Mail Kit

public/private key encryption for email

UI

ditch menu bars for context menus only
we should go vector. And we should adopt SVG as our standard.
Dictionary of translated words, so that untranslated apps can be automatically (if imperfectly) translated.

How about being able to have a several applications using the same window, each one having its own tab? I believe there are UNIX window managers that do this though I've not tried them so I'm not sure how good it is in practice. I imagine there would be pros and cons.

Some GUI description language (XUL?) is a really nice thing to have in R2.

include a standard widget for toolbars, Some thinks I like about some toolbars:

drop-down buttons.
animated icons.
separators
options per toolbar - small icons, text under icon.
!!! configuration tool - add/remove button on the fly !!!
ability to collapse the menubar into a clickable icon for more screen space (maybe even into the tab?)

Additions to BBitmap - this class is really in need of a lot more "stuff". Think LeadTools for Windows - the ability to choose some area of the bitmap and apply transforms (plug ins). This has been done a dozen times for a dozen different art programs. Let's do it once more, possibly leveraging someone else's work and make it part of the OS.

BHTMLView - include JavaScript? External players? Use some existing framework?
How about an Outlook bar? Or a grid widget? Many new controls possible, look at other OSs. Graphs and charts
How about a BImageFilePanel? One that queries the device system for image yielding devices and has neat features like thumbnails, etc? Or a BSoundFilePanel that lets you play snippets before loading the whole file? Still-Image Acquisition & Moving-Image Acquisition
RAD / easy graphical GUI-creation toolkit
Color Management
Multiple monitor support
LayoutManager (already in the works for R1)
workspace sharing via network
investigate ZUI concepts

access embedded data (e.g.: email attachments) in-place
spatial data organization

look at Morphic/Tweak, Chalk (Slate's CLIM+Morphic combination)
replicant may run as separate process?
OpenBinder
scalable UI
gamma correction?

Localisation

This would be fantastic it would allow easy language localization of any part of OBOS (OS included) to a specific language and it would allow for users to have several languages available in is system in just one installation.

All higher layers of system should use some kind of localisation. This covers:

Language translation files for applications
Time and Date writing order/conventions
Currencies
Number spacing
Keyboards
Fonts ( BeOS default fonts are lacking some Latin European glyphs )
API/GUI should be able to fit different font sizes and string lengths (Example: Chinese has very big chars)
systemâ€“wide Unicode/UTF-8 is a must

Localization - this is probably the single most requested feature. And one of the biggest. Because this ties into so many other things. At minimum, we need to add currency, calendar, number widgets, phone number, address that tie in to the locale. Plus automatic translation support (i.e. translate phrases into current locale's language), resizeable, font independent widgets, right to left and top to bottom text, etc. There is a *huge* amount of work in doing this right. Layout management, too, so that resized widgets can flow properly.

Note: Axel Dörfler is already working on this in the OpenTracker repos.

Kernel & Drivers

ability to move processes from one machine to another (load balancing)
Anyway, a good thing to add is device feedback. This way drivers would be able to implement force-feedback for mice, for example.
A method for drivers to publish functionality in a standard way. It could be only metadata. It would allow querying to discover if certain functionality exists in the driver and/or the hardware
Power Management and other "special" laptop support
Bluetooth
FireWire
CardBus/PC Card
PCI Express
64-bit processors
Debugging via the kernel
RAID (hardware and software)
Hardwareâ€“accelerated OpenGL
EFI (UEFI 2.1)
Enhanced SpeedStep
WiFi (2200BG, 2915ABG, 3945ABG, PRISM?, USB adapters, ...)
Firewire
Intel graphics drivers
more file systems (NTFS r/w, UDF2.6+attrs r/w, ZFS, XFS?, EXT2/3FS?, ReiserFS?)
FS-independent indexing service (e.g.: Beagle), but might use FS index (if available) for faster queries
userland FS API

LDAP address book
IMAP
IMAP address book + calendar + notes [plug-in based backend]
WebDAV?
FTP
P2P with queries [BeShare?]

transactional VFS (see Windows Vista)
versioning VFS
FS ACLs
extend node monitoring to monitor all VFS calls

not only specific directories
allow for filters that can intercept and deny access (e.g.: virus scanners)

Network

ZeroConf / Rendezvous / uPnP

with support for add-ons: e.g., instant messengers could use ZeroConf to expert services to your friends

event-driven API (new device, configuration changed, (dis-)connected, etc.)
mobility-oriented

access important functions and profiles via Deskbar replicant
auto-recognition of profiles
update default printer and PPP connection
update timezone?

IPv6
WiFi with full encryption support (WEP, WPA, WPA2)
RADIUS client authentication
anonymizer modules (Tor, DNS translation, etc.)
NDIS wrapper
networked file system

BeMail

show all drafts in a list on the left
closing will auto-save your email. no need to save your work
unlimited undo history is stored for all drafts, so you can undo something even after having closed BeMail

Tracker

Not only does it offer a more efficient space, it enhances the usefulness of the OS by offering a place to stash information vital to the user. Some examples of replicants that could be of use would be a pulse like CPU histogram, a virtual workspace manager, a clock and calendar, controller for audio players, applications/script/folder shortcuts and a drive space monitor, to name a few. I'm sure others can come up with more. It would be left up to the user to decide what they want to display as a deskbar replicant, in what order they want them displayed and how they want it displayed.
what if "My Computer" opened into a mime type directory. You could either look at a type's subtypes OR look at the files with that mime type.
In the Tracker with an icon(or icons) highlighted, you decide to copy them to another directory. You simply right click, move the cursor over Copy To and you then proceed to find the directory you wish to copy them to. Now you find a few more files(we will use mp3s as an example) that you wish to copy to the same directory. You simply right click, move the cursor down to Copy To, but this time when the next menu forms their is an option at the top that says Most Recent or Recent. Moving to the right on this item shows you the last 5 or 10 directories that you have copied to. This functionality would be available from the Create Link, Copy To, and Move To popâ€“up menus.
integrate xcv ([1])
This could be implemented like this: when the appropriate file is highlighted, make Tracker extend its viewable area, like a drawer, and this drawer should work like R4's Container; attach a new replicant that can handle this file type. BeMail could be made a replicant, NetPositive already is (could be the handler for graphic files), SoundPlay also...
Folder backgrounds are stored as an attribute of the folder. Why can't we preview images by clicking once on them and have Tracker send them into the open folder's background attribute? For that matter, any type of data/media could be handled the same way. Video, audio - all that stuff. We can even have tracker do cool things like make a split pane to preview emails and text documents (any kind of document that we have a "tool" reader for - Gobe, Word, Abiword, etc.).
What about allowing "rules" for file management on the desktop, i.e. when files are dropped there.
rework queries and UI (categorization, time-slider/scroll-to field)

BFS

I think it would be useful to have attributes with both a name and an index: you could get the 6th attribute named "foo", for instance. This is useful because it lets you associate more than one value with a single attribute in a system-defined way. If we had an installer that tracked what libs an app depended on, it could place those in attributes and query for them, without worrying about separating the lib names with some kind of token. MP3s could have multiple authors. We could also give translators an attribute for what they translate, which would make this obvious to the user, *and* obviate the roster: the system would know where it was going. Currently, we have only one value for attributes which is very annoying with a Contact's email addresses: we use tricks like "Person:Email"="first@mail.com, second@othermail.com". This has to be changed. Think of BMessage: "Person.Email" gets an array of values: "Person.Email"[0] = first@mail.com "Person.Email"[1] = second@mail.com How this is handled with indices: the "Person.Email" index may simply contain multiple entries pointing to the same file.

Full text indexing.
versioning
maybe replace BFS with a DB (DR8, but much better)

Components

The micro solution consists of reverting to the computing roots of the D+F concept (data and functions, no programs). That is, the killer app for GE is that there is NO app. Your system consists of functions which the user invokes in which ever order they choose, and vendors ONLY provide functions. They no longer provide programs. The entire User Interface has to be changed to allow for an entire different concept of work flow. Let me repeat that one more time - a new work flow requires a change in the user interface (think fundamental change like the change from CLI to WIMP).

I connect the Cron component to the MediaPlayer object and boom - alarm clock. This is what OO was supposed to bring to coders. We are talking about bringing it to end users. Of course, just like, say, themes, there will be builders and there will be users. But what we are really talking about is making coding message based and more modularised. The idea of wrapping complex structures in one binary file & using special dev/apps tools to poke inside seems to be giving way to keeping 1 simple type in each file, & letting a folder keep it all together. Advantage is any suitable app can edit specific components. Apple used to use resource forks with ResEdit, now they want all to use the hidden folder approach. Much much easier on tool developers since you reuse what is already out there.

[ Note that the enlightenment foundation libraries ( http://www.enlightenment.org ) goes some way toward making this possible. Combinations of Embryo, Eet and Edje allows this level of customization through "themes" for a single application. ]

Lets make it cooler, you get your components, link them up Cortex style and save them as new processes. Imagine browsing through your Video directory and previewing the video using the folder's background as a screen. The icons maybe will become slightly transparent so that you can see the video a little clearer, but not much because it is - after all - just a preview to see if it's the right document.

Input Kit

fix the InputServerMethod issues.
I also have been thinking of moving Joysticks to the input_server.
allow users to determine the order in which input is passed to the InputServerFilters.
allow for system wide key bindings
MIME/Roster
File types are more human-readable: Document, Image, Video, etc. In our local database we store the MIME translations for those types. Multiple-inheritance is supported, too (Ogg would inherit from audio/ and video/, for example). Instead of specifying attributes for each format individually (MP3 has its own attribute set) the attributes are inherited from the supertype (Audio). Internally, the file types are stored as MIME. This allows for better OS-interoperability, backwards-compatibility, and more flexibility (we can change the inheritance structure of the whole type database and it will continue to work). But there is a problem with this model: global queries (Audio/*) would have to look for multiple MIME-types (application/ogg, audio/*, etc.). Nevertheless, it should be a step forward, usability-wise.
BClipBoard - ability to have multiple items on the clipboard

Translation Kit

meta-data (also for file attributes)
2D/3D vector graphics
documents (OpenDocument-based API?)
spreadsheets
databases?
viewers + editors API (like replicants)

Support Kit

Lots of new classes for here, too. There are numbers of useful little helper classes that we could all use... How about a pool allocator, as an example.

Other

User preferences USB stick (flash storage) - on boot/disk insertion, check to see if there is a removable volume mounted that has a home directory on it. If so, boot using this as home; allows visiting users to bring their preferences/apps/data with them. Basically a Haiku install minus the system on a flash drive/CD/whatever.
bundles
read-only base system (separate partition), read-write overlay system for additional apps, and mobile user profiles (see BSD-HALO)
collaboration services (multiple persons working on one document over the network )
download_server + API (does this make sense, at all???)
input profiles?? (mouse, keyboard, joystick?)
energy profiles

1 comment

Usability Improvements

Posted Sun, 2006-08-13 14:05 by admin

Usability Improvements

Haiku R1 should be polished and not suffer from BeOS' insufficiencies. If we release a half-baked OS our userbase will turn away.

This is a summary of many improvements discussed on the GE-list and elsewhere:

TODO for R1

rework window zooming as it often does not work as one would expect
add BTextView context-menu with "cut", "copy", "paste", "select all", "undo"
improve BTextView keyboard-navigation: move to next/previous word, paragraph, beginning/end of file
show the task switcher immediately upon hitting CTRL+TAB (seems to be an R5 bug which causes a too long delay)
remove unneeded preferences (menu settings, scrollbar style)
combine similar preferences apps (Appearance: UI+screen, Input Devices: mouse+keyboard+keymap, Media: audio+video+sounds, Networking: ppp+networking)
modify apps in the source tree to match modifier key functions for lists: Shift-click selects a range, CTRL-click toggles one item
parent menu items which don't have a message associated with them should not close the menu when clicked
demo apps are not needed by default. why is the clock replicant in the Applications menu? it's a demo! remove more unneeded apps and make sure all apps sit in the right category (apps vs prefs)
Tracker: all entries in the date column should have the same width and use the same formatting. no more mixed entries with "Friday" here and "Sat" there. use fixed-width font?
Tracker: use different cursors for "move" and "copy"
automatically remove deleted apps from FileTypes DB (it quickly blows up like the Windows registry)
highlight controls somehow when the mouse moves over them to indicate "clickability"
Deskbar should be able to reserve screen space for itself (zoomed windows don't take up that space)
Tracker: "Identify" action in context-menu should be hidden or moved somewhere else (if identification cannot be automated reliably)
Deskbar: all items should get a right-click context-menu
Tracker: remove "Clean Up" action. use a fixed, non-overlapping grid for icons (overlapping icons are evil)
auto-mount read-only media (at least CDs)
Tracker: add mouse cursors which indicate a "copy" or "move" operation on drag-n-drop

Ideas for R2

(needs more thought) rework mounting process: create auto-mount-points and always show all mountable volumes. unmounting should be replaced by unloading a complete device (CD, USB drive, etc.). show device icons on desktop. their contents are the mountable volumes. ??By default volumes are auto-unmounted when they not needed, anymore. To permanently keep a volume mounted you drag-n-drop it on the desktop (or maybe a folder?), so you have a permanent mount-point.??
magnetic screen corners (all windows docking to screen edges ala Winamp)
time should always be visible (never overlap Deskbar)
add screen scaling support (resolution-independent)
design all apps such that they show more information and less buttons
less top-menu items and more contextual actions (pop-up menus) and information
Tracker: when holding down some shortcut-button while clicking an item in the folder-browser context-menu the menu should not close, but open that item in the background (allows for multiple items to be opened)
add global shortcut support (open folders, apps, actions) ala SpicyKeys and improve keyboard navigation because experienced users are faster with keyboard
reduce number of servers (audio_server, media_server, media_addons_server, why not just media_server?)
is separation of Tracker and Deskbar needed? it's not that I could continue my work if only Deskbar crashes
Tracker: show size of selected files in current folder as little bubble-window next to mouse pointer (and hide it when mouse exits window frame, so I can quickly check multiple folders). maybe also show size of all files if we have enough space
Tracker: automatically adjust column-widths when window is resized (see Thunderbird)
Deskbar: too inaccessible. I rarely use it because it's always hidden by max-zoomed windows
where is the long-discussed simplified and more powerful one-click installer with a package manager and automatic package updates?
colors should be used more actively in system controls
search results (BTextView, etc.) should be marked within the scroll bar, so you can quickly scroll to other results (instead of clicking "next"/"prev" buttons)
mark location of a selection within the scroll bar (or allow for adding marks via scroll-bar?)
arrange workspaces and desktop as 2D space (navigate via ALT+arrows)?
Deskbar as clipboard (drag-n-drop anything on it)?

2 comments

Installer

Posted Sun, 2006-08-13 13:27 by wkornewald

Introduction

This RFC describes an installation concept that aims to be more natural to the end-user than current package-based installers. The idea behind this concept is to get rid of the whole installation process. The complete application, including its dependencies and data files, is a single self-contained executable (one app, one file). There is absolutely no installation process. Just run and you're done. Delete and it's uninstalled. Replace and you've upgraded.

The RFC is incomplete in that it doesn't describes all edge-cases. Also, it does not touch on how one obtains application packages or resolves dependencies. Repositories will handle this task, but their specification and usage should be part of a separate RFC.

The concept is based on bundles and packages which will be described from the end-user's point of view. Later we will get into a few implementation details.

Bundles

Installation

From the user's point of view, the bundle is the application. The application is executed when you double-click the bundle. Bundles must be self-contained. There are no installation scripts and no dependencies. Bundles must be location-independent, so the user can move them around wherever he wants. In other words, bundles are not installed; they run directly. On the first run, the user might have to agree to the application's license, though.

By default, the Deskbar queries all bundles on trusted volumes. The Deskbar provides a search interface for running applications and allows for maintaining a list of favorite applications which you can organize in a folder-like hierarchy. Additionally, a list of the most frequently used applications is shown (if possible, pure file viewers like ShowImage are not shown in that list). This is necessary because the number of found bundles might be much bigger than the number of applications the user actually works with.

Since all bundles are queried automatically (on trusted volumes) a first-time run isn't necessary to open a file with that application. Of course, the application marked as preferred in your Deskbar will take precedence.

Uninstallation

Bundles can be uninstalled by simply deleting the bundle file. When a bundle is deleted its data files and settings are automatically removed from the system when certain cleanup criteria apply (e.g., after 30 days or depending on available disk storage; also see the note below). This provides the possibility to undo the deletion without losing any settings and it is required for supporting upgrades. Removable media require special handling because otherwise unmounting would result in the system thinking the bundle got deleted (which might not be desired). The settings could, for example, be preserved for a much longer period or migrated to the volume the application resides on (this must be an explicit process, so no secret data gets exposed mistakenly).

Upgrades

Doing an upgrade (or downgrade) is as simple as replacing/overwriting the existing bundle file with a new version. Still, you can have multiple versions of the same application on your computer without any conflicts. In case of incompatibilities each application version gets a separate set of settings.

Multi-app bundles

Bundles may contain multiple applications like it might be the case for an office suite. There is either a default application that should be executed on double-click or the bundle behaves like a folder, showing all available applications when opened. The Deskbar menu will always expand a multi-app bundle as if it were a folder. The default application is highlighted in bold.

Packages

Packages are an advanced form of the BeOS .pkg files. They are primarily intended for system upgrades, application add-ons, and system components/extensions. The installation is a simple one-click process, similar to the Haiku R1 package installer. Unlike bundles, packages are allowed to have dependencies, even on bundles. Bundles and packages go hand in hand, but bundles are preferred and should be used whenever possible.

Only if advanced installation features are required and bundles cannot solve your problem in a clean way packages may be used.

Implementation details

Internally, bundles are compressed, read-only file system images. The compression method should be good enough, so people don't .zip the bundles (which destroys the no-install process).

Installs, uninstalls, and upgrades are atomic: they either succeed or fail. If the system crashes in the middle of an operation the system can revert changes and go back into a clean state. If dependencies are missing the system will search for them in the known repositories. When dependencies are not needed, anymore, they are cleaned up automatically.

Meta-Information in bundles and packages:

name
version
internal version (different between incompatible versions)
description
type: normal or system (appear in separate Deskbar sections)
target architecture
dependencies (only for packages)

Each application within a bundle gets its own entry:

name
description
keywords (e.g.: imaging, photo, image)
path (path of the binary application within the bundle)
ID (used to construct app's MIME type)
supported file types
capabilities: actions on file types (e.g.: Compress, Print, Reply, ...)
exported supplementaries (samples, docs, ...)

The ID follows this scheme:

TYPE.VENDOR.NAME

where TYPE is either of "app", "pkg", "add-on". You must follow the MIME-types RFC and not use slashes when creating your ID. The application's MIME type is generated by prepending "application/x-" to the ID. For example, BeMail would have the ID "app.HaikuInc.BeMail" and the MIME type "application/x-app.HaikuInc.BeMail".

Settings

Every bundle has an internal set of default settings. Only modifications to these default settings should be stored outside of the bundle. All bundle data is stored in two folders (one global, one per user) named by the application's ID. Their contents are categorized by the app's "internal version". All folders should be created on-demand: <ID>/v<internal-version>/

add-ons/
cache/
data/
settings/

Applications should be aware of duplicate add-ons in the global and per-user folders.

On upgrades between compatible versions your settings and add-ons are preserved. But if the internal version has changed the versions will behave like two totally separate applications. In that case it is the new app's responsibility to migrate settings from older versions. Add-ons cannot be migrated because they are only allowed to depend on one specific internal version number.

Attributes and queries

It's important that attributes are preserved over the Internet, so attributes are not stored as BFS-style meta-data, but integrated into the bundle (e.g., as a flattened BMessage). A dedicated index_server must be responsible for indexing bundle and package contents.

Inspection

You can inspect a bundle's contents by right-clicking it. Tracker will add an item that allows for navigating bundles as if they were folders. The mount-point is located in a temporary folder. The complete path to the binary (including the mount-point) is passed to the application in argv[0] (i.e.: it is actually executed from that location). Mounted bundles are not shown in Tracker's volume list.

Supplementaries

All exported supplementaries are added to Tracker/Deskbar's context-menu.

Tracker's info dialog

The dialog will be extended with a bundle's:

name and version
short and long description
access to all supplementaries

Command-line

All actions for managing bundles and packages are accessible from the command-line (possibly with advanced options). The application used to run a bundle is RunBundle. It automatically mounts the bundle, executes the application contained within, and unmounts the bundle when the application quits. The bundle is automatically installed if that is not the case, yet.

Possible future directions

With union-mounts (ala UnionFS) we can add limited dependency support to bundles without risking DLL-hell.

It should be possible to encrypt (e.g., for commercial apps) and sign (e.g., for system upgrades) bundles and packages.

The Fildirute concept could allow for mounting bundles in-place, so you can "cd" into a bundle from the command-line.

Against Directories

Posted Sun, 2004-02-15 07:00 by admin

Let me start out by saying that I am not "against" directories. It is more like "rethinking" directories. We have been talking on the Glass Elevator list about queries and how to make them more useful for some time now. There is a pretty broad consensus that we should try to bring more use of queries into R2 and beyond, that we should help the end user to use them far more than R5 does. While not a "killer app", queries can be, at the very least, an "attacker app": one of those little features that you really miss when you move to other operating systems. As a result of some serious consideration of what I know about how people use computers, it seems to me that, in many ways, directories may not make sense anymore. Beginning users struggle with them. Many people just don't use them--they fill their desktop with all of their files, or deposit everything into a large, flat "My Documents" folder. Advanced users become frustrated with them because they are forced into only one organizational method. They can't easily search for files except along the lines that they first organized their files.

If you take a graphic designer, for example, she might organize her files by client. If Client 1 wants a piece of stock clipart, she has three choices. One is to put her only copy of that clip art in that client's folder. This makes it difficult to find again. Her second choice is to keep it in a "stock" folder. This defeats her purposes in a few ways. One is that the folder for the client is no longer a "pick it up and go"--she needs to include some of the stock folder as well. Another is that she needs to remember what clip art a customer needs. A third is that this defeats the "last directory used" concept that most file requesters use--going automatically to the last folder that the user selected. The graphic designer is now forced to "ping pong" between two or more directories to complete her work. For these reasons, her third option, the link, was invented. There are two varieties of links: hard and soft. Soft links are much like references or shortcuts in Windows. They contain a path to the "real" filename. Hard links are a directory entry that points to the same data as another directory entry. Each has issues and difficulties. Links are "just different enough" that users need to be aware of them and consider them. For example, if our graphic artist wants to copy files to a CD, she may well need to tell the burning software to include the original file rather than the link (for soft links). Hard links cannot cross volumes: You can't make a hard link from Disk 1 to Disk 2. None of the options above, though, really make it feasible to ask questions like "which customers use clip art ABC?"

Directories have problems. We started by discussing all of the "cool things" we could do with queries. Add a tab to the file requester allowing you to do queries on the fly for the file that you are looking for and you have an easier system. We considered some ideas about what metadata should exist by default. The system provides filename, creation date, mod date, mime type, file size, etc. Additional possibilities include resolution (for images), MP3 tags, document type (for text files), etc.--anything that the system can reliably autogenerate. Users could add their own attributes to files to make it easier for them to find things. The core problem that this generates is that it is more work for the end user to do--assigning values. Then it hit me--if we convince end users to replace directories with attributes, it decreases their work and increases the system's usefulness.

This proposal was met with some resistance, because directories have been around a very long time and have solved organizational needs for a long time. I would like to discuss some of the objections here and react to them.

The first is stability--that directories are more stable and queries are more dynamic. That directories only change on command. I would respond that queries change in the same way as directories--when you want them to. If you choose a very dynamic parameter for your query (file size, for example, or last_mod_date), you will have folders that seem random. But that also makes sense--if you told a secretary that you want all of the newest memos on your desk at all times, you wouldn't expect the older ones to remain.

Another is identity--that directories provide one and only one clear path to each file. This is completely true. I don't see a lot of value in it, to be honest. In fact, with hard links, it is not true. BeOS doesn't have them, but Unixes that I have used do. It doesn't disturb me all that much when I see that there are a bunch of hard links to a file--that there is more than one way to get there.

The notion of hierarchy is brought up--that the hierarchy of files that a directory provides brings value. That queries are "opt-out" instead of "opt-in". Much of this depends on how you structure your queries. Sure, if you say "type=text" and nothing more, you get a lot of files. This is not radically different, though, from going to "My Documents" and saying "ls -R", recursively listing everything in your documents. If you instead say "type=text and project=obos-editorials", this is a lot like saying "ls -R 'My Documents/obos-editorials'". In a similar vein, the ability of the hierarchical tree to be divided into subtrees is brought up. You can do things like crawl the whole tree in pieces. This is more powerfully done with queries, though. Pick an attribute, divide up the possible results any way that you like, and run separate queries. So long as there is only one value associated with one attribute, this works well.

Queries make "drag and drop organization" a little bit more of a challenge. For example, if you organized your directories of music by genre then artist, you can assign an artist's music by dragging and dropping them into the genre of choice. That is a little tougher with queries--you would have to assign attributes. For a simple query (genre=blues) this is OK, but for (genre=blues or genre=jazz), this is harder. Various possibilities of a GUI to support this were discussed. The issue comes from the extra power of queries. You can make queries that you can't make with folders. One way to solve this solution is the same way that file permissions are handled in Windows--multiply select a bunch of files, assign a set of permissions and click OK.

Temporarily collecting files with queries is different than with directories. With a directory, I can drag and drop files into a temp directory, then copy the whole thing to a CD. With queries, you would need to assign the files a common attribute which does not get burned to the CD and gets removed as the files are burned. This is a bit of a shuffle around. It does have an advantage, though: The files still match their original queries. So, using backups for example, you could deal with backups by creating a "backed up" attribute of type datetime. Creating a new backup would be an easy query: "last_mod_date>backed_up". While the backup application is running, other applications could still access those files.

Finally, dealing with other filesystems (non-BFS) is more complex without directories. The whole directory API must exist to support interfaces with ext, ntfs, iso9660, udf, fat, FTP and others. Some method of manipulating directories must continue to exist as long as we must coexist. I understand and accept that. That doesn't mean that we need to allow others to dictate our future.

Queries have a vast number of advantages over unidirectional organizational schemes. They allow the users to ask questions in the way that makes sense to them. We have all seen classic Star Trek, in which they use the computer like a librarian--"Show me the files on Midas 5". That is the sort of power that a well built query system can bring to OBOS. The ability to work the way that you think at the moment, not the way that you (or a dev) thought of some time in the past.

Some vague ideas...

Posted Wed, 2002-10-16 05:00 by admin

Late at night, beating my brains for yet another newsletter article, my eyes were drawn to a notebook nearby my desk. This notebook contains my ideas that I brainstorm for future versions of OBOS. One of the complaints that people have is that R1 as we have defined it has no "future". It doesn't do anything beyond recreate what Be did and that we should aim higher for our first release. Interestingly enough, there is another, equal sized crowd of people who say that we are trying to do the impossible. In either case, R1 will be what it will be.

R2 and beyond are wide open, though. The following are some bullet items, some thoughts and ideas. Nothing solid, nothing developed, nothing thought through all the way, and certainly nothing promised. But some ideas, none the less...

XML - possibly methods for BMessage to transform to and from XML, possibly a whole different kit

Encryption - a plug in architecture for encryption/decryption. Probably public/private key. With a key manager of some sort, so that it is easy for users. Also with a tie-in to the Mail Kit of some sort so that mail programs can quickly and easily encrypt and decrypt messages. Also a cache of public keys with methods to refresh them (via Networking Kit)

In a similar vein, how about a BSound class that adds effects? Mute, slide, reverb, echo, etc. All, again, as plug ins.

Vastly improved printing is needed. Color management is huge, now, with digital photography. Additionally, more functionality is needed. Watermarks, more margin control, etc. All of those "extras" that you have on Windows and use once a year.

BHTMLView - I am not sure how this one should be done, but it is just obvious to everyone that we need one.

Localization - this is probably the single most requested feature. And one of the biggest. Because this ties into so many other things. At minimum, we need to add currency, calendar and number widgets that tie in to the locale. Plus automatic translation support (i.e. translate phrases into current locale's language), resizeable, font independent widgets, right to left and top to bottom text, etc. There is a *huge* amount of work in doing this right.

Game Kit - this kit needs a massive overhaul. Be never really took it seriously, but I do. Sprites, Backgrounds, collision handling, parallax, 3d, scrolling, tiling, AI, controllers (joysticks, etc) and more. This kit could almost be a career for someone.

IM Kit - I have heard rumours that this is being worked on. Possibly leverage that into our work. This kit could be useful in a dozen different apps. Tech support in your office suite? Inter-player chatting in games? More and more, we are all connected...

Device Kit - if there is any less cared for kit out there, I don't know what it is. Only BJoystick (which belongs in Input Kit) and BSerialPort remain. But why does serial port deserve a class but not BParallel? Or BAudioCD? Or BVideoCD? Or Scanners, Cameras, PDAs, etc? Every "thing" that you plug into your BeOS machine should have a class to access it. Banish ioctl()'s forever!

Tracker - A lot of code clean up to happen here. After that, I would like to experiment with different, alternate Trackers. The desktop metaphor doesn't work for everyone. I don't think that anything works for everyone. Let's make a couple or more different Trackers and see if they suit someone's needs.

BClipBoard - ability to have multiple items on the clipboard

Interface Kit - there are dozens of widgets missing from here. Not to mention all of the stuff we mentioned for internationalization. How about an Outlook bar? Or a grid widget? Lots of honest work to be had, here.

Storage Kit - I think that this is a little hard to use. Lots of times, I have found myself taking the long way around on some simple things. Maybe some better methods...

Support Kit - Lots of new classes for here, too. There are numbers of useful little helper classes that we could all use... How about a pool allocator, as an example.

DataBase Kit - access for SQL databases will be a large sticking point to getting on the corporate desktop. The sooner the better.

Translation Kit - Good kit, as far as it goes. How about 3D objects? Or vectors (structured drawing)? HTML read/write? Tons of good work to be done here, too.

A CD Writer application is a critical piece that we lack. And a scanning app. Simple stuff that come with other OS's.

Power Management and other "special" laptop support

A dock - every OS should have one of these.

As you can see, there are a ton of ideas. And I know that every one of you has some, too. These are just mine. R1 is a stepping stone. A place to start. Not a place to end up. I certainly don't intend to rest on my laurels when R1 is done. I intend to step it up another notch and build what Be didn't have time to finish.