Comments 29
Довольно интересная статья, но много «букв» и не читается на одном дыхании, возможно как совет все же нужно вставлять немного от автора для связки ;)…
Спасибо.
Очень хорошая и полезная статья. Я согласен с Bygaga, очень много «букв». Сначала я прочитал только выделеное жирным. Потом только когда нечего было делать, прочитал целиком, и то не сразу.
Как было сказано в статье, «Здесь стоит вспомнить слова Стива Крюга». Побольше примеров с картинками бы.
Статья полезная и интересная, спасибо Вам за перевод.
Могу помочь картинкой:

Это часть экрана в Друпале, спряталась еще часть меню административного, и внизу еще пункты.

Я на 90% в друпале не понимаю, что там к чему. Поэтому пункт: 2. Защитите пользователей от сложностей системы — для меня как бальзам на сердце.

Друпал — яркая иллюстрация к статье, как не надо делать.
Вы опубликовали скрин админки довольно навороченного и гибкого модуля Views. Чем гибче система, тем она тяжелее в настройке.

Модули же для публикации контента в Drupal вполне интуитивны.
Это скриншот настроек модуля Views, представляющего из себя графический интерфейс, с помощью которого можно составить SQL-запрос практически любой сложности.

а) Разобраться с этим модулем гораздо проще чем освоить SQL.
б) Модуль действительно очень мощный и сложный и я не могу представить как его интерфейс можно было бы еще сильнее упростить. Во здесь я приводил пример использования этого модуля, в котором описал назначение каждого из блоков, изображенных на картинке.

Кроме того, в статье речь идет о конечных пользователях CMS, а этот модуль предназначен для разработчиков.
Упростить — не значит сделать удобнее.

Удобнее сделать можно, но чего мы ждем от бесплатного открытого кода, когда почти все платные этим грешат, начиная от Битрикса. Я бы не сказал, что Битрикс намного удобнее Друпала или Джумлы. Задача создания интерфейса CMS очень сложна, а тем более интерфейса не заточенного под конкретного пользователя, функционал и даже сайт.

Достойных решений я, пока, не видел, только жалкие потуги. Но это не значит, что эта статья поможет сделать удобную CMS. Статья не для профессионалов (я имею в виду в интерфейсах), а без опыта, по статье, разработать удобный интерфейс для CMS, практически невозможно.
Я понимаю, что сейчас фанаты Друпала назовут меня ламмером, так оно и есть, но тем ни менее, возражу искренне уважаемому мной Ромке:

MySQL я освоил за пару часов, прочитав одну главу книги. Все остальное я почти не читал, потому что понял основу. В MySQL есть простота и чистота замысла.

Парсер я освоил часов за 5, прочитав 6 простых уроков. А я не программист и не разработчик. Но врубился. Потому что в Парсере тоже есть чистота и простота.

А друпал пытаюсь понять уже примерно год. И считаю его CMS сложной, не интуитивной, тяжелой в освоении и с отсутствующим пошаговым учебником. В принципе, да, в друпале я ламмер. И, боюсь, таким и останусь. Потому что эта система не имеет основы в задумке. В задумке — сделать сразу все.
Не, вообще, друпал хорошо документирован, просто до этой информации еще надо добраться. Есть книги-учебники для разработчиков Drupal, и есть замечательный ресурс api.drupal.org/ и его русскоязычное зеркало api.drupal.ru/
Большой сложностью, конечно, остаются модули Views и CCK, потому как у них совершенно своя, мало на что похожая логика взаимодействия с пользователем, но и это в принципе изучается.
Что мне не нравится в Drupal — это процесс разработки модулей к нему. Там совершенно свое API, при этом оно очень неочевидное, и мало понятное при прочтении кода готовых модулей в качестве примеров.
А конечному пользователю все можно упростить до минимума, оставив в менюшке пару ссылок для выполнения нужных операций, и сократив количество настроек в диалогах для их выполнения. Например, диалог публикации записи можно упростить до полей ввода заголовка статьи, текста статьи, и кнопки отправки. Соответственно, реализуем и любой промежуточный вариант между этим минимализмом и дефолтным нагромождением чекбоксов и селектов с полями ввода дополнительных опций.
Что касается картинки, то на ней интерфейс сторонней надстройки, а не интерфейс ядра.
Если завтра кто-то сделает свой модуль ещё более сложным, ядро системы от этого не станет ни хуже, ни лучше.
Я не понимаю, почему авторы не оформляют переводы как переводы, ведь первые от этого получают очевидные преимущества, в том числе пониженный проходной балл на главную. Даже если это ваша первая публикация здесь, при её создании вы не могли не увидеть нужный вам тип топика. В чём проблема?
Тут все говорят спасибо как роботы и даже в текст не вчитываются?
5. Don’t forget the real-world purpose
The acronym “CMS” is made up of three words, one of which is much less important than the other two: the S.

