Recherche personnalisée

mercredi 25 juillet 2012

Jelly Bean: Accessibility Gestures Explained

Jelly Bean: Accessibility Gestures Explained

1 Jelly Bean: Accessibility Gestures Explained

This article details accessibility gestures in Jelly Bean and is a follow-up to Jelly Bean Accessibility Explained. It gives a conceptual overview of the 16 possible gestures and describes how they are used. The interaction behavior described here holds for all aspects of the Android user interface, including interactive Web pages within Chrome and the Android Web Browser.

1.1 Conceptual Overview Of The Gestures

Placing a finger on the screen speaks the item under the finger by first placing Accessibility Focus on that item. Moving the finger triggers touch exploration which moves Accessibility Focus.

To generate any of the Accessibility Gestures discussed below, one moves the finger much faster — how much faster is something we will tune over time, and if needed, make user customizable.

To remember the gestures, think of the four directions, Up, Down, Left and Right. In addition to these four basic navigational gestures, we defined an additional 12 gestures by picking pairwise combinations of these directional flicks, e.g., Left then Down — this gives a total of 16 possible gestures. In what follows, left then down means swipe left, and continue with a down flick. Note that in performing these additional gestures, speed matters the most. As an example, it is not essential that you make a perfect Capital L when performing the Down then Right gesture for instance; speed throughout the gesture, as well as ensuring that the finger moves some distance in each direction is key to avoid these being misinterpreted as basic navigational gestures.

1.2 Accessibility Focus And Accessibility Gestures

Accessibility Focus is moved using the four basic directional gestures. For now we have aliased Left with Up, and Downwith Right; i.e., both Left and Up move to the previous item, whereas Down and Right move to the next item. Note that this is not the same as moving with a physical D-Pad or keyboard on Android; the Android platform moves System Focus in response to the D-Pad. Thus, moving with a D-Pad or trackball moves you through the various interactive controls on the screen; moving Accessibility Focus via the Accessibility Gestures moves you through everything on the screen.

1.3 Accessibility Gestures For Common Actions

In addition to the basic navigation describe above, we define the following gestures for common actions:

Navigation Granularity
You can increase or decrease navigation granularity by rapidly stroking Up then Down or Down then Up.
Scrolling Lists
You can scroll a list forward by rapidly stroking Right then Left; the reverse, i.e., Left then Right scrolls the list backward by a screenful.

1.4 User Configurable Gestures

Gestures Down then Left, Up then Left, Down then Right and Up then Rightare user configurable; their default assignments are shown below.

Back
Gesture Down then Left is the same as pressing the Back button.
Home
Up then Left has the same effect as pressing the Home button.
Status Bar
Gesture Up then Right opens Status Notifications.
Recent
Down then Right has the same effect as pressing the Recent Applications button.

1.5 Summary

Gestures for manipulating and working with Accessibility Focus are an evolving part of the Android Accessibility; we will continue to refine these based on user experience. At this point, you are probably saying:


But wait, you said 16 gestures, but only told us the meanings of 12 of them

You are correct — we have left ourselves some gestures to use for future features.

mardi 24 juillet 2012

Jelly Bean Accessibility Explained:Touch Exploration Augmented By Gestures

Jelly Bean Accessibility Explained:Touch Exploration Augmented By Gestures

1 Jelly Bean Accessibility Explained:Touch Exploration Augmented By Gestures

We announced a number of accessibility enhancements in Android Jelly Bean — see our Google IO 2012 announcements and our Android Accessibility talk from I/O 2012. This article gives a user-centric overview of the Jelly Bean interaction model as enabled by touch exploration and navigational gestures. Note that as with every release, Android Accesssibility continues to evolve, and so as before, what we have today is by no means the final word.

1.1 High-Level Concepts

First, here's some shared vocabulary to ensure that we're all talking of the same thing when explaining Jelly Bean access:

Random Access
Enable user to reach any part of the on-screen UI with equal ease. We enabled this as of ICS with touch exploration.
Deterministic Access
Enable user to reliably land on a desired item on the screen. We enable this in Jelly Bean with linear navigation.
Accessibility Focus
The item that the user most recently interacted with — either via touch exploaration or linear navigation receives accessibility focus.
Activation
User can activate item having accessibility focus by double-tapping anywhere on the screen.

1.2 Sample Interaction Scenarios We Enable

The combination of random access via touch exploration, backed up by linear navigation starting from the point the user just explored enables users to:

  • Touch explore an application to understand its screen layout,
  • Use muscle memory to quickly touch parts of the display to access familiar application screens,
  • Use linear navigation to reach the desired item when muscle memory is wrong by a small amount.

As an example, when using the Google Play Store, I can use muscle memory with touch exploration to find the Search button in the top action bar. Having found an application to install, I can once again use muscle memory to roughly touch in the vicinity of the Install button; If what I touch is not the Install button, I can typically find it with one or two linear navigation steps. Having found the Install button, I can double-tap anywhere on the screen.

The same use case in ICS where we lacked Accessibility Focus and linear navigation would have forced me to use touch exploration exclusively. In instances where muscle memory worked perfectly, this form of interaction was highly effective; but in our experience, it also tended to lead to breakdowns and consequent user frustration in instances where users almost found the control they were looking for but missed by a small amount.

Having introduced accessibility focus and linear navigation in Jelly Bean, we decided to eliminate the ICS requirement that the user tap on or near a control to activate it — we now enable users to activate the item with accessibility focus by tapping anywhere on the screen. To eliminate spurious taps --- especially on tablets, we made this a double-tap rather than a single tap. Note: based on user experience, we may optionally bring back single tap at some point in the future as an end-user customization.

1.3 Summary

Android Accessibility continues to move forward with Jelly Bean, and will continue to evolve rapidly along with the platform. Please use the Eyes-Free Google Group to provide constructive feedback on what works or doesn't work for you --- what is most effective is to objectively describe a given use case and your particular experience.

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 рядків коду -- це занадто, і цього важко досягнути на деяких мовах, але я вважаю, що все одно така стислість є бажаною метою.

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



jeudi 8 décembre 2011

(Translations) The Guru Myth - Міф про гуру

Ryan Brush

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

Кожен, хто займався розробкою достатньо довго, чув питання на зразок такого:


В мене вилітає виключення XYZ. Ти часом не знаєш, в чому справа?

Ті, хто задають такі запитання, рідко додають до опису проблеми слід стеку(stack traces), логи реєстрації помилок, або будь-який контекст, у якому виникла дана проблема. здається, що вони вважають, що ви думаєте якимось інакшим способом, що рішення з’являються перед вами без аналізу, який базується на фактах. Вони вважають, що ви -- гуру.

Таких запитань слід очікувати від людей, не знайомих з програмним забезпеченням: для них системи видаються мало не магією. Що мене турбує -- це такі випадки у спільноті програмного забезпечення. Подібні питання постають при проектуванні програм, наприклад: “Я пишу керування запасами(inventory management).Чи варто використовувати оптимістичне блокування(optimistic blocking)?” Парадоксально, але той, хто задає питання, часто може дати кращу відповідь, ніж той, кого запитують. Той, хто питає, скоріше за все, знає контекст і вимоги, а також може прочитати про переваги і недоліки різних стратегій. Втім, вони очікують від вас розумної відповіді без контексту. Вони очікують чаклунства.

Настав час індустрії програмного забезпечення розвіяти цей міф про гуру. “Гуру” -- це люди. Вони керуються логікою і системно аналізують задачі, як і всі ми. Вони користуються своїм досвідом та інтуіцією. Гляньмо на найкращого програміста, якого ви знаєте. Був час, коли він знав про програмування менше, ніж ви знаєте зараз. Якщо хтось здається вам гуру, то це результат років навчання і тренування розуму. “Гуру” -- це просто розумна людина з невгамовною цікавістю.

Звичайно, залишається велика різниця у природних здібностях. Багато хакерів розумніші, обізнаніші і продуктивніші, ніж я міг би коли-небудь бути. Незважаючи на це, розвінчання міфу про гуру має і позитивний вплив. Наприклад, працюючи з кимось розумнішим за мене, я напевне займатимусь біганиною, щоб забезпечити цій особі достатні умови, щоб вона могла ефективно використовувати свої навички. Розвіювання міфу про гуру також означає усунення перепон для розвитку. Замість магічного бар’єру я бачу простір, в якому можна розвиватися.

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





