Sorry... this is a long one. Jesse Ross wrote: > There are two "filetypes": > - Container (could also be seen as a Project, Folder, or Desktop) > - Content (could also be seen as a Document or File) > > Containers can hold Content and other Containers. Both Containers and > Content have two states: > - Active (could also be seen as Open or Maximized) > - Dormant (could also be seen as Closed or Minimized) > > Active Containers would consume the entire screen -- they would be like a > desktop. > Dormant Containers would act like icons whose image was a miniature of the > actual desktop. > > Active Content would consume as much of the screen as they needed for > editing/viewing. > Dormant Content would act just like an icon whose image was a miniature of > the actual content -- like a Preview in OS X. > > An Active Container would be equivalent to N.E.'s "squished" view. > Active Content would be equivalent to N.E.'s "scrollable" view.
That's not quite a correct assessment of my idea. I'll try to correlate my terms with yours. - "Active Content" - You: manually-sized. Me: Interactive (either manually-sized or full-screen). - "Active Container" - You: full-screen. Me: Interactive (either manually-sized or full-screen). In each case, the contents are "scrollable" -- there are scrollers, and child windows are shown at proper size. - "Dormant Content" - You: thumbnail. Me: either a thumbnail, or locked (an icon with a padlock, requiring security credentials to "open"). - "Dormant Container" - You: thumbnail. Me: either a thumbnail, or locked. The thumbnail case would have no scrollers, would show all windows (not just those in the visible scroll-area) scaled down to fit, and is what I described as a "squished" view. As you can see, I have treated "Active" and "Dormant" as properties of all windows, and a "Content" and a "Container" are just types of windows. Some key differences in our approaches: - My "thumbnail" windows are really just "dynamically-sized" windows and take up all available space (I called them "Presentation" windows in my last email). For example, for a DVD-player window, this would show the DVD continuing to play, and would use whatever real-estate was available. If there were no other windows open, the DVD player window would take up the whole screen. (Remember, my proposal has non-overlapping of windows: more below.) - Your model doesn't allow Active Content to go full-screen. I think that this functionality is important. - In your model, the Container automatically becomes full-screen when activated, whereas in mine there is an option of activating a Container without necessarily going to full-screen. I now think that neither of these is ideal (more below). > There are three possible methods I can think of for visualizing the > transition from Dormant Content to Active Content: > - Zooming: Launching Dormant Content simply zooms in on that piece of > Content, thus all Content around it would be zoomed in as well and either > be partially visible or off the edges of the screen. In my opinion, "zooming" should be restricted to converting a window from manually-sized to full-screen. When converting a window from "dynamically-sized" (dormant) to "manually-sized" (active), which is really what you are describing, the window should just size itself and move other windows out of the way. > - Stacking: Launching Dormant Content brings that Content to the front > and pushes other content behind: think of how Expose works. I think overlapping windows have historically been a huge mistake for many reasons, the main ones being: - Overlapping windows require additional constructs need to be introduced to allow access to the hidden windows (i.e. Windows Task Bar, Exposé, Window lists). Windows can get lost under the pile. - Overlapping windows can be confusing to look at. Even in OS X, with the drop-shadow, it is often hard to comprehend the mess of windows stacked on the screen. - Non-overlapping windows remove the need for a "proxy icon" such as in Mac OS X; since windows cannot overlap, the window itself can be dragged into other windows as an object. - Non-overlapping windows allow for a faster, simpler drawing implementation. - Etc... > - Split Screen introduces another mode and mental concept into our UI, > and greatly diminishes screen real estate. Agreed. Best to avoid introducing additional concepts when unnecessary. Before I describe how I address this issue in my model, your ideas have inspired a revision of mine: my scrollable, active, non-full-screen container is a bad idea, as it might result in an undesirable "nested scroller" situation (the non-full-screen container has a scroller, and windows within also have scrollers). However, I don't like the idea of an activated container necessarily becoming full-screen either; although better, it seems a little inflexible. Here is my revised version: - It is possible to "zoom into" any window, making it the full-screen window. - A container is a window. - All immediate child windows of a full-screen container are active (meaning that they are manually resizable). - All immediate child windows of any other container are dormant (meaning that they are either thumbnail or locked, thumbnail being the default). - A full-screen container has scrollers, whereas containers within do not have scrollers (they only contain dormant windows that scale to fit the container when it is manually resized; therefore, these containers don't need scrollers). - There are two ways to make a window active: (a) drag a window from a container into the full-screen container, or (b) zoom into a container, making it the new full-screen container and thus making all of its immediate child windows active. This strategy makes each non-full-screen container like a little resizable dock, containing scaled-down windows. Also, since dormant windows (inside the little containers) are no longer activated when clicked, it makes it easier to drag them around (i.e. by dragging anywhere on the dormant window). Now, finally, how the multiple-document-editing issue is addressed in my model: - There is only one key window. - All windows (including containers) that are direct children of the full-screen container are "active" (manually-sized). This means that there can be several active windows on the screen at once. - All windows within other visible containers are "dormant" (either thumbnail or locked). - Because windows can't overlap, resizing a window larger "pushes" other windows out of the way, and resizing a window smaller "pulls" adjacent windows inward. This provides split-pane functionality without needing split-panes. How does that sound?
