Tracing / feedback

[sseppi]

There are many advantages to trace at least errors that happen in the Databrowser application and to report them to the ODH team in an automatic way. For example, stability problems could be detected early on, before they affect to many users.

In addition, user feedback is often very valuable. We should make it as simple as possible for a user to give feedback

• should we add some tracing mechanism? If so, we need to discuss how that would work, what conditions to trace, what data to send back and many more
• should we add some feedback mechanism for users, e.g. feedback form, "give feedback" menu entry, ...

[sseppi]

It has been decided that the first step will be the integration of the parameter origin as databrowser2 in every call that the databrowser does at the Open Data Hub API.

In this way the Open data Hub monitoring system will be able to track all errors through the API monitoring system.

For this it has been created a dedicated issue #185

[gappc]

Hi @sseppi, I don't think that the mechanism discussed in #185 tracks all errors. It will just show problems related to a ODH request. Any other problem / error will not be tracked.

Simple example: a user opens the table view for Dataset X. The component that renders column A in the table has a bug where it doesn't check for null values (this example already happened). Unfortunately, some records have null set for the data at column A. The result is, that the column A will not render properly for those records. This kind of bug can not be detected by the mechanism discussed in #185. It needs a different kind of tracing.

We should decide if we want to track the kind of errors mentioned above (in my opinion we should) and how to do that. Example solutions for what i have in mind are Sentry or GlitchTip.

[sseppi]

@gappc understood, so in issue #185 we solve only the first and most simple part to track.

Could it be also Catch Solve or Selenium possible solutions to track this kind of errors?

[gappc]

Hi @sseppi, here is my feedback to your question.

Catch Solve

I'm not 100% sure what catch-solve is, but it seems to be a combination of web-crawler that identifies broken links and a HTML / JavaScript parser that identifies initial errors / logs that are written to console until the website is ready. While it is for sure useful to identify certain error (e.g. broken links), it misses the errors that happen due to dynamic user interaction.

Selenium

Selenium is a test framework that combines test setup (e.g. navigate to page X) with execution (click on button Y, ...) and a check if expectations are met (e.g. popup is open). This is a very valuable tool for frontend / E2E tests and should detect those errors where tests exist, but it won't cover unknown errors that happen to a user due to its usage of the Databrowser.

What I have in mind

What I have in mind is a a big try / catch block in the frontend. On error, the catch part sends a message with error details and maybe some additional description to an endpoint, such that we are able to collect, identify, analyze and understand bugs that happen on the frontend, without the user having to send us an error report (most users won't do that).

[sseppi]

@gappc and @RudiThoeni is Hotjar enough to collect feedback from the users or do we have to think to introduce something different?

[gappc]

@sseppi At the moment it should be enough, but please keep in mind that we use the hotjar free tier, which has limitations on the number events / feedback / records it accepts and stores. Please evaluate if those limits are enough.

[gappc]

@sseppi what's the current state of this issue? Can we close it? Do we use HotJar at all or should we remove it?

[sseppi]

@gappc and @pkritzinger is this feature still needed?

We have to do a review of the feedback in HotJar and decide if we want to keep it.

[pkritzinger]

@sseppi Let's have a look at the results in Hotjar when we analyze the results oft the UX-Test. Afterwards (from my POV) we can close this isue and remove Hotjar.

[sseppi]

@pkritzinger maybe we can include them in a section of the the user test result?

[pkritzinger]

@sseppi ok. will get back to you regarding access as soon as we start the analysis.

[gappc]

@sseppi @pkritzinger are there any news regarding this issue? What about Hotjar?

[pkritzinger]

@sseppi @gappc from my point of view, the insights generated are not valid, or rather distorted by internal users?

[sseppi]

@pkritzinger so your proposal would be to remove Hotjar and trace the feedback by letting the users write to help@opendatahub.com in case of need?

[pkritzinger]

@sseppi It depends on what we want to achieve: Collect UX-Insights:

• Hotjar can be a valid tool, but currently it seems that there is too little traffic on the staging environment so that the collected data is not representative.
• Do other, small, UX-Tests

Allow users to give feedback on bugs/ malfunctions: feedbucket can be a good tool: https://www.feedbucket.app/

[gappc]

@sseppi @mrabans @pkritzinger @Mazzolintis given that we have a discussion about the Toolbox button in #590, main reason being that there is only so much space on mobile devices: is the Hotjar integration still in use? Did anyone take a look at it or its data?

If we don't use Hotjar, it could be an idea to remove the integration and the Hotjar button. That way we could free up some space on the right side of the application, it would look less overloaded (at least on mobile).

[sseppi]

@sseppi @mrabans @pkritzinger @Mazzolintis given that we have a discussion about the Toolbox button in #590, main reason being that there is only so much space on mobile devices: is the Hotjar integration still in use? Did anyone take a look at it or its data?

If we don't use Hotjar, it could be an idea to remove the integration and the Hotjar button. That way we could free up some space on the right side of the application, it would look less overloaded (at least on mobile).

@gappc, since there isn't much traffic and data collected through Hotjar, my suggestion would be to remove it from the app and collect the feedbacks in other ways (e.g. customer interview by the Cuatomer Care, ticket in the Customer Care, etc.). Shall I open a dedicated issue for that?

[gappc]

@sseppi we can also use this ticket and close it as soon as the Hotjar integration is removed.

[gappc]

@sseppi there is now PR #593 that removes HotJar from the project as soon as it gets merged

[gappc]

@sseppi the PR was merged, should we close this ticket?

[sseppi]

@gappc Thank you!

I think we can move this issue in the "To review" lane, test it and then, if everything is fine, close the issue.