Требования к макетам

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

Corel Draw:

1.  Макеты в файле должны быть расположены постранично, то есть на одной странице – один, на второй – следующий. Если продукция двусторонняя, на первой странице располагается «лицо», а второй – оборот и так далее.
2. Размер страницы должен быть равен размеру продукции.
   Существуют 2 наиболее распространенных формата визиток: российский (90х50 мм) и европейский (85х55 мм).
3. Информационная часть (адреса, телефоны, имена, должности, логотип, название фирмы и т. д.) должна располагаться не ближе 4 мм к обрезному формату. Таким образом, если визитка имеет размеры 90х50 мм, вся информация должна поместиться на площади 82х42 мм, если размер 85х55 мм, соответственно, 77х47 мм. Аналогично визиткам делаются все остальные форматы.
4. Все элементы «на вылет» должны выступать за границы реза как минимум на 2 мм.
5. Все шрифты должны быть переведены в кривые (это можно сделать, разгруппировав макет (Ctrl + U) и нажав сочетание клавиш Ctrl + Q).
6. Логотип и фирменный знак должны быть отрисованы векторами.(желательно).
7. Если в макете есть растровые изображения, они должны иметь разрешение 300 dpi, любые специальные эффекты должны быть преобразованы в растровую графику. Добиться этого можно с помощью выполнения следующих команд: BitMaps > Convert to Bitmap — 300 dpi CMYK. Также очень важно, чтобы растровые изображения были выполнены в цветовой модели CMYK, так как цифровая печать предполагает печать 4 красками). Также необходимо знать, что вероятность того, что растр менее 5% при печати будет практически незаметен, очень велика.

Adobe Illustrator:

1. Файл должен быть сохранен в формате .eps, в 8-й версии.
2. Каждая визитка (или сторона визитки) должна быть выполнена в отдельном файле (Adobe Illustrator не поддерживает многостраничность) с прозрачной рамкой, равная размеру визитки.
3. Информационная часть (адреса, телефоны, имена, должности, логотип, название фирмы и т. д.) должна располагаться не ближе 4 мм к обрезному формату.
4. Все элементы «на вылет» должны выступать за границы реза как минимум на 2 мм.
5. Все шрифты должны быть переведены в кривые (этого можно достичь, выполнив следующие действия Type > Create Outlines).
6. Логотип и фирменный знак должны быть отрисованы векторами.
7. Если в макете использована прозрачность, все ее элементы обязательно должны быть переведены на один слой цветовой модели CMYK.
8. Стоит помнить, что растр ниже 5% скорее всего не будет виден при печати.

Photoshop:

1. Макет должен быть сохранен в формате TIFF Uncompressed одним слоем. Разрешение слоя должно быть 300 dpi.
2. Размер изображения должен быть равен размеру продукции с учетом полей «на  вылет» (поля на вылет должны равняться не менее 4 мм).
3. Вся информационная часть должна располагаться на расстоянии не менее 4 мм с каждой стороны от обрезного формата.
4. Макет, выполненный в данной программе, не должен содержать:
   • меток обреза;
   • дополнительных слоев;
   • дополнительных путей.

Важно помнить, что:

1. При печати разными технологиями (цифровой печатью, шелкографией или офсетом) одни и те же цвета по Panton выглядят по-разному. Если Вам важен какой-то определенный цвет, рекомендуем напечатать пробный лист.
2. При печати цифровым способом на фактурных бумагах (например, лен), а также на некоторых видах Металлика запечатка красок производится неравномерно. 
3. Изображения, имеющие разрешение меньше 300 dpi, как правило, при печати получаются не качественно.
4. Шрифты, не переведенные в кривые, могут изменить свой внешний вид.
5. Для изготовления визиток методом шелкографии, а также с использованием тиснения и конгрева, пригодны только изображения, отрисованные векторами.
6. Сделать градиент при помощи тиснения невозможно.
7. При печати методом шелкографии градиент получается крупными точками

Макет отправляется в программе для печати и в формате jpg для визуального просмотра файла для каждой страницы.

Макеты подготовленные в других программах возможно присылать в формате pdf. (обговаривается отдельно)

Макет отправленный заказчиком считается утвержденным и проверенным самим заказчиком.

Как устроена работа продуктового дизайнера. Гайд для создания лучшего решения — Дизайн на vc.ru

Зачем нужны продуктовые дизайнеры и в чем их ценность — в колонке Никиты Денисенко, тимлида дизайн-студии Ростелекома.

9280
просмотров

«На небе только и разговоров, что о море…».

Равно так же ИТ-сообщество в России продолжает обсуждать, кто же такой этот продуктовый дизайнер и какова его роль в продукте. Ряд компаний просто использует модный термин для развития своего бренда работодателя, другие подразумевают под этим просто UI-дизайнера. И лишь единицы понимают ценность этого специалиста и истинный смысл его работы. Давайте вместе разберемся, кто же такой этот продуктовый дизайнер и как он работает.

Введение. Эволюция цифровых дизайнеров в России

Поле действия дизайнера цифровых интерфейсов со времени появления этой профессии в нашей стране постоянно расширяется.

Веб-дизайнер занимался отрисовкой сайтиков в фотошопе.

UI-дизайнер начал уже сильнее влиять на образ продукта, создавать визуальный стиль и язык цифровых интерфейсов компании.

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

UX/UI, UI/UX и прочие комбинации по сути являются мультистаночниками, но с определенным уклоном — приоритетное направление ставится до /.

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

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

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

Глава 1. Три кита продуктового дизайна

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

Бизнес-ценность

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

Пользователи

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

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

Технологический стек

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

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

Бонус: ещё раз про коммуникации

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

Вот не надо так. Пожалуйста, выравнивайтесь вместе.

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

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

Итак, вот из каких этапов состоит работа.

Глава 2. Этапы. Подготовка

1. Планирование роадмапа по дизайну

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

📥 Требуется: роадмап продукта, бэклог разработки.

🎁 Результат: роадмап по дизайну

2. Формирование задач на спринты

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

Естественно, это будет приближенное планирование, которое надо уточнять в ходе проекта и после завершения спринта.

Да-да, конечно, надо проектировать от общего к частному, но для художественного приёма порежем котика поперёк

📥 Требуется: роадмап по дизайну

🎁 Результат: список задач на спринт или несколько спринтов

3. Аналитика

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

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

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

📥 Требуется: подготовленный план исследований (список гипотез, методы проверки), сценарии от бизнес-аналитиков, фокус-группа пользователей для проведения исследования

🎁 Результат: ролевая модель, сегменты пользователей в формате Jobs to be Done (JTBD) или User Story, описание путей пользователя в виде Customer Journey Map (CJM) или карта продукта (она немного проще)

Глава 3. Этапы. Активное проектирование

1. Макеты низкой детализации

Вайрфреймы (от англ. wireframe — каркас) экономят ресурсы: дизайнер может сразу обсудить реализацию сценариев с аналитиками, бизнесом и разработчиками, не тратя времени на отрисовку красивого UI. Есть и второй плюс — при согласовании никто не будет обсуждать цвет кнопок, все будут сконцентрированы именно на спроектированной логике продукта. На этом этапе структура интерфейса и последовательность экранов могут несколько раз кардинально измениться.

Самое главное здесь — выровняться, определить основные навигационные паттерны и более частные концептуальные решения с учетом потенциального масштабирования продукта.

Для вайрфреймов даже такой уровень детализации не требуется. Скорее, он будет напоминать быстрый набросок с указаниями «вот тут капот», «место для колеса» и т.д.

📥 Требуется: описание путей пользователя в виде Customer Journey Map (CJM) или карта продукта

🎁 Результат: макеты низкой детализации, утвержденная навигационная логика и общие паттерны в продукте

2. Визуальный дизайн

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

Как и в промдизайне, конструкция диктует визуальный стиль. Ровно так же работают UX и UI.

📥 Требуется: референсы, конкурентный анализ, видение настроения и эмоций продукта от оунеров и заказчиков, макеты с низкой детализацией

🎁 Результат: визуальный стиль продукта, макеты высокой детализации (UI)

3. UX-тестирование макетов

Внесение изменений в макеты всё же дешевле, чем повторная верстка в коде, поэтому рекомендуем тестировать на кликабельных прототипах качество проектирования интерфейса. Для этого дизайнер может использовать список составленных ранее гипотез и отрисованные макеты. Также понадобится фокус-группа пользователей. По результатам UX-исследования можно внести корректировки в макеты и передать их разработке.
Важно понимать, что при составлении сценариев для тестирования пользователем нельзя указывать шаги с конкретными UI-элементами. То есть «нажмите на кнопку «создать»…» — неправильно. «Создайте…» — правильно. Пользователь должен самостоятельно найти решение в интерфейсе, а не выполнять задачу по поиску геометрических фигур.

