Pull to refresh

Comments 90

Подскажите, пожалуйста. Я не совсем понял, будет ли возможно следующее поведение:
— при поиске, Яндекс отправляет запрос сайту;
— если пользователь авторизован на сайте, то показывается один остров (например, с каким-то действием, требующим авторизации);
— если же пользователь не атворизован, то показывать другой остров с формой регистрации/авторизации.

Т.е. я правильно понял, что это будет возможно за счёт real-time взаимодействия?
Да, мы рассматриваем возможность авторизованного взаимодействия. Подробности чуть позже.
Интересно, я один пытался зайти на santehnik-mario.su?
пошел регистрировать этот домен)
Теперь точно не один.
Я одного не понимаю: получается, сейчас количество контролов внутри острова ничем не ограничено?
Т.е. я могу создать остров высотой во весь экран, напихав туда кучу полей?
Прямо сейчас можно сделать любой остров.
В дальнейшем, возможно, на внешний вид островов появятся дополнительные ограничения. Нынешний эксперимент мы проводим как раз для того, чтобы лучше понять, какими они должны быть.

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

UPD: я буду рефрешить комментарии перед отправкой!
Пожалуйста, сделайте ещё хотя бы несколько примеров островов — сейчас документации сильно не хватает.

И ещё проясните такой момент: я сделал остров для своего сайта, xml-файл, проверил его в вашем сервисе. Что мне потом с ним делать (после официального запуска островов)? Куда его добавлять, что прописывать на сайте?

И если сайт по соответствующему запросу, скажем, на 42 месте, то будет ли отображаться остров? Или есть какое-то ограничение на глубину показов островов?

Это далеко не все интересующие вопросы, но я смог вовремя взять себя в руки и остановиться :)
Мы планируем сделать библиотеку примеров островов.
2) Сейчас тестировать создание острова через описание формы в xml-файле можно впесочнице. В какой-то момент они переедут внутрь Яндекс.Вебмастера, будут привязаны к конкретному сайту и станут таким же инструментом, как, например, «оригинальные тексты».

3) Ограничения на глубину показа не планируются. Пример с расширенными сниппетами.
Интересно, в выдаче острова будут показываться для всех сайтов, которые их сделают, или выборочно.
И если выборочно, то от чего будет зависеть, покажет Яндекс остров или нет?
Выборочно. Мы следуем одному принципу — запускать только то, что увеличивает счастье пользователя. Поэтому всегда тестируем и измеряем, какое влияние на поведение пользователей оказывают новые элементы.

Политика показа островов будет сформирована на основе этих экспериментов.
UFO just landed and posted this here
Ответ x1 ≈ −0.27 у вас не примут ни на одном ЕГЭ

Если честно, у нас не было цели решить уравнение, чтобы кто-то мог сдать его на ЕГЭ.
Формулы для правильных ответов там даны, наглядно тоже видно всё, что нужно.
UFO just landed and posted this here
Интересно, а 0,2(6) был бы верным в ЕГЭ?
В тесте не может быть задания с таким ответом, потому что разрешены только конечные десятичные дроби.
В любом случае должна быть запятая, а не точка.
Это явно баг.
Программисты с вами не согласны
Я сам программист и согласен с собой. Следовательно, ваше утверждение неверно.
Вы можете потерять огромную аудиторию определённого возраста, если в ответах Яндекса по ЕГЭ будут ошибки! :-D
Потерять на определенный срок, всего лишь. От года до двух.
Так вроде, срочники сейчас даже на флоте год служат. Или я уже не в теме?
Действительно не в теме. ЕГЭ в вузах не сдают.
Будут ли помимо представленных элементов форм добавлены такие как Textarea? К примеру: на сайте есть сервис «Вопрос-ответ». Было бы удобно, чтобы пользователь мог задать вопрос не переходя на сам сайт, прямо в результатах выдачи.
Мы подумаем над этим — кажется, такой кейс действительно есть.
Покажи какой у тебя остров и я скажу какой у тебя сайт.
Заголовок поста, кстати, вводит в заблуждение. Я думал тут действительно будет что-то про API, а тут
В настоящее время из всех возможностей, описанных в спецификации, наш редактор поддерживает только передачу описания формы в отдельном xml-файле

В остальном, всё это в той или иной форме повторяет предыдущий пост.
Предыдущий пост был про визуальную сторону, этот — про техническую. Причём это как про сам пост, так и про то, какие вопросы можно и нужно задавать.
Экспериментировал с островами. Нашел нюанс: чтобы работала автоподстановка слов из запроса в форму, надо, чтобы все значения были уникальными. То есть, если вы продаете двери и окна, то нужно делать форму отталкиваясь сначала от материала, а потом от типа товара.

