[CFGUI-87] Improve Problem UI Created: 17/Apr/19 Updated: 12/Aug/19 Resolved: 15/May/19 |
|
| Status: | Closed |
| Project: | Definitions App |
| Component/s: | None |
| Affects Version/s: | 2.0 |
| Fix Version/s: | 2.0 |
| Type: | Story | Priority: | Major |
| Reporter: | Christopher Zimmermann | Assignee: | Roman Kovařík |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 5m | ||
| Time Spent: | 6d 2.85h | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||
| Epic Link: | UI framework: advanced features | ||||||||||||||||||||||||||||
| Sprint: | Foundation 10, Foundation 11 | ||||||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||||||
| Description |
|
User Story: As a developer, I can easily get an overview of all of the problems in my definitions so that I can troubleshoot and fix problems with my team. Notes Dealing with problems is one of the primary use cases of the definitions app, so it should work well. Common scenarios: Notice and fix problems when I upgrade to a new Magnolia version, try new modules, develop new projects. In some of these scenarios, a project might have 10's or even 100's of problems. So an overview is important. Acceptance criteria Please see revised criteria and mockups here:
|
| Comments |
| Comment by Jan Haderka [ 18/Apr/19 ] |
I disagree. The fact that problems are now shown directly in the main app instead of only separately is great improvement and removal of problems subapp is step in right direction. We all agreed that reducing amount of very limited apps/subapps is the way to improve the experiences. And showing issues directly in the main app with filtering allowing to achieve view of problems only is more then sufficient replacement for problems subapp. What would make it even better would be to make window showing the error bigger or resizable or both. Currently majority of exceptions or log messages would simply not fit in. Another important aspect is that not having extra subapp that requires special code handing significantly reduces code base of definitions app and thus simplifies maintenance. We should not forget about that aspect too. |
| Comment by Christopher Zimmermann [ 23/Apr/19 ] |
|
Description updated. No longer relevant:
|
| Comment by Christopher Zimmermann [ 23/Apr/19 ] |
|
rkovarik What is this "detail generator" bug in Vaadin? |
| Comment by Jan Haderka [ 23/Apr/19 ] |
|
czimmermann I might be too dense, but if you look in the screenshot of the new filter field, it provides just same key benefits
On top, you have also rather nice visual notification next to each problematic item even when browsing definitions in normal mode and thus get alerted to problems even if you did not switch to the problem-only view. |
| Comment by Roman Kovařík [ 25/Apr/19 ] |
|
Could you evaluate possibility of replacing the tree view with a list view?
|
| Comment by Christopher Zimmermann [ 25/Apr/19 ] |
|
Hi Roman, Interesting question! The definitions subapp is important because it is the one place where you can see the actual live definitions in the system. All of the "decorations" and "includes" are applied. And now as an added benefit, the problems are flagged directly on the tree. The Resources app and the Config app do not show those things. Also its handy to see all defs, and all props, from all config-sources, in one place. This provides a lot of value to developers, and we've recieved a lot of positive feedback on the feature. A lot of this value would be lost if it was not a tree. It is extra effort for us to maintain these different apps, but they all provide different important values, and the effort is worth it. Re: "filtering by any column makes grouping into folders by registry type redundant". Yeah its sort of redundant, but its really convenient to have the folders by default. It gives devs a nice approachable overview when you open the app. I find it mentally easier to just explore all the definitions by opening a type folder. I use the filters when that isnt working or I have something really specific. Re: "filtering in the tree view raises the question if the folders should be expanded after the search to actually see the filtered results or not ". Huh, really good question. Im not sure. I have to play with it. For example with the problems, having them all opened was really distracting, I could not get an overview of what my problems actually were. |
| Comment by Hieu Nguyen Duc [ 22/May/19 ] |
|
Two defects found during QA. 1) In Definitions tab, grid header looks shaky when clicking on items continuously. Footer also gets bigger upon toggling on item. shakingGridHeaderAndOversizedFooter.mov 2) In Problems tab, grid appears to be flashing when dragging last column. |