Custom Search

vendredi 29 juin 2012

What's New In Google Accessibility From Google I/O 2012

Google IO 2012: What's New With Google Access

1 Google IO 2012: What's New From Google Access

We showcased a number of exciting advances in accessibility on Android and Chrome during IO 2012. With these advances, blind and low-vision users can leverage Google applications and services on Android and Chrome to collaborate effectively with their peers and to obtain on-the-go access. Advances include out-of-the-box access on Android (JellyBean), a new set of gestures that enable fluent interaction on touch-screen devices, Braille support on Android, an extension framework for ChromeVox, and a new, high-quality voice for use with Web applications on Chrome.

1.1 Enhanced Android Accessibility In JellyBean:

  • Accessibility on Android can be enabled by long-pressing with two fingers (4 seconds) the setup screen to enable out-of-the-box access for blind users.
  • Touch exploration has been enhanced with simple gestures that enable users navigate on-screen contents.
  • JellyBean provides a set of Accessibility Actions that can be called from any AccessibilityService such as TalkBack; it also provides early support for Braille displays.
  • Touch exploration and gesture navigation both set AccessibilityFocus —

double-tapping anywhere on the screen activates the item with AccessibilityFocus .

  • TalkBack now has a sister service BrailleBack for providing Braille support on Android.
  • Chrome on Android is now accessible and supports the latest in Web Access standards.

With these enhancements in Android access, blind users can use a combination of touch exploration and navigational gestures to access any part of the Android user interface.

As an example, I typically use the Android Play Store by touching the screen around the area where I expect a specific control; quick flicks of the finger then immediately get me to the item I want. With these touch gestures in place, I now use touch exploration to learn the layout of an application; with applications that I use often, I use a combination of muscle memory and gesture navigation for rapid task completion.

1.2 Chrome OS On Chrome Books And Chrome Box

Chrome OS comes with ChromeVox pre-configured — ChromeVox is our Web Accessibility solution for blind users. With the new high-quality voice that is being released on the Chrome Webstore, ChromeVox now provides smooth spoken feedback in Chrome on all desktop environments. Finally, we announced a flexible extension framework that enables Web developers leverage ChromeVox from within and outside of their own Web applications to provide rich, contextual spoken feedback.

1.3 Developer Tools For Ensuring Accessibility

To help developers better leverage Web Accessibility, we are releasing a new Accessibility Audit tool that enables Web developers detect and fix commonly occuring accessibility errors. This tool has been integrated into Chrome's Developer Tools and helps Web developers ensure accessibility while working within their normal workflow.

1.4 Accessibility Related Presentations At Google I/O 2012

Catch these on Youtube in the next week if you weren't able to attend I/O this week.

  • Android Accessibility (T. V. Raman,Peter Lundblad, Alan Viverette and Charles Chen).
  • Advanced Web Accessibility (Rachel Shearer, Dominic Mazzoni and Charles Chen).
  • What's New In JellyBean: Android Team.
  • JellyBean announcement in the Wednesday keynote.

Date: 2012-06-21 Thu

Author: T.V Raman

Org version 7.8.11 with Emacs version 24

Validate XHTML 1.0

jeudi 29 décembre 2011

(Translations) Запитайте себе "А що б зробив користувач?"

Переклад статті з книги 97 Things Every Programmer Should Know про те, як мислить юзер і як його краще зрозуміти. Більше стосується програмування, та думаю і тестерам може бути цікаво. Буду вдячний за будь-які зауваження щодо помилок чи неточностей. Також вдячний друзям за допомогу. Ну що ж, поїхали!

В оригіналі статтю можна прочитати тут.

Запитайте себе "А що б зробив користувач?"

Giles Colborne
Ми всі часто припускаємо, що інші люди думають так само як і ми. Але це не так. Психологи називають це упередженням несправжньої згоди. Людей, які мислять або поводяться не так як ми, ми часто (підсвідомо) вважаємо неповноцінними.

Це припущення пояснює, чому програмістові так складно поставити себе на місце користувача. Користувачі думають зовсім не так, як це роблять програмісти. Перш за все, вони проводять значно менше часу за комп’ютером. Вони не знають, яким чином працює комп’ютер, та їх це й не цікавить. Це означає, що вони не можуть застосувати одну з багатьох технік розв’язання проблем, які добре відомі програмістам. Вони не розпізнають структури та натяки, які допомагають програмістам використовувати, вдосконалювати та обходити інтерфейс.

