Как составлять макет программы

Область применения:Visual StudioVisual Studio для Mac Visual Studio Code

Вы можете создавать или настраивать части приложения на основе модели.

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

Создание кода приложения на основе модели

Самый простой способ создания кода — это использование текстовых шаблонов. Вы можете создать код в том же решении Visual Studio, в котором хранится модель. Дополнительные сведения см. в разделе:

5 ЛУЧШИХ РЕКЛАМНЫХ ФРАЗ ДЛЯ ТАРГЕТА // Что написать на рекламном макете?

• Создание кода во время разработки с помощью текстовых шаблонов T4
• Создание кода из доменного языка Этот метод легко применять последовательно. Начните с приложения, которое работает только для определенного случая, и выберите несколько его частей, которые должны изменяться в соответствии с моделью. Переименуйте исходные файлы этих частей, чтобы они стали файлами текстовых шаблонов (TT). На этом этапе исходные файлы CS будут автоматически созданы из файлов шаблонов, поэтому приложение будет работать точно так же, как и до этого. Затем можно взять одну часть кода и заменить ее выражением текстового шаблона, которое считывает модель и создает данную часть исходного файла. По крайней мере одно значение модели должно создавать первоначальный исходный код, чтобы приложение можно было запустить снова и оно работало так же, как и раньше. После проверки различных значений модели можно перейти к следующему этапу и вставить выражения шаблона в другую часть кода. Такой последовательный метод означает, что создание кода обычно является подходом с низким уровнем риска. Получающиеся приложения обычно работают почти так же хорошо, как и вручную написанная версия. Однако если начинать работу на основе существующего приложения, может оказаться, что для разделения различных поведений, управляемых моделью, требуется обширный рефакторинг, чтобы можно было изменять поведения независимо. Рекомендуется рассматривать этот аспект приложения при оценке стоимости проекта.

Настройка приложения на основе модели

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

Как Подготовить МАКЕТ К ПЕЧАТИ в Adobe Illustrator?

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

Разработка производного приложения

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

• Начинайте с конкретного, потом обобщайте. Сначала напишите конкретную версию приложения. Эта версия должна работать при одном наборе условий. Когда будет определено, что приложение работает правильно, часть его можно сделать производной от модели. Расширяйте производные части постепенно. Например, создайте веб-сайт с определенным набором веб-страниц перед созданием веб-приложения, которое представляет страницы, определенные в модели.
• Создайте модель переменных аспектов. Определите аспекты, которые либо будут различаться в разных развертываниях, либо будут изменяться с течением времени по мере изменения требований. Эти аспекты должны определяться моделью. Например, если набор веб-страниц и ссылок между ними изменяется, но стиль и формат страниц всегда одинаковы, модель должна описывать ссылки, но не должна описывать формат страниц.
• Отдельные проблемы. Если переменные аспекты можно разделить на независимые области, используйте отдельные модели для каждой из них. С помощью ModelBus можно определить операции, влияющие как на модели, так и на их ограничения. Например, используйте одну модель для определения навигации между веб-страницами, а другую — для определения макета страниц.
• Моделируйте требование, а не решение. Спроектируйте модель так, чтобы она описывала требования пользователей. Не следует разрабатывать нотацию в соответствии с переменными аспектами реализации. Например, модель веб-навигации должна представлять веб-страницы и гиперссылки между ними. Модель веб-навигации не должна представлять фрагменты HTML или классов в приложении.
• Генерирование или интерпретация? Если требования для конкретного развертывания будут изменяться редко, создайте код программы на основе модели. Если возможны частые изменения требований или в одном развертывании могут сосуществовать несколько вариантов, напишите приложение, способное считывать и интерпретировать модель. Например, если вы используете модель веб-сайта для разработки ряда различных и отдельно установленных веб-сайтов, следует создать код сайта на основе модели. Но вы используете свою модель для управления сайтом, который меняется каждый день, то лучше написать веб-сервер, который считывает модель и представляет сайт соответствующим образом.
• UML или DSL? Рассмотрите возможность создания нотации моделирования с использованием стереотипов для расширения UML. Определите модель DSL при отсутствии схемы UML, удовлетворяющей конкретной цели. Однако избегайте нарушения стандартной семантики языка UML. Например, схема классов UML представляет собой набор прямоугольников и стрелок. Теоретически с помощью этой нотации можно определить все что угодно. Однако схему классов рекомендуется использовать только в том случае, если вы действительно описываете набор типов. Например, можно адаптировать схемы классов для описания различных типов веб-страниц.

См. также раздел

• Создание кода из доменного языка
• Практическое руководство. Открытие модели из файла в коде программы
• Создание кода во время разработки с помощью текстовых шаблонов T4

Источник: learn.microsoft.com

Как передавать макет приложения разработчику: чек-лист

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

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

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

Важное замечание. хорошо работает на небольших проектах, которые ты делаешь сам(а), организуя всё понятным тебе и только тебе образом, и не работает на крупных проектах (мобильное приложение ИЛЬ ДЕ БОТЭ — один из таких примеров в портфолио Лайв Тайпинг), в которых заняты несколько дизайнеров. Во втором случае система должна быть понятна всем дизайнерам сразу, для чего нужно создавать библиотеки стилей Это уже совсем другая история.

Я буду опираться на процесс, который принят у нас в Лайв Тайпинг: дизайнеры рисуют все макеты интерфейсов в Sketch, а разработчики принимают их в Zeplin. Это удобно, потому что:

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

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

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

Упорядоченная работа дизайнера в Sketch

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

• Ведите макеты для iOS и для Android в отдельных файлах.
• Все повторяющиеся элементы (иконки, элементы управления, таб- и , кнопки, девайдеры ) делайте символами. Если вы работали в Photoshop, то наверняка помните в нём возможность создавать . Символы в Sketch работают по тому же принципу. Когда вы создаёте символ и используете его в качестве повторяющегося в макете элемента, вы можете изменять все его копии сразу, редактируя только сам символ. Ещё один занимательный факт о символах: с ними повторяющийся элемент в любом месте макета будет одним и тем же, и в конце работы вам не нужно будет подчищать отличающиеся кнопки или иконки. А если рабочий файл нужно передать другому дизайнеру, вам не придётся ему объяснять, какая из десяти похожих кнопок правильная. Подробнее о том, как создавать символы, хорошо рассказано в этой статье.

Пример использования символа — строка с категорией каталога

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

Цвет кнопки на примере выше задан стилем

Стили ускорят вашу работу и не дадут применить к элементу похожий, но не идентичный цвет. Вы избежите ошибок с интерлиньяжем, цветом, размером, начертанием и самой гарнитурой. Когда вам нужно поменять размер шрифта, например, в блоках основного текста, вы сможете быстро изменить вид всех текстовых блоков с таким же стилем. Но! Если вы хотите оформить блок под конкретное окружение на одном экране — не редактируйте его стиль: другие текстовые блоки с этим стилем «поплывут».

Называть текстовые стили стоит осознанно, так вы сможете применять его быстрее. Например, по такому принципу: для чего используется текст, начертание (regular), размер (17 pt).

А вот так в Sketch упорядочиваются текстовые стили

Когда вы экспортируете проект в Zeplin, все цветовые и текстовые стили можно будет добавить на удобную и понятную панель — разработчик при первом же знакомстве с макетом увидит, с чем он будет работать.

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

• Мы в Лайв Тайпинг чаще всего следуем рекомендации «на одном экране не больше четырёх начертаний и кеглей одного шрифта». Это экономит время разработчика и чаще всего оправдано с точки зрения эстетики и юзабилити.

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

• Договоритесь внутри команды о правилах наименования элементов и придерживайтесь их. Мы приняли у себя такой порядок: сокращение от типа объекта_название объекта. В итоге должна получиться вот такая запись — ic_name, где ic означает icon, а name — название этой иконки. Название не должно содержать кириллицы и дополнительных символов, если только это не нижнее подчеркивание.

Почему это важно? Название элемента должно отсылать к его функции. Если из Zeplin скачать элемент с названием, например, shape1, то остаётся непонятным, в какую часть проекта его встраивать. Разработчик может переименовать загруженные файлы с элементами сам, но на каждый элемент у него будет по три файла для iOS и по пять для Android.

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

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

• Следите, чтобы в размерах элементов и в расстояниях между ними не было дробных пикселей. А ещё лучше выражайте все размеры и расстояния чётными числами. Дробные пиксели в расстояниях могут появиться, если вы выравниваете элементы по центру относительно друг друга, пользуетесь функцией round pixel или меняете размеры иконки. Если векторную иконку не получается выровнять вручную, вокруг неё можно создать пустой прямоугольник с правильными размерами и объединить его вместе с иконкой в символ. При экспорте в Zeplin вы получите иконку с паддингом правильного размера.

• Ещё одна хорошая привычка — сразу содержательно называть артборды в Sketch. Это полезно, если вы каждый раз рисуете новый экран на новом артборде. Когда вы экспортируете дизайн приложения в Zeplin, содержательные названия артбордов облегчат разработчику ориентацию в макете.

• Сразу группируйте в Sketch экраны макета по табам или разделам в приложении — так будет проще ориентироваться уже вам.

Экраны лежат по группам «Авторизация в приложении», «Главная» и «Контакты»

Подготовка макетов для передачи разработчикам

• Проверьте ещё раз все пункты по списку выше.
• Вынесите все элементы, которые разработчик не может создать кодом, в отдельный артборд. Это могут быть иконки, карточки и другие элементы. Когда все такие элементы собраны в одном месте, найти их проще.

Все нужные элементы вынесены из макета

• Нарежьте все графические элементы, которые разработчик не сможет отобразить кодом. Для этого сохраните элементы в пяти разных размерах для Android и в трех размерах для iOS. Разработчик будет скачивать себе все эти файлы по мере надобности. Перед этим не забудьте правильно их назвать.
• Если вы делаете приложение для iOS, нужно предусмотреть, как оно будет выглядеть на разных устройствах (для iPhone 5, 6, 7, 7+, 10): если элементы отличаются, нужно показать это. Мы делаем так: создаем отдельный борд в Sketch, указываем версию смартфона и показываем, как элементы будут выглядеть для конкретной модели.
• Покажите все состояния повторяющихся контролов: как выглядит ховер, как выглядит нажатие кнопки, как выглядит форма с активной клавиатурой и без неё, как выглядит поле, когда в него вводят текст, как оно выглядит, когда текст введён

Неочевидный для новичков факт: для форм важно отображать экран с активной клавиатурой

• Обращайте внимание на то, что говорят гайдлайны в таких случаях, чтобы разработчикам не пришлось делать лишнюю работу, если речь идет об Android.
• Продумайте, как должны выглядеть ошибки в приложении. Например, что должно показать пользователю приложение, если тот задаст параметры фильтров, под которые не подпадает ни один элемент из перечня? Как должен выглядеть экран с избранными товарами, когда пользователь ещё ничего не добавил в избранное? Что делать, если нет соединения с интернетом? Составьте список всех подобных ситуаций и покажите, как они должны выглядеть, предложите пользователю другое логичное действие вместо недоступного.

Примеры экранов ошибок в проектах Лайв Тайпинг

• Не забывайте, что приложению нужен лоадер и . — это экран, который пользователь видит перед экраном прелоадера. Как пишет в одной из своих статей Илья Бирман, «заставки при загрузке приложений не нужны: они не решают никакой задачи пользователя». В том, чтобы занимать весь экран заставкой (то есть лоадером) с рекламой продукта, которым человек и так начал пользоваться, мало смысла. Вместо этого лучше показать скриншот экрана приложения или упрощенные блоки контента на экране, как на примере ниже.

