Hot answers tagged

114

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


46

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


9

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


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

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


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

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


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


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


1

Like others have said, this is almost impossible to solve for the general case. Knowing the actual parameters, however, a tailored design can be developed that covers most cases (e.g. Pareto’s 80%:20%) well and still supports the exceptional ones. If we have to consider only the working/sunlight hours for the week or 5–10 days following today and half-hour ...


1

There isn't a dead simple solution to this, but here's the simplest way I could think of: http://jsfiddle.net/b3f6wvyp/1/ Allow the user to specify 1 or more time windows. A time window is comprised of a date and 2 times ('from' and 'to'). When a new time window is added it copies the contents one currently last in the list. The input widgets I used for ...


1

your problem needs breakdown.i think there are two kinds of issue, the date range you want to repeat and another you don't. No Repeat: This week I am available weekdays after 6pm, except for Thursday, and also all day on Saturday Repeat: 6-10pm each weeknight I just designed UI that might resolve your both problems. have a look below. In each day, you ...


1

Unfortunately, calendars are hard for people to understand and use well and consistently. What about allowing people to respond with text availability and then you code that into something? If you have a few hundred users right now that probably isn't too bad for a CS person to take care of while you scale a good solution. You could even do A/B testing ...


1

The amount of effort you should put in to fix something depends on 2 things How significant is impact? How likely is it? In the given example The relative times on social media (i.e post was 1 week ago, 3 hours ago) is a trivial item PC's have a very strong tendency to be kept close to the correct time Thus in combination zero effort is the right ...


1

Firstly, being registered and being active are different. You can have registered customer who are not active in your system. Active for shall be used for the customer who are active in your system. Being precise and relative are not the same thing. Registration date can be shown absolute (DD/MM/YYYY) or relative (x +- 31 days/hours etc..). The other ...



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