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?
Dogfooding is an excellent reason not to use oomph if your users
aren't using it... But it's equally excellent reason to encourage
your users to use oomph if they can. Either option lets you
experience the same workflow as your users, but the latter may
offer an improved user experience for both you and your your users
-- but only if there's no blocking reason why they can't do so.
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.
--
|