Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-1402

WebJive usability fixes: integrate Devices and Dashboards

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • Feature
    • Not Assigned
    • PI9
    • None
    • Obs Mgt & Controls
    • Hide

      When this issue is solved users will not notice the separation between the two React apps. And will therefore be more satisfied, will make fewer errors and will be more productive when building complex dashboards.

      This problem now severily hinders people that have to work on complex dashboards.

      Show
      When this issue is solved users will not notice the separation between the two React apps. And will therefore be more satisfied, will make fewer errors and will be more productive when building complex dashboards. This problem now severily hinders people that have to work on complex dashboards.
    • Hide
      • when I switch from Dashboards to Devices and the to Dashboards, the browser shows me the dashboard I was editing/running
      • when I switch from Devices to Dashboards and back to Devices, the browser shows me the particular device I was inspecting.

      NOTE: the 3 feature point estimation is indicative, and it might be the case that after additional investigation we come to the conclusion that only the first 1 of these 2 ACs can be achieved in the allotted effort. Because it might be difficult to deeply refactor Devices, we expected that only part of this feature can be done on Devices.

      Additional acceptance criteria are:

      • commands in Devices should perform the same validation of arguments as in Dashboards. A user switching from one app to the other should not experience differences.
      • all the args types that are available to commands in Dashboards should be available also in Devices. A user should be able to control a device in same ways, regardless whether he/she is using Devices or Dashboards.
      • the file-upload-command is available in Devices.

      The following acceptance criterion is worth some extra business value:

      • this refactoring results in features in WebJive that are toggeable. In MaxIV they might not need/want to see these changes in Devices and their WebJive should work just fine.
      Show
      when I switch from Dashboards to Devices and the to Dashboards, the browser shows me the dashboard I was editing/running when I switch from Devices to Dashboards and back to Devices, the browser shows me the particular device I was inspecting. NOTE: the 3 feature point estimation is indicative, and it might be the case that after additional investigation we come to the conclusion that only the first 1 of these 2 ACs can be achieved in the allotted effort. Because it might be difficult to deeply refactor Devices, we expected that only part of this feature can be done on Devices. Additional acceptance criteria are: commands in Devices should perform the same validation of arguments as in Dashboards. A user switching from one app to the other should not experience differences. all the args types that are available to commands in Dashboards should be available also in Devices. A user should be able to control a device in same ways, regardless whether he/she is using Devices or Dashboards. the file-upload-command is available in Devices. The following acceptance criterion is worth some extra business value: this refactoring results in features in WebJive that are toggeable. In MaxIV they might not need/want to see these changes in Devices and their WebJive should work just fine.
    • 3
    • 3
    • 11
    • Team_CREAM
    • Sprint 4
    • Hide

      The 2 app devices and dashboards are now aligned in terms of:

      • state persistence
      • argument types validation
      • commands availability
      • file upload

      A configuration file has also been created that allows for toggling functionalities (i.e. remove some widgets, change widgets minimum size..)

      Show
      The 2 app devices and dashboards are now aligned in terms of: state persistence argument types validation commands availability file upload A configuration file has also been created that allows for toggling functionalities (i.e. remove some widgets, change widgets minimum size..)
    • 9.5
    • Demonstrated, Satisfies Acceptance Criteria, Accepted by FO
    • PI22 - UNCOVERED

    • webjive
    • SPO-715

    Description

      Recent demos and conversations with some SKA users revealed some UX technical debt of WebJive.

      One issue has to do with the "Devices" functionality (aka web version of Jive) and "Dashboards", the dashboard editor and runner. Devices and Dashboards do not remember their state when the user switches between them. For example if I’m using Devices and go to a certain device and explore its commands, but then switch to Dashboards and open a specific dashboard, and finally want to go back to Devices,  that context is lost, and I need to browse all my devices again and again. Similarly when I return to the Dashboards, where I have to again open my dashboard.

      This is really annoying, prone to errors and slowing down the user.

      In addition, the way in which commands are handled in Devices and Dashboards is different: in the way in which a command processes/validates its args (eg. in Devices there is not the same validation of arguments as in Dashboards), in the ability to issue the same commands (eg file-upload-command is missing in Devices).

      THis is caused by the fact that Devices and Dashboards are implemented by two separate React applications; they were developed at different time by different people, and they feature different levels of quality. Devices is less modern, is not compliant to more modern React best practices and has fewer tests.

      Attachments

        Issue Links

          Structure

            Activity

              People

                g.brajnik Brajnik, Giorgio
                g.brajnik Brajnik, Giorgio
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 3.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete1135.0
                  Total1135.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel