Маленьких фич не бывает

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

Неверно.

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

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

Что будет происходить, когда отзыв превышает 140 символов?  Мы обрезаем строку или отображаем сообщение об ошибке для пользователя?  Если отображаем ошибку, то где она появляется?  О чем это говорит?  Кто будет писать сообщение об ошибке?  Как мы объясним пользователю, почему мы ограничиваем его 140 символами?  Как будут выглядеть эти ошибки?  Есть ли у нас определенный стиль, UI Kit для ошибок?  Если нет, то кто его проектирует?

Погодите, это ещё не всё…

Это ещё не всё, даже в том маловероятном случае, когда у нас есть ответы на все вышеперечисленные вопросы.  Просто делать это на стороне сервера — “грязный” способ обработки ошибки.  Мы должны сделать это на стороне клиента.  Но если мы собираемся проводить валидацию на стороне клиента, то возникает еще больше вопросов…

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

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

Уже близко…

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

Кроме того, где отображается количество букв на экране?  Как выглядит счетчик?  Конечно, стиль должен меняться по мере того, как пользователь приближается к нулевому количеству символов, и определенно должен выглядеть как ошибка, когда он использует более 140 символов — или программа должна перестать принимать ввод в этот момент?  Если да, то что происходит, когда они что-то вставляют в строку, что заведомо длиннее 140 символов?  Должны ли мы позволить им отредактировать текст или нужно вывести предупреждение?

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

Невозможно игнорировать тот факт, что пользователи будут задаваться вопросом, почему кто-то написал отзыв из восьмидесяти слов прямо перед ними, а им теперь разрешено писать только один из 140 символов.  Очевидно, что нам нужно будет постоянно поддерживать эту тему и обновлять документацию, API, приложения для iPhone и Android.  Кроме того, что нам делать со всеми предыдущими отзывами?  Должны ли мы обрезать их или оставить всё как есть?

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

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

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

Ну ты же не всерьез?

Да, это всё простые разглагольствования. Да, большинство вышеперечисленных решений могут быть приняты на лету опытными разработчиками, однако не все.  Можно использовать атрибут maxlength, но это относится только к одному из пунктов выше, да и то, только в HTML5.

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

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

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

ДЕС ТРЕЙНОР

Переведено Кириллом Гурбановым, gurbanov.ru

Источник