Если вы сделаете вложенные выпадающие списки так:
  • Окна
    • Деревянные
    • Пластиковые
  • Двери
    • Деревянные
    • Пластиковые
    • Металлические

то при запросе «окна деревянные» подставится только слово «окна». Но для запроса «Двери металлические» подставится значение уже в оба списка.

Можно посмотреть примеры:

Здесь тип зависимости является дочерним списком для каждой из услуг. Наименования дочерних пунктов совпадает, работает автоподстановка только для первого слова (для услуги).
Запросы: «Детоксикация при наркомании», «Реабилитация при алкоголизме».

Здесь списки услуг и параметров услуг разделены (списки услуг и типов зависимостей несвязаны). Автоподстановка работает нормально.
Запросы: «Детоксикация при наркомании», «Реабилитация при алкоголизме».

Здесь тип зависимости является дочерним списком для услуги. Попытался уникализировать типы зависимости, изменяя словоформы. Автоподстановка работает.
Запросы: «Детоксикация при наркомании», «Реабилитация алкоголиков».

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

В вашем случае должно быть так:

Объект — окна, двери
Материал — дерево, пластик, металл

Тогда вы не будете испытывать никаких проблем.
А если окон металлических нет и не предвидится — забивать лишними «островами» выдачу?
«Остров» — это сам сниппет с вашими полями. Забить своими «островами» выдачу вы не сможете, так как сниппет всего один.
Если металлических окон нет, то в случае с xml, при нажатии на кнопку «искать», человек получит пустой ответ.
В случае с API можно сделать поля зависимыми и «налету» проверять есть ли окна с выбранным типом материалов. Если человек выбрал «металл», а таких окон у вас нет, то в поле «объект» окон не будет. Будут только двери.
Или от обратного: если человек выбрал в поле объект «окна», то ему не будут показываться материалы, которые не привязаны к окнам.
Я так понял, что «острова» выдаются не по названию фирмы, а по любому подходящему запросу, т.е. по запросу «окна металлические» вылезут все «острова» на эту тему.
Надеюсь вы не думаете, что вылезут все ваши «острова»? :)
Лично я сайтиков не держу и «островов» не делаю (пока). А думаю я, что острова будут вылезать так же, как и сайты — по релевантности/надежности/достоверности или как там ещё. Возможно, будут разворачиваться из ссылки на сайт.

Эгей, представители Яндекса, прокомментируйте хоть!
Для начала интерактивный элемент будет жестко прибит к тому месту, на которое ранжирование поставило соответствующий сайт.
А потом посмотрим, как полетит.
Не-не-не, это у нас бага. Было бы странно заставлять вебмастера предлагать пользователям «металлические окна».
Да, есть проблема с разбором запроса при наличии нескольких фильтров с одинаковыми caption'ами. Знаем, починим.
И спасибо за «ветвистые» примеры.
Очень не хватает datePicker фильтра.
Знаем, сделаем, но не все сразу. 8)
не забудьте пожалуйста и о periodPicker'е, не важно будет это один datePicker или два, главное функция у него достаточно специфическая.
Это может быть:
1. ограниченный диапазон каледаря(даты мин-макс, смена года/месяца)
2. бесконечные значения мин-макс
3. не установленные значения мин-макс(как вариант могут символизировать бесконечные)
4. предустановленные значения
5. встроенный timePicker для обоих значений
6. ну и т.д.
Пятый пункт не понял. Поясните?
Остальное собираемся приделать (правда, совместив бесконечность и неустановленность).
ну чтобы возможность была время тоже указать помимо календарика. Для бронирования обычно является актуальным.
Будут ли Яндексом монетизироваться снипеты? Например, онлайн-бронирования или покупки товаров?
Острова повлияют на нашу модель монетизации, но говорить об этом до появления нового интерфейса в продакшене пока рано.
Почему вы назвали «Острова» — Островами если это набор(судя по картинкам) одинаково оформленных форм?
Называете «Острова» — тогда добавляйте в спецификацию ограниченную поддержку пользовательских стилей оформления! Планируется?
Логично. Сейчас нет ограничений на тему и внешний вид формы в острове, чтобы все сайты могли пробовать, как это работает. Далее наберем критическую массу, сформируем стайлгайды и все будет аккуратно.

