Автодополнение адреса для сайта, новые возможности в черновиках
У сервиса «КЛАДР в облаке» большое обновление. В данной статье я хочу рассказать об обновлении наиболее близкой к большинству пользователей части этого сервиса, а именно о jQuery плагине. Кому интересно, добро пожаловать под кат.
Новая версия сервиса включает в себя несколько дополнительных возможностей, которые были так же отражены в плагине. Рассмотрим их подробнее.
Начнём наверно с самого важного и долгожданного обновления: поддержки ввода адреса одной строкой. Теперь для подключения этой возможности к полю ввода достаточно написать следующий код:
Посмотреть пример можно по ссылке.
Помимо этого мы реализовали фильтрацию населённых пунктов по типу (город, посёлок, село). Сейчас список предлагаемых населённых пунктов можно ограничить с помощью параметра typeCode плагина:
Посмотреть пример с использованием typeCode можно на сайте.
Ну и последней новой возможностью сервиса является поиск по почтовому индексу. Специально для неё был реализован плагин kladrZip. Он проверяет корректность введённого почтового индекса и если ему соответствует реальный адрес подставляет объекты этого адреса в другие поля формы. Звучит не очень понятно, согласен, лучше 1 раз увидеть. Подключается же плагин очень просто:
Это первая версия kladrZip, поэтому он практически не принимает параметров. В дальнейшем плагин будет дорабатываться.
На этом новые возможности сервиса, отражённые в jQuery плагине, закончились. Но это ещё не всё. Сам плагин был полностью переработан для того, чтобы сделать автодополнение адреса ещё удобнее для пользователя и менее трудоёмко для разработчика. Перечислю вкратце новые возможности:
Автодополнение адреса для сайта
Cервис «КЛАДР в облаке» чуть более недели назад стал абсолютно открытым и бесплатным. Помимо сервиса реализованы модули интеграции для различных языков и платформ. Эта статья о том как сделать автодополнение адреса на своём сайте с помощью jQuery плагина «КЛАДР в облаке«.
К слову, все примеры на официальном сайте реализованы с помощью данного плагина.
Ок, начнём. Плагин Primepix.Kladr унаследован от jQuery.ui.autocomplete, поэтому для его корректной работы нам понадобится jQuery и jQuery UI.
Подключение необходимых библиотек
Для jquery.primepix.kladr к сожалению CDN пока не поднят, поэтому его нужно скачать (github) и скопировать в проект. Так же добавим input для которого будем подключать автодополнение. Код всей страницы будет выглядеть следующим образом:
Теперь можно непосредственно подключить автодополнение из КЛАДРа. Для этого надо сначала зарегистрироваться на сайте сервиса и получить токен с ключом для доступа. После этого, в простейшем варианте, вам достаточно написать следующий код:
В этом случае будет производиться автодополнение регионами. Если вы хотите, чтобы автодополнение выполнялось районами или же населёнными пунктами нужно указать тип объектов для подстановки:
Теперь при вводе названия города вам будет предложен список вариантов.
Однако в этом случае автодополнение будет производится всеми населёнными пунктами России, а их не много не мало 200000. Если надо ограничить список населённых пунктов определённым регионом можно задать в параметрах плагина код родительского объекта:
Следует отметить, что для автодополнения улиц надо обязательно указать код населённого пункта, а для автодополнения строений нужно обязательно указать код улицы.
Плагин также позволяет получать объекты вместе с их родителями (в объект будет добавлено поле parents, в котором они будут перечислены).
Для тех, кто дочитал до данного места, самое интересное =) Если же вам понадобилось переопределить форматирование подписей в списке вариантов, это можно сделать передав в параметре label функцию для форматирования:
Вот здесь как раз и пригодился параметр withParents.
Аналогичным образом можно переопределить функцию для форматирования подставляемого в input значения:
Получить информацию о выбранном пользователем объекте можно подписавшись на событие select:
Сравнение сервисов для автодополнения адресов в форме
На Хабре не раз поднимался вопрос автодополнения адресов в форме (раз, два, три).
Но какой источник данных выбрать? Я выбрал целых четыре, и решил их сравнить: в одном углу ринга заморские Google Geocode и Google Autococomplete, а в другом отечественные КЛАДР в облаке и DaData подсказки.
DISCLAIMER: Автор никак не причастен к разработчикам ни одного из представленных сервисов.
Google Geocode (Google Maps API)
В примерах к плагину Typeahead в документации к AngularJS Boostrap UI использован именно Google Geocode для автодополнения адреса. Так почему бы не попробовать, если готовый код уже есть?
Делаем get запрос к адресу http://maps.googleapis.com/maps/api/geocode/json с параметрами
В ответ получаем json, парсим его, и вроде всё неплохо. Вот только нам надо ограничить область поиска только Москвой. Добавляем:
к параметрам и получаем интересное поведение:
Какую ахинею не ввёл бы пользователь, Google предложит «Москва, Россия». К тому же, название улицы он предлагает только после ввода третьей-четвертой буквы, а до этого все те же «Москва, Россия».
Можно ограничить результаты с помощью параметра ‘bounds’ (координаты юго-западного и северо-восточного угла рамки, внутри которой производить геокодирование), но это нестрогое ограничение, поэтому результаты будут появляться и из других областей.
Конечно, не стоит ожидать чудес от сервиса, который вообще не предназначен для автодополнения адреса, но все же резюмирую:
Надежный источник данных
Удобный способ запроса/доставки данных (запрос обычным GETом, обратно — JSON)
Возможно автодополнение одной строкой и даже разбивка полученных данных по компонентам (Страна, регион, город, улица, дом)
Тяжело ограничить область поиска
Сервис не предназначен для автодополнения
Google Autocomplete (Google Places API)
С Google Autocomplete у меня с самого начала не срослось: если запрашивать информацию обычным GETом, то гугловский сервер отвечает ошибкой CORS (Origin… is not allowed by Access-Control-Allow-Origin), а JSONP они не поддерживают после выхода третьей версией API. Некоторые говорят, что это сделано специально, чтобы в веб-разработке использовали их JS библиотеку. Конечно, можно еще сделать прокси, через который будут проходить данные, но я решил не заморачиваться ради такой мелочи.
Но для объективности сравнения, я все же попробовал Google Autocomplete через JS библиотеку. В итоге:
Надежный источник данных
Возможно автодополнение одной строкой
Легко подключить (если использовать их JS библиотеку)
Невозможно достучаться до API с фронтенда из-за CORS
Нельзя строго ограничить область поиска до одного города (Можно строго ограничить только страну, или нестрого ограничить с помощью параметра ‘bounds’)
КЛАДР в облаке
КЛАДР в облаке — отечественный сервис, который не раз упоминали на хабре.
Лично для меня он оказался неподходящим, т.к. не позволяет производить автодополнение одной строкой. Вы можете искать или регионы, или города, или улицы, или номера домов, но никак не всё это вместе в одной строке. То есть или придется разбивать одну форму на несколько, или искать только по названиям улиц только в Москве.
Мне это не подходит, но сильные и слабые стороны я всё же приведу:
Авторитетный источник данных (КЛАДР)
Постоянные обновления базы данных
Российский разработчик
Хороший API
Открытый исходный код
Невозможно автодополнение одной строкой
DaData подсказки
Я уже отчаялся найти сервис своей мечты и собирался вернуться к Google Geocode, как вспомнил про подсказки сервиса DaData.
Сразу перейду к сравнению:
Возможно автодополнение одной строкой
При начале ввода первых букв улицы, он сразу предлагает и номера домов на этой улице
Российский разработчик
Разбивка полученных данных по компонентам (даже индекс и код КЛАДР и ОКАТО)
Неизвестная база данных
Бесплатным пользователям не гарантируется стопроцентный uptime
Неочевидный формат запроса данных (POST, а не GET)
Скудный API
+ БОНУС: автодополнение еще и имён.
В итоге лично я решил остановиться на последнем варианте, заодно и воспользоваться их автодополнением имён. Правда я считаю, что у каждого свои задачи, и для каждой конкретной задачи нужен свой инструмент.
Топ-3 плагина для автозаполнения полей
Введение
Сегодня я расскажу про плагины браузера, которые помогают быстро заполнить поля тестируемой формы. Рассказ также доступен в виде видео. Мой топ-3:
Если авторизоваться в системе, можно добавить новую компанию. Из обязательных полей только «название» и «тип», но есть еще 6 дополнительных — ИНН, ОГРН, КПП, телефон, адрес, сотрудники.
Форма создания компании в Users
Для тестирования обычно нужно иметь хотя бы одну полностью заполненную карточку. И именно это вызывает тоску — сидеть и прописывать все поля формы. Даже когда все эти поля — простые строки, всё равно скучно. А уж если они ещё и с ограничениями…
Вот, например, правила формирования ИНН и КПП. Иногда система даже контрольные суммы выверяет, там просто “123” не введешь! В Users проверка проще, только по количеству цифр, но “123” или “ааа” тоже не прокатит =)
Получается, что при заполнении карточки нужно включать мозг и писать значения осознанно. Это интересно делать один раз, а потом — нудная рутина. Рутину лучше автоматизировать. В users это даже несложно, можно сохранить в postman запрос на создание и заполнение всех полей.
Но эта статья не про автоматизацию, а про плагины. Я уверена, что их сильно больше, чем описано тут. Но чем больше выбор, тем он сложнее. Так что я дам свой топ-3, а дальше уже сами выбирайте))
Заполнять будем форму создания компании в Users и форму создания пользователя. Она еще хардкорнее, там 20 полей!
Форма создания пользователя в Users
Ну что, давайте сравнивать плагины!
3 место — Bug magnet
О плагине
Заполняет поля по одному и с участием человека — нужно выбрать значение, которое хочется подставить.
Но зато в плагине есть куча разных типов полей:
Autofill: чего не знают веб-разработчики, хотя должны знать
Многим известно, что в мобильной версии Safari можно отсканировать свою банковскую карту. Но многие ли разработчики умеют создавать формы, поддерживающие эту возможность?
Готов поспорить, что немногие.
Дело осложняет полное отсутствие документации от Apple по работе этой функции. Но тут есть один момент. Функция сканирования банковских карт является подмножеством автозаполнения — браузерного функционала, давно игнорируемого веб-разработчиками. Понятно, почему они не уделяли ему должного внимания: когда регулярно заполняешь форму тестовыми данными, автозаполнение обычно мешает. Но для наших пользователей это важная функция. В Google выяснили, что при использовании автозаполнения пользователи на 30% быстрее заполняют формы. Так что давайте изучим работу автозаполнения, разберёмся, как создавать формы, поддерживающие кросс-браузерное автозаполнение, и воспользуемся преимуществами новых возможностей наподобие сканирования банковских карт.
Как работает автозаполнение?
До недавнего времени не существовало стандартов, регламентирующих реализацию автозаполнения. В каждом браузере это делалось по-своему, и было доступно очень мало документации, описывающей браузерный механизм определения контента, который нужно внести в то или иное поле.
Несмотря на такую анархию, можно выделить два основных подхода:
1. Поля с заранее заданным автозаполнением
Chrome, Opera и Safari обнаруживают наиболее важные поля в форме и позволяют выбирать, какими данными браузер должен автоматически их заполнить. К примеру, Opera умеет автоматически заполнять адреса и реквизиты банковских карт. Эта функциональность настраивается здесь:
Каждый из трёх браузеров имеет свой набор полей, к которым может применить автозаполнение, но поддержка основных полей платёжных форм реализована практически везде.
Для использования автозаполнения большинству пользователей не придётся обращаться к этим настройкам. Браузер отслеживает заполнение человеком форм и, когда распознаёт поля для адреса и реквизитов банковской карты, спрашивает, нужно ли сохранить введённые данные для последующего использования.
2. Автозаполнение любых полей
Если предыдущий подход можно сравнить со скальпелем, применяемым к заранее выбранным полям, то этот сродни бензопиле, режущей всё на своём пути.
Хотя второй подход позволяет работать с большим количеством полей, я как разработчик предпочитаю вариант с заранее заданными полями. Так гораздо проще определять, какую информацию должен заполнять браузер, да и легче настраивать тестовые профили.
Кроме того, при втором подходе вам нужно сначала отправить заполненную форму, чтобы браузер сохранил у себя данные для последующего автозаполнения. Без отправки он не запомнит введённую вами информацию. Также мне неприятно думать, что браузер может хранить реквизиты моей банковской карты в незашифрованном виде, если не определит тип поля.
Разумеется, Microsoft и Mozilla заинтересованы в обеспечении безопасности и приватности, и я уверен, что они предусмотрели какие-то защитные механизмы. Но лично мне гораздо спокойнее видеть в настройках браузера, что он распознаёт и чётко отделяет данные по банковской карте.
Учитывая всё сказанное, я не знаю предпочтений конечных пользователей. Вторая система может применяться шире, но я видел немало обращений в службу поддержки, когда люди пытались убрать данные автозаполнения из истории браузера.
Будет интересно посмотреть, как изменятся Edge и Firefox после того, как начнут поддерживать новый стандарт автозаполнения.
Поведение, которое нужно отслеживать
Иногда браузерам требуется более одного поля определённого типа, чтобы предложить вам варианты автозаполнения. Например, ниже показано, как Safari не станет автоматически заполнять одиночное поле имени владельца банковской карты, но если рядом есть поле для номера карты, то браузер предложит это сделать.
Тем не менее, если присутствует только поле номера карты, Safari предложит его заполнить. Согласно моему опыту, из-за этого поведения браузера бывает непросто тестировать отдельные ситуации с одиночными полями. Однажды во время тестирования я столкнулся с тем, что Opera потребовала наличия трёх полей для применения автозаполнения, но больше мне не удалось воспроизвести такое поведение.
Если ваша форма создана с поддержкой автозаполнения (об этом ниже), то пользователи не должны встречаться с такими ситуациями. Я просто упоминаю это на случай, если вы также встретите подобные странности в процессе отладки и тестирования автозаполнения.
Использование стандартов при реализации автозаполнения
Недавно были добавлены новые значения атрибута — autofill detail tokens. Эти токены помогают браузеру понять, какая информация нужна для заполнения поля.
Наименование компании, относящееся к человеку, адресу или контактной информации в других полях, связанных с этим полем.
Пример поля с автоматическим заполнением названия организации будет выглядеть так:
В спецификации HTML5 есть огромная таблица, где перечислены все 53 возможных наименования поля автозаполнения, указано их назначение и типы инпутов, с которыми их можно использовать.
Это простейший вид автозаполнения, но оно становится мощнее и сложнее.
Значением атрибута autocomplete является разделённый пробелами список токенов. К примеру, если вы хотите собрать данные для доставки товара, то перед значением атрибута нужно добавить токен shipping :
Телефоны, электронная почта и ники в мессенджерах
Для номеров телефонов, адресов электронных почт и ников в мессенджерах используется другой вариант токена. Для таких случаев предусмотрен опциональный токен, обозначающий, что в поле нужно ввести номер домашнего ( home ), рабочего ( work ), мобильного ( mobile ) телефона, факса ( fax ) или пейджера ( pager ).
Общие и уточняющие наименования полей автозаполнения
Для многих типов информации в спецификации определены общие (broad) и уточняющие (narrow) наименования полей автозаполнения. Скажем, в дополнение к единственному полю для ввода номера телефона tel можно использовать:
В целом авторам рекомендуется использовать общие наименования, а не уточняющие, поскольку последние навязывают западные стандарты. Например, в ряде стран принято сначала писать имя, а потом фамилию, в то время как во многих других странах принято писать наоборот — сначала фамилию, потом имя. Также немало стран, где используется одно лишь имя (мононим). Поэтому использование одного поля ввода является более гибким подходом.
Я согласен с этой рекомендацией. С практической точки зрения это означает, что важно уделять внимание таблице значений и выбирать правильное наименование для каждого поля.
При использовании токенов автозаполнения они должны следовать в таком порядке:
Помните, что токены [home|work|mobile|fax|pager] применяются только для полей ввода номеров телефонов, адресов электронных почт и ников.
Самый длинный из возможных наборов токенов автозаполнения может выглядеть так:
Да здравствуют стандарты! На этом всё, правильно?
Боюсь, что нет. Я лелею надежду, что в конце концов все браузеры будут поддерживать расширенный стандарт автозаполнения, но пока это не так. Я протестировал мобильные и настольные версии браузеров, чтобы выяснить текущую ситуацию с поддержкой атрибутов. Вот результаты:
Странное поведение Safari
С момента появления в iOS 8 функции сканирования банковских карт веб-разработчики занимаются гаданием на кофейной гуще, стараясь определить, какую комбинацию признаков ищет Safari. Кто-то считает, что в атрибуте name нужно иметь определённые значения. Другие обнаружили, что используются значения в ID. Кажется, даже лейбл имеет значение:
Поле для имени владельца карты особенно хитрое. Мы долго игрались с разными ID и почти сдались. Нам не удалось вычислить ID, который заставил бы Card Scan заполнить реквизиты. После многочисленных разочарований мы наконец-то обнаружили, что всё дело в содержании соответствующего элемента label. Как только мы установили лейбл «Name on card», всё волшебным образом заработало.
Я провёл немало тестов и до сих пор не могу с уверенностью утверждать, что полностью разобрался в работе Safari. Тем не менее я всё же пришёл к нескольким основным заключениям:
Autocomplete поддерживается в полях ввода контактов и адреса
Safari распознаёт созданную мной форму, содержащую только атрибуты autocomplete. Как только я начинаю писать в первом поле, браузер предлагает заполнить форму моими контактными данными.
Всё работает, как и должно, но нужно сделать пару пояснений.
Во-первых, неясно, какая информация используется Safari для принятия решения об автозаполнении моих контактов из адресной книги Mac’a. Здесь указана моя должность, а название компании — нет.
Во-вторых, браузер не предлагает на выбор варианты для заполнения. В моих контактах указаны домашний и рабочий адреса, и Safari заполняет только домашний. Так что мне не повезёт, если я захочу заказать доставку в офис.
Автозаполнение платёжных форм работает совершенно ненадёжно
Поведение Safari в корне меняется, когда дело доходит до полей платёжных реквизитов. Атрибут autocomplete игнорируется. Вместо него браузер использует какую-то волшебную эвристику. А поскольку я не маг из Apple, то мне было трудно распознать, что же на самом деле происходит:
Список значений, по которым Safari выполняет поиск, нигде не опубликован. К счастью, Жак Карон смог извлечь этот список строковых значений из эмулятора iOS:
Создание кросс-браузерной автозаполняемой формы
Учитывая всё вышесказанное — действительно ли можно создать форму, поддерживающую автозаполнение в разных браузерах? Я думаю, да.
По крайней мере, можно очень близко подойти к этой цели, выполнив четыре шага:
1. Добавьте атрибуты autocomplete
Это будущее автозаполнения. Если браузеры не распознают значения, то они их игнорируют. Это отличный пример прогрессивного улучшения.
2. Используйте для атрибутов name стандартные значения
При реализации автозаполнения в Firefox и Edge вам остаётся надеяться, что выбранные вами значения для атрибута name совпадают с теми, которые используют другие разработчики на своих сайтах. Для этого можно проанализировать популярные сайты и посмотреть, какие там значения. Или можно взять те же значения, что и в атрибуте autocomplete, в надежде, что чем больше веб-разработчиков познакомятся со стандартами, тем чаще будут использовать для своих полей те же наименования.
3. Добавьте значения name и/или label в соответствии с используемым в Safari списком
4. Внесите автозаполнение в ваш план тестирования
Недавно я попросил у своих слушателей поднять руки, у кого в плане тестирования есть автозаполнение. Ни у кого не было. Я работаю в веб-разработке с 1996 года и до сих пор не встретил тех, у кого в плане тестирования было бы автозаполнение. Наверное, это какая-то слепая зона разработчиков и дизайнеров. Тем не менее крайне важно тестировать эту функциональность, чтобы удостовериться в её надёжной работе.
Финальная форма
Вот пример формы, поддерживающей автозаполнение в Chrome, Safari, Opera, Firefox и Edge:
Чтобы увидеть её работу, вам нужно просмотреть её на CodePen через HTTPS, в противном случае браузер не заполнит реквизиты банковской карты. Я также сделал форму с 53 полями по спецификации autocomplete. Пока что ни один браузер не поддерживает все эти поля.
Будущее автозаполнения и форм
Разработчики браузеров активно работают над проблемой веб-платежей. Mozilla, Microsoft, Google и Facebook совместно создали Payment Request API. Apple участвует в Web Payments Working Group, где обсуждается и Payment Request API. Так что Apple номинально тоже примкнула к этому проекту.
Ходят слухи, что сервис Apple Pay будет доступен в мобильном вебе к сезону праздничного шоппинга, так что веб-платежи в этот раз могут получить новый импульс.
Возобновление интереса к упрощению процесса оплаты внушает мне надежду, что в ближайшее время улучшится поддержка autofill detail tokens. Эти токены сильно облегчают создание форм, работающих с автозаполнением.
И самое важное — поддержка автозаполнения сделает заполнение форм менее утомительным для наших пользователей, что поспособствует росту продаж в сегменте e-commerce.