Такой подготавливает человека к тому, что он увидит на экране.

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

• Кроме лоадера отобразите все нетипичные состояния экрана при скролле. На примере ниже пользователь перемещается по карточке фильма вниз, при этом сверху закрепляется календарь. Он помогает выбирать сеансы в разные дни недели. Такие особенности интерфейса нужно продумывать и показывать до того, как за макет возьмётся разработчик.

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

• Загружайте в Zeplin все цвета, используемые в приложении, и все стили шрифтов: начертания, размер и цвет шрифта.
• Оформите карту экранов — схему, где все скрины связаны стрелочками, показывающими переходы между ними.

Так все связи между экранами и элементами станут очевидны

• И последний совет. Называйте все экраны либо номерами, которые совпадают с картой экранов, либо названиями, которые рассказывают о том, что происходит на экране.

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

Источник: livetyping.com

Как создать бизнес-план для мобильного приложения

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

В этой статье разбираемся, как правильно написать бизнес-план, чтобы помочь и себе, и своей команде.

Время чтения: 8 минут

Зачем писать бизнес-план?

С помощью бизнес-плана закладывается фундамент любого проекта. Его часто сравнивают с картой, которая помогает добраться из пункта А (идея) до пункта Б (успех) и при этом не свернуть в пункт В (банкротство). Если уйти от метафор, то этот документ также можно описать как набор инструкций, чтобы разрабатывать стратегии развития и эффективно управлять бюджетом.

Бизнес-план помогает команде двигаться в нужном направлении

Грамотно составленный бизнес-план позволяет опираться на факты и точные расчеты, чтобы определять общее направление бизнеса. Вы сможете:

• Получать полезные инсайты о конкурентах и текущем состоянии рынка
• Принимать взвешенные решения в отношении маркетинга и коммуникаций
• Создавать подробные финансовые стратегии
• Объективно оценивать результаты работы и распределять ресурсы

Этот документ также поможет эффективнее управлять командой:

• Все будут точно понимать, к каким целям нужно стремиться
• Вы сможете правильно расставлять приоритеты и определять KPI

И это еще не все: бизнес-план также незаменим, если вам нужно завоевать доверие инвесторов и стейкхолдеров.

Можно ещё долго говорить про пользу бизнес-плана, но мы лучше просто покажем статистику. Крупная калифорнийская компания Palo Alto Software недавно провела опрос https://timberry.bplans.com/real-data-on-the-success-of-business-planning/

среди 2900 предпринимателей и обнаружила следующее: у инициатив, которые опираются на бизнес-план, в два раза больше шансов добиться успеха. Чтобы измерить «успех», Palo Alto использовала три метрики: рост бизнеса, объем привлеченных инвестиций и объем одобренных займов.

Как выглядит бизнес-план

Стандартный бизнес-план включает в себя 8 глав:

1. Резюме
2. Описание продукта
3. Обзор компании
4. Анализ аудитории
5. Анализ конкурентов
6. Маркетинговая стратегия
7. Финансовая стратегия
8. Приложения

Обычно все эти секции занимают не больше 20–40 страниц, однако конкретный объем зависит от масштабов проекта и ваших целей. Бизнес-план среднего по величине стартапа вряд ли займет больше 50 страниц, а вот бизнес-план международной корпорации может включать в себя сотни страниц.

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

READ MORE Хочешь поймать рыбу — думай как рыба: учимся понимать инвесторов и то, как они выбирают стартапы

На что обратить внимание

Собрали несколько советов, которые помогут вам при написании бизнес-плана. После этого перейдем непосредственно к тому, как его писать.

Цель

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

Структура

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

Заголовки, подзаголовки и диаграммы помогут структурировать документ

Объективные прогнозы

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

Взгляд со стороны

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

Пишем бизнес-план: пошаговая инструкция