I’m a big proponent of creating an entirely new foreman (and katello) UI that uses patternfly 4 and addresses many of the problems of the current UI by offering opinionated workflows. We could even have the current UI be the “advanced mode” of this easy to use UI at least at first.
In my opinion, every time a user has to refer to the documentation it’s a failure of our UI but I’m glad it helped you (also welcome to the forum 
).
IMHO you need to start with designs how it would look like before making that decision, just “creating a new UI” won’t fix much - I would not start without a SME (and probably a dedicated UX designer) to design the ideal / practical workflows
IMHO you can start with a standalone UI to just to play with things (research experiment) but I totally agree you need to have a vision before building something that you intend to ship.
we have the lab features where you can easily create a brand new workflow
and the commit bar is lower, or in other words, I don’t think that its a
lack of ability with the UI vs what exactly should we build
I agree with both of you on this. Definitely need a dedicated designer and other stakeholders to collaborate on this.
I don’t quite follow the second sentence but I think we could use the lab features menu but that the code itself should live in an entirely new repository.
I’d be very surprised if outcome of any UX reserach is different than:
I’ll add to that:
Designing any other pages is IMHO wasting of both time and resources.
I would add as one of the worst workflows we should improve assigning templates to an operating system.
Especially annoying if you update a system which gets a new operatingsystem release. In this case it creates and assigns the new operating system to the host and makes redeployment impossible until you go to provisioning templates and assoziate them with the operating system and afterwards go to operating system and pick them as default, assign the mirror and added parameters.
So it is a bad workflow at all, and it would be even better if there was no need to do it at all because it could just automatically copy from the older version of the operating system. If adjustments are needed later it would still be easier in this way.
This has actually been mentioned several times in the last community survey, and fixing it is probably very low hanging fruit that doesn’t require a whole new UI - just a fairly small change to the existing forms.
For orcharhino installations we provide a web based installer.
The installer queries some data from the user and save the required information inside a yaml file.
The yaml file is used by an ansible playbook to do the installation and starts foreman-installer with all the needed options.
If you’re interested we could start open sourcing the installer and work together to improve it further.
Please have a look at some screenshots from the documentation:
https://docs.orcharhino.com/sources/installation_and_maintenance/installation_guide.html#main-installation-steps
For what it’s worth, kafo_wizards was started in 2014 but nobody picked it up and finished it. Now people are suggesting to build an entirely different system just to drive the installer. That doesn’t make sense to me because who is going to maintain that? I suspect if someone builds a getstarted.theforeman.org it’ll have the same issues as foreman_setup where things break and nobody notices for a long time because it’s not tested.
Earlier this week during a conversation it came up that installer might be a bad name for the project, especially in the Katello scenario where it is also used to upgrade. Installers are typically only used once so that sets the wrong expectation.
This is a good point, whether its docs or a tool to manage the installer or a combination of both, it should be tested or it will become outdated and unreliable. The testing effort and tools being worked on can help this effort.
I’ve often thought this, it feels weird to run an installer to update options and configurations after you’ve installed the software with it. I wonder if this has been a point of confusion for a lot of users, it wouldn’t surprise me to hear this. Maybe a name like foreman-configure would be better?
One thing to ask is how have other dev teams reduced the complexity in their applications? We could stand to not re-invent the wheel, so if there are proven paths out there we could benefit from learning from them.
Its not a perfect parallel, but I know React was a huge pain to set up with a webpack config before create-react-app was created. This opinionated layer made it much more approachable and easier to setup (I wouldn’t dream of starting a React app without it). You can also “detach” your application from being managed by it and then be on your own if you would like to own the configuration. So this is a good example of introducing an opinionated tool to help manage a complex setup.
How about starting with the design first and not worrying about the implementation until the design is figured out? I know this is hard for us engineers to do… but starting with what we would like our UI to look like without worrying about technology restrictions may be the best way to approach things. Once the design is finished, then the implementation can be discussed.
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 