Skip to main content

Posts

Showing posts from May, 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 shou

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:

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