Hi-Tech

Любое изменение в разработке имеет значение

Пример отзыва

Это незначительное изменение, ведь так?» «Мы хотим уменьшить размер отзывов на продукт до 140 знаков, потому что когда-нибудь, возможно, захотим использовать SMS.

Нет, не так.

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

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

Убрать лишние строки или просто вывести на экран ошибку? Что делать, если отзыв больше 140 знаков? Что писать? Если выводить ошибку, где её показывать? Как объяснить пользователю, почему установлен лимит в 140 знаков? Кто будет писать текст ошибки? Стиль уже выбран? Как будет выглядеть ошибка? Если нет, то кто будет его разрабатывать?

Но подождите, есть ещё вопросы

Выдавать ошибку на стороне сервера — плохое решение. Даже если вдруг у нас и есть ответы на все выше поставленные вопросы, это ещё не конец. Но если мы решаемся на валидацию со стороны клиента, следует ещё ряд вопросов… Это должно быть на стороне клиента.

JavaScript будет отображать тот же тип ошибок, что и код сервера? Кто будет писать JavaScript? Как он работает без JavaScript? Если нет, то какой новый стиль использовать? Как убедиться, что лимит в 140 символов работает с валидацией на стороне сервера и на стороне клиента?

Посмотрите на эту ситуацию глазами пользователей. И это тоже ещё не конец. Должен быть иной путь. Они уже недовольны тем, что их отзыв ограничен 140 знаками по какой-то странной причине, непонятной им, а теперь мы предлагаем им угадать, насколько длинное у них сообщение? Ах да, ведь тогда появляется ещё больше вопросов… Давайте добавим счётчик знаков.

Почти закончили

Если мы собираемся использовать тот, который нашли в сети, то кто будет тестировать его на целевых браузерах (не только на Google Chrome). Кто будет писать счётчик знаков?

Как он выглядит? Кстати, а где этот счётчик будет отображаться? Или нужно запретить ввод символов после превышения лимита? Конечно, стиль должен поменяться, когда пользователь приближается к лимиту, и должен отображать ошибку, когда пользователь превысит лимит... Нужно разрешить редактирование или предупредить о превышении лимита? Если да, то что произойдёт, когда пользователь скопирует и вставит текст в окошко?

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

Очевидно, служба поддержки должна быть готова к вопросам от пользователей, а мы должны обновить документацию, API, приложения на iPhone и Android. Всё вышеописанное не учитывает замешательство пользователя, который не понимает, почему кто-то до него смог написать отзыв на 80 слов, а ему теперь даётся только 140 символов. Убрать лишние символы или оставить без изменений? Кстати, что делать с прошлыми отзывами?

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

Теперь дело за чем-то более сложным, чем оператор if. Когда вы решите все проблемы, у вас наконец-таки будет рабочее дополнение, и это только лишь счётчик символов. Поэтому UX-дизайнер должен хорошо понимать, как много труда нужно вложить в какое-либо дополнение, прежде чем соглашаться на его разработку. Когда вы работаете на совесть, не может быть речи о незначительных дополнениях.

Да вы шутите…

Опытные разработчики могут быстро решить большинство перечисленных проблем. Да, это были пустые слова. Да, можно использовать "maxlength", но это снимает только один из вопросов (и только при кодировании в HTML5). Но не все проблемы.

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

Его разработка — напротив, тяжёлый труд. Согласиться на новое дополнение — обманчиво просто. Когда речь идёт о качестве, все изменения значительны. Техническое обслуживание дополнения может быть кошмаром.

#дизайн

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»