Current state: In Development
Discussion thread: https://lists.apache.org/thread/knd5xgkswp83x92c0sclh7ghcob7bpfx
JIRA:
Released: -
(Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.)
Improve overall security by removing EOL code from the code base
Preserve functionality by providing an updated Admin UI
Make Solr more approachable by both users and devs
Improve maintainability of UI code base
Improve UI/UX of the UI (in favor to SIP-10)
Plan and implement new Admin UI features
Modernize the UI look and feel
Migrate to v2 API
Improve error handling
Improve limited user's experience
Introduce a desktop client
No interface will be changed, existing API is consumed for the new implementation. Existing Admin UI will coexist with the new UI until the new UI is production ready and can replace current UI.
The option to provide new interfaces for extending the UI may be considered in the future.
UI-specific interfaces that only the current UI is consuming will be deprecated and removed together with the current UI.
The proposed changes include a full rewrite of the Admin UI by implementing step-by-step a new UI and co-hosting it with the current UI until it can be fully replaced. Various links in the current UI should allow users to test the new implementation early on and provide feedback (see for that the current POC PR#2605).
The current POC uses Compose Multiplatform, a Kotlin-based UI framework that is very popular in Mobile app development and comes with desktop and web support. See the detailed writeup here for more details on why ComposeMP was chosen as a candidate. Other UI frameworks, mainly web-based frameworks, are still considered if Compose MP is proven unsuitable in the POC.
The new UI should also aim to address as many existing issues as possible, starting with the issues already associated with our JIRA project's "Admin UI" component. Still, focus should remain on the most "important" features that are necessary for replacing the current UI. New features may be introduced in a later stage.
The proposed design (i.e. look-and-feel) and page layout can reviewed using the provided Figma mockups.
You can participate and provide additional feedback and input in the users discussion thread.
In order to realize the proposed changes and proceed with the migration plan (see below), the new UI implementation has to be accessible via web. The new UI should ideally be linkable in the old UI so that users can start using the new UI during the experimental / development phase and give feedback.
The work should be split into two phases:
Preparation Phase (steps not necessarily in chronological order):
Development Phase:
Create new Designs based on current state (in progress)
In order to address many UI / UX flaws of the current UI, we should plan ahead and create new designs, discuss them and in an iterative way improve and extend them if necessary. This process should involve the Solr users too.
There are already a couple designs created for the new UI that can be found here. Use the current discussion thread for feedback, ideas and any other kind of input related to the new designs.
Create epic and prepare Jira issues (in progress)
To address the large scope of the new UI implementation, we should make use of an epic and splits the UI into smaller chunks the community can easily be work with. This way we will avoid a single, huge PR that is hard to review.
Choose framework/language (selected)
In order to select a suitable UI framework, we should create a proof-of-concept (POC) for the most interesting candidate and validate its integration, code complexity and learnability.
Implement and merge new UI's base (in progress)
In order to work with the new UI and merge continuously and over time new changes, a proper base needs to be available. This could be covered partly or completely by a POC.
The new UI can be distributed with any upcoming release and can simply be marked experimental for the time being.
Implement new UI (in progress)
Once the base is available and the new UI coexists with the current UI, developers can start working on the Jira issues and implement new UI components.
The epic should include all features necessary in order to complete this step and proceed to the deprecation and removal of the old UI.
Deprecate old UI
Once the new UI is usable and could potentially replace the old UI, we may not have received enough user feedback and tested it in production. For that reason, we should mark and disable the old UI as deprecated for a period of time until we can safely remove the old UI and fully replace it with the new UI.
In this phase new plans and features can be planned and developed for the new UI.
Remove Old UI
Once we ensured that the new implementation is tested and used enough by users, we can proceed and remove the source code of the old UI.
The current UI contains EOL JS code and libraries. They pose a variety of risks and leave Solr more vulnerable at that vector. New UI frameworks address many of the web application vulnerabilities listed by OWASP and therefore are considered an improvement in security.
Even though new UI frameworks are considered safer now, they become more and more complex and have many dependencies that could also pose new risks. Therefore, maintenance and tool support will also play a significant role.
Note about Compose MP (POC)
In the POC code changes, a WebAssembly app is launched aside the current webapp, which requires the script-src flags unsafe-eval (in development) and/or the unsafe-wasm-eval (in production) to be allowed (see unsafe WebAssembly execution for more details). Two jetty configurations were added for this reason that are dynamically loaded based on the environment.
The typical test plan includes unit tests and integration tests that are executed with our automation scripts.
Since UI testing is not always straight-forward, an additional test plan is added with the proposed migration plan. "Early adopters" / Users will be able to use the new UI during its development. In this phase, feedback can be provided early on, allowing us to address any matter early on. This includes feedback, feature requests, UI/UX issues and bugs in general.
An alternative to the proposed UI framework is a solution based on web-frameworks like Angular, Vue and React. Choosing one of these frameworks would have the following benefits:
The drawbacks that could be expected are:
These alternative frameworks have not been rejected yet and could be considered in case Compose Multiplatform is proven unsuitable as a framework.
Moving UI code out of Solr project
Although the motivations behind this approach are reasonable, it would have a larger impact on Solr, as it would turn into a headless system.
This is considered a huge drawback for beginners, as the setup steps are increased and third-party tools have to be trusted to get a UI dashboard. Additionally, new UI developers may find their way to the UI project, but not to Solr, resulting to potentially fewer contributions in both UI and the Solr project.
Continuing with EOL AngularJS
See motivation of this SIP-7.
Old Discussion Thread - https://lists.apache.org/thread/klvcr3x8clplq6qktokwjy7s52yz878j