Xpoint
   [напомнить пароль]

Управление списком

Метки: [без меток]
2004-10-15 14:08:15 [обр] Эдуард Суров(2/264)[досье]

Пусть есть список из каких-то сущностей, которые надо добавлять в список и редактировать. Типичная схема реализации такая:

  1. Нажали "Создать".
  2. Переместились в форму.
  3. Заполняем форму.
  4. Пытаемся сохранить.

Тут-то и начинаются проблемы.

  1. Предположим, сохранение прошло успешно - тогда куда следует перемещаться? Обратно к списку или к редактированию свежесозданного элемента? Пока что решение видится в виде трех ссылок: "Сохранить и продолжить редактирование", "Сохранить и вернуться к списку" и "Не сохранять и вернуться к списку". Может, у кого-то есть идеи лучше? Мне кажется, что такой наворот только запутает пользователя.
  2. Как обрабатывать ошибки? Понятно, что в случае ошибки мы должны вернуться обратно к форме, заполненной теми же значениями. Но как сообщить об ошибке? Если выводить промежуточную страницу с сообщением об ошибке, то а) эта страница застревает в history, б) грузим лишнюю страницу. Если сообщать об ошибке, скажем, выводя сообщение об ошибке над формой - рискуем, что пользователь этого не заметит. Впрочем, этим мы рискуем в обоих случаях :). Опять-таки, в случае успешного сохранения формы как об этом сообщать? Гадостность ситуации в том, что пользователь попадает на страницу с точно таким же (или мало отличающимся) содержимым; как ему ясно дать понять, что сущность уже добавлена в список?
спустя 35 минут [обр] Юрий Щапов(3/114)[досье]
  1. Обратно к списку, который должен обновиться + каждый уже созданный элемент должен иметь возможность редактирования.
b)
  1. В случае ошибки... А что есть ошибка? Неправильно заполненное поле, ошибка сервера или ... ?
  2. В случае успешного сохранения формы ничего сообщать не надо: пользователь обязательно просмотрит обновился/добавился ли редактируемый элемент.
спустя 10 минут [обр] Антон Иконников(0/30)[досье]
По поводу б) мне кажется, что большая красная надпись и большая зеленая надпись перед формой (на белом фоне, конечно) достаточно красноречиво говорят о наличии и отсутствии ошибок.
По поводу a), на мой взгляд, все зависит от конкретного списка и его элементов. Если предполагается, что пользователю будет правильней накидать элементов в список, а затем редактировать каждый элемент отдельно, то правилей будет после каждого добавления возвращаться к списку (или позволить создавать сразу много элементов). Если же каждым элементом пользователь будет заниматься от начала и до конца сразу, то нужно сразу и переходить к редактированию. Это, конечно, при условии, что я правильно понял вопрос :).
спустя 20 минут [обр] Эдуард Суров(2/264)[досье]

Юрий Щапов[досье]

  1. Это в данном случае неважно. Ошибка есть ошибка (с точки зрения пользователя). Понятно, что в большинстве случаев ошибки будут связаны с неверно заполненными полями.
  2. в случае возврата к списку - да; но всегда ли оптимален именно возврат к списку?

Антон Иконников[досье]
Красную/зеленую надпись не очень красиво реализовывать. Рассмотрим сперва красную:

  1. передавать в URL текст ошибки - ужжасно криво.
  2. передавать в URL код ошибки - менее криво, но вывод сообщения об ошибке может потребовать дополнительных данных, которых в избытке в скрипте, выполнявшем сохранение, но которые затруднительно передавать в скрипт с формой (никакого URL не напасешься; а если надо показать сглючивший SQL-запрос или еще что-то в этом духе?).
  3. передавать в cookie/сессии текст ошибки - куки могут быть отключены, и непонятно, что с этой ошибкой делать дальше. Ушли с формы, полазили по сайту, вернулись - а там ошибка светится, а мы уж и забыли, что когда-то отправляли форму.

Итак, наилучшим выглядит решение 2, но и оно не идеально.
С зеленой в принципе та же беда.

Вообще вылезает следующая поведенческая проблема формы. Вот пусть нас перенаправили на форму с сообщением - а как дальше эта форма должна себя вести при нажатии F5? Сохранить сообщение? Или отобразиться без сообщения?

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

спустя 30 минут [обр] Антон Иконников(0/30)[досье]
Вообще вылезает следующая поведенческая проблема формы. Вот пусть нас перенаправили на форму с сообщением - а как дальше эта форма должна себя вести при нажатии F5? Сохранить сообщение? Или отобразиться без сообщения?

А вот добавил пользователь новый элемент, а затем нажал F5, что тогда? Вы же этот случай обрабатывать будете? Так же и с ошибкой. Если по F5 все поля будут очищаться, то и сообщение об ошибке убирать надо ("подать мне чистый лист" - говорит юзер), а если значения полей будут сохранены, то сообщение надо оставлять.

По первому пункту. В Вашем случае, что собой конкретно представляют элементы списка?

спустя 20 минут [обр] Сергей Круглов(10/2057)[досье]
  1. Список в левом фрейме, редактирование в правом. Так что оновременно к списку и к редактированию.
  2. Если сообщения об ошибках выводить вверху до формы, то пользователь их не заметит, только если он слепой совсем или стихи сочиняет в данный момент.
спустя 46 минут [обр] Андрей Брайнин(0/127)[досье]

мы делаем так:
форма редактирования (создания новой) сущности открывается в новом окне.
http://xpoint.ru/poem/
http://xpoint.ru/poem/screen/article.gif

в этом с формой редактировнаия две кнопки "Сохранить" и "Закрыть"
c Закрыть все понятно.
при нажатии на "Сохранить":
- если все ОК: данные сохраняются. окно закрывается. список сущностей (из которого была вызвана форма редактировнаия) атоматически обновляется (нечто типа self.opener.refresh)
- если ошибка: поверх формы выводится сообщение об ошибке с указанием причины (alert), и окно с формой остается открытым.

спустя 51 минуту [обр] Эдуард Суров(2/264)[досье]

Антон Иконников[досье]

А вот добавил пользователь новый элемент, а затем нажал F5, что тогда?

Так я этим и интересуюсь :) Или вы имеете в виду не "добавил", а "перешел к форме добавления"? Это разные понятия; добавил - значит, уже создан элемент.

В Вашем случае, что собой конкретно представляют элементы списка?

У меня нет конкретного случая :) Точнее, их было достаточно много в моей практике, равно как и способов реализации, вот и задумался - нет ли универсального подхода?

спустя 4 минуты [обр] Эдуард Суров(2/264)[досье]
Сергей Круглов[досье]
Список далеко не всегда влезает в левый фрейм. Клиент обычно предпочитает видеть максимум параметров сущности непосредственно в списке.
Если вы имеете в виду полноценный <frame>, а не просто указываете на наличие двух столбцов - то на большинстве сайтов они не используются, разве что в CMS.
Насчет показа ошибок в форме - соглашусь (с самого начала писал, что этот вариант мне больше нравится), но как их туда лучше передавать?
спустя 7 минут [обр] Эдуард Суров(2/264)[досье]
Андрей Брайнин[досье]
Это отличное решение для CMS, но на frontend'ах не хочется лишний раз связываться с отдельно открывающимися окнами... К тому же вопрос можно рассматривать более общо: как задачу "красивой" обработки форм вообще.
спустя 1 час 52 минуты [обр] Антон Иконников(0/30)[досье]
Эдуард Суров[досье]
Тогда, если у Вас в данной ситуации нет конкретного случая, все мои мысли по этому вопросу я уже изложил. Т.е. мне кажется, что каждый раз надо делать в заваисимости от конкретной ситуации.
спустя 1 день 23 часа [обр] Юрий Щапов(3/114)[досье]
Да-да, Эдуард, дайте побольше конкретики. Что за список, кем редактируется, сколько пунктов и всё такое прочее. Не хватает информации уже.
спустя 15 часов [обр] Эдуард Суров(2/264)[досье]

Хорошо, вот синтетический пример, навлекающий максимум проблем:

  1. Количество элементов - больше 1000. То есть по страницам список нужно бить в любом случае.
  2. Пользователь желает видеть порядка 5-8 атрибутов сущности непосредственно в списке. То есть получается довольно широкая таблица, что сразу отметает идею, которую предложил Сергей Круглов[досье]: перенаправлять одновременно на список и на форму сложно.
  3. Вдобавок сама форма содержит достаточно большое количество полей и скроллится экрана этак на два по вертикали.

Идеальный вариант в данном случае - имхо форма редактирования в отдельном окне; но насколько такое решение применимо для frontend'ов?

спустя 1 час 19 минут [обр] Сергей Круглов(10/2057)[досье]
Можно типа раздвинуть таблицу и показать форму под редактируемой строчкой.
спустя 4 дня [обр] Андрей Иванов(0/3)[досье]

Как сделано у нас:

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

Вывод.
Есть три способа:

  1. список со ссылкой на создание объекта, когда идём по ссылке, показывается только форма (со ссылкой возврата)
  2. список со ссылкой на создание объекта, когда идём по ссылке, показывается и форма и список
  3. список и форма создания/редактирования на одной странице

Пункт а) обычно используем для больших форм, чтобы легко можно было перемещаться по форме, не прикидывая, сколько в скроллбаре будет занимать список, а сколько форма, плюс, правильно работают кнопки "End" и "Home".

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

После создания/редактирования/отмены возврат идёт туда, откуда пришёл.

Пункт обычно в) используется для небольших форм и справочников. Когда список и сама форма помещается на одном-двух скроллах.

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

спустя 4 минуты [обр] Андрей Иванов(0/3)[досье]
По F5, кстати, если не было ошибки, пользователь не увидит никакой разницы между до F5 и после.
спустя 8 дней [обр] Сергей Сирик(0/737)[досье]

> решение видится в виде трех ссылок: "Сохранить и продолжить редактирование", "Сохранить и вернуться к списку" и "Не сохранять и вернуться к списку".

Я бы добавил четвертую кнопочку - "Ссохранить и открыть чистый бланк добавления".

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

У нас сложилась практика, при которой успешное редактирование/добавление заканчивается "сенкс-пейджем", на котором пользователя можно и поблагодарить пространно за добавление новой сущности в каталог, рассказать много интересного, что с этой сущностью еще можно сделать, что еще на портальчике интересного есть. В том числе там же ссылки "В список", "Продолжить редактирование", "Добавить новый элемент" и так далее. В зависимости от того, в какой именно список добавляемся ...

Powered by POEM™ Engine Copyright © 2002-2005