Comments 60
С мобильными несколько не правильно.
Не все могут написать точно о том, какой код страны. А что если я заказываю на какой-нить временный телефон, находясь в другой стране? Смотреть справочник?
Не все могут написать точно о том, какой код страны. А что если я заказываю на какой-нить временный телефон, находясь в другой стране? Смотреть справочник?
Маловероятно что вы этот номер запомните наизусть, забыв лишь код страны, правда? А там где он будет записан (а где-то его придется вам записать, ведь с этим даже справочники не помогут) — будет и вожделенный код страны.
А представьте что вы были в Амстердаме а потом кааак отправились в Германию например, на волне позитива и легкости мышления, при этом телефон временный заказывали вообще в Бельгии, вам какую страну выбирать в списке? Поэтому мне кажется единое поле для всех цифр — подходящее решение, ну не обязан пользователь разбираться где в многообразии цифр (+4244242499234) код страны, где код оператора, а где уже тело телефона.
А представьте что вы были в Амстердаме а потом кааак отправились в Германию например, на волне позитива и легкости мышления, при этом телефон временный заказывали вообще в Бельгии, вам какую страну выбирать в списке? Поэтому мне кажется единое поле для всех цифр — подходящее решение, ну не обязан пользователь разбираться где в многообразии цифр (+4244242499234) код страны, где код оператора, а где уже тело телефона.
А мы сделали удобнее, при вводе имени на русском языке, идет транслитерация по ГОСТу и если пользователь ввел: Иван Петров, то в input он получает Ivan Petrov, что намного упрощает жизнь пользователю.
Хорошая идея! Слава разработчикам, которые на такое решаются! Главное только чтобы в один прекрасный момент (коих у нас в государстве может наступать аж несколько за год) ГОСТ этот не пересмотрели. И не получилось так что существуют паспорта с именами Julia и Yulia в зависимости от даты их получения. Ведь строгая тетя контролер будет смотреть в паспорт и сверять буковки с теми что в билете, про ГОСТ ей лучше не говорить даже.
Но это теория, на практике вы молодцы!
Но это теория, на практике вы молодцы!
Подтверждаю существование таких «паспортов не по ГОСТ'у».
И да, именно имени «Юлия» сильно не везёт.
И да, именно имени «Юлия» сильно не везёт.
В большинстве АК можно до 3х ошибок
Это заблуждение, ни у одной авиакомпнии или ИАТА нет таких правил. Наоборот есть четкое правило не допускающее ни одной опечатки.
В прочем, допущение 3-х ошибок фонетически не изменяющие имя и фамилию поддерживается как негласное правило, и сбоев при перелетах по Европе не дает. А вот если летите в Азию, то обращайте пристальное внимание на ошибки — вероятность возникновения проблемы при обратном вылете намного больше.
В прочем, допущение 3-х ошибок фонетически не изменяющие имя и фамилию поддерживается как негласное правило, и сбоев при перелетах по Европе не дает. А вот если летите в Азию, то обращайте пристальное внимание на ошибки — вероятность возникновения проблемы при обратном вылете намного больше.
у меня при заказе билета жене, сделали ошибку в имени, нормально прошли 3 таможни, погранцов и побывали в 3-х странах!
подтверждаю
подтверждаю
А когда пользователь зарегестрировн в бонусной программе и данные у него написаны в другой транслитерации?
Пример: Sergey/Sergei и т.д.
Пример: Sergey/Sergei и т.д.
Проверка правильности имени полностью лежит на пользователе. Если имя не то, что транслитировалось по ГОСТу, пользователь может сам ввести как ему хочется на английском языке.
Хотя он и на английском может опечататься.
Хотя он и на английском может опечататься.
А как поступать если билет на внутренний рейс, например, Санкт-Петербург — Москва, и имя можно указать русскими буквами? В такм случае система все равно транслитерирует? Или это у вас отрабатывается только для международных перелетов?
Надеюсь, у вас в самом начале формы ярко-красным висит предупреждение:
«пользователь, имей ввиду: некоторые — только нам известные — поля ввода мы незаметненько корректируем после твоего ввода. Поэтому перечитывай все вдумчиво по два раза, даже если тебе кажется, что все введено правильно!»
«пользователь, имей ввиду: некоторые — только нам известные — поля ввода мы незаметненько корректируем после твоего ввода. Поэтому перечитывай все вдумчиво по два раза, даже если тебе кажется, что все введено правильно!»
У меня всегда по разному пишут имя. где Maksim, а где Maxim.
Если имя требуется для чего-то неофициального, то такая транслитерация уместна. Однако для покупки билета неправильное написание может создать очень много проблем для пользователя. У разных авиакомпаний разные правила на количество ошибок в имени. Однако всем придётся объяснять, что ты не верблюд.
Конечно, в теории пользователь должен проверить имя. Однако, автоматическая транслитерация как бы говорит: «не волнуйтесь, мы знаем лучше, как ваше имя пишется». Если было переведено неверно, то бедный человек будет потом объяснять сотруднику охраны аэропорта «а мне сайт так сам имя написал, по ГОСТу». Не знаю, общались ли люди, принявшие решение об автоматической транслитерацией, с сотрудниками охраны. Я общался. Это очень неприятный разговор.
Конечно, в теории пользователь должен проверить имя. Однако, автоматическая транслитерация как бы говорит: «не волнуйтесь, мы знаем лучше, как ваше имя пишется». Если было переведено неверно, то бедный человек будет потом объяснять сотруднику охраны аэропорта «а мне сайт так сам имя написал, по ГОСТу». Не знаю, общались ли люди, принявшие решение об автоматической транслитерацией, с сотрудниками охраны. Я общался. Это очень неприятный разговор.
Особенно удобно будет пользователю, когда после выписки билета окажется, что в паспорте у него написано по другому, а а/к забила на правило 3х ошибок и отказалась сажать его на рейс -)
А что делать, если пассажиров несколько? Лепить все данные на одну страницу? А если кто-то покупает билеты на компанию из шести человек? Мне кажется, должно быть по одной странице с формой на каждого пассажира, а в конце сводка о всех введенных данных с возможностью вернуться на предыдущие страницы для их редактирования. На этой же странице должны быть кнопки «Купить билет сейчас» и «Забронировать билет». Еще неплохо было бы иметь возможность вернуться к странице выбора рейса без потери введенных данных о пассажирах. (Вдруг вы заполнили все данные, но вдруг поняли, что выбрали неправильный день).
Если пассажиров несколько ни в коем случае не надо лепить все на одну страницу! В статье я упомянул, что рассмотрю вариант оформления только 1 человека, как самый распространенный. Для нескольких должно быть последовательное заполнение, разумеется, с возможностью переключения между ними (ну вдруг вы забыли что Вася то уже и не Вася вовсе а Василиной изволил стать).
Хранение данных о пассажире, мне кажется, не такая сложная задача в рамках сессии. Но вот стоит ли делать кнопку «изменить рейс» на данной форме — не уверен. Можно конечно подписать «уважаемый, вы если что не бойтесь, мы ваши данные храним тут тщательно, можете и рейс сменить, если изволите». Но опять же не уверен что это уместно
Хранение данных о пассажире, мне кажется, не такая сложная задача в рамках сессии. Но вот стоит ли делать кнопку «изменить рейс» на данной форме — не уверен. Можно конечно подписать «уважаемый, вы если что не бойтесь, мы ваши данные храним тут тщательно, можете и рейс сменить, если изволите». Но опять же не уверен что это уместно
Чтож вы за глупость-то говорите! Статистика показывает, что как раз ЧАЩЕ ВСЕГО оформляют билеты на 2+ человека. Вариант с 1м человеком, это, как правило, бизнес-тревел, что, можно сказать, выходит за рамки данной статьи, поскольку там немного другие процедуры и интерфейсы.
Откуда у вас такая статистика? Одна продажа это, в среднем, 1.4 пассажира, при том что 3,4,5 паксов и более так же бывают. 1 пассажир сильно больше 50%. Туры мы не рассматриваем, турфирмам не нужны правильные сайты как и сотрудники с интеллектом выше дауна.
У вас не правильная статистика. В среднем в одной броне 1,4 — 1,5 человека. На больше 1го приходится около 30%.
Очень приятная форма. Несколько соображений:
1. Ссылки «С какими документами можно лететь?» и «Адреса терминалов» выглядят опасно: вдруг форма исчезнет, если на них нажать? Может, подчеркнуть их прерывистой линией и при нажатии открывать скрытый элемент на странице с формой?
2. Я бы перенёс ссылку «Адреса терминалов» в текст про оплату. Во всяком случае, не ставил бы её в один ряд с кнопками, обозначающими действия.
3. Можно сформулировть первый заголовок формы так же, как и второй, в формате «вопрос – подсказка». «Представьтесь, пожалуйста» – «Для приобретения или бронирования билета...».
4. Можно ещё раз указать стоимость заказа на кнопках действия вместо указания типа комиссии. Чтобы получилось «Купить билет сейчас / 1200 руб.», «Забронировать билет / 1201 руб.».
5. Мобильная версия не спашивает e-mail. Надеюсь, это мелкий баг мокапа.
1. Ссылки «С какими документами можно лететь?» и «Адреса терминалов» выглядят опасно: вдруг форма исчезнет, если на них нажать? Может, подчеркнуть их прерывистой линией и при нажатии открывать скрытый элемент на странице с формой?
2. Я бы перенёс ссылку «Адреса терминалов» в текст про оплату. Во всяком случае, не ставил бы её в один ряд с кнопками, обозначающими действия.
3. Можно сформулировть первый заголовок формы так же, как и второй, в формате «вопрос – подсказка». «Представьтесь, пожалуйста» – «Для приобретения или бронирования билета...».
4. Можно ещё раз указать стоимость заказа на кнопках действия вместо указания типа комиссии. Чтобы получилось «Купить билет сейчас / 1200 руб.», «Забронировать билет / 1201 руб.».
5. Мобильная версия не спашивает e-mail. Надеюсь, это мелкий баг мокапа.
Спасибо.
1. Основная идея была — не потерять их, над точным оформлением можно еще подумать. Как миниум они не должны вдруг открывать в активном окне новую страницу со справкой на пяток листов, что бы пользователь за голову не хватался от испуга что все егорукописи сгорели данные пропали.
2. Справедливо
3. 4. Нет предела совершенству
5. А нужен ли он? Если достоверно известно что да — то будем считатьмелким багом моей ошибкой. Ведь уведомление о том что билет забронирован, номер брони, иные данные — можно получить и в виде SMS. Ведь телефон то у меня точно есть с собой — раз я с него заказывал.
1. Основная идея была — не потерять их, над точным оформлением можно еще подумать. Как миниум они не должны вдруг открывать в активном окне новую страницу со справкой на пяток листов, что бы пользователь за голову не хватался от испуга что все его
2. Справедливо
3. 4. Нет предела совершенству
5. А нужен ли он? Если достоверно известно что да — то будем считать
Почему сначала фамилия, потом имя?
Мне всегда нравилось наоборот и всегда было интересно, почему некоторые ставят на первое место фамилию, как в классном журнале в школе.
Мне всегда нравилось наоборот и всегда было интересно, почему некоторые ставят на первое место фамилию, как в классном журнале в школе.
Все таки, на мой взгляд, лучше выбирать дату, чем заполнять самостоятельно. Сразу отметаются неправильные варианты написания (8.10.11, 081011, 08102011 и т.д.)
Согласен, добавить к полю модуль по выбору даты. Тем более что в самом поле даты по сути тоже подсказка, как и справа от поля, только разделители почему-то другие — палочки «день | месяц | год» против точек «11.11.2011»
А что стоит толковым разработчикам правильно распарсить дату формата 081011 или 08102011? и преобразовать ее в удобоворимое «8 октября 2011» Но добавить календарик к полю можно, согласен с вами, кому-то это сможет облегчить задачу.
Можно и мозг человеку распарсить )) Зачем усложнять, когда можно получить данные сразу в нужном формате?
В данном случае усложняем мы жизнь только разработчику, ведь это ему придется возиться с тем что пользователь ввел данные так как захотел а не «сразу в нужном формате», верно? Если да, то, на мой взгляд, их мучения можно допустить, т.к. они оплачиваются работодателем, а пользователя то зачем мучать?
Что сложнее для пользователя: 3 клика мышкой (в случае с грамотным календарем) или напечатать минимум 6 символов? Что выгоднее для заказчика: оплачивать такие «мучения» разработчика или обойтись без лишних затрат? Что проще для разработчика: взять готовый календарь или писать парсер на все случаи?
Конечно проще взять готовое, тут и речи нет. Только надо действительно грамотный календарь: ведь пользователь мог родиться как в 1970 году так и в 1991, и в январе и в сентябре. Не думаю что всегда можно обойтись тремя кликами.
Что сложнее? Разумеется 3 клика, да это три жеста, но долгих, так как включают в себя долгое наведение курсора на скорее всего мелкий элемент календаря. Ввод в данном случае (для более менее опытного пользователя) тоже 3 жеста, потому что ввод он ту не шести символов, а трех чисел, и при том 3 очень быстрые жеста.
Разделители само собой должны дописываться автоматически после ввода каждой чиселки.
Разделители само собой должны дописываться автоматически после ввода каждой чиселки.
При вводе даты рождения будет гораздо больше 3х кликов.
Вы, для начала, должны выбрать правильный год, потом месяц и только потом день.
Вот и посчитайте — клик на иконку, клик на селектор, поиск нужного года, клик на год, клик на селектор, поиск нужного месяца, клик на месяц, клик на дату. 6 кликов и 2 поисковые операции.
Вы, для начала, должны выбрать правильный год, потом месяц и только потом день.
Вот и посчитайте — клик на иконку, клик на селектор, поиск нужного года, клик на год, клик на селектор, поиск нужного месяца, клик на месяц, клик на дату. 6 кликов и 2 поисковые операции.
Оптимальный вариант — число и год вводить вручную, а месяц давать в дропдауне.
Вообще лучше давать вводить данные в разных форматах, но в случае с датой, пользователь начнет думать и сомневаться в каком формате нужно писать. Элемент datepicker известен большинству пользователей и на тур сайтах он есть почти везде, стало быть пользователи к нему привыкли и чтобы оправдать ихние ожидания, необходимо его оставить.
в некоторых странах 081011 это например 10 августа
заметка: вряд ли получиться распарсить 1122011 — 11 февраля или 1 декабря 2011? Ошибка слегка надумана, но пользователи, они такие, обязательно когда-нибудь введут.
У меня странный вопрос…
Что скажете о порядке полей внутри блоков (персональных данных например)?
Что скажете о порядке полей внутри блоков (персональных данных например)?
Мне никогда не нравилось выбирать документ.
Можно попросить просто номер документа и автоматически определить что это за документ. Справа вывести информацию том с какими документами можно летать (возможно, под псевдоссылкой).
Можно попросить просто номер документа и автоматически определить что это за документ. Справа вывести информацию том с какими документами можно летать (возможно, под псевдоссылкой).
Очень важный момент — оформления покупки, тем более в таких больших компаниях каждая мелочь может показать насколько существенно она отражается на количестве транзакции. Действительно, бывает вводишь долго и щепетильно, и вдруг что-то вроде логина пароля, поломаной капчи и хуже всего если введеная информация пропадает.
Остается надеятся что ваши рекомендации дойдут до адресатов :)
Остается надеятся что ваши рекомендации дойдут до адресатов :)
Ваш анализ вызывает интерес, спасибо.
Если вы попробуете сделать из вашей формы настоящий интерфейс, то увидите, что у вас получится монстр.
Так как людей надо несколько, у вас будет несколько страниц. Понятно, что в этом случае в конце всех шагов вам нужно будет сделать страницу, где собраны все пассажиры, чтобы пользователь мог проверить всё, что он навводил. При этом именно на этой последней странице пользователь будет обнаруживать, что ошибся. Поэтому вам придётся либо на эту последнюю страницу пихать интерфейс редактирования, повторив, таким образом, всякие Энивеи.
Либо вы сделаете возможность вернуться назад и там отредактировать. В этом случае будет клиника. Я вижу ошибку, но чтобы её исправить, я должен вернуться назад на N шагов, исправить её, а потом пройти обратно вперед, чтобы увидеть результаты своего редактирования. Если вы еще решите сделать «удобную» переключалку по шагам, чтобы пользователь мог проще справляться со странной необходимостью ходить туда-сюда по шагам, то получится спейс шаттл. Это сильно повлияет на продажи билетов. Не могу себе представить клиента, который бы принял такой интерфейс. Эта форма — главный барьер на пути денег из кармана пользователя в карман хозяина сервиса и надо сделать так, чтобы этого интерфейса было как можно меньше.
Еще, кстати, очень бы интересно было посмотреть, как бы вы сделали вашу форму начисто, потому что накидать прототип такой сложной формы — одно, а задизайнить её по-настоящему (например в стиле Озона) — совсем другое дело. Однин только билетик (у вас это туда-обратно вверху) сделать не так уж просто будет :)
Если вы попробуете сделать из вашей формы настоящий интерфейс, то увидите, что у вас получится монстр.
Так как людей надо несколько, у вас будет несколько страниц. Понятно, что в этом случае в конце всех шагов вам нужно будет сделать страницу, где собраны все пассажиры, чтобы пользователь мог проверить всё, что он навводил. При этом именно на этой последней странице пользователь будет обнаруживать, что ошибся. Поэтому вам придётся либо на эту последнюю страницу пихать интерфейс редактирования, повторив, таким образом, всякие Энивеи.
Либо вы сделаете возможность вернуться назад и там отредактировать. В этом случае будет клиника. Я вижу ошибку, но чтобы её исправить, я должен вернуться назад на N шагов, исправить её, а потом пройти обратно вперед, чтобы увидеть результаты своего редактирования. Если вы еще решите сделать «удобную» переключалку по шагам, чтобы пользователь мог проще справляться со странной необходимостью ходить туда-сюда по шагам, то получится спейс шаттл. Это сильно повлияет на продажи билетов. Не могу себе представить клиента, который бы принял такой интерфейс. Эта форма — главный барьер на пути денег из кармана пользователя в карман хозяина сервиса и надо сделать так, чтобы этого интерфейса было как можно меньше.
Еще, кстати, очень бы интересно было посмотреть, как бы вы сделали вашу форму начисто, потому что накидать прототип такой сложной формы — одно, а задизайнить её по-настоящему (например в стиле Озона) — совсем другое дело. Однин только билетик (у вас это туда-обратно вверху) сделать не так уж просто будет :)
Дорисовать кнопку "+", при нажатии добавлять еще столбик полей ввода с информацией о пассажире.
Это все достаточно легко решаемо. По сути эта ошибка — классическое наследие систем, которые делали программисты и которую из-за тяжести движков и инертности мышления никак не могут исправить.
А так — onetwotrip уже это сделал.
А так — onetwotrip уже это сделал.
Спасибо за комментарий.
Как мне видится форма оформления нескольких пассажиров «вчерне»:
— имеем, пусть три, «болванки» оформления пассажиров, первая из которых раскрыта:
после заполнения инфы о первом пассажире переходим ко второму:
в итоге получим 3 заполненных болванки на одной странице. Разумеется претерпят изменения заголовки и добавятся контролы: с этим закончил, давайте оформлять следующего/ редактировать данные / этот вообще не полетит. При допилке из состояния «вчерне» до «удобоваримого» кажется что не так монструозно будет выглядеть.
Конечно после надо будет проверить это на людях, в лабораторных условиях. Но главное начать.
Задизайнить начисто я, к сожалению, не могу — просто руки заточены настолько грубым топором что чистый дизайн не мое совсем, однако я не верю что это невозможно. Если «стиль Озона» не позволяет сделать удобную форму и превращает ее в монструозную, может стиль стоит сменить? Как раз у Озона инфа о билете занимает столько места, что можно из соседней комнаты рассмотреть что на мониторе отображено, это, на мой взгляд не позволительная роскошь.
Как мне видится форма оформления нескольких пассажиров «вчерне»:
— имеем, пусть три, «болванки» оформления пассажиров, первая из которых раскрыта:
после заполнения инфы о первом пассажире переходим ко второму:
в итоге получим 3 заполненных болванки на одной странице. Разумеется претерпят изменения заголовки и добавятся контролы: с этим закончил, давайте оформлять следующего/ редактировать данные / этот вообще не полетит. При допилке из состояния «вчерне» до «удобоваримого» кажется что не так монструозно будет выглядеть.
Конечно после надо будет проверить это на людях, в лабораторных условиях. Но главное начать.
Задизайнить начисто я, к сожалению, не могу — просто руки заточены настолько грубым топором что чистый дизайн не мое совсем, однако я не верю что это невозможно. Если «стиль Озона» не позволяет сделать удобную форму и превращает ее в монструозную, может стиль стоит сменить? Как раз у Озона инфа о билете занимает столько места, что можно из соседней комнаты рассмотреть что на мониторе отображено, это, на мой взгляд не позволительная роскошь.
Явно же хуже получается. На Энивее или на Раздватрипе будет три тонких полосочки, а у вас три высоченных блока и специальный интерфейс для их сворачивания. Сворачивание, кстати, наверняка будет бесить.
То есть вы явно движетесь не в ту сторону. Идеальный интерфейс — это тот, которого нет, а функция его выполняется. На Энивее, чтобы перейти к заполнению следующего пассажира, надо просто взять и начать заполнять следующую строку, а у вас будут контролы «давайте оформлять следующего», значит энивеевский интерфейс идеальнее.
То есть вы явно движетесь не в ту сторону. Идеальный интерфейс — это тот, которого нет, а функция его выполняется. На Энивее, чтобы перейти к заполнению следующего пассажира, надо просто взять и начать заполнять следующую строку, а у вас будут контролы «давайте оформлять следующего», значит энивеевский интерфейс идеальнее.
Посмотрите как сделано на eviterra.com
В среднем в одном заказе 1,5 пассажира. Т.е. примерно в трети случаев люди покупают билеты более, чем на одного человека. Во что ваша форма превратится тогда? Форму оплаты на отдельный шаг вы отнесли зря. И их даже у авада больше 2х. Да еще и две кнопки сделали там, где можно сделать одну.
И почему поля с заданным количеством символов такие большие. Почему при таком подходе расположение заголовков полей — слева от полей, а не над полями?
Вообще, видно, что с предметной областью вы знакомы только как пользователь услуг. Что стоит за ней вы не знаете. Вообще, самая главная проблема этой переделки, что вы залезли в сложную предметную область, а переделывали из поверхностных соображений. Ключевой недостаток всех приведенных форм в том, что вы не можете добавить или удалить пассажира из заказа. Все остальное по сравнению с этим — полная ерунда.
И почему поля с заданным количеством символов такие большие. Почему при таком подходе расположение заголовков полей — слева от полей, а не над полями?
Вообще, видно, что с предметной областью вы знакомы только как пользователь услуг. Что стоит за ней вы не знаете. Вообще, самая главная проблема этой переделки, что вы залезли в сложную предметную область, а переделывали из поверхностных соображений. Ключевой недостаток всех приведенных форм в том, что вы не можете добавить или удалить пассажира из заказа. Все остальное по сравнению с этим — полная ерунда.
Спасибо за комментарий.
Я действительно не более чем пользователь услуг, и мне, именно как пользователю, совершенно не интересно какие глубинные проблемы заставили столь простую, на первый взгляд форму превратить в такое чарующее разнообразие вариантов заполнения. С другой стороны, как автору переделки, стоило ознакомиться более детально, согласен. Как видно из комментариев момент оформления нескольких пассажиров — один из самых острых, и стоило изначально сделать форму с возможностью оформить 2х или 3х человек. Только их число должно быть определено заранее, т.к. если их добавлять в процессе оформления может случиться неприятность в виде отсутствия такого количества доступных билетов. Поэтому, мне кажется, добавлять пассажира уже в момент оформления — не корректно. Удалить — без проблем.
Расположение / заголовок — поле — подсказка / мне кажется наиболее удобным для восприятия, как единой строки.
Почему сделано 2 кнопки вместо одной — я пояснил в статье, скорее попытался пояснить — раз не удалось. Ровно как и форму оплаты предпочитаю видеть отдельным шагом.
А может действительно все это полная ерунда, пока не показано как усадить в самолет семью из 3х человек.
Я действительно не более чем пользователь услуг, и мне, именно как пользователю, совершенно не интересно какие глубинные проблемы заставили столь простую, на первый взгляд форму превратить в такое чарующее разнообразие вариантов заполнения. С другой стороны, как автору переделки, стоило ознакомиться более детально, согласен. Как видно из комментариев момент оформления нескольких пассажиров — один из самых острых, и стоило изначально сделать форму с возможностью оформить 2х или 3х человек. Только их число должно быть определено заранее, т.к. если их добавлять в процессе оформления может случиться неприятность в виде отсутствия такого количества доступных билетов. Поэтому, мне кажется, добавлять пассажира уже в момент оформления — не корректно. Удалить — без проблем.
Расположение / заголовок — поле — подсказка / мне кажется наиболее удобным для восприятия, как единой строки.
Почему сделано 2 кнопки вместо одной — я пояснил в статье, скорее попытался пояснить — раз не удалось. Ровно как и форму оплаты предпочитаю видеть отдельным шагом.
А может действительно все это полная ерунда, пока не показано как усадить в самолет семью из 3х человек.
Все эти системы знаю сколько доступно мест в момент открытия формы. Повесить правильное ограничение и показать каунт — не проблема. Даже примеры работающие уже есть. При этом количество ситуаций, когда дошли до ввода данных и поняли, что искали на одного, а билетов надо 3 — не мало.
Модель реализации сейчас такая: покупка билета состоит из двух шагов. Бронирование билета и выписка билета. Бронируя вы просто занимаете билет, но ничего не платите. Выписывая — вы подтверждаете, что заплатите. Западный онлайн и часть российского объединяет эти два шага для пользователя. В вашем варианте — такого объединения нет. Да, модель реализации формируют не агентства, а GDS и а/к. Повлиять на нее практически не возможно.
Что-то поменять после создания брони уже практически нельзя. Т.е. по правилам IATA нельзя менять только фамилию, имя и пол. Можно менять номер проездного документа (тип нигде не указывается), срок действия, дату рождения, гражданство и страну выдачи. Но если будет много таких ченжей, то агентство попадет на штрафы от а/к. Поэтому никто такие ченжи в онлайне не разрешает, их можно сделать только позвонив оператору.
Обе ваши кнопки сейчас, по сути, выполняют одно и тоже действие. Они создают бронь. Эта бронь будет висеть до наступления timelimit (который, кстати, критически важно показать). При этом вы заставляете на этом шаге пользователя сделать выбор, вместо того, чтобы просто создать бронь. Это плохо и для пользователя, т.к. вы на этом шаге заставляете его думать и плохо для вас, т.к. каждое раздумье пользователя — снижении конверсии. Поэтому вторая кнопка — лишняя.
После нажатия на любую из них вы что-то покажете человеку. Почему бы не показать ему форму оплаты кредитной карты и информацию о том, что он может оплатить в терминалах? О ситуациях, когда у вас этих способов оплаты больше десятка я даже говорить не буду.
Модель реализации сейчас такая: покупка билета состоит из двух шагов. Бронирование билета и выписка билета. Бронируя вы просто занимаете билет, но ничего не платите. Выписывая — вы подтверждаете, что заплатите. Западный онлайн и часть российского объединяет эти два шага для пользователя. В вашем варианте — такого объединения нет. Да, модель реализации формируют не агентства, а GDS и а/к. Повлиять на нее практически не возможно.
Что-то поменять после создания брони уже практически нельзя. Т.е. по правилам IATA нельзя менять только фамилию, имя и пол. Можно менять номер проездного документа (тип нигде не указывается), срок действия, дату рождения, гражданство и страну выдачи. Но если будет много таких ченжей, то агентство попадет на штрафы от а/к. Поэтому никто такие ченжи в онлайне не разрешает, их можно сделать только позвонив оператору.
Обе ваши кнопки сейчас, по сути, выполняют одно и тоже действие. Они создают бронь. Эта бронь будет висеть до наступления timelimit (который, кстати, критически важно показать). При этом вы заставляете на этом шаге пользователя сделать выбор, вместо того, чтобы просто создать бронь. Это плохо и для пользователя, т.к. вы на этом шаге заставляете его думать и плохо для вас, т.к. каждое раздумье пользователя — снижении конверсии. Поэтому вторая кнопка — лишняя.
После нажатия на любую из них вы что-то покажете человеку. Почему бы не показать ему форму оплаты кредитной карты и информацию о том, что он может оплатить в терминалах? О ситуациях, когда у вас этих способов оплаты больше десятка я даже говорить не буду.
Интересный обзор, но вот у меня лично закрались сомнения, что автор сам часто летает и покупал много билетов он-лайн.
Не по форме, а просто ремарка. Пол пассажира нужен для самой авиакомпании, как минимум для сбора статистических данных, но мне кажется это еще и требование IATA.
По форме: вертикальное расположение полей в формах занимает значительно больше места на странице. Для устройств с диагональю 10-13 дюймов это становиться действительно проблемой, так как надо еще и прокручивать страницу. Может казаться, что эта часть пользователей не самая большая, и можно сделать упор на владельцев больших мониторов. Но! зачастую выбор в пользу не большого устройства делается человеком, который много передвигается. Думаю такие люди гораздо ближе к ключевой аудитории сайта продажи билетов и надо их потребности учитывать в обязательном порядке.
Не по форме, а просто ремарка. Пол пассажира нужен для самой авиакомпании, как минимум для сбора статистических данных, но мне кажется это еще и требование IATA.
По форме: вертикальное расположение полей в формах занимает значительно больше места на странице. Для устройств с диагональю 10-13 дюймов это становиться действительно проблемой, так как надо еще и прокручивать страницу. Может казаться, что эта часть пользователей не самая большая, и можно сделать упор на владельцев больших мониторов. Но! зачастую выбор в пользу не большого устройства делается человеком, который много передвигается. Думаю такие люди гораздо ближе к ключевой аудитории сайта продажи билетов и надо их потребности учитывать в обязательном порядке.
Sign up to leave a comment.
Создание универсальной формы ввода данных о пассажире