I'm writing an application. This application allows the user to interactively analyze (and lightly modify) specific bundles of files. Each file in the bundle is individually editable by other applications; however, there is one file in the bundle (or the containing folder) that represents the bundle itself. My application allows the user to select one of these bundles and make investigations about the content of all files in the bundle.

Superficially this could be a document-centric application. Opening a 'bundle file' creates a new window representing the analysis on that bundle. Closing that window stops that analysis.

However, the window does not represent a single file, and not just in the nitty-gritty implementation sense. The user knows that there are many different files being looked at as a whole. Some modifications made during analysis will affect the content of individual files within the bundle. And it will be extremely unlikely that the user will ever want to create a new, empty bundle from my application. (There is no File->New.)

Should my application then be MDI? Modal, operating on a single bundle at a time?

Is this setup document-centric, or is there another term (or similar application paradigm) that applies?

More details on what the app does

Each 'bundle' of files in a folder actually represents something like a computer application. There are multiple files representing "presentations" (sort of like interactive PowerPoint), state machines, models, materials, images, scripts, and more.

Some of the analysis will be browsing the data specified in all these files. For example, each presentation has a hierarchy of models/groups/cameras/lights/etc., along with various 'slides' (variations), and animated values on those slides. Models reference their source asset file on disk, and have materials (which may be referencing a material files on disk).

Some use cases:

  1. Artist launches the app and opens a bundle to find out if there any image files in the directory that aren't being used, and asks to delete them.
  2. Artist wonders where in the hierarchies of many presentations a particular material file is being used. Artist looks at an inverted asset view (referenced files pointing to all the places where they are referenced from) to understand.
  3. Artist sees that there is a model that is never actually used, and deletes it from the hierarchy. The presentation file containing that hierarchy is dirtied.
  4. Artist looks at a map of all the unique color values being used throughout the project, and asks to replace three shades of orange with a new green color. Five presentation files are dirtied.
  5. Artist browses a tree view of all presentations/hierarchies and selects a particular element in the hierarchy. The application shows all the properties and their values on different slides. The artist picks a slide and then copies the value for the property.
  6. Artist uses the REPL to write script code to find all animation keyframes on the scale.x of objects inside a group and set any values of 0.5 to 0.4. One Presentation is dirtied.
  7. Artist selects a state in a state machine and adds an onenter action that causes a particular slide to be shown on a component in a presentation. The state machine is dirtied.

While not exhaustive, hopefully that helps inform the sort of tasks the application will perform on a bundle, and hopefully that helps clarify what windowing model is appropriate.

  • Not clear. "Some modifications made during analysis will affect the content of individual files within the bundle." Are they aware which document? Are they able to navigate to individual documents. And I would avoid the term document-centric as now have document-centric databases.
    – paparazzo
    Commented Sep 30, 2014 at 14:53
  • @Blam Yes, the user will generally know when they make a modification which file(s) in the bundle will be modified as a result. They will not be able to select individual files on disk directly, but there is in many cases a 1:1 correspondence between objects shown in the bundle and the file. (But not always; some files are referenced multiple times within a presentation.)
    – Phrogz
    Commented Sep 30, 2014 at 15:53
  • Then what could even be MDI if they don't access individual documents?
    – paparazzo
    Commented Sep 30, 2014 at 15:56
  • @Blam Multiple bundles. MDI is probably not the right term for what I was envisioning - more like multiple 'tabs', one for each bundle activity open.
    – Phrogz
    Commented Sep 30, 2014 at 17:02
  • You really need to work on problem statement. "Interactively analyze (and lightly modify) specific bundles of files." "Select one .." Implies one at a time. What type of analysis.
    – paparazzo
    Commented Sep 30, 2014 at 17:44

1 Answer 1


A Database, not a Document

Sounds like more of a database-type user interface, rather than a document-type user interface: instead of multiple database records per window, you have multiple files per window, where you display certain information about each file, in addition to aggregated information about whole bundle. This is especially the case if you represent each file as a series of discrete single-line text fields (editable or not) or other controls (checkboxes, dropdowns, spinners, etc.). It’s certainly the case if you allow users to add and remove individual files from the bundle from within the window. Perhaps you essentially need a file-manager-type UI (e.g., like Windows Explorer), which I consider to be a form of database UI.

The Database UI

If I got it right, then I’d recommend my standard database UI:

  • Each window is a large resizable modeless primary window with a full menu, not a dialog box. Dialogs (modal or modeless) are for a simple brief action. It sounds like your users will be doing multiple actions on the files and bundle.

  • Each window has one or more resizable, closable, scrollable panes, where each pane holds one class of data objects. In your case, that means one pane shows all the files, and one pane shows information about the bundle as a whole (I’d put the bundle pane to the left or on top the file pane to suggest to the user that it “contains” the files, like the way the folders are to the left of their contents in a file manager). You may have additional panes if the complexity of the app warrants it.

  • Each pane represents its data as a page, table, or graphic. For example, the information of a single file could fill the file pane, and the user “pages” through the pane with appropriate controls to see a different file. More likely, you want to show the files as a sortable table (filename, size, type, priority in analysis, etc.). Maybe you only need to show the name of file, so your “table” is simply a list. If you need to show the relations among files (maybe that’s what the analysis computes), then you may want to show a graphic representation of the files (e.g., a binary tree to represent file similarity).

  • The UI is SDI, rather than MDI. There is no “container” window for the primary windows. Each window replicates the menu/toolbar (if not an Apple Mac app). However, the File - Open command opens a new window for a bundle (to be selected) leaving the old window (and bundle) still on the screen (like recent versions of MS Word does for a document). This is in contrast to a design where Open replaces the contents of the current window with a different bundle (like MS Notepad does for a text file). SDI gives your users the most flexibility to work with multiple bundles (sizing and positioning the windows on the screen as desired), and avoids the confusion that the MDI’s “nested” windows can induce. To exit the app, the user must close all windows. Optionally, you can provide an Exit menu item on all windows, which automatically closes all windows of the app.

No “New”?

If you don’t need a File – New menu item, then simply omit it. However, if you don’t have a New command, how does the user create a new bundle from scratch? Perhaps the user can select one or more files from the file manager then right click to select a “Create a Bundle” menu item that your installer added to the context menu. That would be great for expert users, but it has mediocre discoverability. You may want to have a New command anyway that opens a new blank primary window but also automatically opens a file dialog on top of the primary window for the user to select the first file(s) to go into the bundle.

Document-Centric vs Document-Type

The UI should be “document-centric” in the sense that the user can double-click the bundle file in the file manager to open bundle in the app for viewing and modifying (as is convention, the user should also be able start the app from the Start button and select a bundle through the Open dialog, which can appear automatically). However, it’s not “document-type” like MS Word or Powerpoint are in the sense of trying to represent everything as a single cohesive virtual paper document (e.g., you can’t have scrollable panes within a paper document).

  • Thanks for all your suggestions. I am still considering to what degree this seems applicable. Regarding the 'new' issue, new bundles are created in a suite of other tools (each for the correct file type). This is a standalone tool that takes a broader view of the bundle and cross-file interactions.
    – Phrogz
    Commented Sep 30, 2014 at 22:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.