[jbosstools-issues] [JBoss JIRA] (JBIDE-10550) [UI][Usability] Streamline UI for server editor and all possible options

[Rob Stryker (JIRA)]

     [ https://issues.jboss.org/browse/JBIDE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Stryker updated JBIDE-10550:
--------------------------------

    Fix Version/s: 4.0.0.Alpha2
                       (was: 4.0.0.Alpha1)

    
> [UI][Usability] Streamline UI for server editor and all possible options
> ------------------------------------------------------------------------
>
>                 Key: JBIDE-10550
>                 URL: https://issues.jboss.org/browse/JBIDE-10550
>             Project: Tools (JBoss Tools)
>          Issue Type: Task
>          Components: JBossAS/Servers
>    Affects Versions: 3.3.0.M5
>            Reporter: Rob Stryker
>            Assignee: Rob Stryker
>             Fix For: 4.0.0.Alpha2
>
>         Attachments: JBIDE-10550_empty_editor.png, serverUIasProperties.png
>
>
> The Server Editor has often been called "too busy" with unrelated settings populating it in a rather disorganized fashion. Less-often used settings, such as which pollers to use, or manually setting ports, have often been suggested that they be hidden a bit so as not to distract users. 
> With several jiras open for adding additional settings (ex: expose management port?  or, for openshift, automatically git-add new files before commit?), simply throwing them into the Server Editor would only serve to clutter it further. A uniform UI with a real design and intuitive location for new settings should be created, with clear outlines for what belongs in the server editor (very little) vs what is a more advanced setting and can be hidden (though still not too far... user should not need to go 'DIG' to find it). 
> Currently, there are 4 key sections:  Pollers, Ports, Credentials, and "Behaviour" (or mode... local vs rse).  But, in recent builds, the "Behaviour" section has received several checkboxes that have more to do with launching, such as binding to all interfaces, or the server being remotely controlled and thus a dummy adapter. Other options, like the possibility of restarting a module on .class changes, have no obvious place to live, and, if added today, would most likely be added in the "Behaviour" section, which seems like it does not belong there.  Also, an option like exposing the management port on launch would probably similarly be placed in this section, bringing the number of options for "Behaviour" to 4. 
> This of course seems very wrong to me. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira