Well you know what they say, UX is like poetry, everyone thinks they are a poet just because they rhyme some words. Just kidding, no one says that except for me.
But in all seriousness, I think that UX professionals who do user testing and research are infinitely more qualified than engineers to determine what users want, even if your users are technical. Everyone has an opinion about UX but only some of those opinions are informed by research.
this.
Like @hlawatschek mentioned. For orcharhino installations we basically have an Ansible wrapper around the foreman-installer.
Documentation is also not tested very often, heck we even released few versions without noticing major issues with the quick start section of the manual.
The major problem of foreman_setup is that I am not interested in maintaining it, therefore it’s dying. I believe documentation is the answer to setting up Foreman for provisioning. And I see the “Get Started” site as just an interactive documentation.
The plugin only handles small portion of provisioning setup. It does not help at all with other aspects of installation. This plugin should have died years ago. And it’s essentially dead, we just still distribute it with Foreman. It does not even start in some versions.
I like it, if there was an easy way of bootstrapping it and it could even setup Foreman YUM/DEB repositories for the user, that would be such a nice workflow for newcomers and everybody evaluating Foreman.
How extensible is it? We should keep it simple but few more fields could be required in the future.
Honestly, I like the idea. It solves multiple things:
If open-sourcing is on the table at ATIX, then I think it is worth try. The best case scenario is this becomes the new standard for from-scratch deployments. The worst case is indeed that your codebase is open-sourced and the community don’t adopt it.
We would still provide the “traditional” installation via foreman-installer command and documentation, but this could be advertised as an option. Since we are working on new documentation set for Foreman, this could become new Quick Installation Guide (CLI installer or The Wizard - make your pick) while we would still offer Advanced Installation Guide (the current Satellite Installation which we are currently working on bringing upstream).
Our installer is basically a browser based wizzard/GUI that allows the user to set a few parameters that must be set by the user.
The GUI then writes these user parameters to a YAML file (answers.yaml) which then becomes the extra vars for an Ansible run.
In general this is as extensible as Ansible. If you want it to setup repositories for the user, add another Ansible role that does so. (See also: https://github.com/theforeman/foreman-ansible-modules/milestone/5)
Extensibility isn’t the problem. The problem is that we currently make lots and lots of orcharhino specific assumptions in our roles. Another problem is that we are sometimes using our Ansible roles to override what the Puppet from the foreman-installer call wants to do.
In order to get our installer Open Source ready for use with foreman, we would need to split our Ansible roles into separate ones providing general foreman functionality and orcharhino specifics respectively. This is not impossible but a significant chunk of work.
This would also likely result in an installer (at least initially) that does not fit everyone’s use case. For example we always install Katello. But I guess the whole point of this thread is providing something fairly opinionated.
Forgive me for resurrecting this thread, but I saw an interesting blog post called Why designing for open source can be so difficult and a lot of the problems and patterns pointed out in it do feel relatable on some level and touch on some of the topics brought up in this thread.
The case study linked in the article was interesting, and the hacker news comments comments too, with someone from the VLC team (I assume the media player) commenting:
Oh boy, we’re redesigning VLC interface those days, and does this article is spot on on numerous part we’ve seen.
- A lot of things are not-intuitive, and we’ve had to do basic UX and looking at our users to understand what the needs where (we don’t use telemetry/spying). And it took a lot of time…
- And yes, this requires to rethink some of the basics stuff for VLC usage.
- And the nerd-porn part is very true: we solved it with 3 layers of access. Simple usage should be direct, Advanced usage for normal users should be within 2 clicks, and Geek/Pro options can be further away.
And we will have options for different usage of VLC that will impact a bit the UI (but we’re making that as simple as possible, to not make the codebase too complex → more time)- Finally, a lot of things had to be decided without consensus, and that requires leadership that is not the usual way we work.
I can share some of the work, if some people care…
It was a good reminder for me that our problems are not unique and are shared across many other open-source teams! Its always interesting to hear how other teams approach them and if anyone does hear how problems similar to ours are being solved elsewhere please do share here or elsewhere on the forum 