-
Notifications
You must be signed in to change notification settings - Fork 496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion for Config UI Improvements #1700
Comments
@Startrekzky @yumengwang03 Thank for the UI proposal/feedback. I feel there are many months of development history not taken into consideration, however, also our interface is a result of selective business requirements we choose to meet each sprint. So there are features and interactions that need completion as a result. I've noted some responses below to add further context.
Endpoint URL maybe standard for some providers like GitHub, for JIRA it would be custom based on how the instance is deployed. For GitHub we can simply prefill a default value of the current known REST Endpoint for JIRA. I agree there are many visual improvements as well as several ways to design a GUI for Crontab configuration that can be done to make visual scheduling easier for less advanced users. However for advanced users the current interface would still be very practical.
There are differences between Advanced and Standard (Visual Mode) intentionally, for instance multi-stage was intentionally left out of standard mode due to engineering decision -- there were plans to add stage support to the main interface. The pipeline provider options were mainly driven by our Data Integrations, as well as some additional plugins were created that were to be "Pipeline-only" plugins (GitExtractor, Refdiff etc). Advanced Mode was created to allow expert features we didn't want to yet incorporate in the visual interface. That being said, Feishu and other Plugins can be added to the main interface as needed.
The Tasks is one sub-component that needs to be added in Blueprint details view once expanded, however due to the limited features we released for the first version of Blueprints this was not yet added.
Field/Input order can be customized as needed for each Data Provider. Mockups should be made for the preferred presentation of the Provider parameters.
I don't agree that they are convoluted, Blueprints reflect a Recurring Plan/Configuration whereas Pipelines represents the historical runs/executions of that blueprint. Users should still be able to execute a pipeline without the overhead of creating a recurring data collection plan. With this proposal to fully merge to the 2 concepts, this would mean that a user is forced to create a Blueprint before being able to run the pipeline, which would mean the user is unable to run an on-demand pipeline. We are already showing related pipelines with the Blueprints, once tasks are displayed with the blueprint and interface changes are made the current approach would make sense. |
offer available sub tasks for user to select what to run |
@klesh Yes this can be done, it was requested since this ticket 924 https://github.com/merico-dev/lake/issues/924, however never prioritized during sprint planning. The Backend would also need to provide a new set of API endpoints |
can we show button for load config in advanced mode instead of clicking date |
@warren830 We do have 2 access points already for loading configurations. The Pipeline Name Menu and the Settings Gear on the Tasks Editor Panel. |
to create issues for this epic |
@yumengwang03 @e2corporation @klesh I got some feedback from end users and from our own experience of setting up demo instances. This feedback is not just for config-ui, but also for the configuration feature itself.
|
@hezyin @Startrekzky @klesh and I had a discussion on the next-step improvements for Config UI, summarized in the following form. The solution and priority columns are open for discussion.
|
@yumengwang03
Each |
@yumengwang03 @Startrekzky |
will be addressed by #1862 |
Description
Yumeng thinks the current Config UI has a series of problems/potential improvements, so she'd like to share some thoughts here for discussion:
Objectives of improvements
How do we improve?
1. Reduce user flow friction
Several text input fields (e.g. GitHub endpoint url) are redundant and should be eliminated for users. Some other text input fields require users to memorize/look up Regular Expression, Cron code, Board IDs, etc. to fill in; it will be more friendly to turn them into dropdown selectors.
2. Correct the imbalance between regular UI mode and Advanced JSON mode at creating pipelines
The functions of the regular UI mode doesn't match those of the Advanced mode for which user types in JSON for configuration. For instance, the regular UI mode has missing configuration fields (e.g. Feishu).
3. Show most relevant details for users in more obvious places (e.g. progression/status of pipeline runs)
Lots of status/progression related information is buried too deep. For instance, in the Blueprint list, even unfolding a Blueprint cannot reveal the tasks of that Blueprint.
4. Reconsider the order of configuration tasks for each data provider
Based on different data providers, we should reconsider the order of configuration tasks. For an example for GitHub, we should let users select repos first before filling in PR and Issue Type options. We can draw a flow chart for each.
5. Disentangle convoluted concepts
The concepts of Pipelines and Blueprints are presented in a convoluted way by the UI. We should eliminate the "All Pipeline Runs" page and unify the function of "creating a Pipeline with Blueprint" and "creating a Blueprint with a previously defined Pipeline task" into one place.
The text was updated successfully, but these errors were encountered: