Re: [platform-ui-dev] Editor management improvements

[Randy Hudson <hudsonr@xxxxxxxxxx>]

I strongly agree with Bob's comment:

"I find it equally likely that users use windows as a way to
organize their working set(s) into partially disjoint subsets"

I almost exclusively use Control+Shift+H to open files just for the purpose of getting a new WorkbenchWindow  (I had to change the default preference for this).  This gives me a quick way to close a bunch of open editors (ALT+F4).  And I use F4 as frequently as F3, for the purpose of getting a new WorkbenchWindow (I had to change F4 preference to open the Hierarchy perspective, not View).  So mulitple windows *IS* the way I partition my set of Editors, it's the way I group related "browsing" of code, and it is the way I close several Editors at once.  So I would argue that these problems are mostly solved.  I was a little disappointed when "morphing" the current perspective was removed, and when stacked perspectives started shared the same set of open Editors.  I might be convinced to work in a single window if each perspective had its own set of open Editors, giving me a quick way to t!
hrow out a "browsing session".

I also agree that the set of dirty editors is meaningless.  The users should be trying to keep this set empty.

I won't mention everything, but that doesn't mean I disagree with the rest.

-randy

"Bob Foster" <bob@xxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 09/24/2002 10:09 PM Please respond to platform-ui-dev

To:        <platform-ui-dev@xxxxxxxxxxx>         cc:                 Subject:        Re: [platform-ui-dev] Editor management improvements

Brilliant analysis in 1 and 2! On re-reading, my comments below seem rather
negative and I apologize but they are only possible because you have so
clearly outlined the main ideas.

A few of the Top Requirements don't seem to follow from the analysis:

> - Ability to view and define a working set of resources,
>   in a single action, that users will focus on for editing purpose

I don't even know what this means.

> - Ability to close all editors of a given type or close all editors that
>   are not a given type

This seems unmotivated. (What is an editor type anyway?) I have never had
the desire to close all my Java files while keeping my XML files open, and
nothing in the use cases suggest I would have.

> - Ability to select all clean editors or its compliment easily

I don't believe users make a sharp distinction in their working sets between
clean and dirty "editors". Would it be useful to be able to switch quickly
between dirty and all open editors? Maybe, but nothing about the use cases
tell me so.

> - Ability to see opened editors from all windows

I think even the "editors" terminology is inappropriate, and this item
highlights it as well as any. Users don't see the editor view as a
collection of open editors, they see it as a collection of open resources.
If the word "editor" is replaced with "resource" then I don't agree that
users want to see all opened resources from all windows. Why have seperate
windows? I find it equally likely that users use windows as a way to
organize their working set(s) into partially disjoint subsets.

> - Ability to close all but the current editor

A worthy feature, maybe, but it adds complexity to the UI for a marginal
benefit. And where does it come from?

Bob

From: <jinli@xxxxxxxxxx>
To: <platform-ui-dev@xxxxxxxxxxx>
Sent: Tuesday, September 24, 2002 8:09 PM
Subject: Re: [platform-ui-dev] Editor management improvements


