Pull to refresh
0
0
Send message

Улучшаем форму оплаты с помощью дизайна и анимации

Reading time4 min
Views16K
Многие думают, что разработка дизайна для формы оплаты — это не самое важное занятие. Однако, если задуматься, то форма оплаты любого продающего сайта — один из важнейших составляющих его элементов, та самая «точка невозврата», пройдя которую покупатель уже не повернет вспять. Находясь на форме оплаты, клиент принимает окончательное решение о покупке выбранного товара или же об отмене заказа. Другими словами, платежная форма — это та тонкая грань, которая отделяет вас от цели любого продающего сайта — реализовать товар. И если рассуждать в подобном ключе, то становится очевидным, что пренебрегать дизайном формы никак нельзя.

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

Анимация на форме оплаты не должна носить исключительно развлекательный характер, напротив, ее главная цель — помочь пользователю разобраться с тем, что от него требуется и подтолкнуть к наиболее эффективному использованию вашего продукта. Здесь важно не переусердствовать. Существует простое, но эффективное правило, помогающее понять, так ли нужна выбранная вами анимация на форме оплаты: отключите ее и посмотрите, что будет. Если после отключения анимационных эффектов ваша форма значительно потеряла в информативности и функциональности, интерфейс стал менее удобным и выглядит неполным, значит анимация действительно полезна и нужна, в противном случае, если после отключения анимации восприятие формы не изменилось, вероятнее всего, она будет лишней.
Читать дальше →
Total votes 24: ↑21 and ↓3+18
Comments6

Что такое красивый код, и как его писать?

Reading time22 min
Views205K

1. Вступление


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

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

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

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

Говоря о базовых знаниях, надо отметить, что умение писать красивый профессиональный код — это то, что по тем или иным причинам, в эти базовые знания категорически не входит. Вместо этого, в соответствующих заведениях, а также в книжках, нам рассказывают про алгоритмы, языки, принципы ООП, паттерны дизайна…

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!
Читать дальше →
Total votes 97: ↑79 and ↓18+61
Comments145

Техническое задание на сайт

Reading time11 min
Views697K
UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ


А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:



Далее много букв
Total votes 212: ↑209 and ↓3+206
Comments141

Information

Rating
Does not participate
Registered
Activity