Design decisions

File save: explicit vs. automatic

We'll go with automatic save so there's one less thing to worry about (e.g. "Do you want to save before running this app?"). Noting that many users use "save" as a checkpoint to which they can revert by exiting the editor, we can provide similar behavior with an explicit checkpoint operation.

Implementation:

• No explicit save
• Provide a visual indicator to show whether the content has been saved
• Provide a visual indicator to show when the file is being saved (e.g. a "busy" icon in the corner)

Open editors: Browser tabs, tabbed pane, or single editor?

The Web IDE should support some type of multiple-document interface for editing a "working set" of files. Users will expect that editor state (e.g. scroll/cursor position, highlighting) is maintained in the working set throughout the session.

Options:

• Browser tab per editor: Using a separate browser tab per editor would give maximum separation (performance, cleanup), but it was felt this design forces an awkward navigation experience since the user must return to the "application" tab in order to open another file.
• Tabbed pane: This design improves the navigation experience. Possible risk in performance (several editors loaded in one window); effects can be partially managed by the user closing unused panes, but most users won't want to deal with this.
• Single editor: Requires another feature to handle the working set. Can use a recent files list for this purpose, but maintaining editor state requires that we either keep the editors loaded in the background or save the state as metadata. The former has a risk in performance and the user cannot easily force cleanup; the latter can be managed by the IDE (storing/retrieving state) and editors (reporting/receiving state).

We'll go with the single editor with managed state, so only one editor is loaded at a time. The IDE must manage the state; editors must be designed to participate.

File list: Tree or list w/ search?

The "right" view depends on the task. Tree views serve well for direct file system CRUD operations. When simply editing files, a list view may be more succinct. There are a few additional clues that can help with the list view:

• Directory information to distinguish between files of the same name (two-line entries: file name, directory)
• "Type" qualifier (e.g. "resource", "view", "page"); think of this as a logical grouping of the basic file list (e.g. according to app/resources, app/views, public)

As the file list gets longer, a filter/search function becomes important.

We'll go with a list view in the application editor. In fact, we'll offer different variations of the list view:

• "Recent files" with a search function across all the files (not just the recent files); a file selected from the search results is opened for editing and added to the recent list
• "All files" shows a list of all the files with a filter function that subsets the list
• "Logical" list organizes the files by type; types may be separated by "headings" that offer a button for creating new instances (e.g. "Resources [+]"; clicking on + opens a new-file dialog primed at app/resources)

A full tree view will be available in a separate "file explorer" view.

Structured workspaces vs. free-form application layout

"Workspaces" as a collection of applications provides certain value, including:

• Notion of a "working set"; opening a workspace brings all of its applications into view
• Logical grouping for metadata (e.g. compiler settings for all applications in the workspace)
• Some clarity in terms of the "peer resolve" behavior

Workspaces also have a cost in terms of added complexity in the UI, in that users must be able to deal with workspaces directly.

The suggestion is that general users might find workspaces to be restrictive or awkward. There are other ways to recover some of the above values while allowing free-form application layout (within a "sandbox" portion of the filesystem):

• "Working set" could be handled with tags
• We can debate about the desired scope of metadata. Workspace-scoped metadata isn't always what's wanted, either (e.g. SVN repository locations in Eclipse). For now, we'll deal with metadata at the IDE (eventually per user), application, and file; seems we can make do without workspaces here.
• "Peer resolves" will still be supported for applications in the same directory. Users can view details about resolves by opening the "dependency" activity pane; it's not necessary to show this information at the application-management UI.

Future topics

How might resolve evolve?

• add "lock" marker to prevent auto resolves
• add markers on files to indicate that there's a newer version available (local/remote)
• when pulling a dependency, should we hard-code the specific version into ivy.xml? prefer a "+" on the major version ==> requires that Zero be stable on APIs within a major version so that user's code wouldn't break
• Related topic - Workspaces - how do we live without them?