Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Accessibility

Сломался сайт или вас забанили?

03.11.2020 04:15:37 | Автор: admin

По всем канонам жанра, когда вы сталкиваетесь с ошибкой на сайте, из-за которой абсолютно ничего не работает, вы прикидываете уровни абстракции на которых вероятнее всего эта ошибка произошла. И если раньше в списке моих приоритетов была ошибка в коде сайта, то теперь в первую очередь я думаю, что попал в условный Shadow Ban. Особенно, если речь идет о заграничных сервисах. Давайте посмотрим почему так происходит, и что можно с этим поделать.


Все больше популярных сайтов в интернете прибегают к теневому бану в том или ином виде. Причем его изощренность зависит от каждого конкретного случая. Это может быть пустая страница, как будто сервер умер, сообщение 500 об ошибке сервера, сообщение об ошибке 404, неправильные редиректы при попытке отправить заполненную форму. Суть одна владелец сайта не хочет, чтобы вы, ваша страна, ваша подсеть или IP адрес, пользовались его сайтом. Но при этом внятного объяснения давать не хочет, потому что оно для кого-то может звучать оскорбительно, а то и неприемлемо с точки зрения местного законодательства.


Как правило есть несколько основных причин почему ваш IP адрес или отпечаток броузера забанен:


  • вы используете TOR или публичный прокси, VPN

  • адрес принадлежит хостинг-провайдеру в датацентре, а не интернет-провайдеру, предоставляющему услугу доступа в интернет обычным людям

  • с вашего IP адреса или подсети идут хакерские атаки, брутфорсы, иная противоправная деятельность

  • у вас IPv6

  • вы сидите с IP страны к которой у владельца сайта нет коммерческого интереса или много людей из нее показало себя хакерами, скаммерами, спамерами и т.п.

  • автоматическая система безопасности на основании скрытых критериев решила, что вы верблюд, не имеющий справки об обратном


Если вы живете в аграрной, ядерной или морской(снабжает морепродуктами ядерную) сверхдержаве, то шанс пополнить ряды преждевременно забаненных весьма велик. Причем буквально на уровне файервола. Основные причины того малая платежеспособность, обилие скаммеров и хакерских атак, что является обратной стороной экспорта IT-услуг из региона. Не стоит забывать и про полуостров, в чьей территориальной принадлежности не хотят разбираться иностранные компании, и потому банящие диапазоны IP из стран принадлежащих странам, что претендуют на данный полуостров. Особой пикантности добавляет ситуация, когда диапазоны страны забанены, но значительная часть программистов самого сервиса находится в ней самой.


И да, всегда есть вероятность, что просто локализация на сайте сделана настолько криво, что он молча и внезапно падает. Особенно это касается США, где традиция локализации слаба, а 256 байт хватит всем. Но, поскольку сайт не работает у тех, у кого он падает, они не могут найти контакты и написать гневное письмо в техподдержку. Это тоже надо учитывать. Как и то, что техподдержка будет отвечать в духе Sorry, we couldn't help you. Seems problem is on your side. Thank you for choosing us! Bgggeeeee...


Вот алгоритм поведения, чтобы понять, можете ли вы воспользоваться сервисом, обойдя Shadow Ban, или он действительно сломан.


1) Выключите TOR или VPN, если они у вас имеются.


2) Скачайте Google Chrome с сайта Google, именно официальную сборку, без плагинов. Создайте новый чистый профиль броузера и попробуйте проделать на сайте требуемые действия из под этого профиля.


3) Поменяйте язык системы на английский, или установите локаль en_US, или запустите броузер с локалью en_US.


4) Попробуйте воспользоваться бесплатным или платным VPN, или прокси, чтобы выходный адрес VPN был в той же стране, что и ваш сервис. Предпочтителен свой VPN на арендованной VPS в той же стране. Обязателен Google Chrome с чистым профилем, иначе можете потерять купленный IP в никуда, система безопасности просто добавит его в бан по отпечатку броузера.


5) Последний рубеж, если вам ОЧЕНЬ надо. Виртуальная машина или отдельный компьютер с Windows 8-10, язык системы установлен в язык региона, где находится сайт. Доступ к сайту через IE или Chrome с чистым профилем, через приватный прокси, чей IP числится за провайдером интернета, а не датацентра, а сам прокси находится в той же стране, что и сайт.


В случае умных систем защиты могут быть очень простые комбинации для бана, и достаточно создать просто новый профиль в броузере или воспользоваться Opera VPN. Или наоборот во временный бан улетят даже проверенные пользователи с многолетней историей посещения, и проще и дешевле переждать период обострения у администрации.


И конечно же читайте комментарии, там тоже могут быть полезные советы.

Подробнее..
Категории: Информационная безопасность , Браузеры , Accessibility , Локализация , Фриланс , Спам и антиспам , Shadow ban , Firewall

Перевод Безжалостное избавление от Layout Shift на netlify.com

04.12.2020 00:04:03 | Автор: admin

Приветствую. Представляю вашему вниманию перевод статьиRuthlessly Eliminating Layout Shift On Netlify.com, опубликованной 25 ноября 2020 года автором Zach Leatherman.

На сайте Netlify у нас есть небольшой баннер, который появляется вверху для привлечения трафика к новым и интересным вещам, происходящим в мире Netlify.

Этот баннер состоит из двух частей:

  1. Расширенная фича HTML, о которой знают только разработчики старой школы: гиперссылка.

  2. Кнопка закрытия (которая сохраняет предпочтение для будущих загрузок страницы)

В жизненном цикле этого компонента есть несколько ключевых этапов производительности, и вот как это работало раньше:

  1. Первоначальный рендеринг страницы. По умолчанию баннер скрыт. До загрузки JavaScript или без JavaScript баннер не отображается.

  2. После загрузки JavaScript мы проверяем localStorage, чтобы узнать, закрывал ли пользователь баннер ранее. Значение - URL-адрес ссылки, чтобы при изменении баннера он снова отображался, даже если пользователь его закрыл. Если нужно - рендерим баннер.

  3. Наконец, мы вешаем события на кнопку закрытия. Для гиперссылки это не нужно, потому что ее поведение предоставляется исключительно в HTML (вааау).

Шаги 2 и 3 объединены и выполняются вместе в одном компоненте. В некоторых предедущих версиях сайта время между шагами 1 и 2 могло достигать ~600 мс.

При редизайне нашего сайта (заметьте, быстрее) мы вставили JavaScript шагов 2 и 3 в конец <body>, и задержка все еще была:

Решение

Что нам нужно сделать? Сделать поведение наоборот. Обычно баннер по умолчанию скрыт. Мы должны сделать баннер видимым по умолчанию и с помощью JavaScript скрывать его, если нужно.

Это изменяет наш выше упомянутый Шаг 1, первоначальный рендеринг страницы. Теперь без JavaScript или до загрузки JavaScript баннер будет виден.

Мы также разделили код JavaScript-компонента на две отдельные части: в одной проверяем, есть ли у пользователя флаг для скрытия, и отдельный веб-компонент для привязки событий.

Update: Я собрал этот код и выложил на GitHub для повторного использования.

HTMLи CSS

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

.banner--hide announcement-banner,announcement-banner[hidden] {  display: none;}[data-banner-close] {  opacity: 0;  pointer-events: none;}.banner--show-close [data-banner-close] {  opacity: 1;  pointer-events: auto;}

<announcement-banner>  <a href="http://personeltest.ru/aways/www.netlify.com/sustainability/">Read about our Sustainability</a>  <button type="button" data-banner-close>Close</button></announcement-banner>

JavaScript

banner-helper.js, вставленный в<head> страницы:

// Адрес CTA ссылки, мы инжектим его из JSON файлаlet ctaUrl = "https://www.netlify.com/sustainability/";let savedCtaUrl = localStorage.getItem("banner--cta-url");if(savedCtaUrl === ctaUrl) {  document.documentElement.classList.add("banner--hide");}

banner.js, отоложен на потом (на сколько позже - зависит от вас):

class Banner extends HTMLElement {  connectedCallback() {    // Независимо от того, когда это выполняется, кнопка закрытия будет скрыта,     // пока этот класс не будет добавлен - он предотвращает призрачные клики     // по кнопке до добавления обработчика событий.    this.classList.add("banner--show-close");    let button = this.getButton();    if(button) {      button.addEventListener("click", () => {        this.savePreference();        this.close();      });    }  }  getButton() {    return this.querySelector("[data-banner-close]");  }  savePreference() {    let cta = this.querySelector("a[href]");    if(cta) {      let ctaUrl = cta.getAttribute("href");      localStorage.setItem("banner--cta-url", ctaUrl);    }  }  close() {    this.setAttribute("hidden", true);  }}window.customElements.define("announcement-banner", Banner);

Внимательные читатели заметят, что это веб-компонент, но давайте оставим это между нами.

Результат

Обратите внимание, что первый рендер содержит баннер! Это одинаковый рендеринг вне зависимости от того, задействован ли JavaScript или нет.

На этой диаграмме видно, что мы снизили показатели Layout Shift до нуля.

И поскольку мы вставили скрипт для повторных просмотров в <head>, когда пользователь скрывает баннер и переходит на новую страницу, баннер также будет скрыт перед первым рендерингом.

Довольно неплохо для таких маленьких изменений!

Следующей целью будет улучшение отображения веб-шрифтов.

Подробнее..
Категории: Html , Javascript , Разработка веб-сайтов , Accessibility , Доступность , Lighthouse , Netlify

Доступность это просто, Или 5 смертных грехов доступности

10.12.2020 12:12:32 | Автор: admin

Привет, Хабр! Меня зовут Алексей Устинов, я Frontend-разработчик в Delivery Club. В свободное время я интересуюсь вопросами доступности интерфейсов. Это первая из двух статей, в которых я хочу рассказать о проблемах с доступностью в вебе. Я расскажу про 5 простых правил, соблюдая которые можно значительно улучшить доступность сайта. Также мы рассмотрим самые распространённые проблемы, я объясню, почему они являются проблемами, и дам простые советы по их решению. Во второй статье я, наоборот, приведу примеры элементов страницы, сделать доступными которые совсем нетривиальная задача.

Я уверен, что ты, %username%, слышал про правило 80/20: 80% результата можно достичь за 20% трудозатрат, а на достижение остальных 20% необходимо потратить 80% трудозатрат. Именно это правило объединяет эту и следующую статью.

Как работает скринридер

Основная цель программ экранного доступа, таких как NVDA, VoiceOver и других, это объяснить пользователю, что за элемент сейчас находится в фокусе, и, самое главное, рассказать о его предназначении. Если элемент содержит в себе какую-то текстовую информацию, то скринридер заботливо прочитает её для пользователя.

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

Грех 1. Бардак в заголовках

В HTML существует шесть уровней заголовков, которые обозначаются тегами от H1 до H6 и используются именно в этом порядке, создавая иерархическую структуру.

Пример иерархии заголовковПример иерархии заголовков

Очень часто (сейчас, к счастью, реже) вместо использования элементов H1H6 разработчики создают заголовки с помощью стилей. И если для зрячего пользователя с клавиатурой и мышкой, на первый взгляд, это не является проблемой, то для незрячих пользователей это превращает страницу в сплошную портянку текста.

Другой частой ошибкой является неправильная последовательность в заголовках. Согласно стандарту, сначала используется заголовок H1, он должен быть один на странице. Следующий заголовок всегда будет H2. Если нужен вложенный заголовок, то используется H3, а если нужен равнозначный заголовок, то снова используется H2.

Я часто встречаю страницы, на которых есть несколько заголовков H1, или на которых вслед за H2 идет, например, H4.

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

Варианты решения

  • Объявлять заголовки с помощью тегов H1H6.

  • Использовать заголовки в иерархической последовательности от H1 до H6.

Грех 2. Кнопки с неопределенным назначением

Пример кнопок недоступных для скринридераПример кнопок недоступных для скринридера

Посмотрите на картинку: вы понимаете, что делает каждая из кнопок? Если да, то как вы это поняли? О значении кнопок вам рассказывают иконки, но что делать, если вы не видите иконок? Тогда вы, в лучшем случае, услышите что-то в роде button, а в худшем даже не сможете попасть фокусом на этот элемент.

Худший случай происходит, когда кнопка сделана с помощью div и стилизована под кнопку с помощью CSS. Рядовой пользователь, вооруженный мышкой, кликнет на этот div, JavaScript обработает событие, произойдёт какая-то магия, и пользователь увидит результат. Скринридер же просто не поймёт, что это кнопка.

Если же кнопка сделана через элемент button, то скринридер догадается, что это кнопка, но вот её предназначение он будет брать из атрибута aria-label или текста, находящегося внутри тега button.

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

Варианты решения

  • Добавлять назначение кнопки.

Грех 3. Невидимые картинки

Изображение часто передаёт ценную информацию. В большинстве случае ключевую мысль изображения можно описать в одном-двух предложениях. Именно для этой цели существует атрибут alt (альтернативный текст), в который можно вписать, что изображено на картинке, или с какой целью автор вставил её в текст.

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

Заполненное описание атрибута alt позволит незрячим и слабовидящим пользователям понять, для чего это изображение появилось в тексте, удобным для них способом. Несколько лет назад Facebook начал распознавать, что изображено на картинке, с помощью машинного зрения и добавлять описание в атрибут alt.

Варианты решения

  • Всегда добавлять описание к картинкам в атрибут alt.

Грех 4. Отсутствие описания форм

Формы есть на подавляющем большинстве сайтов. Это может быть что-то простое, вроде поля поиска, или что-то сложное, например, форма для заказа кастомной пиццы. Однако, когда эти формы не подписаны правильно, они становятся бесполезны для людей, пользующихся программами экранного доступа.

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

Для решения проблемы описания поля ввода существует тег label, который позволяет добавить описание к тегу input. С ними тоже иногда возникают сложности, но наличие лейбла сильно увеличивает шансы на успех.

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

пример капчипример капчи

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

Варианты решения

  • К каждому инпуту добавлять тег label с достаточным описанием.

  • Не использовать капчу, которую можно разгадать только при помощи зрения.

Грех 5: фоновая музыка или автовоспроизведение

Лет 10 назад я постоянно встречал сайты, при переходе на которые начинало громко играть рекламное видео, запущенное, скорее всего, в модальном окне, перекрывающем основное содержимое.

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

сайт с огромным количеством рекламных попаповсайт с огромным количеством рекламных попапов

Варианты решения

  • Не использовать фоновую музыку, которую нельзя выключить.

  • Не использовать видеоплееры, которые начинают играть при переходе на страницу.

  • Не использовать плееры, кнопки которых недоступны для скринридера.

Вывод

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

Всем добра!

Подробнее..
Категории: Html , Интерфейсы , Usability , Блог компании mail.ru group , Accessibility , Web-разработка , Блог компании delivery club tech , Доступность сайта

Доступность это не так просто

22.12.2020 14:23:50 | Автор: admin


Привет, Хабр! В предыдущей статье я рассказывал о простых случаях проблем с доступностью, исправив которые можно сделать свой сайт или web-приложение гораздо доступнее. Я упоминал о правиле 80/20 и писал о проблемах, которые при наименьших затратах дают наибольший результат. Сегодня я бы хотел поговорить о другой группе проблем, которые входят в 20% и для решения которых нет готовых рецептов вроде всегда заполняйте атрибут alt или используйте верные заголовки.

Выбирая формат повествования, я не придумал ничего лучше, чем просто описать ход своих мыслей на достаточно часто встречающемся примере.

Формализуем проблему


Как я уже говорил, для некоторых проблем в сфере доступности невозможно предложить какое-то простое решение. Эти проблемы очень вариативны, а иногда и вовсе уникальны для конкретного приложения. Помимо этого, ситуация осложняется различиями в работе разных скринридеров в разных браузерах и на разных операционных системах. Дополняет всё это то, что решение лежит на стыке двух дисциплин: доступности с её стандартами и Interaction Design (Проектирование взаимодействия) с её достаточно гибкими правилами.

Если вы, как и я в такие моменты, чувствуете уныние, то предлагаю не решать все проблемы сразу, а двигаться постепенно.

Обычно я начинаю с описания алгоритма взаимодействия с моим элементом для пользователей без мышки. Пользователи клавиатуры это большая группа пользователей, далеко не всегда с какими-то ограничениями. Иногда это просто люди, которые ценят скорость работы.

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

К таким элементам можно отнести:

  • табы;
  • модальные окна;
  • аккордеон;
  • меню (в том числе с большой вложенностью).

Каждый компонент их этого списка можно условно разделить на две составляющие:

  • триггер элемент, запускающий действие;
  • целевой контент элемент, который содержит в себе кусочек видоизмененного контента.

Реализация триггера


Первое, с чем я предлагаю разобраться, это какой базовый элемент будет лежать в основе триггера. Использование элементов, которые сразу являются фокусируемыми и интерактивными, я считаю хорошей идеей. Поэтому сразу отбрасываю всевозможные реализации с помощью div, span и т. д.

В итоге я прихожу к первому вопросу: должен ли быть триггер ссылкой или кнопкой?

Ответ на этот вопрос звучит примерно так: в зависимости от ситуации, но в целом, вы не ошибётесь, если будете всегда использовать кнопку.

Кнопка это элемент, предназначенный для запуска каких-либо интерактивных элементов внутри страницы. Поэтому пользователь, нажимая на кнопку, будет готов, что на странице что-то изменится. Кажется, это то, что нам нужно. Тем не менее, я считаю, что ссылки имеют некоторые преимущества в некоторых случаях.

Поэтому я задаю себе второй вопрос: должен ли изменившийся контент получить фокус?
И опять ответом на этот вопрос будет фраза в зависимости от ситуации. Но можно помочь себе, просто посмотрев на DOM-дерево и оценив, насколько далеко триггер находится от целевого контента.

Если целевой контент находится сразу после триггера, то стоит использовать кнопку и обойтись без автоматического фокуса на целевой элемент. Поскольку пользователь следующим табом попадает на появившийся контент.

<button>Trigger Text</button> <div id="target">   <p>Target content.</p></div>

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

<a href="#target">Trigger Text</a>  <div id="target">  <p>Target content.</p></div>


Реальный пример


Предположим, в макете, предоставленном дизайнером, имеется элемент Войти, расположенный в шапке сайта. И, согласно дизайну, по нажатию должно открыться модальное окно с формой входа. Сам код модального окна, скорее всего, находится в конце DOM-дерева. В этом случае использование ссылки не кажется мне плохой идеей.

При работе со ссылками, в отличие от кнопок, пользователь ожидает, что после клика он будет куда-то перенаправлен. И, в целом, модальные окна можно рассматривать как отдельные страницы, поэтому результат не будет неожиданным для пользователя.

Вернёмся к вопросам, поставленным выше: Должен ли быть триггер кнопкой или ссылкой? и Должен ли фокус автоматически переключиться на целевой контент? Ответ на эти вопросы можно найти, просто ответив на вопрос: Как далеко друг от друга находятся триггер и целевой контент.

Далее я добавляю на страницу немного JavaScript, чтобы убедиться, что пользователи клавиатуры и мыши могут взаимодействовать с созданным компонентом. Конечно, не обходится без небольшой магии с tabindex и методом focus(), которые заслуживают отдельной статьи.

Теперь самое время подумать о пользователях скринридеров. Первое, что стоит сделать это добавить атрибуты aria-expanded в триггер и aria-hidden в целевой контент.

// Таргет не активирован
Триггер - aria-expanded="false",
Целевой контент - aria-hidden="true".

// Пользователь нажал на таргет элемент
Триггер - aria-expanded="true",
Целевой контент - aria-hidden="false".

Ещё существует атрибут aria-controls, который позволяет явно указать взаимосвязь между целевым компонентом и триггером.

<button aria-controls="target">Trigger Text</button><div id="target">  <p>Target content.</p></div>

Правда, он не всегда работает так, как это можно ожидать.

В качестве заключения


Для более наглядного примера я реализовал два codepan: один с триггером в виде кнопки, а второй со ссылкой (кнопка, ссылка). В чём разница, спросите вы? Всё просто: в примере со ссылкой целевой контент сразу получил фокус без каких-то дополнительных телодвижений со стороны разработчика.

Это наводит меня на мысль, что, возможно, если вы работаете над SPA, то стоит задуматься, стоит ли делать SPA, а потом пытаться сделать его доступным, продумывая, куда перевести фокус в появившемся контенте. Где должен оказаться фокус после исчезновения появившегося контента, что будет с фокусом, когда целевой контент скроется? Ведь очень часто, пытаясь делать SPA доступным, вы во много повторяете функциональность, уже заложенную в браузеры.

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

И помните, что тот факт, что вы дочитали этот материал до конца, означает, что вы знаете, как решать проблемы с доступностью лучше, чем большинство разработчиков.

Спасибо за внимание, всем добра!
Подробнее..
Категории: Html , Css , Блог компании mail.ru group , Accessibility , Web-разработка , Блог компании delivery club tech , Доступность , Доступность сайта

Свободно стилизируемы outline DOM элементов

13.01.2021 16:08:51 | Автор: admin

В последнее время всё чаще и чаще возникает вопрос о доступности, если раньше скрытиеoutlineдля элементов страницы было общим правилом, то теперь хороший сайт должен иметь outline у элементов, как минимум:focus-visible.Основная проблемаoutline- это их стилизирование.

Я пришел к своему решению, которое изложено в этой статье.

Большой gif

Работая над своим pet проектом мне нужно было сделать один и тот же стиль обводки (при наведении и фокусе) для элементов визуализаций и всех фокусируемых элементов DOM.

Моё решение

Вставляемdivповерх всего остального контента вdocument.body, и отключаем ему обработку событий черезpointer-events: none, растягиваем в размер документа,z-indexдолжен быть больше всех остальных на странице.

Добавляем еще 4-edivс абсолютными позициями в ранее добавленный родительский:

их стили (scss):

Добавляем подписку на события дляdocument:pointerenter,pointerleave,focus,blur:

Не забудьте отписаться если вы делаете какое то React приложение, и вюшка может быть отмонтирована.

В функциях слушателей фильтруем все события поtabIndex > -1уevent.target. При этом также проверяем что у ссылок естьhref, и кроме того что у элементов нет атрибутаdisabled. Когда происходитblurможет оказаться, что элемент оказался в контейнере, который тоже может иметь фокус (тут конечно можно задаться вопросом семантики, но такое бывает почему вbuttonнаходитсяa):

В методеshowполучаем размерыtargetс помощьюgetBoundingClientRect. А затем перемещаем, наши 4-ediv, каждый в свой угол:

Собственно, всё!

Описанный выше код вы можете найти здесь.

Заключение

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

Кроме того,overflow: hiddenне влияет на нашoutline, но иногда нам нужно следить за формой элемента и размерами (к примеру ResizeObserver) , поэтому вы можете улучшить этот подход, все в ваших руках.

Спасибо за прочтение!

Если вам нужна дополнительная информация, дайте мне знать об этом DMartzub.online.

P.S.: английская версия моей статьи здесь

Подробнее..
Категории: Html , Javascript , Css , Usability , Веб-дизайн , Accessibility , Ui , Ux , Ux/ui

Перевод HTMHell адовая разметка

30.04.2021 00:08:01 | Автор: admin

Приветствую. Представляю вашему вниманию перевод заметок с сайтаHTMHell - коллекции плохих примеров HTML-кода, взятых из реальных проектов.

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

Так как я объединил в единую статью заметки, которые изначально являются независимыми и самодостаточными, во время перевода позволил себе иногда немного отходить от стилистики изначальных формулировок, пытаясь сделать текст менее "сухим" и более последовательным.

1. Кнопка, замаскированная под ссылку

Плохой код

<button role="link" title="Name of website" tabindex="0">  <img alt="Name of website" src="logo.jpg" title="Name of website"></button>

Ошибки и что следует исправить

  • Пример неправильного использования элемента <button>. Для ссылок на другую страницу или сайт следует использовать элемент <a> . Не пренебрегайте семантикой HTML-тегов, если только в этом нет явной потребности

  • Благодаря элементам <a>, на страницы можно ссылаться и без использования JavaScript

  • Атрибут title описывает содержимое элемента в виде всплывающей подсказки и для элементов <button> указывать его излишне

  • В атрибуте tabindex также нет необходимости, ведь при переключении между элементами с помощью клавиатуры кнопки получают фокус по умолчанию

Хороший код

<a href="http://personeltest.ru/aways/">  <img alt="Name of website" src="logo.jpg"></a>

2. Элемент с атрибутом role="button"

Плохой код

<div tabindex="-1">  <div role="button">    <svg width="28" height="24">  </svg>  </div></div>

Ошибки и что следует исправить

  • Нет необходимости пытаться задать семантику <div>-элемента с помощью атрибута role, ведь вместо этого достаточно просто использовать элемент <button>

  • При использовании <button> не понадобится и атрибут tabindex . HTML-кнопки по умолчанию могут получать фокус

  • На <div>-элементах событие клика вызывается только непосредственно кликом мыши. На элементах же <button> это происходит ещё и при нажатии на кнопки Enter или Space на клавиатуре

  • SVG-иконки, расположенной внутри нашей псевдокнопки не хватает текстовой альтернативы на случай, если SVG не отобразится

Хороший код

Чтобы предназначение кнопки было понятно не только визуально, но и оставалось доступным для пользователей скринридеров, внутрь добавляется описательный текст.

<button>  <span class="sr-only">Send</span>  <svg width="28" height="24" aria-hidden="true">  </svg></button>

Тексту присваивается класс .sr-only с набором свойств, делающим его скрытым только визуально

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

3. Картинки - кнопки

Плохой код

<img src="http://personeltest.ru/aways/habr.com/images/edit.gif" onclick="openEditDialog(123)"><img src="http://personeltest.ru/aways/habr.com/images/delete.gif" onclick="openDeleteDialog(123)">

Ошибки и что следует исправить

  • Элемент <img> предназначен отнюдь не для выполнения JavaScript, а для показа изображений

  • Как и на упомянутом ранее <div>, на элементе img> событие клика вызывается только непосредственно кликом мыши. Если бы вместо него использовался элемент <button> , это происходило бы ещё и при нажатии кнопок Enter или Space на клавиатуре

  • Для самого изображения не задана текстовая альтернатива (атрибут alt ). Из-за этого скринридеры могут озвучивать название самого файла изображения, что далеко не всегда информативно

Хороший код

Решение 1: Использовать кнопки, а к помещённым внутрь кнопок изображениям добавить атрибут alt

<button onclick="openEditDialog(123)">  <img src="http://personeltest.ru/aways/habr.com/images/edit.gif" alt="Edit product XY"></button><button onclick="openDeleteDialog(123)">  <img src="http://personeltest.ru/aways/habr.com/images/delete.gif" alt="Delete product XY"></button>

Решение 2: Использовать кнопки и вместо добавления атрибута alt к изображениям, добавить описание в текстовые элементы

<button onclick="openEditDialog(123)">  <span class="sr-only">Edit product XY</span>  <img src="http://personeltest.ru/aways/habr.com/images/edit.gif" alt=""></button><button onclick="openDeleteDialog(123)">  <span class="sr-only">Delete product XY</span>  <img src="http://personeltest.ru/aways/habr.com/images/delete.gif" alt=""></button>

Изображения с пустым атрибутом alt недоступны для пользователей скринридеров, что нам и нужно, ведь название кнопок мы добавили в виде отдельного текста, визуально скрытого с помощью набора свойств упомянутого выше класса .sr-only

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

4. Ссылка с кнопкой внутри

Плохой код

<a href="http://personeltest.ru/aways/example.com">  <button>Example</button></a>

Ошибки и что следует исправить

  • Вкладывая кнопку внутрь ссылки, вы подаёте сразу два сигнала: это кнопка, но также это и ссылка

  • Если вы не уверены, когда нужно использовать элемент <a>, а когда <button>, рекомендую посмотреть видео "The Links vs. Buttons Showdown" от Marcy Sutton

Хороший код

.button {  /* используйте CSS, чтобы задать ссылке вид кнопки */}

<a href="http://personeltest.ru/aways/example.com" class="button">Example</a>

5. Кнопкоподобная ссылка

Плохой код

Контекст: это ссылка, стилизованная под кнопку. Ведёт она на форму, расположенную на этой же странице

<a href="#form" role="button" aria-haspopup="true"> &nbsp;&nbsp;Register&nbsp;&nbsp; </a>

Ошибки и что следует исправить

  • Добавляя к ссылке role="button" , вы сообщаете, что это кнопка, хотя она ведёт себя как ссылка. Не меняйте семантику элементов, только если в этом нет серьезной необходимости

  • Атрибут aria-haspopup="true" призван сообщать вспомогательным устройствам, что данный элемент вызывает попап, но в нашем случае этого не происходит

  • Внутренний отступ padding следует добавлять к элементам через CSS, а не с помощью &nbsp;

Хороший код

.button {  /* с помощью CSS задайте ссылке вид кнопки  */}

<a class="button" href="#form"> Register </a>

6. Ссылка с void-оператором в значении атрибута "href"

Плохой код

<a href="javascript:void(1)" onClick='window.location="index.html"'>Link</a>

Ошибки и что следует исправить

  • Если JavaScript-код не загрузился или не может быть выполнен, использующая его ссылка просто перестанет работать

  • Да и для ссылки на другую страницу нет необходимости использовать JavaScript. Адрес можно указать в атрибуте href, который 100% поддерживается всеми браузерами и будет корректно работать

  • Такая ссылка будет работать только при клике левой кнопкой мыши. Открыть её в новой вкладке/окне щелчком скролла или через конктекстное меню не удастся

Хороший код

<a href="index.html">Link</a>

7. Дубликаты "id" и табличная раскладка

Плохой код

 <table>   <tr id="body">     <td id="body">       <table id="body">         <tr id="body_row">           <td id="body_left"></td>           <td id="body_middle"></td>           <td id="body_right"></td>         </tr>       </table>     </td>   </tr> </table>

Ошибки и что следует исправить

  • Значениея атрибутов id должны быть уникальными, независимо от того, к какому тегу они добавляются

  • Данный код использует раскладку, основанную на таблицах (это при том, что дизайн сайта обновлялся в 2016 году). Избегайте разметки страниц с помощью таблиц, потому что эти элементы имеют вполне конкретное семантическое значение и не предназначены для этих целей

  • Текущую разметку следует заменить на семантические HTML5-теги. Это существенно сократит количество тегов и сделает код более понятным

  • При стилизации следует использовать новые технологии FlexboxиCSS Grid, но никак не элементы таблиц

  • Для значений атрибута IDдолжны быть использованы более семантические термины

Хороший код

<main id="body">   <aside id="secondary_content"> </aside>   <article id="primary_content"> </article>   <aside id="tertiary_content"> </aside> </main>

8. Якорная ссылка в роли кнопки

Плохой код

<a href="#" onclick="modal.open()">Login</a>

Ошибки и что следует исправить

  • Элементы <a> следует использовать для ссылки на другие ресурсы: такие как страница или PDF-документ

  • В нашем же случае задача элемента вызвать JavaScript-действие на текущей странице. Для таких целей лучше подходит элемент <button> с атрибутом type="button" , потому что не имеет поведения по умолчанию и изначально предназначен для вызова действий в ответ на нажатие пользователем

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

Хороший код

Решение 1: Использовать элемент <button>

<button type="button" onclick="modal.open()">Login</button>

Поскольку целью данного элемента является не навигация, а вызов действия на текущей странице, элемент <button> является семантически более подходящим.

Решение 2: Ссылка на отдельную страницу

<a href="http://personeltest.ru/aways/habr.com/login" onclick="modal.open()">Login</a>

Ещё одно решение - использовать элемент <a> , у которого в атрибуте hrefуказать путь на отдельную полноценную страницу, где пользователь сможет проделать те же действия, что и в модальном окне. А переход по указанному пути, который является поведением ссылки по умолчанию, заблокировать через JavaScript

Таким образом, получаем некий фолбэк для браузеров и устройств, которые не поддерживают JavaScript или если он по какой-то причине не сработал

Это пример прогрессивного улучшения при разработке

9. Запрос согласия на хранение Cookie

Плохой код

<body>  <header></header>  <main></main>  <footer></footer>  <div class="cookie_consent modal">    <p>We use cookies</p>    <div class="cookie_consent__close">      <i class="fa fa-times"></i>    </div>    <div class="cookie_consent__ok">OK</div>  </div></body>

Ошибки и что следует исправить

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

  • Кнопки данного окна, реализованные с помощью <div> элементов , а значит не получат фокус при переключении между элементами с помощью клавиатуры

  • Содержимое внутри <div>-кнопок семантически является просто текстом. Всё это не позволит вспомогательным технологиям вроде экранных читалок понять, что определённые элементы на самом деле являются кнопками

  • Как уже было указано ранее, в дополнение ко всему, на элементах <div> событие клика вызывается только непосредственно кликом мыши. Если бы всесто них использовались элементы <button>, это происходило ещё и при нажатии на кнопки Enter или Space на клавиатуре

  • Для иконки нет текстовой альтернативы, а значит её назначение можно определить только визуально

  • Font Awesome советует скрывать иконки от скринридеров, добавляя элементам <i> атрибут aria-hidden="true"

  • Font Awesome добавляет Unicode-содержимое через псевдоэлемент ::before. Некоторые вспомогательные технологии могут озвучивать его. Но в данном примере иконка будет названа "разы" (times), поскольку fa-times - это не "крестик", а "знак умножения". Обратите внимание: Talkback и VoiceOver в данном случае не озвучат вообще ничего

  • В завершение можно также добавить, что крайне полезным было бы иметь возможность закрыть модальное окно нажатием Escape

Хороший код

<body>  <div class="cookie_consent modal">    <h2 class="sr-only">Cookie notice</h2>    <p>We use cookies</p>    <button class="cookie_consent__ok">OK</button>    <button class="cookie_consent__close">      <span class="sr-only">Close notification</span>      <i class="fa fa-times" aria-hidden="true"></i>    </button>  </div>  <header></header>  <main></main>  <footer></footer></body>

Для описательного текста кнопок мы снова используем набор свойств, называемых классом .sr-only , который скрывает его визуально, но оставляет доступным для скринридеров

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

Дополнительные материалы

10. Элемент как замена для

Плохой код

<section id="page-top">  <section data-section-id="page-top" style="display: none;"></section></section><main>  <section id="main-content">    <header id="main-header">      <h1>...</h1>      <section class="container-fluid">        <section class="row">          <article class="content col-sm-12">            <section class="content-inner">              <div class="content__body">                <article class="slider">                  <section class="slide">  </section>                </article>              </div>            </section>          </article>        </section>      </section>    </header>  </section></main>

Ошибки и что следует исправить

  • Элементы секционного содержимого (<article>, <aside>, <nav>, <section>) это разделы, которые потенциально можно как-то озаглавить

  • Секционные элементы вкладывать друг в друга можно, только это имеет смысл в ситуациях, когда содержимое внутренных элементов связано с содержимым родителя

  • В данном конкретном случае секционные элементы используются не для того, чтобы разбить содержимое на разделы, а лишь с целью стилизации. Значит большинство из них должны быть элементами <div>, не передающими семантическое значение

  • Когда пользователь переходит к элементу <section>, скринридеры могут озвучивать роль выбранного элемента region. Устройства также могут предоставлять возможность быстрой навигации по этим разделам. Использование большого количества элементов <section> (в том числе, вложенных) может сделать интерфейс излишне сложным для пользователей экранных читалок

  • Важный момент, который следует понимать элементы <section> не являются заменой <div>

  • Ещё одна ошибка в данном примере - неправильное использование элемента <header>. Обычно он содержит вводное содержимое для ближайшего родительского элемента <main> или другого секционного элемента. Если <header> не является вложенным, относится ко всей странице

  • Компонент карусели (слайдера) следует озаглавливать и связывать заголовок с главным элементом с помощью атрибута aria-labelledby чтобы позволить пользователям скринридеров легко его найти

Хороший код

<div id="page-top">  <div data-section-id="page-top" style="display: none;"></div></div><main>  <section id="main-content">    <header id="main-header">      <h1>...</h1>    </header>    <div class="container-fluid">      <div class="row">        <div class="content col-sm-12">          <div class="content-inner">            <section aria-labelledby="sliderheading" class="content__body">              <h2 id="sliderheading" hidden>New Products</h2>              <ul class="slider">                <li class="slide">  </li>              </ul>            </section>          </div>        </div>      </div>    </div>  </section></main>

Дополнительные материалы

11. Триграмма неба

Плохой код

<span class="nav-toggle">  Menu </span>

Ошибки и что следует исправить

  • Проблема данной реализации в том, что текст внутри тегов скринридеры могут озвучить как "триграмма неба меню". Причина кроется в символе "", который таким образом называется в unicode

  • Задача иконок - декоративное оформление, поэтому они должны быть скрыты от скринридеров. Рассмотрите добавление декоративных изображений с использованием CSS-свойства background

  • Так же, как на упомянутых ранее <div>, и <img>, на элементе <span> событие клика вызывается только непосредственно кликом мыши. Если вместо него использовать <button> , клик можно будет вызвать ещё и при нажатии на кнопок Enter и Space на клавиатуре.

  • Элемента <span> касаются и проблемы, связанные с невозможностью получения фокуса при переключении между элементами с помощью клавиатуры. А в нашем случае это особенно важно, ведь главная навигация открывается и скрывается именно с помощью данного элемента

  • Для улучшения доступности при открытии навигации к элементу следует добавлять атрибут aria-expanded для обозначения текущего состояния панели. Значением true если панель открыта, false если закрыта

Хороший код

<button class="nav-toggle" aria-expanded="false">  <span aria-hidden="true"></span> Menu</button>

12. Доступный опрос "Да/Нет"

Плохой код

<form role="form">  <h2>Poll title</h2>  <div id="pollQuestion">Is this accessible?</div>  <div name="pollGroup" role="radiogroup">    <div role="radiogroup" aria-label="Poll title">      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>Yes</span>      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>No</span>      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>Maybe</span>      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>Can you repeat the question?</span>    </div>    <button type="submit">Vote</button>  </div></form>

Ошибки и что следует исправить

  • Элемент <form> сам по себе семантически подразумевает форму, поэтому нет необходимости повторно указывать это с помощью атрибута role="form"

  • Форма это важный для доступности страницы ориентир. Поэтому внутрь формы полезно поместить заголовок, а в элементе <form> с помощью атрибута aria-labeledby, сослаться на него. Это существенно облегчает навигацию в документе с помощью вспомогательных технологий

  • Задавать атрибут role="radiogroup" необязательно, и уж точно не дважды. Если нужно сгруппировать элементы, просто используйте <fieldset>

  • Не используйте aria-labelledby для создания связи между радиокнопкой и вопросом. Данный атрибут предназначен для установки доступного имени. Вместо этого для текста вопроса используйте элемент <legend>

  • Чтобы радиокнопке назначить доступное имя, текст из <span> поместите в элемент <label> и свяжите с радиокнопкой с помощью атрибута for

  • Кнопку также следует поместить внутрь <fieldset> для создания одной логической группы элементов

Хороший код

<form aria-labelledby="poll-title">  <h2 id="poll-title">Poll title</h2>  <fieldset>    <legend>Is this accessible?</legend>    <input type="radio" id="radio1" name="poll" value="yes">    <label for="radio1">Yes</label>    <input type="radio" id="radio2" name="poll" value="no">    <label for="radio2">No</label>    <input type="radio" id="radio3" name="poll" value="maybe">    <label for="radio3">Maybe</label>    <input type="radio" id="radio4" name="poll" value="repeat">    <label for="radio4">Can you repeat the question?</label>    <button type="submit">Vote</button>  </fieldset></form>

13. Ссылка или

Плохой код

<input type="checkbox" id="accept" required><label for="accept">  <a href="http://personeltest.ru/aways/habr.com/legal"> I accept the confidentiality policy and data </a></label>

Ошибки и что следует исправить

  • Вкладывать элементы с запускаемым поведением (таким как клик) считается плохим решением

  • Возможность выбора чекбокса путём нажатия на его название улучшает удобство и доступность (путём увеличения области клика)

  • Но в данном случае пользователи не ожидают, что при нажатии на название чекбокса откроется новая страница

  • Размещайте ссылки за пределами элемента <label>

Хороший код

<input type="checkbox" id="accept" required><label for="accept"> I accept the confidentiality policy and data </label>(read <a href="http://personeltest.ru/aways/habr.com/legal">Terms and conditions</a>)

Источники

14. Неподходящий "type"

Плохой код

<a type="button" class="button" href="http://personeltest.ru/aways/habr.com/signup" tabindex="-1">Sign up</a>

Ошибки и что следует исправить

  • В данном примере с элементом <a> используется атрибут type , хотя он никак не влияет на семантику и можно сказать, что совсем неуместен

  • Если его и добавлять, то лишь со значением, являющимся допустимым MIME-типом. Браузеры могут учитывать его, но исключительно как рекомендацию

  • Если это ссылка, которая в атрибуте href содержит путь на какой-то ресурс (страницу или документ), следует использовать элемент <a>, а не <button>, независимо от того, как данный элемент выглядит в дизайне: как ссылка или как кнопка

  • Отрицательное значение tabindex значит, что элемент не получит фокус при переключении между элементами с помощью клавиатуры. Правда, такой элемент всё же может получить фокус с помощью JavaScript

  • Не меняйте семантику элементов, присущую им по умолчанию, если только в этом нет явной необходимости

  • Если вам нужна кнопка, просто используйте элемент <button>

Хороший код

<a href="http://personeltest.ru/aways/habr.com/signup" class="button">Sign up</a>

Источники

15. Буква за буквой

Контекст: буквы обёрнуты в <div> с целью анимирования каждой буквы через JavaScript

Плохой код

<h3>  <div style="display: block; text-align: start; position: relative;" class="title">    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">H</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">e</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">a</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">d</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">i</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">n</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">g</div>  </div></h3>

Ошибки и что следует исправить

Если каждая буква обёрнута в отдельный элемент, вспомогательные технологии могут озвучивать текст, произнося каждую букву по отдельности

Код примера, продемонстрированного на видео

  • Старайтесь избегать разрастания DOM. Слишком большое количество DOM-узлов или вложенных элементов может плохо отразиться на производительности страницы

  • Большое DOM-дерево ведёт к большому дереву доступности, которое также может плохо сказываться и на производительности вспомогательных технологий

  • Рекомендуется отделять представление от содержимого. Стили, которые не изменяются динамично, поместите в CSS-файл

Хороший код

Решение 1

<h3> Heading </h3>

Решение 2

Если в этом действительно есть необходимость, добавьте версию текста, доступную для скринридеров, а текст, предназначеный для визуального отображения, скройте с помощью aria-hidden="true"

<h3 class="title">  <span class="sr-only">Heading</span>  <div aria-hidden="true">    <div style="transform-origin: 50% 50% -30.8917px;" class="char">H</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">e</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">a</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">d</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">i</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">n</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">g</div>  </div></h3>

К сожалению, не существует встроенного способа скрывать содержимое только визуально. Для этого следует использовать CSS-правило, называемое классом .sr-only которое гарантирует, что контент будет скрыт визуально, но останется доступным для пользователей скринридеров.

.title {  display: block;  text-align: start;  position: relative;}.char {  position: relative;  display: inline-block;  transform: rotateX(90deg);}.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

Источники

16. alt, хотя нет..., aria-label, хотя нет..., alt

Контекст: список изображений, которые ссылаются на страницы с товаром

Плохой код

<a tabindex="0">  <div alt="Browser Wars: The Last Engine" aria-label="Browser Wars: The Last Engine">    <div>      <img alt="Browser Wars: The Last Engine" src="thumbnail.jpg">    </div>  </div></a>

Ошибки и что следует исправить

  • Если у элемента <a> атрибут href имеет пустое значение или данного атрибута нет вообще, он представляет собой заполнитель для того места, где могла быть ссылка (HTML спецификация)

  • Если вы добавляете обработчик клика к ссылке-заглушке, то, по всей видимости, хотите, чтобы она была не заглушкой, а полноценной ссылкой с атрибутом href или кнопкой <button>, в зависимости от того, что должно происходить при клике

  • Ссылки без href не получают фокус при переключении между элементами с помощью клавиатуры. tabindex исправляет эту ситуацию, но необходимость использовать данный атрибут лишь подтверждает тот факт, что корректно оформленная ссылка была бы в данном случае лучшим выбором

  • Атрибут alt не используется с элементами div и никак не влияет на их семантическое значение

  • Не злоупотребляйте ARIA. Атрибут aria-label лишний для элемента div, потому что img уже имеет доступное имя (значение атрибута alt)

Хороший код

Полноценная ссылка с заполненным атрибутом href и текстовая альтернатива alt для изображения

<a href="detail.html">  <div>    <img alt="Browser Wars: The Last Engine" src="thumbnail.jpg">  </div></a>

Источники

17. Недоступные карточки

Контекст: список карточек со ссылками, каждая из которых имеет заголовок, изображение и краткое описание

Плохой код

<section>  <section>    <h2>Overview</h2>    <figure class="card" data-url="image1.html" style="background: url(image1.jpg)">      <figcaption>        <h4>My heading</h4>        <article>Teasertext...</article>      </figcaption>    </figure>    <figure class="card" data-url="image2.html" style="background: url(image2.jpg)">  </figure>  </section></section>

Ошибки и что следует исправить

  • Вероятнее всего, в подобных ситуациях необходимости в таком количестве элементов <section> нет. Чтобы лучше понять почему, рекомендую прочитать статью "Why You Should Choose HTML5 <article> Over <section>" автора Bruce Lawson

  • Не следует недооценивать важность соблюдения иерархии заголовков. Например, пользователи скринридеров при навигации по сайту нередко ориентируются в структуре документа именно по его заголовкам

  • Согласно спецификации, HTML5-элемент <figure> представляет собой самодостаточный элемент, который под основным содержимым опционально может содержать подпись. Но в этом примере нет содержимого, есть только подпись

  • Изображнеие карточки не является декоративным, оно несёт какую-то информацию и должно быть частью HTML-кода документа, а не добавляться через CSS-свойство background . Фоновые изображения доступны пользователям не всех устройств

  • В приведённом примере обработка клика на карточку происходит только через JavaScript. Если нет элемента ссылки с указанием пути (<a href="path/to/page">), для пользователей скринридеров переход на страницу карточки становится недоступным. Также элемент карточки не получает фокус при навигации с помощью клавиатуры

  • Элементы <h1> - <h6> представляют собой вводный заголовок для родительского элемента <section>. <h4> является потоковым содержимым и, как следствие, технически может быть потомком <figcaption>, но лучше сделать его заголовком всей карточки

  • Элемент <article> представляет собой самодостаточную композицию на странице. Это может быть газетная статья , эссе или отчёт, публикация в блоге или социальной сети. Для обычного абзаца текста лучше использовать элемент <p>

  • Сделать доступной карточку, вся область которой является кликабельной, непросто. Дополнительную информацию можно найти в разделе "источники" ниже

Хороший код

<div>  <section>    <h2>Overview</h2>    <article class="card">      <h3>        <a href="image1.html"> My heading </a>      </h3>      <img src="image1.jpg" alt="Description of image1" />      <p>Teasertext...</p>    </article>    <article class="card">  </article>  </section></div>

Источники

18. Панель div-игации

Контекст: главная панель навигации

Плохой код

<div class="nav">  <div>    <div>about</div>    <div>thoughts</div>  </div></div>

Ошибки и что следует исправить

  • <div> - это элемент, используемый в крайнем случае - когда никакие другие элементы не подходят. Использование <div> вместо более подходящих по семантике элементов ухудшает доступность

  • Для главной панели навигации лучше использовать самантический элемент <nav>. Он является важным для доступности страницы ориентиром, содержащим ссылки на внешние и внутренние страницы. Пользователи скринридеров могут сразу получить доступ к навигации или наоборот пропустить её

  • Используйте элементы <ul> или <ol> для структурирования ссылок, связанных семантически и визуально. Скринридеры обычно объявляют номер элемента в списке, что помогает ориентироваться

  • Если в навигации имеет значение последовательность элементов, используйте <ol> вместо <ul>

  • Если вместо <a> для ссылок использовать элемент <div>, событие клика будет вызываться только непосредственно кликом мыши. Это сделает их недоступными для пользователей скринридеров и тех, кто переключается между элементами с помощью клавиатуры

Хороший код

<nav>  <ul class="nav">    <li>      <a href="http://personeltest.ru/aways/habr.com/about">about</a>    </li>    <li>      <a href="http://personeltest.ru/aways/habr.com/thoughts">thoughts</a>    </li>  </ul></nav>

Источники

19. Неправильная работа с заголовками

Контекст: простая страница, которая отображает наличие товара

Плохой код

<h1>Product Status</h1><h2>Is the product available?</h2><div>  <h3>    <div>      <div>        <i>          <h3 class="message is-success">            Its <a>available</a>.          </h3>        </i>      </div>    </div>  </h3></div>

Ошибки и что следует исправить

  • Элементы <h1> - <h6> не должны использоваться для разметки подзаголовков, альтернативных заголовков и слоганов, если только они не озаглавливают новый раздел или подраздел

  • Все элементы <div> в данном примере излишни. Скорее всего, они присутствуют только потому, что фронтенд-фреймворк добавляет их по умолчанию. Используйте Fragments in React или подобные техники в других фреймворка, чтобы избежать этого

  • Старайтесь избегать разрастания DOM. Слишком большое количество DOM-узлов и вложенных элементов может отрицательно повлиять на производительность страницы

  • Большое DOM-дерево ведёт к большому дереву доступности, что может отрицательно влиять и на скорость работы вспомогательных технологий

  • Потомками <h1> - <h6> могут быть только элементы фразового содержимого. <h3> и <div> к ним не относятся

  • Элемент <i> представляет собой фрагмент, который скринридеры произносят изменённой интонацией, чтобы обозначить его отличие от остального текста. Если вам нужен просто курсивный текст, используйте CSS-свойство font-style: italic

  • Если у элемента <a> нет атрибута href, он представляет собой заглушку в том месте, где в другой ситуации может быть ссылка

  • Если вы добавляете обработчик клика к ссылке-заглушке, то, по всей видимости, хотите, чтобы она была полноценной ссылкой с атрибутом href или кнопкой <button>, в зависимости от того, что должно происходить при клике

Хороший код

 <h1>Product Status</h1> <p>Is the product available?</p> <p class="message is-success">   Its <a href="http://personeltest.ru/aways/habr.com/product.html">available</a>. </p>

Источники

20. Спецвыпуск HTMHell: кнопка "Закрыть"

В данном спецвыпуске рассматривается один из наиболее сложных и наиболее спорных шаблонов во фронтенд-разработке кнопка "Закрыть".

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

После недолгого исследования, занявшего менее 2 часов, HTMHell представляет 11 примеров плохой реализации данного элемента

Пример 1: с фоновым изображением

<div class="close"></div>    

close::after {  background: url("close.png");  content: "";}

Ошибки и что следует исправить

  • <div> - это элемент для крайнего случая, когда никакие другие элементы не подходят. Использование <div> вместо более подходящих по семантике элементов ухудшает доступность

  • На <div> событие клика вызывается только непосредственно кликом мыши. На элементах <button> это происходит ещё и при нажатии на кнопки Enter или Space на клавиатуре

  • <div> не получает фокус при переключении между элементами с помощью клавиатуры

  • Для фонового изображения невозможно задать текстовую альтернативу

  • Данный элемент скринридеры озвучат: Никак

Пример 2: с иконкой

<div class="close">  </div>

Ошибки и что следует исправить

  • Символ "" не является чем-то вроде "Закрыть" или "Перечёркнуто", это знак умножения. Например, 2 2 (два умножить на два). В кнопках "Закрыть" использовать его неуместно

  • В первом примере подробно описаны проблемы, связанные с использованием элемента <div>

  • Данный элемент скринридеры могут озвучить: как-то вроде "умножить на" или "разы" (times)

Пример 3: Иконки Font Awesome

<div class="close">  <i class="fas fa-times"></i></div>

.fa-times::before {  content: '\f00d';}

Ошибки и что следует исправить

  • Скринридеры могут озвучивать содержимое, которое генерируется через CSS

  • Font Awesome рекомендуют скрывать иконки семантически с помощью атрибута aria-hidden="true" для элемента <i>

  • Font Awesome добавляет Unicode-содержимое через псевдоэлемент ::before. Вспомогательные технологии могут озвучивать эту Unicode-альтернативу, которая в этом конкретном примере будет звучать как "разы" (times), поскольку fa-times - это не крестик, а знак умножения. Обратите внимание: Talkback и VoiceOver в данном примере не озвучат вообще ничего

  • Элемент <i> представляет собой фрагмент, который скринридеры произносят другой интонацией, что обозначить его отличие от остального текста. Если вам нужен просто курсивный текст, используйте CSS-свойство font-style: italic

  • В первом примере подробно описаны проблемы, связанные с использованием элемента <div>

  • Данный элемент скринридеры могут озвучить: "разы" (times)

Пример 4: Закрывающая ссылка

<a href="#" class="close"></a>

a::after {  font-size: 28px;  display: block;  content: "";}

Ошибки и что следует исправить

  • Если элемент <a> содержит атрибут href, он представляет собой ссылку на другой ресурс: такой как страница или PDF-документ

  • Задача элемента в нашем примере вызвать JavaScript-действие на текущей странице. Элемент <button> с атрибутом type="button" подходит лучше, потому что не имеет поведения по умолчанию и разработан для вызова действий в ответ на нажатие пользователем

  • Если вы не уверены, когда нужно использовать элемент <a>, а когда <button>, посмотрите видео "The Links vs. Buttons Showdown" от Marcy Sutton

  • Скринридеры могут озвучивать содержимое, которое генерирует CSS

  • Символ "" не является чем-то вроде "Закрыть" или "Перечёркнуто", это знак умножения. Например, 2 2 (два умножить на два). Не используейте его в кнопках "Закрыть"

  • Данный элемент скринридеры могут озвучить: "ссылка, разы" (link, times)

Пример 5: Закрывающая ссылка с текстом

<a href="#" class="close">  Close</a>

.close::before {  content: "\e028";}

Ошибки и что следует исправить

  • Хорошая попытка, но это всё ещё ссылка, а не кнопка

  • В предыдущем примере подробно написано про использование элемента <a> и генерируемое CSS содержимое

  • Данный элемент скринридеры могут озвучить: "ссылка, разы закрыть" (link, times close)

Пример 6: Закрывающая ссылка без атрибута href

<a class="close" onclick="close()"></a>

Ошибки и что следует исправить

  • Ещё одна хорошая попытка, но ссылка без атрибута href всё еще не является кнопкой

  • Если у элемента <a> нет атрибута href, он представляет собой заглушку в том месте, где в другой ситуации может быть ссылка

  • Если вы добавляете обработчик клика к ссылке-заглушке, то, по всей видимости, хотите, чтобы она была не заглушкой, а полноценной ссылкой с атрибутом href или кнопкой <button>, в зависимости от того, что должно происходить при клике

  • Ссылки-заглушки не получают фокус при переключении между элементами с помощью клавиатуры

  • Если вы не уверены, когда нужно использовать элемент <a>, а когда <button>, посмотрите видео "The Links vs. Buttons Showdown" от Marcy Sutton

  • Данный элемент скринридеры могут озвучить: "разы, кликабельно" (times, clickable)

Пример 7: Ссылка-заглушка и изображение

<a onclick="close();">   <img src="close.png"> </a>

Ошибки и что следует исправить

  • Для изображения не задана текстовая альтернатива. Скринридеры могут озвучить название файла

  • В 6 примере подробно написано про использование ссылок-заглушек

  • Скринридеры могут озвучить данный элемент: "close.png, изображение" (close.png, image)

Пример 8: Радио-кнопка

<label class="close" for="close">   <svg>  </svg> </label> <input id="close" type="radio">

[type="radio"] {  display: none;}

Ошибки и что следует исправить

  • Когда сторонники доступности говорят "Просто используйте кнопку", они имеют в виду элемент <button>, а не радио-кнопки

  • Радио-кнопки используются в группах, описывающих набор связанных вариантов (опций)

  • У SVG нет текстовой альтернативы. Чтобы больше узнать о доступности SVG, рекомендую почитать статью "Creating Accessible SVGs" автора Carie Fisher

  • Также, display: none на элементе <input> делает недоступным <label>

  • Данный элемент скринридеры озвучат: Никак

Пример 9: Кнопка с иконкой

<button class="close" type="button">  </button>

Ошибки и что следует исправить

  • Символ "" не является чем-то вроде "Закрыть" или "Перечёркнуто", это знак умножения. Например, 2 2 (два умножить на два). Не используейте его в кнопках "Закрыть"

  • Данный элемент скринридеры могут озвучить: "разы, кнопка" (times, button)

Пример 10: Кнопка с svg

<button class="close">  <svg>  </svg></button>

Ошибки и что следует исправить

  • У SVG нет текстовой альтернативы. Чтобы больше узнать о доступности SVG, рекомендую почитать статью "Creating Accessible SVGs" автора Carie Fisher

  • Данный элемент скринридеры могут озвучить: "кнопка" (button)

Пример 11: Старая добрая буква "X"

<div role="button" tabindex="0">X</div>

Ошибки и что следует исправить

  • Нет необходимости с помощью атрибута role явно задавать семантику элемента, вместо этого стоит просто использовать элемент <button

  • При использовании <button> атрибут tabindex не нужен. HTML-кнопки получают фокус по умолчанию

  • В 1 примере подробно описаны проблемы, связанные с использованием элемента <div>

  • Буква "X" не является иконкой для кнопки "Закрыть"

  • Данный элемент скринридеры могут озвучить: "икс, кнопка" (X, button)

"Использовать букву "X" для кнопок "Закрыть" это то же, что добавлять в кофе соль вместо сахара, потому что выглядит она так же"

Max Bck

Примеры правильной разметки

Решение 1: Кнопка с видимым текстом без иконки

<button type="button">  Close</button>

  • Только текст: легко в реализации и понятно для пользователей

  • Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 2: Кнопка с видимым текстом и только визуально доступной иконкой

<button type="button">  Close  <span aria-hidden="true"></span></button>

  • Если вы вынуждены использовать иконку "умножить", скройте её от скринритеров, обернув в элемент <span> с атрибутом aria-hidden="true"

  • Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 3: Кнопка со скрытым текстом и только визуально доступной иконкой

<button type="button">  <span class="sr-only">Close</span>  <span aria-hidden="true"></span></button>

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

  • К сожалению, не существует встроенного способа скрывать содержимое только визуально. Для этого следует использовать CSS-правило, называемое классом .sr-only которое гарантирует, что контент будет скрыт визуально, но останется доступным для пользователей скринридеров.

  • Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 4: Кнопка со скрытым текстом и только визуально доступной иконкой

<button type="button" aria-label="Close">  <span aria-hidden="true"></span></button>

  • Если вы не хотите показывать текст на экране, обеспечьте для иконки или SVG текстовую альтернативу, добавив к кнопке атрибут aria-label

  • Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 5: Font Awesome

Для полноты картины, закрывающая кнопка с иконкой Font Awesome

<button type="button" class="close" aria-label="Close">  <span class="fa fa-times" aria-hidden="true"></span></button>

Общие примечания

Порой может иметь смысл использование более описательных названий "Закрыть окно", "Закрыть галереию", "Закрыть рекламу".

Если вы используете сторонние решения для подальных, диалоговых окон, проверяйте, как они были реализованы перед добавлением на сайт. Не полагайтесь на других в вопросах качества и доступности кода.

Источники

21. Легендарный legend

Контекст: кнопка, которая разворачивает и сворачивается блок текста

Плохой код

<button class="panel-heading" tabindex="0" href="#collapse0" aria-expanded="true">  <legend> Industries Served </legend></button>

Ошибки и что следует исправить

  • <legend> не разрешается помещать в какой-нибудь другой элемент, кроме <fieldset> (HTML спецификация для legend)

  • При использовании <button> атрибут tabindex не нужен. HTML-кнопки получают фокус по умолчанию.

  • Атрибут href не может использоваться с элементом <button> (HTML спецификация для button)

Хороший код

<button class="panel-heading" aria-expanded="true">  Industries Served</button>

Источники

22. Старая добрая div-ссылка

Контекст: ссылка на другую страницу

Плохой код

<div>About us</div>

<div onClick="location.href='about.html'">  About us</div>

<div data-page="aboutus" data-url="index.php">  About us</div>

... или любой другой вариант этого шаблона, где для ссылки на другую страницу используется отличный от <a> элемент

Ошибки и что следует исправить

  • <div> - это элемент для крайнего случая, когда никакие другие элементы не подходят. Использование <div> вместо более подходящих по семантике элементов ухудшает доступность

  • На <div> событие клика вызывается только непосредственно кликом мыши. На элементах <a> это происходит ещё и при нажатии на кнопку Enter на клавиатуре.

  • <div> не получает фокус при переключении между элементами с помощью клавиатуры

  • При нажатии правой кнопкой мыши в контекстном меню не будет пунктов "Открыть в новой вкладке/окне" или "Добавить ссылку в закладки"

  • По умолчанию скринридеры просто озвучивают текст внутри <div> (например, "О нас"). В случае использования ссылки <a> скринридеры текст и роль элемента (например, "О нас, ссылка")

  • Атрибуты наподобие aria-label у элементов <div> могут работать неправильно

  • Пользователи скринридеров могут использовать раздел со списком ссылок страницы. <div>-ссылок в этом разделе не будет, если только к элементу не будет добавлен атрибут role="link"

Хороший код

<a href="aboutus.html">  About us</a>

23. Шаблон карточки

Плохой код

<article>  <div>    <div class="sr-only">Image</div>    <img src="http://personeltest.ru/aways/habr.com/feature-teaser.png" alt="Feature teaser" />  </div></article><div>  <span>    <span>Exciting feature!</span>  </span>  <div> This text describes what the feature does! </div>  <a href="http://personeltest.ru/aways/habr.com/blog/feature">    <span>Read more</span>    <svg viewBox="0 0 9 12" xmlns="http://personeltest.ru/away/www.w3.org/2000/svg">      <path d="M.84 10.59L5.42 6 .84 1.41 2.25 0l6 6-6 6z"></path>    </svg>  </a></div>

Ошибки и что следует исправить

  • В примере выше используется <article>. Этот элемент предназначен для самодостаточного содержимого, которое может быть повторно использовано на странице. Если здесь и есть что-то повторно используемое, то вся карточка. Более подходящим является элемент <section>

  • В первом <div> присутствует доступный только для скринридеров текст "Image". Ощущение, что это своего рода определение роли следующего за ним элемента <img>. Правильно подобранные HTML-элементы сами сообщают о своей семантике. Необходимость в дополнительных "уточнениях" отпадает

  • Далее расположен <span>, который, кажется, является заголовком. Вспомогательные технологии могут использовать указанные в коде заголовки для быстрой навигации. Следовательно, более корректным будет использовать элемент заголовка корректного уровня. В данном случае <h4>

  • Основной текст внутри карточки обёрнут в <div>. Использование <p> лучше передало бы его предназначение

  • "Read more" не самый лучший текст для ссылки. Это особенно заметно пользователям скринридеров, которые используют навигацию по ссылкам. Из названия непонятно, куда именно ведёт эта ссылка

  • <svg> внутри ссылки не предоставляет дополнительную информацию и должен быть скрыт от скринридеров

Хороший код

<section>  <div>    <img src="http://personeltest.ru/aways/habr.com/feature-teaser.png" alt="" />  </div>  <div>    <h4>Exciting feature!</h4>    <p>This text describes what the feature does!</p>    <a href="http://personeltest.ru/aways/habr.com/blog/feature">      <span>Read more about our exciting feature </span>      <svg aria-hidden="true" viewBox="0 0 9 12" xmlns="http://personeltest.ru/away/www.w3.org/2000/svg">        <path d="M.84 10.59L5.42 6 .84 1.41 2.25 0l6 6-6 6z"></path>      </svg>    </a>  </div></section>

Источники

24. Placeholder - это не label

<input type="text" placeholder="First name">

Ошибки и что следует исправить

  • Каждому элементу <input> нужен <label>. Когда пользователи скринридера переходят к полям формы, озвучивается содержимое <label> и тип поля (например, "имя, поле ввода"). Если этот текст пропущен, пользователи могут не знать, какую информацию они должны указать в этом поле

  • Некоторые скринридеры всё же берут текст из атрибута placeholder, но не стоит полагаться на это

  • По умолчанию, текст placeholder отображается светло-серым цветом с плохой контрастностью. Людям со слабым зрением может быть трудно его прочитать при ярком солнечном свете

  • С помощью псевдоэлемента ::placeholder можно улучшить контрастность цвета. Но тут тоже нужно не переборщить, поскольку текст с очень контрастным цветом пользователи могут принять за текстовое содержимое поля

  • Использование <label> увеличивает область выбора нужного поля, что может быть очень полезным, особенно на устройствах с сенсорным экраном

  • Если placeholder является единственным местом, содержащим название поля, при вводе текста он скрывается. Это ухудшает удобство заполнения форм, особенно если содержат много полей.

  • Пользователи не могут проверить, правильно ли они заполнили форму, потому что видят только значения, но не названия полей.

  • Если браузер заполняет поле автоматически, пользователь вынужден вырезать содержимое поля, чтобы убедиться, что оно заполнилось корректно

  • Текст placeholder обрезается, если он выходит за рамки поля

  • Инструменты подобные Google Translate могут не переводить значение данного атрибута при переводе всей страницы

  • Названия полей лучше воспринимаются, когда расположены над соответствующим текстовым полем, а не внутри него

Хороший код

 <label for="firstname">First name</label> <input type="text" id="firstname">

Источники

Подробнее..
Категории: Html , Разработка веб-сайтов , Css , Usability , Accessibility , Htmhell

HTML и CSS ошибки, ухудшающие UX

24.05.2021 10:16:39 | Автор: admin
В прошлом году я собрал несколько случаев, когда HTML и CSS ошибки негативно влияют на доступность интерфейсов. В этой статье я хочу продолжить и описать еще несколько случаев.


Не мучайте пользователей свойствами justify-content и align-items


Когда мы решаем задачи по позиционированию элементов, нам нравится использовать свойства justify-content и align-items. Но мало кто знает, что эти свойства могут провести к мукам пользователя. Особенно часто проблемы связаны с вертикальным позиционированием.

Это связано с особенностями работы свойств, а именно свойства justify-content и align-items не учитывают размеры flex-элементов. Соответственно в случае когда размеры flex-элементов больше размеров flex-контейнера, то flex-элементы будут выходить за его пределы, и могут отображаться некорректно.

Например, я часто не могу закрыть модальное окно, потому что кнопка-крестик вышла за пределы окна и не доступна. Вы можете увидеть этот эффект на изображении ниже.

Эта проблема легко решается с помощью свойства margin со значением auto. Внутри flex-контейнера значение auto будет рассчитано с учетом размера самого контейнера и размеров flex-элементов. Если размеры flex-элементов меньше, чем размеры flex-контейнера, то браузер рассчитает отступ автоматически. А если больше, то элементы прижмутся к границам flex-контейнера.

Не делайте так

<div class="modal">  <div class="modal__main"></div></div>



.modal {  display: flex;  justify-content: center;  align-items: center;}


Можно делать так

<div class="modal">  <div class="modal__main"></div></div>



.modal {  display: flex;}.modal__main {  margin: auto;}




Не заставляйте пользователей ждать загрузки кастомных шрифтов


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

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

Для это существует дескриптор font-display, который определяет то, как шрифт, подключённый через font face будет отображаться в зависимости от того, загрузился ли он и готов ли к использованию.

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

Этим трюком вы поможете вашим пользователям быстрее начать взаимодействовать с интерфейсом, а не ждать отображения текста.

Не делайте так

@font-face {  font-family: "Baloo Tamma";  src: url("balotamma.woff2") format("woff2"),       url("balotamma.woff") format("woff");}


Можно делать так

@font-face {  font-family: "Baloo Tamma";  src: url("balotamma.woff2") format("woff2"),       url("balotamma.woff") format("woff");  font-display: swap;}




Не ломайте SVG иконками интерфейсы


Когда вы используете SVG иконки внутри HTML, обратите внимание, что вам нужно уставить атрибуты width и height. Если вы это не сделаете и установите ширину и высоту через CSS, то ваш интерфейс будет сломан.

В эпоху фреймворков CSS может сработать не сразу. Я не понимаю как это получилось, но я видел приложения на React, в которых cначала отображались огромные иконки, а только потом они принимали нужный размер. Поэтому просто установите размеры через атрибуты width и height, и ваши интерфейсы будут пуленепробиваемыми.

Не делайте так

<svg   xmlns="http://personeltest.ru/away/www.w3.org/2000/svg"  viewBox="0 0 448 512">    <path fill="currentColor" d="..."></path></svg>



svg {  width: 0.875rem;  height: 1rem;}


Можно делать так

<svg   xmlns="http://personeltest.ru/away/www.w3.org/2000/svg"  viewBox="0 0 448 512"  width="0.875rem"  height="1rem">    <path fill="currentColor" d="..."></path></svg>


Не заставляйте ждать пользователей загрузки тяжелых изображения на всех типах устройств


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

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

Например, мы может создать 2 source элемента и определить через медиа-запросы, какое изображение загружать на планшетах, а какое на десктопах. Кроме того, для отображения изображения на мобильных устройствах мы будем использовать элемент img.

Не делайте так

<img   src="ferrari-1920x1080.jpg"  alt="yellow ferrari F8 spider on the background of the ocean">


Можно делать так

<picture>  <source     srcset="ferrari-1200x960.jpg"    media="(min-width: 641px) and (max-width: 1200px)">  <source     srcset="ferrari-1920x1080.jpg"    media="(min-width: 1201px)">   <img     src="ferrari-640x480.jpg"    alt="yellow ferrari F8 spider on the background of the ocean"></picture>

Также мы можем оптимизировать загрузку изображений для retina-экранов. Для этого мы будем использовать дескриптор плотности.

Например, если у смартфона плотность пикселя 2x, то браузер загрузит ferrari-640x480-2x.jpg, а если 1x, то ferrari-640x480-1x.jpg. Такой же механизм сработает для планшетов и десктопных экранов.

Не делайте так

<img   src="ferrari-1920x1080.jpg"  alt="yellow ferrari F8 spider on the background of the ocean">


Можно делать так

<img   src="ferrari-1x.jpg"  srcset="ferrari-2x.jpg 2x"  alt="yellow ferrari F8 spider on the background of the ocean"><!-- или  --><picture>  <source     srcset="ferrari-1200x960-1x.jpg, ferrari-1200x960-2x.jpg 2x"    media="(min-width: 641px) and (max-width: 1200px)">  <source     srcset="ferrari-1920x1080-1x.jpg, ferrari-1920x1080-2x.jpg 2x"    media="(min-width: 1201px)">   <img     src="ferrari-640x480-1x.jpg, ferrari-640x480-2x.jpg 2x"    alt="yellow ferrari F8 spider on the background of the ocean"></picture>


P.S: Если у вас есть вопросы по CSS/HTML, то, не стесняйтесь, пишите мне на мою почту. Она указана в моем профиле на Хабре.
Подробнее..
Категории: Html , Css , Usability , Accessibility , Ux , Front-end

Нарушает ли React DOM-стандарты?

13.03.2021 18:22:01 | Автор: admin

Существует довольно популярный сайт https://custom-elements-everywhere.com где показывается как работают веб-компоненты в разных фреймворках. Почти у всех фреймворков там красивый 100% результат, но у React там очень настораживающие 71%:

Рейтинг React на custom-elements-everywhere.comРейтинг React на custom-elements-everywhere.com

Многие пользователи смотрят на эту страничку и делают вывод, что React плохо поддерживает не только веб-компоненты, но и DOM API в принципе. Так ли это? Действительно ли все плохо?

Давайте разбираться!

Анализируем тесты

Рейтинг высчитывается на основании тестов. Вот тут показывается результат. Всего 15 тестов, 7 из них сломаны, отсюда получаем такой неважный рейтинг. Сломаны следующие тесты:

  • attributes and properties

    • will pass array data as a property

    • will pass object data as a property

  • events

    • can declaratively listen to a lowercase DOM event dispatched by a Custom Element

    • can declaratively listen to a kebab-case DOM event dispatched by a Custom Element

    • can declaratively listen to a camelCase DOM event dispatched by a Custom Element

    • can declaratively listen to a CAPScase DOM event dispatched by a Custom Element