(Tranlations) Постійно вчитись - Клінт Шанк

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

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

Clint Shank
Ми живемо в цікаві часи. Розробка поширюється по світу, і ви дізнаєтеся, що є дуже багато людей, здатних виконувати твою роботу. Вам слід постійно вчитися, щоб залишатися конкурентоздатним. Інакше ви застрягнете на своїй роботі до того часу, поки Ви станете непотрібними або на неї не підрядиться хтось за меншу оплату.

То що ж Вам з усім цим робити? Деякі роботодавці достатньо щедрі, щоб забезпечити тренінги для покращення Ваших умінь. Інші ж можуть не мати змоги виділити ні часу, ні грошей для Вашої освіти взагалі. Щоб не ризикувати, потрібно серйозно взятись за свою освіту самостійно.

Ось список способів, як продовжувати навчатися. Багато з них доступні безкоштовно в інтернеті:
  • Читайте книги, журнали, блоґи, Твіттер та веб-сайти. Якщо ви бажаєте заглибитись у вивчення предмету, подумайте про приєднання до розсилок новин. 
  • Якщо ви справді хочете розібратись в технології, приступайте до діла -- пишіть код. 
  • Завжди намагайтеся працювати з наставником, бо якщо ви найкращий у колективі, це може ускладнити Вашу освіту. Хоча від кожного можна чогось навчитися, набагато більше можна почерпнути від того, хто розумніший чи досвідченіший за Вас. Якщо ж ви не можете знайти вчителя, переходьте до наступних пунктів. 
  • Використовуйте віртуальних учителів. Знайдіть в інтернеті авторів і розробників, які Вам справді до вподоби, і читайте все, що вони пишуть. Підпишіться на їхні блоґи. 
  • Вивчайте фреймворки та бібліотеки, які ви використовуєте. Якщо ви знаєте, як що-небудь працює, то можете краще його використовувати. Якщо вони мають відкритий код, то Вам дуже пощастило. За допомогою дебаґґера покроково проходьте код і спостерігайте, що відбувається під капотом. Ви побачите код, який писали і перевіряли дуже розумні люди. 
  • Кожного разу, коли ви зробили помилку, виправили баґ, або зіткнулися з проблемою, постарайтесь розібратися, що сталось насправді. Скоріше за все, ще хтось зіткнувся з подібною проблемою і опублікував її в інтернеті. Google -- Ваш друг:) 
  • Прекрасний спосіб щось вивчити -- вчити це або говорити про це. Коли люди збираються Вас слухати, і задавати Вам запитання, у Вас буде чудова мотивація вчитись. Спробуйте lunch’n’learn на роботі, приєднайтесь до групи користувачів, або відвідайте якусь місцеву конференцію. 
  • Приєднайтеся до навчальної групи, або створіть нову (як-то спілка вивчення "узорів"-паттернів), або приєднайтеся до місцевої групи користувачів мови, технології чи дисципліни, яка Вас цікавить. 
  • Відвідуйте конференції. Якщо ж не маєте змоги -- багато конференцій транслюються онлайн безплатно. 
  • Далеко їхати? Слухайте подкасти. 
  • Користувалися статичним аналізом кодової бази? Бачили попередження свого середовища розробки (IDE)? Дізнайтеся, що вони повідомляють і чому. 
  • Послухайте пораду Pragmatic Programmers та вивчайте нову мову програмування кожного року. Принаймні вивчіть нову технологію чи інструмент. Це дасть Вам нові ідеї, які ви зможете використати у технології, з якою працюєте зараз. 
  • Не все, що ви вивчаєте, повинно буди пов’язане з технологією. Вивчайте свою галузь роботи, щоб краще розуміти вимоги і допомагати в розв’язанні бізнес-проблем. Вчіться бути продуктивнішими і краще працювати -- це також дуже хороший варіант. 
  • Поверніться до школи.  (?)
Було би класно мати таку можливість, як Нео з “Матриці” і просто завантажити усю необхідну інформацію у наш мозок. Але, на жаль, такої можливості немає, тому доведеться тратити час. Вам не треба проводити кожну вільну годину навчаючись. Трохи часу кожного тижня - це набагато краще, ніж нічого. Повинне бути життя і поза роботою.

Технологія змінюється швидко. Не відставайте.