Closed ronja-ui closed 2 months ago
Graphs have a similar problem as in #216, there's two different ids just for one graph: p{{id}}_graph
and p{{id}}_{{viz.id}}
It shouldn't need two separate ids where one is for a container div and another one for the graph itself.
Nested divs around plain text content has been removed succesfully.
I also moved succesfully graph settings from result.html to result-chart-selector.html and finally fixed the margin problem around graph settings.
There's visible divs which shouldn't be visible in source code.
When a paragraph doesn't have any results, it should look something like this:
<div class="paragraph">
<div ng-include="" src="'/app/notebook/paragraph/paragraph-control.html'">(paragraph controls)</div>
<div class="paragraph-editor">...</div>
<div class="paragraph-footer">...</div>
</div>
In other words, paragraph-output
shouldn't appear in source code at all. Tho now it looks like this:
<div class="paragraph">
<div ng-include="" src="'/app/notebook/paragraph/paragraph-control.html'">(paragraph controls)</div>
<div class="paragraph-editor">...</div>
<div class="paragraph-output">
<dynamic-forms>...</dynamic-forms>
<div class="error"></div>
</div>
<div class="paragraph-footer">...</div>
</div>
Outcome is a bit messy but the worst part is that it creates ghost margins because of those empty divs.
A similar problem when there's results available.
paragraph-output
looks like this for angular content:
<div class="paragraph-output">
<dynamic-forms>...</dynamic-forms>
<div class="table-display">
<div ng-include="" src="'/app/notebook/paragraph/result/result-chart-selector.html'">...</div>
<div id="p{{id}}_resize">
<div ng-if="type == 'ANGULAR'">(results)</div>
</div>
</div>
</div>
At least <dynamic-forms>
and result-chart-selector.html
shouldn't be visible at all. This happens with other content (excluding graphs and dynamic forms content) as well.
Current status of the issue: the results module getting a full refactoring, which will include an optimized HTML structure, which will no longer create unnecessary containers, and combine result-chart-selector.html and settings panels inside the new result container itself.
Second iteration of refactor prototype is now available for testing in QA. Currently implemented viz modules: table, barchart, piechart, html. The code is still rough, bugs are expected.
Current module implementation status:
Markdown and Angular forms are working fine.
Current bugs:
Additional TODOs:
"if I have set some values in those settings boxes in bar/pie/line/area chart, then switch to scatter chart (which is empty) and add some settings in it, and THEN change back to i.e. bar chart, previous settings have disappeared."
Amnesiac problem in the comment above is solved
on the subject of date format option: "by default graphs show x-axis labels in YYYY-MM-DD HH:mm😕s format but users can change this only in line chart view (I don't know why). when the timestamp is super long and depending on the case I want to present in a graph, sometimes it's enough to emit the time and use only date in the timestamp. then I would write in that date format field YYYY-MM-DD which then shows the x-axis label in YYYY-MM-DD format. or sometimes I want to change the timestamp to match the way Finnish language presents dates (DD.MM.YYYY) since the audience consist of only Finnish speakers."
"as a user I would expect that if the timestamp in my dataset contains only a year, the option either
on the subject of network graph modules: the data usually used with network graph is not very compatible with any other graph types, except table. If the network is used, only table and network should be available to switch
on the subject of network settings: "User runs the query and gets network results. Should the network graph re-render on every change to the values in the settings, or only after user hit Enter or “Save” button? Does this apply to all, or only to numeric fields, and labels should act different?"
"I would unify and omit that save button - in other words whenever there's a new value the graph gets updated"
on subject of report view mode: the graph modes are still switchable, but that might be not optimal.
"maybe only writers and owners could switch the view?" preferably refactor into that way.
The graph modules need refactoring to eliminate dependency to legacy code and unused logic. Current status of refactoring:
Unit test suits for new code:
New bug list based on recent usertesting:
Request: add default "empty" aggregation, which should just return the value, if no aggregations were selected in the graph settings
The result.html structure was rewritten. The issues related to the topic were documented as separate tickets.
To put it nicely, it's a hot mess.
The current structure is something like this:
The ideal would be as simple as possible and prevent unnecessary ng-repeating with hidden content.