В том-то и дело, что есть уже такие устройства. От включения света дома у себя силой мысли вас отделяют лишь несколько сотен баксов и несколько дней, проведенных за программированием и распайкой соответствующего выключателя.
Кстати, когда писалась статья, я еще не знал, но есть уже и опенсорсный проект под названием OpenEEG, который позволяет вам с нуля собрать такое устройство самостоятельно.
А я и не утверждал, что тренды предсказывают будущее. Но они свидетельствуют о том, что люди это ищут, а значит, тренды демонстрируют популяризацию технологии.
Ссылки на тренды — не для доказательства. Они здесь в качестве дополнения, ну и чтобы немного разбавить текст.
Чрезмерная категоричность и слепое следование определенному шаблону — это ошибка, независимо от того, каких принципов придерживаться.
Есть разные ситуации, в некоторых из них наличие маленьких проектов, наряду с большими, необходимо.
А еще можно не впадать в крайности, и брать как маленькие, так и большие проекты. Большие — для развития, маленькие — для диверсификации и подстраховки.
Думаю, сильно. Сейчас проверил три открытых сайта (хабр, стэковерфлоу и вики ) везде есть :)
Ок, здесь я не угадал :) А, например, атрибут lang тоже все проставляют, если нужно вставить текст на другом языке?
Причём, насколько я понимаю, технической возможности определить использует ли пользователь какие-то экзотические девайсы нет ни на стороне сервера, ни даже на самом клиенте (девайсы внедряются на уровне ОС и браузер о них даже не догадывается), чтобы прозрачно для пользователя выдать ему динамическую или статическую версию страницы
Ну, с одной стороны, действительно, обычная качественная верстка сама по себе улучшит читаемость страницы инвалидами, но с другой стороны, если уходить в детали, этого недостаточно.
Например, каждый контрол должен быть снабжен не просто лейблом, а лейблом с атрибутом for. Думаю, не сильно ошибусь, если скажу, что по умолчанию этот атрибут не проставляет ни один верстальщик, даже самый хороший.
Насчет js и флеша — прямого запрета на использование нет ни для того, ни для другого. Но если смотреть на конкретные случаи использования динамики в вебе, то она почти всегда ухудшает accessibility.
Пример: есть выпадающий список, в зависимости от выбора элемента меняется какой-то кусочек страницы. Такие фишки в современном вебе сплошь и рядом. Но незрячий не может мгновенно отследить, что что-то на странице изменилась. Он думает, что двумя строчками выше написано одно, а там уже совершенно другое.
А если внезапно откроется какое-нибудь всплывающее окно, так это вообще сразу дезориентация. Представьте, что у вас содержимое всей страницы резко меняется, а вы этого даже понять сходу не можете, не говоря о том, чтобы найти, как вернуться обратно.
С технической точки зрения там достаточно просто. Если посмотреть на стандарты веб-разработки для инвалидов типа WCAG 2.0, их можно свести к двум простым верхнеуровневым требованиям:
1) Чистота вывода. Т.е., чтобы сайт хорошо парсился и разбирался на составляющие (была соблюдена уровневость заголовков, у ссылок был понятный альтернативный текст, все картинки были подписаны, у таблиц были заголовки и т.д.).
2) Чистота ввода. чтобы можно было осуществлять навигацию по сайту без мыши (а например одним табулятором)
При соблюдении этих требований, люди с ОВЗ смогут пользоваться сайтом с помощью своих спец. девайсов, в зависимости от вида инвалидности. Слепоглухонемой человек тогда может интерпретировать весь текст на сайте через дисплей Брайля, а безрукий — использовать специальные манипуляторы.
Другое дело, что соблюдать чистоту ввода-вывода не так просто. О флеше и большей части джаваскрипта в этом случае лучше сразу забыть (либо все страницы делать в двух вариантах — динамический и статический).
Я искренне рад, что у вас получилось реализовать хорошо и быстро, и не особо стремлюсь оправдать чиновников, «срывающих сроки». Я только призываю посмотреть на проблему с разных точек зрения.
Есть разные ситуации, где-то бизнес-процессы, возможно, остаются неизменными, и конкурсы быстро объявляются, и деньги приходят вовремя, и организаций не очень много в проекте участвует, и вообще все хорошо. Тогда создаются условия для хороших внедрений вроде вашего.
А бывают другие ситуации. Конечно, и несогласованность с некомпетентностью могут иметь место, но не всегда виноваты чиновники или исполнители.
Что же касается «выделяемых бюджетов» — это старинный холивар, провоцирующий долгое обсасывание одной и той же темы.
Во-первых, смотрят на то, какую кучу денег выделяют, а совокупные издержки не видят. «Дайте нам сто студентов, и мы сделаем вам электронное правительство за два месяца и за три миллиона рублей». Этот подход просто не работает в госучреждениях, по причине долгого финансирования, большого объема сопутствующих формальных работ и необходимости следовать ФЗ-94. За исключением отдельных частных случаев, к которому, возможно, относится и ваш.
Во-вторых, большой бюджет не всегда может повлиять на сроки. Это все равно что считать, что ребенка родить за три месяца вместо девяти, если утроить материнское пособие.
Это неправда. Электронные услуги оказываются совершенно по другим бизнес-процессам. Могу привести большое количество аргументов, почему это так. Ограничусь несколькими:
1. Оказание электронной услуги требует от чиновника иных действий, чем оказание обычной услуги.
2. Изменяется оргструктура — чиновников нужно меньше, и их квалификация должна быть другой.
3. Информационные потоки идут совершенно иначе.
Пример: то же зачисление в вуз, упомянутое выше. Изначально каждый вуз занимался этим сам, с помощью своей учетной системы, а в министерство предоставлял заполненные формы.
При внедрении госуслуги, подача заявки должна происходить вообще не в вуз, а в некую единую базу на уровне министерства. Меняются не только ответственные люди, но и ответственные за процесс ведомства.
Так что при внедрении госуслуги бизнес-процессы перекраиваются так, что их просто не узнать.
Легко критиковать. Для нормального внедрения госуслуги даже на уровне простой подготовки бланков нужно гораздо больше времени, чем было отведено министерствам.
Для каждого внедрения нужно дождаться финансирования, подготовить ТЗ и конкурсную документацию, объявить конкурс, подождать заявок, рассмотреть их, подписать контракт… Формальные процедуры затягивают реальное выполнение работы на полгода и больше, и ведомства с этим вряд ли могут что-то сделать: ограничения накладываются самой системой. А ведь это только ритуальная часть, дальше нужно реальную работу делать — проводить аналитику процессов (а они там, нужно заметить, весьма непростые), строить архитектуру, и так далее. Конечно, это делают не сами ведомства, а исполнители, но тем не менее на это все тоже требуется время.
Не забываем, что в этом году оргструктуру того же Минобрнауки колбасило больше полугода — было упразднено Федеральное Агентство по Образованию, и кадровые перетасовки просто не позволяли заняться чем-то полезным.
Я бы поставил вас на место рядового чиновника, который вынужден разгребать всю эту бодягу с электронным правительством, и посмотрел бы, как бы вы справились :)
Насчет каталогизатора — я думал, для деления на группы товаров есть специальный интерфейс, который один раз сделали, и теперь используют для настройки отдельных групп. Неужели все эти формы сравнения товаров каждый раз кодируют вручную?
Спасибо! Но я имел в виду не связь с конкретным сервисом, а движок.
Попробую переформулировать вопрос: можно ли с помощью продукта Я.Сервер развернуть свой, узкоспециальный аналог Я.Маркета? Присутствует ли в движке каталогизатор и сравнение неких объектов по ряду параметров?
Ваши запросы уже довольно узкоспециальные :) Я хорошо учился в школе, но не встречал термина «массовые коммуникации» (жена подсказывает, что этот термин вводится в универе на журфаке), и про ученого Кондорсе не слышал. Но наверное эти запросы тоже могут дать много интересного в плане нахождения новых трендов.
Кстати, когда писалась статья, я еще не знал, но есть уже и опенсорсный проект под названием OpenEEG, который позволяет вам с нуля собрать такое устройство самостоятельно.
Ссылки на тренды — не для доказательства. Они здесь в качестве дополнения, ну и чтобы немного разбавить текст.
Чищу зубы аквафрешем, зубы стали классные —
Как родной российский флаг, бело-сине-красные
Есть разные ситуации, в некоторых из них наличие маленьких проектов, наряду с большими, необходимо.
Ок, здесь я не угадал :) А, например, атрибут lang тоже все проставляют, если нужно вставить текст на другом языке?
Во флеше есть метод Accessibility.isActive(), но он работает далеко не всегда. Так что да, стопудового способа проверки нет.
Например, каждый контрол должен быть снабжен не просто лейблом, а лейблом с атрибутом for. Думаю, не сильно ошибусь, если скажу, что по умолчанию этот атрибут не проставляет ни один верстальщик, даже самый хороший.
Насчет js и флеша — прямого запрета на использование нет ни для того, ни для другого. Но если смотреть на конкретные случаи использования динамики в вебе, то она почти всегда ухудшает accessibility.
Пример: есть выпадающий список, в зависимости от выбора элемента меняется какой-то кусочек страницы. Такие фишки в современном вебе сплошь и рядом. Но незрячий не может мгновенно отследить, что что-то на странице изменилась. Он думает, что двумя строчками выше написано одно, а там уже совершенно другое.
А если внезапно откроется какое-нибудь всплывающее окно, так это вообще сразу дезориентация. Представьте, что у вас содержимое всей страницы резко меняется, а вы этого даже понять сходу не можете, не говоря о том, чтобы найти, как вернуться обратно.
1) Чистота вывода. Т.е., чтобы сайт хорошо парсился и разбирался на составляющие (была соблюдена уровневость заголовков, у ссылок был понятный альтернативный текст, все картинки были подписаны, у таблиц были заголовки и т.д.).
2) Чистота ввода. чтобы можно было осуществлять навигацию по сайту без мыши (а например одним табулятором)
При соблюдении этих требований, люди с ОВЗ смогут пользоваться сайтом с помощью своих спец. девайсов, в зависимости от вида инвалидности. Слепоглухонемой человек тогда может интерпретировать весь текст на сайте через дисплей Брайля, а безрукий — использовать специальные манипуляторы.
Другое дело, что соблюдать чистоту ввода-вывода не так просто. О флеше и большей части джаваскрипта в этом случае лучше сразу забыть (либо все страницы делать в двух вариантах — динамический и статический).
Есть разные ситуации, где-то бизнес-процессы, возможно, остаются неизменными, и конкурсы быстро объявляются, и деньги приходят вовремя, и организаций не очень много в проекте участвует, и вообще все хорошо. Тогда создаются условия для хороших внедрений вроде вашего.
А бывают другие ситуации. Конечно, и несогласованность с некомпетентностью могут иметь место, но не всегда виноваты чиновники или исполнители.
Что же касается «выделяемых бюджетов» — это старинный холивар, провоцирующий долгое обсасывание одной и той же темы.
Во-первых, смотрят на то, какую кучу денег выделяют, а совокупные издержки не видят. «Дайте нам сто студентов, и мы сделаем вам электронное правительство за два месяца и за три миллиона рублей». Этот подход просто не работает в госучреждениях, по причине долгого финансирования, большого объема сопутствующих формальных работ и необходимости следовать ФЗ-94. За исключением отдельных частных случаев, к которому, возможно, относится и ваш.
Во-вторых, большой бюджет не всегда может повлиять на сроки. Это все равно что считать, что ребенка родить за три месяца вместо девяти, если утроить материнское пособие.
1. Оказание электронной услуги требует от чиновника иных действий, чем оказание обычной услуги.
2. Изменяется оргструктура — чиновников нужно меньше, и их квалификация должна быть другой.
3. Информационные потоки идут совершенно иначе.
Пример: то же зачисление в вуз, упомянутое выше. Изначально каждый вуз занимался этим сам, с помощью своей учетной системы, а в министерство предоставлял заполненные формы.
При внедрении госуслуги, подача заявки должна происходить вообще не в вуз, а в некую единую базу на уровне министерства. Меняются не только ответственные люди, но и ответственные за процесс ведомства.
Так что при внедрении госуслуги бизнес-процессы перекраиваются так, что их просто не узнать.
Для каждого внедрения нужно дождаться финансирования, подготовить ТЗ и конкурсную документацию, объявить конкурс, подождать заявок, рассмотреть их, подписать контракт… Формальные процедуры затягивают реальное выполнение работы на полгода и больше, и ведомства с этим вряд ли могут что-то сделать: ограничения накладываются самой системой. А ведь это только ритуальная часть, дальше нужно реальную работу делать — проводить аналитику процессов (а они там, нужно заметить, весьма непростые), строить архитектуру, и так далее. Конечно, это делают не сами ведомства, а исполнители, но тем не менее на это все тоже требуется время.
Не забываем, что в этом году оргструктуру того же Минобрнауки колбасило больше полугода — было упразднено Федеральное Агентство по Образованию, и кадровые перетасовки просто не позволяли заняться чем-то полезным.
Я бы поставил вас на место рядового чиновника, который вынужден разгребать всю эту бодягу с электронным правительством, и посмотрел бы, как бы вы справились :)
Насчет каталогизатора — я думал, для деления на группы товаров есть специальный интерфейс, который один раз сделали, и теперь используют для настройки отдельных групп. Неужели все эти формы сравнения товаров каждый раз кодируют вручную?
Попробую переформулировать вопрос: можно ли с помощью продукта Я.Сервер развернуть свой, узкоспециальный аналог Я.Маркета? Присутствует ли в движке каталогизатор и сравнение неких объектов по ряду параметров?