Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile, Bitcoins

Давайте наймем дизайнера

На фронте сложно без дизайнера. Приходится принимать много решений по юзабилити и хочется чтобы рядом был кто-то кто разбирается в теме. Но только, блин, что бы разбирался. Пусть всему сам научился, пусть нет ни одного диплома, главное чтобы все что от него требуется сделать, он не в первый раз уже делал и не в 10, чтобы уже о большинстве проблем в курсе был. Самое худшее что может произойти – это найм художника на должность дизайнера. Если это произойдет, то все тушите свет и закрывайте лавочку.

Давайте разбираться.

looking-for-designer

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

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

При таком раскладе не может быть чтобы все данные были доступны сразу. Значит нужно это передать в интерфейсе. То есть не может быть “ползунка”, который бы легко (и моментально) менял бы резолюцию. При таком подходе при каждом сдвиге придется все блокировать и ждать ответа от сервера, чтобы отобразить изменения. Имеет смысл поступить как гугл аналитикс – добавить кнопку apply в выборе дат для графика.

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

Это только одна достаточно узкая проблема, их на самом деле значительно больше. И решения для них приходят только с опытом, потому что все это ни разу не очевидно “при первом подходе к снаряду”. Если дизайнер не сделает свою работу как надо, то потом программистам придется доделывать за него.

А теперь небольшое послесловие.

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

Поделиться:
comments powered by Disqus