> Here's the summary of platform-ui-dev postings and bug reports in
> Bugzilla (as of Sept. 10) related to editor management issues in Eclipse.
>
>
> Current Mechanism in Eclipse v2.0
> ---------------------------------
> For discussion purpose, I list the current ways one can switch between
> editors in Eclipse:
>     - Arrows next to the tabs (when there are many opened editors)
>     - Ctrl+F6 or Ctrl+Shift+F6 to see a list of opened editors and
>       switch between them
>     - "Switch to editor..." menu item (Ctrl+Shift+W) to bring up the
>       switch to editor dialog
>
> There are also proposed solutions:
>     - Editor view showing a list of opened editor (has working code)
>     - A drop-down list of all opened editors, via a control between
>       the arrows next to the tabs (no code yet)
>
> Sample competitor's solution:
>     - IDEA's IntelliJ editor: primitive back-track support
>       via Ctrl+Shift+Left/Right
>     - MS VisualStudio .NET: standard window navigation support
>
>
> Top Issues
> ----------
> After analyzing the platform-ui-dev postings and bug reports in Bugzilla,
> and thinking through the common editor use cases, I think the following
> are the two key user scenarios for editors in an IDE:
>
> 1. Understanding Code
>        Users are trying to understand the program by opening editors to
> browse / analyze the code. Users may open the editors explicitly (e.g. by
> double-clicking on an XML file), via the search result view, using F3 to
> inspect a type, and so on. There will be many editors opened in this user
> scenario. In this case, users will start with an initial set of files
(e.g.
> two Java files and one XML file) as their (initial) working set, but it
> will grow as users drilling down into the base classes, etc. However,
users
> won't be concerned with this expanding working set, since their main goal
> is to understand the program, they will browse / analyze as much code as
> required to accomplish the task. In their mind, the working set is still
> the initial set of files -- two Java files and one XML file.
>        The second case in this user scenario is debugging. Users will use
> the debugger to trace through the program flow, and have as many files
> opened as required to achieve their goal -- finding the bug / problem with
> their program. Their initial working set is their program code, everything
> else that are opened during the program execution support the debugging
> task.
>        For this scenario, users don't (and shouldn't) care how many
editors
> are opened, since they want to focus on their task -- understanding code.
> They need the capability to quickly drill-down and back-track through the
> program code they are browsing / analyzing.
>
>
> 2. Editing Code
>        Users are ready to focus on creating / modifying program code. They
> usually have a specific working set (which includes a set of resources,
not
> just Java files) to deal with. They want quick access to this working set
> and work with them. In this case, I think switching between opened editors
> is a red-herring. Users are probably not mentally concerned if certain
> files are opened or not, but they would just want to work with it (instead
> of wasting time to find out if the file is opened in an existing editor,
> and then switch to that particular editor).
>
>
> Although the above two scenarios are separate, however I think users are
> not always working in one or the other mode exclusively. There will be
> times when they need to (seamlessly) transition from understanding
> (scenario #1) to editing (scenario #2), and vice versa. This transition
may
> not be explicit or abrupt, so we need to support such transition smoothly.
>
>
> Top Requirements
> ----------------
> From the discussions above, I have identified the following top editor
> management requirements in Eclipse. Note: I refer to the term "working
> set" below loosely, I mean a collection of resources. However, this can be
> mapped to the Eclipse working set concept nicely.
>
> - Ability to drill down on resource / type information
> - Ability to back track from drill-down operations easily
> - Ability to navigate among opened editors quickly
> - Ability to view and define a working set of resources,
>   in a single action, that users will focus on for editing purpose
> - Ability to add a resource to the working set easily
> - Ability to see full path file name
> - Ability to apply actions (e.g. close) to opened resources that do not
>   belong to the user's working set (this means Eclipse needs to keep track
> of
>   the working set boundary for opened editors)
> - Ability to close multiple opened editors at once
> - Ability to save contents of multiple opened editors at once
> - Ability to switch between opened editors with only one hand using
>   accelarator keys
> - Ability to distinguish opened files via editor tabs under normal
>   circumstances
> - Ability to select all clean editors or its compliment easily
> - Ability to see opened editors from all windows
> - Ability to close all but the current editor
> - Ability to close all editors of a given type or close all editors that
>   are not a given type
>
>
>
> Jin Li
> IBM Canada Ltd.
> Internet: jinli@xxxxxxxxxx
>
>
>
>
>
>
>                       "Kevin Haaland"
>                       <Kevin_Haaland@xxxxxxx        To:
<platform-ui-dev@xxxxxxxxxxx>
>                       >                             cc:
>                       Sent by:                      Subject:
[platform-ui-dev] Editor management improvements
>                       platform-ui-dev-admin@

>                       eclipse.org
>
>
>                       2002-09-24 19:59
>                       Please respond to
>                       platform-ui-dev
>
>
>
>
>
> How eclipse manages editors has been a good source of defect reports,
> feature requests and newsgroup postings. In some cases developers
> have implemented alternative editor management strategies and have
> proposed that the eclipse platform team adopt it.  In order to
> properly assess the merits of the existing as well as proposed
> strategies it would be useful if we started with a shared
> understanding of the problem.
>
> A summary of platform-ui-dev postings and bug reports in Bugzilla (as of
> Sept. 10) related to editor management issues in Eclipse will be posted
> soon. The purpose is to identify the issues and requirements for editor
> management in eclipse so that we can use this as the reference to further
> discuss and refine the top issues and  requirements.  If you would like
> to add to or refine this analysis your feedback is welcome
>
> In order to reach closure quickly on this I propose that we end discussion
> on this by October 5'th. At this time we will use our shared understanding
> of the problem to decide what enhancements, if any, are needed
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev