x
 
Денис
3 ноября 2008

Здравствуйте, Артем!

У меня вопрос по целесообразности использования WYSIWYG-редактора в администраторской панели сайта. С одной стороны, раз уж делаем сайт с возможностью администрирования — нужно предоставить возможность наполнять сайт любому пользователю, без каких-то особых навыков. А с Вордом вроде бы знакомы все. С другой стороны — заплатил клиент довольно приличную сумму, ему сделали качественный дизайн, хорошо его сверстали ну и т. д. Поручил он секретарше добавить страничку — она ее в Ворде набрала, скопировала в WYSIWYG-редактор, который при этом сохранил форматирование и в лучшем случае немного почистил код — шрифты, отступы и все остальное осталось, как в Ворде. И все впечатление от дорогого дизайна портится.

  • Вариантов — чтобы и пользователю угодить, и слишком больших возможностей редактирования кода ему не давать, я вижу несколько:
  • 1) Все-таки WYSIWYG, но с сильно урезанной функциональностью и набором предопределенных стилей. Но этим от копи-паста из Ворда не защитишься… Возможно, фильтровать теги при сохранении?..
  • 2) BBCode, ну или какая-то вариация на тему… Плюс возможность быстрого просмотра изменений.
  • 3) Использовать HTML и кнопки для форматирования для тех, кто не знает тегов, и тоже с возможностью предварительного просмотра.

Что посоветуете? Чтобы и клиенту сделать удобно, и дизайн сайта не портить?



Верстка требует соответствующей квалификации не только в вебе. Секретарь наберет текст в Ворде, но вряд ли правильно сверстает его в Индизайне.

У меня нет сомнений, что режим ЧУВТИП — «что увидишь, то и получишь» — был бы удобнее и секретарям, и профессиональным верстальщикам.

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

В нашем бюро первую проблему решают ограничением форматирования необходимым минимумом, вторую — редактированием на уровне простого текста или семантического ХТМЛ. БиБи-код, конечно, работает, но, на мой взгляд, является тупиковым компромиссом. Уж лучше секретарь выучит основы ХТМЛ.

Секретаря сравнительно безболезненно допустить к публикации новостей: форматирование сводится к указанию заголовка, анонса, разметке на абзацы и добавлению картинок. Газетные статьи ведь обходятся без полужирных и курсивных выделений в тексте, а для местной акциденции используют врезки. Для таких задач не требуется ни ХТМЛ, ни ЧУВТИП.

Для более сложной верстки мы обучаем специалистов клиента нескольким простым тегам, соответствующим предусмотренным элементам оформления: заголовок H, абзац P, цитата BLOCKQUOTE, ссылка A, иллюстрация IMG, врезка DIV, специальный термин DL.

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


Тем не менее, я думаю, что будущее за ЧУВТИПом. Пока его повсеместному внедрению мешают слишком много вещей: различия браузеров, пользовательская база устаревших браузеров, несовершество ЦСС и Яваскрипта.

От англ. WYSIWYG, What You See Is What You Get

Поделиться
Отправить

Комментарии

Павел Власов
3 ноября 2008

Мне в этом отношении симпатична идея WYSIWYM (mean) — это голая семантика, без произвольных украшательств, и потому результат будет выглядеть скорее хорошо, если достаточно ограничить набор средств. Этакое совмещение идеи «Ворда» с идеей семантики.

Вот пример реализации: http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html

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

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

Саша Сергеев
3 ноября 2008

Я согласен, что за WYSIWYG — будущее всего, где требуется подготовка текстов. Лучше всего работают такие редакторы, которые не дают возможности верстать заранее неверно. Например, двойного абзаца не получится, как ни старайся, потому что такой вариант был заранее отсеян дизайнерами. Или свистопляски с шрифтами нельзя устроить, как бы ни хотел. Выбор должен быть ограничен и копипейст должен соответствующим образом трансформироваться в нужный формат. Опять же мне нравится, когда над CMS и прочими вещами работают вместе специалисты по дизайну и верстке в паре с людьми, знающими поисковую оптимизацию и прочие важные детали. Очень сильно необходимо продумывать блоки мета-контента, которые должны быть доступны при верстке. Должны быть продуманы такие моменты, как «что случается со ссылками на страницу А если ее название изменить на Б». Или «как происходит перенос страницы из раздела 1 в раздел 2».

