От идеи до Play Store
В один прекрасный день я решил, что хочу создать приложение для управления задачами. Что-то вроде Jira, но для всех текущих личных проектов, которые у меня были.
Я просмотрел много сообщений в блогах, видео на YouTube и руководств, чтобы усвоить как можно больше знаний о приложениях. Я пробовал себя в различных сферах, как конкретизировать ваши идеи, исследования рынка, UI / UX, цветовые схемы, различные технологические стеки для разных типов фреймворков, и какой из них лучший, и многое другое.
Я создавал приложение для развлечения, поэтому пропустил несколько первых шагов тщательного исследования рынка. Я был клиентом, для которого создавал это приложение. Благодаря успеху таких продуктов, как Basecamp, я понял, что это может быть не так уж и плохо, когда я только начинаю свой путь.
Ради читателей я разделил свой бурный период обучения на этапы. Но есть предостережение: эти этапы не исключают друг друга. Они больше похожи на разные процессы, связанные с созданием приложения. Подробнее об этом позже.
Это руководство, которое я хотел бы прочитать перед тем, как начать свое путешествие по приложениям. Это отправная точка, когда финиша нигде не видно.
Фаза идеи
У вас может быть идея для приложения, а может и нет. Когда я начинал, я не знал, что хочу создать приложение для управления задачами. Я хотел что-то построить . Как инженер-программист, стремящийся знать все, что нужно знать об этом мире, я хотел запачкать руки.
Лучший способ найти идеи для приложений - это найти проблемы, с которыми вы сталкиваетесь сами. В мире 7 миллиардов человек, и шансы, что кто-то еще столкнется с той же проблемой, весьма высок.
Я понял, что мне нравится Jira как инструмент на рабочем месте. Это концепции Scrum и Agile, смоделированные в продукт. Я использовал аналогичные «Agile» концепции, чтобы отслеживать свою жизнь. Все это происходило в моем дневнике, который становился случайным, и его было нелегко поддерживать, поскольку я не совсем художник, у меня есть куча времени, чтобы сделать его красивым.
Но я могу кодировать и потенциально создавать продукты, поэтому я и решил сделать это.
У меня было еще много идей. Когда я начал думать об этом, у меня появилось много проблем, которые можно было решить с помощью различных приложений. Этот просто остался со мной.
Итак, у вас есть идея для приложения. Что дальше?
Вы можете начать кодировать его и столкнуться с массой проблем и переделывать по мере развития идеи. Или вы можете немного конкретизировать идею. Какую проблему он пытается решить? Кто является целевым клиентом?
Поскольку я создавал это приложение как любимый проект, я не вдавался в подробности о том, существует ли целевой клиент на самом деле. Если вы создаете приложение для своего бизнеса, это поможет провести исследование рынка и выявить потребности ваших клиентов.
Я бы посоветовал записать эти вещи. Ответьте на все вопросы почему, кто и как, прежде чем приступить к его созданию. Если вы будете ставить цели в центре внимания на последующих этапах, это поможет вам помнить о них при принятии важных решений.
Несколько вопросов, которые заставили меня задуматься, были:
- Зачем мне это приложение? Что я пытаюсь исправить?
- Для чего мне нужно это приложение? А чего мне этого не делать?
- Как приложение может наиболее эффективно решить мою проблему? Есть ли другой способ?
- Какие высокоуровневые функции будут в этом приложении (на словах)?
Фаза дизайна
Как только вы почувствуете, что это за идея на самом деле (то есть больше, чем однострочная), вы также автоматически начнете представлять, как она будет выглядеть.
Эскизы жирных маркеров
Очень легко погрузиться в такие мелкие детали, как размещение кнопок. На ранних стадиях мы этого не хотим. Мы просто хотим знать, как пользователь (то есть вы) будете следить за экранами, чтобы унять зуд (то есть проблему).
Для такого макета лучше всего подойдет набросок жирным маркером. Просто возьмите маркер с более толстым кончиком и начните рисовать на бумаге формата A4. Уровень детализации, который позволяет жирный маркер, идеально подходит для разработки карты пути пользователя, и он быстрый и грязный. Если мы хотим опробовать много разных карт, нам нужно быстро и грязно.
Подход с использованием жирного маркера помогает сосредоточиться на нужном уровне детализации. После того, как вы выбрали карту пути пользователя (из тех немногих, которые вы будете рисовать и в конечном итоге отбрасывать), каждый экран должен выполнять единственную основную функцию. Это скорее рекомендация, чтобы не сделать ваше окончательное приложение запутанным и неуклюжим, но это не правило.
Экраны с низким качеством изображения
Итак, у вас есть карта пути пользователя. Имейте в виду, что это не высечено на камне. Вы можете в любой момент настроить его или перейти на совершенно новый. Все эти размышления могли даже изменить ваши ответы на вопросы на стадии идеи. Все в порядке. Просто храните свои наблюдения в том же месте, что и анализ идеи.
Теперь посмотрите на каждый шаг в пользовательском процессе и перечислите самые важные действия, которые ваш пользователь будет выполнять на каждом экране. Эти действия должно быть проще всего выполнять на экране. От этого будут зависеть такие вещи, как размер и размещение кнопок. Теперь полезно взглянуть на идею / целевого пользователя, которого вы определили ранее, и взглянуть на эти новые наборы эскизов с немного более подробной информацией.
Чего я здесь делать не хочу, так это смотреть на цвета, тени или любую эстетику. Мы по-прежнему хотим, чтобы экраны приложений были просто функциональными и просто на бумаге. Наворотов пока нет.
Когда у меня есть очень общее представление о том, как пользователь будет взаимодействовать с экраном, я предпочитаю использовать инструмент для создания эскизов или дизайна, чтобы создать экран самого простого вида. Мой любимый инструмент - Figma. Он бесплатен с меньшей кривой обучения, чем такие вещи, как Adobe Suite of Tools, и поставляется с предустановленным множеством виджетов, которые распространены в приложениях, таких как стандартные размеры экрана, кнопки, значки и т. Д.
Я очень умоляю вас не использовать значки, если они не означают действенную цель на экране. Речь идет только о функции. Нам не нужно красивое приложение, которое не делает то, что намеревалось делать.
Как только ваши скетчи с низкой точностью будут выглядеть готовыми (потому что они никогда не будут полностью завершены, и в этом нет необходимости), Figma дает вам возможность прикреплять действия к элементам на экране. Таким образом, вы можете имитировать перемещение между экранами с помощью кнопок, которые вы нарисовали в интерфейсе. Это потрясающая функция, поскольку она помогает проверить, насколько точны ваши карты пути пользователя (формализованные в вашем наброске жирного маркера) в реальной жизни! Это действительно решение тех проблем, которые вы хотели решить? Неужели легко делать то, что должно быть проще всего делать на экране?
Это серьезная проверка на самых ранних этапах разработки приложения. Я имею в виду, что мы еще даже не думали о кодировании этой штуки, и у нас есть гораздо более конкретное понимание нашей очень расплывчатой идеи.
SideBar: цветовая палитра
Теперь вам нужно выбрать цветовую схему для своего приложения. Вы можете много думать об этом или совсем не думать. Я оставлю это на ваше усмотрение.
Это важный шаг для меня, потому что, начав кодировать, я не хочу отвлекаться на исследование цветов, но я также хочу закончить свой день кодирования чем-то, что выглядит законченным и красивым. Это очень важно для моей мотивации как разработчика.
Вторая причина в том, что цвет имеет значение. Зеленый означает свежесть, фиолетовый означает уверенность, красный означает агрессию или опасность, синий не дает уснуть и т. Д. Если вы создаете это приложение для воздействия (ссылаясь на результаты анализа стадии идеи), то выбор цвета, который будет представлять ваш бренд, может быть важным. . Я говорю «может», потому что, если вы не решите проблему, которую, по словам вашего бренда, он собирается решить, цветовая схема может увести вас далеко.
Но смотреть на цвета интересно, так что я все равно потрачу на это некоторое время. Давайте ограничим это временем до нескольких часов. В конце концов, я строю это для развлечения.
Фаза разработки
Выбор функции
Теперь у вас есть готово много частей вашего потенциального приложения. Проблема в том, что штук слишком много.
Итак, мы разбиваем все на наборы функций, а затем расставляем их по приоритетам.
Первые три функции будут MVP (минимально жизнеспособный продукт). Без этих трех наше приложение не смогло бы выполнить то, что было задумано на этапе разработки идеи.
Есть много преимуществ выбора MVP:
- Вы не обязуетесь использовать функции, которые, возможно, еще не требуются.
- Если вы возьмете на себя слишком много функций, вы потеряете фокус и мотивацию на этапе разработки.
- MVP уже разбит на управляемые функции, что делает работу видимой.
Сократите количество функций до минимума и приступайте к созданию.
Выберите стек технологий
К этому решению нельзя относиться легкомысленно. Чаще всего вы будете застрять с этим решением в предстоящей жизни приложения (если только вы не решите полностью переписать). Таким образом, потратьте много времени на изучение возможных вариантов.
Следует иметь в виду несколько соображений:
- Вы же не хотите выбирать стек, который требует огромного обучения. Быстро и грязно - это хорошо, пока оно стабильно.
- Вам не нужна технология, не пользующаяся поддержкой сообщества. Очень сложно отладить проблемы, с которыми вы неизбежно столкнетесь, если не можете их погуглить.
- Мне нравится сначала выбирать интерфейс, потому что он помогает мне точно знать, что на самом деле обслуживают серверные API. Фронтенд обслуживает клиентов, а бэкэнд - фронтенд. Мы идем от клиента, его потребностей, и движемся назад.
Вот некоторые из моих вариантов.
Интерфейс:
- Android: Java или Kotlin в Android Studio
- iOS: Swift с Apple XCode
- Кроссплатформенность: React Native + TypeScript или Flutter
Я выбрал React Native из-за поддержки сообщества и его кроссплатформенности.
Бэкэнд:
- BaaS: Firebase
- Традиционные бэкенды: Java или Node.js с решением БД
Я быстро понял, что мое приложение будет сильно загружено через интерфейс. Мне не нужно было вести две битвы, поэтому я решил выбрать Firebase в качестве бэкэнда.
Кодирование
Наконец-то мы можем приступить к программированию! Я здесь не для того, чтобы учить программированию. Есть миллион статей, множество документации и сообществ, которые помогут вам писать код.
Но я могу посоветовать вам помнить о нескольких вещах, которые не упоминаются в этих ресурсах:
- Иметь хорошую структуру папок - большинство фреймворков поставляются с базовым стартовым пакетом. Выбор хорошей структуры каталогов для аккуратной организации ваших функций может принести огромные дивиденды в долгосрочной перспективе. Это ускоряет будущую разработку, гарантируя, что текущие функции не сломаются.
- Создание глобальной темы CSS - я совершил ошибку, не создав тему CSS с цветовой палитрой, которую я доработал на этапе проектирования. Это вызывало много повторяющегося кода во внешнем интерфейсе, что делало его излишне тяжелым и сложным в обслуживании. Так делай или не делай. Твой выбор. Я бы предпочел избавиться от этого в первые дни написания кода в следующий раз.
- Тестирование в процессе написания кода. Кодирование и тестирование должны идти рука об руку. Продолжайте быстро тестировать небольшие изменения и по ходу исправлять ошибки. Ищите крайние случаи, потому что в противном случае ваши пользователи найдут их для вас. На раннем этапе протестируйте скелет на разных размерах и ориентациях. Если вы обнаружите недостатки конструкции, их будет легче исправить сейчас, чем позже.
Высококачественный дизайн (да, мы снова переходим к дизайну)
Я понимаю, что, хотя на бумаге все выглядит просто, кодирование - это совсем другая игра. Дизайн с низким качеством воспроизведения дал мне функции, которые мне нужно было развить. Как только у меня появились функции и их соответствие друг другу в коде, у меня появилось что-то функциональное. Оно работает. Выглядит некрасиво, но работает.
Выбирайте высококачественный дизайн, если у вас есть что-то - хотя бы одна функция - функциональная. Я смог действительно сосредоточиться на удобстве использования и впечатлениях от каждого экрана в самой Figma. Поскольку я уже начал разработку, у меня было четкое представление о препятствиях, с которыми мне предстоит столкнуться. Имея в виду обе эти вещи, я начал добавлять больше деталей в дизайн, от цвета до того, как будут выглядеть уведомления и насколько большим или маленьким должен быть текст на кнопках.
Это также помогло мне выявить любые вопиющие ошибки в моем дизайне. Их было много. Написав несколько функций, я смог выявить потенциальные проблемы с потоком. Затем я вернулся к чертежной доске, чтобы исправить их, и обратно в код, чтобы сделать необходимый подъем и сдвиг.
Фаза развертывания
Я использовал интерфейс React Native с серверной частью Firebase. Firebase - это потрясающая инфраструктура Backend-as-a-Service, которая предоставляет множество функций, таких как вход в систему, базы данных в реальном времени, Firestore и многое другое. Это был хороший выбор, чтобы быстро получить что-то функциональное спереди и сзади.
Еще одним преимуществом использования React Native было наличие Expo. Expo предоставила мне готовые функции для создания пакетов развертывания с помощью одной команды в интерфейсе командной строки.
Но по большей части вам нужен .apk файл, который нужно загрузить в Google Play Store. Play Store не так строг в отношении требований разработчиков приложений, как App Store, а Android по-прежнему остается одной из ведущих мобильных ОС на рынке.
Шаги по созданию учетной записи разработчика Google и доступа к консоли Google подробно описаны в этом руководстве.
Несколько вещей, которые вам понадобятся для вашей записи в Google Store:
- Пакет приложений (конечно).
- Разрешения и доступ, которые требуются на устройстве пользователя.
- Политика конфиденциальности, если вы получаете какую-либо личную информацию от своих пользователей (например, их адрес электронной почты).
- Скриншоты приложения, демонстрирующие его функции.
- Логотип (на Canva я сделал очень простой).
- Описание вашего приложения.
Некоторые мысли об обслуживании
И цикл продолжается!
Теперь у вас есть то, что вы можете показать миру и использовать сами. У вас будет больше улучшений, которые вы можете добавить к этому. Вы можете добавлять функции, удалять функции, делать это красивее, устранять ошибки.
Но это теперь существует в реальном мире. Ваше приложение вышло в свет. Пришло время заняться этим.
Отказ от ответственности: я плохо обслуживаю свое приложение, поэтому делайте, как я говорю, а не как я.
Исправление ошибок
Помимо общего обслуживания, о котором Google будет напоминать вам снова и снова, обязательно просите своих друзей и семью использовать приложение и сообщать об ошибках. Исправьте их быстро или в зависимости от приоритета.
Улучшения функций
Вы можете идти в ногу с этапами, упомянутыми выше, и выполнять Agile-спринты для создания функций и рассылки обновлений. Это процесс. Приложение будет постоянно развиваться.
Открытый исходный код
Вы можете опубликовать код, чтобы другие разработчики могли внести свой вклад и улучшить его. Самое лучшее в разработке программного обеспечения - это сообщество. Поскольку я не занимаюсь ни одним из двух пунктов выше, я хотел бы сделать это в будущем. Если кто-то заинтересован в совместной работе над этим, пожалуйста, свяжитесь со мной!
А для тех, кто держался до конца ...
Вот несколько скриншотов приложения!
Привет, я Мегна, инженер-программист, пишущий о технологиях, карьере и жизни. Если вам нравится то, что вы читаете, подумайте о том, чтобы присоединиться к моему информационному бюллетеню Off-by-One, чтобы получить дозу небольших изменений, которые вы можете сделать, чтобы сделать жизнь на 1% лучше.
