Make WordPress Core

Opened 9 years ago

Last modified 7 years ago

#30170 new enhancement

"Start Date"/"End Date" are confusing in the exporter

Reported by: chrisvanpatten's profile chrisvanpatten Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Export Keywords: has-ux-feedback has-patch
Focuses: ui, administration Cc:

Description

I've been running a lot of post exports lately, and for some reason I'm constantly screwing up "Start Date" vs "End Date" when selecting an export range.

The right way is Start Date == Older Date, and End Date == Newer Date. But, because my memory is pathetic (at best), I constantly forget this and end up downloading empty exports.

I think there are a few potential fixes:

1) Change the wording, to something like "Start Date (Older)" and "End Date (Newer)", or different text entirely

2) Use some JS to alert the user/prevent the download if they chose a more recent month as the Start Date

3) Try to guess the user's intentions and download the export even if they screw up the order

(Or perhaps some combination of the three.)

Attachments (4)

export-start-end-date.patch (781 bytes) - added by herbmillerjr 9 years ago.
Swap start and end dates if start is more recent than end
export.patch (2.4 KB) - added by barrybell 9 years ago.
Removing ambiguity of the export Start Date/End Date fields.
museumofradioinbritishcolumbia.wordpress.2017-07-15.xml (2.9 KB) - added by adiant 7 years ago.
Empty Example
museumofradioinbritishcolumbia.wordpress.2017-07-16.xml (8.3 KB) - added by adiant 7 years ago.
Start < End Example

Download all attachments as: .zip

Change History (10)

#1 @johnbillion
9 years ago

  • Keywords ux-feedback needs-patch added
  • Type changed from defect (bug) to enhancement
  • Version trunk deleted

I've never had a problem with this, but I can see how it could be ambiguous. My vote goes to option 3.

@herbmillerjr
9 years ago

Swap start and end dates if start is more recent than end

#2 @herbmillerjr
9 years ago

  • Keywords has-patch added; needs-patch removed

I like option 3 as well. Gives the user the choice of doing either/or, so I'm thinking why not just swap the start and end dates before that part of the SQL query is constructed if, and only if, start date is greater than end date. I tested this with wp-admin/export.php with a couple of different combinations of blank, start, and end dates. Seems to do the trick. Don't know if there are any other parts of WP that rely on wp-admin/include/export.php though.

Last edited 9 years ago by herbmillerjr (previous) (diff)

#3 @barrybell
9 years ago

Is secretly switching input values around in the backend the absolute right way to handle this? Or would it be better to fix the immediate issue - ie, the ambiguity of the instructions - so that we remove any potential for confusion and create a better experience for users?

Regardless of whether we silently fix things for them in the backend, if they do need to pause for a few seconds to think about whether they're getting their dates in the right order or not then the UI isn't doing its job properly.

How about this:

4) Get rid of the 'Start Date'/'End Date' <option>s in the dropdowns and replace them with 'From' and 'To' labels. In addition, preselect the oldest month in the 'From' dropdown and the newest month in the 'To' dropdown.

Option 3 would certainly cover users if they screw up, but the language ('Start Date'/'End Date') is still pretty ambiguous, given that blog posts are usually ordered by most recent date first in users' minds.

Using 'From' and 'To' as labels for the dropdowns is a more natural way to ask a user for a date range in this situation. And by preselecting the oldest and newest months, we're also reinforcing the correct way to input the range.

What do you think?

Last edited 9 years ago by barrybell (previous) (diff)

@barrybell
9 years ago

Removing ambiguity of the export Start Date/End Date fields.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 years ago

#5 @karmatosed
7 years ago

  • Keywords has-ux-feedback added; ux-feedback removed

This is a little old but came up in triage of ux-feedback queue. I would also say 3 is the best option. However 4 looks a good option to avoid field name issues. As its quite old, can we maybe get a patch test and update - this may need changing.

#6 @adiant
7 years ago

Like most here, I have never had a problem with this, but just answered a Support question where this was the problem. I fail to see how it is not considered a Bug to create an XML file with no Posts in it when Start Date > End Date. Either swapping the dates or displaying an error message are arguably Correct.

Note: See TracTickets for help on using tickets.