The journey to Single Page Application

I like this idea, I enabled this and there’s currently nothing. I guess only Katello uses this?

This is a good idea, is there a plan to use the same approach for Foreman Core pages?

please take under consideration that many of our UX design is reusable (e.g. not specific to foreman) and its done as part of the patternfly project, meaning, that a component like the notification drawer is designed first in patternfly context (where also the discussion happen initially by UX designers and developers) and then reused by every consumer of the patternfly project. this allow us to both reuse the designs (sharing is caring) and to have more developer lift as other projects are working on patternfly and patternfly-react.

I do agree we must improve communications, this is a known issue and i believe folks are actively trying to improve this (e.g. I’m aware of a get together during the summer in TLV where one of the agenda points is how to improve, BTW: if community folks like to join I believe we will be happy to open it for wider audience, or record it).

if you have specific feedback, I suggest you start a new thread, and we will loop folks like @Roxanne_Hoover for further discussion…?

1 Like

When we implemented the first cut of the vertical nav, there was significant concern from the community. The resulting discussion was excellent and gave us a great result in our nav, which has been well received. I’d like to see more of this - and I think we are seeing it, as @boaz1337 showed in the recent thread.

I think we’re all served well if a design is seen in advance, before PR stage. I agree with @ohadlevy that it’s difficult to show off generic component development, but page design sounds perfect for RFC posts and demo content. More please :slight_smile:

It doesn’t have to be a discussion, but even a heads up announcement on the development section can be nice. This also goes for other things, like I do often with changes that people should be aware of (most recently HTTPS on Redmine). The big one I missed was about using webpack in plugins. We can now see how hard it is and how much of an issue it actually is in production mode. We should have looped in much more people early on. Discourse is a great async medium which allows us to catch up at our own pace.

1 Like

At the moment there’s only new subscription page from Katello. But the setting is in core and the menu item is open for all plugins. Anybody can use it.

My concern with patternfly is that not every component may fit us well. There are some very nice widgets, but I don’t like the design of all of them. My impression is, that folks feel that we have to use the components from patternfly when they are in there and that the design of the components is a final decision. I’d like to have more freedom, maybe custom styles in Foreman. The goal imho should be to use patternfly as a basis but not stick to it blindly. But maybe it’s just me who is feeling patronized. I can live with that, it’s no big deal. But maybe something that can be improved and explains why some people might be hesitant towards this change.


I apologies in advance if I sent the wrong message, Foreman is an open source project, lead by its community of users and developers, and its important that it stays that way, I personally hope everyone feel comfortable to speak their mind. the last thing I want, is that a valuable community members feel patronized.

History has shown, that in the past, we didn’t have the best UX, this was a combination of lack of resources (e.g. proper UX designers), developers who wanted to focus on UI or just disagreement on technology (it took over a year to align on weback/react for example). as part of discussions we had in the past, we agreed it was in our best interest to leverage an existing platform that specialized in UX, in the early days, it was mostly a theme for bootstrap (so we don’t look like any other website out there), later on more complex designs came along (e.g. vertical navigation) and finally we were able to actually share code by reusing patternfly-react.

