Support Page UX Design

[dongniwang]

No description provided.

[paoloantinori]

Relates to: syndesisio/syndesis-project#135

[paoloantinori]

Related to this topic, I have a comment on the current UI in presence of errors:

• My integration fails to deploy for whatever backend reason. The integration listing page shows me only that my Integration is in Pending status, but there is no other useful error. I had to check Openshift logs to find the root cause.

Despite the aim is to simplify the tool to the end user, I think we have to share some more specific hint of what might be wrong with the user. Currently, the only option she has is to delete the integration.

[dongniwang]

Hi @paoloantinori, thank you for your suggestion on error handling. I agreed there's room for improvement on the current implementation.

It would be great if we can better inform users with specific error message so it's easier for them to troubleshoot. Additionally, I believe capturing specific error message could also help the support folks better understand the problems/issues.

This is a collaborated efforts among ux, back-end and front-end. @gashcrumb , do you have any insights into this?

Do we track error handling under this issue? Or should we file another issue to track it separately? @amysueg @sjcox-rh @gashcrumb

[amysueg]

Yes, thank you @paoloantinori

@dongniwang Error handling seems broader than just this one issue so I would suggest a new issue to improve error handling in the UI. First, we need a list of all the possible error conditions and when and where they occur. Is there such a thing? Or at least a starter set?

[paoloantinori]

I'm still new to this system, so probably @rhuss is a better person to reply to this.

In general, in any sw or java based sw you have a set of "expected" errors, that are the "easy" ones, since you can foresee them.

Then you have a more generic group that could logically be referred to as "anything else" that includes either errors that are currently still not classified, or eventually error that are so chaotic that don't really belong to any classification, but that anyhow should still be at least logged so that can give a hint about what's not working.

[rhuss]

Currenty the error handling and live monitoring of integrations is part of a bigger story which we want to tackle for TP4.

What we already start is to connect the health status of an integration into the UI (syndesisio/syndesis-project#42). We will need to come back to this issue when we are at. I hope at the beginning of next week.

[paoloantinori]

While reasoning on this functionality, even from a UX pov, I was thinking that there are support information can be divided in:

• global information
• integration specific information

And with this classification in mind I was asking myself if this has to be an isolated page, or if, at least the integration specific information, should actually be presented within the current Integration view.

I'm not sure what's best. I'm just some food for thought.

[paoloantinori]

Hi @amysueg . Do you have any news on this activity?

[amysueg]

@paoloantinori The UX team has laid out a schedule of our design work by Sprint based on the product priorities that came out of the F2F meeting, and we have scheduled this work for an internal (UX team) review around the first week of December.

From related issue: syndesisio/syndesis-project#135
"...we allow the user to choose which information to extract, and just produce a .zip file that he's going to download on his own desktop. Leaving the step of attaching it to a case as a manual step for the user."

Assume that the workflow will be:

1. Go to Help menu
2. Select a menu item labeled "Support" or "Red Hat Support"
3. Open a modal page that is a form displaying options for the download (sensitive information protected, etc.). Can you share more about what choices those will be initially?
4. The user selects options then "Download" button. There should be some instruction on the page that indicates the sending to Red Hat Support is a manual process and where to send the zip file.

@dongniwang @sjcox-rh please add your thoughts

[amysueg]

It looks as though the work is being scheduled for Sprint 19, so you need UX design sooner? We can shuffle some things around - when do you need the UX designs @paoloantinori ?

[paoloantinori]

Hi @amysueg, thanks for your input. I think there has been some miscommunication regarding what was expected for spring 19. Anyhow I will start the work with the info you gave me that are definitely more than enough to define the development direction.

Thank you

[amysueg]

@dongniwang Dongni created a few designs for this.
@rhuss @paoloantinori - once we have more detailed requirements regarding what to show on the download page, we'll be happy to update the designs.

[paoloantinori]

Hi @amysueg , thank you for the update. Please see the linked issue here for more details: syndesisio/syndesis-project#135

[amysueg]

On hold until after Sprint 20 demo per Paolo; we'll move this to Sprint 21 during planning cycle.

[paoloantinori]

Confirmed.
As a future reference, the characteristic of this page is that it's gonna get new elements with time; depending on evolution of the platform and the information that we identify as being useful.

So in my view it will have a filtering text box, to allow the user to display a subsection of the main form.

And the form will probably be divided in multiple logical sections, like: "platform information", "integration information", and possibly more.

An example of the interaction is a user that wants to attach logs.
She can choose to attach platform logs
She can choose to attach Integration logs
In case of Integration she might want to chose to attach only the logs for an arbitrary subset of Integration(pods) that she want to share.

[rhuss]

@paoloantinori @amysueg This issues has been moved to syndesisio/syndesis#334 (as well as anyo other UX issue). Could you please to continue on this issue (and maybe copy over the latest comments ?)

[rhuss]

Ah, just saw that is was already copied.