Well put. Many modern technologies have the “hello world” problem. They work like a charm on small CRUD projects, but things start to screw up very quickly. Let’s be honest: Foreman is a beast. We are very large Rails project and we had to workaround dozens of things in 12 years old Rails codebase already. I am little bit worried here, that’s why I am actually against small evolution in favor of fully working prototype (including packaging, deployment, installation).
Software projects failure is high, this is no news in our domain. No matter how I’d love to see a single stack that’s fun to work with for everyone, if SPA fails I’d rather see a prototype failing rather than Foreman in production deployments. Every hour spent on reinventing wheel could be spent working on actual pains our users have. And we have lots of them: http://projects.theforeman.org/projects/foreman/issues
It’s more complex then that, sometimes it’s good to have that information, and sometimes it’s a bug, and it’s not a trivial thing to know what and when, and what to do on each case.
As you and many others here knows (about the subject I’m writing in my comment), I have feeling need to explain that I just trying to explain my point of view, I know that you know this one already
You have something called PATH_INFO. it’s a hack that dynamic scripting created, and web servers followed.
For example /index.php/a/b/c/d is a path info after the index.php (a very common in blogs for example).
Or even /host/1 that we are using in foreman is also a PATH_INFO.
When requesting a path from a web server, if there is a something for it to execute on that path, the server will give that something the ability to decide what to do, if the request is a static content, the server will return that content, and if the server does not understand what it is, there will be either 404 or other return codes based on what is wrong.
All of the client side routers are riding on a fact that the server will not do anything from the given path, and most of them are triggered on the 404 error, to understand that it’s their turn to do something.
The other way of doing it, is to ride on the fragment of the URL (that is the # char, aka anchor name in HTML). It is done on the client side, and never requested by the server, and it is handled by the “history” API, and URL object.
Please remember, you must have a server in order to do even the simplest bootstrapping, and most UI routers “ride” on the fact that the server will return something that they can capture and do.
While I disagree about your view on unit tests usefulness and dropping policy, I definitely agree with responsibility. It’s not just sending code. To your list
It’s slightly more nuanced than that. Unit tests quickly tell you if something broke with a strong indication of exactly where it went wrong. That can be useful. It doesn’t show you when a complicated interaction of various components breaks. end-to-end tests do. You need both. Dropping unit tests sounds like a bad idea because it makes refactoring much more uncertain. They provide guarantees about a units function.
That said, I fully agree that we need black box end-to-end tests. The whole stack is complicated and has many edge cases. It’s important (senior) developers understand what moving parts we have in the whole stack so they know what various changes affect.
Sorry to bring this to the attention, but there was a good discussion here but I don’t see many conclusions made. The RM issue tracker have few items associated but I just stumbled upon another thread Move “Hardware model” page to React and it looks like this is happening.
One of my concerns is that we move all the simple pages to React and then we can hit the wall called New/Edit host form. Is the most challenging form somewhere near top on the TODO list? If not, could we consider bumping it higher? Perhaps after 1.19 is branched, this could be THE feature for 2.0.
I think it’s okay to migrate two-three pages as a test, but then let’s focus of the challenges. The worst thing possible is that we migrate all of our app except New Host/Hostgroup. It can be a technical challenge, prioritization or lack of resources - it all happened before to other teams. We also want to avoid learning by doing, we want to do the challenging part first the hard way and then the rest should be piece of cake.
Doesn’t it make more sense to have a new design for host pages besides blindly copying them?
the thought process behind moving simple pages (such as hardware models, or architectures) is to:
have a complete page examples, folks have been asking for example to copy paste from, and as long as we just do small components (like the notification drawer, breadcrumb switcher etc) we limit future development to the current rails approach when creating new complete pages.
we wanted to be able to start creating higher reusable elements so we can look into things like routing concepts etc, so that would mean we need to write at least a few simple pages (as it would speed up our ability to deliver in the mid term future).
I’d rather see us creating those components on paper and prototyping them separately and applying them onto New Host/Hostgroup first when they are ready to be used. My yesterday experience of current status of Repositories page in Katello which is undergoing new React design was not the best and I wonder if we will be rushing in patches after 1.19 freeze to fix UX issues.
This has something to do with my other concern: I am not comfortable with using Foreman as UX sandbox. This can be done separately, prototyping UX outside of target application is nothing uncommon. If this was some orchestration change, that would be challenging but this is I believe doable.
We already spent some time doing UX designs I believe, why not to take natural approach of prototyping them first, showing it to us where we can discuss these. Merge and fix later is not the best approach for UX IMHO. Let’s be careful, UX is something that everyone experience, comment and have feelings and opinions about.
When we are missing a component, e.g. for search auto completer, we developed the type ahead component, the same for other things like dual pane, notification drawer etc.
We are finally in a point it make sense to combine them in a single screen, to add more logic (above how it looks as behave as a unit) to how routing works, permissions etc.
I do agree with you that the subscription page was rushed, and took a few shortcuts, we should avoid that in the future.
We’re not doing it outside of the application, but there’s a “Labs” menu that you can enable in settings where the new pages are supposed to live during development. AFAIR the new repos page was there for some time and it was also demoed while still being on the labs page.
Then why I have no idea? Can we please start doing some noise around this? When there is a new component, let’s start a thread on our community forums where we can discuss. Demos are simply not enough IMHO, this is pretty sensitive work, everyone is exposed to UI.
Frankly, I watched all demos in Foreman core history and I don’t remember much about incoming React components. I am pretty sure JS/UX/UI guys are doing tremendous amount of good work, the problem communication. There is an improvement already (Hardware model thread) but I’d like to see more on the PatternFly React level. It can be as simple as “here is new date picker, tell us what you think” and I am good.
When a page UI rewrite PR is filed, it deserves more attention than regular one and perhaps a separate thread on our site because our users don’t regularly do reviews on UI PRs but yet they want to be able to raise voice. I miss our “users” forum a bit which was turned into Support category, this should be probably more user-facing discussion.
There are few examples of components which I’d like to discuss:
the new breadcrumb with small menu (I don’t even know name for this)
notification drawer
possibly others (I have no idea what components were added because of Foreman)
It’s not that I have critical comments but rather to have an opportunity (and in right time not when things are done and merged and are in “yeah file a bug” state). Please don’t get me wrong, I am trying to end up with best possible UX for the future.
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…?
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.
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 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
to most of this, however just one small point 
). 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 