Алексей Володин
9 июля 2013

Добрый день, советчики!

Работаю над своей системой управления контентом. В ходе разработки возник вопрос: идеальная панель администратора, какая она? К чему стремиться, на кого ориентироваться?



Генрих Альтшуллер определяет идеальный объект как объект, которого нет, но функция которого выполняется. Согласимся с таким определением. Тогда если у вас есть панель администратора, то она неидеальна по определению. Так мы приходим к настоящему вопросу: как сделать систему управления контентом без панели администратора?

Функция системы — создавать и редактировать страницы, изменять меню и другие элементы сайта.

Система отличает простого посетителя от администратора. На любой странице администратор видит в уголке элемент, включающий редактирование. При редактировании сверху появляется тулбар с выбором стилей текста, настройки изображения или управления таблицей, в зависимости от редактируемого объекта. В правом конце тулбара — кнопка «Сохранить изменения».

Чтобы добавить новый пункт в меню, администратор дописывает его так же, как если бы он редактировал обычный текст, делает ссылкой и указывает адрес, куда ссылка должна вести. Поскольку реально такой страницы пока нет, то этот пункт меню будет виден только администратору. Администратор кликает в только что созданный пункт меню.

Если зайти по адресу несуществующей страницы, то обычный посетитель видит 404-ю страницу, но администратор видит пустую страницу в режиме редактирования. Он мог и не переходить из меню, а просто зайти браузером по несуществующему адресу на сайте. Как только страница заполнена, администратор нажимает «Сохранить изменения» — страница создаётся и становится доступна всем.

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

См. также совет А. Г.
P. S.

Я веду практический курс «Пользовательский интерфейс и представление информации». Дата следующего курса пока неизвестна.

 
Мы напишем вам, когда будет открыта запись. Без спама.

Поделиться

Комментарии


9 июля 2013

Вместо кнопки «Сохранить» должна быть кнопка «Опубликовать». А сохранятся всё должно автоматически после любого изменения.

Вячеслав Мацнев
9 июля 2013

О, я как-то раз решал подобную задачу. Хотя мой подход был более традиционен и, возможно, не так интересен, как предложенный Ильёй, я всё же поделюсь скриншотом.

При входе в админку пользователь видит всего одну кнопку «Обновить сайт» и меню из трёх пунктов.

Это не фейк и не шутка, данная система проработала на реальном проекте (3 000+ страниц) около года.

Магии нет: контент в виде TSV-файлов и изображения загружались по ФТП, затем администратор заходил в «Панель управления» и жал кнопку «Обновить сайт». Начинал работать «движок» сайта: смотрел входные данные, проверял их и обновлял / создавал страницы, меню, БД для поиска и прочее.

Алексей Мельников
9 июля 2013

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

Полагаю, что непосредственно процесс исканий выходит за рамки данного вопроса, поэтому я сразу перейду к тому, к чему я в конце концов пришел.

Как оказалось, ключевое значение в удобстве управления играет не интерфейс, а понятная структура данных из которых состоит сайт: база данных (включая имена таблиц и полей), структура каталогов, правила именования и размещения файлов, а также умозрительное понимание настроения сайта.

Кстати это правило работает и в жизни, достаточно сравнить, скажем, качество вождения двух водителей: со стажем, который знает поведение своей машины до мелочей, и девушки-новичка.

Так вот, если целью «системы управления контентом» является действительно управление контентом, то разработав единожды складную и понятную структуру данных вопрос об интерфейсе отпадет сам собой: он может быть любым, вплоть до командной строки.

Что касается предложения Ильи, то оно напоминает объектно-ориентированное программирование, где набор заранее заданных объектов навешивается на форму, а затем устанавливаются их свойства и связи. Полагаю, что некоторые идеи можно позаимоствовать именно оттуда.

Тимур Арефьев
9 июля 2013

Илья, если речь идет о панели управления сайтами, такой вариант имеет один значительный минус: если система используется на различных сайтах, и разработчику, и человеку, который будет наполнять и редактировать сайт, каждый раз придётся искать в новом дизайне сайта, где же расположены меню и нужные нам страницы.

Главным элементом идеальной панели управления сайта, мне кажется, является дерево, отображающие карту сайта. Дерево показывает иерархию страниц. Каждая страница содержит список элементов, уникальных для данной страницы: текст, форма, списки и т. д., данные которых можно редактировать.

Игорь Алексеенко
9 июля 2013

Мне кажется, что нельзя ответить на этот вопрос однозначно. Идеальная панель администратора должна идеально решать задачу, которая стоит перед администратором.

Если это панель администратора простого сайта, который состоит из текстовых разделов, то схема которую описал Илья выглядит достаточно хорошо.

Если же это, например, панель для переводчика, то такой подход не будет работать и нужно придумывать что-то другое. Например, сделать таблицу, где в левой колонке которой будет текст на русском языке, а в колонках справа — переводы на другие языки.

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

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

Павел Радьков
9 июля 2013

Во многих генераторах статических сайтов метаинформация о странице хранится в формате YAML. Это выглядит, например, так:

title: «Нарезка графики в Photoshop. Инструмент New Layer Based Slice“»
description: «Об эффективной работе верстальщика в Фотошопе»
layout: article
published: 2012-02-22
tags: [photoshop, tools]

В интерфейсе достаточно одной дополнительной текстобласти для всех служебных данных.

Иван Большов
9 июля 2013

Мы как-то сделали так. Можно переключаться в режимы редактирования контента или блоков (блоки можно расставлять на странице, менять им тип и т. д.). Конструктор позволяет создавать любую страницу из заранее подготовленных блоков. Интерфейс пока прототипный.

Андрей Лось
9 июля 2013

Илья описал систему, исходя из предположения, что создание и потребление информации — схожие процессы, поэтому для них возможно создать некий единый интерфейс, который одинаково хорошо будет решать обе задачи.

Представим себе каталог товаров: посетителю сайта нужно найти и купить один пылесос, в то время, как администратору нужно добавить или отредактировать сотни моделей, причем сделать это как можно быстрее и с минимумом ошибок. Допустим, может понадобиться возможность совершать операции над группами товаров или устанавливать связи между ними.

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

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

Артём Дап
9 июля 2013

На сегодня самая близкая к пониманию «идеальный» — панель администрирвоания «Редимаг». Дальше стоит подумать как это превратить в администрировние на исключительно на тачпадах, поскольку возможности ввода через клавиатуру и мышку технологически исчерпаны.

http://vimeo.com/61953558

Иван Титов
10 июля 2013

Сложность известных мне ЦМС заключается в разнообразии страниц и панелек, которые приходится изучать администратору. А между тем, даже у сложного сайта ЦМС реально сократить до 1-2 страниц и одной управляющей панельки. Такое возможно благодаря продуманной и простой организации базы данных, в которой прописаны все связи.

ЦМС, которую я разрабатываю для сайта avtodeti.ru, представляет собой продвинутый вариант ПХП-май-админа. Вся необходимая информация о редактируемой таблице считывается из БД автоматически, а затем представляется не в виде «сухих» данных, а красиво и понятно.

В зависимости от типа значения подставляется чекбокс, текстовое поле, картинка, или открывается связанная таблица во всплывающем окне (которую можно редактировать аналогично). Основные принципы — наглядность, минимум кликов, сохранение данных на лету.

Но главный плюс в том, что нет дублирования структуры в БД и в CMS. Любые изменения таблиц, в том числе сложные, достаточно внести в базу данных, при этом саму админку менять не придётся.

Евгений Арутюнов
10 июля 2013

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

Андрей Щербатых
15 июля 2013

Суть подхода Ильи — не плодить сущности. Если уже есть сущность — страница на сайте, то лучше её редактировать на ней, а не в отдельном интерфейсе, попутно думая как же блин будет выглядеть на морде то что я ваяю в админке.

Другой вопрос, что иногда в админке есть управление каким-то таким свойством объекта, которое визуально на сайте не присутствует. Поэтому приходится «лепить горбатого» (в частности — это его вопрос про метатеги). Есть ещё один пример — если в интернет-магазине нет статуса «есть на складе» нигде, а отсутствующие товары просто не отображаются в каталоге или на сайте вообще, то приходится придумывать контрол для свойства объекта «есть / нет на сайте».

