Admin UI: Maturation model
(This issue is type:exploration
. It is intended to discuss/explain/invite comment. It is not a singular action-item for implementation. The discussion may lead to other more concrete things. We can close the discussion when the approach is agreed; it doesn't need every possible follow-up task.)
Context
- Much of CiviCRM UI was originally built with one particular architecture. (Key concepts:
HTML_Quickform
,Smarty
,Selector
,StateMachine
.) (Short-hand: "Civi-Quickform" or "CQF") - We're in the middle of a multiyear project to convert large swaths of the CiviCRM UI to another architecture. (Key concepts: APIv4, Form Builder, SearchKit, Angular, Managed Entities.) (Short-hand: "SearchKit/FormBuilder" or "SKFB")
- The "Admin UI" extension (
civicrm_admin_ui
) is a bundle of SKFB screens (which replace CQF screens). The bundle currently provides ~20 screens.
Question
As the screens in "Admin UI" mature, how do we roll them out to the user-base?
Opinions/Thoughts
- The great thing about "Admin UI" extension is this: we can "move fast and break things" while keeping the ship "pointed in one direction" and also allowing "real-world testing".
- For site-builders, it's an opt-in that doesn't interfere with their existing screens. They can try new-screens and easily switch back to the familiar screens.
- For developers, it lowers the effort to get started -- you don't need perfection. You can do a first-pass in February -- it's a "good/decent" screen with a couple quirks or missing-features. You can take some time to get feedback or think-through the quirks. Then in May, you come back and make a better version.
-
civicrm_admin_ui
is accumulating a set of viable replacements. - But they're not all equally viable.
- There are still many screens that don't have replacements -- screens which will need their own maturation time.
- There was some discussion about whether we're ready to enable
civicrm_admin_ui
by default. Some options are:- No, keep it disabled by default (until the entire UI has been re-done). But then a lot users don't get the benefit of perfectly good (improved) screens. And developers still have to maintain both the old+new variant of each.
- Yes, enable it by default (while conversions are on-going). But then it puts more pressure for new screens to be perfect. You can't merge a replacement unless you've addressed all the features of the original.
Proposal
Replacement-screens go through process of incubation/graduation, mediated by civicrm_admin_ui
.
-
Incubation: When a new replacement is written in SKFB, put it in
civicrm_admin_ui
. Allow 3-9 months for additional development, real-world usage, etc. -
Graduation: When the replacement is sufficiently mature, move it to a standard/universal folder. (Ex: A new CiviContribute SKFB screen will go to
ext/civi_contribute/
.) - Cleanup: Three months after graduation, delete the old screen.