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

Основные рекомендации и ввод данных

• Стремитесь к краткости.
• Убедитесь, что в форме используется один язык (обороты, термины).
• Если на странице находится только форма и ничего кроме нее, то при загрузке страницы стоит ставить фокус на первое поле формы, это позволит сэкономить немного времени (страница поиска, входа, регистрации).
• Поддерживайте ясный путь заполнения формы.
• Избегайте вторичных действий, если это возможно.
• В противном случае четко разделяйте основное и дополнительные действия.
• Выравнивайте основное действие так же как и поля формы, это упрощает восприятие формы.
• Цветная подложка у главной кнопки сделает её более видимой.
• Отключайте кнопку «Отправить» после того как пользователь на нее нажал, это позволит избежать двойной отправки данных.
• Еще лучше — показывайте индикатор отправки.

Вступление

Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.

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

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

И, как обычно, прощу прощения за объем статьи. Но, надеюсь, вам будет интересно дочитать до конца.

После покупки Acer 1410 как основного ноута для использования дома/в командировках старый добрый EeePC 900 остался не у дел и пролежал в ящике стола полгода. В очередной раз наткнувшись на него, я понял, что нужно его либо продать, либо сделать из него что-нибудь полезное. Чем-нибудь полезным оказалось применение в быту в качестве:
— Торренто-качалки/раздавалки
— Устройства для постоянного отображения Яндекс.Пробок и прогноза погоды (Удобно когда перед выходом из дома можно оперативно посмотреть обстановку на улице и спланировать маршрут)
— Принт-сервер для старенького, но экономичного и бесперебойно работающего win-принтера Canon LBP-810
— Часов

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

Никого не удивишь проектом, в котором сейлз, маркетинг и бизнес анализ находятся в Англии, разработка в России, тестирование и саппорт — в Индии. Компания, в которой я работал, специализировалась именно на таких проектах. Наиболее слабыми местами в них, я бы назвал коммуникации внутри проекта и мотивацию его участников. Эта статья описывает эффективный подход к решению этих проблем в проектах с распределенной командой.

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

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

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

Я хочу поделится с хабрасообществом опытом проведения интервью и списком вопросов. Cвежепринятые сотрудники еще стесняются критиковать старожилов, надеюсь получить какие-то возражения, или альтернативные идеи по механизму отбора здесь.

По мотивам предыдущих постов: "Практика разговорного английского языка" и "Как учить английские слова".

В современном мире многие сталкиваются с необходимостью изучить иностранный язык. Чаще всего этим языком является английский. Методов изучения иностранного языка, и английского в том числе, существует много: заучивание слов по карточкам; расклеивание стикеров с названиями предметов по всему дому; метод 25-го кадра (хотя лично я в него не верю); штудирование грамматики,– как с репетитором/в школе/в университете/на курсах, так и самостоятельно; метод погружения, наконец. В общем, есть из чего выбрать. Благо, на просторах Интернета материалов можно найти великое множество.

Выбор конкретного метода, а может быть, и нескольких, зависит от мотивации. Прежде чем остановиться на каком-то из них, задайте себе вопрос: «Для чего я учу язык?». Кому-то будет вполне достаточно базовых знаний грамматики и словаря, — просто потому, что язык нужен только для чтения статей, например. А кому-то этого будет мало. Да, грамматика и лексика – это, конечно, хорошо. Они – основа языка, его фундамент и стены. Но как быть с живой речью? Ведь понимание иностранной речи, а потом и возможность говорить на иностранном языке – немаловажная составляющая.

Вы думаете лучшими специалистами в своем деле становятся талантливые и гениальные люди? Нет, быть лучшим — это возможность каждого нормального человека! И у тебя, Хаброжитель, эта возможность тоже есть!

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

Бывают такие проекты, когда нет возможности заниматься анализом и исследованиями так, как это принято в цивилизованном обществе. Это происходит по разным причинам: отпуска сотрудников, маленький бюджет, сжатые сроки, а иногда встречаются даже противники предварительного обследования. Практически как в известном анекдоте: «чего тут думать — трясти надо». Поэтому приходится собирать и формализовывать требования за очень короткий срок и одну-две встречи с заказчиком, который не всегда может рассказать о решаемых задачах в силу отсутствия опыта работы с сайтами.

