Take this paginated data set as an example.
The user can change the order, and changing the order doesn't affect the total number of results returned.
If the user changes the order, is the any common consensus for if the page should be reset back to page 1, or stay on what the user is on?
As explained in Sorting a Paginated Record Set User Experience Expectation, and as illustrated there by the following order of data transformations:
You can see that both filtering and sorting come before pagination.
This means that whenever the order changes (sort), you should repaginate.
Whether or not you should go back to page 1 depends on the context:
Concretely in your case, once on page X and the order changes, page X most likely refers to the previous user query, not the current one.
Most of the time people go to the next page because their query wasn't answered by looking at the first page. In this case, re-ordering the data means a new attempt to answer the query (ie, locate the desired data) and in most cases this means starting from page 1 all over again.
But this is not always the case.
Say the user wants to know what item is at position 22 (say which is the 22nd cheapest item), then throwing back to page 1 after sorting is NOT a good thing.
There are more examples in the comments.
So it all depends why the user is on any page other than the first one to begin with.
Keeping the page number after changing the order makes no sense. The page number is the same but the page isn't, let alone that going back or forth between pages lost the idea of coordination. What use would that have for the user? If you test this on real users you can expect them to be confused by this. They probably expect to see the first result on page 1 after the order has changed. If you can, test this as early as possible on users or just show it to people around you and see/hear their reactions.
EDIT: To those stating that it can be useful to have the selected/active element still visible after the order has changed. There are cases where this is the required behavior, but that still means that the page number can change. It will show the page where the selected items appears after re-ordering the items, which can be a different page with different items surrounding the selected one. The only case when it is useful to stay on the same page is as @Izhaki answered, when the position of the selected item is important to the user, but I thought it's fair to assume that that is not question.
Note that there are cases when it makes sense to not reset to the page one—when there's a notion of the ‘current selected’ or focused item in the list. Examples are mostly desktop apps with emphasis on immediate user interaction in the list itself with the help of the concept of ‘focus,’ instead of jumping between views like in web apps:
etc.
In such cases, after a change in the sort order or in filters it makes sense to keep the focused item on the screen and selected. I.e. to find the item in the new list and jump to that page.
If a web app has a similar workflow, with the focused item being displayed and manipulated on the same screen as the list, then it might be prudent to borrow this feature too.
A sort order change should lead to a page reset (to one) when nothing is selected in the results list. The user has not yet shown specific interest in a particular entry.
If, however, there is a selection (especially in lists that have a master-detail view), it is likely the user wants to see "what is around the selected entry" - In this case, the page should not be re-set, but rather re-centered around the selected entry. It is confusing when the selected entry is suddenly paged out of view. (This also seems to be standard MS Windows design). This obviously implies you should not be presenting the same page that was show before, but the one where the selected entry is going to end up up with the new sort key - which might end up in quite a bit of a daunting task in a web-based application where the server supplies entries in chunks.
This may lead to a conflict when a list allows multiple selection of entries - In case these entries would be spread over multiple pages when re-sorted, it's probably best to remove multiple selections altogether in this case.
There would be a weak case for not resetting it:
User wants random samples that avoid being at the extremes of any sort order.
This certainly does not make a good default, but might be useful if selectable as an option.
If changing the sort direction while not changing the criterium, browsing to the page that has the most of the items that were visible before could be the most intuitive way, since it allows keeping context.
What might, in some cases, also be a useful option when the criterium is changed is to allow one list item to be marked (or, using the last activated item), then to change the sort order, and browse to the page where that item appears with the sort order changed.
I am a back-end programmer and not UI expert at all
Let say data shown in your screenshot is is sorted to Oldest First and user is on page 20
Then user thinks he wants to see newest items, so he selects Newest First, if you keep him on page 20, will he see the newest on page 20? NO
In short, pagination should be reset upon change of order
