Потребител щракна върху бутон, заснема на екран грешката и я изпраща на мен без да инсталира нищо

Има момент в живота на всяко уеб приложение, когато потребител наизненада нещо счупено. Бутон, който не прави нищо при щракване. Оформление, което се свива на определен размер на екрана. Форма, която поглъща собственото си съобщение об грешка. Потребителят гледа екрана, объркан, и след това прави едно от две неща. Повечето от тях просто си отиват и никога не се връщат. Редки са тези, които отделят време да напишат съобщение от вида "нещо не е наред с твоя сайт." Това съобщение пристига без контекст, без описание на това какво се е случило, без никакво указание какъв браузър или устройство е bilo involved, и със сигурност без екранна снимка показваща действителния проблем. Разработчикът прочита това съобщение, се опитва да възпроизведе проблема, не успява, и грешката остава неправена, докато не ударя следващия потребител. Този цикъл се повтаря безкрайно по интернет, и коренната причина не е лентост на потребителя. Коренната причина е триене.

Заснемането на екран на компютър изисква познаването на правилния клавишен shortcut, който варира в зависимост от операционната система. На Windows може да бъде Print Screen, или Alt плюс Print Screen за активния прозорец, или Windows ключ плюс Shift плюс S за инструмента за нарязване. На Mac това е Command плюс Shift плюс 3, или 4, или 5, всеки произвеждащ малко по-различни резултати. На телефон жестът включва натискане на два физически бутона едновременно, което половина от времето случайно заключва екрана. След като екранната снимка е направена, трябва да бъде намерена в файловата система, приложена към имейл или поставена в формуляр за поддръжка, и изпратена. Всяка от тези стъпки е още една точка, където потребителят се отказва и решава, че грешката не си струва да се докладва. Резултатът е, че разработчиците получават грубо един доклад за всеки сто грешки, които потребителите всъщност срещат.

Решението, което възникна от тази фрустрация, е срамежливо просто. На страницата се появява малък бутон. Когато потребителят го щракне, сървърът заснема на екран точната страница, която потребителят преглежда, и я прикрепя към доклад. Не е необходимо браузър разширение. Никой клавишен shortcut за запомняне. Няма файл за намиране и качване. Един щракваж, една екранна снимка, един доклад. Потребителят добавя изречение или две описващо какво се е случило, и разработчикът получава идеално ясно изображение на счупената страница заедно с описанието. Това е целия работен процес, и той е променил начина, по който пристигат докладите за грешки.

Защо браузър разширенията никога не разрешиха този проблем

Очевидната първа реакция е, че браузър разширенията вече съществуват за тази цел. Има дузини инструменти за скринщот достъпни като Chrome разширения, Firefox add-ons, и Safari плъгини. Някои от тях са доста хубави, с функции за анотиране, автоматични качвания, и интеграция с платформи за управление на проекти. Но всички те споделят същата фундаментална грешка. Те изискват от потребителя да инсталира нещо преди грешката да се случи. Никой не инсталира браузър разширение за докладване на грешки поради всякакъв шанс, че някой уебсайт, който посетити утре, ще има счупено оформление. Разширенията решават проблема за QA екипи и вътрешни тестери, които могат да бъдат указани да инсталират конкретни инструменти. Те абсолютно не правят нищо за общественост, която среща грешка за първи път на сайт, който може никога да не посети отново.

Има също така въпросът на доверието. Поискването от потребител да инсталира браузър разширение за докладване на грешка въвежда рязка смяна на взаимодействието. Потребителят дошъл на сайта да направи нещо, откри, че е счупен, и сега му се пита да инсталира трета страна софтуер. Това искане с право ще повдигне подозрение за много потребители, и дори тези, които са готови да го направят, се сблъскват с допълнителното натоварване на навигация на разширение магазините, предоставяне на разрешения, и разбиране как работи инструментът. До момента, когато разширението е инсталирано, оригиналната грешка може да не е повече възпроизводима, или потребителят просто се е преместил на конкурент. Прозорецът за заснемане на докладване на грешка е тесен, и всичко, което разширява пропастта между "нещо е грешно" и "доклад изпратен" означава, че докладът никога не се изпраща.

Клиентските библиотеки за скринщот като html2canvas се опитаха да решат това от различен ъгъл. Тези JavaScript библиотеки се задават на DOM в елемент на canvas, ефективно създавайки скринщот без никакво участие на сървър. Те работят разумно добре за прости оформления, но падат бързо с сложно CSS, вградени iframes, снимки от кросс-origin, елементи на canvas, и потребителски шрифтове. Полученото изображение често изглежда нищо като това, което потребителят всъщност вижда, което поражда целта напълно. Докладване на грешка, съдържащо скринщот, който не съответства на реалната страница, е по-лошо от нито един скринщот, защото изпраща разработчика да преследва визуален проблем, който не съществува, докато реалния проблем остава скрит.

Скринщоти от сървъра и как те заснемат това, което потребителят вижда

Подходът зад screenshots.yeb.to отива напълно по-различен път. Вместо да се опитвам да реконструирам страницата от клиентска страна, сървърът получава URL и я изобразява, използвайки реален механизъм за браузър, работещ в контролирана среда. Скринщотът е направен от действително Chromium инстанция, която зарежда страницата, изпълнява JavaScript, прилага CSS, задава шрифтовете, и заснема резултата като идеално точно изображение. Това означава, че скринщотът изглежда точно както действителен браузър показва, защото това е това, което действителен браузър показва.

