industrial-optimization-group / desdeo-webui Goto Github PK

We currently show very crude error messages. Better error handling would probably involve adding some error states to the state machine in functional_api.ts.

Scatter plot matrix should be added to available visualizations. There is two possibilities of implementing the component:

1. Make a single component using ECharts grids. Use grids to make the matrix and assign a scatter plot for each grid.
2. Make a component for a single scatter plot and a parent component which then contains a grid using HTML divs/tables or any other HTML way and add a single scatter plot component to each div/cell in the table.

Here's an ECharts example of the scatter plot matrix in one echarts instance: Scatter plot matrix

An example of just a single scatter plot: Scatter plot

Reference point method should have a "stop" button to stop the solution process. At the time of writing, the documentation for desdeo-webapi doesn't seem to mention a command for stopping the solution process, but I've been told it exists. I understood that this command should return at least the objective and variable values of the selected solution.

We should show the objective and variable values to the user and provide options to visualize them. The user should also be provided with the option to save the solution to an archive.

It would be nice if the method control buttons stayed at the top of the page when the page is scrolled down. This should probably be implemented as a component.

We should unify the display format of numbers in different components, and this should be configurable by the user.

How to do this?

• Each component that displays numbers should probably have a property for this with some sensible default value. Currently we show 4 decimals.
• We should probably store the desired format in the application state (or in a suitable context). This would allow customizing the format globally.
• Should the components read the format from the state or should this be the responsibility of the their parents?
• Should we also allow customizations of the format at component level? Should these local customizations be temporary or permanent?
• Using scientific notation was raised as one good possibility.

In the charts, where the is multiple solutions in the same chart (parallel coordinate), change the appearance of each solution.

• By using a gradient of some color
• Using different texture/pattern for each solution

As one of the props given to visualization components, we should include information about the multiobjective data to be visualized. This prop may be called solution_data, for instance. This prop should be implemented as its own type and contain the following fields:

• names (string[]): e.g., the names of the objective functions.
• values (number[][]): e.g., the objective vectors, each vector representing the objective function values of each solution. A row represents one solution.
• value_ranges (number[][]): e.g., the objective function ranges, which in most cases are the ideal and nadir points of the problem being solved.
• tags (string[][]): multiple tags defined for each solution (row, first dimension).
• uncertainty (number[][][]): e.g., the upper and lower values for each objective function value in each solution.
• minimize (boolean[]): only applicable when data represents objective function values. True, if the objective is being minimized, false otherwise (maximize).

Note that data type above can also be used to represent decision variable data for a problem.

Here is an example of the structure in TypeScript:

type SolutionData = {
  names: string[];
  values: number[][];
  value_ranges: number[][];
  tags: string[][];
  uncertainty: number[][][];
  minimize: boolean[];
};

let exampleData: SolutionData = {
  names: ['Objective1', 'Objective2', 'Objective3'],
  values: [[1, 2, 3], [4, 5, 6], [7, 8, 9]],
  value_ranges: [[0, 10], [0, 10], [0, 10]],
  tags: [['Tag1', 'Tag2'], ['Tag3'], ['Tag4', 'Tag5', 'Tag6']],
  uncertainty: [[[0.9, 1.1], [1.9, 2.1], [2.9, 3.1]], [[3.9, 4.1], [4.9, 5.1], [5.9, 6.1]], [[6.9, 7.1], [7.9, 8.1], [8.9, 9.1]]],
  minimize: [true, false, true]
};

This requires at least:

• Make sure that the backend sends infinite values in valid and easy to handle format. One possibility is to use the strings "+Infinity" and "-Infinity" (this idea is from the MathJSON format).
• Handle the selected method of encoding infinite values in requests.ts.
• Handle infinite ranges correctly in the UI.
  • Perhaps show an interface for setting limits in place of the horizontal bar for the affected objectives.
  • Verify that the visualization components can show sensible output without finite ranges, or limit the availability of visualizations.

The validity of the preference value is currently checked and reported only at the top level. It would be useful to have this checked and reported at the level of each input box.

This is easy to do with Zod and is a good first task for beginners.

Refactor the code, so that the component uses the base version of the parallel plot and then adds the arrows to that instance. The arrow swapping feature needs then to be reviewed, because at the current stage it's not working in the real UI environment.

