Skip to content
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

Open
pradumangoyal opened this issue Jun 15, 2020 · 10 comments
Open

404 page with login button #8

pradumangoyal opened this issue Jun 15, 2020 · 10 comments
Assignees

Comments

@pradumangoyal
Copy link
Member

pradumangoyal commented Jun 15, 2020

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.

@pradumangoyal
Copy link
Member Author

Mentioning designers: @kunalsatpal @gouranshi @clinckzone @manya-s

@Yavnikaa
Copy link
Member

Yavnikaa commented Sep 3, 2020

I would like to work on this. May I ?

@algomaster99
Copy link
Member

@Yavnikaa feel free to take this up!

@Yavnikaa
Copy link
Member

Yavnikaa commented Sep 4, 2020

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?

@algomaster99
Copy link
Member

algomaster99 commented Sep 4, 2020

@Yavnikaa which one is that?

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.

@Yavnikaa
Copy link
Member

Yavnikaa commented Sep 6, 2020

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.
@pradumangoyal @algomaster99 shall I go ahead with this approach?

@pradumangoyal
Copy link
Member Author

Yes, that's what I was thinking of. We can have a prop passed to the 404 components namely checkIfLoggedIn or similar, which if set to true will check if the user is logged in and if not will show an additional message with a login button beside the Go Back button. and if the prop is set to false, it will normally show a Go Back button only that is its default behaviour.

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.

@Yavnikaa
Copy link
Member

Yavnikaa commented Sep 7, 2020

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.

@pradumangoyal

@pradumangoyal
Copy link
Member Author

pradumangoyal commented Sep 7, 2020

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.

@Yavnikaa
Copy link
Member

Yavnikaa commented Sep 7, 2020

Yes. I meant the 404 component redirecting to the login screen directly only without showing the 404 error page, otherwise toh chaotic ho jaega.
Alright then, I'll get on ahead with the code with this flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants