-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
404 page with login button #8
Comments
Mentioning designers: @kunalsatpal @gouranshi @clinckzone @manya-s |
I would like to work on this. May I ? |
@Yavnikaa feel free to take this up! |
Since the other go back issue on 404 is connected to it's UX and I'll be working on it, toh can I take that one up to? |
No, it's alright. I am letting two people work on the same repository and the same function. There might be merge conflicts but there is a scope for learning git too. |
So, I read about 404 pages and worked on the user flow. What I've thought is that whenever there is a direct link (eg. launch of a new app), instead of the 404 page, users can be directed to the login screen itself. On logging in, if the user is authenticated and has access to the app, then well-in-good, he'll be taken to the app accordingly, else he'll be redirected to 404. On this 404, we can do away with the login button and will simply have the illustration, go back button and maybe a description that you don't have access to the app. This way, both the pain-points of not being able to find the login button on 404 and seeing 404 twice (after logging in) will be taken care of. |
Yes, that's what I was thinking of. We can have a prop passed to the 404 components namely With the prop we should this information to be passed through URL params, as sometimes the component is not used directly and apps redirects to /404 or similar URL. In that case, we can have /404?checkIfLoggedIn=1 or 0 to pass the same information. Checking if the user is logged in should not be done by making a user authentication request again, if possible we should use the one already requested and stored in the redux store. |
Here, user will still have to see 404 twice. Like, if checkIfLoggedIn prop is false, he'll be taken to 404, will login, and again 404 (if the app is not for him). I like the idea of passing this prop but what I'm suggesting for the case when the user is not logged in, we'll redirect them to the login page (no 404, directly the login area) and there, after logging in, they'll be taken to 404 or the app, accordingly. On, the 404 we can simply have the illustration, go back button and possibly a description that sorry, you don't have access to this app. |
Oh okay, that's also a good idea. We can proceed with this. But it will be better if it is handled by the 404 page only (i.e. 404 component redirects to the login screen if required, not showing the 404 page) as otherwise, this logic needs to be handled individually by developers each time. |
Yes. I meant the 404 component redirecting to the login screen directly only without showing the 404 error page, otherwise toh chaotic ho jaega. |
The current structure of the omniport is such that we can't decide for a non-logged in user that the app should be seen or not by them. So, we simply show a 404 to an unauthorised user, when they hit any Url which doesn't match with any service (as going on service shows Login). But it creates a lot of confusion among users as they saw 404 whenever a new launch is there and they visit the link in the post. The Login button though is seen on the NavBar but is difficult to locate for many.
The issue is there with any role-based platform. We should search for some solution here. GitHub is one example but GitHub users are very different from the audience a platform like Omniport catters.
One of my suggestions would be to have a prop to the 404 component which can decide that if to show the login button. It will show something like "You may need to Login" and the button. The demerit of this solution is if some person login through the button for whom the app was not made, it will get a 404 eventually. That can be a bad experience like suggested login by platform and then giving a 404.
The text was updated successfully, but these errors were encountered: