Probator stub

[akmetainfo]

Кнопка "Попробовать тестовые задания" - см. issue #127

Выглядит на текущий момент как-то вот так:

Вывод результатов пока функцией alert:

[akmetainfo]

Кинул в почту предложения по этой фиче.

[akmetainfo]

Теперь кнопка тестирования показываются в тех пулах, где есть примеры.

Расчёт происходит на лету (добавился JOIN к одной таблице), в принципе, как предлагал Виктор - можно и материализовать это полем archieved_pools_count таблицы morph_annot_pool_types и раз в сутки выполнять перерасчёт.
(По этому вопросу предлагаю высказаться Диме и Саше)

[akmetainfo]

В принципе, раз похоже будет в каком-то но виде сохранение в базу -- то можно при выводе примеров не хранить сразу и правильный ответ, чтобы не было соблазна подсмотреть и пройти безошибочно. А делать так: если получены ответы на все вопросы (без пропусков), то при нажатии на кнопку "получить результаты" отправить сразу весь массив ответов на бэкенд, там провести какие-то манипуляции (получить список верных ответов, сравнить, подготовить ответ для фронтенда) при необходимости сохранить -- что-то куда-то сохранить.
Не знаю, что и как нужно будет сохранять -- но можно уже потихоньку готовить бекенд и переделывать фронтенд.

[madfriend]

Посмотрел код, поставил ветку локально.

1. Нужно все функции (особенно работающие с базой) перенести из probator.php в lib/lib_annot.php.
2. Нужно сделать адекватное сохранение в базу данных результатов пробной разметки.
   Будет очень хорошо, если принцип хранения ответов на проверочные задания будет совпадать с принципом для реальной разметки.