Более сложный пример — когда есть несколько групп пользователей, у каждого из которых своя цена для товара (опт 1, опт 2, розница, например), и пользователь видит только свою цену. Как тогда отобразить таблицу цен для редактирования? А как заводить / удалять группы (объект «группа» вообще нигде на сайте не отображается как таковой)?

Я заметил, что я как разработчик все чаще и чаще пользуюсь ПХП-май-админом для просмотра / заполнения данных, потому что он привычен и максимально результативен. А вот клиенты наоборот пользуются админкой т. к. там им проще в том смысле, что их не пугает избыточность интерфейса (которая есть в ПХП-май-админа)

Павел Гращенко
11 февраля 2015

Есть архитекторы сайта, а есть операторы. Проблема всех систем управления сайтом в том, что они плохо разделяют сценарии этих персонажей.

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

Операторы — это, как правило, представители заказчика. Люди, для которых слова «аштиэмель», «шаблон», «парент», «эфтипи» — филькина грамота. Простые дяди и очень простые тети. Они будут каждый день выполнять строго детерминированные действия: добавлять, удалять и редактировать новости, товары, акции, курсы, слонов, термоусаживаемые муфты, турбины атомных подводных лодок, или чем там они занимаются.

Так вот, я убежден, что оператору нельзя давать в руки инструменты архитектора. Это 1) не нужно ему; 2) сложно для понимания; 3) просто опасно для работоспособности сайта. Поясню.

Это не нужно ему. 99,999% задач оператора однообразны. Если это блог, то человек добавляет посты. Если магазин — товары и акции. Если фотогалерея — фотографии. Если сервис подбора недвижимости — карточки квартир. Ситуация, когда оператор вдруг захочет уложить именно эту квартиру в другую ветку структуры с другим шаблоном оформления — фантастическая. Видимо, это уже не оператор.

Это сложно для понимания. Я думаю, все присутствующие не раз имели разговор с тетей, представителем клиента, которая «теперь будет заниматься сайтом», что, мол, внимательно выберите выберите родителя новой страницы и примените к ней шаблон оформления, а вот это поле не трогайте, а то все сломается. «Ой, так сложно! А мне всего-то нужно новость добавить». Работать с ЦМСками (особенно общего назначения) — сложно для большинства людей. Чтобы проверить это попробуйте научить свою маму работать в Джумле.

Это опасно для работоспособности сайта. Да, действительно, не ограничивая возможности оператора, вы оставляете ему возможность по ошибке снести целую ветку структуры, случайно перенести страницу туда, где «её не должно быть» (новость в товары, или контакты в проекты), выбрать не правильный шаблон оформления, создать ветку структуры, которая никак не была предусмотрена дизайном (вот эти вот разговоры «ну мы же сможем самостоятельно в любой момент добавить новый раздел на сайт?»), или удалить какой-то критический файл без которого всё просто развалится к чёртовой матери.

Поэтому когда мы начали разрабатывать свою ЦМС, то дали себе обещание, что операторы клиентов никогда не увидят ни строчки HTML и CSS, не будут выбирать парентов страниц и шаблоны. А будут оперировать понятными сущностями в их собственном мире. В терминологии нашей системы эти сущности называются «Типы контента»: для них архитектором определено положение в структуре, шаблон и набор специфичных свойств.

Тут выше Евгений Арутюнов говорил, что не нужно пытаться создать идеальную ЦМС, а нужно создавать свою под каждый проект и со временем, возможно, выделить какие-то общие моменты.

Но, по мне так, лучше сделать «конструктор индивидуальных систем управления», как пытаемся мы.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.





Недавно всплыло

Начальник считает, что перед встречей нужно обязательно разработать несколько вариантов предложений 6 2 У меня остаётся ощущение, что я идиот, «рассыпала бобы», но на конкретных ошибках не могу себя поймать 3 Это я неправ, что долго думал, или магазин, что допустил такую ситуацию? 3