Tuesday, November 8, 2016

Login form authentications

We have been using login forms from many many years now. As the web is continuously evolving these form have gone through many unnoticed changes over all these years.

There was the first era of showing fields like username, password, remember me, forgot password, need help, reset, and an anonymous question mark which was too much to think about and proceed with the login process.

Gradually, these forms have become shorter and shorter with only username and password fields because that's what the user is actually interested in using as interaction elements to accomplish the task.  

The validation process:
Ever since beginning websites do validate both the username and password fields, but there are another type validation requirements; such as, for security reasons some websites don't validate usernames; the login process is only completed after typing a correct password.

In such cases we face some common questions like:
1. Should I use the current trend of showing username on first screen and password on second screen?

2. What will happen if the authentication fails on second screen?

3. Should we redirect the user to first screen with a message 'your username or password is incorrect'?

4. Or should we use the traditional username and password fields on same screen and then so the failure message, and if we do which field should have a focus?

A lot to think on....

The best bet here would be to use the traditional login form with username and password fields placed on same page with a forgot credentials link in case if the user doesn't remember his credentials (username and password both), and a signup link for new users.

What about the focus?

Well, when you are not validating the username field there is no point in keeping the typed username in the field after validation error as there is a possibility that the username also could be wrong. So it's best the system resets the form entirely with a focus on username field.



Sunday, May 29, 2016

Mobile app notifications for business meetings

Annoying notification is one of the top reasons why people uninstall mobile apps, so the notification designers have to be very careful while designing their behavior.



At first the app should ask users as to when they would like to be reminded about the meetings, because the user behavior  vary; some people might want to be reminded a day before and also 30 minutes before the meeting starts as they might have to prepare for the meeting; and some people might be just ready to jump into the meeting without any delay so they would want to set the reminder to 5 minutes. So, let the user set time to receive a notification.

Once the notification is on screen; the user should be able to dismiss it or open the meetings app - this feature can be used with the slide option.

In case if the user doesn't attend the meeting and the meeting time is over, then the notification should still sit on screen but in negative state to let the user know that he/she has missed it. And there should be an option to dismiss it or send a message to the meeting organizer with the reason why the user couldn't attend the meeting.




Saturday, May 28, 2016

UX patterns for dates

Generally, users are quite fast at entering dates into input fields rather than selecting one from date picker. One reason why many web applications provide date pickers is that user may not be accurate about what date would it be on next Thursday.

The best approach would be allowing the user to enter/type date, and show a date picker on mouse focus. While using this pattern you have to make sure that the validations are working just fine as the user may enter dates in different formats such as:
01/01/1956
1/1/1956
01/01/56



Date & Time
In many situations date and time is combined together and many designer find a way to implement it in a better way every time. Here are some best ways to implement the date and time controls together:

Display the dates of course where students can apply as per their schedule considering they don't have to select from different months and the time is fixed:











Thursday, May 26, 2016

Mobile device volume controls Vs app volume controls

Should mobile apps have volume controls or they should use the device controls?

This question has been raised by many UX practitioners; the answer to it is mobile apps must have their own playback controls, but their functionality has to be synced with the device controls as well.

Reasons your app should have volume controls:
1. The inApp controls give the user the feel of carefully developed application which has all features of its own.
2. The user feels more in control rather than depending on the device.
3. Most mobile users don't use the device controls very often as they are a little careful that overuse of those hardware buttons would might cause damage.
4. We should not ignore the possibility that the user's device controls could already be damaged/non-functioning.

Many people are also having debates on the Mute feature as well. I think you should never use the device's mute feature as it may mute all other applications as well, for instance: A Phone Call.