[platform-ui-dev] File, Open Type & Search

[Greg_Adams@xxxxxxx]

Dan Kehn made the following suggestions. Here are my comments (see <greg>).



----------------------

FWIW, I'm concerned about the generalization of the Project menu.  The
VA/Smalltalk and VA/Java products had a general pulldown ("Tools") that
quickly became the dumping ground for every menu item that needed a home.

<greg> 
Agreed - must avoid a dumping ground. 
There was pressure leading up to 1.0 for a tools dumping ground and it was resisted.

ui component team
        It seems the UI component team needs to produce strict guidelines on the workbench menu and maybe even consider precluding its user to other plugins (UI contributors don't always follow guidance<g>)?
</greg>



I'd prefer to create more top-level menu pulldowns that push them together.

I don't see a big conceptual problem with "Build" and "Build All", since
they do in fact apply against one or more projects.  
<greg> 
Build vs. Build All are clear.  
From my perspective build vs, rebuild is more problematic. See separate post about this.
</greg>


The "Open Type" is an
instance that is less easily explained, and might be better relocated to
File (above New) under the submenu Open ("Open > Type...").  This gives you
a centralization based more on the action than a vague object (i.e.,
"Workbench" is basically synonomous with "YourWorld").

<greg>
* File > Open Type is an interesting suggestion.

* Do you think users will become confused and assume it means open the selected type?

* Some clients had asked for a File > Open and unfortunately there were two flavours of this
1) open a file that's in the workspace   -- would be consistent with open type...
2) open a file that's floating in the file system  -- seems inconsistent with this (and many other things)


</greg>


Perhaps this problem really stems from the mixture of action-based
pulldowns (File, Edit) and object-based pulldowns (Project), but we're kind
of stuck with it.  In a more OO approach, File would be renamed to
Workbench (or Workspace), since it is the conceptual anchorpoint.  

<greg> 
Disagree with this suggestion. It would displease most people on multiple platforms.
Also it's unclear why the file menu is not "oo".
</greg>

That
also resolves the question of search scope since "Workspace > Search..."
and "Project > Search..." is not ambigious.  Since I believe in
multilayered UIs, I would nonetheless include two radiobuttons ("Search
projects only" and "Search entire workspace" or similar wording) or
checkbox in the Search dialog that allows either type of search from either
choice location, the principal difference being its initial selection
state.

<greg>
Disagree.
* Having multiple operations for search is confusing. 
* What would it mean for a search toolbar operation.
*  At some point in the future it might make sense to have working sets - this would then require adding yet another operation for that won't play well. The current approach seems more feasible. It does a search, scopes it based on what you are doing but you can change it.
</greg>




Dan

PS: Parting comment on Preferences.  I always thought it was odd to find it
under "Window" of all places.  In the above scheme, it would move under the
pulldown formally known as File, since it has a global scope.
<greg>
I commented in a separate thread. It was getting tricky with so many issues in one email<g>
</greg>