Решение проблем является основным аспектом разработки программного обеспечения, часто существует множество различных решений проблемы, и хороший разработчик будет стремиться к самому простому без ущерба для удобства обслуживания. Тем не менее, бывают определенные моменты, когда просто не существует элегантного способа решения проблемы, поэтому вы заканчиваете тем, что пишете то, что обычно в отрасли называют хаком . Вы, вероятно, не будете этим гордиться, и, возможно, вы даже зафиксировали код под псевдонимом, чтобы никто не мог обвинить вас в этом, но как бы ни был уродлив, взломщик все же решает проблему, и следующее, что вы знаете, вас спрашивают написать блог, детализирующий каждую его отвратительную щель.
Давайте на шаг вернемся на время назад, это обычный рабочий день, вы просто устраиваетесь на какое-то приятное исправление дефектов, когда вас зовет высшее руководство. Вы находитесь на сайте клиента, и возникла проблема с онлайн-кампанией, созданной внешним маркетинговым агентством. Целевая страница кампании включает в себя видео с YouTube, это интерактивная игра, в которую входят кнопки, которые будут загружать различные видео при нажатии.
К сожалению, интерактивные элементы не работают на мобильных устройствах, что усугубляется тем фактом, что 40% их трафика является мобильным и что они уже запустили телевизионную рекламу, баннеры на веб-сайтах и почтовые вставки, указывающие на эту страницу. Кажется, что это не должно быть слишком сложно исправить, у вас, вероятно, уже есть целая куча идей…
Решение, санкционированное YouTube
Если присмотреться, кнопки внутри видео используют общепринятую в настоящее время технику добавления аннотаций для создания активной точки в видео YouTube. Ваш первый шаг — просмотреть документацию YouTube; Существует много разных вариантов размещения видео на веб-странице, поэтому неосторожное маркетинговое агентство, вероятно, просто забыло поставить галочку в поле, позволяющем добавлять аннотации.
После небольшого рытья вы увидите страницу со сноской, указывающей, что аннотации не поддерживаются мобильными игроками. Менеджмент не доволен этим результатом, поэтому они напрямую звонят в Google, их тон-компания с намеком на смятение, тем более, что у Google нет никакого чудодейственного решения.
«Аннотации не поддерживаются на мобильных устройствах и не будут появляться в ближайшее время. Ты не должен их использовать.
Несмотря на разочарование, становится очевидным, почему Google занял такую позицию, но это осознание, которое не поразит вас, пока вы полностью не погрузитесь в лабиринт мобильных видео манипуляций.
HTML макет аннотации
Так что Google не поможет, это не страшно, когда в последний раз они вам были нужны? О . Кнопки уже существуют визуально в видео, поэтому ваша задача — найти способ обнаружить щелчки (или касания мобильных устройств ) и выполнить действие невидимых аннотаций, чтобы воссоздать эффект интерактивного видео.
YouTube на самом деле имеет довольно хороший JavaScript API, поэтому загрузка нового видео в тот же встроенный проигрыватель не является проблемой после того, как щелчок был обнаружен, но тот факт, что проигрыватель работает внутри iFrame, представляет собой небольшую проблему. IFrame — это веб-эквивалент черной дыры — пользователь может щелкнуть все, что ему нравится, но вы не будете знать, где находился курсор или вообще имел место щелчок.
Возможно, вам повезет больше, если вы управляете страницей внутри iFrame, но проигрыватель и его контент поступают непосредственно с YouTube, поэтому меры по межсайтовому скриптингу отключат вас, прежде чем вы даже сможете подумать о написании этого вызова функции.
//Are you kidding? This isn't going to work!
$("iframe").click(function () {
player.loadVideoById(video);
player.playVideo();
});
Однако вы контролируете веб-страницу, в которую встроено видео, поэтому более эффективный обходной путь — это абсолютно позиционировать некоторые прозрачные элементы div над видео в том же визуальном пространстве, в котором появляются кнопки, и вместо этого обнаруживать щелчки на элементе div. Есть некоторая ручная работа по позиционированию и времени, когда div должен наложиться, но взлом, кажется, работает отлично на устройстве Android… но не на iPad.
Что с этим iPad?
Устройства iOS — это совершенно другая порода боли и страданий. Хотя вы можете просто отображать HTML-элемент поверх видеоплеера iPad, вы не можете обнаружить на нем никаких кликов. Внутренне веб-движок iOS вырезает невидимую дыру в области, занятой видеоплеером, поэтому он может использовать аппаратный рендер для этой части страницы. Хотя щелчки все еще обнаруживаются в этой области, они отправляются непосредственно в элемент видео, и событие щелчка будет проходить прямо через перекрывающиеся элементы, как если бы они были просто проявлениями ума.
Подумав об этом, вы придете к решению, которое намного уродливее и оказывает небольшое влияние на взаимодействие с пользователем. Для этой конкретной кампании призыв к действиям в видео появляется ближе к концу, и хотя видео продолжает воспроизводиться, это всего лишь фоновая анимация в режиме ожидания, причем основное внимание уделяется кнопкам, стимулирующим взаимодействие с пользователем.
Используя то же определение времени из исправления Android, вы пишете сценарий, чтобы скрыть элемент видео и заменить его статическим снимком экрана, расположенным точно в том же месте. Это создает иллюзию приостановки воспроизведения видео при появлении кнопок и в качестве дополнительного бонуса обеспечивает механизм обнаружения щелчков и восстановления функциональности интерактивного видео.
Взлом iPhone плеера
К сожалению, когда дело доходит до воспроизведения видео, iPhone берет на себя все хорошее, что соответствует согласованным веб-стандартам, и быстро выбрасывает их в окно. Когда вы воспроизводите видео с помощью браузера iPhone, вместо этого он запускает собственный видеопроигрыватель iOS в полноэкранном режиме, который уводит вас с веб-страницы. Примерно в этот момент контроль над пользовательским интерфейсом сорван с ваших когтей, и вы остаетесь проклинать властных богов Apple.
В блестящем кругу поэтической справедливости Apple столкнулась с этой самой проблемой при создании маркетинговой страницы для iPhone 5. В то время на этой странице было очень короткое встроенное видео с разблокировкой iPhone после прокрутки вниз. Это верно, их маркетинговая страница iPhone работала на всех устройствах, кроме iPhone. Учитывая обстоятельства, которые поставили их в такую ситуацию, их решение (которое включает в себя повторную реализацию кодирования и воспроизведения видео с использованием изображений JPG и фоновых HTTP-запросов ) можно назвать только нелепым.
Однако этот метод не будет работать для вашей видеокампании, поскольку длина видео делает решение неосуществимым. Вместо этого, путем многочисленных проб и ошибок, вы обнаруживаете, что можете использовать JavaScript для удаления всего элемента iFrame во время воспроизведения, чего достаточно, чтобы нарушить работу собственного видеопроигрывателя iOS и заставить его вернуться на веб-страницу. Это также означает, что вам нужно будет повторно инициализировать API проигрывателя YouTube для подготовки к воспроизведению следующего видео.
$("#video").html("<div id='video-player'></div>");
var player = new YT.Player("video-player", {
height: "505",
width: "100%",
videoId: nextVideoId,
playerVars: { "autoplay": 0 },
});
Вернувшись в контекст веб-страницы, вы теперь имеете возможность реализовать статическое исправление снимка экрана, используемое для iPad, что дает не совсем идеальный пользовательский интерфейс, но позволяет пользователю нажимать кнопку и переходить к следующему видео.
Что-то грязное
Когда вы начнете пожинать слава от этих славных исправлений, вы не можете избавиться от отвратительного чувства в глубине души, что должен быть лучший путь. Вам приходит в голову, что если бы вы могли каким-то образом контролировать содержимое внутри iFrame, у вас не было бы проблем безопасности на нескольких сайтах, которые мешали бы более элегантным и прозрачным решениям.
Вы запускаете быстрый бэкэнд-сервис, который скручивает контент из iFrame YouTube и отправляет его обратно в виде стандартного HTML-ответа. Это тип прокси, который создает видимость того, что контент видеоплеера поступает из того же домена, что и страница хоста, и позволяет вам внедрить сценарий, который может обнаруживать действия пользователя в iFrame (устраняя необходимость в фиктивных элементах div или static скриншоты).
Ответ от YouTube нуждается в доработке, многие ссылки относительны, поэтому вам необходимо программно заменить их абсолютными путями, указывающими на YouTube. После нескольких манипуляций он начинает работать, так что вы идете домой на тот день, в восторге от того, что превратили свой уродливый хак в гораздо более внушительное хитрое исправление .
На следующее утро вы приходите к своему рабочему столу, готовые потратить следующий час, наслаждаясь вашим улучшенным решением, но быстро урезаны, когда хрупкость подхода вчерашнего дня высвечивается из-за ночного изменения в ответе видеоплеера YouTube. Не просто незначительные изменения, они полностью реструктурировали HTML, загруженный в iFrame, что делает ваше исправление совершенно бесполезным. Не зная, как часто это может происходить, вы решаете, что лучше отказаться от прокси-решения и вернуться к менее впечатляющему ручному взлому.
В ожидании более простого решения
Этот побочный эксперимент был не без его понимания; доказано, что можно многое сделать для улучшения интерактивности на мобильных устройствах, если вы можете контролировать HTML-код видеопроигрывателя. В какой-то момент YouTube частично поддерживал аннотации, но, по-видимому, это было прекращено, когда из-за ограничений iOS они были не в состоянии обеспечить единообразное взаимодействие на всех мобильных устройствах .
Тем не менее, они уже обеспечивают противоречивый опыт между настольными и мобильными платформами, так зачем проводить черту там? Понятно, что ведущие инженеры Google, вероятно, слишком заняты изобретением автомобилей и созданием компьютерных умов, чтобы разобраться в этом, но, несомненно, стажер , следящий за лучшим в мире веб-сайтом по обмену видео, имеет запасной час или два для улучшения текущей ситуации.
Вы также извините маркетинговое агентство, которое разработало и изначально разработало концепцию интерактивного видео. Очевидно, что на мобильных устройствах не проводилось никаких испытаний, независимо от того, была ли важность мобильных устройств никогда не передана, или если ее просто не заметили, они быстро сняли с себя всякую ответственность. Их предлагаемое решение? Вырежьте все видео непосредственно перед появлением нажимаемых кнопок и перенаправьте внимание пользователя на ссылки, отображаемые вне элемента видео. В наше время, когда креативные агентства крутят технологии, чтобы достичь маркетингового блеска , эти полусырые решения не собираются его сокращать.
«Мобильные устройства составляют почти 40% мирового времени просмотра YouTube»
Согласно собственной статистике YouTube и предполагаемой бесконечной досягаемости, это потенциально сотни миллионов пользователей в месяц, которые не смогут полностью погрузиться в вашу интерактивную видеокампанию. Это заставляет задуматься, почему Google не решает эту проблему для 75% мобильных пользователей , добавляя поддержку на платформе, которой они управляют . В то же время, вы останетесь победителями, взломав вместе четыре разных решения для решения проблемы, которой вообще не должно было быть.