📥 Требуется: посценарно собранные интерактивные прототипы, список гипотез для проверки, фокус-группа

🎁 Результат: подтверждение спроектированных решений и/или список необходимых доработок с приоритизацией для пользователей

Глава 4. Этапы. Поддержка разработки

1. Передача документации в разработку

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

📥 Требуется: макеты высокой детализации, UI Kit, сценарии

🎁 Результат: согласованный пул задач на разработку с прикрепленной дизайн-документацией

2. Ревью верстки

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

📥 Требуется: доступ к стенду (ко всем ролям), договоренность о формате проведения ревью и регистрации багов

🎁 Результат: доступ к стенду (ко всем ролям), договоренность о формате проведения ревью и регистрации багов

3. UX-тестирование сборки

Тестирование сборки нужно для того, чтобы проверить продуктовые гипотезы на большей аудитории. Да, мы проверяли всё на макетах. Но важно понимать, что опыт реальной эксплуатации сильно отличается от синтетического прохождения сценариев. Хотя на данном этапе мы вряд ли будем опровергать гипотезы. Скорее корректировать и находить новые кейсы использования. Обычно в таких исследованиях участвует гораздо больше респондентов, чем в UX-тестировании макетов, и сам процесс длится дольше.
Исследования могут быть не только количественные, но и качественные. На основе этих исследований составляется список гипотез дальнейшего развития продукта, которые можно включить в роадмап или скорректировать уже имеющийся план на последующие спринты.

📥 Требуется: фокус-группа пользователей продукта, доступ к информации из инструмента аналитики (Яндекс.Метрика, Google Analytics и т.д.)

🎁 Результат: оценка успешности реализации интерфейса, обновление и корректировка роадмапа

Заключение

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

Подготовили:
Иван Манжулов (ТГ: @john_smthn) и Никита Денисенко (ТГ: @nikdenisenko)
Тимлиды направления профинтерфейсов центра компетенций UX/UI Ростелеком ИТ

Render in LAYOUT as Solid

Корпорация OMAX не несет ответственности за неточности перевода, выполненные Google Translate™.

__________________________________________

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

Причины рендеринга

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

 

Пример визуализации в LAYOUT в виде тела.

Пример рендеринга в LAYOUT в виде твердого тела с объектами.

ПРИМЕЧАНИЕ

В LAYOUT есть несколько мест, где можно «рендерить». Эта страница справки относится к рендерингу из основного экрана LAYOUT. Также возможно визуализировать окончательный путь инструмента, что является другой темой. См. также: Отрисовка траектории инструмента как твердого тела.

Рендеринг временно отрисовывает экран. Последующие перерисовки экрана очищают визуализацию. Можно выполнить рендеринг в буфер обмена Windows, либо щелкнув правой кнопкой мыши кнопку «Визуализация» и выбрав «Визуализировать в буфер обмена Windows», либо удерживая клавишу SHIFT в самом начале рендеринга. Также можно выполнить визуализацию в файл .jpg, щелкнув правой кнопкой мыши кнопку «Визуализация» и выбрав «Визуализировать в файл».

Рендеринг не идеален и следует некоторым правилам, чтобы добиться наилучшего результата:

• Чтобы команда «Визуализировать в LAYOUT as Solid» работала, сначала нужно начертить что-то, что разумно ожидать для вырезания на станке. Это означает, что качества должны быть назначены, и деталь должна иметь непрерывно связанные элементы, чтобы определить ее. (Большинство образцов файлов ProtoMAX соответствуют этим критериям.)
• Во время работы в главном редакторе в LAYOUT программа ничего не «знает» о вашей детали, последовательности резки и т.д., кроме линий и дуг и качеств, с которыми вы работаете. Из-за этого он может только предположить, каким может быть окончательное намерение вашей части и пути. По этой причине рендеринг возможен не для каждого возможного разреза. Программное обеспечение должно сделать некоторые предположения о том, какие элементы определяют деталь, какие элементы определяют брак, какие элементы определяют прорези, травление и т. д. Иногда он будет делать неверные предположения, и рендер будет выглядеть не так, как вы ожидаете. В этом случае рекомендуется либо не использовать рендеринг, либо найти альтернативный метод, например стороннее программное обеспечение, чтобы сделать то, что вам нужно. Рендеринг лучше всего подходит для 2D-деталей, которые большинство людей чаще всего вырезают на своих машинах.

Некоторые вещи, которые могут запутать процесс рендеринга:

• Режущие объекты не назначены (процесс визуализации игнорирует ходы)
• Объекты, которые не имеют ничего общего с конечной частью (например, строительные объекты, если только они не нарисованы зеленым цветом, которые будут просто проигнорированы).
• 3D-функции, такие как вторичные вырезы для создания сложных скосов
• Выступы и зазоры (которые будут визуализированы, но не будут считать деталь чем-то отличным от обрезков вокруг нее, как если бы вы просто вырезали паз. )
• Если рендеринг не дает ожидаемых результатов, учтите также, что алгоритм рендеринга просто не смог обработать данные, но также учтите, что это может указывать на проблему с чертежом детали, например, на пробел в элементе, дубликаты объектов, которые нуждаются в «очистке» или подобном.

Параметры визуализации

Для визуализации чертежа нажмите кнопку Render в нижней части LAYOUT или нажмите CTRL + R .

Расположение кнопки Render в LAYOUT

Щелкните правой кнопкой мыши кнопку Render , чтобы открыть дополнительные параметры.

Опции правой кнопки мыши на кнопке Render

Щелкните Render (по умолчанию) , чтобы создать сплошную визуализацию текущего чертежа:

Пример визуализации с выбранным параметром Render (Default).

Выберите Визуализация с объектами…, чтобы создать сплошную визуализацию текущего чертежа, которая также включает все объекты:

Пример рендеринга с выбранным Render with Entities.

Выберите «Визуализация в буфер обмена Windows», чтобы сохранить текущую визуализацию в буфере обмена Windows.

Выберите «Визуализация в файл», чтобы сохранить текущую визуализацию в виде файла .jpg.

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

Окно настройки рендеринга по умолчанию

Пример визуализированного чертежа с пользовательскими цветами

При нажатии кнопки «Поменять местами» цвета переднего плана и фона для отображаемого визуализированного чертежа меняются местами.

Советы:

• Рендеринг гигантских рисунков может быть медленным. Нажмите Esc для отмены.
• Если вам действительно нужен снимок экрана, нажмите ALT + Print Screen , чтобы скопировать снимок экрана любого активного окна в буфер обмена Windows. (Это функция Windows, а не программного обеспечения ProtoMAX, поэтому ее можно использовать практически для любого необходимого снимка экрана.)

Ruby on Rails — визуализация макета

спросил
13 лет, 9 месяцев назад

Изменено
6 лет, 1 месяц назад

Просмотрено
31к раз

Я пытаюсь разделить веб-сайт на две части. Тот, который должен использовать макет приложения, и тот, который должен использовать макет администратора. В моем application.rb я создал следующую функцию:

 def admin_layout
  если current_user.is_able_to('siteadmin')
    визуализировать: макет => 'админ'
  еще
    визуализировать: макет => 'приложение'
  конец
конец
 

А в контроллерах где может быть и то и другое ставлю

 before_filter :admin_layout
 

Это отлично работает для некоторых страниц (где это просто текст), но для других я получаю классическую ошибку:

 У вас есть нулевой объект, хотя вы этого не ожидали!
Вы могли ожидать экземпляр Array.
Произошла ошибка при оценке nil.each
 

Кто-нибудь знает, что мне не хватает? Как мне правильно использовать рендеринг и макет?

• ruby-on-rails
• layout
• render

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

В Rails заложен шаблон для всего этого. Просто передайте символ макет и метод с таким именем будет вызван для определения текущего макета:

 class MyController < ApplicationController
  макет: admin_layout
  частный
  определение admin_layout
    # Проверяем, вошли ли вы в систему, потому что current_user может быть равен нулю.
    если залогинился? и current_user.is_able_to('администратор сайта')
      "админ"
    еще
      "приложение"
    конец
  конец
конец
 

Подробнее см. здесь.

4

возможно, вам нужно сначала проверить, что пользователь вошел в систему?

 по умолчанию admin_layout
  если current_user и current_user.is_able_to 'siteadmin'
    визуализировать: макет => 'админ'
  еще
    визуализировать: макет => 'приложение'
  конец
конец
 

1

Это может быть связано с тем, что current_user равно nil , когда пользователь не вошел в систему.