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 ...


107

|All| or last | 365 | 30 | 7 | days


59

Consider this: | Past year | Past month | Past week | This is much less likely to be misunderstood than "last year", and is a common way of presenting menus for selecting a time range. For example, the filters for Google search and Reddit's top posts use this exact wording.


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 ...


21

Given today's date, 6/20/2016, I offer my users these choices: Today 6/20/2016 Yesterday 6/19/2016 Last 7 Days 6/14/2016 - 6/20/2016 Last 30 Days 5/22/2016 - 6/20/2016 This Month 6/1/2016 - 6/20/2016 Last Month 5/1/2016 - 5/31/2016 This Year 1/1/2016 - 6/20/2016 Last Year 1/1/2015 - 12/31/2015 All Time First ...


18

I would skip the 'Last' altogether and go with Lifetime | 1 year | 30 days | 7 days At most it would take the user one try to remember what it means, especially if you display the date range of the selected period once selected


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 ...


11

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 ...


5

A screenshot from iOS Health app: No past or last. Simple. Understandable. Fit for smaller screens.


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 ...


3

download bmml source – Wireframes created with Balsamiq Mockups The dropdown menu is a better idea, and it fits on most screens. Also, you should include a "custom" option. You can't imagine how many people are FRUSTRATED everyday because THERE IS NO CUSTOM OPTION! That said, the mockup is an example of a diary app with the dropdown menu.


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

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

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

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. ...



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