5. Не забывайте реальные цели
Аббревиатура CMS состоит из трех слов, одно из которых является гораздо менее важным, чем два других: С.

А вообще, извините, но не читается. Просто перевод не должен быть ощутим — а здесь в каждом втором предложении читается английский оригинал. Честно говоря, в таком случае, оригинал читать даже удобнее.
Прозреваю, что «asset models» можно перевести и не словосочетанием «модель актива».

Помыслите об этом.
Пожалуй, с пунктом 17 стоит не согласиться — а как же бета-релизы, RC и сбор фидбэка с их помощью? В этом вопросе, мне кажется, разработчик должен исходить из времени, которое он готов посвятить системе, и качества, которое он хочет вложить в продукт.
Да, перевод корявенький:
«Вовлеките дизайнера в процесс» — «Привлекайте дизайнера» или даже «Интерфейсом должен заниматься дизайнер»

В общем, впечатление такое: Многие советы скорее для самописных систем, если даже не сказать для разработчиков, которые делают сайт на основе готовых CMS, а некоторые для создателей этих «готовых» систем.

Хотя одно можно сказать точно, если человек понимает о чем написано в статье, то он и так это сделает, в статье нет никаких ноу-хау или не очевидных вещей. А если для человека это открытие, то он все-равно не сделает так как надо, потому, что нужно понимание, а не следование весьма размытым инструкциям. Да и для знакомства с удобными интерфейсами — это не лучшая статья.
Понравилось — много относится не только к CMS, но и к любым другим MS.
Не понравилось — ссылки на платные книжки (ну да, авторы тоже хотят кушать, но я почему-то предпочитаю бесплатные знания платным). И, как было верно подмечено, читается немного тяжеловато.
Опять общие слова, сраная теория. Лучше бы примеры приводили конкретные, пользы было бы больше.
Примеров действително нехватает, в статье много воды и описываются довольно очевидные вещи.

А по поводу юзабилилти лично я считаю самым удачным вариантом делать для админа или редактора не админку (как отдельный элемент для управления материалами), а использовать по возможности инлайн редактирование и все действия CRUD (Create Read Update Delete) + сортировка и т.д. помещять на основных страницах сайта (материала) чтобы человеку не нужно было тыкаться по 10 ссылкам для редактирования, а потом еще и переходить на основной сайт чтобы посмотреть изменения. Админку следует делать только для настроек и операций, которые не входят в повседневные задачи, чтобы обычнному редактору не приходилось ходить по ненужным ему страницам.
Есть CMS с хорошими пользовательскими качествами и интересной идеологией. Могу сказать, что она отличается от принятых парадигм в коммерческих CMS Битрикс, Неткат и open source типа Джумлы.

CMS платная, но была доступна демо версия.
К сожалению сейчас поддержка её прекращена. С ajax и новыми востребованными функциями она могла бы повоевать за некоторую долю рынка
Only those users with full accounts are able to leave comments. Log in, please.