[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-ui-dev] Proposal - Context and pulldown menus affecting resources in Navigator view

David,
        Forgot to address one of your comments...

   - "Team" items better in File than in Edit.  I can see your point about
   these options  affect the entire resource, so File may be a better
   choice.  I was probably biased by precedents in other tools (i.e., Front
   Page) which place similar options Check In/Out options under Edit, but
   agree that File would be a better choice.
      In any case it seems like Team oriented items could be visible in all
   perspectives... although may end up disabled (like other File options
   like Save in the Help perspective) if they don't apply.

    Thanks,

           Lucinio Santos
           Web Tools Human-Computer Interaction
           Phone: (919) 543-4813  (tie: 3-4813) -  Fax: (919) 254-4147
           Internet: santosg@xxxxxxxxxx


"David Springgay/OTT/OTI" <David_Springgay@xxxxxxx>@eclipse.org on
11/30/2001 11:59:58 AM

Please respond to platform-ui-dev@xxxxxxxxxxx

Sent by:  platform-ui-dev-admin@xxxxxxxxxxx


To:   platform-ui-dev@xxxxxxxxxxx
cc:
Subject:  Re: [platform-ui-dev] Proposal - Context and pulldown menus
      affecting resources in Navigator view




Hi Lucinio,

Thanks for the input.  This is exactly what we are hoping to see.

Please see DS>




                    "Lucinio Santos"
                    <santosg@xxxxxxxxxx>           To:
platform-ui-dev@xxxxxxxxxxx
                    Sent by:                       cc:
                    platform-ui-dev-admin@e        Subject:
[platform-ui-dev] Proposal - Context and
                    clipse.org                     pulldown menus affecting
resources in Navigator view


                    11/30/01 10:37 AM
                    Please respond to
                    platform-ui-dev





The current organization and distribution of menu items among context and
pulldown menus involving resources in Navigator View is somewhat
unbalanced.  Consequently the context menus are  too long and seemingly
disorganized, while certain pulldown menus (Project) are underutilized,
thus keeping inconspicuous important items (e.g., Project properties)

     The following proposal addresses this issue:

   1- Reorganize the context menus: Better Grouping (according to semantics
   and usage)  and separators (see summary at the end).

   2- Remove "Open Perspective" from the context menu.  It doesn't belong
   here since this action is not "tied" to the selected resource/object
   (e.g., the opened perspective doesn't select the current resource
   automatically).  This is already in the "Perspective" pulldown.
   Although it could be argued that having it in the context menu provides
   a "shortcut", given the large number of items, we have to be selective
   and only place items in the context menu that pertain to the selected
   object/resource... to keep the context menu to a manageable size.

DS> Actually, the Open Perspective action in the navigator and the packages
view IS tied to the selection.  If you select a folder, and invoke Open
Perspective, the visible items within the new perspective are confined to
the contents of the folder.  This is an intentional way of scoping what you
see.

   3) Remove "Go To".  As above.   This is just a navigational shortcut we
   can do without (arguably) .   These GoTo operations are provided already
   in the Navigator toolbar (it's already close to a selected object, so
   there is not a lot of "mouse travel" gain anyway.

DS> This may be reasonable.  I might also suggest that Go To should be in
the pulldown menu for consistency.

   3- Open Project and Close Project are complementary and mutually
   exclusive.  One one is enabled the other one is disabled.  There is no
   need to have entries for both.  There should be a single "Open Project"
   or "Close Project" depending on the current state of the project.

DS> Good idea.

   4 -The Project pulldown is underutilized.  Currently contains a single
   item: Rebuild All. Some of the options exclusively presented in Context
   menus are quite important (Validate, Edit Deployment Descriptor, and
   Properties) and we should surface in the menu bar to make them more
   visible. Thus...
     The Project pulldown should include all the items currently present in
     context menu for a selected project.  If the resource selected is a
     File or (non-project) folder instead of a project, the Project
     pulldown would be populated with the items present in the context menu
     of the project to which the selected File or folder belongs to.

DS> I know there is some discussion that the name of the Project menu
should actually be changed to Workbench, or something similar, as this menu
doesn't pertain to the actual project, but pertains to everything in the
workbench, whether it is a project, projects, or stuff outside of the
resource workspace.  Some of your choices for the menu contents are
interesting.  Validate and Edit Deployment Descriptor are definitely WSAD
actions.  Would you contribute them using an action set?

        ... Except the following (context menu items) which would be placed
        under  other pulldowns (instead of in the Projects pulldown)
          - Clipboard items (Cut, Copy, Paste, Delete) would be placed in
          the Edit The following items currently present in context menu
          would be removed.  This items are already in the Edit pulldown
          - Team (Edit pulldown)
          - Replace with (Edit Pulldown)
          - Compare with (Edit Pulldown)
          - Go into (File pulldown)

DS> The team oriented items are very resource centric.  If you're in the
help perspective, would these items still be visible?  If so, how would you
resolve the resources which should be used for the team actions?

DS> My current thinking is that Eclipse is very context menu oriented.  In
some ways this is a reflection of the goals, to be an open, extensable
platform for tools.  This makes it very difficult to place resource
specific actions in the menus.  Instead, we have chosen to adopt a few
actions in the window menu which are generic (save, close, cut, copy,
paste) and universal.  The inclusion of domain specific actions in the
window may be misdirected.

        Context menu           Pulldown Menu

        New...            File (already there)
        OpenProject/Close Project   Project    (this only shows for
        projects. One entry for both)
        Open              File (this only shows for projects.  Already
        there)
        Refresh from Local          Project (if context menu of a Project)
        or File (if context menu of a File)
        Go into                File
        ----------------------------
        Copy              Edit (already there)
        Move              Edit (already there)
        Rename            Edit (already there)
        Delete            Edit (already there)
        ------------------------------
        Run on Server          Project
        Restart                Project ((this only shows for projects)
        _________________
        Run Validation         Project (this only shows for projects)
        Validate HTML syntax   Tools  (this only shows for files.  This is
        already in the Tools pulldown)
        ------------------------------
        Team              Edit
        Compare with           Edit
        Replace with           Edit
        _________________
        Properties             Project (if context menu of a Project) or
        File (if context menu of a File)

DS> In the table above, it looks like many of the actions in the Project
menu will only appear if a project is selected.  Is my interpretation
correct, or would they be enabled / disabled instead?  If the selection
controls their appearance, do you think the user will be disoriented when
the window menu changes dynamically, depending on the selection.  One of
the advantages now is that the window menu and toolbar are predictable, and
the context menu contains all of the actions for an object.

DS> Your choice of the edit menu for team items is interesting.  I actually
view these as file operations.  If you put them in the edit menu, wouldn't
the user be confused if they are actively editing a document?  Or do you
suggest that these actions come and go, depending on the active part within
the window.  We considered an approach like this, but decided it would
cause too much menu and toolbar flash.  Toolbar change in itself can lead
to relayout of the entire window.  I know one of our partners strongly
believes that the edit menu should always target the active editor,
regardless of the focus.

The principles here are:
          - Place all objects pertaining to a selected object in its
          context menu... meaningfully organized
          - Placed generic items having to do with projects in the Projects
          pulldown (in addition to the context menu)
          - Place generic items having to do with files i the File pulldown
          (in addition to the context menu)
          - Place "edit" type items in the Edit pulldown whether the object
          is a file or a project...



                  Lucinio Santos
                  Web Tools Human-Computer Interaction
                  Phone: (919) 543-4813  (tie: 3-4813) -  Fax: (919)
          254-4147
                  Internet: santosg@xxxxxxxxxx

_______________________________________________
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