Support Page UX Design #334
Comments
syndesis-bot
added
cat/design
Relates to: #191 |
Related to this topic, I have a comment on the current UI in presence of errors:
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. |
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 |
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? |
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. |
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 (#166). We will need to come back to this issue when we are at. I hope at the beginning of next week. |
While reasoning on this functionality, even from a UX pov, I was thinking that there are support information can be divided in:
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. |
Hi @amysueg . Do you have any news on this activity? |
@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: #191 Assume that the workflow will be:
@dongniwang @sjcox-rh please add your thoughts |
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 ? |
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 |
@dongniwang Dongni created a few designs for this.
|
Hi @amysueg , thank you for the update. Please see the linked issue here for more details: #191 |
|
On hold until after Sprint 20 demo per Paolo; we'll move this to Sprint 21 during planning cycle. |
|
And to save @paoloantinori from having to copy and paste, here is his response: 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. |
|
Sorry for the confusion, but this is the new monorepo ux issue. Copying your comments from syndesisio/syndesis-ux#47 (comment)
|
|
There should be an explanation on the support dialog describing what this screen is about, why it offers downloads and what to do with the downloaded file. |
|
@lhein Thank you for the comments. Can someone confirm what the user should do once she has downloaded the file? Is there an email address we would specify in the UI, or a link to another page where more information would be provided? @paoloantinori @rhuss |
|
They have to ship it to Red Hatt Support, but that is an external workflow
we are not linking to directly in the context of our app.
They might upload a file in a form, attach it to an email or uploading it
via ftp, but it should be transparent to us.
…On 27 November 2017 at 15:41, Amy Glass ***@***.***> wrote:
@lhein <https://github.com/lhein> Thank you for the comments.
Can someone confirm what the user should do once she has downloaded the
file? Is there an email address we would specify *in the UI*, or a link
to another page where more information would be provided? @paoloantinori
<https://github.com/paoloantinori> @rhuss <https://github.com/rhuss>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#334 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABcz2kdgPMu1ve7qJvAObprSI9nfY4QIks5s6soEgaJpZM4Qfl4C>
.
|
|
I understand. However, when @lhein suggests that we inform the user in the UI what to do with the downloaded file, do we actually include an email address or the location of an FTP site? That's what I'm unclear about. And if we do include an email address in the UI, what email address? [email protected]? @sjavurek copying you for your thoughts, thank you. |
|
Sorry, I'm way behind on my e-mails. Hopefully the meeting this morning helped. These files can be very large so an e-mail address won't work. The FTP site (dropbox.redhat.com) is our ideal place, however, I do not think there is a web based interface for that. I'm researching it. After our call, I'm also wondering about our discussion for the checkbox to allow us to export a project with credentials. I know we mentioned have a little "i" information pop up but given the ramifications of sharing your credentials, I wonder if we need to have a pop up when the user a checks that box, i.e. something like "By checking this box you agree to share your username/passwords" for this integration.". What do you think? |
|
@paoloantinori @rhuss I was mulling over the meeting in my mind this morning. Why is it less taxing to the system or easier for us to download a large file locally then to stream it to dropbox.redhat.com? It just seems like an extra step for customers to take that is rather cumbersome. I think this should be as easy as possible. Sorry for the rehash, I'd just like to understand. :-) Susan |
|
@sjavurek The problem is that we can't guarantee that the backend (Syndesis) can reach dropbox.redhat.com (although very likely as we are talking about 'integrations' which naturally require accessing external systems, too). But maybe more important, it's about giving the user the opportunity to check the logs before sending it out to the support. Could be that this is the German in me ;-), but if this is not a problem, we should offer both possibilities. For the "Upload to Red Hat Support" option, we would need some extra fields (e.g. email address, notes) so that we can later correlate back to the user when uploaded. |
|
I would just put in some more detailed explanation why one should zip the logs and then what to do with that archive mentioning that they can be sent to some email address AND/OR uploaded to some official dropbox folder. Tbh the URL dropbox.redhat.com doesn't really show its a support thing. Also it might be reasonable to ask the user to create a Jira issue / Salesforce case and attach the file there. |
|
@lhein I think its the sheer size of the logs which can be too large for sending via mail or attaching to a JIRA ticket. Saying this, we must be also clear that creating and sending these logs can put quite some burden on the backend (even when used with streaming). Also we should make it as simple as possible for the citizen user. On the other hand, it's not really clear to me now, how large the files are really are and whether we are optimizing too early. |
|
We can let the user implement their own integration:
```
from("syndesis").to("rhsupport");
```
;)
…On 29 November 2017 at 08:28, Roland Huß ***@***.***> wrote:
@lhein <https://github.com/lhein> I think its the sheer size of the logs
which can be too large for sending via mail or attaching to a JIRA ticket.
Saying this, we must be also clear that creating and sending these logs can
put quite some burden on the backend (even when used with streaming). Also
we should make it as simple as possible for the citizen user.
On the other hand, it's not really clear to me now, how large the files
are really are and whether we are optimizing too early.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#334 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABcz2vWLgY8hYuLaTLOcCivW2Av3L3qlks5s7Qe5gaJpZM4Qfl4C>
.
|
|
Anything larger than 1GB has to go via the FTP site. There are ways to chunk up large files to work around that but its a lot of work to reassemble them. It's much easier to simply put it on the FTP site at this time. With that said, we do not have a browser based option at this time, however, there is some work being done in this area as we plan to replace this dropbox at somepoint. The final solution has not been verified yet but I've been looped into some of the conversations. Do we have any early tests that may help us estimate the size of the file in question? Perhaps we can let the customer implement their own integration as Paolo mentioned? By default, we can download it but allow the customer a way to override that and use their own integration. [1] highlights a support tool which is command based. Technically they can even open a support ticket using this tool and attach small tickets to the case. Integration to the FTP site where ever that may be in the future is forthcoming. |
|
1 GB log files in a compressed archive? I am tempted to say that something is wrong with the way the logs are handled if it comes to such sizes. But thats just me maybe. |
|
Any news on this story ? I move it over to Sprint 23 / TP4 as I guess its not finished yet. |
|
PR #1168 merged, closing this issue. |
|
Hi @dongniwang I have a couple of feedback for you now that the main functionality is there and we are working to align the ui the designed one:
|
|
Hi @paoloantinori, thank you for the feedback! I agreed that we should have a way to keep users informed during the process. Here's the proposed solution:
@michael-coker - Can you please help @paoloantinori with the UI implementation? Thanks so much! I'll create a UX pr to update the design later, but meanwhile, please go ahead with the implementation. |
|
@paoloantinori how would you like to handle the messaging and processing indicator work? Will you build the base functionality and pass off to me to handle the styling, or do you have a different workflow in mind? |
The text was updated successfully, but these errors were encountered: