Посоветуйте вводный курс в Xcode 5 для дизайнера

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

Чему хочу научиться:

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

2. Использовать библиотеки анимаций, подключаемые при помощи Cocoapods. Опять же, делать анимации напрямую в Xcode.

Где или у кого можно получить такие знания?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Добрый день, Иван! Если еще актуально, можем Вам помочь. Подавайте запрос на info о индивидуальных программах .

Оффтоп: у вас там на корп. сайте в форме обратной связи вместо Send написано Sent на кнопке отправки месседжа. Повбивав би... )))) (шутка).

Пока мы тут писали, MengTO запустил обучающий курс для дизайнеров designcode.io

Не так давно задавался тем же вопросом. Пробовал различные редакторы, как онлайн сервисы, так и приложения — везде одна и та же проблема, нельзя нормально продемонстрировать работу кастомных элементов, подходят только для полностью стандартных приложений на несколько экранов.
Также был опыт с использованием js для прототипирования, в итоге отказался — результат получается хороший, но временные затраты просто огромны. Пришел все же к тому, что разработчику лучше всего отдавать экраны, нарезку, карту приложения, спецификации по шрифтам и точным координатам (iOs) или координатам и поведению элементов при растяжке (Android, Win) и гифы (если есть нестандартная анимация).
P.S. PNG Express для шопа просто шикарен для составления спецификаций и нарезки.

А где-нибудь можно этот самый png express попробовать, прежде чем купить?

а может вам лучше для прототипирования использовать не XCode, а Quartz Composer + Origami?
vimeo.com/85578380

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

К сожалению оно хорошо только в качестве самопиара и демонстрации возможностей Xcode. Первая же попытка, скажем, запустить этот прототип на IOS 6 или устройстве с другой диагональю приведет к пониманию, что не все в этой жизни так просто.
А правильный расчет необходимой высоты балунчика и текста чата в нем гарантирует батхерт дня на два девелоперу, который этого еще не делал. Так как глючен что для UITextView, что для UILabel, но по разному.

Tim, никто от дизайнера не требует полную совместимость с кучей осей и девайсов, запустится на одном — и ладушки. Главная цель — получить вменяемый нативный прототип, избавившись от объяснений «на пальцах» разработчику, что где должно быть и как будет работать.

Хотел бы я работать с таким дизайнером, как Вы. )
Как правило — набора UIKit + размахаек внешнего вида и координат элементов для каждого скрина для разработчика достаточно.
Идеально, когда еще есть гифки с анимациями (достаточно generic примеров, конкретики на конкретном дизайне никто не ждет, т.к. все равно анимацию программировать). Ну и шрифты, конечно (про них все всегда забывают).
Практически всегда в требованиях к приложению будет совместимость как минимум с предыдущей (на сегодня 6) версией IOS, а для универсальных и iPad приложений еще и IOS5 (iPad 1 все еще процентов 30 на рынке). И эту совместимость приходится программировать — многие вещи через IB не сделаешь. Кроме того — там «едут» размеры, положения элементов друг относительно друга и т.д.
В любом случае сначала поинтересуйтесь у тимлида или ведущего разраба — используются ли сториборды в проекте вообще.
Но даже если и да, то не факт что им будет удобнее, если сториборд соберете Вы, а не они. Возможно есть смысл получить его в женерик виде от них и задекорировать элементами дизайна.

Статью эту я читал, собственно на основе нее и появился этот пост.

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

вам оно не нужно. Половина UI верстается совсем не так, как вы думаете.
Или учите obj-c и вперед педалить

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

тогда вам на курсы ios разработки

Надеюсь, сейчас придет коллега trimm и более подробно расскажет.
Что же касается моей точки зрения (не дизайнера — разработчика), Xcode жутко неудобная среда для разработки дизайна. Кроме того, не будучи разработчиком, Вам врятли удастся правильно построить иерархию элементов для использования в коде.
Из наиболее очевидных недостатков:
1. Многие элементы (подложки и тинты навбаров, их кнопок, слайдеры, мультиконтролы и т.д.) обычно устанавливаются в нужный дизайн в коде «оптом» при помощи appearance, так что их нет вообще смысла рисовать для каждого экрана. Но и единожды нарисованные в NIB они смысла не имеют, т.к. механизм исключительно программный.
2. Сториборды используют только индусы и совсем начинающие разработчики. У них огромное количество проблем, для обхода которых нужно количество кода, сравнимое с программной реализацией всей иерархии.
3. NIB-ы снова-таки используются обычно только в случае совсем простых интерфейсов с жестко прибитым большим количеством графических элементов (когда лень им координаты программно считать).
4. IB не позволяет сделать зум больше 100%. Вы, как дизайнер, понимаете что это значит и что можно делать в таком редакторе...
5. IB категорически не приемлет кастомных элементов интерфейсов — боковых меню, драг-ту-рефреш элементов и т.д. Кроме того — визуализация таблиц и коллекций не позволит оценить их внешний вид прямо из IB — в любом случае придется рисовать дополнительно еще в редакторе.
6. Эффекты и анимации — увы, пока единственный и идеальный для разработчика способ — ссылка на конкретный элемент на сайте cocoapods сотоварищи с пояснениями типа «и с перламутровыми пуговицами». Замечательно кстати, что Вы затронули эту тему — обычно от дизайнеров добиться типов анимации вообще нереально. )

А вообще идеальный дизайнер с точки зрения разработчика, это:
1. Знает штатные размеры элементов и делает графику строго по ним.
2. Растеризует ее с понятными именами файлов и во всех необходимых разрешениях (не забывая про @2x, @4x), не размножает один и тот же элемент для разных вью.
3. Не допускает ошибок юзабилити вроде 4 кнопок 5×5 пикселей, расположенных рядом, скролл-вью внутри другого скролл-вью, шторок поверх штатных шторок, неочевидных элементов (как бэкграунд кнопки, но не кнопка) и пр.
4. Считает анимации частью дизайна и в понятном виде передает требования к ним разработчику.
5. Не пропадает на 3 недели (шутка)

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

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

1. Сделать UI kit со всеми нажатиями и видами состояний элементов в отдельном файле.
2. Нарезать иконки, картинки, иногда и кнопки; или во всяком случае вынести их в отдельный файл со всеми размерами.
3. Сделать анамации в каком-то редакторе, даже для стандартных анимашек iOS этот этап может занять столько же времени, как и основной дизайн.
4. Сделать схему-разметку с размерами элементов, отступов, цветами и шрифтами экранов.
5. Схему взаимодействия, объясняющую порядок переходов и навигациию по приложению + пояснения где какая анимация применяется (частично решается всякими программами прототипирования)
6. Добавить звуковые файлы, если нужно, с описанием где и как их применять.

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

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

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

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

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

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

Что если для одного экрана, нужны разные разные лайауты для iPhone и iPad. В случае обычных ксибов, просто создаем ViewConroller~ipad.xib. В случае сторибордов получаем здоровенный такой костылище.

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

Подписаться на комментарии