Hot answers tagged

115

Imagine you’re telling a friend a story about a time you took a flying class. You want to give an idea of when the story takes place. What format should you supply the time in? Should you say “The date was 2014/12/31 and the time was 16:05:03 PST”? Of course not. The point of the story isn’t the exact time you took the class. You want to focus on ...


47

Not enough reputation to comment, but on many sites with this "friendly" time, you can actually hover to get the exact time. Try it over on this question's "asked" and "active" times on the right hand side.


24

This is the use of relative timestamps. In relative timestamps, accuracy isn't important, and immediacy of scanning prevails over accuracy, so things like this may happen, where you see "1 year ago" until Aug 15, 2015, where you'll see 2 years ago. There's a lot of controversy about this approach, and IMHO, it's correct that you could add something a bit ...


12

You've caught a common bug (IME) in the implementation of these relative time/date stamps -- at a step-change in the precision you lose a lot of information due to rounding, and the rounding is always down. It's common (I assume due to a built in library) on Android apps to get "59 minutes ago" (more precise than needed) then "1 hour ago" displayed for the ...


10

If 90% of scenario is covered by Today+10 days, then perhaps something like this could work, without having to worry about Next | Previous or losing your current place. It takes up more space, but it's also less finicky. download bmml source – Wireframes created with Balsamiq Mockups Today is indicated as bold. You also need month, because ...


5

When to allow future dates What happens if a user enters a date range that extends into the future? Is anything ever displayed, such as planned events or predicted data? If so, then users have a valid need to select future dates. If you do allow future dates, make sure that your date picker clearly indicates the current day so that it's difficult to ...


5

Have you thought about whether there is a preference for weekends / week days in the selection and highlight vs grey out the sections that are less important? Concept 1 I think just a simple Next / Previous with a hidden calendar that can expand beneath it should work. As per the comments here's a modified version, showing today: There is no other ...


5

Stick to conventions and consistency This is really simple: if user is charged on day 5 of the month, he should be charged on day 5 next month. Most users plan in anticipation and they know that every fifth day of the month they will be charged for a service. Otherwise, see what would happen January 5 February 4 March 5 April 4 May 4 June 3 July 3 ...


4

You can tell better but since you mentioned that 90% time the dates will be within next 10 days - I am assuming that the user pretty much starts off with a date in mind, rather than thinking which date to pick. So in essence he/she is clear with the date (which is approaching soon), and just needs to select what is in mind. With that assumption, check the ...


4

You don't need to over think this. Unless there are regulatory constraints it can be whatever you want it to be and your users will take it as corporate policy. (By the way is there existing corporate policy relating to the definition of a month in other areas? If so leverage those decisions.) If you want to be thorough, and have the time and resources, you ...


4

I might lean more towards my left mockup, just for the sake of being explicit. The left one is a bit more explicit with the exact times for the courses, but the right is a bit cleaner (if you think users will notice the message--this could be tested though). I lean towards spelling out the dates when possible to accommodate users who come from different ...


3

One plausible UX reason for this is preventing the situation where a user sees a date, fails to notice the year, and due to the proximity of month/day, assumes that the post was made within the past few days/weeks rather than (possibly many) years ago. This sort of user error can lead to embarrassing answers/comments/follow-ups on content where they're no ...


3

This sounds like a timeline to me. There are controls available that look something like this: or this: Of course yours would have time on both x and y axis! You could have flight timeline listed on the y axis, and then dates across the x axis, and schedule prices using the little bars. In what I imagine, the bars would span more than one row, so I ...


3

This is a bit of a "Apples to Toboggans" comparison. Your first date picker with individual year, month/day/year selections is functional and will let you pick any potential date. (We can't tell from the screenshot but I'm going to presume you can't pick Feb 31st... e.g. there's some logic to filter the options to ensure validity) In a typical scenario you ...


3