Patternfly, being a project that started over 5 (or 6) years ago, suffer today from not adapting fast enough, both the fact that its based on bootstrap, and also that its build environment etc hasn’t been modernized (for example, its not possible to take a component and only that, one needs to inherit the entire css (and sadly some of the jquery code with it) regardless of which patterns are used.

Patternfly has recently started pf4, in lights of many improvement areas, that include concerns around design and implementation with developer happnies in mind as well (e.g. how easy is it to consume).

The reason I’m sharing all of this (and I’m not a PF developer, purely a “consumer”) is that I agree with you that PF is not perfect, and in a lot of areas needs to be improved. the key here is that we continuously communicate, either in patternfly github organization, or by leveraging folks that are part of both communities such as @Roxanne_Hoover .

In the past, when things were not agreed upon (see vertical nav) patternfly folks tried their best to reach out to the community and find a solution which is acceptable by all parties, there were a lot discussions, folks putting up demo machines and even a live hangout was done with multiple senior designers to raise concerns and collect feedback.

My hope is that we can improve the process, so everyone feels included in the conversation (hence the reason I started this thread and also asked @boaz1337 to share his plan here) we are a very large team of distributed developers, I’m confident this is not anyone patronizing rather simply that we communicate too late or too little in the process.

We are aware of the challenges around communications, and trying to take active measures to improve it, there is going to be a small conference during August for UI developers and designers who work on Foreman, @TimoGoebel it would be my pleasure to have you if you can join us.

Please keep the feedback coming, I think this is really a great conversation to have.


Huge :+1: to most of this, however just one small point :slight_smile:

Please do ensure this reports back in the right way (I know you will, I’m just saying it publicly :ok_hand:). Meetups are a great way to spur innovation as ideas can be rapidly discussed and/or prototyped - anyone whos been to an in-person hackday (on any project) will have experienced this. However, they are a terrible way to make decisions as they are, by definition, exclusive - not everyone can attend. So long as the attendees are all aware that the goal is to generate ideas and possible ways forward, which can then be presented to the rest of the community, then this meetup is great news for our UI :slight_smile:

@boaz1337 has done it right with the design thread (although I’d argue it could be under RFCs, but details…) as this has not only attracted discussion on the design itself but also brought attention back to this thread, which has been largely positive I think. Let’s have more such threads coming out of the August meeting - and if you want live streaming from the event, let me know :wink:

Lively UX discussion, I love it!

I agree that not all components are perfect because of both conscious and unconscious decisions. That said PatternFly is an open community and capable of change and adaptation. Whenever we have previously run into components that don’t fit our needs I encouraged that we try and submit back up to PatternFly. I’m happy to help that process in anyway I can.

In regards to more communication (A+ suggestion) - I think most are aware but I would check into the PF React Community meetings which happen very regularly (usually monthly) and are recorded. There is also the PF slack channel.

For me, I will do my best to share more information. For example: Next week we will be demo’ing the new Audits page designs. Afterward we will be sure to post all the designs to this forum for additional feedback.

1 Like

@ohadlevy, thanks for your feedback on this. I really appreciate it. I just want to answer briefly so that we can all focus on getting things done and not spend too much time in discussions.

I really appreciate the work done on the UX side. We can definitely improve both the workflows and the visual appearance of Foreman and it’s plugins. I believe the workflows are actually the important parts that we should focus on.
To be honest I don’t remember how we as a project decided to move from bootstrap to patternfly and if any alternatives were considered. Important is, that we stick to it now to not cause any agitation for the users. If we implement new screens as a single page app, I’d try to stick to the current look and feel of Foreman and not introduce new components that don’t fit the rest of the application. What I mean is: A table in Foreman should look the same on all pages. A button should not look any different just because we migrated the page to a single page app. Or we’re going to have the same situation as we have with katello now. UI’s that don’t fit together. That’s what makes the difference in my opinion.
Let’s take a look at the host view page for example. I’d suggest to get rid of the two charts that almost fill the whole screen and I believe nobody cares about. If we add some cards and give the tabs more space, it’ll be a great improvement. And we even don’t need react or patternfly 4 for that.
I try to look at this from a customer’s perspective. A customer doesn’t care what UI framework is used. The software has to get the job done and provide an overview of what’s going on in the whole infrastructure.

Just my 2 cents.

Patternfly next looks like it’s all new, so I’d prefer to wait for it to mature before we migrate Foreman to patternfly 4 (if we do). The documentation definitely looks way better then pf3. And I think I like the design ideas. Looking forward to seeing what’s next. I love patternfly 3’s list view, especially with status icons. I hope patternfly 4 will have something similar. :slight_smile:

I’d love to come but I can’t make any promises, yet.

Yep, it shows that people care and Foreman is important to them.


Following this discussion, I just ran across this article on the same subject:


Highly recommended reading, it kinda explains all I am trying to articulate here but in much more nicer form. I don’t feel that SPA was justified enough for our case, at least I am not sold at all.

GraphQL or SPA Rehydration are super-smart solutions to very complex problems. But what about if, instead of trying to find a solution, you put yourself in a situation where those problems don’t exist? That’s problem restatement at work.

I agree with you,.

I still not sure that I understand what it is that we really trying to solve here.
While SPA have amazing UX, it has so much pain in implement it properly, and it is very easy to get lost, and do a lot of mistakes.

The effort is way to complex in my opinion, and I do not see the benefits here for the massive rewrite.

As I wrote above, I have a lot of experience making SPA since around 2006, when I needed to write my own libraries because even jQuery did not exists, but I used “ajax” (not just the sockets, but only XML parsing and other stuff from it).

When you have on-demand heavy information application, or heavy usage with many changes that effect the entire system right away, I can see how SPA helps a lot, but I do not see it in foreman.

That is, while foreman should know when to re-load some information again, it does not really matter if I render a web component, JSX, or just erb, while the content is loaded when needed and populated.

While I also think going all the way SPA doesn’t make that much sense given the complexity right now & the rewrite, I still think there is a ton of value on using React for our UI, like being able to reuse Patternfly tested components for example.

In some pages like the Job invocation info page, or anything tasks related, I can see how it could make sense. Like on the dashboard, etc…

1 Like

Out of curiosity, is React = SPA or can it be used also with regular RoR or with Turbolinks?

Lukas… we are using react since 1.14 (Oct 2016 - details) , clearly it works with RoR and turbolinks.

And when we started playing around with SPA then?

As I understand it we’re still only talking about a SPA. A lot of the current UI work would allow us to move to a SPA in the future, but AFAIK nothing has been decided.

please re-read the beginning of the thread.

Foreman is not SPA today, the purpose of this thread is if we should set a long term goal for foreman to migrate to a SPA.

I’ll try to summarize my response from the various posts before (hopefully I didn’t miss anything).

let me start with the end, I don’t assume we will rewrite foreman UI.
I also don’t assume we would rewrite all of Katello’s angular based UI.
thats a lot of work, for very little value, and virtually bring nothing but new bugs to our users.
I do however, see us, investing in various areas, which by the end - could be considered a kind of SPA.

when we started this initiative 2 years ago, we simply didn’t have the right tools to implement features proparly, I remember @Ori_Rabin @tbrisker and others struggling improving parameters UI, work that was suppose to take 2 months, end up taking 6 months, and even then, we have implemented only about 50% of what we want to achieve. (as the amount of incoming bugs was simply too high).

we reviewed and agreed on technology stack, which allow us to address many (if not all) of the issues we were having in the past, we had to solve some unique problems due to the fact that we were keeping compatibility with RoR and rails engines (plugins) which is not a common problem across the industry (yet?).

after being able to implement and test new UI work, we agreed to align on UI architecture called flux using redux, in the process we continued participating and contributing to the patternfly-react community, where a lot of other patternfly based project developers work and contribute to.

over time, we have seen, that maintain a react based code base, where the UI is mixed with traditional server side rendering, required a lot of work, things like turbolinks many times generated unexpected bugs etc.

Going forward, with performance and maintainability in mind, I suggested in the beginning of the thread, that we will switch the main UI (e.g. top bar, vertical menu and login screens) to react and eventually to the client. this would allow us to control routing from within the client (when applicable), and would allow us to serve pages faster (as we can get html responses without rails layout or by using js generated ui) and to store state that doesn’t get removed (as you don’t actually do full page reloads).

secondary to that, it would be nice to establish websockets for faster updates (to avoid continuing pulling) but that’s secondary and discussed to some degree on the memcache/redis thread.


I wouldn’t mind a real SPA. Mixing the stacks (ERB, turbolinks, jquery, react, redux) is creating a patchwork. I suspect that Bug #24176: Smart proxy delete + recreate leads to 404 - Foreman is a result of this and I would be surprised if we don’t see more of these kind of issues.

Over time I’m leaning more and more to a pure JS frontend that only uses the API. It does mean a plugin might require changes in many projects:

UI plugin (JS) <=> API plugin (Rails engine) <=> Smart Proxy plugin <=> Actual backend service.

This is not bad per se, but we should be careful not to widen the stack too much so it’s still doable for most developers to fully write their own plugin stack.