    • can declaratively listen to a PascalCase DOM event dispatched by a Custom Element

Можно заметить, что все это тесты с похожими именами, то есть они тестируют разные аспекты одной и той же штуки. Скорее всего все эти падения вызваны одной проблемой и можно исправить их все одним изменением. Поэтому цифра в 71% по сути ничего не значит, это могло быть и 90% и 15% в зависимости от фантазии автора, и сколько тест-кейсов он написал.

Однако факт остается, что-то не работает, и с этим нужно разбираться. Вся ситуация сводится к двум баг-репортам на Github:

Какие же сложности мешают "просто взять и починить" фреймворк? Давайте сначала разберемся с событиями.

События

В современных фреймворках принято добавлять обработчики событий сразу рядом со обычными атрибутами:

<input type="checkbox" checked={checked} onChange={handleChange} />

Это позволяет сразу видеть что подается на вход и выход элемента в одном месте. С веб-компонентами хотелось бы делать то же самое:

<custom-checkbox checked={checked} onChange={handleChange} />

Однако это не работает, потому что не каждый атрибут начинающийся с on* React превращает в обработчик события. Вместо этого они поддерживают избранный (пусть и довольно большой) список событий. Почему они так сделали, объясняет Sebastian Markbge (один из разработчиков React) в этом комментарии. Вот мой перевод:

Мы активно ищем различные способы решения этой проблемы, но нужно принимать в расчет некоторые моменты. Например, как touch-события будут работать в сложных жестах и как это будет согласовываться со всплытием событий, как это будет работать при серверном рендеринге с избирательной гидрацией, как мы сможем добавить дополнительные возможности вроде различного приоритета разным типам событий, как мы будем различать дискретные события и непрерывные поточные события в конкуретном режиме, как мы будем взаимодействовать с "глобальными" событиями вроде нажатия клавиш, и т.д. Мы уже предприняли несколько неудачных попыток, и в конце концов мы хотим сделать это правильно.

Конечно, мы можем добавить простую реализацию, которая оставляет эти вопросы открытыми. Однако, мы уже знаем, что даже если мы добавим такую простую модель, мы захотим задепрекейтить ее и удалить в будущем в пользу наших текущих изысканий. Нам кажется, что работа не стоит того ради небольшого синтаксического улучшения. Экосистема будет вынуждена поддерживать как ручные ссылки на DOM-элементы, _так и_ этот новый синтаксис, пока мы разрабатываем новую систему. Вместо этого вы можете уже сейчас пользоваться ручным управлением через ссылки на DOM-элементы (refs) и это будет рабочий вариант.

Таким образом, React не предоставляет прямого доступа к DOM-событиям, потому что они хотят их обернуть в свои абстракции, чтобы лучше поддержать будущие фичи React (вроде Concurrent mode), у разработчиков уже сейчас есть вариант добавлять события вручную через Refs API:

function CustomCheckbox({ checked, handleChange }) {const ref = useRef();useEffect(() => {ref.current.addEventListener("change", handleChange);return () => ref.current.removeEventListener("change", handleChange);  }, [handleChange]);  return <custom-checkbox ref={ref} />;}

Если возможность добавления событий есть, то почему же тогда это не делается в тестах custom-elements-everywhere? Автор этой странички считает это хаком и настаивает на том, что поддержка должна быть встроена во фреймворк. Получается, что результаты этого теста основаны на субъективном мнении, а не технической возможности/невозможности решить задачу.

Свойства или атрибуты?

Вторая причина так называемой "несовместимости в веб-компонентами" это невозможность передать в них свойства. Все, что вы передаете веб-компоненту в JSX будет превращено в атрибут. Атрибуты могут быть только строками, поэтому передать сложный объект не получится (хаки с JSON.stringify) в расчет не берем:

<user-view user="{user}" /><!-- рендерит <user-view user="[object Object]" /> -->

Причины такого поведения очень похожи на ситуацию с событиями выше. Команда React хочет абстрагироваться от реального DOM и назначать кастомное поведение индивидуальным свойствам для каких-то своих целей. При этом у вас всегда есть возможность обратиться к DOM-элементу напрямую, и задать какие угодно свойства. С появлением React-хуков код становится очень простым и элегантным:

function UserView({ user }) {const ref = useRef();// обновлять свойство при новом объекте useruseEffect(() => (ref.current.user = user), [user]);return <user-view ref={ref} />;}

Более того, если написание обертки для каждого свойства и компонента может утомить, то можно взять вот этот маленький модуль, который научит JSX работать и со свойствами, и с событиями как надо:

/** @jsx h */import { createElement } from "react";import val from "@skatejs/val";const h = val(createElement);function Checkbox({ checked, handleChange }) {// работает!return <custom-checkbox checked={checked} onChange={handleChange} />;}

Таким образом, технически задача решается, есть и переиспользуемый плагин, но Google Developer Advocates недовольны тем, что решение это не такое, как им бы хотелось. Ради этого они готовы дезинформировать публику о том, что у React есть проблемы с совместимостью с DOM (которых на самом деле нет).

Достоверность 100% рейтинга

Еще есть интересная ситуация со 100% результатами. Действительно ли это гарантия отсутствия проблем совместимости? Как бы не так!. Имена событий могут быть любой строкой и содержать любые символы (вы же всегда хотели сделать new CustomEvent('клик!'))?

Иногда это вызывает проблемы совместимости с синтаксисом шаблонов. Например, в Angular нельзя использовать двоеточие при назначении обработчика событий в шаблонах. При этом materials-components-web использует такую систему именования событий: MDCSlider:change. Возникает ироничная ситуация когда один проект Google (Angular) несовместим с другим проектом той же компании (Material design). Решение всё то же, нам уже знакомое добавим обертку и назначим обработчик через прямое обращение к DOM-элементу.

Таким образом, необходимость создания оберток, из-за которой React влепили его 71% рейтинга, не помешала дать Angular 100%. Вот такой вот непредвзятый рейтинг.

На всякий случай замечу, что это не является проблемой ни одного из фреймворков. Имена свойств и событий могут быть самыми разными и не вписываться в синтаксис шаблонов. Явное лучше неявного, и брать ручное управление DOM в особых случаях это нормально. Не очень понятно, какую цель преследует автор custom-elements-everywhere своим рейтингом.

Реальная ситуация

После того как мы разобрались c custom-elements-everywhere, давайте посмотрим на реальные проблемы совместимости между React и DOM API за пределами этой истории с веб-компонентами. Будем честны, они есть:

  1. onChange обработчик в React совсем не равен DOM-событию change. Это действительно проблема, причины такого поведения объясняются в этом [Github issue](https://github.com/facebook/react/issues/9657). Это вызывает сложности как при изучении React, так и при миграции с React на что-то другое, когда выясняется, что onChange в React не настоящий.

  2. onFocus/onBlur события всплывают. В привычном нам DOM API, событие focus, вызывается только на том элементе, который получает фокус. В React же это событие всплывает по дереву компонентов, по сути работает как событие focusin. Больше об этом можно почитать в этом issue.

  3. События всплывают по порталам. Возможно, многие посчитают это фичей, но для полноты картины написать об этом стоит. Portal API позволяет рендерить элементами за пределами основного контейнера с React-приложением. При этом события продолжат всплывать по дереву компонентов а не DOM-дереву, как будто портала никакого и нет.

Список далеко не полный, но это те моменты с которыми довелось лично мне столкнуться и которые я бы хотел исправить. Как видно, все не так уж плохо, и несмотря на эти недостатки, с помощью React можно строить большие, но при этом доступные (семантичные) веб-интерфейсы и использовать полную мощь DOM API в тех местах, где React недостаточно (например, декларативно управлять фокусом через react-focus-lock).

Послесловие

Одним из фундаментальных требований по доступности к веб-сайтам является правильное оформление текстовых полей. Каждому полю должен быть назначен соответствующий label. Часто это делается через for и id атрибуты:

<label for="name">Ваше имя</label><input id="name" name="firstName" />

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

const id = useUniqueId();<Label for={id}>Ваше имя</Label><Input id={id} name="firstName" />

При этом компоненты Label и Input рендерят соответствующие html-тэги и наше текстовое поле остается семантичным и доступным.

Попробуем сделать то же самое без React, но на веб-компонентах:

<custom-label for="name">Ваше имя</custom-label><custom-input id="name" name="firstName" />

Наше текстовое поле сломалось! Внутренний тэг label не смог связаться с тэгом input, потому что они находятся в разных ShadowDOM инстансах. Существует proposal призванный решить эту проблему, но он еще в зачаточной стадии и не работает ни в одном из браузеров (напоминаю, веб-компоненты разрабатываются без малого уже 10 лет). А в настоящий момент реализовать custom-label и custom-input в виде веб-компонентов, соблюдая требования доступности, не получится.

Вот и думайте сами, какая технология тут является настоящим нарушителем веб-стандартов.

Подробнее..
Категории: Javascript , React , Разработка веб-сайтов , Reactjs , Accessibility , Web-components , Ui library

Программа HolyJS нюансы DevTools, минусы GraphQL, инструменты a11y

01.04.2021 14:11:52 | Автор: admin


Осталось меньше месяца до конференции HolyJS (20-23 апреля, онлайн) пора рассказать, что именно там будет. Под катом описания докладов с разбивкой по тематическим блокам. А для начала несколько вопросов для затравки:


  • В чём недостатки GraphQL?
  • Зачем OCaml на фронтенде?
  • Чего вы не знаете о DevTools?
  • Как писать надёжные тесты для Vue?
  • Как сделать свой DSL-язык легко и непринуждённо?
  • Как добиться на дешёвом устройстве плавности дорогого?
  • Как отобразить 100500 метрик и не сойти с ума?
  • Как принести в JS типы ещё радикальнее, чем в TypeScript?

Ответы на всё это и многое другое в докладах.


Оглавление


Инструменты
Производительность
Фреймворки
Языки
Микрофронтенды
Основы
Визуал
Заключение



Инструменты


Всё, что вам нужно DevTools, Виталий Фридман


DevTools очень продвинутый и полезный набор инструментов, но также он может быть устрашающим и непосильным. Давайте исправим это. Виталий пройдёт через десятки полезных и скрытых фич DevTools, советов и приёмов, объяснит пугающий перформанс и сетевые панели, покажет навороченные экспериментальные фичи и процесс дебага для работы с CSS и JS.


Чем хорош спикер: Виталий человек-харизма, не нуждающийся в представлении: зрители предыдущих HolyJS хорошо помнят его доклады. Он известный перфекционист и адвокат современного веба, отличающийся вниманием к каждой детали.


Чем хороша тема: DevTools использует каждый, но там столько подводных камней, что без помощи не разобраться! Возможно, сверхсеньоры и не найдут чего-то прорывного, но даже им будет интересно увидеть flow работы Виталия.



Сделать сайт доступным за 60 секунд, Глафира Жур и Денис Бирюк


Все вокруг говорят о доступности: она нужна, важна и должна быть добавлена в проект на самом раннем этапе. Но никто не говорит, как рядовому фронтенд-разработчику, путающему a11y и 11ty, разобраться в вопросе. Какой пакет подключить в Webpack, чтобы проблемы решались на этапе сборки? Где в консоли найти отчёт об ошибках a11y? И как проверить результат своей работы после деплоя?


Чем хороши спикеры: Два спикера два мира. Глафира эксперт по интерфейсам, Денис любит прикручивать автоматизацию к фронтенд-проектам.


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


Кому будет полезно: Знаете про доступность, но не практикуете, потому что ну это же сложно? Тут расскажут, что конкретно добавить в ваш проект, чтобы пользователям было удобнее.



WebXR в реальной жизни, Роман Пономарев


Дополненная и виртуальная реальности отличные инструменты для демонстрации продукта. А браузер всегда под рукой и позволяет визуализировать что угодно без скачивания приложений. В докладе рассмотрим существующие технологии для работы с AR и VR в вебе, стандарты, лежащие в их основе, а также затронем состояние XR-индустрии в целом, увидим демки и узнаем, как можно продать это всё бизнесу.


Чем хорош спикер: У Романа есть практический опыт в теме. Некоторые зрители также могут знать его по Фронтенд Юности.


Чем хороша тема: Даже в доковидные времена Virtual/Augmented Reality всё больше проникала в нашу жизнь, а уже теперь и подавно. Тем временем спецификация WebXR взрослеет и позволяет делать всё больше.



Make your authentication flow perfect, Anton Nemtsev


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


Чем хороша тема: Актуальный доклад, который покажет не только как сделать хорошо, но и как это продать. У нас уже были доклады о теоретической, секьюрной части авторизации, мы увидели фидбек о том, что нужно больше практичности, и следуем ему.


Кому будет полезно: Если вы работали с формами авторизации и регистрации, либо вам интересно, как можно сделать их удобными



Воркшоп. GitLab + CI/CD + JavaScript = любовь, Виталий Слободин


Стать передовиком производства можно при помощи настроенных процессов. Это знают все. Но как настроить процессы вопрос сложный, лучше всего начинать с машин, потому что они податливее, чем люди. Первым шагом для настройки непрерывного цикла разработки может стать CI/CD. Цель Виталия показать вам трюки и рецепты для создания CI/CD, чтобы все инженеры были довольны и счастливы.


Чем хорош спикер: Ранее на HolyJS Виталий рассказывал про headless browsers, и доклад приняли отлично: глубоко знать тему ему помог личный опыт разработки PhantomJS. А теперь он работает в GitLab так что снова поговорит о том, к чему сам причастен.


Чем хороша тема: В результате развития подхода DevOps сейчас JS-разработчикам самим приходится думать про то, как их код будет тестироваться и собираться. Виталий обещал дать набор готовых рецептов.



Serverless и Edge Computing на практике, Алексей Тактаров


Две основные проблемы при построении веб-сервисов повысить пропускную способность и снизить время ответа от сервера. Это проблемы, которые обычно решают с помощью наращивания мощностей, горизонтального масштабирования и разнесения дата-центров по континентам. Такой подход надежен, но дорог и требует обслуживания. Лямбда-вычисления и Smart CDN относительно новые и дешевые технологии, призванные решить обе задачи.


В докладе Алексей рассмотрит практическое применение лямбд от Vercel и Cloudflare: проектирование фронтенд-микросервисов, их авторизацию, работу с CDN и особенности кеширования на пограничных (edge) серверах. Будут затронуты архитектурные приемы для построения легко масштабируемых сервисов на примере задач: рендеринг PDF/DOCX-документов, генерация above-the-fold CSS для страниц на лету в Cloudflare Workers, отрисовка OG-картинок.


Чем хорош спикер: Алексей очень опытный спикер и специалист очень широкого спектра: отлично разбирается во фронтенд-разработке, дизайне, бекенде, инфраструктуре, безопасности, оптимизации и много другом. А благодаря стартаперскому бэкграунду понимает, что полезно бизнесу.


Чем хороша тема: Достаточно высокая практическая польза. Много примеров и будет показан реальный опыт. Применение этих знаний можно легко использовать для улучшения архитектуры и скорости проектов многих зрителей. Доклад охватывает достаточно широкую аудиторию подходит практически для любого уровня.



Гиперавтоматизированный пайплайн, или Почему матрица должна победить, Алексей Золотых


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


Но настало время машин. Алексей расскажет о том, как быстро захватить власть в проекте на JavaScript или TypeScript. Как унижать и угнетать разработчиков так, чтобы они при этом оставались эффективными и счастливыми. И как не допустить появления Нео!


Чем хорош спикер: Пишет на JavaScript c 2007 года, давно участвует в HolyJS в качестве участника программного комитета.


Чем хороша тема: В наше девопсовое время вопросы автоматизации пайплайнов всё актуальнее.



Воркшоп: Знакомство с MobX, Назим Гафаров


MobX это простая и эффективная библиотека, но найти хорошие материалы по ней невероятно трудно. Видеоуроки и статьи, да и сама документация MobX слишком перегружены.


В этом воркшопе мы напишем приложение на React и TypeScript, используя MobX для управления состоянием. Начнем с фундаментальных понятий, таких как наблюдаемые объекты, действия и реакции. Вместе с основами глубже рассмотрим варианты решения проблемы окрашивания асинхронных функций. В конце рассмотрим полезные архитектурные паттерны вроде композиции классов и способов внедрения модели.



Производительность


Быстрый и красивый веб на дешевом девайсе с голосовым, пультовым и тач-управлением, Павел Ремизов


Вот реальная инженерная задача: есть SberBox за 3 000 рублей и SberPortal за 30 000. Производительность разная, но написанный на веб-технологиях интерфейс должен работать одинаково плавно. Павел Ремизов расскажет, как решали эту задачу, как ускоряли анимации и как использовали React, как кэшировали статику на девайсах и уменьшали размеры бандла, как отлаживали и измеряли производительность.


Чем хорош спикер: Имеет очень хорошую экспертизу в производительности и в реальных аспектах ее оценки


Чем хороша тема: Реальные устройства, юзкейсы, пользователи никаких коней в вакууме! Происходят реальные эксперименты на в боевых условиях, и их результаты не всегда совпадают с общепринятым мнением.



Оптимизация производительности высоконагруженного поиска на стороне фронтенда, Даниил Гоник, Ян Штефанец


Даниил Гоник и Ян Штефанец работают над редактором наподобие Google Docs.


Они расскажут, как правильно частично отрисовывать контент, что делать, если пользователь быстро скроллит, как подсвечивать нужные области при поиске, и как это применять не только в редакторах, но и на обычных сайтах.


Чем хороши спикеры: Докладчики глубоко и много работали с созданием редактора в вебе, поэтому экспертизы и знания нюансов много.


Кому будет полезно: Если вы реализовывали подсветку элементов на сайте по тексту, если вы работали когда-либо с WYSIWYG



Стабильность React Native-приложения с круглосуточным up time, Евгений Гейманен


Евгений Гейманен расскажет поучительную историю про проблемы производительности одного React Native-приложения. Из нее вы узнаете:


  • Как оптимизировать перерисовку виртуального React DOM;
  • Как правильно мутировать redux-store, коннектить к нему компоненты и описывать селекторы;
  • Как находить проблемные места в Android-версии React Native-приложения;
  • Какими инструментами стоит обзавестись для того, чтобы держать руку на пульсе приложения и начать думать как приложение.

Чем хорош спикер: Евгений Lead Developer в Bolt и ему есть что рассказать как с точки зрения технологий, так и с точки зрения истории


Чем хороша тема: Мониторинг это одна боль. Мониторинг приложений установленных на куче девайсов другая. Это реальный опыт решения некоторого количества проблем производительности на примере React Native приложения



Производительность в полевых условиях, Александр Шушунов


Вы уже прочитали все статьи Эдди Османи. Выучили, как расшифровываются аббревиатуры RAIL, PRPL, LCP и прочие. Свежий перформанс-гайд Фридмана второй месяц висит в открытой вкладке. Но как все это применить к текущему проекту? Как улучшить производительность здесь и сейчас? Александр не знает и не будет давать общие советы зато расскажет, что сделал он. И надеется, что его опыт борьбы за секунды и байты покажется вам интересным.


Чем хороша тема: Сугубо практический взгляд на производительность от человека, повидавшего виды. Будет отличным дополнением к докладу Виталия Фридмана. Причем зачастую хороших результатов можно достичь малой кровью


Кому будет полезно: Если вам интересна тема производительности клиентских приложений. Особенно, если вы никогда специально не работали в этом направлении, и хотите посмотреть на свой текущий проект под другим углом



Фреймворки


А нужен ли нам GraphQL?, Павел Черторогов


Это далеко не первый доклад Павла про GraphQL, так что он уже глубоко в теме, но у него нет слепого фанатизма. Он понимает, что GraphQL это инструмент, а не серебряная пуля. И каждый инструмент удобен под свою категорию задач. Молотком шуруп не закрутишь, отверткой гвоздь не забьешь это практически нереально.


И в этом докладе речь пойдёт как раз о том, каких ситуациях GraphQL нужен (например, когда модели постоянно развиваются и количество полей растет), в каких не нужен (например, когда ведется работа с файлами или другими бинарными данными), и что делать, если ситуация спорная (попадаем в обе категории сразу). Будут разобраны сильные и слабые стороны и найдены разумные компромиссы.



How we built our custom React SSR Engine, Erzhan Torokulov


Эржан Торокулов расскажет, как несколько лет назад в Toptal сделали React Rendering Engine: он уже тогда умел делать ряд вещей, которые теперь знакомы по инструментам вроде Gatsby и Next.js. Компания по-прежнему использует этот инструмент для своего сайта и продолжает его развивать.


Чем хорош спикер: Эржан имеет глубокий опыт не просто применения существующих решений, но и написания больших инструментов для компании.


Чем хороша тема: Никого не удивить сайтом на React, Vue или даже Svelte, и доклады про React стали очередными. Индустрия перестала строить велосипеды и догадалась положить рельсы. Но иногда хочется большего и это такой случай.



Как в GitLab @vue/test-utils обновляли, Илья Климов


За последний год Илья дважды обновлял @vue/test-utils в GitLab и оба раза это заняло огромное количество времени. Для того, чтобы это сделать, ему пришлось отправить более десятка pull-request'ов во @vue/test-utils, обсудить в RFC внутри GitLab возможность создания собственного форка, глубоко разобраться в механизмах реактивности Vue и нещадно воевать за качество кода и тестов как в GitLab, так и в самом @vue/test-utils.


Теперь Илья со зрителями HolyJS будет разбираться в следующих вопросах:


  • где спрятана сложность в тестировании подобных систем;
  • какие ошибки были допущены разработчиками @vue/test-utils и можно ли было их избежать;
  • как магия реактивности усложняет построение надежной системы и как с этим бороться;
  • как писать надежные тесты для Vue.

Доклад будет интересен не только тем, кто использует Vue.js в повседневной разработке, но и всем, кто верит в unit-тестирование как ключ к управляемости любого проекта.




Языки


Свой язык с поддержкой sourcemaps за полчаса, Дмитрий Карловский


DSL (Предметно-ориентированный язык) техника для высокоуровневого описания чего-либо (конфигурации, UI, баз-данных). С помощью DSL можно решить множество проблем бизнеса (и множество создать). Дмитрий поговорит об этой теме, раскроет нюансы sourcemaps и расскажет, как в два счёта реализовать свой язык с их поддержкой. А также как легко и просто трансформировать AST, даже если вы никогда с ним не работали и ничего не знаете про sourcemaps.


Чем хорош спикер: Является автором собственного инструмента для работы с DSL.


Чем хороша тема: DSL недооцененная техника: во многом как раз из-за сложности написания инструментов для исполнения этих самых языков. В данном докладе, будет показан инструмент, который упрощает жизнь.



Зачем OCaml на фронтенде, Дмитрий Коваленко


Возможно, вы слышали о таких технологиях, как ReasonML/Resсript и bucklescript. Всё это OCaml на фронтенде. Но как всё это работает? Как OCaml компилируется в JS? Почему это круто? Всё это вы узнаете в данном докладе.


Чем хорош спикер: Дмитрий один из немногих людей, использующих OCaml на практике.


Чем хороша тема: Про Ocaml много кто слышал, но мало кто представляет, что это такое и чем он замечателен. Если вы хотите разнообразить свои знания мира языков транспилируемых в JS и узнать (а возможно и подсесть на) что-то новое вам сюда.



Strict Types in JavaScript, Виктор Вершанский


Говорят, что JavaScript динамически типизированный. А если хочешь другой типизации, надо использовать что-то вроде TypeScript, который не заставляет писать без ошибок типов в runtime.


Но что, если это не совсем так? Что, если можно у чистого JS заставить его runtime работать с типами по всей строгости и получать связанные с этим ошибки? Если вы думаете, что это невозможно нам есть о чём поговорить.


Чем хороша тема: Такое решение еще никто не представлял, это самый эксклюзивный доклад из всех возможных.


Кому будет полезно: Всем, кто:


  • задумывался про проблему строгой типизации в рантайме
  • устал ловить TypeError в рантайме
  • хочет поломать мозг неординарными решениями


How to outsmart time: Building futuristic JavaScript applications using Temporal, Ujjwal Sharma


Почти 25 лет JS-разработчики страдали каждый раз, когда нужно было что-то сделать со временем и датой. Было сломано много костылей, сорвано много подорожников, и прожжено много стульев. И вот, наконец, будущее наступило: появилось долгожданное Temporal API, которое позволяет работать с временем и датой, как все давно мечтали. Уджвал Шарма покажет, как это всё работает.


Чем хорош спикер: Данный спикер помогает разрабатывать этот стандарт (ТС39 делегат) и внедряет его в браузеры.


Чем хороша тема: Поскольку текущий Date API не слишком хорош, разработчики подключают внешние библиотеки для работы с датами вроде date-fns, moment, luxon и тд. Temporal предложение для самого языка, это будущий стандарт работы с датами.




Микрофронтенды


Микросервисы, которые делаем мы, Олег Сметанин


Олег представит обзор способов проектирования микросервисов, API, использования шаблонов и паттернов взаимодействия; DevOps и тестирования на основе обобщения опыта проектирования и аудирования приложений с микросервисной архитектурой для разных индустрий: финансы, ритейл, ресурсы. Вы узнаете, как использовать TypeScript/NestJS для реализации микросервисов под NodeJS для cloud-native-приложений и как применять TypeScript/React для фронта.


Чем хорош спикер: У спикера большой опыт в построении больших систем с высокой нагрузкой.


Чем хороша тема: Доклад по построению больших микросервисных систем. Обосновываются причины использования тех или иных инструментов. Обзор технической, функциональной, DevOps архитектуры, построение карты микросервисов, организация доставки приложения на примере нескольких крупных проектов.



Микрофронтенды на модулях и веб-компонентах, Юрий Караджов


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


Чем хорош спикер: У докладчика есть интересное мнение, отчасти затрагивающее вопрос, поднятый Павлом Чертороговым на прошлой HolyJS. Умеет и готов обсуждать архитектурный паттерн с разных неожиданных сторон.


Чем хороша тема: Доклад про лёгкий и прозрачный способ внедрения микрофронтендов. Анализ преимуществ и недостатков. Практическая применимость и подводные камни для популярных фреймворков.



One logic to rule them all, from clot to wire, Владимир Минкин


Презентация концепции Strings API с библиотекой Wire для создания веб и мобильных приложений, которые повторно используют бизнес-логику в языке Dart. Цель этого доклада: продвинуть идеи создания программных систем, состоящих из плагинов отдельных компонентов и блоков, которые можно тестировать индивидуально, визуально и в модульных тестах.


Разделение ответственности это не новая идея и того же можно добиться с помощью уже существующих инструментов. Разница с Wire заключается в том, что он предоставляет простой и семантически красивый API с четким разделением задач на уровне API-библиотеки: общение в одном месте, данные в другом. В докладе будет уделено внимание архитектуре систем визуального ПО и тому, что всё это MVC, а также архитектуре Flux.


Чем хорош спикер: Владимир обладает хорошим опытов разработки приложений в ООП стиле. Автор библиотек. Имеет опыт боевой опыт разработки на Dart и Haxe. Он может помочь зрителю посмотреть на разработку под другим углом.


Чем хороша тема: Эта тема напрямую касается практических аспектов разработки больших приложений. Это очень полезно нашим зрителям, так как выходит за рамки документации и учить принимать иненерсные решения. В докладе описан подход, который перекликается с первоначальным представлением об ООП




Основы


Напомни через минуту, или Как считать время в браузере, Никита Дубко


Пришла как-то к разработчику Мефодию задача: показывать через заданное пользователем время попап с напоминалкой, что время прошло. Написал Мефодий setTimeout, запушил, тикет закрыл. А пользователь так и не дождался своей напоминалки.


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


Чем хорош спикер: Обладает огромным опытом выступлений и предоставил очень интересную тему


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



Оптимизация синхронной асинхронности, Дмитрий Махнев


Дмитрий Махнёв хочет показать проблему обманчивости простоты async/await на реальном кейсе и приблизительные пути решения и профиты от этого.
Что вас ждет в докладе:
очевидное нахождение проблемы синхронной асинхронности в реальной задаче (индексе сайта);
удивительно неправильная попытка решения;
героическое ускорение примерно на порядок без переписывания на Rust;
неловкая ситуация с unhandledRejection, пролетающей сквозь try/catch;
пара полезных абстракций.


Чем хорош спикер: Дмитрий ранее состоял в программном комитете HolyJS, работает в JetBrains. Увлеченный инженер, выступающий за фундаментальный подход ко всему.


Чем хороша тема: async/await, которого боялись несколько лет назад, стал чем-то обыденным, повседневным, повсеместным. Раньше у нас был callback hell, then hell. Нет, await hell не выглядит чем-то страшным для читабельности кода. Он в определённых ситуациях критически влияет на производительность. Дима на собственном примере покажет, как правильно работать с async-await.



Machine Learning and JavaScript. Unleashing the power of sentiment analysis, Artur Nizamutdinov


Если вы работали с ML на Python и хотите перенести часть опыта в браузер (или не имели дела с МL, но очень хотите попробовать) приходите на доклад Артура Низамутдинова. Он покажет на живом примере, для каких задач можно использовать машинное обучение в браузере, и разберёт дообучение моделей.


Чем хорош спикер: У Артура сильная экспертиза. А еще он сильно переработал доклад конкретно для нашей аудитории. Так что тут будут не просто знания, а знания, поданные именно для слушателей конференции


Чем хороша тема: ML сейчас почти так же моден, как JavaScript. И этот доклад совмещает в себе эти два мира, показывая на практическом примере, для каких задач мы можем использовать ML в браузере.




Визуальное


Анализ больших географически распределенных данных через визуализацию на карте, Никита Швыряев


Доклад основан на опыте построения трёх систем для бизнес-анализа географически распределенных данных. В основном доклад будет построен вокруг использования библиотеки Mapbox GL JS. Рассмотрим востребованную функциональность, осветим проблемы и решения во многих задачах (от загрузки данных до кластеризации). Целевая аудитория JS-разработчики, которые работают или планируют работать с визуализацией на карте.


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


Чем хороша тема: В докладе рассматриваются практические примеры построения архитектуры для анализа больших географически распределённых данных через визуализации на карте. Рассматриваются паттерны, которые не стоит использовать при работе с картами, кратко вводится необходимая терминология.



Как отобразить 100500 метрик распределенной системы и не сойти с ума, Андрей Гончаров


Представьте распределённый кластер из 100 машин. Каждая собирает по 100 разных метрик. А теперь представьте график со всеми метриками сразу. Получилось? Вот и у Hazelcast не получилось. Поговорим, что делать, когда хочется показать много и сразу в условиях ограниченного экранного пространства и конечного числа глаз пользователей. Вспомним, что такое интеграл. Вместе посмотрим, чем он может быть лучше арифметического среднего и медианы.


Чем хорош спикер: Андрей работает в компании, которая оперирует огромным количеством машин и метрик на них. Задача правильного и, что самое главное, доверительного отображения метрик первостепенная.


Чем хороша тема: Любой бизнес любит метрики продуктовые, технические. Почти любой разработчик знает что такое медиана, 75, 90, 95 перцентиль. Правда, не всегда понятно пора бежать чинить, мы горим. Андрей расскажет, как можно обрабатывать метрики, чтобы они лучше отображали существующую картину.



Браузерный игровой движок как pet-проект, Михаил Реммеле


Михаил расскажет о своем опыте работы над pet-проектом. Игровой движок штука достаточно сложная, это огромный источник всевозможных задач и очень нетипичный опыт. Писать его можно бесконечно долго. Интересующие темы могут меняться, но в таком проекте всегда можно подобрать подходящую для исследований задачу. Технологии в данном случае: JavaScript, WebGL, Webpack.


Чем хорош спикер: Опыт работы в геймдеве, крайне редкий среди спикеров JS-конференций. Опыт разработки собственного игрового движка под браузер.


Чем хороша тема: Не распространённый, а возможно и редкий опыт в мире фронтенда. В докладе будет рассказано как автор с нуля написал свой игровой движок и с какими архитектурными сложностями столкнулся.




Заключение


Доклады это хорошо. Но напомним, что HolyJS не сводится только к тому, чтобы сидеть и слушать:


Спикерам можно будет задавать вопросы в чате во время доклада и в Zoom-созвоне после него.
Можно общаться с другими зрителями в чате конференции и на нашей виртуальной площадке.
На виртуальных стендах партнёров можно будет узнать больше о самих компаниях, послушать мини-доклады и поучаствовать в активностях.


Напоминаем, HolyJS пройдет с 20 по 23 апреля в онлайне. Вся информация и билеты на сайте.

Подробнее..
Категории: Javascript , Typescript , Vuejs , Vue , Блог компании jug ru group , Accessibility , Graphql , A11y , Holyjs , Holyjs2021piter

NextMind Dev Kit обзор первого нейроинтерфейса реального времени

02.02.2021 18:09:11 | Автор: admin

Мечта об управлении компьютером силой мысли вот уже более полувека будоражит умы людей. Еще с 1960 года специалисты DARPA рассматривали возможность симбиоза человека и компьютера. Казалось бы, задачка элементарная: считать электрический сигнал от мозга, сформировать на его основе команду и исполнить ее на компьютере. Но даже на первом этапе возникают очень большие сложности. Дело в том, что сигнал от мозга настолько слабый, что его требуется усиливать почти в 20000 раз.

Собрать такую схему сейчас не проблема, но тут возникает еще один существенный нюанс. Для того, чтобы снять полезный сигнал с кожи головы, необходима как можно большая площадь контакта датчиков. При малой площади контакта неизбежно начнут возникать проблемы из-за резкого увеличения сопротивления. Полезный сигнал просто не будет различим на фоне шумов.

В идеальном варианте голову следует побрить, но для большинства людей такой способ неприемлем. Для традиционного снятия электроэнцефалограммы (ЭЭГ) без бритья волос используются специальные гели с высокой электропроводностью. Маловероятно, что кому-то захочется для использования нейроинтерфейса каждый раз мазать голову гелем.

Еще одна проблема возникает при интерпретации сигналов. В отличие от компьютера, где сигналы цифровые, наш мозг способен выдавать только слабые электрические колебания с определенными частотами, реагируя тем самым на различные события. Такими событиями могут быть визуальная стимуляция и фокусировка внимания. Распознавание мозговых волн от этих двух событий и лежит в основе нейрогарнитуры NextMind. Взглянем на устройство поближе и посмотрим, как разработчики решили все эти проблемы.

Внешний вид устройства



Нейрогарнитура поставляется в красивой черной коробочке с зеленой полосой посередине. Внутри находится сама гарнитура, крепление на голову и кабель для зарядки USB Type-C. Обмена данными по кабелю не происходит, так что это реально только для зарядки. Связь с гарнитурой осуществляется по Bluetooth.

Соединение гарнитуры с креплением на голову выполнено по принципу обычной прищепки. Слегка отжимаем верхнюю часть с логотипом, вставляем пластиковую вставку крепления и отпускаем. На этом все гарнитура надежно закреплена. Такой способ явно предполагает использование разных вариантов крепления на голову, в том числе и совместно с VR/AR-очками.


На прилегающей к голове стороне расположено 9 вертикально расположенных электродов, имеющих по три степени свободы (наклоняются влево-вправо, вверх-вниз и ход вниз-вверх). Без этого невозможно обеспечить плотное прилегание. Каждый электрод на конце раздваивается, что создает 18 полос контакта. Что удивительно, визуально электроды пластиковые, на ощупь слегка напоминают soft-touch покрытие. Металл с кожей головы по факту не контактирует. Могу лишь предположить, что тут используется токопроводящий пластик.


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

Первое включение и калибровка


Прежде всего необходимо скачать программное обеспечение с официального сайта проекта. Пока что оно там присутствует только для Windows и MacOS. Вместе с менеджером приложений и SDK для Unity там есть некоторое количество демок, которые мы, разумеется, протестировали на себе. После запуска дашборда NextMind Manager запускаем их и переходим в раздел Setup&Calibrate. Пришло время выполнить сопряжение с нейрогарнитурой.


Устройство имеет только одну кнопку. Короткое нажатие на нее включает и выключает гарнитуру. Длительное нажатие в течение 4 секунд инициирует процесс соединения. У белого светодиода три режима работы. В рабочем режиме он горит постоянно. В процессе сопряжения Bluetooth медленно моргает, а когда ждет подтверждающего нажатия моргает быстро.

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


Теперь надо добиться идеального прилегания электродов к скальпу, медленно и плавно покачивая гарнитуру, сдвигая ее вверх-вниз. Сложность в том, что детектор реагирует медленно и каждый раз после смещения надо выждать секунду, до того как все 8 точек загорятся сначала красным, а затем сменят цвет на зеленый в точках, где контакт идеален. Достаточно миллиметрового сдвига, и все точки сначала пропадают, затем снова становятся красными и только потом зелеными.

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


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


Система по итогу оценивает ваш результат от 1 до 5. Сразу скажу, что если вы получите 3 и менее, то рекомендую сразу повторить калибровку, чтобы не портить себе дальнейший опыт. Менять положение головы, двигать руками/ногами и разговарить в момент калибровки нельзя. Вы должны четко видеть круг и не сводить с него глаз. Получив оценку 4 или 5, можно себя проверить на трех кругах и запускать приложения.


Brain like a DJ


Первое демо, которое стоит попробовать, Music Composer. На экране есть геометрические фигуры, сгруппированные по типу инструмента. Это классический лупер, где можно включать или выключать закольцованный трек выбранного инструмента. Достаточно сконцентрироваться на любой фигуре точно так же, как в процессе калибровки, и она начнет играть музыку. Если честно, для меня это был шокирующий и ни с чем не сравнимый опыт. Настоящая техномагия, если можно так выразиться.


Что интересно, вероятность ошибки практически нулевая, мне ни разу не удалось включить элемент, на котором я не концентрировался. Так что можно с уверенностью сказать, что каждая геометрическая фигура вызывает определенный паттерн в визуальной коре, который четко считывается нейрогарнитурой. Было бы интересно узнать, за счет чего конкретно формируется этот паттерн.

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

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

Brain like a TV Remote control


Еще одна крутейшая демка управление телевизором. Есть несколько коротких видеороликов, имитирующих телеканалы и простой интерфейс управления по углам экрана. Клик мозгом на каждый из углов открывает панели, в которых есть кнопки. Слева переключение телеканалов, а справа Пауза и Выключение/Включение звука.


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

Плюсы и минусы


Постараюсь быть максимально объективным и перечислю все плюсы и минусы использования этой нейрогарнитуры. Начнем с положительных моментов:

  • Действительно позволяет управлять компьютером и техникой силой мысли.
  • Потенциально интересно разработчикам, особенно тем, кто уже делает приложения и игры на Unity.
  • Имеет красивый футуристичный дизайн.
  • Пригодно для людей разных профессий от архитекторов до музыкантов.
  • Длительное время работы (эта кроха спокойно работает 8 часов нон-стоп).

Теперь о минусах, их тут тоже немало:

  • Устройство имеет достаточно высокую цену (текущая стоимость $400) и пока не продается в России. Для сравнения, тот же Neurosky Mindwave стоит всего $110, хотя отечественные перекупщики продают его в 2-3 раза дороже.
  • Будет неудобно использовать людям с длинными волосами. В идеале, видимо, лучше быть лысым или с короткой стрижкой.
  • Пока требуется частая калибровка (с новыми прошивками обещают поправить).
  • Долго носить такую штуку неудобно, эргономика еще требует доработки.
  • Нет софта. Демо-версии это круто, но по-настоящему этот гаджет станет востребованным только тогда, когда будет написано достаточное количество приложений.
  • Люди с плохим зрением вряд ли смогут его использовать, все-таки четко прослеживается только визуальная стимуляция мозговой деятельности (хотя допускаю, что ошибаюсь, я не медик).

Подводя итог, можно сказать только одно: такое устройство действительно шаг в будущее. Это не просто красивый концепт, а цельное, законченное устройство, которое уже неплохо работает и выполняет заявленные функции. Оно применимо для весьма широкой аудитории не только с практической, но и с развлекательной точки зрения. В играх нейрогарнитура дает новый, интересный опыт. Это чем-то похоже на то, когда первый раз взял в руки контроллеры Nintendo Wii Remote или PlayStation Move.

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

Подробнее..
Категории: Мозг , Гаджеты , Блог компании selectel , Будущее здесь , Accessibility , Носимая электроника , Будущее наступило , Nextmind , Нейрогарнитура

Парсинг логов при помощи Fluent-bit

25.03.2021 18:04:40 | Автор: admin

Не так давно передо мной встала задача организации логгирования сервисов, разворачиваемых с помощью docker контейнеров. В интернете нашел примеры простого логгирования контейнеров, однако хотелось большего. Изучив возможности Fluent-bit я собрал рабочий пайплайн трансформации логов. Что в сочетании с Elasticsearch и Kibana, позволило быстро искать и анализировать лог-сообщения.

Цель туториала: организовать логгирование docker контейнеров. Также необходимо структурировать записи логов, и обеспечить поиск и фильтрацию по их полям.

Кому интересно, добро пожаловать под кат)

Необходимы базовые знания bash, docker-compose, Elasticsearch и Kibana.

Обзор используемого стека

Тестовое приложение будем запускать с помощьюdocker-compose.

Для организации логгирования воспользуемся следующими технологиями:

  • fluent-bit- осуществляет сбор, обработку и пересылку в хранилище лог-сообщений.

  • elasticsearch- централизованно хранит лог-сообщения, обеспечивает их быстрый поиск и фильтрацию.

  • kibana- предоставляет интерфейс пользователю, для визуализации данных хранимых в elasticsearch

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

Подготовка тестового приложения

Для примера организуем логгирование веб-сервера Nginx.

Подготовка Nginx

  1. Создадим директорию с проектом и добавим в нее docker-compose.yml, в котором будем задавать конфигурацию запуска контейнеров приложения.

  2. Определим формат логов Nginx. Для этого создадим директорию nginx c файлом nginx.conf. В нем переопределим стандартный формат логов:

    user  nginx;worker_processes  1;error_log  /var/log/nginx/error.log warn;pid        /var/run/nginx.pid;events {    worker_connections  1024;}http {    include       /etc/nginx/mime.types;    default_type  application/octet-stream;log_format  main  'access_log $remote_addr "$request" '                  '$status "$http_user_agent"';access_log  /var/log/nginx/access.log  main;sendfile        on;keepalive_timeout  65;include /etc/nginx/conf.d/*.conf;}

  3. Добавим сервисwebв docker-compose.yml:

    version: "3.8"services:  web:    container_name: nginx    image: nginx    ports:      - 80:80    volumes:      # добавляем конфигурацию в контейнер      - ./nginx/nginx.conf:/etc/nginx/nginx.conf

Подготовка fluent-bit

Для начала организуем самый простой вариант логгирования. Создадим директорию fluent-bit c конфигурационным файлом fluent-bit.conf. Про формат и схему конфигурационного файла можно прочитатьздесь.

  1. Fluent-bit предоставляет большое количество плагинов для сбора лог-сообщений из различных источников. Полный список можно найтиздесь. В нашем примере мы будем использовать плагинforward.

    Плагин выводаstdoutпозволяет перенаправить лог-сообщения в стандартный вывод (standard output).

    [INPUT]    Name              forward[OUTPUT]    Name stdout    Match *

  2. Добавим в docker-compose.yml сервисfluent-bit:

    version: "3.8"services:  web:    ...  fluent-bit:    container_name: fluent-bit    image: fluent/fluent-bit    ports:      # необходимо открыть порты, которые используются плагином forward      - 24224:24224      - 24224:24224/udp    volumes:      # добавляем конфигурацию в контейнер      - ./fluent-bit/fluent-bit.conf:/fluent-bit/etc/fluent-bit.conf

  3. Добавим настройки логгирования для сервисаweb:

    version: "3.8"services:  web:    ...    depends_on:      - fluent-bit    logging:      # используемый драйвер логгирования      driver: "fluentd"      options:        # куда посылать лог-сообщения, необходимо что бы адрес         # совпадал с настройками плагина forward        fluentd-address: localhost:24224        # теги используются для маршрутизации лог-сообщений, тема         # маршрутизации будет рассмотрена ниже        tag: nginx.logs  fluent-bit:    ...

  4. Запустим тестовое приложение:

    docker-compose up

    Сгенерируем лог-сообщение, откроем еще одну вкладку терминала и выполним команду:

    curl localhost

    Получим лог-сообщение в следующем формате:

    [    1616473204.000000000,    {"source"=>"stdout",    "log"=>"172.29.0.1 "GET / HTTP/1.1" 200 "curl/7.64.1"",    "container_id"=>"efb81a754706b1ece6948072934df85ea44466305b326cd45",    "container_name"=>"/nginx"}]

    Сообщение состоит из:

    • временной метки, добавляемой fluent-bit;

    • лог-сообщения;

    • мета данных, добавляемых драйвером fluentd.

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

 docker-compose.yml fluent-bit    fluent-bit.conf nginx     nginx.conf

Кратко о маршрутизации лог-сообщиний в fluent-bit

Маршрутизация в fluent-bit позволяет направлять лог-сообщения через различные фильтры, для их преобразования, и в конечном итоге в один или несколько выходных интерфейсов. Для организации маршрутизации используется две основные концепции:

  • тег (tag) - человеко читаемый индикатор, позволяющий однозначно определить источник лог-сообщения;

  • правило сопоставления (match) - правило, определяющее куда лог-сообщение должно быть перенаправлено.

Выглядит все следующим образом:

  1. Входной интерфейс присваивает лог-сообщению заданные тег.

  2. В настройках фильтра или выходного интерфейса обязательно необходимо указать правило сопостовления, которое определяет выполнять обработку данного лог-сообщения или нет.

Подробнее можно прочитать вофициальной документации.

Очистка лог-сообщений от мета данных.

Мета данные для нас не представляют интерес, и только загромождают лог сообщение. Давайте удалим их. Для этого воспользуемся фильтромrecord_modifier. Зададим его настройки в файле fluent-bit.conf:

[FILTER]    Name record_modifier    # для всех лог-сообщений    Match *    # оставить только поле log    Whitelist_key log

Теперь лог-сообщение имеет вид:

[    1616474511.000000000,    {"log"=>"172.29.0.1 "GET / HTTP/1.1" 200 "curl/7.64.1""}]

Отделение логов запросов от логов ошибок

На текущий момент логи посылаемые Nginx можно разделить на две категории:

  • логи с предупреждениями, ошибками;

  • логи запросов.

Давайте разделим логи на две группы и будем структурировать только логи запросов. Все логи-сообщения от Nginx помечаются тегом nginx.logs. Поменяем тег для лог-сообщений запросов на nginx.access. Для их идентификации мы заблаговременно добавили в начало сообщения префикс access_log.

Добавим новый фильтрrewrite_tag. Ниже приведена его конфигурация.

[FILTER]    Name rewrite_tag    # для сообщений с тегом nginx.logs    Match nginx.logs    # применить правило: для лог-сообщений поле log которых содержит строку    # access_log, поменять тег на nginx.access, исходное лог-сообщение отбросить.    Rule $log access_log nginx.access false

Теперь все лог-сообщения запросов будут помечены тегом nginx.access, что в будущем позволит нам выполнять фильтрацию логов описанным выше категориям.

Парсинг лог-сообщения

Давайте структурируем наше лог-сообщение. Для придания структуры лог-сообщению его необходимо распарсить. Это делается с помощью фильтраparser.

  1. Лог-сообщение представляет собой строку. Воспользуемся парсеромregex, который позволяет с помощью регулярных выражений определить пары ключ-значение для информации содержащейся в лог-сообщении. Зададим настройки парсера. Для этого в директории fluent-bit создадим файл parsers.conf и добавим в него следующее:

    [PARSER]    Name   nginx_parser    Format regex    Regex  ^access_log (?<remote_address>[^ ]*) "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<status>[^ ]*) "(?<http_user_agent>[^\"]*)"$    Types  status:integer

  2. Обновим конфигурационный файл fluent-bit.conf. Подключим к нему файл с конфигурацией парсера и добавим фильтр parser.

    [SERVICE]    Parsers_File /fluent-bit/parsers/parsers.conf[FILTER]    Name parser    # для сообщений с тегом nginx.access    Match nginx.access    # парсить поле log    Key_Name log    # при помощи nginx_parser    Parser nginx_parser

  3. Теперь необходимо добавить файл parsers.conf в контейнер, сделаем это путем добавления еще одного volume к сервису fluent-bit:

    version: "3.8"services:  web:    ...  fluent-bit:    ...    volumes:      - ./fluent-bit/fluent-bit.conf:/fluent-bit/etc/fluent-bit.conf

  4. Перезапустим приложение, сгенерируем лог-сообщение запроса. Теперь оно имеет следующую структуру:

    [  1616493566.000000000,  {    "remote_address"=>"172.29.0.1",    "method"=>"GET",    "path"=>"/",    "status"=>200,    "http_user_agent"=>"curl/7.64.1"  }]

Сохранение лог-сообщений в elasticsearch

Теперь организуем отправку лог-сообщений на хранения в elasticsearch.

  1. Добавим два выходных интерфейса в конфигурацию fluent-bit, один для лог-сообщений запросов, другой для лог-сообщений ошибок. Для этого воспользуемся плагиномes.

    [OUTPUT]    Name  es    Match nginx.logs    Host  elasticsearch    Port  9200    Logstash_Format On    # Использовать префикс nginx-logs для логов ошибок    Logstash_Prefix nginx-logs[OUTPUT]    Name  es    Match nginx.access    Host  elasticsearch    Port  9200    Logstash_Format On    # Использовать префикс nginx-access для логов запросов    Logstash_Prefix nginx-access

  2. Добавим в docker-compose.yml сервисы elasticsearch и kibana.

    version: "3.8"services:  web:    ...  fluent-bit:    ...    depends_on:      - elasticsearch  elasticsearch:    container_name: elasticsearch    image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2    environment:      - "discovery.type=single-node"  kibana:    container_name: kibana    image: docker.elastic.co/kibana/kibana:7.10.1    depends_on:      - "elasticsearch"    ports:      - "5601:5601"

На текущем этапе структура проекта выглядит следующим образом:

 docker-compose.yml fluent-bit    fluent-bit.conf    parsers.conf nginx     nginx.conf

Финальную версию проекта можно найти в репозитории.

Результаты

Благодаря структурированию лог-сообщений мы можем фильтровать их по различным полям, к примеру:

  • показать только лог-сообщения запросов;

  • показать лог-сообщения запросов с http статусом 404;

  • отображать не все поля лог-сообщения.

Пример фильтрации логов. Выполнена фильтрация по значению поля "status", так же выбраны только необходимые в данный момент поля.Пример фильтрации логов. Выполнена фильтрация по значению поля "status", так же выбраны только необходимые в данный момент поля.

Всем спасибо! Надеюсь туториал был полезен.

Подробнее..
Категории: Визуализация данных , Системное программирование , Devops , Nginx , Accessibility , Docker-compose , Elasticsearch , Kibana , Fluent-bit

Цифровая доступность пять ключевых проблем в интерфейсах. Совместный вебинар Яндекс.Практикума и Валерии Курмак

05.05.2021 16:05:29 | Автор: admin
13 мая Яндекс.Практикум вместе с Валерией Курмак проводит открытый вебинар Цифровая доступность: пять ключевых проблем в интерфейсах. Вебинар будет полезен дизайнерам и разработчикам интерфейсов, которые хотят научиться проектировать доступно.



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

На вебинаре слабовидящий Дима Глюз покажет на примерах, какие барьеры он встречает в интерфейсах. А руководитель продуктового дизайна Яндекс.Практикума Сергей Кудинов и руководитель фронтенд-разработки Давид Роганов расскажут, как не создавать такие барьеры при проектировании.

Ведущая


Валерия Курмак член Strategic Leader in Accessibility Initiative в IAAP, автор образовательного курса по цифровой доступности, автор телеграмм-канала об инклюзивном дизайне Не исключение.

Спикеры


Дима Глюз слабовидящий пользователь с диагнозом нейропатия Лебера.

Сергей Кудинов руководитель продуктового дизайна Яндекс.Практикума, www.sergeikudinov.com

Давид Роганов руководитель фронтенд-разработки Яндекс.Практикума.

Вебинар пройдёт 13 мая в 19.30 (Мск). Регистрация.
Подробнее..
Категории: Разработка веб-сайтов , Веб-дизайн , Accessibility , Яндекс.практикум , Блог компании яндекс.практикум , Доступность сайта

Перевод Доступность на iOS началась с 36 секунд

27.05.2021 16:21:56 | Автор: admin

8 июня 2009 года Фил Шиллер выступил на WWDC. Всего 36 секунд он неловко говорил о VoiceOver, Zoom, White on Black (с iOS 6 называется Invert Colors) и Mono Audio. Это были первые реальные специальные функции на платформе iPhone OS, как её тогда называли. Однако, они не произвели большого впечатления 36 секунд закончились, а потом не было никакой демонстрации или аплодисментов, и Шиллер просто перешел к описанию приложения Nike+.

Но в сообществе людей с проблемами зрения всё было иначе. Казалось, что время остановилось где-то после 1:51:54. Произошло нечто совершенно удивительное, и только несколько человек, казалось, понимали, что это значит.

Примечание. Статья переведена и адаптирована в качестве поддержки книги Миши Рубанова Про доступность iOS. Надеемся, что статья поможет вам глубже погрузиться в мир доступности и начать разрабатывать доступные приложения. В этом и поможет книга. Первые четыре главы уже доступны на сайте. Остальные будут выходить в канале Dodo Mobile. Подписывайтесь.

Что произошло 8 июня 2009 года

8 июня 2009 года Фил Шиллер два часа выступал на WWDC. В 1:51:54, после того, как он продемонстрировал голосовое управление и новое приложение Compass, на экране появился логотип Apple accessibility фигура в виде пряника с вытянутыми руками и ногами, которая используется по сей день.

Мы также очень заботимся о доступности.

Сказал Шиллер, и слайд переключился на экран настроек iPhone с перечислением функций доступности: VoiceOver, Zoom, White on Black (с iOS 6 называется Invert Colors) и Mono Audio.

36 неловких секунд и всё кончилось: никакой демонстрации или аплодисментов. Доступность не произвела большого впечатления, и от первых реальных специальных функциях на платформе iPhone OS, Фил перешёл к описанию приложения Nike+.

Но в сообществе людей с проблемами зрения всё было совсем по-другому. Время, казалось, остановилось где-то после 1:51:54 на видео. Произошло нечто совершенно удивительное: одни были вне себя от радости, другие сомневались, третьи пребывали в шоке.

У всех возникли вопросы: смогут ли теперь пользоваться iPhone люди, которым он был недоступен? Спустя 10 лет мы знаем ответ теперь у Apple лучшая мобильная доступность. Но всё это происходило не сразу, и не каждый шаг на этом пути был верным. Я бы хотел рассказать об этом пути.

В дополнении к моему аудио-документальному фильму 36 секунд, которые изменили все: как iPhone научился говорить, я собрал список основных этапов доступности iOS за последние 10 лет. Я сосредоточился на аппаратном обеспечении и ОС Apple. Обновления приложений Apple и сторонние приложения, которые открыли двери для новых способов использования iOS, тоже важны, но с ними список будет слишком длинным. Поэтому, за некоторыми исключениями, я обратился к особенностям доступности iOS. Многие основные функции имеют специальные приложения и преимущества, даже если они не подходят напрямую.

2007-2009: до появления iPhone

В 2007 году на Mac всего пару лет было доступно ПО для чтения экрана для людей с проблемами зрения Mac Screen Reader. Это теперь он называется VoiceOver, а в 2005 его представили как Tiger версии 10.4. До Tiger ни одна версия Mac OS X не предоставляла инструменты доступности.

Поэтому немного пользователей Mac с проблемами зрения были настроены услышать что-то кардинальное на MacWorld Expo в 2007 году. До Mac OS X Apple действительно предлагала несколько настроек доступности, и программу для чтения с экрана от сторонних разработчиков.

Источник: https://www.macintoshrepository.org/2483-outspoken-8Источник: https://www.macintoshrepository.org/2483-outspoken-8

Некоторые энтузиасты технологий с проблемами зрения перешли на Mac после прихода VoiceOver с Tiger. Именно они больше всего интересовались, будет ли доступен iPhone.

Потому что в 2007 году среди покупателей iPhone не было людей с проблемами зрения iPhone был им недоступен. Многие люди, как незрячие, так и зрячие, полагали, что этого не будет никогда.

В конце концов, как перемещаться по холодному гладкому стеклу без зрения?

Примечание: о проблеме холодного стекла у нас есть перевод статьи Будущее интерактивного дизайна в руках.

Весной 2008 года Apple добавила VoiceOver в iPod Nano. В то же время iTunes на Mac стал доступен для VoiceOver. Старое приложение Carbon раньше не работало с устройством чтения экрана.

Это означало, что незрячий человек теперь мог подключить Nano к iTunes, включить VoiceOver на устройстве, скопировать на него песни и использовать VoiceOver для поиска и воспроизведения.

На самом деле VoiceOver на Nano был серией аудиофайлов, созданных с помощью преобразования текста в речь, которые устройство генерировало, когда вы включали эту функцию в iTunes. Но это было гораздо лучше, чем вообще ничего.

Теперь, когда iTunes стал доступен через Mac, Apple заложила основу для доступности iPhone, сделав возможным для человека с проблемами зрения синхронизировать iPhone со своим компьютером.

Следующая остановка настоящий, доступный iPhone.

2009: iPhone OS 3, 3GS и iPod Touch

Анонс iPhone, которого все ожидали на WWDC 2009, обещал быть грандиозным. Все ждали существенного обновления с длинным списком новых функций, учитывая, что App Store существовал уже год, а за плечами Apple два года разработки. iPhone 3GS был солидным релизом, а iPhone OS 3.0 принесла такие важные и запоздалые достижения, как copy/paste.

Июнь: iPhone OS 3 и 3GS

Поспешное, позднее открытие VoiceOver, Zoom, White on Black и Mono Audio принесло только неопределенность отсутствие демо-версии не внушало доверия. Кроме того, существующие устройства даже не были совместимы с iPhone OS 3.

Чтобы получить доступ, придется подождать и купить iPhone 3GS. Пользователи, которые были довольны или, по крайней мере, смирились со своими телефонами, внезапно обнаружили, что подписались на AT&T и перешли на новый, доступный iPhone.

Как работает VoiceOver

Из четырех новых специальных функций в iPhone OS 3 самой важной была функция VoiceOver. Когда он включен, прикосновение к экрану iPhone заставляло устройство озвучивать то, что было под вашим пальцем: название приложения, пункт меню или кнопки.

Жесты для управления телефоном были изменены по умолчанию. Вместо того, чтобы нажать один раз, чтобы открыть приложение, вы должны нажать дважды, а смахивания теперь нужно выполнять двумя пальцами. Ввод текста на виртуальной клавиатуре осуществлялся сначала выбором (нажатием) клавиши, а затем двойным тапом.

VoiceOver также включал в себя интерфейсное устройство под названием ротор, которое работает немного как контекстное меню. Это один из самых гениальных и недооцененных элементов озвучки. Со временем его важность и функциональность только возросли. Чтобы его использовать, вы кладете два пальца на экран и поворачиваете как ручку громкости у магнитофона, а iOS произносит контекстные опции в ответ.

Источник: https://support.apple.com/ru-ru/HT204783Источник: https://support.apple.com/ru-ru/HT204783

Если, например, вы находитесь в Заметках, эти параметры позволяют читать по строкам, словам или символам, позволяя редактировать текст.

Остальные функции специальных возможностей

  • Масштабирование увеличивает экран iPhone. Pinch-to-Zoom был доступен в оригинальной ОС iPhone, но работал только в некоторых поддерживаемых приложениях, таких как Safari. Общесистемный зум увеличивал экран по всему интерфейсу.

  • Белый на черном (позже переименовали в Инверсию цвета) был своего рода ранним тёмным режимом, выворачивающим экранное изображение наизнанку тёмный фон со светлым текстом. Пользователям с низким зрением, чувствительные к свету, это помогает лучше видеть. Изменение настолько важно, что люди готовы терпеть, что картинки выворачиваются и превращаются в негативные изображения.

  • Моно аудио позволяло пользователю с ограниченным слухом заменить стерео выход на моно так громче и сфокусированнее, весь звук можно передать в то ухо, которое лучше слышит.

Осень: iPod Touch третьего поколения

Следующая возможность получить доступное устройство от Apple появилась с выпуском iPod Touch третьего поколения старые модели не поддерживали iPhone OS 3.

Самым большим недостатком iPod, конечно, было отсутствие навигационных функций, предоставляемых GPS-оборудованным iPhone. Навигация представляла огромный интерес для незрячих пользователей.

Тем не менее, iPod Touch был явно лучшим мобильным устройством с поддержкой Интернета, доступным для людей с ограниченными возможностями, при ограниченном бюджете.

2010: iPad, iBooks, iPod Touch

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

Весна: iPad первого поколения и iBooks

Но ещё одна особенность первого iPad также была интересна людям с ограниченными возможностями чтения iPad был первым устройством Apple, с приложением iBooks и iBooks Store. Можно не только добавить любую книгу Apple на iPad, но и использовать VoiceOver, чтобы прочитать её вслух. Это означало, что если книга не была доступна в шрифте Брайля, на ленте или в другом доступном формате, владелец iPad всё равно мог её изучить.

На iPad первого поколения также показали предварительный просмотр новых функций, которые появятся в iOS 4 осенью. Некоторые из них были новыми жестами VoiceOver, такими как почесывание экрана двумя пальцами для перехода на экран назад.

Осень: iOS 4

Ввод текста одним касанием (Touch typing). Сначала он был представлен как второй режим набора текста на iPad. Сенсорный ввод на виртуальной клавиатуре работает быстрее для пользователей VoiceOver, чем стандартный. Не нужно выбирать, а затем дважды нажимать клавишу на клавиатуре, чтобы ввести её. Теперь это проще: опустите палец на клавиатуру, наведите на нужную кнопку и отпустите палец для ввода буквы под ним. Разделенное нажатие делает сенсорный ввод гораздо эффективнее с помощью VoiceOver. Перейти в такой режим набора можно через ротор.

В iOS 4 добавили веб-ориентированный ротор с определенными опциями для навигации по элементам в Safari. Эта функция в конечном итоге будет свернута в ротор общего назначения, но iOS 4 это то место, где впервые появились веб-опции.

Использование ротора в Safari.Использование ротора в Safari.

Поддержка клавиатуры Bluetooth означала, что слепому пользователю не нужно бороться за ввод текста на виртуальной клавиатуре. С Bluetooth стала возможна поддержка обновляемых дисплеев Брайля.

Дисплей Брайля. Источник: http://com-v.ru/tiflomarket/braille-edge-40/90_m_bild1_brailleedge/Дисплей Брайля. Источник: http://com-v.ru/tiflomarket/braille-edge-40/90_m_bild1_brailleedge/

Количество таких дисплеев, поддерживаемых iOS, увеличивается с каждой версией, и Apple ведет текущий список в Интернете.

С помощью клавиатуры Брайля можно печатать шрифтом Брайля, а необычной. Можно также перевести разговорный интерфейс VoiceOver на шрифт Брайля и передать его через дисплей Брайля: точки выступают из экрана, проведя по нему пальцем можно прочитать предложение. Это позволяет человеку, у которого проблемы и со зрением и со слухом, использовать устройство iOS с VoiceOver. Поддержка дисплеев Брайля продолжает развиваться и по сей день.

Доступность получила важные обновления в iOS 4, некоторые из которых придали легитимность iOS в глазах скептиков, которые предпочитали Windows.

2011: iPhone 4s, Siri и iOS 5

iPhone 4S был первым телефоном с Siri. Это не функция доступности, как таковая, но человек с физической или зрительной инвалидностью может управлять iOS голосом, что быстрее и проще.

Осень: iOS 5

iOS 5 освободила всех пользователей от необходимости настраивать устройство с компьютера, а пользователи VoiceOver получили возможность выполнять свою собственную настройку с помощью программы чтения с экрана. Начать настройку можно было через iTunes, поскольку Mac OS X также включала программу чтения с экрана.

Тройной щелчок. Незрячим людям стало проще благодаря корректировке поведения кнопки Домой. Раньше тройной щелчок вызывал выбор между масштабированием и голосом за кадром. К сожалению, пользователь VoiceOver с проблемами зрения не мог определить нужную опцию. В iOS 5 теперь можно было сделать тройной щелчок во время процесса установки, чтобы вызвать VoiceOver он включался по умолчанию.

Новые голоса стали доступны в iOS 5. Они были улучшенными версиями существующих голосов, что важно, если вы постоянно их используете. Особенно если вы читаете веб-статьи или другой массивный контент.

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

Выбор речи и автотекст. В iOS также добавили эти новые функции речи. При включенном Speak Selection можно выбрать текст в любом месте iOS появившееся меню теперь включает кнопку Speak Selection. Speak Auto-Text делает именно это, когда применяется автокоррекция или автокапитализация. Обе эти функции речи используют тот же выбор голосов, что и VoiceOver можно выбрать голос, который вы хотите использовать, независимо от VoiceOver, и скорость.

VoiceOver Item Chooser также дебютировал в iOS 5. При посещении веб-страницы с множеством ссылок и элементов контента вызовите средство выбора элементов, чтобы вызвать алфавитный список элементов на странице. Если знаете, что вам нужно, вводите текст, чтобы сузить поиск. Затем дважды коснитесь элемента, который хотите выбрать.

Средство выбора элементов экономит время при навигации по знакомому сайту. В качестве альтернативы выбору элементов для пользователей Bluetooth-клавиатуры также был добавлен ряд веб-специальных сочетаний клавиш VoiceOver, например, набрав H (от heading) на подключенной клавиатуре можно переходить по заголовкам

Обнаружение лиц. Дебютировало в iOS 5 в приложении камеры. При включенном VoiceOver наведите устройство на объект или объекты, и VoiceOver покажет, сколько лиц видит камера и где они находятся в кадре.

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

Метки. Добавили пользовательскую маркировку VoiceOver, которая позволяет пользователю присваивать метку элементу управления в приложении без метки разработчика. Многие приложения частично доступны для VoiceOver люди могут перемещаться и пользоваться с помощью скринридера, хотя одна или несколько кнопок или других элементов управления могут не иметь названий, потому что разработчик этим не озаботился. Пользовательская маркировка позволяет компенсировать этот недостаток.

Особенности слуха

Вибрация. iPhone, конечно, всегда поддерживал пользовательские мелодии звонка, но iOS 5 принесла шаблоны вибрации. Если у вас есть проблема со слухом или вы просто хотите пофантазировать с вибрационными паттернами для отдельных абонентов, выберите один из них или наберите свой собственный.

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

Новый режим слухового аппарата. Позволил устройствам iOS лучше работать со слуховыми аппаратами Bluetooth. Это было началом расширенной поддержки слуховых аппаратов, которая расцветет в более крупную инициативу Made for iPhone для слуховых аппаратов. Начиная с iPhone 5, они сертифицированы как совместимые со слуховыми аппаратами (Hearing Aid Compatible, HAC) Федеральной комиссией по связи США.

2012: iOS 6

Выпуск iOS 2012 года включил специальные возможности в одну совершенно новую категорию физическую доступность. AssistiveTouch была первой функцией iOS, которая поддерживала тех, у кого были трудности с эффективным выполнением жестов из-за задержки движения.

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

Осень: iOS 6

Home-Click Speed. Позволяла пользователю регулировать чувствительность кнопки Home, что облегчало человеку с моторной задержкой эффективное нажатие на неё. Guided Access даже получил демо-версию WWDC Keynote.

Контекстные действия в iOS 6. У некоторых элементов появились дополнительные действия. Чтобы переключиться на них проведите пальцем вверх или вниз, двойное нажатие выполняет действие. Например, так можно пометить письмо как прочитанное или удалить. Это немного похоже на использование ротора VoiceOver, но без необходимости делать жест открытия ротора.

Карты. Получили серьезное обновление в iOS 6. Pause to Follow позволяет найти и выбрать улицу, а затем провести пальцем когда вы слышите Pause to Follow.

Применение Pause to Follow на карте.Применение Pause to Follow на карте.

Действие даёт представление в каком направлении проходит дорога, и насколько она прямая или извилистая. Звуковая обратная связь направляет, когда вы идете по улице, и визуально подсвечивается для людей с низким зрением. Ротор VoiceOver также включал в себя пункт Точки интереса позволяющий пользователю пролистывать близлежащие важные и интересные места, чтобы найти конкретный объект или просто просмотреть свое окружение.

Guided Access. Новинка в iOS 6. Позволило ограничить доступ к элементам iOS, например, отключить кнопки громкости или запретить пользователям доступ к определенным приложениям. Управляемый доступ позволяет учителям сосредоточить внимание учащихся, часто детей со спектром аутизма. Вызовите управляемый доступ и свободно передайте ученику iPad, который может запускать только то образовательное приложение или обучающую игру, которую вы хотите использовать. Также можно замаскировать кнопки или другие элементы интерфейса в выбранном приложении.

AssistiveTouch. AssistiveTouch делает ключевые элементы управления устройствами доступнее.

AssistiveTouchAssistiveTouch

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

2013: iOS 7

Apple лихо переработала внешний вид интерфейса iOS и практически всех своих собственных приложений. Сквеоморфизм исключили, а тонкие шрифты, прозрачные слои и анимация добавили.

Шаг назад с iOS 7

Регресс. Для доступности это был регресс. Особенно для слабовидящих пользователей, которые рассчитывают на высокую контрастность интерфейсных элементов, функции которых очевидны, не требуя острого зрения и визуальной системы отсчета.

Благодаря отрицательной реакции на iOS 7 Apple исправила то, что сломала: откатила первоначальный дизайн ОС и добавила настройки доступности, которые могли бы компенсировать проблематичность определенных элементов дизайна. Например, они включали в себя формы кнопок, уменьшающие движения и метки включения/выключения. Кроме того, iOS 7 представила увеличенную контрастность, полужирный текст и настройку размера шрифта. Они помогли компенсировать проблемы 7.0.

Все выровнялось в iOS 7.1. Это был единственный релиз iOS, созданный специально для слабовидящих пользователей вроде меня.

Более крупный текст используется внутри сообщений.Более крупный текст используется внутри сообщений.

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

FaceTime. Он работает как функция доступности для людей, которые общаются с помощью языка жестов или чтения по губам через видео.

Обновления. iOS 7 представила множество основных обновлений интерфейса, включая Центр управления и усиленный переключатель приложений. Они были сразу же доступны VoiceOver и AssistiveTouch, а также новому интерфейсу управления коммутатором.

Динамичный Текст. Функция Увеличенный текст была доступна в iOS 6, хотя и не сильно повлияла на iOS. Можно выбрать один из шести увеличенных размеров текста и увидеть их в нескольких приложениях, таких как Сообщения или Почта.

Более крупный текст в iOS 7 и поздних версиях это пользовательский интерфейс для Динамичного Текста. Если разработчик поддерживает Динамичный тип в приложении, пользователь может использовать ползунок Размера текста, чтобы сделать его больше или меньше. Даже Apple не поддерживала Динамический тип во всех своих приложениях iOS 7, но постепенно исправила. Многие другие разработчики приняли эту функцию, но не все.

Слуховые аппараты iPhone. Apple никогда не создавала собственные слуховые аппараты, но работала с производителями, чтобы увеличить количество доступных продуктов MFi программу Made for iPhone. Технологические усовершенствования в характеристиках Bluetooth Low Energy (BLE) и согласованные усилия Apple распространили MFi на слуховые аппараты, которые компания начала сертифицировать как совместимые с устройствами iOS.

Субтитры. Фильмы и телепередачи, купленные в iTunes или приобретенные из других источников, можно просматривать с подробными субтитрами или обычными. В iOS 7 появился интерфейс для настройки стиля и размера текста, появляющегося на видео с субтитрами.

Рукописный ввод VoiceOver. Поддержка рукописного ввода VoiceOver позволяет пользователю VoiceOver вводить текст, рисуя печатные текстовые символы пальцем на экране. Есть жесты для обозначения пробела и для обычных знаков препинания. Можно использовать рукописный ввод для поиска приложений на главном экране. Войдите в режим рукописного ввода с ротором, нарисуйте первую букву приложения и iOS найдёт все подходящие. Рукописный текст также можно использовать для навигации по веб-страницам.

Switch Control. AssistiveTouch был частью iOS начиная версии 6. Switch Control расширил идею интерфейса, который поддерживает пользователей с моторными задержками.

Сканирование главного экрана с помощью переключателя управления.Сканирование главного экрана с помощью переключателя управления.

С его помощью мы используем:

  • внешние переключающие устройства, которые представляют собой кнопки с двумя состояниями;

  • сам экран iOS в качестве переключателя или даже камеры: глядя влево или вправо, мы активируем переключатель на основе камеры.

Чтобы работать с переключателями, мы назначаем каждому из них определённую функцию, например нажатие или щелчок влево, открытие Центра управления или вызов Siri. В режиме Управления переключателем iOS сканирует элемент за элементом на экране до тех пор, пока не будет нажат переключатель для активации или иного воздействия на этот элемент.

Многие пользователи Switch Control оснащают свои iOS-устройства несколькими устройствами. А iPad, установленный на инвалидном кресле вместе с переключателями, может создать очень эффективную iOS-установку для человека с тяжелыми двигательными нарушениями.

Быстрый доступ к специальным возможностям. Раньше эта функция называлась Triple-Click Home. Позволяет включать и выключать специальные возможности с помощью тройного щелчка. Теперь на тройное нажатие можно добавить несколько специальных функций. При срабатывании iOS покажет меню из тех, которые вы включили.

2014: iPhone 6 и 6 Plus

Первые большие айфоны включили новую функцию под названием Display Zoom.

Это не функция доступности, но она увеличивает вид экрана, уменьшая разрешение. На экране появляется меньше значков приложений, а на некоторых экранах iOS-текст больше. Масштабирование дисплея можно сочетать с функцией масштабирования специальных возможностей или по отдельности.

Осень: iOS 8

Несколько новых функций в iOS 8 были важны для доступности.

Клавиатура QuickType. Предсказывала текст и отображала панель с предложениями по набору текста над виртуальной клавиатурой.

Новый режим набора текста прямым касанием позволял пользователю VoiceOver положить обе руки на виртуальную клавиатуру и просто начать печатать. QuickType, автокоррекция и собственное ноу-хау VoiceOver вместе помогают исправлять ошибки набора с высокой точностью. Естественно, это экономит много времени и сил, и значительно улучшает набор текста с помощью прямого прикосновения, особенно для пользователей iPad.

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

Использование контроллера масштабирования.Использование контроллера масштабирования.

Алекс. В iOS 8 из Mac OS X пришёл голос Алекс. У Алекса есть естественное звучание дыхания во время разговора, что намного удобнее чтения длинных текстов, чем более старые альтернативы из iOS 5.

Оттенки серого. В iOS 8 появился Режим оттенков серого для некоторых людей отсутствие ярких цветов на экране легче для восприятия.

Обновления Guided Access. Обновления включают таймеры, поддержку активации Touch ID и улучшенный масштаб: новый контроллер масштабирования позволял пользователю выбирать область экрана для масштабирования, регулировать скорость масштабирования и использовать цветовые фильтры для адаптации к дальтонизму.

Ввод с экрана Брайля. Как и функция рукописного ввода, экранный ввод Брайля облегчает ввод текста на экране.

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

Speak Screen. Функция полезна для тех, кто не использует озвучивание текста, но слушает длинные отрывки текста. После включения просто проведите двумя пальцами вниз от верхней части экрана, чтобы его содержимое, например, электронная почта было произнесено. Speak Screen помещает на экран всплывающее меню с возможностью изменения скорости чтения, перемещения вперед или назад, остановки и начала речи.

Экран Speak используется внутри Safari.Экран Speak используется внутри Safari.

2015: Apple Watch и iOS 9

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

3D Touch. Функция появилась на новых iPhone в iOS 9. Несмотря на альтернативные голосовые жесты и необходимость сильно нажимать, чтобы вызвать 3D Touch, пользователи VoiceOver с поддерживаемыми телефонами получили доступ к жестам 3D Touch первого уровня, а также Peek и Pop.

Многозадачность iPad. Появились новые жесты, которые позволяли пользователю VoiceOver работать с Split View или Slide Over. Опять же, пользователи специальных инструментов могли пользоваться новыми инструментами прямо из коробки.

С точки зрения доступности iOS 9 не выдающаяся версия. Но в ней появились новые настройки для людей с физическими недостатками, а также некоторые обновления VoiceOver. Вот исчерпывающий список обновлений, связанных с VoiceOver.

Touch Accommodation. Эта новая функция позволяет пользователю регулировать чувствительность сенсорного экрана и время касания. Полезно для людей с моторными задержками, которые случайно активируют предметы прикосновением или нуждаются в более чувствительном действии для регистрации движений пальцев.

Поведение клавиатуры. Новые опции позволяли пользователю с ограниченными физическими возможностями управлять тем, как аппаратная клавиатура реагирует на их прикосновения.

Switch Recipes для Switch Control. При использовании управления переключателем каждый переключатель выполняет одну функцию. Функция Switch Recipes эффективно позволяет пользователю создавать комбинации действий.

Изменения Ротора выбора текста VoiceOver. Изменения в роторе VoiceOver облегчили выбор текста по символу, слову, строке или странице.

2016: iOS 10

Изменения в iOS 10 в основном косметические. Но не все.

Транскрипция голосовой почты. Безусловно, эта функция имеет дополнительную ценность для пользователей с нарушениями слуха, для которых сортировка голосовой почты проще чем текстовые указания.

Новый редактор произношения. Позволяет произносить или вводить имя так, как его должен произносить VoiceOver, и сохранять правильное произношение. А с VoiceOver audio routing можно передавать звук на устройство по вашему выбору, например на Bluetooth-динамик. Теперь Switch Control позволяет пользователям управлять устройствами, подключенными к устройству iOS, включая Apple TV.

Описание изображения VoiceOver. iOS 10 позволяла выбрать изображение на фотографиях или в потоке сообщений и заставить VoiceOver описать его характеристики. Конечно, VoiceOver это не алгоритм на основе машинного обучения, поэтому получались описания, например, одно лицо, размытое, темное или чёткое, хорошо освещенное.

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

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

Цветовые фильтры. iOS предлагала переключение оттенков серого с iOS 8, но теперь появились цветовые фильтры, предназначенные для настройки вида экрана в зависимости от потребностей пользователей с тремя распространенными формами дальтонизма.

Программное обеспечение TTY. Пользователи iPhone всегда могли подключать свои телефоны к TDD (телекоммуникационное устройство для глухих) если у них был соответствующий аппаратный адаптер. Начиная с iOS 10, можно звонить или отвечать на звонок TTY без допоборудования, а также сохранять стенограммы звонков.

2017: iOS 11

iPhone X первое iOS-устройство без кнопок Home. Это повлияло на доступность: отсутствие кнопки Home изменило жесты по умолчанию, используемые для таких вещей, как open Control Center или App Switcher.

Face ID. Но не только из-за этого стало хуже Face ID создал проблемы для некоторых незрячих пользователей.

iOS 11 была первой версией iOS, которая поддерживает устройства Face ID. Некоторые люди с ограниченными возможностями, особенно незрячие и с протезами глаз, не могут уделять необходимое внимание датчику Face ID. Поэтому iOS добавила переключатель, который позволяет разблокировать телефон без зрительного контакта. Из-за этого Face ID вызывает споры в сообществе людей с проблемами зрения из-за предполагаемого риска безопасности. Также некоторым слепым пользователям трудно заставить Face ID работать.

Однако функция всё равно полезна. Переключатель Require Attention, который включен по умолчанию (функция безопасности) предотвращает разблокировку телефона, если он просто проходит перед лицом своего владельца. Выключение этого переключателя позволяет большему количеству незрячих людей разблокировать телефон с помощью Face ID. Но пользователь потенциально рискует получить телефон разблокированным без их согласия. При настройке устройства, оснащенного Face ID, с помощью VoiceOver пользователю предлагается оставить его включенным или выключить.

Новые возможности. iOS 11 также принесла несколько новых и обновленных версий специальные возможности, например, поддержку VoiceOver для перетаскивания и специальные жесты VoiceOver для владельцев iPhone X. VoiceOver также добавил новый метод перемещения приложений, который был частью iOS 10. Теперь можно использовать ротор для выбора и перетаскивания нескольких приложений в любое место на любом домашнем экране.

Смарт-инверсия цвета. Invert Colors появились ещё в iOS 3, и отображали всё как обратное нормальному внешнему виду. Но Smart Invert Colors отображает изображения как положительные, а не отрицательные, до тех пор, пока рассматриваемое приложение поддерживает его.

Вы все еще можете выбрать между Invert Colors и Smart Invert Colors и добавить их в ярлык специальных возможностей.

Но меню или фон некоторых приложений неправильно отображаются в цветах, контрастирующих с текстом или значками поверх них в режиме Smart Invert Colors. Это даже иногда происходит в приложениях Apple.

В основном это проблема разработчиков, которые не задумывались как будет вести себя их интерфейс и изображения при включенном Smart Invert Colors. Сочетание этих двух проблем причина того, что ни одна из опций инвертирования не работает как эффективный тёмный режим для iOS. Из того, что я видел, тёмный режим предлагает разработчикам возможность использовать затемнение и слои для настройки внешнего вида интерфейса. Это может быть полезно и для пользователей Smart Invert Colors, а также для общего понимания того, что люди, не имеющие слабого зрения, пытаются использовать iOS в тёмном режиме.

Type to Siri. Если вы не можете говорить или это неудобно, Type to Siri даёт возможность выдавать команды Siri с клавиатуры. Можно печатать с виртуальной, с Bluetooth-клавиатуры или в шрифте Брайля с дисплея Брайля.

2018: iOS 12

Все выпуски iOS содержат ошибки. Пользователи специальных возможностей часто находят те, которые относятся к функциям, что они используют каждый день и ждут, пока Apple их исправит, например, когда шрифт Брайля и VoiceOver глючили в iOS 11. Но, как и iOS в целом, iOS 12, казалось, исправила много проблем доступности и добавила некоторые новые функции.

Shortcuts. Автоматизация задач с помощью голосовой команды или нажатия одной кнопки дает большие преимущества доступности для людей со всеми видами проблем. Интерфейс для создания ярлыков также полностью доступен.

Живое Прослушивание. Уже некоторое время можно использовать микрофон iPhone как усилитель окружающего звука, посылая звук на слуховой аппарат. В iOS 12 функция Live Listen была расширена до AirPods. Теперь можно слышать собеседника даже если вокруг шумно.

2019: iOS 13

Доступности уделили много внимания на WWDC 2019. Вот несколько важных особенностей.

Голосовое управление. Последняя и совершенно новая функция специальных возможностей, анонсированная для iOS 13, а также Mac OS Catalina, имеет очень старое название. До появления Siri в iOS была функция голосового управления (и до сих пор существует). Но можно было только инициировать телефонный звонок или воспроизвести песню с помощью голосовой команды.

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

Тёмный режим. Мы не знаем всех различий между грядущей основной функцией тёмного режима и Smart Invert Colors. Apple заявила, что разработчики смогут использовать многоуровневый подход к своим интерфейсам, так что не все экраны или их части должны будут иметь одинаковый тёмный оттенок. Выглядит как улучшение по сравнению со Smart Invert Colors. Если разработчики будут тщательно применять слои, тёмный режим может стать подходящей альтернативой умным инвертированным цветам для некоторых людей с плохим зрением, которые его используют.

Итог

Если вы измеряете доступность iOS по количеству доступных сегодня функций, 2009 год кажется примитивным временем. В тот год на программном слайде WWDC Фила Шиллера появилось всего четыре пункта. Но один из них VoiceOver точно революционизировал реальную доступность на iPhone почти сразу.

Несмотря на то, что Apple продолжала делать большие и маленькие обновления для доступности в течение последних 10 лет, они почти неизвестны большинству, кто отслеживает прогресс платформы. Apple по-прежнему удаётся удивлять и расширять возможности новых групп людей, создавая инструменты, необходимые этим людям.

Полезные материалы:

Статьи по VoiceOver:

Voice Control и VoiceOver: как адаптировать приложение для незрячих или неподвижных.

VoiceOver на iOS: каждый контрол ведёт себя по-разному.

VoiceOver на iOS: решение типовых проблем.

Другие полезные:

Зачем и как мы пишем постмортемы по критичным багам.

Будущее интерактивного дизайна в руках.

Как выйти на китайский рынок с mini-app для WeChat, чтобы не прогореть.

На пути к 10x инженеру: шорткаты, сниппеты, шаблоны.

Подписывайтесь на Dodo Engineering chat в Телеграм будем обсуждать статью, и на канал там новости и разное интересное.

Подробнее..
Категории: Разработка мобильных приложений , Разработка под ios , Usability , Iphone , Accessibility , Ios , Macos , Приложения , Блог компании dodo engineering , Dodopizzaengineering , Доступность , Dodo

Помощь многим Android-приложение для людей с особыми потребностями

26.02.2021 20:18:58 | Автор: admin

Приветствую всех! Я Беглецов Глеб, учусь в 11 классе, летом прошлого года закончил программу IT Школа Samsung в г. Санкт-Петербург на площадке ФМЛ 239 под руководством Левина Михаила Константиновича. В качестве выпускной работы я разработал приложение, которое назвал Parus. Это мой первый большой проект под Android, и он мне принес ГРАН-ПРИ финала Всероссийского конкурса IT Школы Samsung (ролик). Хочу поделиться историей создания этого проекта.

Идея

Я иногда слышал среди своих одногруппников в IT Школе Samsung подобную фразу: Я не знаю, какое приложение мне написать. У меня не было сомнений. Моё приложение должно помочь людям с особыми потребностями полноценно общаться с миром, потому что данная проблема актуальна и в нашей стране, и в мире. И меня она лично касается. Есть много отдельных приложений: для синтеза речи, для искусственного зрения, для напоминаний и т.д. Мне хотелось объединить всё необходимое в одном приложении.

Начало

Учиться в IT Школе Samsung я начал в сентябре, а в начале ноября уже знал, какой проект буду разрабатывать. Но это же классика, откладывать всё на последний момент! В итоге апрель и май выдались очень напряженными. В тоже время это было очень увлекательное время. Я просыпался, кодил с перерывами на еду, ложился спать, просыпался и снова кодил, если не учился в школе. Вот такой был распорядок дня в течение двух завершающих месяцев обучения. Узнавал каждый день что-то новое. Несколько раз было такое: понимал, что написанное не годится и переписывал половину уже сделанной работы. Тогда, как понимаете, было не очень весело.

К началу апреля я освоил основы Java и Android. А за следующие два месяца добавил синтез речи, распознавание речи, компьютерное зрение, отслеживание пульса, создание ежедневных напоминаний (не todo list), связь аккаунтов человека с особыми потребностями и его помощником, чат и передачу данных между ними. Дальше подробнее про каждую функцию.

Говорить. Синтез речи

Данная функция помогает общаться людям с нарушением речи . Сам синтез речи самая лёгкая задача из всех. Подключил TextToSpeech и готово. Но такой функционал не слишком удобен для пользователя, поэтому я решил сделать систему частых фраз и тематические коллекции. Вот с этим уже начались первые проблемы.

Создавая систему коллекций и частых фраз, я не знал о существовании Snapshotов (обновление данных в реальном времени), поэтому обновление данных у меня было реализовано, как я позже понял, через очень шаткие костыли. Я читал данные из БД каждый раз, когда там, гипотетически, могли измениться какие-либо поля. И такая система была реализована ВЕЗДЕ. Вот это и был один из тех моментов, когда, узнав про что-то новое и полезное, обрадовался, а затем взялся за переписывание всего кода.

Смотреть

Компьютерное зрение должно помогать людям со слабым зрением распознавать текст или объект на фото. Но не всё так идеально, как хотелось бы. Firebase Ml Vision удобен и практичен, но бесплатная версия не распознает русский язык, а результаты распознавания объекта иногда выглядят по меньшей мере странно.

Вообще, при реализации многих задач мне очень помог Firebase, отличный инструмент. Для компьютерного зрения я поначалу попробовал использовать Tesseract, потому что была возможность подключить к нему файл с русским алфавитом для распознавания кириллицы. Оказалось зря. Потратив только на его установку в проект около недели, текст с русскими буквами так и не распознавался. Поэтому я стал искать другие варианты. И тут меня спас Firebase Ml Kit, который я настроил в 5 раз быстрей! Firebase даёт очень много плюшек, и без него я вряд ли бы всё сделал. По неопытности, конечно, не сразу все получалось, но я разобрался. Для текущей задачи пока я использую API от Firebase. Может, в будущем найду что-то более подходящее.

Слушать

Просто распознавание речи с помощью SpeechRecognizer API от Google и вывод результата на экран.

Пульс. Google Fit vs Samsung Health SDK

Отслеживание пульса полезная функция для людей с сердечными заболеваниями. С помощью неё пользователь может следить за своим сердцебиением. При обработке данных, если пульс вне нормального интервала (55 < x < 90), то на устройство приходит уведомление об этом.

Но над этой задачей тоже пришлось попыхтеть. Сначала разобрался, как читать данные из Google Fit. Потом прочитал про Samsung Health SDK и решил перейти на него. У S Health SDK есть очень удобное дополнение Data Viewer. С его помощью можно записывать данные в S Health без каких-либо трекеров. Это очень помогает при тестировании приложения, в этом SDK от Samsung выигрывает у GoogleFit. Также не надо делать привязку к аккаунту и подключать QAuth от Google, тоже плюс.

Но если Google Fit может встроить в свой проект любой желающий, то для использования Samsung Health необходимо, чтобы приложение получило статус партнёрского. Без такого статуса приложение будет полноценно работать только в режиме разработчика. К сожалению, на данный момент приостановлен приём заявок на статус партнёрского приложения в связи с обновлением партнёрской программы. Поэтому я был вынужден вернуться обратно к GoogleFit.

Напоминания

Я знаю, что существует множество приложений по типу todo list, но, как говорится, это другое Во-первых, пользователь может установить несколько часов (12:50, 13:10 и 18:30, например) на одну задачу. Во-вторых, есть возможность установить напоминанию интервал времени и повторение: с 12:00 до 20:00 каждый час, например. Напоминания каждый день перезагружаются и начинают всё по новой, как обычный будильник. Это может быть полезно людям, которым надо каждый день сделать что-то важное. Например, люди с диабетом могут установить время для инсулиновых уколов.

Безусловно, что человек может установить множество будильников, которые будут выполнять ту же задачу. Моя программа просто упрощает это. Для напоминаний с 9:00 до 21:00 с регулярностью в полчаса, необходимо установить либо 24 обычных будильника, либо 1 напоминание с интервалом в Parus. Думаю, что второй вариант легче.

Напоминания не сильно тратят заряд батареи, потому что они реализованы за счёт WorkManagerов. Я долго думал между Alarm и WorkManager, потому что первое слишком сильно нагружает телефон и батарею (+на некоторых телефонах ограничен), а второе имеет один весомый минус из-за сверхоптимизации напоминание может не отобразиться, если телефон долго находился в режиме сна. Я около 100 раз протестил данный случай, и 3-5 раз напоминание не срабатывало до выхода из режима сна. На сайте Android developers читал, что Google работает над этим, так что буду надеяться, что скоро это исправят.

Связь с помощником

Это одна из главных функций моего приложения. У человека с ограниченными возможностями здоровья не всегда получается справляться со всеми жизненными ситуациями самостоятельно, поэтому иногда есть человек, который выполняет роль помощника. С ним происходит много коммуникаций, и поэтому я считаю, что очень важно упростить это взаимодействие.

  • Передача данных
    Помощнику будет спокойнее, если он будет иметь информацию о пульсе своего подопечного и его местоположении. Кроме того, помощник может редактировать в приложении напоминания человека с ограниченными возможностями здоровья. А еще всегда можно посмотреть, когда связанный пользователь заходил в последний раз в Parus.

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

  • Чат
    Иногда случается так, что твой помощник это не родной и не близкий человек, а волонтёр или социальный работник. Чтобы не общаться с ним в различных мессенджерах, можно общаться с ним отдельно в чате Parusa.

Samsung Android Bootcamp. Заключение

Выше я описал основные возможности своего приложения на момент участия в конкурсе выпускных проектов IT Школы Samsung. Я совсем не упоминал архитектуру приложения или паттерны, которые я использовал. Знаете почему? Потому что этого не было на момент финала конкурса. Проект состоял из классов, разложенных по пакетам. И всё. Я подозревал, что это ужасно, но не знал, как исправить. И тут нам сказали, что сразу после конкурса пройдет летний Android Bootcamp для выпускников IT Школы Samsung. Я решил, что мне явно туда.

За две недели интенсива я узнал безумно много полезных вещей. Например, зацепился за MVVM + Data Binding + Material Design. Стало понятно, что Parus выпускать в таком виде нельзя. Предстоящая работа: сначала архитектура, потом дизайн, после чего можно и в Google Play. В августе уже не было такого запала, как в конце весны, к середине сентября я почти переделал всё под MVVM архитектуру и все

С октября по январь я ни разу не открыл Android Studio. Мне совсем не хотелось программировать и вообще как-либо доделывать свой проект. Одним словом, пропал весь энтузиазм. Я начал думать, что на самом деле проект ни о чём, что я не способен сделать достойное приложение. Не знаю из-за чего, наверное я устал и понял, что доводить проект до идеального состояния можно бесконечно.

Прошел Новый год. Parusa так и нет в Google Play. Я открыл Android Studio и вдруг почувствовал, что есть силы завершить проект. Я дал себе обещание, что в феврале Parus появится в Play Market. За две недели доделал всё, что планировал, и 4 февраля загрузил проект в Google Play.

Вот такая история моего первого большого проекта. Да, Parus не идеален, но у меня получилось довести его до законченного состояния. Надеюсь, что он окажется полезным кому-нибудь. Буду рад, если вы скачаете приложение и напишете свои предложения. Особенно, если вы моя целевая аудитория - человек с особыми потребностями или заботитесь о таком человеке.

Спасибо, что прочитали статью до конца.

Пока!

Глеб Беглецов

Ученик 11 класса, школа Озерки

г. Санкт-Петербург

Подробнее..
Категории: Разработка под android , Android , Accessibility , Здоровье , Блог компании samsung , Помощь , Слабовидящие , Слабослышащие , It школа , Школьный проект

5accessibilityинструментов вChromeDevTools

29.11.2020 14:18:58 | Автор: admin

Введение

Если вы хотите повысить доступность вашего сайта, но думаете, что для этого необходимо что-то устанавливать или разбираться с каким-то сервисом, товот подборкаиз 5 инструментов, которые доступны вбраузреChrome, и с помощью которых можно быстро определить наличие проблем с доступностью.

Небольшой дисклеймер, я знаю, что многие из вас активно пользуютсяDevTools, тем не менее, я напомню, что для открытияDevToolsудобно использовать сочетание клавишCmd+Shift+ C /Ctrl+Shift+ C.

Accessibilityinspector.

Помимо DOM браузер строитAccessibilityTree(AOM,AccessibilityObjectModel) или Дерево специальных возможностей (чуть подробнее тут). СоответственноAccessibilityinspectorпозволяет просматривать информацию в этом дереве, аналогично тому, как вы просматриваете структуру DOMдевера, во вкладкеElements.

По большей части AOM содержит информацию из ARIA иroleатрибутов, именно с помощью них программы экранного доступа пытаются определить предназначение DOM элемента.

Найти этот и инструмент можно во вкладкеElements, в дополнительной вкладкеAccessibility.

Accessibilityinspector в DevToolsAccessibilityinspector в DevTools

Эмулятор плохого зрения.

С помощьюDevToolsвы можете понять, как видят ваш сайт пользователи с различными нарушениями зрения.

Для того чтобы включить эмуляцию проблем со зрением откройтеDevTools, кликните на три точки на верхней панели. В выпадающем списке выберете менюMoretools, дальшеRendering. В низу откроется дополнительная панель, прокрутите ее до самого конца, там будетпукт Emulatevisiondeficiencies.

Результат работы эмулятора плохого зренияРезультат работы эмулятора плохого зрения

На момент написания статьиDevToolsэмулирует следующие нарушения:

  • Нечеткое зрение

  • Протанопияищи цветовая слепота (помните такие тесты в ГИБДД где среди кружочков необходимо увидеть цифру?)

  • Дейтеранопия - частичная цветовая слепота, в основном к зеленому цвету.

  • Тританопия- частичная цветовая слепота обычно в синежёлтых, фиолетовокрасных цветов.

  • Ахроматопсия илидальтонизм - полная цветовая слепота

Я думаю, очевидно, что данный список не в полной мере покрываетпроблеммысо зрением, возникающие у отдельных людей, тем не менее размещая текст на каком-то цветном фоне, стоит проверить его читабельность..

Lighthouseумеет находить очевидные проблемы на вашем сайте, в том числе и проблемы с доступностью. Поскольку в данной статье мы рассматриваем только доступность, то отключим все остальное и протестируемХабрна наличие проблем сAccessibility.

Настройка и результат работы Lighthouse на сайте habr.comНастройка и результат работы Lighthouse на сайте habr.com

Lighthouseпроверяет такие вещи как:

  • ARIA - атрибуты

  • ROLE - атрибуты

  • Контраст

  • Langатрибуты в HTML

  • Tabindexна формах

  • Наличие описания в атрибутахalt

  • И многое другое

Если посмотреть отчет, то основные проблемы в том, что не все ссылки и кнопки подписаны, а на некоторых картинках отсутствует описание в атрибутеalt. Это значит, что незрячий пользователь будет слышать что-то вроде ссылка, кнопка,изображение, без понимания предназначения данного элемента на странице

Контрастность

Когда речь заходит о доступности контраст очень важен. Это можно понять, если применить эмуляцию не четкого зрения.

Чтобы понять, насколько элемент выделяется от фона вDevToolsесть специальный инструмент, который может проанализировать контраст определенного элемента.

Что узнатькоэфициентконтрастности какого-либо элемента необходимо открытьDevTools, затем выберете любой текстовый элемент, и найдите CSS свойствоcolor

Инструмент измерения контрастности в DevToolsИнструмент измерения контрастности в DevTools

Если посмотреть на скриншот, то можно выделить три основных показателя:

  • текущее значение контраста

  • Минимально допустимое значение контраста (АА)

  • Достаточно значение контраста (ААА)

Inspectelementtooltip

Последний инструмент в сегодняшнем списке, в целом дублирует функциивыше описанныхинструментов. И самое главное, если вы открываетеDevToolsс помощью горячих клавиш, то он сразу активен. Так же его можно активировать кликнув по кнопке спинктограммойстрелки в верхней панелиDevTools.

InspectelementtooltipInspectelementtooltip

ВInspectelementtooltipвыводится сводная информация о выделенном элементе, в том числе общая информация по доступности.

Заключение

Готовя статью, я наткнулся на цитату, которая отлично передает мое отношение к вопросу доступности сайтов

Доступность не обязана сразу быть идеальной, она просто должна быть немного лучше, чем вчера.Леони Уотсон на FronteersConf

Спасибо за внимание, надеюсь, эти инструменты помогут вам сделать ваши проекты чуть доступнее.

Подробнее..
Категории: Разработка , Браузеры , Accessibility , Web , Google chrome , Chrome devtools , Доступность

3 года программирования вслепую. Часть 2

04.04.2021 20:17:04 | Автор: admin

Всем доброго времени суток! Продолжаю свой рассказ о том, как "Войти в IT" без подгляда. Прошлая часть была посвящена, в основном, обучению. В этой больше расскажу о работе.


Поиск и подготовка


Фриланс я рассматривал в основном как простой способ входа в профессию. Так что после начального обучения переключился на поиск постоянной работы. Задачи там казались мне более интересными, а атмосфера основательней и лучше подходящей для развития.


К тому моменту я успел хорошо освоить symfony framework. html и js также не вызывали затруднений. А вот с css был знаком только в теории.
При наличие пары глаз поблизости рано или поздно, безусловно, можно выполнить любую задачу. К тому же для скринридеров существуют плагины, помогающие в позиционировании и не только. Но трудозатраты, в любом случае, были бы неоправданно высоки. Так что я сосредоточился на бекенде самой доступной части веб-разработки. Где незрячий может выполнять все задачи самостоятельно и наиболее полно себя проявить.


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


Еще на первых уроках видеокурсов по php преподаватель перечислил множество редакторов кода, имеющих форматер, подсветку синтаксиса, автодополнение и многое другое. Но они все оказались недоступны. Я ставил и сносил sublime, brackets, visual studio code ни одна из них не работала со скринридером. Скачивал и PHPStorm, потыкался в неозвучиваемый экран установки, после чего снес и его. Notepad++ вроде бы был доступен, хоть и очень относительно. Еще была visual studio, но она вообще не помогала в работе с php. Так что после долгих поисков я остановился на akel pad. В нем не было ничего. Но он был быстрым. Что ж, этого хватило для обучения, но дальше надо было искать что-то другое.


Я снова прошелся по списку редакторов и обнаружил, что за прошедшее время visual studio code "обрел голос". Ранее фокус скринридера просто упирался в молчащее окно программы, сейчас же интерфейс озвучивался как обычная веб-страница с привычными горячими клавишами навигации.
К тому моменту отступы по всему проекту уже были успешно расставлены с помощью php-cs-fixer.


По окончании рефакторинга я возобновил изучение рынка. Мною рассматривались только удаленные вакансии. Это решало проблему поездок в офис и не ограничивало меня бедным локальным рынком. В итоге через несколько недель откликов и собеседований я получил предложение о работе.


Первая работа


Компания занималась разработкой веб-проектов под заказ. Ей требовался middle symfony разработчик. Миддлом на тот момент я еще, разумеется, не был. Но ключевые слова, перечисленные в вакансии, были знакомы. Да и наниматель готов был пойти навстречу. Трудности, однако, стали возникать сразу...


Первой из них был докер. О нем до того момента я только слышал. Сейчас же наш проект требовалось с его помощью поднять локально. Много ли усилий нужно, чтобы выполнить в консоли docker-compose up? В моем случае это заняло неделю.


Проблема заключалась в том, что у меня стояла windows 7. windows самая дружественная для незрячих ОС. Она давно и успешно обжита, для нее есть хорошо развитые скринридеры, множество синтезаторов речи и прочей инфраструктуры. Но вот докер на ней работал медленно, глючно и через виртуальную машину. Остальные члены команды, работавшие на маке и линуксе, помочь могли с большим трудом. Но в итоге после долгих задушевных переписок в чате проект все же удалось поднять. По ходу этого процесса я узнал о git autocrlf и yarn --no-bin-links.


В перерывах между сеансами укрощения докера я изучал код проекта. Он был построен на api platform. Сильно отличавшейся от всего, что я видел до этого. Контроллеров, например, в проекте не было совсем. Есть у api platform и свои подводные камни. Разумеется, успешно найденные в ходе первых же задач.


Кроме выше указанного на проекте присутствовало много того, что я видел впервые: функциональное тестирование, git flow, code review, ci/cd. Работали мы по скраму, спринтами по 2 недели с ежедневными митингами, управление задачами и учет времени шло в jira, переписка осуществлялась в slack. Освоить это и многое другое нужно было еще вчера.


Тут стоит упомянуть, что ознакомление с новыми инструментами с помощью скринридера в среднем занимает больше времени, чем обычно. Представьте человека, заходящего в новое для себя помещение. Ему достаточно взгляда, чтобы понять, что в центре комнаты стоит стол, справа шкаф. А в дальнем углу находится большая ваза с цветами. Незрячему для получения этой информации придется обойти всю комнату и, возможно, не раз. Так и с освоением новых инструментов. Через какое-то время он запомнит горячие клавиши программы. Узнает, что на этой веб-странице удобнее перемещаться по заголовкам или ссылкам. А вторая по счету неподписанная кнопка в jira открывает нужное меню. Но на все это требуется время. Так что более-менее освоиться у меня получилось только к концу первого месяца. За него я закрыл несколько небольших задач, начал пониматьскрам и прочие процессы, брать чуть больше ответственности и не писать по каждому поводу прикрепленному ментору.


По прошествии первого из трех месяца испытательного срока были подведены итоги. Ментор обозначил все положительные и отрицательные стороны моей работы, HR сказал, что через два-три дня они все проанализируют и примут решение о формате дальнейшего сотрудничества. Я воспринял это как полезную в плане обратной связи формальность. Таких было много в компании. К бюрократии мне тоже нужно было привыкать. Например, отпроситься на два часа в течение рабочего дня с гибким графиком у ПМ было нельзя. Для этого требовалось заполнить специальную форму на корпоративном портале, после чего один из менеджеров должен был заявку утвердить. Но через пару дней HR связался со мной и уведомил, что компания больше сотрудничать не планирует. Работодатель ожидал от меня большего, к тому же в тот момент у меня возникли проблемы со здоровьем. Вообще я чувствовал, что после первоначальных трудностей начинаю выходить на нормальную продуктивность. Но риски для компании перевесили потенциальные преимущества. А значит, у меня оставался всего месяц на то, чтобы впитать в себя как можно больше знаний из этой среды.


В этом плане второй месяц прошел куда более гладко, чем первый. Задач было выполнено больше. По моим ощущениям я вышел процентов на 80 продуктивности среднего члена команды. И целенаправленно работал над тем, чтобы без самой крайней нужды не отвлекать никого из коллег. Что за первый месяц успело сильно утомить ментора.


Работа над ошибками


Опыт первого трудоустройства давал обильную пищу для размышлений. Я приобрел большое количество знаний. Но были и проблемы. В частности, я был не доволен visual studio code. Кроме автодополнения переменных оно практически ничем не помогало при повседневной работе. Большинство разработчиков на предыдущем проекте использовало PHPStorm. И мне сильно не хватало его возможностей. Но в очередной раз установив его, я снова уткнулся в неозвучиваемый экран. После чего написал гневное письмо в поддержку о том, что неплохо бы обеспечить хоть какую-нибудь доступность их продуктов. Однако в ответном письме указывалось, что они вполне доступны уже сейчас.
В итоге я нашел на сайте jetbrains неочевидно расположенную страницу, посвященную accessibility, по инструкциям с которой установил java access bridge и IDE, наконец, заговорила.


Что ж, это и впрямь был качественный шаг вперед по сравнению с visual studio code. Вероятно с помощью плагинов и можно довести функциональность редактора кода до уровня IDE, но для php у меня и близко это не получилось.
Быстрая навигация по всей кодовой базе, очень мощное автодополнение, множество встроенных рефакторингов. Все это давало ощущение полета от процесса разработки. Вот разве что подсветку синтаксиса скринридер у меня так и не озвучил.
Следующие несколько месяцев я снова посвятил своему домашнему проекту, просто наслаждаясь тем, как быстро и легко пишется код.


Свободное плавание


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


Мы связались с менеджером по почте и очень быстро обо всем договорились. У нас даже не было созвона. Вообще так получается, что во всех местах, где я работал, найм проходил в очень простой и деловой атмосфере. От меня хотели узнать, кто я и что умею. Итоговое решение о сотрудничестве принималось быстро.


О том, что у меня проблемы со зрением, разным работодателям я говорил по-разному. Прямое заявление во время интервью, что я слепой, выбивает из колеи большинство интервьюиров. Некоторые люди реагируют в стиле: "Вот это да! Я что-то об этом слышал, можешь объяснить как ты делаешь то и это?" У кого-то возникают опасения по поводу моей работоспособности. Я объясняю, как работаю с компьютером, кидаю ссылки на статьи, где все подробно расписано. Однако на данный момент я стараюсь уведомлять о своих проблемах со зрение в момент, когда мы договариваемся об интервью. Это позволяет всем лучше к нему подготовиться. Еще интервьюиров часто интересует, есть ли какие-то особенности моего взаимодействия с другими членами команды. На что я указываю, что не люблю скриншоты и другую графическую информацию. И обычно прошу передавать ее текстом, хотя с развитием машинного распознавания картинок эта проблема стала менее острой.


Проект, на который я устроился, нужно было реализовывать с нуля. Мы вместе с присоединившимся чуть позже разработчиком создавали систему по ТЗ. Высокая интенсивность работы от нас не требовалась. В целом наш менеджер не был склонен держать процесс разработки под жестким контролем, да и имел постоянную занятость в другом месте. Так что вскоре все технические решения я принимал самостоятельно. Я старался максимально следовать образу разработки, увиденному на предыдущем проекте. CI, code review, функциональное тестирование. Это позволяло нам довольно уверенно двигаться вперед и при этом быть спокойными за тылы.


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


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


В процессе я набирался опыта, изучал новые подходы и инструменты. Безусловно, обладая сейчас большими знаниями кое-какие вещи я бы сделал иначе. Сложные расчеты стоимости услуг лучше было сделать по TDD. А спецификации упростили бы работу с множеством типов пользователей. Однако в целом код на всем протяжении проекта был предсказуемым и поддерживаемым. А вот организационные проблемы нам мешали постоянно.


У менеджера совсем не было времени нами заниматься. Раз в месяц он отчитывался перед заказчиком о текущем состоянии проекта. Причем требования заказчика постоянно менялись и, узнавая это за несколько дней до релиза, мы всякий раз работали в авральном режиме.


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


Тем не менее где-то через полгода после начала разработки мы сдали готовую систему в эксплуатацию. Дальше оставалось заниматься ее поддержкой и небольшими доработками. На это двое разработчиков не требовалось. К тому моменту я защитил диплом и решил искать работу с полной занятостью.


В последнее время


Так окончились первые 3 года моей карьеры. Но я так долго собирался с мыслями для этих двух статей, что с тех портоже прошло немало времени. Прошлой весной я снова стал изучать рынок вакансий. Он показался мне довольно бедным. Быть может все замерли, наблюдая первую ковидную волну, а может весна не самое активное время для найма. Так или иначе, где-то через месяц я нашел место, где работаю и сейчас.
За этот год я научился в юнит тесты. Подружился с докером на WSL. Стараюсь больше читать умных книг, пробовать новые инструменты, подтягивать английский, да и в целом двигаться вперед!

Подробнее..
Категории: Php , Карьера в it-индустрии , Читальный зал , Accessibility , Symfony , Работа в it , Удалёнка

Дискриминация в алгоритмах ML существует и нет, это не либеральные сказки

26.03.2021 18:19:00 | Автор: admin

Человеческий мозг, как мы все знаем, полон предрассудков. Возникает вопрос: если машинное обучение "живет" за счет того, что очень близко имитирует этот наш мозг, то почему его алгоритмы не могут быть такими же необъективными и проявлять такую же несправедливость? К сожалению, они частенько это и делают.

Давайте расскажем вам как именно.

Машинное обучение (ML) это очевидно новая звездочка ИТ индустрии. И она уже никуда не денется. Одна из причин, почему ML сыграет (и уже играет) значительную роль в нашей жизни это успешная интеграция его моделей в большое количество уже существующих систем: социальные сети, шоппинг, здравоохранение и т. д.

В настоящее время в отрасль инновационных технологий хотят идти миллионы школьников, студентов и начинающих специалистов, стремящихся сделать карьеру в этой области. При этом, чтобы успешно обучить следующее поколение профессионалов в этой области, необходимо понять несколько неочевидных сторон машинного обучения.

Давно прошли те времена, когда люди могли слепо доверять программам в получении объективных рассчитанных результатов. Алгоритмы машинного обучения не дают простых математических результатов, как это делает калькулятор, а влияют на прогнозы преступной деятельности, медицинские диагнозы и решения о приеме на работу. Поскольку мир всё больше и больше полагается на машинное обучение при принятии важных решений, важно, чтобы мы узнавали о необъективных сведениях, понимали последствия некорректных результатов модели и принимали превентивные меры.

Так какая предвзятость (bias) есть в алгоритмах машинного обучения?

  • Интеграция машинного обучения в здравоохранение вызвала большие споры, потому что некоторые алгоритмы не могли одинаково лечить всех пациентов. Например, алгоритм обнаружения рака кожи был обучен с использованием данных, включающие в себя в основном фото и информацию о светлых тонах кожи. Следовательно, этот алгоритм был не эффективен при обнаружении рака кожи у людей с более тёмными тонами кожи. Несмотря на то, что у ИИ есть много возможностей повысить доступность медицинских услуг для нуждающихся, важно должны убедиться, что качество медицинской помощи не ухудшается для определенных демографических групп.

  • Хороший пример необъективности распознавания естественного языка (NLP) можно увидеть в социальных сетях: твиты, написанные афроамериканцами, в среднем отмечены алгоритмами ИИ как оскорбительные (хотя на самом деле таковыми не являются, показатель false positive) в 1,5 раза чаще, чем такие же твиты белых.

  • Было обнаружено, что даже более серьёзная предиктивная полицейская система неверно оценивает правонарушителей. COMPAS, система искусственного интеллекта, используемая для прогнозирования вероятности совершения преступником другого преступления, оказалась явно настроенной против афроамериканцев. Получилось так, что у афроамериканцев было вдвое больше ложных предсказаний рецидивизма, чем у белых американцев.

Почему эти признаки необъективности существуют?

Модели машинного обучения изучают закономерности в предназначенных для их обучения данных. Таким образом, если набор данных является стереотипным или не разнообразен, модели могут прийти к ложным выводам. Вот несколько примеров потенциальных ошибок обучения (некоторые из которых действительно произошли):

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

  • Использование данных, которые навязывают стереотип привязанности одного из полов к ряду обязанностей или занятий. Некоторые модели глубинного обучения связывают мужчину с доктором, а женщину с медсестрой из-за вектора представления слов, отображающего социальные стереотипы (word embedding).

  • Использование данных, которым не хватает разнообразия. Да, той самой любимой дайвёрсити. Многие модели распознавания лиц обучаются на данных, которые включают больше белых людей, чем черных. Исследование Тимнит Гебру и Джой Буоламвини показало, что 3 инструмента для распознавания лиц от крупных технологических компаний смогли почти идеально определить пол белых мужчин, а темнокожих женщин определили неверно в 35% случаев. Это может привести к очень серьезным ошибкам правоохранительных органов.

Откуда мы знаем о существовании этой предвзятости?

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

Какие возможные способы решения этой проблемы существуют?

Препятствие, с которым в настоящее время сталкиваются многие компании, заключается в том, что им необходимо переобучить свои модели. Существует два главных способа для того, чтобы это сделать:

  • Ликвидация необъективности наборов данных, используемых моделями это влечёт за собой удаление существующих наборов данных, содержащих стереотипные данные, и создание репрезентации и дайверсити в них, в попытках сделать их более точными.

  • Устранение необъективности моделей. Это влечёт за собой изменение фактических векторных представлений слов для удаления стереотипной привязки (мужчина = доктор, и женщина = медсестра) при сохранении нужной гендерной информации (мужчина = король, и женщина = королева).

Тема является довольно неоднозначной и вовлекает проблемы целого общества, однако путем дискуссий и компромиссов решение может быть найдено. Если у вас есть опыт с темой Этики в ИИ - будет интересно прочитать о нем в комментариях.

Подробнее..
Категории: Искусственный интеллект , Машинное обучение , Big data , Accessibility , Ии , Дискриминация , Этика , Fairness , Машинное+обучение , Bias , Ethics

Фриланс, любовь и инвалидность. Как жить хорошо, когда жить сложно в принципе

06.04.2021 16:12:32 | Автор: admin

Цель этой статьи поделиться своим опытом жизни в сложной ситуации и донести мысль, что любую ситуацию можно улучшить.

Но для начала представлюсь.

Обо мне

Привет! Меня зовут Станислав, мне 32 года, я из Хабаровска. В 2006 году я попал в ДТП, из-за чего получил черепно-мозговую травму тяжелой степени и так Меня признали инвалидом. Сначала слишком тяжелым, потом легче, легче, и легче. На сегодня я инвалид 3 группы 1 степени.

Кстати, на обложке я. Подумал, что лучше всего показать себя.

Несмотря на свое состояние, я таки-женился и живу вместе с женой в частном доме (почти частном на 4 владельца).

В этой статье моя любимая будет комментировать мои слова. Я почти не редактировал ее комментарии вроде, получилось жизненно.

И вот что она говорит о нашем браке.

Маша, моя женаМаша, моя жена

...Я увидела в Стасе сильного харизматичного человека, который не относился к себе как к инвалиду. Мне показалось, что это признак сильной личности. Также я увидела в нем огромный потенциал. Кроме того он очень воспитанный, в тоже время дерзкий и смелый. Он открыто выражает свое мнение и отстаивает свою позицию, не боясь быть отвергнутым или высмеянным. Это то, чего всегда не хватало мне. Я поняла, что с ним я могу быть беззащитной и слабой.

Но спустя 6 лет брака отношение изменилось мои ожидания не совпали с реальностью. Он живет в настоящем моменте и совершает много необдуманных поступков. Иногда бывет очень тяжело и только вера в Бога помогает мне не опускать руки. Я все еще верю в его потенциал, но он никак не может его раскрыть и реализовать. Я молюсь о том, чтобы это произошло и как показывает опыт Бог часто творит чудеса. ...

Финансовое состояние семьи мое больное место, и именно о нем я сейчас расскажу.

Какой у меня доход и из чего он складывается

Слава Богу, у меня есть доход. Если бы я еще и не мог зарабатывать, было бы вообще плохо.

Вот примерная структура моего дохода.

Подробно:

  1. Фриланс. Я автор-копирайтер, то есть пишу статьи для интернет-изданий вроде Хабра. Доход 20-50 тыс., в среднем 30 тыс.

Официально я не работаю считаю этот вид занятости неэффективным в моем случае. Я трудоустраивался несколько раз, но всем работодателям не нравилось, что я работаю медленно (из-за моей травмы). Поэтому лучше трудиться в свое удовольствие и получать гонорар за результат, а не за потраченное время. Пусть меньше денег зато без нервотрепки.

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

  1. Я получаю пенсию 7 800 небольшой такой пассивный доход.

Пенсия это огромное преимущество инвалидов в финансовом плане, потому что пенсия есть постоянно. Плюс она индексируется, идет в ногу с инфляцией.

  1. Аренда. Мы сдаем квартиру и зарабатываем около 4000 .

Итого 31 000 .

Конечно, это мало. Объективно мало. Но зарабатывать мало лучше, чем не зарабатывать вообще и сидеть на шее у своих близких. Я знаю парня, который абсолютно здоров, но не работает и поэтому постоянно ходит в гости к своим знакомым, из-за чего люди к нему плохо относятся. Жалкое зрелище. Я не хочу так.

...Меня очень огорчает то, что Стас мало зарабатывает, потому что на первый взгляд он кажется таким умным, успешным, целеустремленным. Я была уверена, что он умеет зарабатывать. И насколько я могу судить люди из нашего окружения такого же мнения. Но как я уже писала реальность не совпала с моими ожиданиями. Из-за этого я испытывала большое разочарование и недовольство им. Постоянно на него срывалась, устраивала истерики, придиралась по мелочам.

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

Но он молодец все-равно. Самое главное, что он очень хорошо относится ко мне. С мудростью реагирует на мои истерики и критику. Никогда не держит обиду, быстро прощает. Очень внимательный и всегда делает кучу комплиментов. Это заставляет меня улыбаться и чувствовать себя счастливой.

Наша финансовая ситуация далеко не самая простая. Но и не самая сложная. Поэтому я решил сжать *опу и, по возможности, хотя бы что-то изменить.

И вот помощь от государства (довольно актуальная). Что говорит законодательство на какую же помощь я могу рассчитывать?

Федеральный закон о социальной защите инвалидов

(полный текст)

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

Согласно ему я имею право на следующие льготы:

  1. Компенсацию расходов на оплату жилых помещений и коммунальных услуг в размере 50% (статья 17).

  2. Первоочередное получение земельных участков для индивидуального жилищного строительства, ведения подсобного хозяйства и садоводства (статья 17).

  3. Общее образование, профессиональное образование и профессиональное обучение инвалидов в соответствии с адаптированными образовательными программами и индивидуальными программами реабилитации, абилитации инвалидов (статья 19).

  4. Гарантированное трудоустройство путем квоты для приема на работу инвалидов, минимального количества специальных рабочих мест для инвалидов, резервирования рабочих мест по определенным профессиям, наиболее подходящим для трудоустройства инвалидов, стимулирования создания организациями дополнительных рабочих мест для трудоустройства инвалидов (статья 20).

Кстати, люди с ограниченными возможностями обязаны принимать на работу все организации с численностью от 35 сотрудников. Если численность штата компании от 35 до 100, квота на инвалидов не выше 3%, если численность от 100 человек, то квота от 2 до 4%. Если работодатель не выделяет необходимое количество мест для трудоустройства данной категории граждан, его ждет административный штраф.

Кстати, вакансии дата-центра ITSOFT снабжаются на hh специальным значком, если вакансия допускает найм инвалида (смотрите на картинке).

Организации обучения инвалидов новым профессиям (тоже не уточняется, но, подозреваю, что речь идет про какую-то из профессий данного списка).

  1. Пенсию в размере 1 236 рублей.

Почему тогда я получаю 7800, а не 1200? Благодаря помощи государства. Есть даже специальный закон на эту тему.

Федеральный закон "О государственной социальной помощи"

(полный текст)

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

  1. Обеспечение необходимыми лекарствами (по стандартам медицинской помощи, в конкретном объеме уточняйте в местном филиале соцзащиты)

  2. Бесплатное санаторно-курортное лечение с бесплатным проездом к месту лечения и обратно (только если есть медицинские показания).

Я мало ездил в другие города (считанное количество раз). Но после получения инвалидности хоть несколько раз был в санатории. Вроде, хорошо.

Конечно, понимаю, что на Мальдивы мне никто дорогу не оплатит, но хотя бы так. С плешивой овцы хоть шерсти клок :)

  1. Бесплатные топливо, продукты питания, одежда, обувь и лекарства (статья 12).

  2. Доплату к пенсии (статья 12.1) теперь понятно, почему я получаю пенсию 7800?

Это федеральные законы, т.е. справедливые для всей страны. Но важно помнить,что существуют законы отдельных краев, областей, городов - наверняка в них тоже есть много интересного.

И вот, что думает об этом моя жена.

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

Путин нам жить не мешает, дай Бог ему долгих лет жизни. Я считаю, что он хороший президент. По крайней мере лучший из всех, что были до него и получше чем во многих других странах.

Но я бы посоветовала взять пример с президента Швейцарии. Который, чтобы не опоздать на совещание, которое сам и проводит, едет на работу не на машине, а на трамвае, чтоб не застрять в пробках. Вот такая простота.

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

Хотя молодцом я его не считаю. Я думаю, что он старается.

А житель любой страны создает свою реальность сам, и это не зависит от помощи государства. И слава Богу за то, что я это понимаю.

Какие выводы я сделал

Прошло уже 20 лет с момента, когда я стал инвалидом. За это время я получил колоссальный опыт выживания (потому что мне каждый день мне приходится сталкиваться с разными трудностями).

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

  1. Идите в ногу со временем. Учитесь и повышайте квалификацию постоянно.

  2. Будьте фрилансером или организуйте бизнес. Оформите НПД или ИП и получайте оплату только за конкретный результат, и будьте счастливы.

  3. Знайте законы. Даже в самой тяжелой ситуации государство протягивает соломинку помощи. Хоть эту помощь и практически нельзя ощутить, но иногда даже она бывает полезной.

  4. Диверсифицируйте доход (то есть зарабатывайте несколькими способами). И если сами не можете работать, то организуйте себе дополнительный пассивный доход (хотя бы сдавайте квартиру).

  5. Чтобы стать счастливым, нужно постараться. Помощь, льготы это хорошо, но для счастья я явно не достаточно. Поэтому засучите рукава и приготовьтесь работать над своим счастьем.

...Я не обращаю внимания на инвалидность Стаса. Конечно, тяжело, потому что многие простые вещи он делать не может. И мне приходится за ним ухаживать немного больше чем за обычным человеком. Также, когда я болею, это вообще трэш.

Конечно, были мысли о разводе и не раз. Но я не развелась до сих пор в первую очередь потому что нет в этом воли Божьей. Если бы не это может и развелась бы в первые пару лет. Но прошло уже больше шести лет, съеден не один пуд соли, преодолено немало трудностей, мы все еще живы и души друг в друге не чаем.

Вот так и живем. Конечно, я планирую улучшить свою ситуацию, но пока только планирую. Надеюсь, у меня получится.

Вам понравилась статья? Тогда не пожалейте + так я увижу вашу поддержку.

Хотите что-то сказать или пожелать? Тогда вэлкам в комментарии!

Спасибо за внимание!

Подробнее..
Категории: Карьера в it-индустрии , Accessibility , Здоровье , Фриланс , Фрилансеры , Инвалиды , Фрилансер , Блог компании itsoft , Инвалид , Инвалидность

Как не сдаться, начать карьеру в IT и продолжать лечение даже после 15 лет болезни (история инвалида)

16.04.2021 10:20:09 | Автор: admin

Привет! Это снова Станислав М***, реабилитированный инвалид. Рассказываю про свой опыт выздоровления.

Поможет тем, кто инвалид. Также рекомендую рассказывать эту историю тогда, если хотите кого-то вдохновить. Если инвалид сумел преодолеть трудности, то и подавно сможет каждый.

Что со мной

Я переживаю последствия ЧМТ (Черепно-Мозговой Травмы) тяжелой степени тяжести.

Мое заболевание напоминает инсульт, только инсульт это внутреннее кровоизлияние в мозг, а ЧМТ результат внешнего воздействия.

Интересно, что википедия определяет мою болезнь как комплекс контактных повреждений (мягких тканей лица и головы, костей черепа и лицевого скелета) и внутричерепных повреждений (повреждений вещества головного мозга и его оболочек), имеющих единый механизм и давность образования. Но у меня все совсем не так.

Просто головка вава! При этом руки-ноги на месте, лицо не покореженное, вмятин в черепе нет. Интеллект сохранился.

Как появилось это заболевание?

В 17 лет меня сбила машина. Это был 2006 год. Я переходил дорогу с подругой и нас сбил водитель Toyota Town Ace. Шли на зеленый свет, по пешеходному переходу, по правилам. Просто водитель был пьян.

Это я.

А что с девушкой?

Из-за аварии она сломала ногу, но через пару месяцев отошла. Через пару лет уехала в Москву и недавно родила двоих прекрасных детишек (не от меня).

А что с тем парнем, который сбил меня?

Не знаю. Пару лет назад он звонил - пьянющий и страдающий от цирроза печени. Жалко его. Надеюсь, сейчас он жив и с ним все в порядке.

Но ему явно досталось больше, чем мне. После инцидента со мной от него ушла жена, его уволили с работы (а он работал машинистом в РЖД!), от него отвернулись друзья, он спился. Я слышал, что подобные случаи влияют на водителей. Но чтобы настолько

Он заплатил?

Да, но совсем не много.

Он помогал в лечении?

Нет. Сначала просто откупился какой-то незначительной суммой, потом заплатил около 100 000. И все.

И вот сегодня я живу так, как я живу сижу в мягком кресле, пью кофе, пишу статью для Хабра. Просто инвалид...

Какие последствия травмы

Жесткие. Они повлияли как на мое физическое состояние, так и на моральное.

  • У меня угнетенное мышление. Ни с того ни с сего, на ровном месте я начинаю чувствовать себя подавленно, неудачником, ничего не умеющим и ни на что не способным.

  • Ужасная координация. Я не в состоянии делать 2 простейших дела единовременно (идти и разговаривать, завязывать шнурки и говорить). Без затруднений я могу только думать, дышать, молчать и идти в этом я мастер.

  • Замедление движений. Причем настолько сильное, что аж невозможно. Наверное, примерно как у ленивцев. Чтобы вы понимали сложность глубину проблемы: эту статью я писал неделю. Жесть.

  • Кривая походка. Как у алкоголика: ноги заплетаются даже при медленной ходьбе.

  • Скандированная речь. Как будто я говорю в рупор, только тихо.

Самое интересное то, что я только недавно начал осознавать весь ужас моей проблемы. Раньше понимал, что у меня есть дефекты, но не понимал их масштаб. Теперь понимаю.

Как объясняли врачи, нервные импульсы проходят по моему мозгу по усложненным маршрутам. То ли более протяженным, то ли прерывистым. То есть из-за травмы нарушился обычный маршрут импульса, и ему нужно проходить по-другому. Поэтому движения кривые и замедленные.

Травма налагает отпечаток на все сферы моей жизни. Но мне помогают продолжать движение.

Как эти последствия мешают жить, но я жив

Из-за инвалидности я все делаю медленнее, чем остальные люди. Но это, в принципе, не особо смущает никого из моего окружения.

Вот что они говорят.

Маша, моя женаМаша, моя жена

Видно, что Стасу очень плохо. Но он не сдается. Наверное, поэтому я и вышла за него замуж.Его инвалидность мне абсолютно не мешает. Я даже горжусь тем, что мы не такие как все. Воспринимаю это как приключение. Люблю трудности так интереснее жить.Конечно, иногда приходится выполнять какую-то несложную мужскую работу, но для меня это не проблема. Я привыкла все делать сама.

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

Игорь, деловой партнерИгорь, деловой партнер

Мы контактируем со Станиславом по электронной почте. До недавнего времени я и не знал, что он инвалид. Да и это не имеет значения в нашем случае лишь бы он хорошо писал. В плане корпоративного блога результаты у него хорошие.

Спасибо, Игорь! К счастью, мы нашли общий язык.

Я зарабатываю копирайтингом, представляете?! Копирайтер, который печатает медленно это же нонсенс. Я организован, пишу красиво и информативно, но устаю примерно в 20 часов, а в 23 меня просто выключает. Уффф

Чтобы вы понимали всю серьезность этой проблемы, проиллюстрирую. Вот эту статью я писал около недели со всеми правками и редакциями. Хотя тут дел-то на 4-5 часов.

И вот еще один мой знакомый.

Денис, парень, которому я сдаю квартируДенис, парень, которому я сдаю квартиру

Здорово, что Станислав не сдается. Он помог мне с жильем. Успехов ему и счастья.

Нам с женой выдали помощь от государства как молодой семье на покупку квартиры (по региональной программе). Мы взяли ипотеку и поселили квартиранта Дениса. Теперь он живет в квартире и оплачивает нашу ипотеку, а мы живем в частном доме.

Благодаря этим людям (и еще много кому) я до сих пор не сошел с ума. Это реальная помощь свыше. Спасибо.

Из-за них хочется продолжать лечение даже спустя много лет.

Как лечусь

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

Вот как проходит лечение.

  • Мышление лечится сложно и со скрипом. Но мне помог Иисус. Понимаю, что неверующим людям это сложно понять, но я связываю решение проблемы только с Ним.

Моя проблема это ропот, ворчание и недовольство. Они духовного происхождения. Как только перестаешь говорить, что все плохо, настроение улучшается.

Я перепробовал многие решения:

  • изменял рацион питания,

  • смотрел stand up,

  • ложился спать раньше.

Но ничего не помогало. Помог только Иисус.

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

А что с остальными последствиями?

  • Координация, походка, речь и прочие поражения неизлечимы. Вернее, излечимы, но не проходят без последствий.

Вот что я делаю с этими проблемами.

Работаю по дому. Домашние дела часто предполагают пребывание в неестественной позе, что благоприятно сказывается на координации. + иногда мне все-таки приходится залезть на стремянку, вкрутить шуруп и т.д. Это помогает.

Я забил на ЛФК и любую физкультуру. Уверен, что двигательная активность и постоянная работа по дому заменит упражнения.

Тем не менее, не призываю никого поступать также.

Максим, тренер спортклубаМаксим, тренер спортклуба

В принципе, идея хорошая. Но только отчасти. Ведь движение это жизнь, и любая двигательная активность способствует жизни.Минусы такого решения не во всех условиях можно выполнять нужные упражнения. Например, в случае Стаса нужны фиксированные и рычажные тренажеры чтобы снять нагрузку со стабилизаторов и таким образом повысить эффективность упражнений. Но забивать гвозди, лазить по лестнице, носить тяжести и т.п. это правильные упражнения. Они монотонны и требуют подключения различных групп мышц одновременно.В целом, решение верное. Только тренажеры хороши тем, что позволяют регулировать нагрузку, подстраивать их под себя. Но если подойти к вопросу организации тренировок с умом, то можно и в домашних условиях добиваться результатов.

Далее, что я делаю еще.

Стараюсь не торопиться и делать все с расстановкой. Качество важнее скорости. Спешка нужна только при ловле блох, сказала мне одна знакомая (и слава Богу, что я тороплюсь только во время игр с котиками).

Кстати, да у меня 2 кота. Иметь домашнее животное прям показано при таком заболевании (опять же это врачи сказали).

Смоки и Барсик, прекрасные ребята. Общительные, приветливые. И реагируют на перемены эмоционального фона в доме. Например, когда мы с женой ругаемся, Смоки прибегает и начинает орать.Смоки и Барсик, прекрасные ребята. Общительные, приветливые. И реагируют на перемены эмоционального фона в доме. Например, когда мы с женой ругаемся, Смоки прибегает и начинает орать.

Я читаю стихи. Книги вслух, статьи. Рэп (но делаю это редко).

Стараюсь следить за своим произношением и, по возможности, его корректировать.

И если собеседник не понимает меня, то я повторяю медленнее и с расстановкой стараюсь убедиться, что информация прошла без искажений. И делаю это постоянно.

принимаю БАДы для общего укрепления организма.

Эти меры не требуют особого времени или внимания. А у меня его особо и нет (из-за моей медлительности), поэтому такие оздоровительные мероприятия то, что нужно в моем случае.

Ответственно заявляю: нервные клетки восстанавливаются (вопреки устоявшемуся мнению). Просто долго и не до конца.

Что я рекомендую читателям

Из своей истории я вынес несколько ценностей, которые могут помочь людям в сложной ситуации. Оформил их в 7 советов. Наверное, можно говорить о чем-то еще, но я решил сосредоточиться на главном.

  1. Обретите внутренний стержень. Это сложный вопрос, но им необходимо задаться каждому человеку. И чем раньше, тем лучше.

  2. Дружите. Люди вокруг помогут не сойти с ума.Человек создан для дружбы. Поэтому жена, друзья, бизнес-партнеры, родственники они сначала друзья, а потом уже все остальное. Такая философия помогает трудиться усерднее и достигать больше.

  3. Женитесь. И любите свою жену (или мужа). Вдвоем жить легче, интереснее, веселее.

  4. Не ругайтесь. Ни с кем, никогда.Это деструктивно влияет на каждую сторону конфликта.

  5. Заведите домашнее животное оно будет создавать атмосферу тепла и уюта. И это дисциплинирует здорово (потому что кормить надо по расписанию и, желательно, несколько раз в день).

  6. Не работайте по найму. Оформите самозанятость, идите в IT и трудитесь, а не продавайте свое время.А еще лучше оформите ИП и наймите на работу других людей. Вместе и веселее, и эффективнее.

  7. Не сдавайтесь. Самое стремное, что может сделать человек это спасовать перед трудностями. Лучше не начинать дело, чем начать и бросить. Если взялись, то доделайте до конца.

И помните: Бог никогда не посылает непосильных испытаний. Если что-то случилось в жизни, то из проблемы есть минимум 2 выхода (обычный и через *опу).

Еще раз: никогда не сдавайтесь перед трудностями, ни под каким предлогом это мораль статьи.

Если вам понравилось, поставьте +, если хотите поддержать меня. Также можете подписаться на меня мне будет приятно.

У вас остались вопросы? Вэлкам в комментарии я постараюсь отвечать оперативно.

Спасибо за внимание!

Дата-центр ITSOFT размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.

Подробнее..
Категории: Карьера в it-индустрии , Accessibility , Здоровье , Фриланс , Саморазвитие , Реабилитация , Личностный рост , Спорт , Фрилансер , Блог компании itsoft , Инвалид

Загадочные субтитры на CNN

01.12.2020 02:09:30 | Автор: admin
Зрители CNN обратили внимание, что в выпуске новостей 12/11/2020 на их официальном YouTube-канале вместо субтитров какая-то каша из обрывков английских слов, сплошным капсом:



Как такое могло получиться? (По состоянию на 1/12/2020, субтитры на YouTube так и не исправлены.)

Stenotype


Американские стенографисты уже больше сотни лет как используют специальные устройства с минимальной 22-клавишной клавиатурой по две клавиши под каждый палец, чтобы минимизировать движения кистей:



Сто лет назад стенотайп был вариантом печатной машинки, и каждая клавиша оставляла оттиск на бумаге. Каретки не было: после каждого аккорда из одной или нескольких одновременно нажатых клавиш, бумага проматывалась на одну строчку вниз. Оттиск каждой литеры приходился всегда на одно и то же место в строке. Клавиши P, R, S, T присутствуют в двух экземплярах каждая под левой и под правой рукой.



Каждый аккорд, и каждая строчка в распечатке, соответствует одному слогу. Промежутков между словами нет, а сами слова передаются фонетически: на показанной выше распечатке застенографирована фраза You should be able to read these short words. Поскольку клавиш меньше, чем букв в английском алфавите, и тем более чем звуков в английской речи, то используется хитроумная система кодирования, например [n] записывается как PB, [l] как HR, дифтонг [e] как AEU, и т.п. При таком кодировании, например, слово gleam записывается как TKPWHRAOEPL аккорд из одиннадцати одновременно нажатых клавиш!
Пример отрывка стенограммы судебного заседания

После заседания стенографист должен был сидеть и перепечатывать свою стенограмму на обычной печатной машинке, потому что прочесть её неподготовленному человеку решительно невозможно. В приведённом примере фраза absolutely one hundred percent записана как SHRAOUT HRAOE WOPB HUPBD PERS, что означает [sljutli wn hnd prs] пропущенные слоги должны восстанавливаться по контексту, а гласные не вполне соответствуют словарной транскрипции. Существуют разные системы обозначений и сокращений, так что даже самим стенографистам сложно читать записи один другого. Вот короткий отрывок из учебника стенографии, исправленного владельцем под другую систему:



Считается, что средний темп английской речи 130 слов в минуту, а стенографист со стенотайпом может печатать до 300 слов в минуту, что позволяет записывать разговор даже тогда, когда собеседники перебивают друг друга. Есть аналогичная система Velotype, ориентированная на побуквенную запись вместо фонетической; она позволяет печатать до 200 слов в минуту. Разница вызвана тем, что в английских словах почти всегда букв больше, чем звуков иногда вдвое, как в словах choose [tuz] или earth []. Велотайп был создан в 1939, когда расцвели табуляторы и автоматическая обработка данных; мотивацией для побуквенной записи была более простая расшифровка стенограмм, которую можно было бы поручить даже электромеханической машине. Вместе с прочей оргтехникой электрифицировались и сами стенографические машины: вместо механически соединённых клавиш и литер, печатающих на бумаге, с конца прошлого века используется электроника, удобные дисплеи, цифровое хранение и обработка стенограмм.



В начале этого века возможности компьютерной обработки естественных языков достигли того уровня, чтобы автоматически расшифровывать стенотайповые фонетические стенограммы и превращать SHRAOUT HRAOE в absolutely. Затем поддержка лиц с ограниченными возможностями достигла того уровня, чтобы телеканалы сопровождали прямой эфир субтитрами в реальном времени для тех, кому читать проще, чем слушать. Это значит, что за эфиром следит стенографист со стенотайпом, он записывает речь диктора и других участников передачи, его компьютер расшифровывает стенограмму, при необходимости автоматически переводит её на язык целевой аудитории, и передаёт получившийся текст в эфир и на YouTube.

Судя по всему, 12/11/2020 у CNN в этой сложной системе что-то засбоило, и вывод расшифровщика перемешался с кусками нерасшифрованной стенограммы. Даже если они во время передачи и обнаружили сбой, то решили ничего не трогать, чтобы не отломалось что-нибудь более важное. Случай на Fox News в 2013 наделал гораздо больше шума: в тот раз расшифровщик не справился с именем Джохара Царнаева, устроившего взрыв на Бостонском марафоне, и подставил вместо него в субтитры имя актрисы Зоуи Дешанель.
Подробнее..
Категории: Accessibility , История it , Natural language processing , Типографика , Cnn , Стенография , Stenotype , Velotype , Fox news , Computer aided transcription

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru