Hot answers tagged

121

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


71

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.


27

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


20

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


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


7

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


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

The time element is a machine-readable element. So it is mainly used to help out the computer not the user directly. https://css-tricks.com/time-element/ The element in HTML represents a machine-readable date, time, or duration. It can be useful for creating event scheduling, archiving, and other time-based functions. and The uses of ...


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


4

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.


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

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

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

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

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

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

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

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

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

As you are showing a partial segment, a week, formatted as one normally does in a month-by-month calendar, UP would be the expected direction for the previous week and DOWN the direction one would look to find the next week. To clue in the user, I'd add the words LAST WEEK above the top arrow and NEXT WEEK below the bottom arrow.


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


2

It might be confusing at first, but the disambiguation comes quickly: Showing data for the month before the current one exclusively is silly. No one would consider such a feature. As soon as you click on it, you'll see what appears. You may also add the indication of the precise time range somewhere (with actual dates) after the user selects one option. ...



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