Connect with us

Разработка

Григорий Петров: Забудьте слово “ошибка”

Если при общении с разработчиком вам кажется что он <вырезано цензурой> – вспомните эту статью. Возможно, у вас просто сложности коммуникации.

Григорий Петров

Опубликовано

/

     
     
[button color=4d61d7 icon=arrow-left-2 url=https://apptractor.ru/develop/grigoriy-petrov-zachem-v-kode-kommentarii.html] Зачем в коде комментарии [/button]

 

При управлении разработкой менеджер борется как с классическими управленческими сложностями, так и со сложностями нашей отрасли. Часто эти сложности переплетаются и порождают чудовищ: “звездную болезнь” среди программистов, синдром Not Invented Here и прочие неприятные штуки, которые могут легко и непринужденно привести к провалу самый перспективный проект. В рамках цикла статей я стараюсь рассказывать о нашей работе со всех сторон, включая вопросы психологии и работы с коллективом.

Многим знакома такая ситуация: менеджер или тим лид приходит к разработчику и говорит ему:

– Василий! Вот здесь баг. Надо исправить.

Разработчик внимательно смотрит на менеджера, на баг, снова на менеджера, снова на баг и отвечает:

– Нет, Николай, ты не прав. Это не баг. Я сейчас объясню, почему оно так и должно работать.

В этот момент менеджер обычно понимает, что у него проблема. Даже кучка проблем:

  • Прямо сейчас ему надо убеждать разработчика, что это все-таки баг, спорить, ругаться.
  • Сколько еще будет таких “не-багов” в проекте?
  • А что будет, если придет не он, руководитель, а, к примеру, сотрудник отдела тестирования?

Что за проблема в консерватории?

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

1

Заезженная фраза, не правда ли? Почему-то бытует мнение, что “разница в восприятии” эта какая-то мелочь, вроде того, что одним людям нравится кофе с ванильным сиропом, а другим с шоколадным. Чтобы оценить ширину пропасти между нами, достаточно посмотреть на результаты небольшого эксперимента, который поводили над жителями племени Химба в Намибии. Эти результаты легко гуглятся по фразе “himba color study”. В рамках эксперимента им показывали на мониторе несколько зеленых квадратов и один синий, и просили найти отличающийся по цвету квадрат. И они не могли. Для них все квадраты были одного цвета.

Самое веселое в этой истории – предполагаемая причина такой избирательной цветовой слепоты. Ученые считают, что жители этого племени не могут отличить синий от зеленого одинаковой яркости потому, что в их языке нет слова для обозначения синего цвета. Зато более полусотни слов для обозначений оттенков зеленого – этот цвет они различают намного лучше нас с вами.

Оцените всю глубину пропасти – человек физически не видит синий цвет, потому что в его языке нет слова для обозначения этого цвета. Люди воспринимают окружающий мир совсем по-разному. И пропасть в восприятии одних и тех же вещей между вами и вашим коллегой запросто может быть более глубокой, нежели между вами и жителем южного берега Африки. К примеру, для большинства разработчиков слово “асфальт” вызовет ассоциацию с дорогой. Тогда как для строителя это такая горячая черная штука с набором любопытных физических свойств, которую так весело зимой класть на снег.

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

Что происходит в голове разработчика

Я не знаю.

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

2

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

Мозг Василия пропускает фразу через его картину мира, которая складывается из индивидуального опыта, социального влияния, инстинктов, гормонов и множества других факторов. Фразе присваиваются эмоциональные маркеры, которые на низком уровне определяют, что это за социальное взаимодействие. Затем, в соответствии с этими маркерами (и еще кучей других факторов, и вообще – это все гипотезы), лимбическая система принимает решение, как надо реагировать, и отдает команду механике внутренней секреции на изменение гормонального фона. Под действием которого мозг “генерирует” ответ.

У лимбической системы, при всех ее достоинствах, есть небольшой недостаток – она у нас довольно старая. И хорошо умеет разруливать ситуации на уровне каменного века и стай животных в 50-100 особей. Про современное общество, офисную работу и разработку программ лимбическая система не знает ничего. Поэтому на уровне “ассемблера” общение менеджера с разработчиком выглядит примерно так:

Менеджер:

– Василий! Вот здесь баг. Надо исправить.

Мозг:

– Маркер коммуникации между двумя самцами, маркер агрессии, маркер требования. Какие маркеры будут ставиться, определяет картина мира. Та самая, которая у всех разная.

Лимбическая система:

– Другой самец проявляет по отношению к нам агрессию и требует подчиниться? Очень интересно. А это альфа самец? Вроде нет. Тогда – это угроза нашему положению в стае! Необходимо занять оборонительную позицию и зарычать – меняю гормональный фон

Мозг:

– Нет, Николай, ты не прав. Это не баг.

Обратите внимание – все произошедшее выше происходит без участия Василия. Он не обдумывал фразу менеджера, не думал, какие слова сказать. Все это делает автоматика. “Сознание” включается уже после того, как лимбическая система “защитила” своего хозяина от “посягательств” на его “место в стае”. То есть, для Василия это выглядит следующим образом: сидит, никого не трогает, работает. И тут хоп – заканчивает произносить фразу “Нет, Николай, ты не прав. Это не баг”. И понимает, что надо что-то говорить дальше. И начинает срочно придумывать, как бы объяснить только что сказанное. Он же не может сказать “ой, что я только что сказал?”. Потому что на уровне сознания мы не разделяем “обдуманное” поведение и “автоматическое” – для нас это “наше поведение”.

Как с этим жить

Проблемы коммуникации – они большие, страшные и недооцененные. Я видел, как большие проекты разработки умирали только потому, что руководитель разработки не мог договориться с разработчиками. Вопросам коммуникации посвящены тысячи книг, курсов и тренингов. Разделы психологии и научные работы. В рамках этого цикла статей об управлении разработкой я бы хотел сделать акцент на двух моментах, которые лично я видел чаще всего:

  1. Помним о лимбической системе и не допускаем, чтобы она перехватывала управление ни у нас, ни у собеседника. С собой проще всего – достаточно делать паузу в несколько секунд перед ответами и заставлять себя игнорировать “рвущийся наружу” ответ. С собеседником тяжелее – обучить всех искусству коммуникации вряд ли получится. Но можно строить свою речь таким образом, чтобы мозг не маркировал ее сильными эмоциями, тогда лимбическая система ее будет просто игнорировать. Не используем слово “ошибка” – используем “интересная ситуация”. Не говорим “исправить”, спрашиваем “как думаешь, можно сделать еще лучше?”. Эти простые приемы не сделают из вас гуру коммуникации, но помогут избежать многих проблем.
  2. Помним про племя Химба и разную картину мира. Даже если мы успешно избежали общения двух лимбических систем, разница в картине мира может разрушить коммуникацию не менее эффективно. Что делать, чтобы этого не случилось? Не надеяться на телепатию. Не стесняться просить разработчика пересказать своими словами, как он понял задачу. Формулировать задачи от результата и явно указывать критерии того, что задача выполнена – для этого хорошо подходит методология постановки задач “SMART”.

Если при общении с разработчиком вам кажется, что он <вырезано цензурой> – вспомните эту статью. Возможно, у вас просто сложности коммуникации.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
9 комментариев

9 Comments

  1. Stepan S.

    08.11.2015 at 16:00

    Ребята, привет! Я вот читаю интересную статью на апптрактор и хочу ей поделиться с другом. Читаю с телефона. В моем поле зрения несколько кнопочек для поделиться и вацап мне кажется наиболее удобным. Нажимая на вацап, я улетаю в Аппстор : типа у меня нет вацапа. Вот это баг или у нас просто разное восприятие мира?

    • AppTractor

      09.11.2015 at 10:06

      Степан, привет :)

      А по другим мессенджерам нормально работает? Честно говоря это же сторонний скрипт “Поделиться”, мы на него мало влияем.

      • Stepan S.

        09.11.2015 at 11:18

        Я знаю что это за скрипт и уже писал в тех поддержку разработчику. Вроде все норм работает, кроме вацапа. Мне интересно просто было услышать ответ про этот баг в контексте статьи))) Расскажут ли мне, что это не баг с пояснением как это работает.

        • AppTractor

          09.11.2015 at 11:43

          Ответ: нет, это не баг, это интересная ситуация :)

          • Grigory Petrov

            09.11.2015 at 13:45

            Почти правильно :). Это действительно интересная ситуация, ребята из Апптрактора попробуют ее исправить.

          • AppTractor

            09.11.2015 at 13:53

            Григорий :) Еще раз – это сторонний виджет, к которому мы имеем мало отношения, он делается UpToLike. Мы вряд ли в нем что-нибудь можем поправить :)

  2. Artem Voronov

    12.11.2015 at 11:23

    Ребята из Стратоплана целый курс выпустили, в котором рассматриваются такие ситуации и способы их решения. Даже решебник составили: ситуация – что делать. Проверил сам на практике, работает.

  3. p2mbot

    15.11.2015 at 10:55

    Григорий, ваши статьи о психологии шикарны! От вас узнал про кошелек Миллера, что аццки улучшило мою работу в сложных проектах.
    Благодарствую за просветительскую работу! )

  4. Andrew Kovzel

    10.03.2016 at 13:07

    Отличная статья, спасибо! Есть одна замечательная книга “Думай медленно, решай быстро” Канемана. Фундаментальная теория о нашем восприятии мира, автор получил Нобелевскую премию. Она возможно даст более глубокое понимание ситуации с программистом, например учитывание эффекта фрейминга.

You must be logged in to post a comment Login

Leave a Reply

Обучение

Истории разработчиков, получивших первую работу после 30, 40 и 50 лет

Куинси Ларсон, преподаватель в freeCodeCamp, собрал более 300 историй разработчиков, которые доказывают, что начинать учиться программированию никогда не поздно.

Анна Гуляева

Опубликовано

/

Почему я это сделал

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

Мне __ лет. Мне уже поздно учиться разработке?

Это один из самых распространенных вопросов в разработке в целом. Чтобы показать вам, сколько разработчиков волнует их возраст, я зашёл на Quora. Конечно, я нашел людей всех возрастов, которые переживают из-за того, что они «слишком старые», чтобы учиться программированию и становиться разработчиком: 60, 59585756555453, 52, 51504948474645444342414039383534333231, 29282726252423222120191817161514.

Что вы скажете кому-то, кто переживает, не слишком ли уже поздно? Многие люди ограничатся старой цитатой Уолта Диснея: «Если вы можете представить это, вы можете сделать это!»

Но я понимаю эти переживания. Я работал учителем и не умел программировать до 30 лет. До этого возраста я не мог написать даже простой код на JacaScript. Я не мог установить Linux. Да, я даже не мог настроить роутер без помощи жены.

Я получил первую работу в качестве разработчика в 31. И, конечно, я верю, что возраст — это просто число. И что все, кто могут вложить в обучение свои силы, могут научиться программировать и получить работу.

Но как мне убедить всех этих людей, задающих этот вопрос каждый день? Просто говорить «не переставайте верить» — неэффективно.

Я собрал доказательства, чтобы убедить людей расслабиться по поводу возраста

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

Например, одна моя подруга была учительницей французского за 50. После бесплатных университетских онлайн-курсов она получила работу разработчика в Apple. Поэтому я знал, что это возможно.

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

Поэтому однажды, после очередной попытки успокоить тревоги людей, я пересмотрел свой подход. Я подумал: «Возможно, я смогу найти список разработчиков, которые получили первую работ в 30, 40 или больше лет. Может быть, это убедит людей перестать так беспокоиться о возрасте».

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

Оказалось, что многие разработчики получили первую работу в 30, 40 или 50 лет. Вот несколько историй:

Я создал список из 300 разработчиков, которые начали после 30, чтобы показать, сколько людей начали переход к разработке ПО в более старшем возрасте. Я буду и дальше вести этот список. Поэтому, если вы разработчик, получивший первую работу после 30, твитните мне с хэштегом #DevAfter30, и я добавлю вас в список.

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

Комментарии
Продолжить чтение

Новости

Интересные материалы: 18.01

Под конец дня – Unity 2018, приложение по доставке и огромное академическое исследование стоимости разработки игр.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Мероприятия

Как я участвовал в хакатоне с 13 днями опыта в программировании

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

Анна Гуляева

Опубликовано

/

Я даже не понял, что подал заявку на хакатон. Я услышал этот термин в подкасте CodeNewbie, когда кто-то делился своей историей. Из подкаста я запомнил рекомендацию стать частью сообщества. Поэтому, когда я увидел пост в группе freeCodeCamp Las Vegas о мероприятии StartUp Weekend, он привлек мое внимание.

Это мероприятие было посвящено созданию новых компаний через объединение предпринимателей, дизайнеров и разработчиков. Но, согласно моему аккаунту freeCodeCamp, я занимался программированием всего 13 дней. Я оставил комментарий под постом и спросил, могу ли я получить пользу от этого мероприятия, несмотря на нехватку знаний и опыта. Мне ответил Майк Зиетлоу и сказал, что я могу получить пользу, только мне нужно будет постараться. Поэтому я оставил заявку на то, что я сначала принял за митап.

Когда я приехал на место и не мог найти нужную комнату, я начал сомневаться в себе, но встреча с дружелюбными людьми помогла мне почувствовать себя уверенней. Я встретил Майка и мы обсудили, что я могу сделать на хакатоне.

Я объяснил, на каком этапе обучения я сейчас нахожусь. Я только закончил проект с созданием страницы о выдающемся человеке. Майк сказал, что группам понадобится человек для создания лендинговых страниц для их идей. Это помогло мне успокоиться: я мог сделать хоть что-то.

Майк на питче своей идеи

Выбор команды

Мероприятие началось, и участники начали представлять свои бизнес-идеи. Хороших идей было много. Когда мне нужно было выбрать команду, я хотел присоединиться к людям, которые дадут мне вызов, задачу, над которой надо будет потрудиться. Но я не хотел быть единственным разработчиком в команде.

Поэтому я искал команду, в которой будут опытные разработчики. Так получилось, что Майк питчил идею создания сайта для связи предпринимателей и разработчиков из Лас-Вегаса. Пять разработчиков и два бизнес-аналитика вступили в эту команду, и так появилась Developers.Vegas.

Две вещи подкрепили мое решение вступить в эту команду. Одна произошла, когда мы впервые встретились и обсуждали свои планы и подготовку. Майк упомянул, что в какой-то момент ему нужны будут фотографии. У меня был опыт в фотографировании и я предложил свою помощь. Майк был рад её принять, но затем он отказался. Он сказал, что я собирался быть разработчиком, и у меня были свои дела. Действительно, я пришел туда, потому что хотел учиться программированию, и Майк помнил об этом и уважал мое решение.

Во-вторых, наше первое утро тогда началось со знакомства с командой. Мы кратко рассказали о себе, своих целях на эти выходные и ответили на разные вопросы: от глупых до глубоких и важных. Это заняло два часа, но это того стоило. Я думаю, это действительно нас объединило как команду для создания рабочего продукта.

Работа над проектом

Наконец пришло время работы над проектом. До этого мероприятия я писал код в браузерных редакторах в freeCodeCamp и CodePen. После общения с командой я скачал VS Code. Я понял, что не понимаю, как все это работает. Мне нужно было разобраться с git, концепцию которого я понял, но мне ещё многому предстояло научиться. В один момент я работал над master вместо своей ветки. Эта работа была довольно нервной. Я думал, что подведу всю команду. Но, к счастью, я ничего не разрушил.

Это была только одна из сложностей, с которыми мне предстояло справиться перед началом работы. У меня было немного задач. Все они включали создание стиля текста и кнопки над баннером. Я был рад сделать это, потому что я знал, как с этим справиться, ну или хотя бы мог разобраться с этим сам.

Мне напомнили заходить в Google, как только я застряну. Это звучит несложно, но я думаю, здесь есть особая техника. Я должен был знать, что задаю верные вопросы и получаю нужные ответы. Потом я понял, что никто не хотел браться за работу, которую дали мне. Я пока слишком мало знаю, чтобы понять, почему все ненавидят CSS.

На мероприятии я мог поучиться у других разработчиков. Я немного узнал о React и работе компонентов. Мы обсуждали код, когда пытались понять, как извлечь данные из базы данных, чтобы отобразить их на сайте. Я даже помог решить одну из проблем, когда захотел попробовать что-то новое. В процессе мы поняли, почему один участник команды не мог справиться с проблемой: мы управляли кое-чем как массивом, когда это на самом деле был объект. Тогда я понял, что действительно вношу вклад в работу команды.

Итоги

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

Я думаю, что значительная часть успеха команды основана на лидере. С самого начала Майк страстно относился к своему проекту. Большую роль сыграло его решение уделить время познакомиться друг с другом. Он также сыграл роль куратора, и наш успех во многом основан на том, что в команде был человек, который понимал конечную цель и средства для её достижения.

В итоге мы заняли второе место! Я рад, что поучаствовал в этом событии. Хотя оно и прервало мою 13-дневную серию на freeCodeCamp, я бы сделал это снова.

Комментарии
Продолжить чтение

Разработка

Как приложение Wikipedia готовится к работе в офлайне

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

AppTractor

Опубликовано

/

Автор:

Представляем вашему вниманию статью Риты Хо, соучредителя Wikimedia.

Нам в Wikimedia нам нравится начинать процесс проектирования с понимания аудитории. В 2017 году наша инициатива «Новые читатели» проводила этнографические исследования в Нигерии и Индии. Несколько моментов сильно повлияли на Android-команду Wikipedia:

Мобайл доминирует в выходе в Интернет, а Android — главная платформа. Мобильные приложения бьют все рекорды: мгновенные сообщения и социальные медиа находятся в топе.

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

Особенности работы в офлайне

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

  • Списки чтения. Пользователи могут легко сохранять статьи в списках чтения, чтобы просматривать их позже в автономном режиме.
  • Кеширование по умолчанию. Все открытые статьи кешируются и остаются доступными даже при потере интернет-соединения.
  • Офлайн-библиотека. Эта функция предусматривает бесшовный просмотр Википедии в онлайне и офлайне. Пользователи могут загружать коллекции статей Википедии в свою «автономную библиотеку» и продолжать поиск и чтение этих статей вне зависимости от наличия интернета.

Проектирование для офлайн

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

1. Осознавать состояние

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

Примеры различных уведомлений, когда приложение отключено от Сети. Слева: “тост” уведомление, когда отображается автономная версия статьи. Центр: сообщение отображается в автономной библиотеке при поиске в автономном режиме. Справа: сообщение о том, что можно обновиться.

2. Контекстные действия

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

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

Разница между онлайн и офлайн.

3. Обратная связь на медленном соединении

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

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

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

Мы также планируем обновить экран загрузки, чтобы показать “скелет” приложения – так пользователи смогут понимать, какой контент получается в момент открытия приложения,  это лучший индикатор прогресса, чем текущий статический экран с буквой «W» от Wikipedia.

4. Умное кеширование для ненадежных соединений

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

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

5. Контроль использования данных

Теперь доступны дополнительные настройки для тех, кто хочет экономить использование данных – есть возможность отключения изображений, и еще один вариант «предпочитать офлайн-контент», а не всегда загружать последнюю версию статьи.

Слева: настройка изображения. Справа: Предпочитаю использование автономного содержимого.

В будущем планируется еще больше контроля, в том числе:

  • Возможность загрузки статей только по WiFi
  • Исключительно автономный режим
  • Загрузка изображений с низким разрешением перед загрузкой изображений с полным разрешением

6. Использование и хранение данных

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

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

Мы также изучаем способы уменьшить размер самого приложения, рассматривая альтернативы “тяжелым” функциям. Например, использование Mapbox для просмотра статей поблизости в режиме карты.

7. Обучение пользователей

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

Имея это в виду, мы сделали обучающий онбоардинг, а также воспользовались «пустыми состояниями», чтобы предоставить дополнительную информацию о функциях, при помощи которых пользователи могут взаимодействовать с приложением.

Экран обучения пользователей для офлайн-библиотеки.

Пустые экраны.

8. Совместное использование офлайн

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

Автономная библиотека была разработана с учетом этого – пользователи, загружающие коллекции статей на одном устройстве, могут обмениваться файлами с другими через USB, передавать их на карте microSD или даже через соединение Bluetooth. Приложение само может обнаруживать файлы с коллекциями статей, независимо от того, записаны они на устройстве или где-либо на внешней SD-карте.

Наконец, помимо функции «Автономная библиотека», само приложение Wikipedia также может быть загружено из сторонних источников, доступно на F-Droid (за пределами магазина Google Play), его можно скачать как APK на нашем сайте.

9. Вопросы экономии батареи

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

Недавнее обновление добавило “черный” режим, поскольку было доказано, что устройства AMOLED получают значительную экономию энергии при использовании пользовательского интерфейса в черном цвете.

Что любопытно, эту функцию мы внедрили после того, как наше сообщество попросило об этом.

Примеры черного режима.

Приложение для Wikipedia является открытым проектом и вы можете принять участие в его развитии. Официальная страница: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/App_hacking.

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X

Спасибо!

Теперь редакторы в курсе.