На первом этапе каждый из островов, который мы будем публиковать в бете, попадет на доработку у наших дизайнеров.
Не подскажите где можно к острову подцеплять стили или выбирать темы?
Под темами я имел ввиду не оформление, а сегмент, в котором находится конкретный сайт. Свобода в том, какие именно поля формы использовать в острове. Дизайн функциональных элементов острова и стиль его оформления останется единым.
интересно, подумалось после Вашего замечания об API Яндекс-карт. Там мы на своих картах сами вольны выбирать иконки для меток.
Я имел ввиду как раз про что-то вида стилевых тем на выбор.
Может и сам Яндекс-поиск воспримет идею отойти от шаблонов и позволить пользователям хоть на каплюшечку кастомизировать свои островки в интернете?
БЭМ вроде никак это не ограничивает, темы можно сделать не по css в API а по типу Android: темная тема, светлая тема, зеленая тема…
После мысли о том что можно на сайте сделать в xml остров, который будет в поиске на Яндекс, и который можно будет еще и с помощью api островов Яндекс, встраивать на другие сайты — вообще голова кругом идёт. Как идея?
Для нас очень важна консистентность опыта для пользователя. Он не должен привыкать к внешнему виду контролов или осваивать новую схему организации данных.

Это, кстати, одна из причин, по которой «Острова» включают в себя не только интерактивные ответы и новый интерфейс поисковой выдачи, но и единый портальный стиль. Сначала на него перейдут ключевые поисковые сервисы, а потом и остальные.

Но идея кастомизировать острова для внешних сайтов по примеру API Яндекс.Карт интересная, возьмем ее на заметку.
Про вынос интерактивных островов на третьи сайты — отличная идея, но несколько преждевременная. 8)
Можно ли будет привязывать к сайту несколько островов?
Например у нас в магазине несколько типов товаров и для каждого типа есть уникальные характеристики… Если перечислить их все — остров будет очень большой и сложный для пользователя… а так при поиске покажется наиболее релевантный остров, где будут характеристики уже конкретной группы товаров.
Теоретически можно несколько. Но надо ли?
Многие-многие разделы сайта легко умещаются в одном дропдауне, а внутренняя структура каждого — в зависимых фильтрах.
Кроме того, мы не просим вас все фильтры протягивать в форму. Тащите только самые востребованные.
Пример:
На сайте есть два раздела: «Запись на прием к специалисту» и «Вопрос специалисту».
Логично иметь два острова, которые бы выводились в зависимости от запроса. Так как в одном обе функции не уместить.
Запихивать в дропдауны — это значит прятать(!) от пользователя то, что он, по идее, должен был видеть как раз сразу. Ведь острова, если следовать презентации, для этого и создавались…
Так ведь пользователю можно показать предзаполненный остров, и ничего важного от него спрятано не будет. Все ок.
Не понял. Это как?
Ну вот например, для острова «Запись на прием к специалисту» выводятся поля:
Время приема (дропдаун), Ваше имя (поле ввода), Ваш email (поле ввода), Кнопка сабмит

А для записи «Вопрос специалисту» выводятся поля:
Ваше имя (поле ввода), Ваше сообщение (texteareа, надеюсь это будет ;)), Кнопка сабмит

Как это сделать в одном острове?
Классический для нас пример разных форм — поиск билетов на сайте авиакомпании и регистрация на рейс. В первом случае — это поисковая форма, за которой на сайте находится выдача с рейсами, во втором — транзакционная форма, за которой необходимо ввести свои данные.

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

Запихивать их в начальный дропдаун, по типу «Выберите что вам надо: поиск билетов или регистрация на рейс»?
Можно сделать 2 острова и привязать их к разным страницам. Можно сделать структуру островов в одном xml-файле, используя в качестве дерева структуру сайта, и привязать их к хосту. Первый вариант сейчас кажется проще, посмотим, как будет лучше это реализовать.