Найкращий спосіб дізнатися, як думає користувач, -- це спостерігати за ним. Попросіть його виконати якесь завдання, використовуючи програмне забезпечення, схоже на те, що ви розробляєте. Переконайтесь, що завдання цілком реальне: "Знайти суму колонки чисел" -- нормально; "Підрахувати витрати за останній місяць" -- взагалі чудово. Уникайте занадто конкретизованих завдань, на зразок "Виберіть комірки таблиці і введіть формулу сумування під ними" -- занадто багато підказок в одному реченні. Дозвольте користувачу розповісти про його успіхи. Не перебивайте. Не намагайтесь допомогти. Постійно запитуйте себе "Чому він робить саме так?".

Перше, що ви помітите -- це те, що користувачі роблять більшість речей однаково. Вони намагаються виконати завдання в одному й тому ж порядку і роблять однакові помилки в тих самих місцях. Слід взяти цю базову поведінку за основу. Це не те саме, що відбувається на нарадах з проектування, де люди схильні слухати, коли хтось каже: "А якщо користувач захоче те-то і те-то?". Це призводить до появи хитромудрих функцій і непорозумінь щодо вимог користувача. Спостереження за користувачами допоможе уникнути цих непорозумінь.

Ви побачите, як користувачі потрапляють у глухий кут. Коли ви потрапляєте в таку ситуацію, ви оглядаєтесь навколо. Користувач же, коли опиняється в тупику, навпаки, зосереджується на місці виникнення проблеми. Йому стає важче побачити рішення деінде на екрані. Ось чому тексти допомоги є поганим рішенням проблеми неякісно розробленого інтерфейсу. Якщо необхідно подати інструкції або текст допомоги, обов’язково розташуйте їх поряд з проблемними місцями. Через вузьке поле уваги користувача спливаючі підказки ефективніші, ніж меню допомоги.

Користувачі як-небудь справляються з труднощами. Вони знаходять робочий спосіб і постійно ним користуються, навіть якщо він дуже заплутаний. Краще забезпечити один очевидний спосіб виконання завдання, ніж декілька посилань на спосіб вирішення проблеми.

Ви також побачите, що між тим, що користувач каже, хоче та робить насправді, є певна різниця. Саме це і хвилює найбільше, бо найпоширеніший спосіб збирати користувацькі вимоги -- це задавати їм запитання. Ось чому найкращий метод вловлювати вимоги до продукту -- це спостерігати за користувачами. Провести годину, спостерігаючи за процесом роботи користувачів, краще, ніж витратити весь день, роблячи припущення про те, чого вони хочуть.

mardi 13 décembre 2011

(Translations) Beauty Is in Simplicity - Jørn Ølmheim

Оригінал статті можна прочитати тут.

Beauty Is in Simplicity - Jørn Ølmheim
Краса у простоті

Jørn Ølmheim
Є відома цитата Платона, яку, на мою думку, варто знати і пам’ятати усім розробникам програмного забезпечення.


У характері, в манерах, в стилі, у всьому цьому найпрекрасніше - простота.

Усього в одному реченні описані всі цінності, до яких ми повинні прагнути як розробники програмного забезпечення.

Ось кілька властивостей, які ми прагнемо надати коду:
  • Легкість читання
  • Легкість підтримки
  • Швидкість розробки
  • Невловиме поняття краси

Платон каже, що всі ці якості можна досягнути через простоту.

Що таке гарний код? Це дуже суб’єктивне питання. Сприйняття краси, як і будь-чого іншого, залежить від нас самих. Люди з художньою освітою сприймають красу не так, як люди з технічною освітою (чи, принаймні, мають інший підхід до краси). Знавці мистецтв при оцінці краси програм порівнюють їх з творами мистецтва, натомість науковці згадують симетрію і золотий переріз та намагаються звести все до формул. Наскільки я знаю, більшість аргументів обох сторін ґрунтується на простоті.
Пригадайте той код, який ви вивчали. Якщо ви не вивчали чужий код, зараз же припиніть це читати і знайдіть який-небудь відкритий код для вивчення. Негайно! Пошукайте в інтернеті якийсь код на вашій мові програмування, написаний відомим і поважним експертом.

Ви вже повернулись? Чудово. На чому ми зупинилися? Ага... Я помітив, що код, який я вважаю красивим, має декілька спільних ознак. Головною з них є простота. Я вважаю, що незалежно від того, наскільки складна програма чи система в цілому, окремі частини повинні бути простими: прості об’єкти з простими обов’язками, які містять так само прості, сфокусовані методи з описовими назвами. Дехто вважає, що короткі методи на 5-10 рядків коду -- це занадто, і цього важко досягнути на деяких мовах, але я вважаю, що все одно така стислість є бажаною метою.

Отже висновок такий: гарний код -- це простий код. Кожна окрема частина повинна залишатися простою, з простими обов’язками та взаємозв’язками з іншими частинами системи. Саме так можна зробити наші системи легкими в підтримці, з чистим, простим кодом, який можна тестувати, і забезпечувати високі темпи розробки впродовж усього часу життя системи.
Краса народжується і відкривається у простоті.