Александр Зайцев
3 ноября 2008

В WYSIWYG на данный момент недостатков намного больше. Есть, например, огромная проблема — абзацы текста парсятся в несколько
.

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

Только синтаксис вроде нельзя внутри текстобласти подсвечивать :-(

Степан Столяров
3 ноября 2008

Клиенты, к сожалению, не будут учить никакие языки разметки, так что надо быть готовым к копи-пасте из Микрософт-офиса. К счастью, реализовать вполне приличный очиститель ХТМЛ от Ворда проще, чем кажется.

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

Алексей Рытов
3 ноября 2008

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

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

Алексей А. Евдокимов
5 ноября 2008

Вопрос, в самом деле, тот еще. Далеко не первый раз попадается. Идеального решения до тех пор, пока не вырастет два поколения пользователей, которым культуру использования языка разметки гипертекста преподавали в 7-м классе средней школы, нет.

В 2001 году, создавая свою CMS, я выкрутился так: http://www.mittec.ru/help/editor_content — то есть, использованием BB-кодов, но
а) параметризованных,
б) гибко настраиваемых под конкретный сайт,
в) с предварительной визуализацией.

Результаты до сих пор радуют.

Александр Мядзель
5 ноября 2008

Денис, этот извечный вопрос беспокоит, в первую очередь, разработчиков и дизайнеров сайтов.

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

Увы (?), но это так.

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

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

Если вам все равно, что будет с сайтом после предоставления доспупа к административной части, а клиент заказал сайт (условно) за 500 долларов, тогда используйте визуальный редактор и не мучайте ни себя, ни клиента.

Как говорится — что посеем, то и пожнем.

Олег Финкельштейн
8 ноября 2008

Сейчас, возможно, существует еще один вариант решения задачи о «семантическом секретаре» — это текстовый процессор LyX (http://lyx.org/), который занимает промежуточное (с точки зрения пользователя) положение между Вордом и Техом, являясь графической оболочкой для последнего.

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

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

Александр Овчаренко
10 ноября 2008

Что же все на секретарш накинулись… Внедрение стилей вместо оформления («заголовок», «параграф», «цитата») конечно спасет, но только отчасти.

Ну да не об этом. До сих пор не сталкивался с решением, которое помогло бы и секретарям и тем, кто с типографикой «на ты»: внедрение редактора прямо в фронтэнд сайта. Т. е. эдакий интерфейс вордовский, но вместо страниц с текстом можно щелкнуть в любое место (вероятно, контентное), увидеть курсор и отправить текст. Потому что внедрение WYSIWYG в бэкэнд (админку) — половинчатое решение, даже если и стили «подцепляются» родные для сайта — потому что важен контекст, и тот же цвет подобрать будет трудновато, не видя исходной страницы, и вечные проблемы с вставкой каких-нибудь нестандартных элементов — крупных изображений или широких таблиц.

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

Александр Вознюк
17 декабря 2008

Александру Овчаренко: реализация систем с возможностью редактирования содержания непосредственно с front-end есть: например, CMS SAPID sapid.sourceforge.net/ru/ — простая и очень удобная для маленьких проектов система, не требующая наличия на хостинге базы данных. Редактирование в ней работает по принципу — «где кликнул — там и печатаешь».

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

И, в принципе, клиенту можно отдавать макрос для Ворда с кнопкой «Скопировать текст для вставки на сайт» и забыть о тыканьи мышкой в WYSIWYG-редакторе в админке, — ведь, как правило, текст на сайт не пишется «с нуля», он уже набран, — так зачем его форматировать во второй раз. Получается такой себе веб 1.5.


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

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

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

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

4 Как правильно писать размерность? 6 Год назад запустил личный проект «Либретто опер» 2 Хочу сделать красивый блог с пошаговыми рецептами 7




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

Какие законы для текста, который будет восприниматься только на слух? 1 1 Как следует поступить дизайнеру, если клиент постоянно вспоминает «нечто очень важное» 7 Все уже успели заметить, что вы почти во всех пятничных примерах советуете немного поунижаться 12