Когато потребителят щракне на бутона за докладване на грешка, текущия URL на страницата се изпраща към сървър заедно с метаданни за размера на преглед на потребителя, съотношението на пиксели на устройство, и всякакви релевантни параметри на състояние. Сървърът стартира сеанс на headless браузър, конфигуриран да съответства на тези параметри максимално близо. Той зарежда страницата, чака всички активи да завършат рендериране, и заснема скринщота. Резултатът се съхранява и се свързва към докладване на грешка, дава на разработчика точен визуален запис на страницата в момента, когато потребителят щракна на бутона. Целия процес отнема няколко секунди, което е достатъчно бързо, че потребителят може да добави описанието си, докато скринщотът се генерира в фона.

Има нюанси, които си струва да се признаят. Скринщот от сървър заснема страницата както се появява на сървър, не е непременно точните пиксели на екрана на потребителя. Ако грешката е причинена от браузър-специфични рендериращи особеностост, кеш съдържание, или локално съхранено състояние, сървър заснемането може да не възпроизведе точния визуален артефакт. Но на практика, огромното мнозинство на грешки, които потребителите докладват, са проблеми с оформлението, счупени снимки, липсващо съдържание, или функционални откази, които са съответни, независимо кой зарежда страницата. За тези случаи, скринщот от сървър е неразличим от един от клиентска страна, и огромното намаление на триене прави компромиса си струва.

Вграждане на бутона без промяна на приложението

Интеграцията е преднамерено минимална. Малко JavaScript snippet зарежда компонента на бутона, която може да бъде стилна, за да съответства на системата за дизайн на хост приложението. Бутонът плава в ъгъл на страницата, видлив, но неприметлив. Когато щракнат, той отваря лек overlay, където потребителят може да напише кратко описание и по желание хайлайтер областта на страницата, където е проблемът. Зад кулисите, snippet-ът изпраща текущия URL към screenshot API, който заснема страницата и връща URL на изображение. Докладването, съдържащо скринщота, описанието, URL, и основни браузър метаданни, се изпраща към каквото назначение разработчикът е конфигурирал: имейл адрес, Slack webhook, инструмент за управление на проекти, или потребителски endpoint.

Целата интеграция изисква никакви промени в фона на приложението. Няма SDK за инсталиране, няма middleware за конфигуриране, няма схема на база данни за модифициране. Snippet-ът работи независимо, комуникирайки само със screenshot API и конфигурирано докладване на назначение. Това означава, че може да бъде поставено в WordPress блог, React единична страница приложение, статичен HTML сайт, или наследство PHP приложение с еднаква лекота. Времето от решаване да добавя докладване на грешка към наличност на сайта се мери в минути, не спрули.

За разработчици, които искат по-дълбока интеграция, API може да бъде вещто произведен от сървър страна код. Това отваря възможности като автоматично заснемане на скринщота всякъгаеф необработено изключение се случи, или периодични скринщоти на критични страници и разликата им срещу основа за обнаружаване на визуални регресии. Но за основния случай на използване на позволяване на потребителите да докладват грешки с един щракваж, JavaScript snippet-ът обработва всичко без никакви сервърни промени какъвто.

Какво се променя, когато докладванията за грешки действително пристигат

Преобразуването в качество на докладване на грешка е драматично. Преди внедряване на бутона, типичното докладване на грешка беше смътно изречение в имейл. "Страницата изглежда странно." "Кътжката е счупена." "Нещо се случи, когато се опитах да спестя." Тези докладвания изискваха множество раунди на последващи въпроси, през които потребителят често губи търпение и спира да отговаря. След внедряване на бутона, докладванията пристигат с ясен скринщот показващ точно какво се е случило, придружено от метаданни, които идентифицират страницата, размера на преглед, и времето на възникване. Разработчик може да погледне скринщота и веднага разбе проблемът без никакви раунди на назад-напред.

Обемът на докладванията също значително увеличава. Потребители, които никога не биха съставили имейл или попълнили формуляр за поддръжка, ще щракнат на бутон и напишат три думи. "Менюто се припокрива със съдържание" не е най-детайлното докладване на грешка в света, но в комбинация със скринщот показващ навигационното меню, което припокрива главната областта на съдържание в мобилен преглед, казва на разработчика всичко необходимо за възпроизведение и коригиране на проблема. Комбинацията на по-ниско триене и по-богатия контекст означава, че грешки се докладват по-рано, поправят по-бързо, и проверяват по-надежно. Дните на откриване на критично оформление грешка три седмици след нейното въвеждане са до голяма степен отминали за всяко приложение, което разработка този вид механизъм за обратна връзка.

Има вторичен свързан, който е по-малко очевиден, но еднакво ценен. Архивът на скринщота става визуална история на приложението. Всяко докладване заснема момент във времето, показващ точно как страницата изглежда, когато потребителят се сблъска с проблем. През седмици и месеци, този архив разкрива модели. Може би определена страница се разпадира всеки път, когато нов deployment излиза. Може би мобилни потребители докладват проблеми по три пъти по-висок от плотни потребители. Може би определена браузър версия последователно произвежда оформление аномалии. Тези модели са невидими в текст-само докладвания за грешки, но стават веднага очевидни при преглед през галерия на timestamped скринщоти.