Extension UI

Showing 1-2 of 2 messages
Extension UI Garth Braithwaite 5/21/12 3:10 PM
We had a discussion on the Guidelines for Extension UI.  I posted most of the changes we discussed in a deck available at http://garthdb.github.com/Presentations/extension_ui

The main area where there is still discussion are the guidelines for the application menus, having a large list of every sub menu available makes finding contextually relevant functionality tricky.  On the other hand, hiding and showing menu items depending on filetype hides extensions (and can be jarring if it changes from file to file).  Perhaps on a less important note, it is hard to guess all filetype extensions as well.  In the example of CakePHP template files (.ctp) all php functionality should be available to them.

Feel free to comment here, and we'll update the slides until we are ready to put a document together for the wiki.
Re: Extension UI Narciso (nj) Jaramillo 5/31/12 3:31 PM
Hey Garth,

Thanks for putting this together.

I think we had talked about a couple of things in the last meeting about this that aren't fully reflected in the slides yet:
  • On the Toolbars slide, I think we wanted to get rid of the first and third bullets, and emphasize the last two points--i.e., toolbars are only for users who really prefer them to keyboard commands or menus, and are always created/configured by users, never by extensions. I think the idea would be that any Command (i.e., functionality that can be executed by a menu item or keyboard shortcut) can be placed in a toolbar, and the extension developer can associate an icon with each Command, but would never explicitly create toolbars themselves.
  • For Panels, I proposed a strawman that panels are only for showing semi-permanent lists of things like search results, lint errors, breakpoints, etc., and that we should basically just have a single collapsible panel area at the bottom that can host multiple lists of results. In other words, you should never create UI-heavy panels for things like property inspectors, toolboxes, etc. This might be too restrictive, but I'd like to start with that and see what reaction we get. 
  • For Inline Editors, I think we need to figure out how to deal with limiting their height without messing up scrolling. I don't have any brilliant ideas here--I think the fact is that you probably will end up with nested scrollbars (on non-Lion systems) in some cases, and touch scrolling will need to deal with nested scrolling as well.