К тому же, мы хотим поддержать разметку простой формы внутри html. Тогда остров будет описан на той странице, которая будет показана в поиске.
Будем ждать полной спецификации
ещё не хватает такого элемента, как выпадающий список с одновременным выбором нескольких вариантов…
по крайней мере в документации я не нашёл такого :(
А для чего вам это нужно?
Ну конкретно я столкнулся с проблемой одновременного выбора нескольких размеров одежды, когда начал делать остров для своего сайта… делать 20 чекбоксов — слишком громоздко, а селект позволяет выбрать только один элемент…
Предвижу, что ещё столкнусь с этой проблемой при выборе страны производителя…
Да и в том самом примере поиска авто, который приведен в документации… если я ищу седан или хетчбэк… мне придётся 2 раза искать…
А вообще множественный выбор — это стандартная логическая конструкция: "… AND x in (a,b,c,d )… "
Запросов с множественным выбором в потоке очень негусто, поэтому мы отказались от этого кейса на первых порах. Если будет заметный спрос на такие контролы — прикрутим и их.
Пока же я бы рекомендовал использовать для таких случаев обыкновенный dropDown.

Кроме того, мы не претендуем на то, чтобы вебмастер выносил в форму все свои фильтры. Нам бы хотелось, чтобы туда были вынесены лишь наиболее востребованные — которых хватит большинству; а привередливым пользователям, мы надеемся, будет несложно дофильтровать и на сайте, за кликом.
Какой запрос нужно послать, чтобы появился график отключения гор. воды (Нск)?
Перечитал всю документацию, но так и не понял — будет ли поддержка нескольких островов для сайта? Мне была бы интересна привязка уникальной формы для каждого типа страниц (через указание этой формы в мета-тэгах страницы, например).
В документации про привязку действительно пока ничего нет.
Но сделаем, да.
Некоторые примеры островов оторваны от жизни.
Например заказ книги. Прям сразу у нас покупатели стали безрассудные, и готовы заказать товар/услугу у первого попавшего магазина, не посмотрев на сам сайт, не посмотрев на стоимость доставки, не почитав о нём отзывы (надёжен ли он, не кинут ли). Ага, щас.

Теперь о технической части.
1. Автоподстановка EMail и телефона. В видео емейл Сегаловича подставляется сам, в документации про это ни слова. Какое название поля должно быть чтобы работала автоподстановка? Как это взаимодействует с «адрес из профиля Яндекс»?
2. В справке не примеров с кнопкой «заказать». Если заказ будет работать в поиске Яндекса, как в этом случае будут срабатывать цели метрики и GA?
По этой причине проведение транзакции непосредственно на странице результатов поиска — не является приоритетом для нас. Это подходит для простых рутинных операций, когда пользователь хорошо понимает поставщика, с которым имеет дело. Например, регистрация на рейс, заказ такси, трекинг посылки.

1. Мы рассматриваем opt-in заполнение полей формы данными из профиля пользователя (в частности, подстановка e-mail), но пока не фиксировали это в документации. Расширим новыми типами данных текущую подстановку адреса из профиля в магазинах Яндекс.Маркета (см. здесь, как это работает).

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

Фиксированный адрес: example.com;
Три параметра (выпадающие списки): x, y, z — у каждого независимые наборы значений;
Адрес формируется таким образом: example.com/prefix/[x/][y/][z/]
Если какой-то параметр не указан, то он не участвует в формировании ссылки.
Пока нельзя; добавим, если увидим, что такое часто нужно. А можно живой пример такой структуры?
Живой пример: rezina.ecar.kz/newtyres/summer/bridgestone/205/55/R16

Здесь rezina.ecar.kz/newtyres — фиксированная часть, а остальные компоненты адреса можно произвольно переставлять местами, удалять или добавлять. Получается приятный ЧПУ и очень хорошо работает в поисковиках
Как сделать информационный остров? Нигде в документации этого нет. А очень хотелось бы.
К примеру, как у кинопоиска — с ссылками и картинками
Информационные острова в документации будут поддержаны позже. Следите за обновлениями.
расскажите, что вы называете термином «Остров»? обычный сниппет выдаче это остров? или остров это некоторая группа сниппетов? а может быть остров это представление сайта в поисковой выдаче где есть интерактивная форма? а врезка это остров?
Островом мы называем выделенный блок на выдаче: это может быть колдунщик, врезка, отдельный сниппет или группа сниппетов. Интерактивными ответами называем остров сайта с интерактивными элементами.

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

Радует, что созданные острова можно тестировать уже сейчас и делать интересные примеры. Чешутся руки посмотреть как бы это работало в реальной выдаче.
Мы продолжаем проработку вариантов отображения островов, поэтому могут быть незначительные расхождения в ответах нашего саппорта. Гайды по дизайну островов, где в т.ч., ограничивается их потенциальный размер, мы в скором времени опубликуем.

Специальных тематических ограничений для создания острово, которые бы выходили за пределы п.п. 4, 5 «Пользовательского соглашения сервисов Яндекса» (http://legal.yandex.ru/rules/), на сегодняшний день нет. Возможно, коррективы внесет недавно принятый закон об авторском праве.
Протестировал xml острова у вас в редакторе форм. Вроде устраивает.
Куда его дальше?
Когда все начнется?
В июле мы запускаем бета-версию платформы «Острова» в России. Постепенно там будут появляться острова, которые сделаны в редакторе форм. Следите за обновлениями в нашем вебмастерском блоге.
Я не понял как происходит процесс добавления острова. Просто загрузить файл, а Яндекс распарсив URL сделает выводы? Или нужно какое-то специальное добавление острова к сайту? Объясните пожалуйста.
Мы готовим документацию про это.
Есть ли возможность вставлять радио-кнопки в интерфейс? Если нет, то когда будет/планируется ли вообще?
Пока радиокнопки не планируются.
С Директом Острова будут дружить? Очень хотелось бы.
Sign up to leave a comment.