Мы хотим сделать это решение понятным для пользователя не только с точки зрения готового сайта, но и с точки зрения его управления. Хочу поделиться опытом на примере формы регистрации на конференцию. Сразу оговорюсь, мы не стремились сделать идеальную форму, но понятную всем тем, кто ее будет так или иначе касаться в работе.
[spoiler]
Итак, мы используем стандартный модуль веб-форм, для компонента сделали свой шаблон.
Казалось бы, форма и форма... Совершенно стандартная. Кинул компонент, наполнил вопросами и работай. Но не совсем так. Давайте посмотрим кто пользуется этой формой.
1. Пользователь.
Заходит на страницу, видит форму. Без вводного текста она не совсем очевидна. Снимаем вопрос "зачем это" у пользователя и пишем несколько слов в начале: "Для регистрации на конференцию заполните форму:".
Наша форма подразумевает, что некоторые поля обязательны, поэтому помечаем их звездочкой (стандартный функционал, но отключать его ради красивого дизайна вовсе не стоит) - сообщаем таким образом пользователю, какая информация важная для регистрации, а какая дополнительная. Далее по возможности группируем обязательные вопросы в начале формы для простоты ввода.
Пользователь заполняет поля, вводит CAPCHA, жмет "зарегистрироваться" (кстати, название кнопки тоже важно - представьте, если бы она называлась "сохранить", о чем бы подумал пользователь?), и... И вот тут самое интересное.
Краткое отступление. Все знакомы с нашими формами регистрации на наши семинары? Так они до некоторого момента у нас работали больше во вред. Пользователи заполняли форму, видели стандартный ответ стандартной веб-формы "Спасибо, ваша заявка принята" и попадали в полный ступор. Дальше они звонили в офис менеджерам и создавали излишнюю нагрузку на сотрудников компании. Другими словами, недоделанная форма обходилась нам довольно дорого в виде оплаты времени сотрудников, потраченное на телефонные переговоры.
Желая учесть этот недостаток, мы дополнили форму адекватным ответом, который объясняет пользователю, что сейчас произошло и что ждет его далее:
Кстати, и этот ответ еще можно улучшать - сделать ссылки на контакты, указать здесь же телефон, к кому обратиться, как получить счет, сообщение о том, что на их адрес ушло письмо с пояснениями и т.д.
Но это еще не все. Не все смотрят на ответ формы. Некоторые ожидают, что раз у них спросили электронный адрес, подтверждение придет туда. Делаем почтовое уведомление, которое отправляется на адрес пользователя (именно за этим поле e-mail обязательное):
В письме пишем заполненные им данные формы и всю необходимую информацию (в данном случае у нас посетитель конференции): даты проведения, ссылки на карту проезда, ссылки на контакты организаторов. Иными словами, отправляем пользователю пакет информации, которая ему может пригодится. Один раз составили шаблон такого письма и избавились от 50 звонков в офис с вопросом "а я уже зарегистрирован? могу приходить?".
Для пользователя мы все сделали, что могли. Для владельца ПО тоже красиво решили его задачу (регистрация участников). Естественно, что можно было сделать и больше и лучше, но не бывает бесконечных бюджетов на разработку и бесконечных сроков. И качества бесконечного тоже не бывает. Считаю, что данный функционал будет достаточен для большинства пользователей. Ограничимся этим в первой версии, а далее посмотрим на отзывы клиентов и скорректируем по необходимости во второй версии.
2. Администратор
Часто ли вы задумываетесь о действиях администратора при разработке на Битриксе? Не уверен, что детально продумываются все возможные сценарии использования системы. Тем не менее, на тиражных продуктах стоит об этом подумать. И именно это позволит не прикладывать разработчика к коробке с тиражным решением для того, чтобы им пользоваться.
Что администратор может делать с этой формой? При чем не какой-то конкретный, а некий абстрактный, "собирательный", если можно так выразиться.
Он может управлять формой, скажете вы и будете правы. Но тут нужно детализировать. Давайте рассмотрим подробнее.
- может разместить эту форму в любом другом месте сайта
Эта задача решается созданием компонента. Перетянул его на любую страницу и вот он работает.
- может изменить состав вопросов формы
- может изменить настройки формы
- может управлять почтовыми уведомлениями формы
Для этого модифицируем компонент (в данном случае сделали свой, который содержит в себе стандартный компонент формы) и дополнили его кнопками управления, доступными только в режимах редактирования и разработки:
Почему только в этих режимах? Да потому что в режиме "просмотр" пользователь не управляет сайтом, а только на него смотрит.
- может изменять ответ формы
Естественно, что формы используются для разных задач, поэтому и ответ формы может быть различным. Делаем для этого возможность управлять ответом формы, например, в настройках компонента:
К этой форме у меня тоже есть некоторые вопросы, но уж извините, не удержался, пишу статью еще до завершения проекта - не все еще "прилизано".
- просматривать список зарегистрировавшихся
В данном проекте еще не сделали, но уже на очереди - добавляем кнопку для администратора, которая ведет в админку на список результатов заполнения этой формы.
Прочие задачи:
- управлять внешним видом
Для этого есть шаблон сайта, но это отдельная история
- управлять доступом к форме
Можно сделать дополнительную кнопку управления, которая даст быстрый доступ к управлению доступом страницы. Но на этом проекте задача управления доступом не очень актуальна, да и кнопок уже довольно много.
Есть веб-форма, которая является центром, связанных с ней задач и процессов. Поэтому мы делаем все элементы управления на связанные задачи непосредственно из самой этой формы.
Похоже, что это все основные задачи администратора и мы их решили.
Кстати, не забываем про администратора - ему тоже интересно получать сообщения о зарегистрировавшихся пользователях. Делаем для него еще одно почтовое уведомление. В уведомление пишем ссылку в админку на конкретно этот результат заполнения формы, а также на список всех результатов.
Еще хочу обратить внимание на то, что речь идет про тиражное решение. В нем мы набиваем демонстрационный контент, который позволит выполнить несколько задач:
1. показать владельцу сайта какую информацию нужно вводить.
2. избавит пользователя от набивания этого контента - ему нужно лишь оптимизировать тексты под себя.
3. (я бы поставил это на первое место) продает продукт! Человек, когда видит знакомые ему слова и картники, он легче принимает решение о покупке.
И не забываем про документацию - для пользователей системы она обязательна!
Как думаете, к такому решению нужно прикладывать разработчика для успешного использования?
На этом, пожалуй стоит остановиться. Если что-то я упустил из виду, пишите!
P.S. Спасибо Сергею Федорову из студии за вдохновение и подсказки.
Как думаете, к такому решению нужно прикладывать разработчика для успешного использования?
Для любого внедрения нужен как минимум консультант в случае, если в компании "пользователе" нет своих Специалистов
есть ведь функционал администратора
Далее все будет зависеть от политики использования.
Если компания "пользователь" будет отдавать себе отчет в том, что гораздо проще и быстрее подстроиться под типовой функционал, то все будет хорошо.
Если не будет, то есть грех у многих разработчиков - идти на поводу у клиентов, по малейшему поводу бросаясь делать доработки
Иногда это бывает вообще ни к чему, а иногда это вредно.
Тиражное решение - не просто решение. Это прежде всего философия, под которую пользователям надо подстроиться. И чем лучше решение соответствует потребностям и процессам отрасли, где будет использоваться, тем лучше. Но и этого недостаточно. У каждого пользователя субъективный взгляд, поэтому, если будет прилагаться не просто разработчик, а именно разработчик-консультант, то это не повредит. Будет кому направлять клиентов в нужное русло.
Да и документация должна быть для тиражных решений не просто пользовательская, а описывать именно методику использования с точки зрения отрасли, а не с точки зрения продукта.
По моему опыту общения с клиентами всего один из клиентов спросил меня
"А почему мы должны закупать работу программистов, а не просто купить продукт и самим работать?"
У всех остальных клиентов редко бывают адекватные люди разбирающиеся в ИТ (программисты, системные администраторы и т.д.) которые бы лояльно относились к продуктам Битрикс. Каждый такой работник продвигает своему начальству те системы управления сайтом, которые нравятся им. Сейчас по одному из проектов у нас такая ситуация: сменилась команда админов у клиента, они не запросив никакой информации и документации начали сами химичить на сервере (сервер у них свой). В итоге умудрились сначала убить сайт, потом подняли но не выставили правильные права доступа. Потом они начальству говорят, что система не устраивает. И это как раз в момент окончания срока поддержки, а значит будут сейчас начальству будут предлагать внедрить новую систему. Чтобы этого не случилось необходимо от нас как минимум 2 человека: продажник и разработчик, которые смогу доказать клиенту, что дешевле модернизировать чем закупать по новой.
Другой момент тиражных решений, они заточены чисто для России! Даже если взять КП для органов власти, то для Казахстана его приходится перетачивать под наши понятия и принципы работы. Возможно в других странах такая-же ситуация. А значит тут 100% нужен разработчик, который заточит под потребности клиента.
И третий на мой взгляд момент влияющий на популярность таких тиражных решений: Документация. Она должна быть по максимуму рассчитана на людей с низкими знаниями компьютера на уровне Word, Excel. Знаю, что порой занимаются публикацией пресс-релизов люди, которые в свой большой стаж журналистом не имеют электронной почты и боятся работать с сайтам считая, что они могут там что нибудь сломать.
Так, что надо учитывать много разных аспектов влияющих как на разработку тиражных решений так и на их популярность, и востребованность.
Как бы очевидные вещи просто...
Для обычных проектов они не всегда актуальны, т.к. что-то вы можете заменить обучением, что-то не входит в задачи конкретного клиента. А в типовых решениях это самое важное.
Так WebForms, по роду моей деятельности, интересны как инструменты психологического тестирования пользователей сайта. "Спасибо, ваша заявка принята" - этого мало, хочется в стандартном функционале видеть возможность смены комментариев обратной связи. Об автоматической выдаче результатов, к сожалению, пока говорить не приходится.