Closed acrollet closed 1 year ago
@loripusey @benbrasso-agile6 here's a stab at a story to cover what we were discussing this morning.
I'm creating a few mockups around ways to handle closing the active sessions, but have a few questions for @benbrasso-agile6 and maybe @acrollet or @brianseek could answer as I build out these mockups: Questions:
Are we solving for day of or pre-check-in? I thought the conversation has been around day of? But, now this ticket is about pre check in. Just want to double check.
I'd be in favor of a coworking session between the 4 of us to tackle this ticket.
@benbrasso-agile6 Thanks! Those answers make sense to me. I can definitely set up a coworking session. I'll do that here shortly!
The other factor here is the speed at which the API team solves for some of these scenarios via redirects. We briefly touched on that ticket that's with the API team in scrum this morning.
Although, I guess their work won't resolve the majority of what we're trying to solve for.
Let's use this ticket for day of, I'll create a separate one for pre check in to tackle another day/sprint
Notes from today's meeting: https://app.zenhub.com/files/133843125/5ddc65dc-f97d-46d8-835c-1346136d1577/download
I removed the missing uuid widget from the check in GA dashboard.
This error will still populate in the errors widget as www.va.gov/health-care/appointment-check-in/error?error=no-token
If/when we create a new page (e.g., /no-token) for this type of "error," theoretically the number of www.va.gov/health-care/appointment-check-in/error?error=no-token "errors" will be reduced.
If/when we add this new page, I'll make room for it somewhere in the GA dashboard.
Ticket created for pre-check-in https://app.zenhub.com/workspaces/check-in-experience-61fc23a2cb8a14001132e102/issues/gh/department-of-veterans-affairs/va.gov-team/51411
Pull into whichever relevant sprint
Updated design for possible solutions for check in
Nice, Kelly. I'm going to leave a couple thoughts in slack.
I feel like these solutions don't really solve the problem of vets using old links but just work towards some clarification; perhaps the unified experience can work to solve this problem.
Ideally if they access an old link under these scenarios, this is what I would expect as a user:
Whether this is even possible without completely re-architecting, I don't know. I think we have to weigh the effort versus the value to end users to change it. I think the architecture for having a link that expires is a valid one and I have seen it used many times out in the real world, but it seems that there will always be folks who don't get it.
I still think that UX's ideas for unified experience will certainly go a long way towards solving this problem. Perhaps we shelve the "end of interactions" discussions or incorporate them into the unified experience discussions. Thoughts?
@benbrasso-agile6 @acrollet @kellysmith1008
Am going to chat a bit with the ux team about it.
If I recall correctly, we're really solving for how we're tracking and interpreting this scenario in GA. Historically, this scenario throws caution to us because it's presented as an "error" in GA, when in fact it's not really an error.
I don't believe there's much of anyone actually trying to check in. Therefore, it doesn't seem worth trying to rejig our architecture to try and somehow recreate a UUID on the fly.
I can see the ux team finishing this up in a day or two, so, if we want to proceed with engineering, that would be nice. It would be a way for us to no longer interpret this as an "error" in GA and throw caution. Plus, the very small percent of Veterans that ARE trying to check in will have a better solution than what exists today.
So, why is this not an engineering problem to solve?
ux and engineering met together last week. We're working on giving the wireframes as a result of that conversation.
Merged a bit of conversation and input around this and created this mockup as an iteration - @zach-park or @ytsaoca to create the branch in abstract if time. I can do it if they don't have capacity.
- I use an old link and I DO in fact have appointments for today --> I am taken to check-in where I can verify my identity and then see my appointments for today and check-in if I am in the check-in window
- I use an old link but I DO NOT have any appointments for today --> I am taken to check-in where I can verify my identity and then see that I DO NOT have any appointments for today
just to clarify, when a veteran accesses a pre-checkin link, we don't know if they have appointments for today or not, we only know the time of the appointment associated with that pre-checkin UUID.
Just making sure we don’t get confused… this thread is for the day of app reopening for an expired session
Just making sure we don’t get confused… this thread is for the day of app reopening for an expired session
very good point, I hadn't realized that until a few minutes ago!
the summary does mention pre-check-in as well, should we split that into a separate story?
Yes it’s located here https://app.zenhub.com/workspaces/check-in-experience-61fc23a2cb8a14001132e102/issues/gh/department-of-veterans-affairs/va.gov-team/51411
great, I updated the summary to remove references to precheckin.
sorry, I have COVID brain, just ignore my comments.
Am going to chat a bit with the ux team about it.
If I recall correctly, we're really solving for how we're tracking and interpreting this scenario in GA. Historically, this scenario throws caution to us because it's presented as an "error" in GA, when in fact it's not really an error.
I think there's more nuance to this, at least from my standpoint. We've noticed the issue because it surfaces as an error in GA, but it's happening when veterans are seeing an error page when they didn't do anything wrong, which seems like a negative interaction to me.
If a user opens a check-in page without a current valid session, this user may assume that he should have a valid session to check in. I think this page was created for this scenario.
Any thoughts?
@benbrasso-agile6 @kellysmith1008
Oh nice @ytsaoca ! I think this is more for when they are trying to reopen an expired session, what that error message looks like. But this wording is very similar, so I don't know if we need to make the distinction between the two errors - no valid session vs reopening and expired session. I'll let @benbrasso-agile6 weigh-in when he gets back in on Tuesday. But I didn't know that page existed - sorry for possibly duplicating work!
No worries! Yeah, we can discuss if we want/ need to make the distinction between no valid session vs reopening and expired session!
I haven't seen that wireframe before and it is not in the master branch. I'm not sure the application uses a page like that. It might, but I haven't seen it before in staging or production (or in master).
The page that users see is actually this one: https://share.goabstract.com/42ad6c8a-1e51-458c-a098-61838b01602b?collectionLayerId=068b5f51-db74-44a4-abb6-b3edfb1ab9d5&mode=design&sha=latest
And, because this is the "general" message, we are actually creating a new error page specific to an expired session. I think Kelly's concept works really well for this scenario.
Final mockup: https://share.goabstract.com/4d46f6ca-4303-4a55-89a2-686f13514d50
Reviewed by @kellysmith1008
@ytsaoca @kellysmith1008 Looks nice!
Should we put a period after 53079?
Should we update the Need help? content to be consistent with what's on production?
For questions about your appointment or if you have a health-related concern, ask a staff member at your VA health facility.
Does the FE team know this is ready to be worked on?
@benbrasso-agile6 @ytsaoca Yes, let's add the period after 53079 - my mistake, I missed that. Yes, @ytsaoca let's update that text to "ask a staff member" instead of "call your VA provider" - and remove the link under. I'm sorry I didn't catch these in the screenshot you sent. It's my lesson learned by reviewing it while I was in another meeting. I'm sorry about that!
So, this new wireframe would ONLY show when there is no LOROTA entry for them (i.e. it has been deleted or doesn't exist); is that a correct statement? Also, other than the period, is this now ready for engineering to work on it? @benbrasso-agile6 @kellysmith1008 @ytsaoca
All, please make sure when we close these tickets that we have a mechanism for actually getting the work onto our backlog. I'll create a work ticket for now, but we need to make sure we don't drop the ball when the wireframe is done. cc @sarahknoppA6
One other comment I'd like ux to take a look at is:
Should C in Check in be capitalized? Seems unusual to have that capitalized in the middle of the sentence.
I believe our posters use bold for "check in" and "53079." Ya-ching, should we look to be consistent in how we're styling the phrase, "Text check in to 53079."
@loripusey it's possible there's still a scenario where a user will get to http://www.va.gov/health-care/appointment-check-in/error?error=no-token. @acrollet and @brianseek would be good to weigh in here.
But, yes, this new page will be something like http://www.va.gov/health-care/appointment-check-in/no-token
Thanks for reviewing it. @benbrasso-agile6 @kellysmith1008
Final mockup: https://share.goabstract.com/4d46f6ca-4303-4a55-89a2-686f13514d50
Very nice 👍
@loripusey Sorry for not syncing with you to have a mechanism before closing the ticket. Will make sure doing it in the future!
@benbrasso-agile6 Do we want to change the Need Help of other error page, too? If yes, do we need to have ticket for this?
It's more than the error pages. I think the plan is to update all of them in check in once @zach-park pushes this branch to master, which will happen in 2-3 weeks when we're ready. So, I think we were just waiting for this to happen, and then they will all update for check in.
If it's easy to push that Need Help content into master now, I don't think anyone would be against it. I think the reason we haven't done that is because it was sort of stuck in that travel branch that isn't ready to go into master yet.
@loripusey , The mockup is ready for the FE team to work on. Thanks!
Background
Similar ticket that contains potential solution
If a user opens a check-in page without a current valid session, we show a generic error page. This might be confusing/worrying to users and give the impression that they have done something wrong.
How might we improve users' interactions after they have completed their task?
(Proposed) User Story
As a Veteran, I do not wish to see an error when re-opening my browser after using day-of check-in, so that I do not think I have done something wrong.
ACs
TBD