3. По % правильных ответов и допуску к реальной разметке к единому решению пока не пришли, возможно, кнопки "Пропустить" нужно будет убрать. Ну или определиться, сколько заданий человек имеет право пропустить.
4. С внешним видом страницы с типами пулов, отображением результатов проверки разбираться буду потом сам. Но сейчас лучше заменить алерт на div c классом alert (http://getbootstrap.com/2.3.2/components.html#alerts) под кнопкой "Узнать свою статистику" (я бы ее переименовал в "Проверить себя")
5. Лучше не хранить на клиенте правильные ответы, а реализовать проверку при запросе к ajax/annot.php (возможно, стоит сделать ajax/annot_test.php)
6. Клики в пробных заданиях тоже надо сохранять, но помечать их стоит по-другому
7. Про ачивку при выполнении тестовых заданий. Лучше сделать ее сразу и выкатить вместе с этой фичей.

[akmetainfo]

@madfriend Саша, там выше ещё вопрос был. Есть ли смысл пересчитывать количество закрытых пулов раз в сутки или оставить как сейчас, расчёт на лету?

[madfriend]

По сути, мы же этим списком закрытых пулов будем оперировать на главной странице.
Так что лучше пересчитывать раз в сутки (вряд ли пулы будут закрываться чаще).

12 мая 2015 г., в 0:06, Andrey notifications@github.com написал(а):

@madfriend Саша, там выше ещё вопрос был. Есть ли смысл пересчитывать количество закрытых пулов раз в сутки или оставить как сейчас, расчёт на лету?

—
Reply to this email directly or view it on GitHub.

[akmetainfo]

Убрал правильные ответы с клиента - сделал отдельный бекенд.
Заменил alert на div.alert, возле каждого ответа схематично показываю правильный он или нет -- не знаю, оно вообще нужно ли или убрать?
Сохранение ответов и кликов в базу пока руки не дошли.

[madfriend]

Сохранение кликов надо взять из реальной разметки (там посылаются запросы к clck_log.php, насколько помню)

Вместо красной/зеленой отдельной кнопки, думаю, нагляднее было бы выделение цветом кнопок с вариантами ответа (именительный, винительный). Например, если ответ правильный - оставить как есть (зеленая обводка); ответ неправильный - красная у моего ответа и зеленая у правильного.

Но это все мелочи, потом могу и сам заняться стилями. Важнее сохранение / клики / приближение к реальному режиму разметки по коду.

[akmetainfo]

Вот с кликами точно проблем не будет в любом варианте. Если делать отдельную таблицу под пробные клики (morph_annot_click_proba_log), то её структура будет один-в-один как у morph_annot_click_log, код вставки полностью идентичный (раз и два). Также можно не создавать новую таблицу под логирование кликов, а вливать в существующую. Из доработок -- добавить поле click_source (0 - annot, 1 - proba) и слегка подрихтовать вызов процедуры логирования. Точек входа немного, ломать в общем-то нечего. Я уже просто сонный вчера сидел, поэтому оставил на следующий раз.

Сложнее вопрос с сохранением ответов.
Во-первых, помимо того, что ответы сохраняются в morph_annot_instances в отдельную таблицу (morph_annot_rejected_samples) логируются пропущенные ответы, а также есть возможность прокомментировать свой ответ (morph_annot_comments). Возможность комментирования я сразу исключил, возможно зря, но у меня тогда такой концепт был на тот момент. Также я не видел смысла сохранять пропущенные ответы, да и сейчас этот вопрос вызывает сомнения. (Кому интересно -- прошу высказаться и по логированию пропущенных и по сохранению комментариев) Что остаётся? Собственно сохранить финальные ответы.

Как мне кажется, структура morph_annot_proba будет отличаться от morph_annot_instances: в разметке предполагается, что ответ на задание можно дать только один (хотя и в click_log'е возможны несколько кликов туда-сюда). А раз ответ один -- то instance_id очевидным образом становится первичным ключом.

А когда мы говорим о тестировании, то предполагаем, что выдавая случайные примеры вполне вероятна ситуация, когда размечающий ответит на один и тот же.

Кроме того, прежде, чем начинать кодировать -- тут очень хорошо предварительно договориться, как мы делаем. Я предлагал такую схему: кликнул "протестироваться" - тебе выдало 50 случайных ответов, ты жмёшь кнопки, клики сохраняются в базу, но ответы не сохраняются - пока не нажмёшь кнопку "получить результаты". По нажатию "получить результатат" все финальные ответы фиксируются, пачкой отправляются в базу, к ним прикрепляются верные ответы - и передаются на бекенд, который считает и выводит цифры.
В принципе, это направление видно по моему последнему коммиту, если и дальше двигаться в эту сторону -- то нужно будет пачке ответов генерировать некоторый номер и этот номер попытки будет заменой instance_id (и первичный ключ будет составной -- связка try_number + sample_id). Также нужно понимать, что если закрыть тест и не продолжать его -- то в базе останутся данные по кликам, но не будет сохранённых ответов (ведь они отправляются по финальной кнопке). И открывая тест заново -- мы получаем другой набор заданий.

Альтернатива очевидна. При нажатии на "протестироваться" проверяется, нет ли неоконченного теста. Если нету -- то выбирается случайных 50 примеров, тут же сохраняется на бекенд "взяты вот эти примеры, ответов пока нет". Если есть -- вытаскивается из базы эти 50 примеров (и с ответами пользователя, если он их успел оставить, нагляднее будет: напомню, что в разметке уже отвеченные примеры не показываются при рефреше).
При этом варианте нужна будет кнопка "не хочу эти примеры, давайте заново начнём 50 случайных". (Не до конца пройденный тест также мусорит в базе, чуть по-иному: и клики есть и есть сохранённые ответы, просто не все 50). Как вариант -- можно выдавать 50 минус количество уже отвеченных примеров, но как мне кажется, всё равно возможны ситуации, когда покликал раз пять абы как, ушёл и позже хочешь начать уже сдавать хорошо -- но пока не докликаешь тест до конца с гарантированно провальным результатом -- не начнётся новый зачёт. А мне хотелось бы избежать ситуации, когда докликивают абы как, "лишь бы было" -- это снижает ответственность за выбор ответа.

[madfriend]

cc @grandsbor

[akmetainfo]

Нужно все функции (особенно работающие с базой) перенести из probator.php в lib/lib_annot.php.

Я это сделаю в одном из последних коммитов перед тем, как делать финальный rebase. Прошу не воспринимать текущий код фичи как финальный, это именно некий прототип, который я набросал в черновом варианте и сижу постепенно подгоняю по мере поступления требований.

[grandsbor]

Здесь или странные отступы, или логическая ошибка. Где заканчивается foreach?