When there is too little space, values don't have enough space and overlap each other. Possible fixes:

• Change the number of showing values (echarts option: xAxis->axisLabel->interval)
• Tilt the labels (axisLabel->rotate)
• Alternate the labels vertically between each other
• Add more space for the component

When values have many decimals and are close to each other, the lines don't render correctly.

Skeleton has just been updated to a new version that brought changes to the theming system. Now would be a good time to create a proper theme for the UI in DESDEO colors.

This is not difficult but the resulting mathematical expressions could have different forms than the original inputs. Should the file format be updated to allow saving LaTeX along the MathJSON expressions? This could be useful for other purposes too and is easy.

Representation of negative values in petal chart should be improved. The state at the moment:

Add a hightlight feature (on mouseover) to the table component, such that the highlighted row is a property of the component. Then use this property to connect the solutions table and the visualization components.

Components that don't have a indicator whether the objectives are to be minimized or maximized:

• Radar chart
  • Symbols can be set to the ends of the axis (symbol: ["arrow", "arrow"]), which could be an easy way to implement this. However, accessing each axis individually and changing the direction of the symbol (arrow) might cause problems.
• Petal chart
  • Same approach could be used as in the bar charts; markLine with symbol: "arrow". This way the arrow angle and position would be set automatically.
  • If that doesn't work, custom icon with position and angle most probably would need to be set manually
• Nautilus Navigator bar
• Currently, dragging is restricted only to one direction.
• A prop should be added and according to that prop drag restriction direction is changed

The values get hidden under the chart like this:

Visualizations where this should be fixed:

• Petal chart
• Radar chart

Currently the saved format is not the one recognized by desdeo-problem because an adequate specification was not available. This task is not terribly difficult but might require spending a lot of time studying the parser and examples in desdeo-problem.

Note that the component doesn't currently have an interface for setting the goals of objectives (minimize or maximize). This was left out accidentally and should also be fixed.

There is a couple of places, where ts-ignore had to be used, because the ECharts options and option types were not compatible. This issue happens most probably because the options used were introduced in a newer version of the library and apparently the types are not updated. The type errors are documented in the code, and should be found by searching "ts-ignore" in the visual folder. There might be a solution that I wasn't able to find.

Some of the requests in the backend client (currently src/lib/api.ts) don't validate the response data. Adding this validation would increase the quality and reliability of the application and would be a good introduction to the popular Zod validation library.

Should be possible with ECharts option showMinLabel. If not, custom text with the position of chart.convertToPixel({ seriesIndex: 0 }, [lowerBound, 0])[0];

The UI should be disabled and an activity icon should be shown while the application is communicating with the backend. See the design files for the intended design. See also if the Waiting.svelte component has something useful.

Can this be implemented as a reusable component? Could this component have some default handlers for unhandled errors and an option to add handlers for specific errors?

This can be done by adding Axios middleware in the with_access_token function in the backend client module (currently src/lib/api.ts), and is not very difficult.

Some user interfaces show a button that the user can click to access additional instructions. It was suggested that this button should have an "official" design so that the same design can be used in every interface.

It was suggested that a user might have trouble understanding that they need to maximize the visualizations to get access to the grid mode. Some instruction text could be added to help the user.

Update the dragging lines to be the same as in Horizontal bar, so that the line is easier to drag. The creation of the dragging line could be a separate function, so that the same code is not copied over and over.

If this is too complicated or the line used in horizontal bar is not compatible, make an invisible line with bigger width than the visible one. This way the line is easier to drag

getModel() is a private method and it can break in the future! apache/echarts#16479. Using the method works fine, it just throws an error: "Property 'getModel' is private and only accessible within class 'ECharts'."

Workarounds might be possible. I started using the method because it was used in some of the examples in the ECharts own examples and provided simple and efficient solutions.

We should show the solutions in different colors so they can be visually differentiated. The suggested idea was to use some kind of gradient approach for this.

This should be easy to implement with a utility function (that probably already exists) that can produce gradient ranges. Many (all?) of the visualization components already have a property that takes a list of hex color values to use. Adding this feature to the table component is easy.