1. Публикация в рубрики сообществ – это главное, что мешает при активной
групповой работе. Модель, предложенную Kuso
(
http://www.npj.ru/in/npjdev/by/kuso/335496) я считаю не очень удачной – у
автора сообщения и менеджеров сообществ могут быть разные представления по
поводу смысловой структуры журнала. Проблема усугубляется, если делается
кросспостинг.
2. В панели управления аккаунтом сделать возможность управления подписками.
3. Админовский интерфейс узла тоже не помешал бы.
4. Для интенсивной работы над документом была бы полезной такая фича, как
фиксация актуальной версии. Если возникнет необходимость внести изменения
в документ, находящийся в публичном доступе, сейчас нужно или перекрывать
доступ к редактируемому документу, или заводить новый документ-копию для
работы над ним – иначе простой пользователь будет видет весь процесс
редакторских правок, что не есть хорошо. Неплохо с точки зрения интерфейса
выглядели бы радиокнопки с пометкой «актуальная версия» напротив каждой
строки на странице «версии документа». Соответственно, нужно разграничение
прав на управление актуализацией документа.
5. Для каждой страницы/записи сделать дополнительное поле с набором
ключевых слов (не путать с рубриками!). Единственное их назначение -
дублирование 1:1 в теге meta name="keywords" в результирующем html-коде.
Унифицировать эти ключевые слова с полем «интересы» на странице профиля
журнала. Сделать поиск по ключевым словам/интересам.
6. Сделать возможность создания многоязыкового контента (и, само собой,
интернационализировать сам движок). Для многих сайтов актуальна
возможность размещения материала на нескольких языках. На уровне
интерфейса это видится в виде нескольких закладок при редактировании
документа/записи, на каждой из которых располагался бы контент на каждом
из языков. Интернациализируемыми предлагается сделать поля
«название/заголовок документа», «ключевые слова» (см. п.5) и собственно
само содержимое. Крайне полезным было бы наличие разграничения прав
доступа на уровне языков – на практике, переводчики оригинального контента
должны иметь доступ к правке только своей языковой версии.
7. (совсем мелочь) Созданный однажды документ может стать рубрикой только
после добавления рубрики при редактировании очередного документа/записи.
Причем название рубрики должно совпасть с названием ранее созданного
документа. Удобным это назвать можно только на весьма нетрезвую голову. В
локальной установке эта проблема решена добавлением чекбокса «Включить в
список доступных ключевых слов» в группе «Опции и настройки» на странице
редактирования документа. Правке подверглись:
Файл «npj/messagesets/std_form_RecordEdit.php», добавлена строка:
"Form.other" => "Прочее",
файл «npj/handlers/record/!form_record.php», добавлен блок:
if ($type == RECORD_DOCUMENT)
{
$other = array( "is_keyword" );
$group2[] = &new FieldCheckboxes( &$rh, array( "field" => "other",
"fields" => $other, "default" => "1", ) );
}
Ну и хотелось бы видеть более широкие возможности для форматирования в
виде тегов, дублирующие html-всикй <div> с набором сопутствующих свойств
CSS. Сейчас для красивой страницы не хватает возможности размешения блоков
произвольной ширины (таблицы предполагают колонки одинаковой ширины, а
потому не выход) с произвольной рамкой, отступами, границами, обтеканием и
пр. Это пожелание в самом общем виде, потому как формализовать его в
терминах NPJ я не берусь.
Автор предложений: Евстигнеев Евгений Юрьевич