Хлебнув несколько раз проблем с нехваткой данных для дальнейшей работы, я выработал для себя ряд мер, которые гордо назвал «виртуальной моделью» =)

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

Как вы, наверное, замечали, прототипы могут быть представлены в разнообразных формах: от каких-то набросков на салфетке, до дизайна созданного в профессиональном пакете, который выглядит очень близко к желаемому результату. Несмотря на такое количество вариантов, мы можем выделить два основных типа прототипов: малодостоверные (Low fidelity) и высокодостоверные (High fidelity ). Малодостоверный прототип – это простое описание, набросок на рисовальной доске или скетч, которые приблизительно показывают кусочек пользовательского интерфейса. Пример такого прототипа представлен на рис. 1.


Рис. 1 – Пример малодостоверного прототипа, который демонстрирует форму входа в систему

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

Отдельное спасибо автору, за разрешение отдельной публикации.

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

Знакомый HR попросил оценить вакансию «специалист по Интернет-технологиям» их конкурента.
Когда я начал вчитываться в текст данной вакансии волосы поднимались дыбом.

Должность: специалист по интернет-технологиям
Заработная плата: 35000 руб.
Компания: *******

Образование: высшее техническое, либо высшее — маркетинг
Видно, что специалист по HR не до конца понимает, какой именно сотрудник нужен.
У технаря один склад ума, а у маркетолога совсем другой, навыки тоже совершенно разные.

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

* Results-oriented professional (специалист, ориентированный на достижение результата)
* Cross-functional teams (имеется различная специализация)
* More than [x] years of progressively responsible experience (более, чем столько-то лет опыта, в чем-то отмеченного и зафиксированного)
* Superior (or excellent) communication skills (высочайшие способности к коммуникации)
* Strong work ethic (строгое соблюдение трудовой этики)
* Met or exceeded expectations (соответствую или превосхожу ожидания)
* Proven track record of success (есть подтверженный список достижений)
* Works well with all levels of staff (умение хорошо срабатываться с сотрудниками всех уровней)
* Team player (умею работать в команде)
* Bottom-line orientation (ориентирован на результат)

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

Интересно, как обстоит с этим дело в России — у нас же многое перенималось по западным канонам раньше?

Получение первичной информации о проекте

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

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

Когда я проводил первые online семинары и тренинги, я наступил почти на все грабли какие можно было, потому хочу поделиться с вами своим best practice, чтобы не подорвать доверие к вебинарам среди профессионалов и серьезных бизнесменов.

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

Тем кто когда либо заказывал разработку дизайна чего либо будь то сайт, лого, буклет и так далее, или делал по заказу подобное, должна быть знакома эта точка в проекте — «утверждение дизайна». Зачастую самая болезненная. Причины бывают разные, и одна из самых распространенных — неправильный выбор заказчиком критериев годности дизайна, и как следствие неверная постановка задачи, а результат — сорванные сроки, испорченные отношения, потерянные деньги и так далее. Вот об этом и напишу, как этот кошмар превратить в праздник ;)

Самые распространенные ошибки заказчика

Решил поделиться опытом создания и продвижения компьютерной фирмы. Думаю, кое-кому да и пригодиться. Тем более, что старт был с абсолютного Кельвиновского нуля. А чего мы и как добились, можно увидеть под катом.

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

Сначала повторяем чужие ошибки, потом делаем свои, потом свои же повторяем ) Итак...

Задачи менеджера проекта (лидера) в работе с командой сводятся к повышению эффективности и снижению себестоимости разработки. Эффективность команды во многом зависит от ее участников. Что мешает нам добиться синергетического эффекта? Пробуем разобраться.

В работе менеджера проектов одно из наиболее ценных качеств – это опыт. Именно опыт формирует интуицию, помогает принимать правильные решения и завершать проекты успехом. Чаще всего наш опыт основан во многом на стандартных ошибках, в стандартных ситуациях. При этом, в текучке проблем, мы придумываем нестандартный выход из них (так проще), и забываем воспользоваться устоявшимся опытом многих предшественников, сведенным в систему. Напрасно. Система «в сознании» позволяет принимать уверенные решения, думать на несколько шагов вперед, и не тратить время на эксперементы с людьми. Описанная ниже схема покажется очевидной многим из нас, но часто мы не берем ее во внимание и совершаем ошибки, которые стоят всем денег.