Во время порядка моей регистрации на АШ отмечался факт зачистки автором предмета обсуждения (статьи). Практически потеря информации и основы дискуссии.
Проблему решили простым/быстрым образом: блокировкой редактирования *опубликованных* (блоги/пульс) статьей старше ~1 месяца. С запретом удаления комментариев (чистым, т.е. с убиранием кнопки) и запретом изменения комментариев (с оставлением кнопки, что как минимум удивляет).
Но такое решение нельзя назвать достаточным.
Хотя бы потому что психологический срыв (с удалением текста) возможен и до достижения контрольной отсечки (1 месяц). А обсуждения на интервале 2-3 недели тоже жалко.
Не говоря об ошибках типа false positives.
Например:
1. Обсуждение статьи показало необходимость иллюстрации. Пока думал, сочинял, собирался — здравствуй блокировка. И нельзя дописать ссылку на продолжение (минус читаемость).
2. На свежую голову заглянул в статью. Вижу — опечатка ☹ Исправить? А вот шиш! Здравствуй блокировка.
Хорошо, что оставлена кнопка ответа и можно продолжить обсуждение или добавить комментарий.
Потому полагаю правильным и предлагаю к реализации (без оценки трудоёмкости, целесообразности и приоритета):
1. По умолчанию редактирование [статей] разрешено всем.
2. При редактировании сохраняются все версии (полностью или в виде diff'ов — детали).
3. В заголовке статьи в формате иконки раздела цифру с числом правок.
По мотивам новостных статей Туфельки: с выводом в формате подсказки последнего комментария и указанием числа символов разницы с предыдущей версией.
4. В конце корректировавшейся статьи — таблицу списка правок (комментарий/разница в символах) и интерфейс к выводу diff'а.
5. Администрации при необходимости возможность блокировки редактирования и фиксации отображаемой по умолчанию версии.
6. В заголовке комментария отображать соответствующий ему номер правки статьи (на какую версию статьи отвечали).
7. Фиксировать (блокировать возможность редактирования) комментария по факту ответа.
Чтоб два раза не вставать. По интерфейсу:
1. Было бы бы логичным как-либо выделять статьи подконтрольных авторов.
А то пока комментарий не увидишь, метки (подписи) как бы и нет.
2. Нет видимых признаков ленты. По моим наблюдениям снос записей, который автор полагает заслуживающими размещения на видном месте (Пульсе) не всегда сопровождается комментарием.
Поэтому рядом с полем количества правок было бы логично предусмотреть визуализацию признака Пульса. Возможно с дополнительными атрибутами — признак сноса (автором посчитано правильным размещение на пульсе, администрация отклонила) и признак одобрения (для режима премодерации).
3. Хотелось бы видеть в профиле работоспособную при выключенном JavaScript функцию выбора умолчательного формата ввода.
Переключаться с умолчательного «WYSIWYG CKEditor» на «Plain text» несколько утомляет.
Также интересен сакральный смысл вывода пункта «WYSIWYG HTML» для пользователей, зарегистрированных после выключения (устаревания) фичи.
4. Для читаемости хотелось бы иметь возможность глобального задания настроек отображения спойлера (всегда развёрнут, всегда свёрнут, использовать индивидуальные настройки отображения).
Комментарии
Проблемы 1-2 вполне решаются за месяц. Более того, возможны и правки в будущем, достаточно меня запросить.
Этот запрос стоит недорого - существенно дешевле всей возни, что вы предложили :-).
А для принципиально-организационной (когда срыв происходит в интервале штатного редактирования) доступна резервная копия?
Проработка нюансов интерфейса — дело вообще и дорогое и скучное.
Потому в форме предложения на видное место. Для подумать.
Пока особенности первоначальной реализации не превратились в стандарт.
ЗЫ: В наличной реализации, как я понял, по запросу сбрасывается счётчик времени по которому блокируется редактирование?
можно так, через сброс, можно и иначе, через права
какая разница? факт в том, что у тех кого вопрос возникал - он был решен
ну да, неплохо было бы еще поулучшать, но у нас нет армии разработчиков, зато есть срочные задачи (индивидуальные рейтинги и т.д.)
Вообще это был скорее вопрос о способе реализации.
Ссылки слать в личку?
ЗЫ: Знаю, что оптимизация интерфейса может съесть ресурсов сколько есть и ещё добавки потребовать.
Причём уже на этапе проектирования.
Потому и пишу что и почему хорошо бы сделать. Пусть оно лучше в долгом ящике полежит.
ЗЗЫ: По мне задача правильных рейтингов значительно сложнее интерфейса. А вопрос оптимизации представления (структурирования) важнее. Впрочем, обоснованного решения у меня тоже нет. Не говоря о том, что здесь, как и в интерфейсе в принципе, простого существования решения недостаточно.
Хватит уже своё ЧСВ расчесывать
Хватит уже проецировать свои фантазии.