What's the user's goal? Clearly, the design is intending to let the user set a recurring monthly reminder. At least, that's clearly the intent on the 1st through the 30th of the month. Would it be wrong to simply round down any number that exceeds the number of days in a given month? That is consistent with the intent. Because, seriously, I can't think of ...


3

I do not agree a spiner is the fastest way. It may be fast for birthdays if you are young enough or if the date is near the default... But i hate that scrolling, it takes much longer than 3 fields and a numeric keyboard. What is faster: scrolling up to 30 days, scrolling up to 11 months and scrolling 42 years OR just type 8 numeric values?


3

Specifying the timezone directly in the timestamp is neither good nor bad practice. The answer to your question has more to do with your user experience than any documentation or timestamp formatting. You stated one or more of your users requested the timezone be added to your timestamps. This would imply your timestamps are currently ambiguous, which is ...


3

Without knowing the full context of your question, I would start off with the lowest common denominator and expand out from there to a maximum of two levels. What I mean could be expressed by the following rules or formulas: w days late (where w = 1 to 6) x weeks, w days late (where x = 1 to 3, w = 1 to 6) y months, x weeks late (where y = 1 to 11, x = 1 ...


2

Using calendar-like UI for managing schedules/events is good. To provide better user experience, you need to use the Calendar UI as primary control. This means you organize flow in the following sequence: Set date/time date using the Calendar UI (direct manupulation) Set additional data (Customer, Address, etc.) (Optional) Adjust the data: a) ...


2

I'm going with the assumption all calendar days offer the same tour, 1 tour a day, happening at the exact same time. But some days are more expensive than others. Price is set per person/seat. You would like visitors to sign up for a seat. Because you're showing a couple pieces of info for each day. It's likely going to be too cluttered/confusing to try and ...


2

The simplest solution I can think of is a numerical text input followed by a drop down for unit size - something like this: download bmml source – Wireframes created with Balsamiq Mockups


2

I recently provided an example of an app I was working on for this exact use case, a nurse entering a patient's birth date: Should I ask the user to enter their age or their birthday?


2

I agree with the octern that it depends on whether choosing a future date is helpful or not... An example of how this is done today is how Google Analytics shows their date picker. Since there is no valid state for a report of the future they gray out the content:


2

Which one is better The one that fits the needs of the particular date better. Context is everything. If only the numeric date is important, your first option is nice. If understanding the particular day-of-the week is important, the calendar is nice.


2

It depends on the other timestamps you display on your site/app. However, timestamps are almost always used to compare events relatively in a single timeline, so in almost always, it's better to stick to one timezone. Give the user an option to select their timestamp. Always load the user-selected time zone, and convert all timestamps to that timestamp. ...


2

There's an interesting paper called How Languages Construct Time by Lera Boroditsky that talks about how the mental representation of time is affected by a number of factors. This is the part of the summary: Across the studies cited here people in different cultures or groups have been shown to differ in whether they think of time as stationary or ...


2

Since you're developing an app for iOS, the best approach is to follow the patterns used on this device. It is more likely for users to understand and like your app, if they don't have to learn how it works. That said, iOS Calendar should serve as a guide when you are in doubts about UI solutions. When there is no start/end time specified assume the meeting ...


2

I'm not aware of any studies for this but I would say there are a couple of possible answers. If you're displaying time in 12hour format (i.e. 10:00AM and 10:00PM) then you could easily display hours below 10 as a single digit. On the other hand, if you're displaying time in a 24hour format (i.e. 10:00 and 22:00) then you're more likely to find that a ...


1

Solution1: Graph Interface A chart that plots price against time is a probable solution. The graph here need to act as a visual form for the user. Internally as the user interacts with the chart, an array of the price information can be built and sent to backend. This solution is suitable for longer date ranges with frequent and granular price ...


1

I assume it depends. Both version have pros and cons and you have to weight them to see which one fits better to your task. For typing in a birthday, the first version is better because you think in terms of month/day/year, the date is far away from the current date and you don't really care about the day of the week. For scheduling a meeting sometime next ...



Only top voted, non community-wiki answers of a minimum length are eligible