| Re: [platform-ui-dev] Oomph |
|
On 03/10/2016 08:56 AM, Stefan Xenos
wrote:
If you were to discover through dogfooding that there are workflow issues in setting up such a project and that a fix for it would be to either use Oomph or write something very much like it, shouldn't we recommend this practice to our users?Right, for Eclipse plugin projects, encouraging Oomph makes sense (and it's actually what's happening since many projects have set up Oomph configurations). What I consider as "my" users at the moment are Java Backend/Web developers (doing Java EE or Spring) and _javascript_/HTML5 developers; I don't think those are users I can influence on using Oomph. Other tools in that field (WebStorm, Atom, VSCode) do not have something It's already difficult to follow them, so thinking about driving them somewhere so IDE-specific seems like a challenge I do not even want to get started with ;) One of my current area of interest (focused on these Web dev personas but that I believe applies to the whole IDE) is that instead of providing documentation or Oomph config upfront to get started with, the IDE could provide more "discoverability". For example, when importing a project, if a nature is missing, discover what to install to support this nature, or if a file doesn't have an editor, discover what to install to get a relevant editor...; about preferences, those can already be shared by the .settings so if they're shared via SCM, there is no need for more IMHO; for target-platforms, I only came up with this idea: https://bugs.eclipse.org/bugs/show_bug.cgi?id=459100 at the moment, but actually this issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=159072 would be a simpler user experience. I believe that more shared/shareable project-specific settings and more "discoverability" are more generic ways to improve user experience than relying on provisioning mechanism a-la Oomph. -- |