[IMP] survey: improve sessions fade in/out delays

PURPOSE

Improve the various sessions flow to make it easier for attendees to reach the
session and to allow better interactions between the host and his audience.

This comes with small usability improvements as well as increased
"beautifulness" by using custom layouts & animations.

SPECS

This commit changes the survey sessions fade in/out delay for both the host
and the attendees.

When going from one question to another, the total delay is now 1 second
(instead of 2 previously), with 500 ms for fade out and 500 ms for fade in.

The previous delay gave an impression of "slowness".

The delays and "server lag reduction" on the attendees side were adapted
accordingly.

LINKS

PR #46768
Task 2208574
This commit is contained in:
Aurélien Warnon
2020-03-31 15:12:05 +00:00
parent a330099b92
commit aaf3cb50c3
4 changed files with 24 additions and 24 deletions
@@ -69,7 +69,19 @@ class UserInputSession(http.Controller):
""" This route is called when the host goes to the next question of the session.
It's not a regular 'request.render' route because we handle the transition between
questions using a AJAX call to be able to display a bioutiful fade in/out effect. """
questions using a AJAX call to be able to display a bioutiful fade in/out effect.
It triggers the next question of the session.
We artificially add 1 second to the 'current_question_start_time' to account for server delay.
As the timing can influence the attendees score, we try to be fair with everyone by giving them
an extra second before we start counting down.
Frontend should take the delay into account by displaying the appropriate animations.
Writing the next question on the survey is sudo'ed to avoid potential access right issues.
e.g: a survey user can create a live session from any survey but he can only write
on its own survey. """
survey = self._fetch_from_token(survey_token)
@@ -87,7 +99,7 @@ class UserInputSession(http.Controller):
now = datetime.datetime.now()
survey.sudo().write({
'session_question_id': next_question.id,
'session_question_start_time': fields.Datetime.now() + relativedelta(seconds=2)
'session_question_start_time': fields.Datetime.now() + relativedelta(seconds=1)
})
request.env['bus.bus'].sendone(survey.access_token, {
'question_start': now.timestamp(),
-12
View File
@@ -632,18 +632,6 @@ class Survey(models.Model):
self.sudo().flush(['session_state'])
def _get_session_next_question(self):
""" Triggers the next question of the session.
We artificially add 2 seconds to the 'current_question_start_time' to account for server delay.
As the timing can influence the attendees score, we try to be fair with everyone by giving them
an extra few seconds before we start counting down.
Frontend should take the delay into account by displaying the appropriate animations.
Writing the next question on the survey is sudo'ed to avoid potential access right issues.
e.g: a survey user can create a live session from any survey but he can only write
on its own survey. """
self.ensure_one()
if not self.question_ids or not self.env.user.has_group('survey.group_survey_user'):
+8 -8
View File
@@ -234,18 +234,18 @@ publicWidget.registry.SurveyFormWidget = publicWidget.Widget.extend({
* If the trigger is 'next_question', we handle some extra computation to find
* a suitable "fadeInOutDelay" based on the delay between the time of the question
* change by the host and the time of reception of the event.
* This will allow us to account for a little bit of server lag (up to 2 seconds)
* This will allow us to account for a little bit of server lag (up to 1 second)
* while giving everyone a fair experience on the quiz.
*
* e.g 1:
* - The host switches the question
* - We receive the event 500 ms later due to server lag
* - -> The fadeInOutDelay will be 750 ms (500ms delay + 750ms * 2 fade in fade out)
* - We receive the event 200 ms later due to server lag
* - -> The fadeInOutDelay will be 400 ms (200ms delay + 400ms * 2 fade in fade out)
*
* e.g 2:
* - The host switches the question
* - We receive the event 1500 ms later due to bigger server lag
* - -> The fadeInOutDelay will be 250ms (1500ms delay + 250ms * 2 fade in fade out)
* - We receive the event 600 ms later due to bigger server lag
* - -> The fadeInOutDelay will be 200ms (600ms delay + 200ms * 2 fade in fade out)
*
* @private
* @param {Array[]} notifications structured as specified by the bus feature
@@ -275,10 +275,10 @@ publicWidget.registry.SurveyFormWidget = publicWidget.Widget.extend({
var serverDelayMS = moment.utc().valueOf() - moment.unix(nextPageEvent.question_start).utc().valueOf();
if (serverDelayMS < 0) {
serverDelayMS = 0;
} else if (serverDelayMS > 2000) {
serverDelayMS = 2000;
} else if (serverDelayMS > 1000) {
serverDelayMS = 1000;
}
this.fadeInOutDelay = (2000 - serverDelayMS) / 2;
this.fadeInOutDelay = (1000 - serverDelayMS) / 2;
} else {
this.fadeInOutDelay = 400;
}
@@ -304,7 +304,7 @@ publicWidget.registry.SurveySessionManage = publicWidget.Widget.extend({
var resolveFadeOut;
var fadeOutPromise = new Promise(function (resolve, reject) { resolveFadeOut = resolve; });
this.$el.fadeOut(1000, function () {
this.$el.fadeOut(500, function () {
resolveFadeOut();
});
@@ -323,7 +323,7 @@ publicWidget.registry.SurveySessionManage = publicWidget.Widget.extend({
var $renderedTemplate = $(results[1]);
self.$el.replaceWith($renderedTemplate);
self.attachTo($renderedTemplate);
self.$el.fadeIn(1000, function () {
self.$el.fadeIn(500, function () {
self._startTimer();
});
} else {