С чего начать нетехническому DOer, когда он будет готов запустить свое приложение? Независимо от того, решите ли вы передать свою идею на аутсорсинг или создать прототип самостоятельно, вы захотите запачкать руки и поработать над процессом создания макета. Зачем начинать с макета? Потому что картинки.

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

Отличное место для начала было бы посмотреть Учебник по простому приложению для задач прямо от Meteor Development Group. Мы разберем проект на этапы подготовки к разработке, используя стратегию сначала дизайн. Вот процесс, над которым мы будем работать:

  • Начните с истории пользователя, в которой подробно рассказывается, как кто-то будет использовать ваше приложение.
  • Создайте макет, который представляет собой грубую версию UI / UX пользовательской истории.
  • Разработайте модель данных на основе вашей пользовательской истории и макета.
  • Начните создавать интерфейс своего приложения

Оглядываясь назад на интеллектуальную карту Meteor Competencies, вот основные аспекты, которые мы собираемся использовать:

  • Интернет
  • MongoDB
  • Текстовый редактор

История пользователя

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

Давайте посмотрим на приложение с простыми задачами для примера пользовательской истории:

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

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

Как только Таня войдет в систему, у нее будет доступ к полю формы с просьбой «добавить задачу». После ввода задачи она может добавить ее в список, просто нажав клавишу ВВОД.

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

После установки флажка для завершения элемента задачи шрифт задачи становится темно-серым и имеет зачеркнутый стиль. Также уменьшается счетчик количества задач в списке дел.

Чтобы Таня знала, могут ли другие видеть ее элементы задачи, к элементу задачи прикреплена общедоступная / приватная кнопка.

Также у Тани есть возможность скрыть выполненные задачи, установив флажок с текстом «скрыть выполненные задачи».

Таня все это видит на одном экране.

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

Другие вещи, которые следует учитывать:

  • 5Ws - Кто что делает, когда, где и почему
  • Нужно ли сохранять информацию? (Взгляните еще раз на пользовательскую историю и напишите, какую информацию нужно сохранить для Тани.)
  • Какую обратную связь получает пользователь после взаимодействия? Предупреждение, сообщение, что-то появляется?
  • Где показано взаимодействие?
  • Есть ли изменения в анимации или стиле? Увеличиваются ли, сдвигаются, меняют цвет или выделяются предметы к предметам? (P.S. Дизайнеры любят, когда вы говорите «сделайте это популярным».)
  • Кто и к какой информации имеет доступ?
  • Что произойдет, если кто-то сделает обратное?
  • Избегайте расплывчатого слова вроде «оно» в черновике пользовательской истории, особенно при работе с другими людьми, чтобы обеспечить конкретные ссылки.

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

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

Макет

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

Как только у меня появится первоначальная идея, я буду повторять дизайн в Illustrator. Если вы новичок в дизайне, просто начните с карандаша и бумаги или нарисуйте коробки в Keynote или Powerpoint.

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

На что следует обратить внимание:

  • Включил ли я способ взаимодействия пользователя со всеми функциями пользовательской истории?
  • Как меняется пользовательский интерфейс?

Модель данных

Давайте начнем с красивой работы и построим модель данных. Все, что делает модель данных, это говорит, какую информацию мы должны хранить в нашей базе данных, чтобы наше приложение могло получить к ней доступ. В этом приложении задачи мы можем создавать или вставлять данные в нашу базу данных с помощью формы, считывать данные из нашей базы данных и отображать эти данные с помощью помощников в наших шаблонах Meteor, update данные, установив флажок, или удалить данные, нажав кнопку. Эти ключевые слова: insert, update и remove являются версией MongoDB стандартных операций CRUD (создание, чтение, обновление, уничтожение), используемых при разработке приложений.

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

Используя MongoDB, мы сначала определяем коллекцию (или имя для списка хранимой информации). Простое название коллекции для примера с простыми задачами - «Задачи». Нам определенно не нужно вдаваться в подробности. Мы будем использовать это название коллекции при создании нашего приложения, поэтому мы хотим дать ему как можно более конкретное имя, чтобы оно соответствовало данным, которые в нем хранятся.

Теперь, когда у нас есть коллекция MongoDB с именем «Задачи», мы можем определить схему. Когда вы смотрите на свои собственные макеты, подумайте о том, какие данные вы хотите вставить в форму, с какими данными взаимодействует пользователь и какие данные вы хотите отображать, которые необходимо сохранить даже после выхода пользователя из системы. В нашем простом примере давайте поработаем с правой верхней части нашего макета и спустимся вниз:

имя пользователя

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

Meteor.user().username

текст

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

проверил

Когда Таня устанавливает флажок, мы хотим сохранить, установлен ли флажок или нет. Как тип ввода html, флажок возвращает значение true или false. Итак, если флажок установлен и отображается флажок, значение будет истинным. Если она снимет флажок, значение будет ложным. Эти истинные или ложные значения являются логическими значениями.

частный

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

владелец

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

создано в

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

Возможно, вы подумали, что мы забыли добавить в нашу схему ключ, - это счетчик списка задач в верхней части приложения. Что ж, как только мы узнаем, сколько задач в нашей коллекции, которые еще не были отмечены как завершенные, мы можем использовать функцию MongoDB с именем .count (), чтобы подсчитать, сколько задач в нашей коллекции не отмечены, и вернуть число. .

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

Если бы мы хотели расширить функциональность этого приложения, потому что Таня хотела иметь несколько списков задач, таких как «дом» и «работа». Мы могли бы создать еще одну коллекцию MongoDB под названием «Списки», в которой будут храниться различные списки, создаваемые Таней. Мы также добавим еще один ключ в нашу коллекцию «Задачи» с именем listId, который будет соединять две коллекции.

Внешний интерфейс

Наконец-то пришло время программировать!

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

  1. Создайте полные интерфейсы (HTML и CSS) для приложения и жесткий код (или введите непосредственно) данные, которые вы замените позже, извлекая данные из своей коллекции; или
  2. Постройте свой интерфейс по функциям.

Оба варианта начинаются с HTML и CSS. Разница в том, когда вы начинаете связывать в приложении логику помощников, событий и манипулировать базой данных. Как я упоминал ранее, простой способ начать структурирование интерфейса - это использовать фреймворк css. Twitter Bootstrap, вероятно, является наиболее распространенным, в то время как другие, такие как Semantic-Ui, Materialize и Ionic или React Native для мобильных устройств, также предоставляют вам доступ к стилизованным компонентам с готовыми к использованию фрагментами кода.

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

В примере с простыми задачами они используют второй вариант - подход по отдельным функциям. После создания проекта Meteor на втором этапе они создают тело html-страницы с простым заголовком: Список задач. Ниже этого заголовка приведена логика Meteor Blaze о том, как мы можем извлечь массив (или список) данных и показать каждый элемент задачи индивидуально.

<!- simple-todos.html ->
...
<ul>
  {{#each tasks}}
    {{> task}}
  {{/each}}
</ul>
...

Этот блок кода говорит следующее: для каждого элемента в массиве с именем tasks распечатайте шаблон с именем задачи. Поскольку шаблон задачи находится в этом блоке кода {{#each}}… {{/ each}}, у него будет доступ ко всем элементам схемы задачи, например к тексту.

В этом примере они использовали переменную с именем задачи, которая равна массиву (обозначенному квадратными скобками []), который содержит три объектных литерала с ключом текста и значением того, что будет читать сохраненный текст. Эта структура массива аналогична тому, как возвращается курсор коллекции MongoDB, поэтому на третьем шаге вспомогательный массив задач заменяется запросом MondoDB к нашей недавно созданной коллекции задач:

// simple-todos.js
Template.body.helpers({
   tasks: function () {
      return Tasks.find({}); 
   }
});

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

Хорошо, это в основном обзор того, как начать создавать прототип собственного приложения с нуля. Мы рассмотрели, как создать подробную пользовательскую историю, как набросать макет, который представляет собой грубую версию пользовательского интерфейса / пользовательского опыта, мы разработали модель данных на основе вашей пользовательской истории и макета, и, наконец, мы приступили к созданию внешнего интерфейса приложения для простых задач, за которым вы можете следить до завершения на Meteor.com .

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

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

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