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 
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.
2 Likes
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.
3 Likes
Huge 
to most of this, however just one small point
Please do ensure this reports back in the right way (I know you will, Iām just saying it publicly 
). 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
@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 
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.
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.
4 Likes
Following this discussion, I just ran across this article on the same subject:
3 Likes
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.
HTH,
Ohad
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.