Open serenamarie125 opened 6 years ago
When looking at this as a quick win, lets focus on Investigate having the launcher be part of the IA - Since the launcher is not part of the IA, it presents a number of problems
@serenamarie125, as we discussed, this is similar to #4197, Please review the UX recommendation and let me know if this issue is NOT addressed. https://redhat.invisionapp.com/share/7VO5831SYNF#/320872291_Start-App
@muruGanesan is this ready for review or In Progress? Please move it to the appropriate state, thanks!
@serenamarie125, since it is similar to #4197, I am moving this to review phase.
Added to the dev plan at https://openshift.io/openshiftio/Openshift_io/plan/detail/778
The original description appears much broader and should be worked under the Navigation stories
The designs for the end of the launcher, are they the landing page that tells the user what is done? Are these final and approved?
Here is the Invision link for design review. https://redhat.invisionapp.com/share/MHP7TIO3XYK#/332556493_ExistingFlow-_Start
CC: @serenamarie125, @sunilmalagi, @sdash-redhat,
@joshuawilson, @christianvogt, Reviewed the above UX proposal as part of our weekly UXD stakeholders review meeting. Please guide me to take this forward with an appropriate team
I've commented on the invision.
@joshuawilson, Thanks for your review comments. I responded back with an explanation. Please let me know if you have a different point of view.
29 Nov 18: Based on yesterday's (stakeholder's_ review meeting. I am updating the UX flow. soon, I will publish the link.
Based on 3 Dec 18, UX design review I updated with the following changes: 1) Removal of tooltips (on mouse over of button in 'setup page' and link in space dashboard) 2) Hint-box (blue box) with text introduced in 'setup page' URL: https://redhat.invisionapp.com/share/MHP7TIO3XYK#/332556493_ExistingFlow-_Start
[I requested @sunilmalagi to review the wireframes and to provide visual design inputs]
CC: @christianvogt, @joshuawilson, @sunilmalagi, @serenamarie125
That looks good.
@joshuawilson, thanks. I see an acceptance from the stakeholders today (5 Dec 18). Please close the story based on the engineering plan.
CC: @christianvogt, @serenamarie125
@muruGanesan @joshuawilson @christianvogt
A user can not see the application on the dashboard until the application setup is completed and Jenkins is unideal only then an application is appear on the dashboard. The application comes under in progress only if the setup is completed. and setup just took 2 to 3 secs.
https://redhat.invisionapp.com/share/MHP7TIO3XYK#/screens/332556491 The setup link that provided to a user on the dashboard that should not be this screen https://redhat.invisionapp.com/share/MHP7TIO3XYK#/screens/332556492.
That setup means the application is building and that should be the pipeline link.
@vikram-raj, Today (26 Dec 2018) we discussed the following points:
1) In the application setup page, "build pipeline" step - reflects the status on pipeline page. i.e once application enters into pipeline it considered as 'the step' completed. In other words, User will NOT get to know the build status of the application on pipeline i.e. whether it started in stage/run etc... [refer the below image]
Question to Build & Application setup team: @sbose78, @hrishin, @sthaha Is it possible to get & show the actual status of application build (in the above setup page)? [If my explanation is not very clear, please check with @vikram-raj]
2) @vikram-raj is proposing different UI display when the application is 'inProgress' state. But it requires larger discussion with all the stakeholders. Because the above flow and design are finalized after multiple discussion with stakeholders.
CC: @joshuawilson, @christianvogt, @serenamarie125, @nimishamukherjee, @sunilmalagi
At this stage, all we need to know is if the buildConfig has been setup successfully. That is what we currently show as successful.
The status of the actual build is outside the scope of application creation and should not be displayed here.
In fact, there are chances that the build wouldn't start right away because it would be waiting on unidling of the Jenkins.
At this stage, all we need to know is if the buildConfig has been setup successfully. That is what we currently show as successful.
The status of the actual build is outside the scope of application creation and should not be displayed here.
In fact, there are chances that the build wouldn't start right away because it would be waiting on unidling of the Jenkins.
" this was a reason we would like to show the in-progress state" -muru
@sbose78, thanks.
In such case, 1) the setup page cannot show the actual status of the application & 2) it will complete in 3-4 sec and mark as completed (as @vikram-raj mentioned)
It looks like, we are going back to the preview design i.e. all the steps will be shown as 'completed' even though the application is in progress - is that correct?
IMO: the scope of this UX enhancement is to show the actual status and allow the user to view the status at any point in time.
the setup page cannot show the actual status of the application &
The setup page only needs to show if 'setup' of everything that is needed for builds and deployment to start.
the setup page cannot show the actual status of the application
The setup page should show the application setup status. Neither the application build status nor the application deployment status.
it will complete in 3-4 sec and mark as completed (as @vikram-raj mentioned)
Yes. In future, this buildConfig setup could be happening on a different cluster ( specific to a customer ).
all the steps will be shown as 'completed' even though the application is in progress - is that correct?
Not really @muruGanesan . The application build is in progress ( could be because of jenkins unidling or because the build is in progress ). Not the application setup. The setup is complete and hence we show a 'green'
@sbose78 thanks, I would request @vikram-raj to explain the changes in the current design. 1st week of Jan 19, as soon as @serenamarie125 comes back, we can discuss and decide on the further steps.
Based on engineering input & UX review, Here is the proposed new flow:
https://redhat.invisionapp.com/share/MHP7TIO3XYK#/332556493_ExistingFlow-_Start
Please review and provide your feedback.
NOTE:
@joshuawilson, @christianvogt, @vikram-raj, @nimishamukherjee , @sbose78 CC: @serenamarie125, @stacymcauliffe
Hi @sbose78, @joshuawilson, @christianvogt,
I need your clarification on the below: 1) Possible error cases. 2) Is it possible to show the log to the user? (ref: point# [e2]) 3) "Try again" - there are two options: (ref: point# [3b]) (i) User can go back to "Application creation" (Launcher) (ii) User can restart the setup process again Which of the above option would help user to reslove the issue?
CC: @vikram-raj, @serenamarie125, @stacymcauliffe, @nimishamukherjee, @hrishin
2 - yes you can view the log. This should be accessable once the build starts even before it has an error. 3 - that really depends on what the error is. Is it something that can be fixed by running it again or do they need to update some field.
@joshuawilson, thanks! IMO: point(3): Pipeline error happens due to Jenkins (idle state) issue, because others are straight forward steps.
@muruGanesan I think you should talk to someone on the build team, like @rupalibehera.
@joshuawilson, thanks. I will talk to @rupalibehera and @hrishin and get more info. Thanks again.
@gastaldi, Could please look at the above proposal and let me know your thoughts? I checked with 'the build' team and I was redirected to check with launcher team. In Brief: 1) During the 'App setup' - does the user encounter any error? 2) If yes, what kind of errors are expected?
CC: @vikram-raj, @joshuawilson, @nimishamukherjee, @sbose78
@muruGanesan it's hard to determine what kind of errors you may find since each step could throw errors, but the most common that I have observed are:
@muruGanesan it's hard to determine what kind of errors you may find since each step could throw errors, but the most common that I have observed are:
* GitHub repository already exists, * Failure on creating the Openshift resources due to quota limit reached
In such a case, would you suggest, the user to 're-run' setup again?
@muruGanesan it's hard to determine what kind of errors you may find since each step could throw errors, but the most common that I have observed are:
* GitHub repository already exists, * Failure on creating the Openshift resources due to quota limit reached
In such a case, would you suggest, the user to 're-run' setup again?
Sorry, by mistake I pressed 'close and comment' @gastaldi, Quick question: Let's say: there is an error (may because of git/quota). Option-1: Tell the user that, something went wrong. Go and look at the log file Option-2: Tell the user that, exact error scenario and the possible way to resolve Option-3: Tell the user that, there is an error + retry again > provide this issue can be resolved. If the "option-3" is NOT possible i.e. we cannot fix the error by clicking on "try again" - I would remove the button.
Could you please provide your input on the above?
Option 1 doesn't seem very user-friendly and isn't possible because there isn't a log file generated per request.
IMHO Option 2 and 3 seems like reasonable choices.
@gastaldi, Thanks, Click on 'Try Again' will restart the setup process again. Shall I finalize the below screen?
CC: @vikram-raj, @joshuawilson, @nimishamukherjee, @sbose78
"Try again" must have the same behavior as in the standalone launcher: restart the setup process from the step that errored.
"Try again" must have the same behavior as in the standalone launcher: restart the setup process from the step that errored.
Thanks George!
Here is the wireframe. Please review and let me know if anyone has any query. [NOTE: I am planning to close this ASAP] https://redhat.invisionapp.com/share/MHP7TIO3XYK#/332556493_ExistingFlow-_Start
CC: @joshuawilson, @vikram-raj , @sbose78 , @gastaldi , @nimishamukherjee, @serenamarie125
@muruGanesan , https://redhat.invisionapp.com/share/MHP7TIO3XYK#/screens/340614425 "view setup details" looks like the user would want to go to an application summary page and not the final step of a wizard.
What we are doing here in this design is to take the user to the last step of the wizard The wizard today hides out the context of the space it is being run in, and not something I would propose the user should go back to after it is done.
@muruGanesan , https://redhat.invisionapp.com/share/MHP7TIO3XYK#/screens/340614425 "view setup details" looks like the user would want to go to an application summary page and not the final step of a wizard.
What we are doing here in this design is to take the user to the last step of the wizard The wizard today hides out the context of the space it is being run in, and not something I would propose the user should go back to after it is done.
@serenamarie125, any thoughts on this?
https://redhat.invisionapp.com/share/MHP7TIO3XYK#/332556493_ExistingFlow-_Start
Hi @joshuawilson, @christianvogt, The above link is a final version of the UX recommendation. Please assign to the respective team/person.
CC: @joshuawilson, @vikram-raj , @sbose78 , @gastaldi , @nimishamukherjee, @serenamarie125,
Updated Description: This issue is around allowing the user to view progress of application creation at any time, after the launcher is complete. The Invision should include progressing from the launcher to the initial progress screen, and should also indicate how the user navigates back to view progress if the application creation is not yet complete.
Historical: As part of the design thinking session around Goal A - Consistency of Design Patterns, Address issues with navigation/wayfinding consistency was prioritized as an issue to address. The following suggestions should help provide context on the design direction: