marklogic-community
Guidelines for refresh values (reputation, vote counts) & layout (answers sorted by votes and accepted)
Selection of an accepted answer should not cause the order of the answers to change until the next page refresh.
From @yawitz audit.
Let's discuss along with sort based on votes. There are a number of tech. reasons why I think we shouldn't implement this as spec'ed.
I'd like to be involved in this discussion or the outcome.
re: UX - I didn't previously realize how jarring it was as a user with automatic update until I tried it. Awesome that it works so fast, but also disorienting when the item you were just interacting with suddenly jumps on the page.
re: Technical reasons - Would like the debrief on the impacts/differences.
The issue is that the this would introduce s very strange state in which the browser needs to keep a list of what not to sort. In a multi-user environment votes/acceptance will change in the background, as well, and these also impact sorting.
My recommendation is that we fix the "jarring-ness" and allow the sort to remain natural. I think animating the transition would do the trick very nicely. I will work up a demo -- should be easier and cleaner to code that and avoids some sticky questions about how/when to allow sorting and when not to.... (this applies equally to #430).
Broadening the issue and would like to explore overall refresh strategy - when values are updated and when layout is updated.
Current wireframes:
"The application of a vote, or the selection of an accepted answer, should not cause the order of the answers to change until the next page refresh."
which would result in 2 bugs in current design wrt layout update:
- Do not reorder answers on answer acceptance
- Do not reorder answers on vote
Further issue is that reputation for logged in user does not update until hard refresh (Ctrl+R). It should update when page is re-drawn for any reason, such as navigating back to Samplestack home page (values update).
We could consider doing simplest approach and continuing to allow dynamic sort for layout update but want to be intentional about the options, decision and impacts. Would also like to understand limitation for improving immediacy of values update (for logged in user).
Let's discuss.
Further issue is that reputation for logged in user does not update until hard refresh (Ctrl+R)....Would also like to understand limitation for improving immediacy of values update (for logged in user).
This is fixable regardless of what we do about the reordering. I don't think the reputation issues bug should have been closed tested/shipped so quickly. I think it still needs work if refresh is required (it very well may need work in the browser, I really don't know yet -- I was expecting to have a chance to validate before QA testing).
That said, I don't think we should conflate this with the reordering issue. Fixing the reputation update issue won't result in strange code and will result in the application displaying the truth.
Suppressing the natural (ultimately correct) of the answers would result in strange code which takes time to write and write correctly, and exposes further complications in design that haven't even been discussed yet. (It also hides the truth and becomes even thornier when you consider the fact that this is and needs to be built as a multi-user app). That's why I'm proposing to animate the reordering to ease the "jarringness" as an alternative.
Animation can help, but not eliminate, UX problems in many cases. It may be OK as a stopgap, but I asset it will be only a partial solution. Propose we have this discussion in real-time, since this raises some important but possibly complex UX issues that are hard to express in this linear text context.
Setup time for @yawitz / @laurelnaiad and me to discuss on Tuesday 1/20 but I may push it because if we don't get this resolved for 8.0-1 its okay. Should still come up with best approach technically and UX-wise.
I could not find any reference to this issue after a web search, so I've posted a question on this topic to ux.stackexchange.com: http://ux.stackexchange.com/questions/72048/editing-multiple-entries-in-a-list-should-you-disable-dynamic-sorting
Let's see what the larger community thinks...
You mention in the question you asked on ux that you read http://ux.stackexchange.com/questions/56780/editable-row-in-table-should-you-disable-the-sorting . The ony answer with any votes says:
A possible solution would be to show where the row landed by scrolling the entire table up or down after the edit is complete, then showing a highlight around the position of the new location"
This is pretty much like my animation proposition.
You also posit that there is a distinction between the use case in that question and ours. What is the distinction?
The answer to the existing question addresses making multiple changes to a single item (a row in a table in that case). As I tried to explain in my posted question:
In that other question, the focus was on making multiple changes to a single item. I'm looking for guidance on how best to handle edits of multiple items in sequence.
In other words, I want to support the user that wishes to go down the list of answers, and optionally vote for each one in turn. If the list resorts after each change, it will be hard to keep track of one's place in the list.
Thanks. I think there are may be some nice ways to accommodate that use case other than by holding down the sorting. What strikes me is that the use case you describe would benefit from not scrolling the page, in particular (as opposed to moving the freshly "touched" content into its place). It would also benefit from showing the user that they've voted an answer/question in a particular direction.
It occurs to me that we stil may not have a UI indicator for which way a user has voted a content item. Did we want to make the associiated vote arrow orange or something in these cases? (cc @wooldridge )
The design already calls for showing the user which way they voted. Perhaps this isn't working at the moment?
NOTE: In Stephen's mockups:
- Initially, both buttons are blue/enabled.
- After voting, voted button is green, other is grayed out.
This, of course, applies to logged-in users only. Guests show both buttons grayed out.
@wooldridge, as you look at this for button style fix (and I can confirm it's not right yet), please also know that the tooltips, at least on the branch I'm looking at right now, are also incorrect after voting (they are disabled as they should be, but the message says "you must be logged in to vote", instead of something like "you've already voted". I'm not sure what the correct verbage is but I assume it's in the spec.
Will check on the tooltip issue once the @clockworked247 tooltips have been merged, I believe the PR is here: https://github.com/laurelnaiad/marklogic-samplestack/pull/50
Moved side conversation about voting buttons and tooltips to #478. Pushing the main issue here (dynamic sorting) to 8.0-2.
Kasey found an excellent example in the wild: Amazon Q&A: http://www.amazon.com/forum//ref=ask_dp_dpmw_al_hza?asin=B00J46VVKE&cdSort=best
Here, the list does not automatically re-sort when you vote on a given question; you need to refresh the page to see the effect. (Kasey also made the good point that, since the answers are paged, you wouldn't want a 0-vote question on, say, page 4, jump to page 1 if you voted on it.) Given the variable, sometimes long, lengths of the entries in our lists, it becomes even more important to maintain a stable view/context of the list.
I hope this example provides good evidence for the wisdom of not dynamically resorting when voting.