Как закрывать модальные окна

Закрыть модальное окно программно.

Во время проведения дока открываю модальное окно обработки, чтобы выдать сообщение. Но вот надо бы его закрыть через 10 сек., если пользователь в ступоре. А не получается. Попробовал так (в форме обработки):

Код
Показать полностью

не работает. Хелп! И возможно ли без использования ВК?

В модальных формах не работает ОбработкаОжидания()
но есть решение без использования ВК.

Сhe Burashka Написал:
——————————————————-
> В проведение пихать вопрос — двойка.
> Вместо модального окна выдай
> Предупреждение(«Программер-ламер!»,60) — будет
> ждать 1 мин.
> + есть решение в формексе вроде обработку ожидания
> мождно и для модального окна

Че, ты прав, конечно. Но. Это — замут самого пользователя. Уж очень любит он такие в**боны. Решение уже найдено и внедрено. Юзверь одобрил. Оч даже понравилось ему.
Смысл в чем: во время проведения снимается профит из регистра партий и передается в эту модальную обработку, которая спрашивает, чо делать: игнорировать тек. позицию, игнорировать все, или не проводить документ вообще. А когда у него (юзверя) манагер тупит и смотрит на модальное окно как баран — база для всех в незаконченой транзакции зависла. Я это понимаю, юзверь это понимает, а вот манагер — не понимает. И мешает всем работать. Поэтому по таймауту — не проводим нафиг да и все.

ЗЫ: Когда МонопольныйРежим()=1 никаких обработок, предупреждений, сообщений и т.п. не выводится.

LiS Написал:
——————————————————-
> ЗЫ: Когда МонопольныйРежим()=1 никаких обработок,
> предупреждений, сообщений и т.п. не выводится.

ИМХО правильный замут. Это нужно для перепроведения документов и восстановления последовательности.

Но ИМХО нельзя исключать программного (пакетного) [пере]проведения документов в немонопольном режиме. Подумай об этом.

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

Я бы эту проверку вставил до проведения документа. Делается так:
В формуле кнопки Провести:
ПроверкаПередПроведением(); #Записать Провести

В модуле формы:

Код
Показать полностью

Заодно решается проблема, о которой написала poppy.

2 Сhe Burashka:
Использовать Предупреждение() или Вопрос() в процедуре проведения — еще большая засада, чем модальную форму обработки. Ибо в них тайм-аут работает только при активном окне 1С. Вредителей, которые бросают одинэску на открытых модальных окнах, и переключаются в другие приложения, достаточно.

Источник

Вы не знаете как должны работать модальные окна

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

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

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

Этот список сформирован на основе спецификаций WAI-ARIA, HTML Living Standard и моего личного опыта. И хотя я буду говорить про веб, большинство правил и рекомендаций применимы для модальных окон где угодно.

Определение модального окна

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

Теги и атрибуты

Интерактивным элементом для открытия диалогового окна должна выступать кнопка. Не

Простейшая реализация кнопки открывающая диалог по его id:

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

  • Chromium — полная поддержка.
  • Firefox — поддержка за флагом.
  • Safari не поддерживает вовсе.

Так что для этих браузеров нужно подгружать polyfill:

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

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

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

Вскользь коснусь внешнего вида.

На небольших экранах диалоговое окно должно занимать 100% его размера. Если ваш диалог будет большим:

  1. Его будет легче «нащупать». Дело в том, что пользователь может взаимодействовать со страницей следующим образом: он водит пальцем по дисплею, а программа чтения с экрана озвучивает то, что в данный момент находится под пальцем.
  2. Пользователю гарантированно не будут озвучиваться элементы «под ним». Иначе, например, VoiceOver на iPad может озвучивать отдельные фрагменты страницы под модальным окном даже «сквозь» оверлей блокирующий доступ указателю.
  3. Вы скроете прокрутку фона на некоторых устройствах при прокрутке контента в диалоговом окне.
  4. Удобнее для одной руки. Если окно растянуто на всю высоту – то у вас есть возможность прижать кнопки управления к нижней части дисплея. Туда намного проще дотянуться одной рукой пользователям современных смартфонов.
  5. Больше места для контента на устройствах с маленьким экраном, таких как iPhone SE.

Заголовок обязателен

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

Настоятельно рекомендуется использовать для заголовка тег

Но просто добавить заголовок в диалоговое окно недостаточно. Их нужно ещё и логически «связать». Сделать это можно с помощью атрибута aria-labelledby следующим образом:

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

Статический контент должен быть связан с окном

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

Делается это атрибутом aria-describedby :

Если в вашем диалоговом окне много контента, тогда стоит обернуть его в один

Важно! Заголовок и любые кнопки не относящиеся к содержимому, а служащие для управления диалоговым окном, не должны быть включены в элемент на который указывает aria-describedby . Они должны быть вынесены отдельно:

Интерактивные элементы связывать не нужно

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

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

Если скомбинировать и статический текст и форму:

Способы закрыть окно

Внутри диалогового окна обязана быть кнопка чтобы его закрыть. Не

Дополнительно, в зависимости от вашей логики, вы можете позволить пользователю закрыть диалог кликнув за его пределами или нажав Escape (встроено в из коробки).

  1. Не рассчитывайте, что пользовать всегда может нажать на оверлей и так закрыть диалог.
    1. Как я писал ранее, во многих случаях диалоговое окно может занимать всю или большую часть экрана. Таким образом попасть в него может быть сложно или невозможно.
    2. Такой оверлей семантически не считается интерактивным элементом. Он не может быть в фокусе и на него невозможно «нажать» клавишами.
  2. Не рассчитывайте, что у пользователя под рукой есть клавиатура, чтобы нажать Escape.
  3. Существует множество устройств, программ и различных инструментов, способных читать веб-сайты и давать пользователю взаимодействовать с ними, но не так как в браузере. Во многих случаях единственным рабочим вариантом остаётся кнопка внутри.

Простейшая реализация кнопки закрывающей родительский диалог:

А если вы делаете кнопку с иконкой, то не забывайте про подпись, чтобы передать ёё назначение:

Поведение фокуса

При открытии диалога

Во время открытия диалогового окна фокус должен быть перемещён на элемент внутри него. На какой именно — зависит от содержания.

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

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

Но есть и несколько исключений:

  1. Запрос подтверждения чего-либо. Если ваш диалог запрашивает у пользователя подтверждения перед выполнением каких-то необратимых действий (удаление чего-то или выполнение финансовых операций), тогда фокус автоматически должен ставится на кнопку «отмены» этих действий, независимо от её расположения.
  2. Ситуации, когда в диалоговом окне много статического контента и первый интерактивный элемент не помещается в видимую область. Проблема тут в том, что в таком случае браузер автоматически проскролит вниз к кнопке в фокусе. Это вынудит пользователя скролить обратно вверх, а потом снова вниз. Для таких случаев есть два подхода:
    1. Переместить или продублировать интерактивные элементы так, чтобы первый из них был в видимой части экрана. Например, выполнить кнопку закрыть в виде крестика и закрепить в верхней части диалогового окна.
    2. Заголовок или первый абзац текста нужно сделать фокусируемым при помощи tabindex=»-1″ и перемещать фокус на него. Но при этом подходе некоторые программы чтения с экрана могут озвучивать заданный текст дважды: сначала как заголовок и описание окна, а потом как содержание выделенного элемента.

Управлять куда именно попадёт фокус при открытии модального окна можно с помощью атрибута autofocus :

Внутри диалога

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

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

Но этого недостаточно, так как остаётся ещё и навигация клавишами Tab / Shift + Tab . Также это могут быть клавиши громкости на смартфонах или специальные клавиши на дополнительных инструментах подключенных по USB/Bluetooth. Этот способ навигации тоже должен быть заблокирован.

После попадания фокуса в модальное окно пользователь может перебирать интерактивные элементы внутри этого окна, но не должен выходить за его пределы. Другими словами, такое диалоговое окно работает как ловушка для фокуса. Это поведение встроено в , так что от вас никаких действий не требуется. А вот используя другой элемент с role=»dialog» его нужно реализовывать самостоятельно средствами JavaScript.

При закрытии диалога

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

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

Пример

Предлагаю разобрать на примере. Представим систему из трех диалоговых окон:

  1. Сообщает пользователю об наличии подписки. В нем две кнопки: «Условия подписки» и «Подписаться»
  2. Отображается по клику на «Условия подписки». Открывается поверх первого.
  3. Отображается по клику на «Подписаться». Заменяет собой первое.

В примерах ниже я специально пропустил дополнительные атрибуты и элементы, для упрощения кода.

Итак, у нас есть стартовая кнопка.

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

Далее пользователь перемещает фокус на «Условия подписки» и нажимает. Открывается второй диалог поверх первого. Фокус перемещается в него, а возвращаться должен на эту же кнопку в первом диалоге:

После закрытия второго диалога ваш JavaScript должен вернуть фокус на кнопку «Условия подписки» в первом.

После чего пользователь нажимает кнопку «Подписаться». По условиям нашей задачи открывается третий диалог. Фокус автоматически перемещается в него. А первый диалог закрывается:

И вот проблема: третье окно должно вернуть фокус на кнопку в первом, но первое окно больше не доступно. В таких случаях фокус нужно вернуть туда, куда указывал закрытый диалог — на кнопку «Рассылка» с которой пользовать начал.

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

Помните, как во время установки программы в Windows можно просто нажимать Enter? Так вот это пример хорошей работы с фокусом: каждый раз, при переходе на новый экран в фокус ставится элемент, с которым вы скорее всего будете взаимодействовать — кнопка «Далее» или «Обзор».

Источник

Доступные способы закрытия модальных окон

Давайте поговорим о великих побегах. Нет, речь пойдет не о волшебных способах ускользнуть, подобно фокусу Гудини с наручниками или Биврёсту, который использовал Тор. Вместо этого мы поговорим о вполне обыденном явлении – об интерактивной иконке, которая удаляет надоедливые всплывающие окна, закрывающие желаемый контент. Если модальные, диалоговые, всплывающие окна… как бы вы их ни называли, являются необходимым злом, то нам нужно создать доступные «аварийные люки» для их закрытия.

Визуальный дизайн

Обычный UX-шаблон для закрытия окна довольно прост. История символа [x] восходит к компьютерному дизайну 1970-х годов. Вероятно, его первым появлением было меню Atari TOS – список действий, привязанных к буквам и символам клавиатуры. [x] был командой для выхода (Exit). Затем его использовал NeXT, который вдохновил Windows, и стал стандартным символом для закрытия окна в 1995 году с массовым внедрением Windows во всем мире. Это означает, что нет необходимости заново изобретать колесо, используйте символ известный во всем мире.

Доступный дизайн

Мы начнем с основ – всегда должен быть [x], даже если пользователь может тапнуть по фону, свайпнуть или использовать кнопку «Назад», чтобы также закрыть модальное окно.

Иконка vs Буква

Создайте иконку, а не используйте типографскую букву, которая соответствует остальной части вашего набора иконок. Должно быть четко понято, что это [x], у которого все четыре конца, четко разделены. Лично я предпочитаю угол 90 ° и регулирую вес в соответствии с набором иконок.

Цвет должен быть нейтральным и соответствовать рекомендованному a11y коэффициенту контрастности 4: 1. Конечно, для всплывающих окон куда лучше, когда [x] беловато-серый и едва заметен, но это, друзья мои, то, что мы называем темным паттерном. Делая [x] едва видимым, мы вынуждаем пользователя выполнять основное действие, как будто оно обязательное. Это приводит к разочарованию пользователей и ложноположительному эффекту для бизнеса.

В контейнере vs Без контейнера

Иконка должна быть заключена в контейнер для обозначения относительного размера цели касания (tap target) и, чтобы отличить интерактивные иконки от статических, особенно, когда они расположены рядом.

  • Если иконка и контейнер имеют минимальный размер tap target (48x48dp / pt), сделайте цель касания больше, чем изображение кнопки, и не перекрывайте ее другими интерактивными элементами.
  • Если эта иконка находится внутри интерактивной панели, то эта панель уже создает кликабельное пространство – ура!

Размещение

Контент всплывающего окна не должен восприниматься как блокировка, и способ выхода из него должен легко распознаваться как действие, связанное со всплывающим окном. Несмотря на то, что традиционно большинство программ под Windows размещают закрытие окна в верхнем правом углу, в настоящее время HIG от Apple и Material Design от Google размещают иконки навигации вверху слева. Ни одна из систем не дает четких рекомендаций, когда речь заходит о модальности.

Размещение модального окна

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

Снизу vs По центру

Размещение [x]

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

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

Снаружи. Появляется за пределами модального окна. Это подчеркивает дизайн модальности, однако [x] может быть перепутан с элементами интерфейса внизу.

Справа vs Слева. Иконки от Meg Robichaud

Конец (справа) Размещение [x] на правой стороне больше подходит для легкого нажатия большим пальцем правой руки и не пересекается со статическими иконками.

Старт (слева) Размещение [x] на левой стороне соответствует текущей парадигме навигации, однако увеличивает вертикальную высоту модального окна из-за его близости к выровненной по левому краю пиктограмме и является еще одной целью нажатия на больших телефонах.

Это для языков с чтением слева направо. «Старт» – это место, где пользователь начинает читать контент, и «конец», где он останавливается. В языках с чтением справа налево вы должны сделать все наоборот.

Оптимальный вариант

Наша текущая оптимальная компоновка – это выровненное по нижнему краю модальное окно с иконкой [x], заключенной в контейнер на внутренней, верхней правой стороне.

Просто текст, изображение и иконка

Мысли в заключение

Вы также можете использовать две кнопки, расположенные горизонтально, одна из которых «Отклонить». Это отличная альтернатива, настоятельно рекомендованная Material Design, но в случае, если вы не хотите, чтобы кнопка «Отклонить» была слишком заметной, не хотите, чтобы ее могли случайно нажать, или у вас возникли проблемы с переводом при локализации, кнопка [x] является отличным универсальным решением.

Автор статьи – Линзи Берри, в настоящее время занимает должность design systems lead в Lyft. Она планирует публиковать статьи раз в две недели. Линзи пишет статьи о системах дизайн -мышления и процессе проектирования, чтобы внести свой вклад в дизайн-сообщество. Подпишитесь на ее блог на Medium!

Источник

Читайте также:  Как переделать окно до пола
Поделиться с друзьями