Комментарии 43
А в чем смысл? Что оболочка данная дает такого, чего нельзя сделать стандартными средствами установив screen reader? С помощью скринридера большинство стандартных программ вполне доступны: и браузер, и офис и многое другое.
> А в чем смысл? Что оболочка данная дает такого, чего нельзя сделать стандартными средствами установив screen reader?
Отличие от других технологий: luwrain.org/doc/difference
> С помощью скринридера большинство стандартных программ вполне доступны: и браузер, и офис и многое другое.
При доступном офисе без зрения очень проблематично, скажем, сделать презентацию.
Или образование. Получится ли получить полноценное высшее образование по IT-специальности, используя говорящий браузер с офисом?
Отличие от других технологий: luwrain.org/doc/difference
> С помощью скринридера большинство стандартных программ вполне доступны: и браузер, и офис и многое другое.
При доступном офисе без зрения очень проблематично, скажем, сделать презентацию.
Или образование. Получится ли получить полноценное высшее образование по IT-специальности, используя говорящий браузер с офисом?
По вашей ссылке можно только понять что это кроссплатформенная оболочка, но что она дает нового, не доступного в стандартном интерфейсе ОС непонятно.
Вот что поддерживается судя из статьи. Укажите пожалуйста где тут есть возможность создания презентации?
Вот я например программирую на python и C++, как мне поможет данная оболочка получать образование в it среде с форматами .py, .cpp или .h?
LUWRAIN поддерживает форматы TXT, HTML, DOC, DOCX, XLSX и без обратной связи читает HTML и PDF.
Вот что поддерживается судя из статьи. Укажите пожалуйста где тут есть возможность создания презентации?
Вот я например программирую на python и C++, как мне поможет данная оболочка получать образование в it среде с форматами .py, .cpp или .h?
Процитирую ответ автора (он не зареган здесь):
Пожалуйста, читайте внимательней. Внизу упоминается TeX. Это в том числе и для создания презентаций. Современные утилиты экранного доступа могут выполнять авторазметку Daisy? Это одна из самых востребованных задач для незрячих. Как это делает LUWRAIN, Вы можете найти на нашем канале на YouTube. Как Вы создадите решение, которое интегрируется в сетевые сервисы? Сравните работу с ВКонтакте, как это делаете Вы в браузере или на трубке, с тем, как это делает LUWRAIN, это тоже есть на нашем канале. Как Вы будете работать в Google Docs? Через браузер? Вы программируете под Windows? Значит, в целый ряд компаний Вас на работу не возьмут. А программировать где-либо ещё Вы с большой вероятностью не можете. Если Вы, конечно, не Игорь Порецкий. На Python Вы постоянно прослушиваете длину отступа? То есть Вы никогда не думали, что для невизуального редактирования работу с Python надо в каком-то виде заскриптовать? Вы будете это делать через скрипты Jaws? Незакрытых задач много, каждая задача в отдельности закрывается трудно, поэтому речь и идёт про конструктор, создав который один раз, мы можем развивать в самых разных направлениях.
Да, про TeX в самом последнем предложении я пропустил, прошу прощения.
Но это не меняет вопроса особенности данной оболочки от обычной ОС и программы экранного диктора.
Общение в вк полностью доступно через браузер. А еще я общаюсь в фейсбуке, у вашей платформы есть такая возможность? Или например этот же хабр. Есть возможность общаться с вами тут в комментариях?
Насчет программирования под windows или linux вообще не понял посыла. Я когда еще видел — программировал под windows утилиты для автомобильного таргета на QNX. Были бы утилиты сборки.
Насчет отступов в python хорошо справляется Notepad++.
Количество пробелов говорится только там где оно меняется. Плюс расставляет сам по предыдущей строке.
Как можно заскриптовать отступы, которыми определяется алгоритм фактически, вообще не понятно.
А на работу не берут по другим причинам, а не потому пишу код я под windows или linux. Тут больше решает сомнение работодателей в твоей эффективности, скорости, особенно когда работа идет на иностранных заказчиков. Не знаю как у вас, а у нас вот так сложилось.
А на данной платформе походу программирование светит только приложений для этой самой платформы, которые нужны только пользователям данной платформы и больше никому.
Я не против развития технологий для незрячих, я только за. Я просто действительно пытаюсь понять особые преимущества платформы.
Пока я особого для себя не увидел, но может просто об этом не написали. В статье хотелось увидеть больше технической информации, а не просто рекламную статью.
Чтением текстовых файлов, pdf или html никого не удивить.
Вы пишите про конструктор, так вот хотелось бы увидеть техническую статью именно про конструктор. Как он работает, как с ним работать.
Но это не меняет вопроса особенности данной оболочки от обычной ОС и программы экранного диктора.
Общение в вк полностью доступно через браузер. А еще я общаюсь в фейсбуке, у вашей платформы есть такая возможность? Или например этот же хабр. Есть возможность общаться с вами тут в комментариях?
Насчет программирования под windows или linux вообще не понял посыла. Я когда еще видел — программировал под windows утилиты для автомобильного таргета на QNX. Были бы утилиты сборки.
Насчет отступов в python хорошо справляется Notepad++.
Количество пробелов говорится только там где оно меняется. Плюс расставляет сам по предыдущей строке.
Как можно заскриптовать отступы, которыми определяется алгоритм фактически, вообще не понятно.
А на работу не берут по другим причинам, а не потому пишу код я под windows или linux. Тут больше решает сомнение работодателей в твоей эффективности, скорости, особенно когда работа идет на иностранных заказчиков. Не знаю как у вас, а у нас вот так сложилось.
А на данной платформе походу программирование светит только приложений для этой самой платформы, которые нужны только пользователям данной платформы и больше никому.
Я не против развития технологий для незрячих, я только за. Я просто действительно пытаюсь понять особые преимущества платформы.
Пока я особого для себя не увидел, но может просто об этом не написали. В статье хотелось увидеть больше технической информации, а не просто рекламную статью.
Чтением текстовых файлов, pdf или html никого не удивить.
Вы пишите про конструктор, так вот хотелось бы увидеть техническую статью именно про конструктор. Как он работает, как с ним работать.
Пишет, что нет времени по интернетам спорить. Говорит, у них рассылка есть — группа: luwrain-users-ru@googlegroups.com, на которую можно подписаться, отправив письмо на luwrain-users-ru+subscribe@googlegroups.com
И контакты на сайте.
Занятой человек в общем. Я вот сам аргументированно потрещать не прочь в интернетах, но тут не моя предметная область, только переправляю вопросы-ответы туда-сюда.
И контакты на сайте.
Занятой человек в общем. Я вот сам аргументированно потрещать не прочь в интернетах, но тут не моя предметная область, только переправляю вопросы-ответы туда-сюда.
ofmetal, я понимаю, что вы просто цитируете чужие слова, поэтому прошу не воспринимать нижеследующее на свой счёт, однако мне бы не хотелось оставлять заведомо некорректную информацию в публичном поле без предметных комментариев, поэтому ниже я считаю нужным сделать ряд замечаний. К сожалению, более половины информации о преимуществах LUWRAIN являются манипуляцией фактами и в таком виде лишь вредят индустрии вспомогательных технологий.
Невизуальная доступность создания презентаций с помощью TeX является свойством TeX и распространяется на все платформы, под которые существуют утилиты работы с TeX. Соответственно то, что Михаил пытается декларировать как преимущество LUWRAIN, к заслугам LUWRAIN не имеет никакого отношения.
Незрячий человек на Windows или macOS может взять TeX, в любом текстовом редакторе при помощи любой программы экранного доступа набрать нотацию TeX и сделать себе презентацию.
То есть наличие решения через PowerPoint или Keynote — это плюс дополнительные варианты, а не что-то исключающее доступность TeX для пользователей не LUWRAIN.
Это мы ещё оставляем за скобками целый ряд небольших инструментов для вполне доступного создания презентаций, типа генерации HTML-слайдов из простых текстовых файлов с MarkDown, что намного проще TeX. То, что Михаилу где-то кто-то пожаловался на свои личные проблемы, ещё не означает, что это является нерешённой технологической проблемой всей индустрии. Большинство озвучиваемых недостатков программ экранного доступа являются пересказом каких-то сплетен некомпетентных людей.
Программа экранного доступа является приложением для обеспечения доступности прочих приложений. Поэтому претензии к ним, что в них нет конвертора DAISY, встроенного MP3 плеера или почтового клиента являются безграмотными. Это примерно как от драйвера для монитора требовать наличие встроенного калькулятора. Задача программы экранного доступа заключается в том, чтобы работать в фоне и озвучивать то, что происходит в графическом интерфейсе какого-то приложения общего пользования.
Корректнее ставить вопрос, что под операционную систему x не существует приложения с какой-то функциональностью, а вот внутри среды LUWRAIN такая функциональность обеспечена.
Однако это не является концептуальным преимуществом идеи LUWRAIN. То есть если бы вместо имплементации этой функциональности в LUWRAIN она была бы реализована в виде отдельного приложения, то это было бы столь же функционально. Фактически на лицо лишь синдром швейцарского ножа, когда вместо написания отдельного приложения с такой функциональностью, оно реализовано как часть какого-то более общего продукта.
В итоге, на лицо манипуляция фактами, когда Михаил пытается обесценивать всю идею программ экранного доступа скопом на основе частных случаев реализованных функций, тогда как обратных примеров на несколько порядков больше, когда что-то в LUWRAIN отсутствует, а с программами экранного доступа доступно.
Кроме того, авторазметка DAISY не является «одной из самых востребованных задач для незрячих», как утверждает Михаил. Это просто неправда. Вероятно он попал в информационное гетто с какими-то сотрудниками библиотек, для которых это важно и является отчётным показателем их работы, поэтому именно они нуждаются в таком инструменте, но не стоит это экстраполировать на всех незрячих.
DAISY-контент, который можно разметить в автоматизированном режиме, вообще обладает спорной ценностью для незрячих в контексте массового использования.
Фактически речь идёт об автоматизации синхронизации текста и звука в текстах художественного или гуманитарного характера, что мало полезно, потому что незрячие массово не испытывают необходимости постоянно переключаться между текстом и аудио в «Войне и мир» или учебнике истории: книга либо спокойно слушается в аудио, либо читается синтезатором речи из текста.
Синхронизированный текст с его дикторским прочтением — востребован в достаточно ограниченном числе случаев, например, в учебниках иностранного языка, книгах, читаемых не носителем языка,, или в материалах, содержащих математические или химические формулы. Для последнего пункта, кстати, автоматизация синхронизации является наименьшей проблемой при подготовке.
Всё это не означает, что достижения проекта LUWRAIN в сфере DAISY были напрасной работой, я как раз, в отличие от представителей проекта LUWRAIN, не склонен обесценивать преимущества альтернативных технологий, но не стоит манипулировать фактами и называть это решением наиболее острых проблем незрячих.
Точно также, как это происходит в LUWRAIN: возьмём язык программирования (причём, не ограничиваясь Java и JavaScript) и напишем клиент для API. Этот аргумент вообще выглядит жалко.
То, что это делают для LUWRAIN, и не делают для пользователей вне LUWRAIN, не означает, что вне LUWRAIN это невозможно. Это обычно означает, что вне LUWRAIN эти задачи либо не считают важными, либо они уже имеют свои достаточно эффективные решения.
Между прочем, доступный кроссплатформенный интерфейс можно написать на целом ряде стандартных технологий GUI. Ну это так, на всякий случай, если кому-то захочется привести аргумент о кроссплатформенности LUWRAIN.
Увы, это призыв к тому, что не делает сам призывающий, а именно: он не в курсе того, как те самые проблемы решаются под Windows или macOS с их инструментами невизуального доступа.
К сожалению, большинство подобных дискуссий вокруг LUWRAIN упираются именно в том, что в этом проекте абсолютно провалена предварительная исследовательская составляющая, поэтому мы и получаем споры вокруг якобы плохой доступности чего-то, о чём разработчики LUWRAIN просто не знают.
В социальных сетях сейчас по всему миру десятки тысяч полностью незрячих людей. Через LUWRAIN там присутствует, боюсь, только один Михаил. Думаю, это о чём-то говорит. Как минимум, о том, что не всё так плохо, а может и вообще даже лучше, чем он считает.
совершенно верно. Плюс существуют и доступные клиенты. Причём, спорить об эффективности этого подхода хотелось бы с тем, кто сам это пробовал, причём, не через браузер внутри Emacs, а через полнофункциональный браузер с современной программой экранного доступа.
Здесь просто стоит отметить то, что программировать без зрения можно на любой платформе без какого-либо привлечения LUWRAIN. Это заявление Михаила в принципе абсурдно. LUWRAIN на сегодняшний день не делает доступной какую-то новую область IT для незрячих, равно как вряд ли это сделает когда-либо в будущем, просто потому что терминал и текстовый редактор доступен везде уже сейчас, впрочем как вещи типа Emacs или различных IDE. Это просто факт, кстати, известный даже Михаилу, так что он просто лукавит.
Это очередной пример проваленной исследовательской работы Михаила, который просто не имеет достаточных представлений о том, как все эти проблемы уже решались в других местах.
Программы экранного доступа давно имеют интеллектуальное озвучивание отступов, когда произносится лишь изменение уровня. Также это изменение можно иллюстрировать не только фразой синтезатора, но и звуковым сигналом, чтобы ускорить процесс параллельно воспринимая и речь, и сигнал.
Это будет работать в любом доступном для программ экранного доступа текстовом редакторе или IDE, а не в каком-то одном месте.
Также программы экранного доступа умеют разными способами в доступной форме доносить до незрячих расцветку кода.
Все эти проблемы были сформулированы в отрасли вспомогательных технологий много лет назад и для них были выработаны достаточно эффективные решения.
Вполне возможно, что в LUWRAIN можно придумать что-то новое или как-то усовершенствовать имеющиеся подходы, но для этого разработчикам этого продукта следует наконец-то дать себе труд провести исследовательскую работу и узнать, до чего дошла индустрия вспомогательных технологий, а не заниматься манипулированием фактами и передёргиванием.
Это очень хороший подход, который я всегда приветствовал в LUWRAIN и не раз советовал Михаилу наконец довести до ума что-то одно.
Проблема заключается в том, что в рамках LUWRAIN самые базовые фундаментальные задачи до сих пор не решены, а главное попытка обсудить это в информационных каналах проекта сталкивается с токсичной реакцией главного разработчика.
Простейший пример — это работа с текстом. Фактически это базовая задача, к которой сводится в том числе и весь интерфейс LUWRAIN.
Решение проблемы доступности текста на экране декомпозируется на большое число маленьких задач:
Все эти проблемы были сформулированы в индустрии десятилетия назад и для них были выработаны решения.
Эти вопросы и необходимость их обсуждения поднимались несколько лет назад и в проекте LUWRAIN, однако там всё это было проигнорировано в достаточно токсичной форме.
В итоге, на сегодняшний день эти самые базовые задачи невизуальной доступности в LUWRAIN не решены, но мы продолжаем наблюдать рассуждения о специально разработанном конструкторе «супердоступных» интерфейсов.
Горькая правда заключается в том, что функциональность доступной и эффективной работы с простым текстом, набранным в редакторе, в LUWRAIN сейчас ниже, чем в каком-нибудь Блокноте Windows с параллельно запущенной программой экранного доступа, то есть специализированный интерфейс спустя 10 лет разработки всё ещё хуже, чем неспециализированный.
До недавнего времени можно было отговариваться beta-статусом LUWRAIN, но пару лет назад была выпущена официально стабильная версия 1.0, где даже просто переход по словам по CTRL+Вправо/Влево упирался в конце строк и требовал дополнительных нажатий для перехода на новую строку и стабилизации фокуса на первом слове этой строки. То есть политика разработки LUWRAIN в реальности не направлена на то, чтобы вытащить доступность интерфейса на максимальный уровень. Это просто суета в множестве разных направлений, ни одно из которых не доведено до работоспособного состояния, даже самые базовые вещи.
При этом, Михаил продолжает игнорировать необходимость повышения собственной эрудиции в подходах к решению задач невизуальной доступности. Он оперирует устаревшими концепциями и представлениями, пытаясь изобретать велосипеды и заново собирая шишки тупиковых направлений или, если повезёт, открывая Америку, например, идею браузерного омнибокса, представляя её как прорыв, который должен посрамить всех любителей программ экранного доступа, которые имели доступ к этому с самого его появления.
Увы, у LUWRAIN, безусловно, есть потенциал в ряде ниш, но я не вижу, чтобы его пытались по-настоящему раскрывать.
Пока LUWRAIN — это продукт, который наверняка очень интересно разрабатывать, но который до сих пор мало что может предложить реальным пользователям. И это спустя почти 10 лет разработки и уже при наличии официально стабильных релизов.
> Внизу упоминается TeX. Это в том числе и для создания презентаций.
Невизуальная доступность создания презентаций с помощью TeX является свойством TeX и распространяется на все платформы, под которые существуют утилиты работы с TeX. Соответственно то, что Михаил пытается декларировать как преимущество LUWRAIN, к заслугам LUWRAIN не имеет никакого отношения.
Незрячий человек на Windows или macOS может взять TeX, в любом текстовом редакторе при помощи любой программы экранного доступа набрать нотацию TeX и сделать себе презентацию.
То есть наличие решения через PowerPoint или Keynote — это плюс дополнительные варианты, а не что-то исключающее доступность TeX для пользователей не LUWRAIN.
Это мы ещё оставляем за скобками целый ряд небольших инструментов для вполне доступного создания презентаций, типа генерации HTML-слайдов из простых текстовых файлов с MarkDown, что намного проще TeX. То, что Михаилу где-то кто-то пожаловался на свои личные проблемы, ещё не означает, что это является нерешённой технологической проблемой всей индустрии. Большинство озвучиваемых недостатков программ экранного доступа являются пересказом каких-то сплетен некомпетентных людей.
> Современные утилиты экранного доступа могут выполнять авторазметку Daisy? Это одна из самых востребованных задач для незрячих. Как это делает LUWRAIN, Вы можете найти на нашем канале на YouTube.
Программа экранного доступа является приложением для обеспечения доступности прочих приложений. Поэтому претензии к ним, что в них нет конвертора DAISY, встроенного MP3 плеера или почтового клиента являются безграмотными. Это примерно как от драйвера для монитора требовать наличие встроенного калькулятора. Задача программы экранного доступа заключается в том, чтобы работать в фоне и озвучивать то, что происходит в графическом интерфейсе какого-то приложения общего пользования.
Корректнее ставить вопрос, что под операционную систему x не существует приложения с какой-то функциональностью, а вот внутри среды LUWRAIN такая функциональность обеспечена.
Однако это не является концептуальным преимуществом идеи LUWRAIN. То есть если бы вместо имплементации этой функциональности в LUWRAIN она была бы реализована в виде отдельного приложения, то это было бы столь же функционально. Фактически на лицо лишь синдром швейцарского ножа, когда вместо написания отдельного приложения с такой функциональностью, оно реализовано как часть какого-то более общего продукта.
В итоге, на лицо манипуляция фактами, когда Михаил пытается обесценивать всю идею программ экранного доступа скопом на основе частных случаев реализованных функций, тогда как обратных примеров на несколько порядков больше, когда что-то в LUWRAIN отсутствует, а с программами экранного доступа доступно.
Кроме того, авторазметка DAISY не является «одной из самых востребованных задач для незрячих», как утверждает Михаил. Это просто неправда. Вероятно он попал в информационное гетто с какими-то сотрудниками библиотек, для которых это важно и является отчётным показателем их работы, поэтому именно они нуждаются в таком инструменте, но не стоит это экстраполировать на всех незрячих.
DAISY-контент, который можно разметить в автоматизированном режиме, вообще обладает спорной ценностью для незрячих в контексте массового использования.
Фактически речь идёт об автоматизации синхронизации текста и звука в текстах художественного или гуманитарного характера, что мало полезно, потому что незрячие массово не испытывают необходимости постоянно переключаться между текстом и аудио в «Войне и мир» или учебнике истории: книга либо спокойно слушается в аудио, либо читается синтезатором речи из текста.
Синхронизированный текст с его дикторским прочтением — востребован в достаточно ограниченном числе случаев, например, в учебниках иностранного языка, книгах, читаемых не носителем языка,, или в материалах, содержащих математические или химические формулы. Для последнего пункта, кстати, автоматизация синхронизации является наименьшей проблемой при подготовке.
Всё это не означает, что достижения проекта LUWRAIN в сфере DAISY были напрасной работой, я как раз, в отличие от представителей проекта LUWRAIN, не склонен обесценивать преимущества альтернативных технологий, но не стоит манипулировать фактами и называть это решением наиболее острых проблем незрячих.
> Как Вы создадите решение, которое интегрируется в сетевые сервисы?
Точно также, как это происходит в LUWRAIN: возьмём язык программирования (причём, не ограничиваясь Java и JavaScript) и напишем клиент для API. Этот аргумент вообще выглядит жалко.
То, что это делают для LUWRAIN, и не делают для пользователей вне LUWRAIN, не означает, что вне LUWRAIN это невозможно. Это обычно означает, что вне LUWRAIN эти задачи либо не считают важными, либо они уже имеют свои достаточно эффективные решения.
Между прочем, доступный кроссплатформенный интерфейс можно написать на целом ряде стандартных технологий GUI. Ну это так, на всякий случай, если кому-то захочется привести аргумент о кроссплатформенности LUWRAIN.
> Сравните работу с ВКонтакте, как это делаете Вы в браузере или на трубке, с тем, как это делает LUWRAIN, это тоже есть на нашем канале.
Увы, это призыв к тому, что не делает сам призывающий, а именно: он не в курсе того, как те самые проблемы решаются под Windows или macOS с их инструментами невизуального доступа.
К сожалению, большинство подобных дискуссий вокруг LUWRAIN упираются именно в том, что в этом проекте абсолютно провалена предварительная исследовательская составляющая, поэтому мы и получаем споры вокруг якобы плохой доступности чего-то, о чём разработчики LUWRAIN просто не знают.
В социальных сетях сейчас по всему миру десятки тысяч полностью незрячих людей. Через LUWRAIN там присутствует, боюсь, только один Михаил. Думаю, это о чём-то говорит. Как минимум, о том, что не всё так плохо, а может и вообще даже лучше, чем он считает.
> Как Вы будете работать в Google Docs? Через браузер?
совершенно верно. Плюс существуют и доступные клиенты. Причём, спорить об эффективности этого подхода хотелось бы с тем, кто сам это пробовал, причём, не через браузер внутри Emacs, а через полнофункциональный браузер с современной программой экранного доступа.
> Вы программируете под Windows? Значит, в целый ряд компаний Вас на работу не возьмут. А программировать где-либо ещё Вы с большой вероятностью не можете.
Здесь просто стоит отметить то, что программировать без зрения можно на любой платформе без какого-либо привлечения LUWRAIN. Это заявление Михаила в принципе абсурдно. LUWRAIN на сегодняшний день не делает доступной какую-то новую область IT для незрячих, равно как вряд ли это сделает когда-либо в будущем, просто потому что терминал и текстовый редактор доступен везде уже сейчас, впрочем как вещи типа Emacs или различных IDE. Это просто факт, кстати, известный даже Михаилу, так что он просто лукавит.
> На Python Вы постоянно прослушиваете длину отступа? То есть Вы никогда не думали, что для невизуального редактирования работу с Python надо в каком-то виде заскриптовать?
Это очередной пример проваленной исследовательской работы Михаила, который просто не имеет достаточных представлений о том, как все эти проблемы уже решались в других местах.
Программы экранного доступа давно имеют интеллектуальное озвучивание отступов, когда произносится лишь изменение уровня. Также это изменение можно иллюстрировать не только фразой синтезатора, но и звуковым сигналом, чтобы ускорить процесс параллельно воспринимая и речь, и сигнал.
Это будет работать в любом доступном для программ экранного доступа текстовом редакторе или IDE, а не в каком-то одном месте.
Также программы экранного доступа умеют разными способами в доступной форме доносить до незрячих расцветку кода.
Все эти проблемы были сформулированы в отрасли вспомогательных технологий много лет назад и для них были выработаны достаточно эффективные решения.
Вполне возможно, что в LUWRAIN можно придумать что-то новое или как-то усовершенствовать имеющиеся подходы, но для этого разработчикам этого продукта следует наконец-то дать себе труд провести исследовательскую работу и узнать, до чего дошла индустрия вспомогательных технологий, а не заниматься манипулированием фактами и передёргиванием.
> Незакрытых задач много, каждая задача в отдельности закрывается трудно, поэтому речь и идёт про конструктор, создав который один раз, мы можем развивать в самых разных направлениях.
Это очень хороший подход, который я всегда приветствовал в LUWRAIN и не раз советовал Михаилу наконец довести до ума что-то одно.
Проблема заключается в том, что в рамках LUWRAIN самые базовые фундаментальные задачи до сих пор не решены, а главное попытка обсудить это в информационных каналах проекта сталкивается с токсичной реакцией главного разработчика.
Простейший пример — это работа с текстом. Фактически это базовая задача, к которой сводится в том числе и весь интерфейс LUWRAIN.
Решение проблемы доступности текста на экране декомпозируется на большое число маленьких задач:
- как обеспечить различаемость на слух одинаково звучащих букв, типа «М» (кириллическая) и «M» (латинская);
- как на слух узнать, что текст «GetFileSize» написан CamelCase'ом и где именно стоят большие буквы, причём, узнать это быстро в одно нажатие, а не читая всю строку по символам;
- как обеспечить улучшенную воспринимаемость на слух специфических записей, типа чисел, написанных с разделителями разрядов, когда «1 000» по умолчанию синтезатором речи читается не как «одна тысяча», а как «один ноль ноль ноль», или когда телефонный номер по умолчанию читается как сколько-то миллиардов с чем-то;
- как наиболее эффективно и гибко представить информацию о неалфавитных символах (знаки пунктуации, те же отступы в коде и др.);
- как максимально быстро донести до незрячего дополнительные метаданные о тексте, типа выделения в нём орфографических ошибок или той же подсветки синтаксиса;
- и прочее, и прочее.
Все эти проблемы были сформулированы в индустрии десятилетия назад и для них были выработаны решения.
Эти вопросы и необходимость их обсуждения поднимались несколько лет назад и в проекте LUWRAIN, однако там всё это было проигнорировано в достаточно токсичной форме.
В итоге, на сегодняшний день эти самые базовые задачи невизуальной доступности в LUWRAIN не решены, но мы продолжаем наблюдать рассуждения о специально разработанном конструкторе «супердоступных» интерфейсов.
Горькая правда заключается в том, что функциональность доступной и эффективной работы с простым текстом, набранным в редакторе, в LUWRAIN сейчас ниже, чем в каком-нибудь Блокноте Windows с параллельно запущенной программой экранного доступа, то есть специализированный интерфейс спустя 10 лет разработки всё ещё хуже, чем неспециализированный.
До недавнего времени можно было отговариваться beta-статусом LUWRAIN, но пару лет назад была выпущена официально стабильная версия 1.0, где даже просто переход по словам по CTRL+Вправо/Влево упирался в конце строк и требовал дополнительных нажатий для перехода на новую строку и стабилизации фокуса на первом слове этой строки. То есть политика разработки LUWRAIN в реальности не направлена на то, чтобы вытащить доступность интерфейса на максимальный уровень. Это просто суета в множестве разных направлений, ни одно из которых не доведено до работоспособного состояния, даже самые базовые вещи.
При этом, Михаил продолжает игнорировать необходимость повышения собственной эрудиции в подходах к решению задач невизуальной доступности. Он оперирует устаревшими концепциями и представлениями, пытаясь изобретать велосипеды и заново собирая шишки тупиковых направлений или, если повезёт, открывая Америку, например, идею браузерного омнибокса, представляя её как прорыв, который должен посрамить всех любителей программ экранного доступа, которые имели доступ к этому с самого его появления.
Увы, у LUWRAIN, безусловно, есть потенциал в ряде ниш, но я не вижу, чтобы его пытались по-настоящему раскрывать.
Пока LUWRAIN — это продукт, который наверняка очень интересно разрабатывать, но который до сих пор мало что может предложить реальным пользователям. И это спустя почти 10 лет разработки и уже при наличии официально стабильных релизов.
Спасибо за конструктивный ответ! Аргументированно.
Я процитирую ответ Михаила:
Я процитирую ответ Михаила:
Уважаемые коллеги!
Хорошо, давайте разбирать факты. Исходной точкой будет ссылка ниже на анонс Яндекс.Директа. В комментах есть явная жалоба на то, что сервис в стандартном виде незрячим недоступен. Писал не я, поэтому просто ссылаюсь на объективную жалобу пользователя. При этом сервис мог бы быть великолепно доступен незрячим через использование API Яндекс.Коннекта, который существует. Несогласных коллег прошу привести конкретные чёткие примеры инструментов, которые позволяют создавать интерфейсы для невизуальной работы с API. Варианты, что можно написать на Python утилиту, которую потом кто-то вызовет из командной строки, пожалуйста, не предлагать, потому что нам нужно решение для массового последующего применения. Там же, кстати, идёт и жалоба на ВКонтакте, которой точно так же могло не быть, если бы был бы достаточный опыт задействования API.
Никита Цейковец, кажется, сам же жаловался на интерфейс YouTube. Этой жалобы могло бы не быть, если бы работа шла бы через API. Доказывать, что веб — это прекрасно, а проблемы только из-за неправильной конструкции сайтов, очень неубедительно.
Стратегия использования API сильно выгоднее тем, что компания-автор сервиса может не вникать в проблемы незрячих. Я предлагаю смотреть на этот пример как на факт, который показывает пользу от разработки платформы.
Рассуждения о доступности инструментов разработки показались теоретическими. Отлично! Любой коллега может проверить, какими масштабами кода может оперировать незрячий человек, если он откажется от утилит экранного доступа. Прошу привести примеры сравнимых разработок в России с использованием стандартных методов доступности, которые были известны, как утверждается, уже давно. Лично мне известен только уникальный опыт Ольги Яковлевой, объём кода которой, в три раза меньше кода, написанного незрячим разработчиком в LUWRAIN (у нас есть и закрытая часть, которая приблизительно составляет половину от объёма открытой части). Давайте факты, пожалуйста. Пока я только вижу, что неоконная концепция позволяет нам работать больше и лучше, чем это могут делать пользователи давно известных решений.
LUWRAIN интересно разрабатывать. Конечно! Потому что мы строим решение, исходя из тех задачь, с которыми сталкиваемся непосредственно в работе. Только ведя разработку можно точно понять, что должно быть. Теперь я требую примеров деятельности, которая позволила автору строк про необходимость лучше узнать о существующих решениях, делать утверждения о их качестве и развитости. Если коллега привести доказательства своего опыта затрудняется, то предлагаю ему брать свои слова обратно, потому что в данном вопросе, как мне кажется, у нас опыта больше.
Тематика ресурса, к счастью, не даст никого ввести в заблуждение, что возможность написать скрипт на Python, где даже подсветка будет озвучиваться, это так же круто, как и вести масштабную разработку на Java.
Теперь уже я требую:
1. Факты существования механизмов для создания доступа к API для людей с нарушениями зрения. Надеюсь, что ни у кого не будет сомнений, что это увеличивает доступность.
2. Факты успешных масштабных проектов, которые ведут незрячие в России с использованием тех самых давно и хорошо проработанных методов доступности.
3. Желаю встретить Никиту на конференции, где он мне лично покажет, как он делает презентации в доступном офисе без посторонней помощи. Мы не будем, конечно, вспоминать, что с этой проблемой обращался человек, который непосредственно занимается обучением как незрячих математиков, так и незрячих школьников. Ах, да, TeX, конечно, не LUWRAIN, а надо будет, все люди отредактируют документ прямо в Ворде.
4. Да и про кроссплатформенность все как-то забыли. Холивар на тему Linux и Windows устраивать не будем, но мне нужны факты доступных, ну не знаю, хотя бы читалок книг в Linux. А то вопросы по этой теме задают люди, которые, что-то не знают про уровень доступности.
Вот ссылка на страницу Яндекса:
yandex.ru/blog/connect/yandeks-obedinyaet-interfeysy-dlya-upravleniya-konnektom-i-pochtoy-dlya-domena
Здравствуйте!
Скажите, пожалуйста, будет дан какой-то ответ по позиции Яндекса относительно accessibility? и сроков насильного переноса?
Если вы в одностороннем порядке перенесете домены в Яндекс.коннект, незрячие и слабовидящие пользователи в подавляющем большинстве потеряют нормальный доступ к управлению DNS, почтовыми ящиками и настройками доменов, не говоря уж об ином функционале Яндекс.коннекта, который так активно рекламируется.
В 2004 году ваша компания делала упор на accessibility, видя в этом и экономические, и социальные плюсы. Скажите, правильно ли я понимаю, что все изменилось, и для возобновления работы в этом направлении потребуется привлечение внимания общественности и государства?
Вспомните историю с недоступностью Вконтакте, а ведь социальная сеть не так значительно важна, как Яндекс.
> Несогласных коллег прошу привести конкретные чёткие примеры инструментов, которые позволяют создавать интерфейсы для невизуальной работы с API.
Ответ на этот тезис содержался в одном из предыдущих комментариев, который в содержательном смысле был проигнорирован. Повторю более развёрнуто.
Реализация любой функциональности, например, того же конвертора DAISY, или клиента для любого API, например, той же «ВКонтакте», может быть написана в доступной кроссплатформенной форме на существующих технологиях GUI, например, wxWidgets или web UI.
Получившийся интерфейс будет доступен за счёт существующих вспомогательных технологий в виде программ экранного доступа, которые на сегодняшний день предлагают более богатые функции по работе с текстовой информацией, если она предоставлена в доступном виде (см. прошлые замечания про ущербную функциональность LUWRAIN при навигации по тексту).
Причём, обращу внимание, что разработка клиента для какого-то API на том же Python с доступным GUI на каком-нибудь wxPython представляется не более трудоёмкой задачей, чем аналогичная разработка внутри LUWRAIN, а степень документированности общераспространённых решений для сторонних разработчиков на порядок выше, чем LUWRAIN.
Опережая возможное возражение, отмечу, что wxPython не требует строгого визуального контроля для создания интерфейса, в частности, весь интерфейс NVDA и её дополнений написан именно на нём командой незрячих разработчиков, равно как и ряд других проектов.
Таким образом, реализация поддержки какого-то API в рамках среды LUWRAIN — это лишь один из возможных вариантов, причём, далеко не во всём лучший, потому что дружественность LUWRAIN к внешним разработчикам низкая (фундаментальные изменения каждые несколько лет, плохая документированность, ограниченный набор языков разработки), да и сам LUWRAIN уступает экранным чтецам по эффективности работы незрячего с текстовой информацией, о чём было сказано ранее с приведением конкретных примеров.
> Стратегия использования API сильно выгоднее тем, что компания-автор сервиса может не вникать в проблемы незрячих. Я предлагаю смотреть на этот пример как на факт, который показывает пользу от разработки платформы.
Давайте всё-таки зафиксируем рамки дискуссии:
Я никогда не заявлял, что пользы от разработки платформы LUWRAIN не существует и что идея бесперспективна, поэтому данную точку зрения я отстаивать не собираюсь. Попытка перевести дискуссию в эту плоскость я считаю недобросовестным приёмом смены темы.
Прошу придерживаться главных вопросов, которые были подняты в начале обсуждения, а именно:
- Искажённая информация об альтернативных решениях, которым приписываются несуществующие недостатки на фоне чего предпринимается попытка сформулировать мнимые преимущества LUWRAIN, тогда как можно спокойно обсуждать реальные преимущества LUWRAIN, а не выдуманные.
- Наличие в LUWRAIN ряда проблем самой базовой функциональности, которые не позволяют говорить о её интерфейсе как об однозначно наиболее удобном и эффективном для незрячих (см. замечания про ущербность навигации по тексту в предыдущем комментарии).
Также стоит отметить, что идея использования публичных API для обеспечения доступности соответствующих сервисов звучит достаточно логично, но имеет целый ряд нюансов.
Дело в том, что публичные API часто имеют более узкую функциональность, чем основной пользовательский интерфейс.
Это обуславливается тем, что многие из них ориентированы не на поддержку полнофункциональных клиентов, а на предоставление интерфейсов для мониторинга отдельных параметров системы.
API тех же сервисов Яндекса далеко не во всём эквивалентны web-интерфейсам. Google Docs также, по крайней мере, раньше, но возможно и до сих пор, через web-интерфейс предоставляли больше возможностей, чем через API.
Ввиду этого, плевки Михаила в сторону работы с каким-нибудь Google Docs через браузер выглядят крайне некомпетентно, особенно ввиду того, что поддержка Google Docs в LUWRAIN обсуждается уже несколько лет, но до сих пор не реализована, так что спор фактически вокруг сравнения уже работающего решения через программы экранного доступа и некого прожекта в рамках LUWRAIN, бесконечно обещающего светлое будущее.
> Любой коллега может проверить, какими масштабами кода может оперировать незрячий человек, если он откажется от утилит экранного доступа.
Считаю этот тезис бессодержательным по следующим причинам:
- Не существует никаких общепризнанных метрик оценки возможности предельного объёма кода, которым может оперировать незрячий или любой другой человек. Не существует также никаких общеизвестных порогов возможностей, установленных эмпирически. Отсылка к этому как к само собой разумеющемуся представляется спекуляцией.
- Само понятие «объём кода» представляется спекулятивным, потому что существует модульность кода проекта, а также разные языки обладают разной степенью многословности.
- Михаил так и не сказал, что же такое происходит с большим кодом в каком-нибудь Notepad++, озвучиваемым при помощи NVDA, что незрячий не сможет с ним работать и его спасёт только LUWRAIN, который сейчас даже текст по словам не позволяет удобно вычитать, не озвучивая CamelCase и прочее. Причём, здесь его об этом спрашивали несколько раз несколько человек.
> Прошу привести примеры сравнимых разработок в России с использованием стандартных методов доступности, которые были известны, как утверждается, уже давно.
Со свой стороны прошу не использовать в технической дискуссии нетехнические доводы, в частности, национальную привязку тех или иных разработок.
Вспомогательные технологии для незрячих не являются критической инфраструктурой, типа сетевых коммутаторов, а ряд технологий лицензируются по жёстким открытым лицензиям, поэтому гипотетические санкционные риски на них не распространяются.
Один тот факт, что какая-то разработка в сфере вспомогательных технологий имеет российские корни, не может являться доводом в её пользу, при условии наличии более функциональных локализованных альтернатив.
Те же программы экранного доступа написаны во многом или практически полностью незрячими и представляют собой более объёмные и функционально сложные продукты, чем LUWRAIN. Разработка какой-нибудь NVDA ведётся незрячими из нескольких стран в распространённых редакторах кода и Visual Studio и сомневаюсь, что LUWRAIN убедит их на него перейти.
Да и вообще наличие инвалидности по зрению у IT-специалиста не означает, что он должен теперь работать только над проектами в области вспомогательных технологий. Я бы даже сказал, что факт его работы вне сферы вспомогательных технологий больше говорит о уровне его профессионализма.
Большая часть профессиональных незрячих программистов работают в обычных проектах по всему миру, в том числе в крупных корпорациях и в командах разработки очень крупных проектов, в том числе операционных систем.
Фактически этот тезис Михаила сводится к следующему: «покажите мне крупный проект для незрячих, разработанный русскими незрячими, или я буду считать, что незрячие, кроме меня, написавшего миллион строк в проекте LUWRAIN, сейчас ни на что не годны».
Прошу прощения, но до обсуждения таких заявлений мне опускаться бы не хотелось. Это просто даже выглядит неприлично.
> Пока я только вижу, что неоконная концепция позволяет нам работать больше и лучше, чем это могут делать пользователи давно известных решений.
Я не знаю, что загадочные люди скрываются под «нам», но та же NVDA представляется пока что намного более значимым в отрасли и технически сложным продуктом, чем LUWRAIN, и с его разработкой без проблем справляются исключительно незрячие, использующие стандартные графические среды.
Это не значит, что кто-то крутой специалист, а кто-то обязательно дурак, как постоянно пытается навесить ярлыки всем несогласным Михаил, но это означает, что на существующих технологиях незрячие могут делать очень сложные вещи, и это неоспоримый факт, доказываемый эмпирически последние несколько десятилетий, в течение которых развивались программы экранного доступа для графических сред.
> LUWRAIN интересно разрабатывать. Конечно! Потому что мы строим решение, исходя из тех задачь, с которыми сталкиваемся непосредственно в работе. Только ведя разработку можно точно понять, что должно быть.
Это и есть одна из главных проблем LUWRAIN. Реальных повседневных пользователей у него буквально несколько человек, да к тому же это те, кто плохо себе представляет полный ландшафт вспомогательных технологий. В этом смысле забавно читать акцентированное «мы», противопоставляемое опыту за все годы уже нескольких сотен тысяч (если не миллионов) незрячих по всему миру, работающих с другими решениями.
Простейший пример — чтение пунктуации. Обычно незрячий разово настраивает удобный ему уровень подробности чтения неалфавитных знаков.
Если всё примерять только на себя, то в продукте будет гвоздями прибит тот уровень детализации, который кажется разработчику подходящим.
Однако здесь как раз и требуется настройка, которой сам разработчик может никогда не будет пользоваться, но которая нужна остальным пользователям, чтобы настроить эту важную часть функциональности под себя.
Именно этим и объясняется, что в LUWRAIN нет кучи базовых вещей в той же навигации по простому тексту, которые нужны, чтобы разные люди могли решать актуальные для них задачи: бегло прочитывать текст или наоборот вычитывать по словам или даже буквам, править трудно выявляемые без зрения ошибки и так далее.
Вместо этого предоставляется крайне мало функциональная система доступности интерфейса, которая соответствует суженным потребностям нескольких «мы», но агрессивно позиционируемая с передёргиванием фактов как самое доступное и функциональное, что есть в индустрии.
> Тематика ресурса, к счастью, не даст никого ввести в заблуждение, что возможность написать скрипт на Python, где даже подсветка будет озвучиваться, это так же круто, как и вести масштабную разработку на Java.
Очередной пример либо лукавства, либо некомпетентности.
Я уже отмечал, что в графических средах задача написания кода с доступным представлением подцветки синтаксиса решена была ещё до создания проекта LUWRAIN. Это было сделано наверное в начале двухтысячных. Также там есть интеллектуальное озвучивание отступов кода, а в отдельных IDE вполне доступны вещи, типа быстрого перехода по структурным элементам и так далее.
Михаил либо намерено продолжает подтасовывать факты, высасывая из пальца преимущества LUWRAIN за счёт искажения фактов об альтернативных решениях, либо просто не читает, что ему пишут.
В любом случае, это показывает его неготовность к обсуждению поднятых вопросов.
Ещё раз обращаю внимание, что фактически спор ведётся вокруг того, что Михаил в качестве преимуществ LUWRAIN обещает в будущем сделать вещи, которые в альтернативных решениях сделаны лет пятнадцать назад, просто он не удосужился об этом узнать.
> 1. Факты существования механизмов для создания доступа к API для людей с нарушениями зрения.
См. выше, где я написал, что эта задача решается на основе любого языка программирования и любой доступной технологии GUI.
Причём, сейчас текст какого-нибудь поста из социальной сети, отображённый в LUWRAIN, читать менее удобно и функционально, чем тот же текст, отображённый в доступном GUI, поверх которого запущена современная программа экранного доступа.
Эта та вещь, которая провалена в LUWRAIN и из-за которой интерфейс LUWRAIN не является самым удобным для незрячих. В очередной раз отсылаю к своим аргументам по этому вопросу, которые Михаил проигнорировал, предпочтя ограничиться бахвальством диссертацией не по теме дискуссии.
> 2. Факты успешных масштабных проектов, которые ведут незрячие в России с использованием тех самых давно и хорошо проработанных методов доступности.
См. выше, где я объяснил, почему привязка к российским разработкам — это спекуляция, и почему нельзя оценивать эффективность работы незрячих программистов только по проектом для незрячих, в которых они задействованы.
> 3. Желаю встретить Никиту на конференции, где он мне лично покажет, как он делает презентации в доступном офисе без посторонней помощи.
Михаил опять грубо передёргивает.
На Windows с программой экранного доступа можно сделать презентацию как в TeX, то есть точно также, как он предлагает делать внутри LUWRAIN, а также при помощи PowerPoint и ряда других решений, в том числе генерирующих слайды из абсолютно доступных для незрячих текстовых файлов с разметкой Markdown. То есть доступными являются все эти варианты, а LUWRAIN лишь обещает сделать доступным один из них.
То, что Михаил отказывается принять реальность, что незрячий может сделать презентацию в PowerPoint, делает бессмысленной весь этот спор. Человек просто не признаёт факты.
- Вот учебник по созданию презентаций в PowerPoint без зрения (специально показываю достаточно старый материал, чтобы подчеркнуть то, что это норма уже долгие годы)
- Вот ролик на YouTube, где девушка показывает азы этого процесса.
и, разумеется, в этих материалах показаны не все доступные возможности.
То, что Михаил общается с людьми, которые этого не знают и/или не понимают, лишний раз демонстрирует общую некомпетентность команды LUWRAIN и их оторванность от актуального состояния вспомогательных технологий для незрячих.
Если на конференциях никто не смог ему до сих пор это показать и объяснить, то не думаю, что вообще имеет смысл ходить на такие конференции, и уж тем более воспринимать их как источник знаний о переднем крае индустрии.
И, конечно, никто бегать за Михаилом по конференциям не собирается, только ради сомнительного удовольствия показать ему то, существование чего он намерено игнорировал все эти годы. Это позиция какого-то маленького капризного мальчика, топающего ножкой с криком «Не верю! Не верю!»
> 4. Да и про кроссплатформенность все как-то забыли. Холивар на тему Linux и Windows устраивать не будем, но мне нужны факты доступных, ну не знаю, хотя бы читалок книг в Linux.
См. на всё тот же ответ про существующие варианты поддержки API.
Если взять какой-нибудь кроссплатформенный язык программирования и wxWidgets после чего написать на нём читалку книг, то можно собрать её как приложение для Windows, Linux и macOS, доступное для существующих программ экранного доступа на всех этих системах.
Простейший пример — это звуковой редактор Audacity — обычное приложение для всех, написанное на wxWidgets, собираемое для нескольких операционных систем и являющееся доступным на всех них.
Это тот самый альтернативный путь, существование которого столь настойчиво отрицается представителями LUWRAIN.
Хорошо, пусть есть желание идти другим путём. Проблема в том, что базовой интерфейс LUWRAIN сейчас менее удобен, чем интерфейс, который можно было бы разработать на доступной технологии GUI и потом озвучить программами экранного доступа. И этот вопрос Михаил сторательно обходит, делая вид, что отсутствие базовых функций по невизуальному взаимодействию с текстом это нормально.
Ну а теперь я всё-таки вернусь к тому, с чего мы начинали.
Я ещё раз прошу предметно описать якобы существующие проблемы выделения текста в графических средах с использованием программ экранного доступа.
Михаил публично соврал в этом вопросе, а потом увёл тему в сторону. Однако я бы всё-таки хотел получить либо публичный аргументированный ответ, либо публичное признание, что он ошибся.
Я наоборот утверждаю, что удобство и функциональность работы с текстом в поле редактирования в LUWRAIN на сегодняшний день ниже, чем в каком-нибудь Блокноте Windows с программой экранного доступа. Свои аргументы я привёл в конце самого первого комментария.
Ну и я также ожидаю спокойного ответа по тем же презентациям, которые, по словам Михаила, нельзя в PowerPoint делать при помощи программ экранного доступа, но я выше показал ссылки на инструкции и прямые демонстрации, которые доказывают обратное.
Причём, убедительно прошу перестать использовать грязный полемический приём Галоп Гиша и не множить взаимные доводы, пока не будет дан ответ на предыдущие. Человек, так часто посещающий конференции и закончивший аспирантуру, всё-таки должен придерживаться стандартов академической дискуссии, а не спорить как на базаре, переходя на личности и параллельно с публичным разговором пописывая гадости на личную почту с кабатской лексикой.
Пока Михаил не выполнит обязательства добросовестного участника дискуссии и не ответит по пунктам на доводы оппонента, я не вижу смысла продолжать этот разговор. Своим поведением он лучше меня справляется с дискредитацией отстаиваемой им точки зрения.
отмечу, что wxPython не требует строгого визуального контроля для создания интерфейса
wxWidgets вообще отличная кроссплатформенная библиотека. Тоже ее использую для своих программ.
Первое время когда искал технологию GUI, доступную экранным дикторам, еще пытался попробовать QT, но к сожалению она оказалась не доступной. Вроде в пятой версии писали, что это частично пофиксили, но к тому времени уже нашел wxWidgets, который удовлетворил все необходимое.
И самое главное, что программы создаются подходящие не только для незрячих, но и зрячие могут пользоваться.
Я уже давно потерял нить дискуссии, просто перешлю ответ Михаила как есть. Сейчас он где-то в разъездах, насколько я понял.
>Вот учебник по созданию презентаций в PowerPoint без зрения
> (специально показываю достаточно старый материал, чтобы подчеркнуть
> то, что это норма уже долгие годы)
>Вот ролик на YouTube, где девушка показывает азы этого процесса.
Поскольку я сейчас в дороге, мне трудно прослушать ролик.
Там существует возможность добавить программируемый ли рисунок или ноты?
Без внешней помощи, естественно.
Надеюсь, что эти задачи не считаются несущественными для проблем образования.
Вот примеры двух презентаций, сделанными без визуального контроля людьми без зрения:
marigostra.ru/materials/KamerataTeX2018.html
marigostra.ru/materials/presentation-mapreduce-tsu-2011-03-02.pdf
Они содержат рисунки, диаграммы, математические формулы, вставленные в рисунки, и пр. Некоторые возможности в них не раскрыты, как, например, формула в роли подписи оси диаграммы или ноты, но это возможно.
Прошу предоставить демонстрацию эквивалентных возможностей, которая без всякого сомнения существует,
раз предлагаемое решение давно стало нормой.
По первой ссылке доступны также исходные материалы, которые наглядно показывают,
что создавать конструкции в Gnuplot, Metapost, TeX вручную крайне неудобно.
Подчёркиваю, что речь идёт о 100% кроссплатформенном решении. Естественно, запрашиваемая мною демонстрация «нормы» должна быть в кроссплатформенном режиме.
>То, что Михаил общается с людьми, которые этого не знают и/или не
> понимают, лишний раз демонстрирует общую некомпетентность команды
> LUWRAIN и их оторванность от актуального состояния вспомогательных
> технологий для незрячих.
Прошу занести в протокол. Атака с переходом на личности.
>Если на конференциях никто не смог ему до сих пор это показать и
> объяснить, то не думаю, что вообще имеет смысл ходить на такие
> конференции, и уж тем более воспринимать их как источник знаний о
> переднем крае индустрии.
Ещё раз. Точно ли можно вставлять невизуально диаграммы, ноты, программируемые рисунки и формулы с возможностью работы как в Windows, так и в Linux?
Вдруг все мероприятия у нас делают и вправду какие-то некомпетентные люди.
>Если взять какой-нибудь кроссплатформенный язык программирования и
> wxWidgets после чего написать на нём читалку книг, то можно собрать
> её как приложение для Windows, Linux и macOS, доступное для
> существующих программ экранного доступа на всех этих системах.
С C/C++ Совместимости на уровне бинарного кода нет.
Использование с реализацией логики на Python сразу нанесёт удар по скорости и создаст серьёзные проблемы совместимости. См. ниже.
Так что утверждение глубоко ошибочное.
>Простейший пример — это звуковой редактор Audacity — обычное
> приложение для всех, написанное на wxWidgets, собираемое для
> нескольких операционных систем и являющееся доступным на всех них.
Глубоко ошибочное утверждение. Привожу ниже фрагмент письма из нашего сообщества, где пользователь оценивает доступность Audacity в Linux.
Считается ли это качественным уровнем доступа?
Имеет ли автор опыт успешной работы с Audacity в Linux?
Если да, прошу демонстрацию работы.
>Это тот самый альтернативный путь, существование которого столь настойчиво отрицается представителями LUWRAIN.
Прошу демонстрацию высококачественной доступности приложений на wxWidgets в Linux.
С трудом понимаю, на чём основано это утверждение.
>Хорошо, пусть есть желание идти другим путём. Проблема в том, что
> базовой интерфейс LUWRAIN сейчас менее удобен, чем интерфейс,
> который можно было бы разработать на доступной технологии GUI и
> потом озвучить программами экранного доступа. И этот вопрос Михаил
> сторательно обходит, делая вид, что отсутствие базовых функций по
> невизуальному взаимодействию с текстом это нормально.
Автор этих строк совершенно забывает, что массового релиза LUWRAIN в сообществе незрячих мы не проводили.
Глубоко уверен, что местом для анонсов приложений именно для пользователей является рассылка Тифлокомп.
Прошу показать наш анонс в этой рассылке.
Другими словами, наши публикации были сугубо информационными для людей, интересующихся разработкой.
Обратите также внимание, что и обсуждение мы ведём на ресурсе для разработчиков.
Это объясняется тем, что работа была сфокусирована над платформенными компонентами.
Мы даже не обещали, что 100% пользовательский функционал планируем писать сами,
но и на этапе попытки обратить ьвнимание программистов на нашу работу столкнулись с агрессивной атакой.
Аналогично, и номера версий указывали, исходя из нашей оценки готовности платформенных компонентов.
О том, что мы работаем именно над платформой, написано на главной странице.
Мне трудно представить, по какой причине этот факт был совершенно упущен.
Следите за tiflocomp, мы будем постепенно выводить различный функционал в сообщество на основе LUWRAIN.
>Ну а теперь я всё-таки вернусь к тому, с чего мы начинали.
>Я ещё раз прошу предметно описать якобы существующие проблемы выделения текста в графических средах с использованием программ экранного доступа.
Как я могу выделить фрагмент текста в терминале Linux с возможностью
определить место окончания выделения путём поиска? Действительно ли
возможно выделение текста:
1. Везде, где это делают зрячие (то есть в терминале Linux, в окне
командной строки в Windows, при просмотре PDF и т. д.)
2. С возможностью выбрать место окончания выделения путём поиска
подстроки. Зрячему легко тянуть мышкой, но если у меня кусок большой, то
мне нужно иметь возможность определить окончание выделения поиском. При
редактировании кода, кстати, это одна из самых активно используемых у
меня операций, которая должна быть предельно упрощена без потери
удобства при росте размера фрагмента для выделения. Равно как и
копирование текста в терминале. Без этого мне трудно представить себе
активную деятельность.
3. В равной степени в Linux и в Windows.
Зрячие всё это делают абсолютно играючи.
Помимо этого, выделение текста ещё очень ограничено текущим элементом управления.
Прошу описание, как пользователь без зрения может выделить
весь текст на экране (в своём рабочем пространстве) или
произвольный его фрагмент.
Причём, естественно, как в Linux, так и в Windows.
Или выделить текст поля для ввода вместе с его подписью.
В LUWRAIN это совершенно обычная операция.
Для протокола: в чём было враньё?
>Я наоборот утверждаю, что удобство и функциональность работы с
> текстом в поле редактирования в LUWRAIN на сегодняшний день ниже,
> чем в каком-нибудь Блокноте Windows.
Автор в очередной раз совершенно упускает, что работа велась над платформенными компонентами,
чтобы предоставить возможность гибко реализовать такой функционал по редактированию текста, который будет максимально всех устраивать.
Это утверждение имело бы смысл,
если бы мы вели эту дискуссию в рассылке tiflocomp.
>Ну и я также ожидаю спокойного ответа по тем же презентациям,
> которые, по словам Михаила, нельзя в PowerPoint делать при помощи
> программ экранного доступа, но я выше показал ссылки на инструкции и
> прямые демонстрации, которые доказывают обратное.
Ноты, программируемые рисунки, диаграммы и формулы.
Естественно, в объёме, чтобы можно было бы подписать ось на диаграмме приличным интегралом.
Про Linux забывать не нужно.
>Это и есть одна из главных проблем LUWRAIN. Реальных повседневных пользователей у него буквально несколько человек.
В третий раз обращаю внимание, что это комментарий к техническому preview. Мы не проводили пользовательского релиза для незрячих.
Работу ведём, но в каком направлении и какими темпами, это уже наше дело.
Точнее, говоря о невостребованности проекта, автор этих строк
ставит под сомнение заключение экспертного совета «Технологий возможностей».
Допускаю, что право на частное мнение есть, но экспертное мнение для нас намного важнее.
Я глубоко убеждён, что прислушиваться стоит к мнению людей, доказавших свою компетенцию.
Оценка скорости разработки характеризует только качества финансовой поддержки разработок в сфере вспомогательных технологий в России.
Если, как утверждается, наш проект просуществовал почти десять лет, то это несомненное преимущество, поскольку характеризует нашу команду как прочный и устойчивый коллектив,
способной работать в условиях национальных санкций и экономического кризиса при постоянном падении уровня доходов населения.
Автор, кстати, исказил возраст проекта в полтора раза, первый коммит был в 2012 году,
но ещё раз повторюсь, что считаю большой возраст проекта сильнейшим преимуществом.
>Если всё примерять только на себя, то в продукте будет гвоздями прибит тот уровень детализации, который кажется разработчику подходящим.
По первой ссылке была дана страница с основным отличием LUWRAIN от прочих технологий.
Текст на этой странице начинается с того, что мы разрабатываем платформу,
поскольку считаем максимальную гибкость и раширяемость самым критическим условием.
Это утверждение по абсолютно непонятной мне причине не только не было воспринято конкретным,
но и до сих пор оставляет возможными опасения, что всё будет «прибито гвоздями».
Коллеги, вот именно это сводит наше обсуждение на нет, потому что я в панике от невнимательности собеседников
и вынужден повторить предложение читать аккуратней.
>Однако здесь как раз и требуется настройка, которой сам разработчик может никогда не будет пользоваться.
Пожалуйста, прочитайте текст исходного поста ещё раз.
Мне не хочется переходить на личности, но тут явное непонимание написанного текста.
>Я уже отмечал, что в графических средах задача написания кода с
> доступным представлением подцветки синтаксиса решена была ещё до
> создания проекта LUWRAIN.
Прошу показать, как при помощи экранных чтецов будет производиться сборка более-менее масштабного проекта (кроссплатформенно).
И, естественно, у нас нет никаких проблем, чтобы после сборки иметь возможность его пропатчить, найти утечки памяти и т. д.
Точно нам тут подсветка кода поможет?
Мне странно видеть, что при обсуждении процесса разработки автора интересует не автоматизация быстрого невизуального восприятия килотонн логов,
и даже не повышение доступности невизуального чтения diff'ОВ, а всего лишь подсветка текста.
Кстати, мне интересно узнать, каким способом автор разбирает вывод diff'а.
Неужели возможность пройтись по нему физически по буковкам считается достаточной?
>Это было сделано наверное в начале двухтысячных. Также там есть
> интеллектуальное озвучивание отступов кода, а в отдельных IDE вполне
> доступны вещи, типа быстрого перехода по структурным элементам и так
> далее.
К сожалению, работа программиста не сводится к структурным переходом.
Мне трудно себе представить отладку масштабного проекта с экранными чтецами.
Мне приходилось отлаживать падение весьма больших сборок,
и я честно пишу, подсветка кода и экранные читалки здесь бесполезны.
>Михаил либо намерено продолжает подтасовывать факты, высасывая из
> пальца преимущества LUWRAIN за счёт искажения фактов об
Ну что Вы! Я сугубо намеренно привожу максимальное количество фактов, наблюдая, что делаются утверждения,
ответы на которые были в самой первой нашей реакции на комментарии.
Да и вообще это атака. Я в дороге. Мне писать много сейчас трудно, но вот делаю это, раз пришлось.
>Ещё раз обращаю внимание, что фактически спор ведётся вокруг того,
> что Михаил в качестве преимуществ LUWRAIN обещает в будущем сделать
> вещи, которые в альтернативных решениях сделаны лет пятнадцать
> назад, просто он не удосужился об этом узнать.
А точно у нас WX Widgets надёжно работает в Linux, чтобы на нём можно было бы строить развитые интерфейсы?
Предлагаю ознакомиться с письмом ниже.
Это фактический опыт пользователя, который я всецело поддерживаю.
Ужасная манипуляция фактами.
>Михаил опять грубо передёргивает.
>На Windows с программой экранного доступа можно сделать презентацию как в TeX, то есть точно
Никита, естественно, не откажется мне показать этот процесс?
>Не существует никаких общепризнанных метрик оценки возможности
> предельного объёма кода, которым может оперировать незрячий или
> любой другой человек.
Наблюдаю попытку увести дискуссию в сторону при ответе на более чем конкретный вопрос.
Понятие существования проекта с исходниками и авторами — абсолютно однозначная вещь.
Как говорит всеми нами любимый Линус Торвальдс,
Talk is cheap, show me the code.
Я с ним абсолютно согласен.
>Михаил так и не сказал, что же такое происходит с большим кодом в каком-нибудь Notepad++, озвучиваемым
Автор этих строк точно уверен, какие проблемы появляются при обслуживании кода 100 кило строк и больше?
Я с ужасом представляю себе работу Никиты, который, видимо, читает diff'ы при помощи Notepad++.
Точно так же он, видимо, героически разбирает все логи в процессе отладки проекта современного масштаба непосредственно в Notepad++.
Особенное восхищение вызывает его умение найти отличия в двух пачках логов после внедрения патча,
даже в условиях, что diff не сообразит ничего из-за изменившихся отметок времени.
Логи он читает абсолютно произвольного размера.
Неужели он это делает, создав приложение на WEB UI?
>Большая часть профессиональных незрячих программистов работают в
> обычных проектах по всему миру, в том числе в крупных корпорациях и
> в командах разработки очень крупных проектов, в том числе
> операционных систем.
Самый авторитетный незрячий программист, которого знаю, оконными читалками как раз не пользуется.
Смотрите историю T.V. Raman, Emacspeak и начала разработки средств доступности в Google.
Это пример неосведомлённости.
>Прошу прощения, но до обсуждения таких заявлений мне опускаться бы не хотелось. Это просто даже выглядит неприлично.
Естественно, это показывает некомпетентность желающего делать такие заявления.
> LUWRAIN интересно разрабатывать. Конечно! Потому что мы строим решение, исходя из тех задачь, с которыми сталкиваемся
>написана в доступной кроссплатформенной форме на существующих
>технологиях GUI, например, wxWidgets или web UI.
О Боже мой!
1. Желаю видеть примеры нормальных доступных приложений в Linux на wxWidgets или в веб.
Нормальных и развитых, а не на уровне говорящих менюшек.
2. Сравнением Java и Python предлагаю не заниматься.
Помнится, что на Javaкогда-то был переписан Quake II с некритической потерей скорости.
Точно ли это эквивалентные инструменты?
Существуют ли подобные обоснования производительности для Python?
3. Разработка на Python неизбежно приведёт как раз к той ситуации, которая сложилась с доступностью для незрячих в Linux,
поскольку будут идентичные проблемы в смысле сохранения совместимости.
Существование различных версий проектов для Python2 и для Python3 неужели никого не пугает?
При этом я должен отметить чрезвычайно высокую совместимость кода на Java, в которой даже ошибки и недостатки сохранены,
чтобы не испортить работу приложений, уже учитывающих особенности.
Типичный пример — сохранение сравнения java.net.URL на равенство с резолюцией DNS, что, очевидно, было большой ошибкой.
4. Наличие компонентов. На Java у нас есть Maven. Точно ли это то же самое, что и pip?
Прошу привести, пожалуйста, пример полноценного браузерного движка с возможностью растеризации страниц и с поддержкой JavaScript.
Авторазметка Daisy даёт большую нагрузку на процессор. Прототипирование я делал на Python,
утверждать, что это не хуже, чем в LUWRAIN, как бы очень несерьёзно.
Если Никита знаком с тем, как это производится и к каким проблемам приводит, прошу здесь в паре строк охарактеризовать общую концепцию вычислительного процесса.
Какие методы обработки сигнала используются, какая математика и так далее.
Я даже не говорю, что для работы требуется весьма большая интерактивность,
которую мне трудно представить себе в оконном интерфейсе.
И точно также ещё дополняю, что писать отдельного клиента для доступа к каждому сервису — занятие безуммное.
LUWRAIN даёт интегрированную систему. Выделив любой фрагмент любой области,
пользователь может его отправить в Твиттер и т. д. одной командой.
Если это не круто, извините.
А теперь письмо из нашего сообщества, где наглядно оценивается качество доступности Audacity:
From: бердников александр <...@gmail.com>
Subject: [l-usr-ru] непонятки с аудасити
Date: Sun, 2 Jun 2019 05:06:36 +0500 (6 days, 11 hours, 18 minutes ago)
привет всем!
решил я поиграться с аудасити, но к своему удивлению обнаружил что
альтовое меню по эф десять не работает, только на цифровом блоке.
это конечно неприятный момент, но жить можно.
открыл я файлик и, для тренировки решил над ним поэксперементировать.
но обнаружилось что это меню куда-то сдвинулось, а под руки лезли
действия, которых я не запрашивал.
кое-как нашел раздел для выделения, но не смог выделить участок для обрезки,
что бы сделать экспортирование мне пришлось сначала задействовать
правку, а затем стрелкой влево сдвинуться в меню файл и, уже там
доделать задуманное.
помнится мне такого безобразия раньше не было.
тут и не поймешь кто виноват авторы приложения или разработчики гнома.
остается только миханически зазубрить горячие клавиши.
> Я уже давно потерял нить дискуссии, просто перешлю ответ Михаила как есть.
ofmetal, совершенно верно. Михаил старательно размывает границы и предмет дискуссии, используя приём Галоп Гиша, сводящийся к забрасыванию оппонента кучей новых доводов, не заботясь об их качестве и соответствии изначальной теме, а также игнорируя содержательную часть встречных доводов. Он требует всё следующих и следующих аргументов от оппонента, со своей стороны отказываясь обсуждать и признавать ранее приведённые доводы, полностью опровергающие его заявления, которые и являлись изначальным предметом дискуссии.
В своём новом сообщении Михаил 2 раза написал «прошу демонстрацию» и ещё по одному разу «пожалуйста, дайте», «прошу описание», «прошу показать» и «прошу привести», каждый раз расширяя общий объём дискуссии, но при этом со своей стороны не дал никаких предметных ответов на предыдущие доводы, в том числе с бесспорной демонстрацией существования того, что он отрицал, а именно являющуюся нормой долгие годы возможность работы в PowerPoint без зрительного контроля.
Он также здесь подвергает сомнению возможность создания презентации на Windows в простом текстовом редакторе при помощи TeX и стандартных программ экранного доступа, что является абсолютным нонсенсом, так как принципы этого процесса аналогичны тому, как он собирается это реализовывать в LUWRAIN и как он сам это делал все эти годы, а именно: набор нотации TeX в редакторе и компиляция этого файла в PDF посредством кроссплатформенных утилит, существующих под все распространённые системы, в том числе и Windows. В Windows также существуют инструменты типа специализированного TeX-редактора WinEdt, ещё больше облегчающего процесс работы с TeX, и всё это доступно и активно используется незрячими долгие годы.
В том числе, эти возможности являются комбинируемыми, в частности, вставка в презентации на PowerPoint формул, написанных на TeX, равно как и их вставка в альтернативные системы презентаций, например, генерирующих HTML-слайды из markdown. Более того, та же математика в презентациях на PowerPoint по ряду критерий более доступна, так как формулы могут быть не просто написаны, но и прочитаны со слайда без помощи зрения, тогда как продвигаемый Михаилом вариант имеет перекос в сторону создания.
Отсылки к его неудачному опыту пробы всех этих технологий когда-то давно являются лишь дополнительными доводами против него и уровня его исследовательской работы в области невизуальной доступности, потому что его вопросы про получение текста всего окна на Windows явно показывают, что он даже не прочитал список команд того же JAWS (JAWSKey+Alt+W (ранее до JAWS 11.0 в 2009 году JAWSKey+CTRL+W) и далее работа в окне виртуального просмотра), но сейчас хотелось бы закрыть хотя бы один пункт с презентациями, так что сосредоточимся на нём.
Итак, одним из первых пунктов дискуссии было заявление Михаила, что в графических средах, в том числе в связке PowerPoint с программой чтения экрана, невозможно без зрительного контроля создавать презентации. Это было одно из главных его программных заявлений, на основе которых он выводил тезис о неоспоримом фундаментальном превосходстве LUWRAIN над существующими альтернативами, когда его об этом в самом начале спросил пользователь DollaR84.
Михаил ссылался на свои якобы достаточные знания по этому вопросу, мнение каких-то специалистов по доступности высшего образования с каких-то конференций, а также якобы отсутствие фактических подтверждений этой возможности. Причём, делал это в достаточно невоздержанной агрессивной форме в безапелляционном менторском тоне.
В предыдущем комментарии Михаилу были предоставлены объективные подтверждения наличия такой возможности в виде существующих долгие годы методических материалов, а также живая демонстрация работы незрячего пользователя в PowerPoint на Windows с программой экранного доступа. Про инсинуации в последнем сообщении Михаила о якобы недоступности TeX на Windows сейчас даже и не говорим, потому что это уже пробивание дна.
В связи с этим, для продолжения дискуссии и рассмотрения аргументов следующего этапа, хотелось бы всё-таки услышать от Михаила одно из двух:
- Либо публичное признание собственной неправоты и недостаточной компетентности в вопросе доступности работы с презентациями в графических средах, равно как его консультантов с хвалённых конференций, на которых он активно ссылался как на истину в последней инстанции. Никаких самоуничижительных формулировок я не требую, достаточно лаконичного «Признаю, ранее озвученная мной информация не соответствует действительности; это было мне не известно, и привлечённые консультанты меня ввели в заблуждение, а я не проверил».
- Либо прямо сформулированное открытое конспирологическое обвинение в фабрикации приведённых доказательств на web.archive.org и YouTube с привлечением третьих лиц из разных стран.
Это последний раз, когда я призываю всё-таки ответить на приведённые объективные факты. Бесконечно повторять это нет никакого желания.
Пока Михаил не выполнит стандартных требований обоснованной дискуссии с последовательным взаимным рассмотрением аргументов друг друга, считать его добросовестным участником дискуссии не представляется возможным.
Таким образом, я ожидаю от Михаила добросовестного ответа на уже выдвинутые доводы, без которого рассмотрение дальнейших вопросов, которые он поднимает, не имеет никакого смысла, хотя и там им допущен ряд неточностей и грубых искажений, но об этом имеет резон говорить, только если он делом докажет свою способность вести дискуссию по академическим стандартам.
Tseikovets, можно, пожалуйста, ещё раз пояснить, за что я должен извиниться? Существование решения по презентациям по озвученным требованиям не представлено. Продолжу дискуссию, когда Никита ответит на все найденные мною абсолютно несомненные, на мой взгляд, недостатки его критики с огромным числом ошибок и использования непроверенных фактов.
> можно, пожалуйста, ещё раз пояснить, за что я должен извиниться?
Пока что в во всём текущем обсуждении с требованиями извинений выступал только один человек, и требовал он их за то, что его назвали так, как он сам публично подписался. Никто больше извинений ни от кого здесь не требовал, даже за откровенное хамство, которое допускали некоторые участники дискуссии.
Во всех остальных случаях речь лишь шла о предложении признать несоответствие сделанных заявлений фактическому состоянию дел, так как заявления были сделаны без должного исследования вопроса. Причём, признать это без громких самоуничижительных формулировок, а в спокойном рабочем режиме.
> Существование решения по презентациям по озвученным требованиям не представлено. Продолжу дискуссию, когда Никита ответит на все найденные мною абсолютно несомненные, на мой взгляд, недостатки его критики с огромным числом ошибок и использования непроверенных фактов.
Хорошо, зафиксируем итог дискуссии:
В самом начале пользователем DollaR84 спокойно был задан вопрос о фактических преимуществах LUWRAIN по сравнению с уже существующими технологиями невизуального доступа. От Михаила поступил расплывчатый ответ с указанием на спорные преимущества в виде якобы эксклюзивной доступности TeX. В ответ на справедливо высказанные пользователями marsalovv и DollaR84 сомнения, Михаил огульно обвинил людей в теоретизировании без понимания практики вопроса, причём, было написано следующее:
«Ваши рассуждения теоретические. В формально доступном офисе при помощи экранных читалок, например, элементарно выделение текста делать трудно, а презентацию создать люди чаще всего вообще не могут. Возможно, вы никогда не были на конференциях по высшему образованию для людей с нарушениями зрения, на них вашу точку зрения точно никто не разделяет.»
Это полная цитата Михаила из комментария от 18:24 06.06.2019 без какого-либо вырывания из контекста. Фактически там содержится 3 утверждения:
- В считающихся доступными для незрячих офисных пакетах якобы присутствуют проблемы с выделением текста.
- Незрячие якобы испытывают фундаментальные неразрешимые проблемы с подготовкой презентаций.
- Всё сказанное правда, потому что так считают какие-то люди с каких-то конференций.
Изначальным предметом дискуссии были именно эти три утверждения, ни одно из которых не соответствует действительности.
Михаилу в корректной форме было предложено предметно обосновать эти утверждения в аргументированной дискуссии, на что он ответил коротким достаточно хамским сообщением с обвинением в том, что никто кроме него из присутствующих в поднятой теме не разбирается.
Позже он всё же формально начал дискуссию, но предпочёл игнорировать объективные доказательства некорректности его заявлений, забрасывая оппонента всё новыми и новыми требованиями привести обоснования вещей, не имевших отношения к первоначальной теме, а затем попытался картинно встать на позицию, что это его оппонент, а не он сам, нарушил рамки и правила аргументированной дискуссии.
В реальности же:
- Во-первых, Михаилу были предоставлены объективные доказательства штатной возможности работы с графическими менеджерами презентаций без помощи зрения в виде одного из многих давно существующего методического пособия для незрячих, а также живой демонстрации работы незрячего пользователя с PowerPoint.
- Во-вторых, Михаилу было указано на то, что решение, предлагаемое в рамках LUWRAIN, а именно работа в текстовом редакторе с TeX, точно также доступно и в графических средах с программами экранного доступа, поэтому никаким преимуществом LUWRAIN это не является, а наоборот, лишь представляет собой суженное пространство возможностей по сравнению с использованием программ экранного доступа.
- В-третьих, от Михаила так и не были получены обоснованные объяснения, что именно в доступных офисных пакетах он называет «проблемами с выделением текста». Михаил по данному вопросу попытался передёрнуть и перевести разговор на выделение текста в терминале Linux, хотя из вышеприведённого изначального заявления отчётливо видно, что речь была о якобы проблемах выделения в офисных пакетах.
- В-четвёртых, полностью дискредитированные в ходе дискуссии первые два утверждения Михаила автоматически дискредитируют и третье, сводящееся к тому, что его позиция поддерживается какими-то людьми с каких-то конференций. Можно лишь констатировать, что как Михаил, так и его знакомые с конференций, одинаково плохо разбираются в вышеупомянутых вопросах.
Я не Михаил, поэтому не буду никого называть полным дураком. Я не подвергаю сомнению компетентность и квалификацию Михаила в вопросах программирования как такового и признаю за ним хорошие знания в области невизуальной доступности Linux, особенно в сфере неграфических сред.
Однако в области общего ландшафта вспомогательных технологий на разных системах и принципиальной доступности тех или иных задач без зрительного контроля Михаил в рамках этой дискуссии продемонстрировал полнейшую некомпетентность и безграмотность. Представленная выше выжимка всей дискуссии это доказывает вполне однозначно, а текст содержит ссылки на упомянутые комментарии, так что любой желающий может с ними ознакомиться в оригинале и убедиться самостоятельно.
Кроме того, сама манера ведения дискуссии у Михаила бескультурна и крайне токсична, да и не соответствует академическим стандартам: это касается как хамских заявлений, с которых он начал, так и недобросовестных полемических приёмов в виде смены темы, передёргивания и Галопа Гиша, которыми продолжил.
Полноценная дискуссия невозможна, когда одна из сторон нарушает правила, а также не обладает достаточными знаниями, чтобы в принципе работать с аргументацией оппонента, как, например, Михаил не знает на должном уровне и в актуальном состоянии принципы и возможности невизуальной работы на системах типа Windows или macOS, невизуальную работу в пакете Microsoft Office, ну или работу с TeX вне Linux.
Даже просто то, как Михаил вёл эту дискуссию, достаточно дискредитирует его позицию по поднятым вопросам, ну а для реальных специалистов, владеющих актуальными знаниями по невизуальной доступности графических сред вне Linux, слабость позиции Михаила очевидна с первых же строк.
Сам же Михаил не заинтересован в расширении своих знаний, хотя и разрабатывает кроссплатформенное решение с пафосным позиционированием в виде якобы самого удобного для незрячих интерфейса, однако и это сейчас также не является правдой, поэтому продолжать что-то объяснять лично ему бесполезно.
Ввиду этого задачу данной дискуссии я считаю выполненной и со своей стороны её прекращаю.
Dixi.
А почему нет? Давно с маком, еще давнее с виндами, периодически поглядываю на линуксы. Всё, разумеется, с говорилками. И с каждым годом всё становится аксисибилетнее и аксисибилетнее! :) Возможностей для разработки очень достаточно. Вот про что не знаю, так это про презентации :) А так, извините, но подобные решения мне видятся костылем… имхо
Полностью с вами согласен. Как я и написал был ниже, скачал попробовал — костыль есть костыль. Лучше юзать стандартные средства ОС плюс говорилка + норм программы сделанные с хорошей доступностью. А эта оболочка не поможет с недоступными программами, для нее придется писать расширение, так называемые ее приложения. Что гораздо удобнее написать сразу для нужной ОС.
Ваши рассуждения теоретические. В формально доступном офисе при помощи экранных читалок, например, элементарно выделение текста делать трудно, а презентацию создать люди чаще всего вообще не могут. Возможно, вы никогда не были на конференциях по высшему образованию для людей с нарушениями зрения, на них вашу точку зрения точно никто не разделяет.
Выделение текста везде в любых редакторах делается просто очень и в офисе также, вообще не пойму какая тут может быть трудность.
Насчет презентаций уже писал.
Да в формате TeX можно сделать, но я этим не занимался.
Вот только там идет описание специальным синтаксисом, что делается снова в любом редакторе.
Напишите как данная платформа облегчит данный процесс?
На конференциях да я не был, но я уже 5 лет незрячий и все это время активно занимаюсь программированием.
Расскажите что я упустил? я же не против новых инструментов облегчающих работу. Вот только каким образом данная платформа улучшит работу не теоретически на конференциях, а практически для пользователя ПК.
Почему нельзя делать просто хорошие доступные приложения, вместо того чтоб писать специализированные расширения для довольно узкоприменимой оболочки.
Насчет презентаций уже писал.
Да в формате TeX можно сделать, но я этим не занимался.
Вот только там идет описание специальным синтаксисом, что делается снова в любом редакторе.
Напишите как данная платформа облегчит данный процесс?
На конференциях да я не был, но я уже 5 лет незрячий и все это время активно занимаюсь программированием.
Расскажите что я упустил? я же не против новых инструментов облегчающих работу. Вот только каким образом данная платформа улучшит работу не теоретически на конференциях, а практически для пользователя ПК.
Почему нельзя делать просто хорошие доступные приложения, вместо того чтоб писать специализированные расширения для довольно узкоприменимой оболочки.
ElenaTep, я ответственно утверждаю, что это ваши рассуждения носят сугубо теоретический характер и что озвученные вами факты о проблемах доступности данных задач в графических интерфейсах с программами экранного доступа некорректны.
Вы готовы здесь и сейчас также публично, как и высказали эти свои утверждения, подробно сформулировать суть проблем с выделением текста и с подготовкой презентаций вне LUWRAIN? Я знаком с обоими концами технологий (и LUWRAIN, и программы экранного доступа (разные и под разными OS)). Рассчитываю на такой же уровень дискуссии и с вашей стороны.
Абстрактные беспредметные доводы о каких-то конференциях я принимать отказываюсь, хотя бы на основании того, что являюсь одним из авторов первичных материалов в корпусе текстов, на которые ссылаются многие участники этих конференций, а также автором тех материалов, которые они используют в своей работе как методические.
Вы готовы подтвердить свои утверждения лаконичным списком конкретных доводов? Ещё раз прошу делать это на этой же площадке столь же публично, как и сами эти утверждения.
Вы готовы здесь и сейчас также публично, как и высказали эти свои утверждения, подробно сформулировать суть проблем с выделением текста и с подготовкой презентаций вне LUWRAIN? Я знаком с обоими концами технологий (и LUWRAIN, и программы экранного доступа (разные и под разными OS)). Рассчитываю на такой же уровень дискуссии и с вашей стороны.
Абстрактные беспредметные доводы о каких-то конференциях я принимать отказываюсь, хотя бы на основании того, что являюсь одним из авторов первичных материалов в корпусе текстов, на которые ссылаются многие участники этих конференций, а также автором тех материалов, которые они используют в своей работе как методические.
Вы готовы подтвердить свои утверждения лаконичным списком конкретных доводов? Ещё раз прошу делать это на этой же площадке столь же публично, как и сами эти утверждения.
Никита, твоя интонация эксперта смешна. Помни, что у меня за спиной получение диплома программиста и аспирантура там же, в чём ты 100% ничего не понимаешь. Что могут читалки и болталки в этом деле, лучше не обсуждать. И на конференциях я тебя никогда не видел. (с) Дядя Миша.
Аргументированно! И что самое важное – без перехода на личности! Теперь все преимущества LUWRAIN Ясны и неопровержимы! Спасибо! :)
у меня за спиной получение диплома программиста и аспирантура там же, в чём ты 100% ничего не понимаешь
Зато я понимаю, работал в it компании Software Developer`ом.
Расскажите мне преимущества вашей платформы, дядя Миша, по сравнению, например, с Visual Studio, ну или хотя бы над Notepad++.
Напомню, что и то и другое доступно благодаря читалке.
Или только на конференциях правда жизни?
А остальные совсем тупые и ничего не понимают, правильно я вас понял?
DollaR84, где я могу ознакомиться с исходным кодом, написанным Вами? Мне это важно знать. LUWRAIN — кроссплатформенное решение, это очевидное преимущество.
На вопрос о преимуществах вашей платформы, вы написали что у вас диплом программиста в чем ваш собеседник ничего не понимает. Я написал что понимаю, расскажите эти преимущества для ознакомления, мне как программисту интересно.
Вы же вдруг перескакиваете на просмотр моего кода, снова манипуляция и увод разговора в другую степь.
Ну а чтоб вам было легче, с моим кодом для automotiv ознакомиться нельзя, если вы знакомы с таким понятием как NDA, то должны понимать.
Вы же вдруг перескакиваете на просмотр моего кода, снова манипуляция и увод разговора в другую степь.
Ну а чтоб вам было легче, с моим кодом для automotiv ознакомиться нельзя, если вы знакомы с таким понятием как NDA, то должны понимать.
DollaR84,
Коллега, я искренне сожалею, что наше с Вами знакомство состоялось при таких неприятных обстоятельствах, и выражаю надежды, что мы сможем установить общение на принципах взаимного уважения. Со своей стороны готов принести извинения, если причиной тому были мои высказывания. По вопросам разработки мы ставим цель максимально подготовить основу для невизуального восприятия больших массивов данных, неизбежно возникающих в ходе работы, логи, диффы, выводы strace и valgrind. Их формальная доступность к практической пользе не приводит. Обязательно при доступности процесса в Linux. Плюс автоматизация написания конструкций в TeX, чтобы сделать его дружественный для массового незрячего студента и аспиранта. Искреннее Вам приветствие!
Коллега, я искренне сожалею, что наше с Вами знакомство состоялось при таких неприятных обстоятельствах, и выражаю надежды, что мы сможем установить общение на принципах взаимного уважения. Со своей стороны готов принести извинения, если причиной тому были мои высказывания. По вопросам разработки мы ставим цель максимально подготовить основу для невизуального восприятия больших массивов данных, неизбежно возникающих в ходе работы, логи, диффы, выводы strace и valgrind. Их формальная доступность к практической пользе не приводит. Обязательно при доступности процесса в Linux. Плюс автоматизация написания конструкций в TeX, чтобы сделать его дружественный для массового незрячего студента и аспиранта. Искреннее Вам приветствие!
Спасибо за начало более конструктивной беседы.
А будут ли более технические статьи, или можно где почитать какую-то типа справки как например мне данной платформой посмотреть диффы с моего локального git репозитория?
Да и еще, не знаю как у вас, а у меня ваш синтезатор запустился вместе с запуском программы только один раз, сразу после установки. При повторном запуске программа запускается, но без синтезатора. Из-за чего становится абсолютно не доступной. Известна ли данная проблема и есть ли пути решения?
А будут ли более технические статьи, или можно где почитать какую-то типа справки как например мне данной платформой посмотреть диффы с моего локального git репозитория?
Да и еще, не знаю как у вас, а у меня ваш синтезатор запустился вместе с запуском программы только один раз, сразу после установки. При повторном запуске программа запускается, но без синтезатора. Из-за чего становится абсолютно не доступной. Известна ли данная проблема и есть ли пути решения?
DollaR84, под какой ОС Вы запускали? Если в Linux, то лучше использовать вывод речи через speech-dispatcher. Нам пришлось экстренно подготовить модуль к нему из-за похожих проблем. Он есть в nightly-сборке.
нет, не линукс, windows 8.1.
скачана сборка, которую можно использовать как запускаемую программу.
скачана сборка, которую можно использовать как запускаемую программу.
В Windows таких жалоб никогда не было. Давайте, пожалуйста, попробуем найти причину через создание luwrain-debug.txt
Нас уже минимум двое! :) win 10 x64. Вылечилась удалением папки luwrain из апдаты и переустановкой, но это так себе решение…
Одним из ключевых преимуществ вы заявляете Кроссплатформенность. Как насчёт разработки под Mac OS?
ElenaTep я сделал лог, на какую почту отправлять?
DollaR84, статьи будут точно. Недостаток документации присутствует, мы пытаемся привлечь людей, чтобы нам помогли с этим. Сейчас построена программа действий по выводу функционала в пользовательское пространство. В первую очередь попробуем отладить этот процесс на функциональности чтения книг. Если всё получится, то приступим к другим компонентам, включая Git и доступ к API github.
Подготовка фундамента, который мог бы быть приспособлен для достаточно разнообразных задач, оказалась очень сложной проблемой. Я полагаю, что нам это удалось, поэтому постепенно переходим к пользовательским задачам. Со звуком надо разобраться непременно. В Windows таких проблем не было ни разу.
О том, какие функции мы выводим в жизнь, можно следить в нашей рассылке. При более-менее устойчивом состоянии будет писать в тифлокомп.
Вы можете создать файл luwrain-debug.txt в Вашем домашнем каталоге, и тогда при следующем запуске системы там должны появиться отладочные сообщения. Изучение содержимого лога может помочь установить причину отсутствия звука. Если никто не против, пошлите, пожалуйста, лог в нашу рассылку.
Подготовка фундамента, который мог бы быть приспособлен для достаточно разнообразных задач, оказалась очень сложной проблемой. Я полагаю, что нам это удалось, поэтому постепенно переходим к пользовательским задачам. Со звуком надо разобраться непременно. В Windows таких проблем не было ни разу.
О том, какие функции мы выводим в жизнь, можно следить в нашей рассылке. При более-менее устойчивом состоянии будет писать в тифлокомп.
Вы можете создать файл luwrain-debug.txt в Вашем домашнем каталоге, и тогда при следующем запуске системы там должны появиться отладочные сообщения. Изучение содержимого лога может помочь установить причину отсутствия звука. Если никто не против, пошлите, пожалуйста, лог в нашу рассылку.
приступим к другим компонентам, включая Git и доступ к API github.
Вот снова вы ограничиваетесь одним GitHub. Но мне не нужен GitHub, у меня свой локальный репозиторий. С вашим подходом, снова вы сделаете один шаг для пользователей, но куча других вариантов использования снова останутся за бортом.
Вы пишите никогда не было проблем со звуком на виндовс. У меня на виндовс 8.1 проблема. Звук есть, бульканье идет при переходах, а синтезатор молчит. Да и все же хотелось возможность выбора синтезатора из доступных, пускай как альтернативная опция от встроенного.
А насчет файла лога, под виндовс, где ваша программа будет его искать?
DollaR84, Кстати, сообщение было адресовано Никите и больше никому. Я позволил неформальную интонацию, поскольку мы с ним давно знакомы. Но я не уверен, что мы находимся в отношениях с кем-либо из этого обсуждения, которые позволили бы фамильярное обращение «дядя Миша» ко мне. Кто бы это ни написал, естественно, жду извинений
сообщение было адресовано Никите и больше никому.
Для таких сообщений на хабре есть приватные сообщения если вы не в курсе.
А публичные комментарии — это место для общего обсуждения.
Если это вас так задевает, то прошу прощения, но впредь прошу
позволил неформальную интонацию
позволять себе только в приватных сообщениях, а в публичных обсуждениях выражайтесь так, чтоб цитирование вас же самих не дергало ваши скрепы.
ElenaTep, принимать участие в истериках мне не интересно. Я предпочитаю более высокий уровень культуры общения и ведения дискуссии. Могу лишь повторить, что всё ещё жду здесь для профессионального обсуждения публичное озвучивание лаконичного списка якобы проблем доступности выделения текста в графических интерфейсах с использованием программ экранного доступа, причём, соответствующего реальным фактам и технически грамотного, а не размахивание диссертацией, которая не имеет к поднятой теме никакого отношения и, насколько я знаю, относилась к алгоритмам решения задачи маршрутизации транспорта. Ну а то, что при разработке LUWRAIN не была проведена исследовательская работа по ознакомлению с современным состоянием всех доступных решений в области невизуальной доступности так и вообще свидетельствует о плохом владении научным методом, где анализ предшествующего опыта должен являться первым этапом любой работы.
Я даже не поленился скачал и попробовал. Какой кошмар.
Хоть бы дали возможность выбора голос синтезатора из доступных, этот булькающий…
Попробовал зайти в настройки синтезатора. И не смог из них выйти обратно. Видишь ли неправильно заданы параметры скорости и высоты голоса.
Вот при обучении незрячих на таких платформах — они и не знают как работать на ПК и даже не хотят учиться.
Прочитал на сайте в разделе FAQ:
Мы используем компонент javafx.scene.web.WebEngine из состава JavaFX, поскольку он поддерживает JavaScript и предоставляет доступ к структуре DOM загруженной страницы. Этот компонент основан на движке WebKit, который является базой некоторых распространённых браузеров, например, Google Chrome.
И вы писали как я буду делать то-то или то-то через браузер. А в итоге вы предлагаете все делать через такой самописный браузер, даже обзор файлов на компьютере…
После такого у меня больше нет вопросов…
Хоть бы дали возможность выбора голос синтезатора из доступных, этот булькающий…
Попробовал зайти в настройки синтезатора. И не смог из них выйти обратно. Видишь ли неправильно заданы параметры скорости и высоты голоса.
Вот при обучении незрячих на таких платформах — они и не знают как работать на ПК и даже не хотят учиться.
Прочитал на сайте в разделе FAQ:
Мы используем компонент javafx.scene.web.WebEngine из состава JavaFX, поскольку он поддерживает JavaScript и предоставляет доступ к структуре DOM загруженной страницы. Этот компонент основан на движке WebKit, который является базой некоторых распространённых браузеров, например, Google Chrome.
И вы писали как я буду делать то-то или то-то через браузер. А в итоге вы предлагаете все делать через такой самописный браузер, даже обзор файлов на компьютере…
После такого у меня больше нет вопросов…
Мы добавили пример ответа на вопрос, как LUWRAIN может повысить доступность, в наш FAQ: luwrain.org/doc/faq. Надеемся, что это достаточно конкретный пример, который может рассматривать как факт. vk.com/away.php?to=http%3A%2F%2Fluwrain.org%2Fdoc%2Ffaq
Tseikovets вам выше уже написал, что любое API доступно на множестве языков программирования, поэтому создание программы с API и нормальным графическим интерфейсом с доступностью можно делать на многих ЯП, поэтому тут преимущества никакого нет.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доступ в интернет открыт: технология LUWRAIN помогает слепым пользователям