Connect with us

Статьи

Почему авторы Trello не смогли создать бизнес на 1 миллиард долларов

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

Анна Гуляева

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

/

     
     

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

В 2011 Джоэл Спольски на TechCrunch Disrupt запустил новый продукт компании Fog Creek под названием Trello. Он был похож на белую доску со стикерами, перенесенную в веб-браузер и в приложение для iPhone. Вместо того, чтобы перемещать физические заметки на доске, вы могли перетаскивать карточки на доске в браузере.

За считанные дни Trello удалось привлечь внимание 131 тысячи человек. 22% из этих людей зарегистрировались. Trello хотели создать простой и полезный продукт, который сможет использовать кто угодно. Он распространялся, как лесной пожар.

Поэтому Trello в итоге пришлось продать Atlassian за $425 миллионов, хотя он и мог стать следующим SaaS-приложением на миллиард долларов.

Спустя пару месяцев после запуска Спольски написал пост, в котором предвидел самую большую сложность:

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

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

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

Давайте поговорим о возможности, которую упустил Trello, и что следовало сделать вместо этого.

Почему Trello нужно было заниматься продажами

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

На практике это выглядело так:

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

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

Они построили свои сервера на Node и использовали MongoDB для хранения данных, поэтому веб-приложение загружалось очень быстро. Каждый раз, когда пользователь перемещал карточку в новый список или менял запись на доске, Trello отправлял эти данные в другие браузеры, чтобы доска открывалась почти мгновенно.

Архитектура Trello

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

Все это было новым в то время и привлекло к Trello много внимания. Но в 2016 подобное красивое и отзывчивое  приложение стало не так сложно создать, и канбан-доски начали появляться везде:

GitHub представили канбан-доски в сентябре 2016:

Asana анонсировали канбан-доски в ноябре 2016:

Airtable запустили канбан-доски в ноябре 2016:

Джастин Розенштейн, сооснователь одного из крупнейших конкурентов Trello, Asana, сказал: “Мы определенно отдаем должное Trello. Этот продукт первым создал подобное видение”. Но Джастин непреклонен в вопросе копирования функции досок Trello: “Мы рассматриваем Trello как функцию, а не как продукт”.

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

Trello не стал такой системой записей. Он стал сильной визуальной метафорой, которую скопировали его конкуренты. Канбан-доска оказалась отличной UX-функцией, но не защищенной от копирования.

В SaaS побеждает не первая компания и не компания с лучшей идеей. Побеждают те, кто постепенно лучше решают проблему. Когда вы создаете популярную или успешную функцию, конкуренты её крадут.

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

1. Trello недостаточно быстро монетизировался

При помощи freemium модели возможно построить нацеленную на пользователей миллиардную компанию. В 2013, спустя шесть лет после запуска, Dropbox был оценен в 8 миллиардов долларов, их доход – 200 миллионов долларов, а количество пользователей – 200 миллионов человек. Это было даже до того, как Dropbox запустил тариф для бизнеса – доход компания преимущественно получала от продажи пользователям месячной подписки за 10 долларов.

Спустя три года после запуска рост количества пользователей Trello обещал превысить уровень Dropbox: в 2015 году у Trello было 10 миллионов пользователей (через три года после запуска у Dropbox было четыре миллиона клиентов). Но Trello было гораздо сложнее переводить неплатящих пользователей на свой план “Trello Gold”.

Запуск Trello Gold в 2013 был освещен этим постом в блоге, которые выделил три причины, по которые пользователю следует платить 5 долларов в месяц за Trello:

  • Настраиваемый фон доски
  • Ограничение в 250 МБ для файлов, прикрепленных к карточке (против 10 МБ в бесплатном плане)
  • Стикеры и кастомные эмодзи

Хотя все любят эмодзи, это не очень хорошая причина тратить деньги на приложение. Бесплатный тариф Dropbox предоставляет 2 ГБ пространства. Платный тариф предоставляет 1 ТБ, что в 50 раз больше бесплатной версии.

Определить ценностное предложение Trello было сложно, потому что они должны были ещё в начале понять, за какие функции захотят платить индивидуальные пользователи.

Решение: Изучить кейсы freemium-модели

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

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

  • Существует ли у вас конкурент, который может делать то же самое или уже делает это сейчас?
  • Каков потенциальный доход этого варианта?

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

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

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

Когда у вас есть обширный продукт, особенно важно рассмотреть индивидуальные варианты его применения, потому что это позволит вам создавать особые функции для этих вертикалей Если вы не хотите строить свой бизнес на freemium-модели, вы можете подняться выше и нацелиться на малый и средний бизнес (SMB).

2. Trello не стал незаменимым для SMB

Даже без доходного B2C-бизнеса Trello могли стать SaaS-инструментом для работы компаний, закрепившись на SMB-рынке. Проблема заключалась в том, что Trello не доказал свою незаменимость в качестве инструмента для управления рабочими процессами, чтобы оправдать свою стоимость перед компаниями.

В 2013 Trello запустил первый план Business Class для малого и среднего бизнеса. Сначала они установили цену в 200 долларов в год для организации, прежде чем перейти к более традиционной модели ценообразования SaaS за рабочее место.

Trello Business Class стоил 10 долларов за пользователя (плата взималась раз в год), и за эти деньги вы получали:

  • Безграничную интеграцию досок
  • Дополнительные функции совместной работы
  • Режим “только для чтения” и настройки приватности

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

В статье на Forbes CEO Trello Майкл Прайор сказал: “Я не хочу, чтобы люди проводили по десять часов в Trello ежедневно, мы не продаем рекламу и не хотим получать больше вашего времени, как это делают социальные платформы”.

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

Что следовало сделать Trello?

Решение: Создать лучшую интеграцию для SMB

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

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

Вместо этого главные функции Trello были скопированы. Представителю GitHub задали вопрос о создании досок для визуального управления вопросами, на что он сказал: “Все ожидали этой функции и спрашивали, почему у нас её не было”. Поэтому GitHub создали доски.

Если вы создаете подобное горизонтальное SaaS-приложение, разделите своих пользователей по интеграциям:

  • Какие API используют люди?
  • Сколько данных входит в продукт и выходит из него?

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

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

3. Trello не подходил для предприятий

Смена фокуса на рынок предприятий – доказанная модель для SaaS. Slack сделал это, запустив Enterprise Grid. Trello могли бы построить прибыльный бизнес таким же образом, быстро переключившись на рынок предприятий.

Менее чем через год после запуска стратегии корпоративных продаж, ежегодные платежи (ARR) достигли отметки в 10 миллионов долларов. В своем интервью вице-президент Trello по продажам Кристен Хабахт сказала, что Trello следует достаточно простой стратегии корпоративных продаж:

«Наша команда по работе с предприятиями рассматривает [клиентов], у которых действительно много пользователей Trello. Большая часть нашей стратегии исходящих продаж – это просто связаться с этими компаниями и сказать: У вас более 2 000 человек пользуются Trello, с кем мы можем поговорить об этом?»

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

Решение: Стать системой хранения данных для предприятия

Trello должны были задать такой вопрос: “Как нам интегрироваться с системами, которые используют большие компании, и стать незаменимой частью рабочего процесса?”.

Один из способов – стратегия Slack. С ростом компании они пытались распространиться от индивидуальных разработчиков к командам, а от команд к компаниям. Slack обнаружил здесь проблему, потому что, в отличие от инструмента продаж или маркетинговой аналитики, почти каждый человек в команде мог наложить вето на инструмент повышения продуктивности. Поэтому Slack провел шесть месяцев в приватном бета-тестировании, изучая свою клиентскую базу и рассказывая им о необходимости в инструменте внутренней коммуникации. Они оптимизировали процесс онбординга вокруг метрики в 2000 отправленных внутри организации сообщений. Сегодня 93% этих компаний продолжают использовать Slack.

Видение, стоящее за корпоративным продуктом Slack, позволяет организациям создавать “структуры” при помощи Slack. Функциональность приложения для предприятия отличается пользовательского. Команды в компании могут организовываться в “рабочие пространства” и формировать подразделения в соответствии со структурой организации. В Slack пытались понять, как и почему продукт распространяется от маленьких команд к отделам и целым организациям, и поэтому они смогли выделить ключевые проблемы предприятий и решить их в Enterprise Grid.

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

Поздравляю, Trello

Смотреть в прошлое, конечно, проще. Хотя большая часть статьи посвящена упущенной возможности Trello, мы не должны забывать, что создание SaaS-бизнеса, оцененного в 425 миллионов долларов, это большое достижение.

Команда Fog Creek заплатила за создание Trello из своего кармана. Приложение стало успешным с момента запуска на TechCrunch Disrupt. За два года Trello приобрел 500 тысяч пользователей, а за четыре года – 4,75 миллиона, и это до привлечения средств инвесторов. Команда создала удивительный продукт, который опередил свое время. Он был простым, изящным и легким в использовании.

В прошлом году я написал такой твит:

Вот такое влияние Trello оказал на SaaS, и вы видите его следы везде: от GitHub до Jira.

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

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

 

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

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 лет. Вот несколько историй:

https://twitter.com/mikleane/status/949452946600730626?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F2215e9cee7ade93a7ffbf76c00f6702a%3FpostId%3D64306eb6bb27

https://twitter.com/americanwombat/status/949486088325799937?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2Ff3305f7a1f903b59e7c4c9a9c6edd974%3FpostId%3D64306eb6bb27

https://twitter.com/jefflazerus/status/949457462939205632?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2Fc3053bd231b0056db2839f8c57f3828d%3FpostId%3D64306eb6bb27

https://twitter.com/peterdaily/status/949453856127307776?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F054d685fc2fed0e12bfc45634abf6296%3FpostId%3D64306eb6bb27

https://twitter.com/gillessew/status/950138976655912960?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F48799b09a4826507d15624371e46bf60%3FpostId%3D64306eb6bb27

https://twitter.com/amwcodes/status/949581047808716800?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F46ff7a793cd12eb3273696b47e4f17f3%3FpostId%3D64306eb6bb27

https://twitter.com/dbriesz/status/949483215256825856?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F5daccc8369b60bb9807d39e133237d74%3FpostId%3D64306eb6bb27

https://twitter.com/jessdelgrande/status/950163504773902342?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F700f10a61f7d7a18fd00ba8d9bc31ecf%3FpostId%3D64306eb6bb27

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

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

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

Магазины приложений

Apple планирует объединить приложения для iPhone, iPad и Mac

Корпорация Apple работает над созданием нового способа взаимодействия с компьютерами Mac: через простые в использовании приложения, доступные для скачивания в App Store. Сейчас приложения для macOS доступны для скачивания в Mac App Store – это город-призрак с ограниченным выбором и редко обновляемыми программами. Джей лаб пишет, что Apple планирует изменить эту ситуацию, предоставив людям возможность использовать один набор приложений, которые одинаково хорошо работают на всем семействе устройств: iPhone, iPad и Mac.

Джей лаб

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

/

Автор:

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

Sketch покидает Mac App Store

В настоящее время разработчикам приходится создавать два разных приложения: одно для iOS – операционной системы мобильных устройств Apple, и одно для macOS – системы, на которой работают компьютеры Mac. Это значительно увеличивает объем работы. Более того, пользователи Apple часто жалуются на недостаточную поддержку и несвоевременное обновление приложений для Mac. Например, популярное приложение Twitter регулярно обновляется на iPhone и iPad, а версия для Mac уже давно не обновилась и считается некачественной. С появлением возможности разработки одного приложения для Mac, iPad и iPhone, пользователи будут получать обновления одновременно.
Объединение приложений может помочь платформам iOS и MacOS развиваться и расти как единое целое. Это станет самым большим изменением для программной платформы Apple с момента появления iOS.

Однако идея Apple по объединению мобильных и настольных приложений не нова. Перед тем, как завершить выпуск программного обеспечения Windows для смартфонов, корпорация Microsoft анонсировала технологию Universal Windows Platform, которая позволяет разработчикам создавать приложения, которые будут работать на всех устройствах – планшетах, телефонах и компьютерах. Магазин приложений Google Play стал доступен для некоторых ноутбуков, работающих на Chrome OS, что позволило пользователям компьютеров запускать приложения для смартфонов и планшетов, такие как Instagram и Snapchat.

UnDistracted: опыт запуска Мак-приложения вне магазина Apple

На данный момент неясно, планирует ли Apple объединить магазины приложений для Mac и iOS, но примечательно то, что версия магазина для iPhone и iPad была переработана в этом году, в то время как версия для Mac не обновлялась с 2014 года.

Идея объединения приложений является частью долгосрочной стратегии Apple, целью которой является сделать основы его аппаратного и программного обеспечения более похожими. Несколько лет назад компания начала разрабатывать собственные процессоры для устройств iOS. В то время как Apple планирует унифицировать приложения, возможно, однажды они смогут использовать один и тот же основной процессор на компьютерах Mac и iOS.

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

Мероприятия

Как я участвовал в хакатоне с 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

Спасибо!

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