Как составить ТЗ для верстальщика — Личный опыт на vc.ru

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

2717 просмотров

Подпись. Точнее, можно, но придется переделывать.

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

Адаптивность – корректное отображения сайта на любом устройстве. Это важно, так как большинство сайтов сейчас просматривается с экрана смартфона или планшета. Адаптивность можно проверить через сервисы, например browsershots.org или crossbrowsertesting.com.

Кроссбраузерность – поддержка всех популярных браузеров, подробнее рассмотрим ниже. Кроссбраузерность можно проверить либо вручную, либо через сервисы, например browsershots.org или crossbrowsertesting.com.

Валидность – соответствие html-кода сайта утвержденным критериям. Критерии были разработаны организацией The World Wide Web Consortium (W3C). Валидный код не содержит «костылей», он полностью подчинен логике, и с ним легко работать в дальнейшем. Валидность css проверяется на jigsaw.w3.org, валидность html — на validator.w3.org.

Скорость работы — скорость загрузки html-кода, JS, изображений и прочего кода, который используется в верстке. Лучше всего проверяется сервисами от Google https://pagespeed.web.dev/ и Webpagetest https://webpagetest.org

Вебмастер Победы, у которого вечно лагает фронтенд

Далее подробно расскажу, какие критерии учитываются в работе верстальщика.

Pixel Perfect – соответствие макету

Расположение всех блоков должно полностью соответствовать исходному макету, максимальное допустимое расхождение – 5 px, и то, оно не возбраняется только в текстовых полях. Но если верстальщик вдруг обнаружит небольшое расхождение в размерах блоков или их немного кривое расположение, конечно, он должен их поправить.

Соответствие макету можно проверить с помощью плагина ModularGrid.

Кодировка и DOCTYPE

По умолчанию, кодировка должна быть UTF-8. Это стандарт, наиболее универсальный вид кодировки, который «съедается» всеми браузерами. DOCTYPE – это html-тэг, который сообщает валидатору, какую именно версию html вы используете. В DOCTYPE вы можете указать, каким именно образом браузеру следует отображать ту или иную страницу. Если DOCTYPE не будет, то браузеру придется самому разбираться, как показывать ваш сайт – и не всегда он сделает это корректно. Используя DOCTYPE, вы можете быть уверены, что в браузере корректно отобразятся и элементы со сравнительно новыми тегами, и даже с устаревшими.

Кроссбраузерность

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

  • Internet Explorer версии 10 и выше, платформа — операционные системы семейства Windows;
  • Mozilla Firefox версии 28 и выше, платформа — Windows версии XP и выше и Mac OS X версии 10. 8 и выше;
  • Safari версии 6.1 и выше, платформа — Mac OS X версии 10.8 и выше;
  • Google Chrome версии 21 и выше, платформа — Windows версии XP и выше и Mac OS X версии 10.8 и выше;
  • Opera версии 15 и выше, платформа — Windows версии XP и выше и Mac OS X версии 10.8 и выше;
  • Браузеры мобильных устройств iOS 7 и выше;
  • Браузеры мобильных устройств Android 5 и выше.

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

Соответствие БЭМ

БЭМ – это это современный метод верстки, который расшифровывается как «блок – элемент – модификатор». БЭМ позволяет соблюдать единые правила верстки, которые помогают быстро разрабатывать интерфейсы, гибко их настраивать и легко модифицировать.

По принципу БЭМ вся верстка делится на:

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

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

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

Адаптивность

Список классических разрешений, в которых должен корректно отображаться сайт:

  • 2560×1440
  • 3840 Х 2160
  • 1024×600
  • 1024×768
  • 1152×864
  • 1280×800
  • 1280×1024

  • 1440×900

  • 1920×1080

  • 1680×1050

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

Корректная работа при заполнении текстом

Верстка не должна терять первоначального вида при изменении контента – например, введении текста в формы. Также должны корректно отображаться все отступы, заголовки, списки и другое форматирование текста. Для этого в работе необходимо использовать использовать html5-тэги для разметки: header, footer, aside, nav, section, article и т.д.

Не забываем и правильной структуре заголовков (h2,h3,… и т.д. и TITLE).

Работоспособность при выключенных картинках и JS

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

JavaScript тоже может быть отключен на определенном устройстве или не работать с низким качеством связи. Сайт должен сохранять нормальный вид, пока он грузится на медленном 3G, и java-скрипты ещё не выполнились. Весь важный функционал сайта должен быть доступен без js.

И еще несколько маленьких, но важных пунктов

  • Лого на внутренних страницах должно вести на главную;
  • У каждой страницы должен быть свой уникальный TITLE;
  • Все ссылки должны реагировать на :hover, :active и :focus.
  • Содержимое страницы должно идти в начале кода;
  • Должны быть favicon.ico с включенными в неё 32×32, 48×48 и 64×64 вариациями и apple-touch-icon;
  • В css должны быть зашиты размеры картинок, выводящихся программно;
  • Изображения должны масштабироваться в зависимости от размера окна (max-width:100%; height:auto;).
  • Картинки должны быть максимально сжаты, должны использоваться современные форматы изображений.

Анимация

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

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

С верткой сложной анимации… все сложно. Я нашла верстальщика, который может делать сложную анимацию только после 3 месяцев поисков. И это при условии, что я искала в сегменте от 1500р/час. Тут совет только один, если вы хотите дать верстальщику сложную анимацию, убедитесь, что в его портфолио есть подобные проекты. Часто сложная анимация тормозит, поэтому нужно очень ответственно проверять работу перед приемкой.

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

Как проверить верстку

  • Для оценки скорости работы стоит воспользоваться сервисами от Google https://pagespeed.web.dev/ и Webpagetest https://webpagetest.org. Если видите ошибки или что-то в красной зоне — правим. По Pagespeed хороший результат это от 70-80 баллов из 100 возможных.
  • Адаптивность сайта можно проверить в инструментах разработчика в Google Chrome или ином браузере. Обязательно проверяйте адаптивность на физических устройствах — вид на них может отличаться. Хороший набор для тестирования это: 2-4 Android телефона — помощнее и послабее, 2 iPhone, 1 iPad, Macbook Pro, Windows-ПК с мониторами разрешением 1366*768 (ноутбук), 1920*1080, 2650*1440, 4к.
  • Для оценки соответствия верстки макету можно установить плагин PerfectPixel https://chrome.google.com/webstore/detail/perfectpixel-by-welldonec/dkaagdgjmgdmbnecmcefdhjekcoceebi и там будет наглядно видно, если верстальщик ушел не туда.
  • Особое внимание обращайте на шрифты и размеры шрифтов. Часто верстальщики не уделяют этому должное внимание.
  • Для оценки микроразметки и пригодности верстки для продвижения лучше позвать SEO-специалиста и заказать простую часовую консультацию. На этом этапе важно убедиться в том, что теги расставлены правильно, например, нет служебных элементов в h2-h4, а также что микроразметка проходит тесты от Яндекса http://webmaster.yandex.ru/microtest.xml и Гугла https://search.google.com/structured-data/testing-tool
  • Техчасть: валидность проверяем тут https://validator. w3.org/, CSS тут http://jigsaw.w3.org/css-validator/, JS тут https://codebeautify.org/jsvalidate.

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

Пример хорошего ТЗ по верстке можно посмотреть тут https://docs.google.com/document/d/1bZyzlhBvR1luYWY3voxptjkaxbXUHBXr2OCJvSa8Nyk/edi (на английском), а посовременнее тут https://github.com/thedaviddias/Front-End-Checklist

Важно помнить: даже на сайтах банков, крупных сервисов я часто вижу ошибки верстки в мобильных версиях сайтов (адаптив). Поэтому, к проверке сайта на мобильных устройствах стоит относиться особенно щепетильно.

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

Требования к html-верстке / Хабр

1. Верстка, аутсорсинг и технические задания


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

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

И этот момент игнорируется. Часто это происходит из-за предположения, что трудозатраты на написание детального ТЗ в сумме со стоимостью аутсорсинга не окупаются сэкономленным временем штатного верстальщика. В конце концов, верстка — это ведь не так уж сложно — думает рядовой project менеджер. И, как правило, это действительно прокатывает, *хвала человеческому интеллекту*, профессиональные верстальщики в большинстве своем ограничивают буйство экспериментаторского духа и заранее знают, какие технические решения в верстке могут вызвать у заказчика геморрой не столь адский, чтобы забанить верстальщика, но все же исключающий радость и восхищение прекрасным html-макетом.

Тем не менее, вероятность факапов, как показывает практика, не столь мала, чтобы этим можно было пренебречь.

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

2. О, велика моя скорбь!


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

Табличная верстка и стили, не вынесенные в CSS файл и стандартный дримвиверовский скрипт для подсветки кнопок даже не воспринимаются как недостатки после того ада, который я увидел. Все поля ввода были вставлены внутрь тегов label, засунутых в отдельные формы, причем при попытках как-то привести это в человеческий вид, вся верстка разваливалась. CSS классы имели кириллические названия, причем не осмысленные, а вида «.стиль1,.стиль2». Большинство элементов форм стилизировались каким-то мало известным и до ужаса кривым скриптом на jQuery, некоторые элементы имели одинаковые ID и между ними был JS код, оперирующий как раз этими элементами и получающий их по ID, и верх маразма — это применение в конце документа метода jQuery.сss чтобы задать стили, которые ну совсем ничто не мешало просто прописать в CSS файл. А еще хедер сайта вместе с кучей ссылок (шрифтом Tahoma и без сглаживания) был сделан одной картинкой, на которую наложены элементы MAP и AREA. Не буду больше травмировать вашу психику описанием фейлов в этом замечательном макете, т. к. было их там еще бессчетное количество.

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

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

Вы можете переработать эти рекомендации и дополнить ними свое типовое ТЗ на верстку. Многие вещи из перечисленных вполне очевидны, но вы можете извлечь profit из того, что все они собраны в одном месте. Некоторые пункты (к примеру требования к поддержке браузерами или используемым скриптам) для разных контор специфичны, но я не буду далее писать расплывчатых фраз, чтобы этот списочек можно было легко скопипастить и заточить под свою специфику работы.

3. Требования и рекомендации

1. Кроссбраузерность
Сайт должен нормально работать в IE7+, FF3+, Opera9+, Safari4+, Chrome последней мажорной версии (или в зависимости от условий договора с клиентом и года, в котором вы читаете эту статью).

2. Всегда описывайте цвет фона для body даже если он белый.

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

4. Названия классов и id должны по смыслу соответствовать применению
например, header, menu, footer, news

5. Просьба разделять основные html блоки комментариями. Примерно так:
<!——BEGIN FOOTER —>
<!——END FOOTER —>

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

6. Не пренебрегать возможностью использовать GIF/PNG с 8-битным альфаканалом вместо PNG-24, где это возможно.

7. Все что можно сделать без Javascript, делать без него.

8. Если Javascript кода много — нужно его выносить в отдельный файл. Обработчики событий тоже лучше отделить и объявлять в отдельном файле.

9. Если это еще не оговорено с заказчиком, предварительно оговорить, какие JavaScript библиотеки вы планируете использовать при верстке макета, чтобы потом не оказалось, что при верстке использовался, к примеру, PrototypeJS, а заказчик планирует в обязательном порядке внедрять на сайт jQuery.

10. Для резиновых макетов обязательно должна быть задана минимальная и максимальная ширина.

11. Если в Т.З. не сказано другое, макет обязательно должен помещаться без горизонтальных скроллбаров в развернутое на весь экран окно браузера при горизонтальной составляющей разрешения экрана 1024px, а если позволяет размер макета, то и 800px.

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

13. Для всех элементов, которые могут содержать текст различной длины, который должен быть вписан в одну строку (например, для кнопок или заголовков, если в дизайне не предусмотрено, что они могут занимать больше одной строки), обязательно задавайте CSS свойство white-space:nowrap.

14. CSS файл должен быть разбит с помощью строк с комментариями на блоки по функциональному назначению, например:

/* ___________1. Сброс CSS____________________*/
/* ___________2. Типовые элементы____________*/
/* _______________2.1. Залоговки______________*/
/* _______________2.2. Ссылки________________*/
/* _______________2.3. Элементы форм_________*/
/*___________3. HEADER (Шапка сайта) __________*/
/*___________4. FOOTER (Подвал )_______________*/
/*___________5. SIDEBAR (Справа)_______________*/
Как именно структурировть стили — вопрос немного холиварный, но главное — как-то это делать.

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

  • Добавил новые картинки в папку img,
  • Картинки btnHome.jpg и btnFeedback.jpg уже не нужны, можно удалять
  • Изменил html-код в секции файла anketa.html
  • Добавил в конец файла main.css новые стили (начиная с .form_row и ниже).
16. Оговорить, в какой кодировке должен быть html-макет. CSS и JS файлы должны быть в той же кодировке, что и макет, иначе вероятность долгой и утомительной охоты на баги критически возрастает.

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

18. Не забывайте прописывать cursor:pointer для кнопок, сделанных не с помощью input. Если вы не знаете, будет на эту кнопку повешен обработчик событий с помощью JS или это будет ссылкой, лучше в любом случае использовать тег <a>.

19. Если вы делаете обработку событий при нажатии на ссылки, следите за тем, чтобы обработчики событий возвращали false, или же используйте href=’javascript:void(0)’ вместо популярного href=’#’, чтобы страница не скроллилась вверх.

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

21. Если в макете используются нестандартные шрифты, обязательно оговорите, можно ли элементы с нестандартным шрифтом делать картинками, если нельзя — обсудите, с помощью какой технологии будет реализовано их отображение (sIfr, Cufon, etc.)

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

23. В макетах, где высота страницы зависит от контента (а таких, как правило, большинство), предусматривайте, чтобы футер был прибит к низу браузера при отсутствии/малом количестве контента, если не оговорено обратное.

24. Если макет не проходит 100%-ную html-валидацию, постарайтесь по крайней мере делать так, чтобы использование невалидного кода было оправданно. Не стоит факапить валидность верстки только потому, что «мне так нравится» или «так получается короче»

P.S.

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

Стандарты ADA для доступного дизайна

Стандарты ADA для доступного дизайна — наряду с положениями Раздела II и Раздела III — определяют, что требуется для того, чтобы здание или объект были физически доступными для людей с ограниченными возможностями.

Законы, правила и стандарты

Прочтите этот документ, чтобы понять свои законные права и обязанности в соответствии с ADA.

  • Чтобы ознакомиться с темой для начинающих, просмотрите Featured Topics
  • Для получения более подробной информации по теме см. Руководства и справочные материалы

Стандарты ADA для доступного дизайна («Стандарты ADA») охватывают:

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

Что такое архитектурных барьеров ?

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

Что означает легко достижимо означает?

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

Что означает доступ к программе ?

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

Знание того, когда стандарты ADA 1991 или 2010 применяются к зданиям и сооружениям, важно для определения того, соответствует ли ваше здание или сооружение требованиям ADA. Руководство «Требования ADA: дата вступления в силу и дата соответствия» помогает объяснить, какую версию стандартов ADA следует использовать и когда.

Существует две версии стандартов ADA:

Стандарты ADA 2010 для доступного дизайна

Скачать PDF для стандартов проектирования ADA 2010 г. (4,2 МБ, 279страниц)

Руководство по стандартам ADA 2010 для доступного дизайна

Загрузите PDF-файл для руководства по стандартам проектирования ADA 2010 г. (3,1 МБ, 166 страниц)

Стандарты ADA 1991 года для доступного дизайна

Скачать PDF для стандартов проектирования ADA 1991 г. (5,1 МБ, 92 страницы)

Отсутствует руководство по стандартам 1991 г.

Связанный контент

Руководство

Требования ADA: Доступные бассейны Средства входа и выхода

Руководство

Требования ADA: продажа билетов

Руководство

Часто задаваемые вопросы о ADA и правоохранительных органах

Законы и правила

Законы, правила и стандарты

Руководство

Вопросы и ответы: Требования доступности для существующих плавательных бассейнов в отелях и других общественных местах

Руководство

ADA и городские власти: общие проблемы

требования к оформлению — перевод на испанский язык — Linguee

Опция: разделение на 3 независимых модуля (формирование, загрузка, склеивание) в соответствии с yo u r Требования к компоновке

cermex. eu

cermex.eu

 Opcin: disociacin posible en 3 mdulos distintos Formado, Encajado y encolado segn las obligaciones de importacin

cermex.eu

cermex.eu

Опыт и ассортимент моделей традиционных и роботизированных паллетоукладчиков обеспечивают множество возможных вариантов

[…]

конфигурации, которые могут быть адаптированы к конкретным характеристикам упаковки, к скорости линии

[…] и к р ла н т требования к компоновке .

ocme.it

ocme.it

La experiencia y la amplia gama de modelos de paletizadores tradicionales y robotizados разрешить создание бесчисленного количества

[…]

configuraciones que se adapteran a las exigencias de cada proceso, a las diversas velocidades

[…] де пер ea y al макет de ca da planta.

ocme.it

ocme. it

Поскольку все опросы IBM SPSS Data Collection Scan отформатированы с использованием IBM SPSS Data Collection Paper, вы можете быть уверены, что

[…]

каждый опрос выглядит профессионально, соответствует фирменному стилю

[…] руководящих принципов и соответствует предварительному стандарту ci 9009.9 s e требования к компоновке

spss.com

spss.com

Como las encuestas de IBM SPSS Data Collection Scan в формате IBM SPSS Data Collection Paper, puede estar seguro de que todas las encuestas Tendrn

[…]

apariencia profesional, reflejarn las directrices de su estilo corporativo

[…] у се ай уста rn a sus necesidades de diseo .

spss.com

spss.com

Вы поставляете нам

[…] с вашими изображениями a n d требования к макету , a nd 9010 0 мы поставим [. ..]

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

kessler-web.co.uk

kessler-web.co.uk

Используемые №№

[…] proporciona las im gen es y l os requisitos de d iseo, y va мо s a poner […]

todo junto y crear un documento listo para imprimir para usted.

kessler-web.co.uk

kessler-web.co.uk

Это конструкция гусеницы для самых компактных

[…]

условия, при которых одна дорожка расположена вертикально над другой

[…] трасса на любом расстоянии для удовлетворения t h e компоновочных требований .

pas-us.com

pas-us.com

Esto es un diseo de pista para las condiciones ms compactas en donde una

[…]

pista est situada verticalmente sobre la otra pista en cualquier

[. ..] distancia pa ra cu mpl ir los requisitos de la disposicin .

pas-us.com

pas-us.com

102.2] «Застройщики/владельцы должны также ознакомиться с Руководством по стандартам планирования и инфраструктуры, подготовленным ЦНПООН, и Руководством для застройщиков, подготовленным Управлением по контролю за развитием Центрального планирования

. […]

Отдел правительства Сент-Люсии для руководства

[…] t o f компоновка a n d 9010 0 infrastruc tu r e требования o f a development….

acs-aec.org

acs-aec.org

102.2] «Constructores/Propietarios tambin deberan consultar el Manual de Normas de Planificacin e Infraestructura preparado por UNCHS y el Manual para Constructores preparado por la Autoridad de Control del Desarrollo de la Unidad Central de Planificacin del

[. ..]

Gobierno de Santa Luca пункт

[…] orientacin con r espec to a l os requisitos de diseo e i nfra 901 00 es структура […]

un desarrollo….

acs-aec.org

acs-aec.org

Если вы хотите заменить

[…] стан da r d макет w i th ваш 90 099 o w n компоновка , t он follo wi n g требования m u st встретить

help.sap.com

help.sap.com

Si desea sustituir l a

[…] disposicin e stndar por su pro pi a disposicin, de ben cumplirse l os si 9009 9 gui ent es requisitos

help. sap.com

help .sap.com

Помещения Трибунала не подходят для

[…] рабочие процессы суда и не имеют возможности для обеспечения требований ir e d макет f o r важные функции на a l требования .

icc-cpi.int

icc-cpi.int

102. Los locales del TPIY, не адаптированные к процессу

[…]

trabajo de la Corte y

[…] без галстука пе n capacidad p ar a of recer la distrib uc in necesaria par a atend 9009 9 er a im por tan tes requisitos fun cio нал эс .

icc-cpi.int

icc-cpi.int

Если т ч е компоновка d o es не соответствует yo u r требованиям y o u необходимо изменить [. ..]

исправьте управляющую информацию.

help.sap.com

help.sap.com

 S i la disposicin no satisf ace su s necesidades, деб эр моди фи […]

y corregir la informacin de control.

help.sap.com

help.sap.com

Да, у вас есть возможность адаптировать

[…] дизайн a n d компоновка a c co rding на ваш или w n требования .

strato-faq.co.uk

strato-faq.co.uk

С, тиене

[…] la posibilidad de cambiar a su gu st или el diseo (lay ou t).

strato-faq.es

strato-faq.es

Каждая инсталляция представляет свой

[…] конкретные проблемы развертывания, основанные на физике ic a l компоновка , t er дождь, погодные условия , и секу ri t y требования .

osce.org

osce.org

Cada instalacin Presenta Sus Problemas

[…]

подробные сведения

[…] Базадос на las характеристики f sic as, el ter reno, l as condiciones meteoro l gicas , y lo s requisitos d es egu ридад .

osce.org

osce.org

Вы можете изменить т б макет a n d sc re e n 901 00 макет t o b еще отражать yo u r требования a t a любое время.

help.sap.com

help.sap.com

Модифицированный формат

[…] ficha y el formato de pantalla en cualquier momento para refl ej ar me jor su s necesidades .

help.sap.com

help.sap.com

Поставщик может сортировать список с данными, отображаемыми как

[…] требуется, изменение т ч е компоновка а n d итого поступления a n d потребности v a lu es.

help.sap.com

help.sap.com

Эль-проверитель лучших классификаций списка с визуальными данными,

[…] modific ar la disposicin y s um ar la s entradas y l o s доблесть es de necesidades .

help.sap.com

help.sap.com

Кроме того, кто-то должен убедиться, что соответствующий набор макетов (форма)

[…]

создан для сертификата с использованием SAPscript, если ни один из

[… ] в наличии ти н г макет s e ts соответствует заказу er ‘ s 90 099 требования .

help.sap.com

help.sap.com

Adems, alguien deber asegurarse de que se ha creado un Formulario apropiado para el

[…]

certificado mediante SAPscript, siempre y cuando ninguno de los

[…] формуляры экс is tene s satisfaga l as necesidades de c лжи nte .

help.sap.com

help.sap.com

Если SAP stan da r d макеты d o n ot удовлетворяет ваш отчет ti n g требования , y или можно создать новый стан da r d 9 0100 макет o r c изменить существующий.

help.sap.com

help.sap.com

 S i los макеты est ndar d e SAP no sa ti sface n l as necesidades re lat ivas a la gestin de informes , se p uede crear u n макет e st nd ar nuevo o mo dificar […]

существующий.

help.sap.com

help.sap.com

Т ч e макет i s l чернила до t h 90 100 e требования g r ou ping в профиль выбора.

help.sap.com

help.sap.com

 L a edicin est enl az ada con el ag ru pamie nto de necesidades del pe rfil de 90 100 селекцин.

help.sap.com

help.sap.com

Если вы не хотите использовать

[…] стандарт S A P макет , y или может определить ваш o w n макет a c co 99 o w n требования .

help.sap.com

help.sap.com

Si no desea utilizar

[…] u n layout e st ndar de SAP , puede d efinir un layout pro pi o segn sus prop ia s necesidades .

help.sap.com

help.sap.com

Вместимость

[…] оценка вы можете структурировать t h e компоновка o f a v свободные мощности и капитал ci t y требования a c co в соответствии с вашими потребностями.

help.sap.com

help.sap.com

En la Evaluacin de capacidad se puede

[…] estructu ra r la disposicin de l a capacidad disponible y l a necesidad d e capacidad de acuerdo c on sus необходимо .

help.sap.com

help.sap.com

В дополнение к заказному номеру

[…]

сертификаты, в которых

[…] содержание a n d макет i s t ail om e r требования , т он ре также […]

общие сертификаты

[…]

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

help.sap.com

help.sap.com

Adems de los certificados especficos del

[…]

cliente en los cuales el

[. ..] Контенидо г su disposicin se aj usta a l as necesidades de 9 0100 l cl ient e, […]

tambin certificados genricos

[…]

que son vlidos para utilizados por un amplio nmero de clientes.

help.sap.com

help.sap.com

Стандартная система R/3 содержит образец набора макетов QM_QCERT_01. Вы можете связать этот набор макетов с сертификатом

[…]

профиль или использовать как копию модели

[…] создать o th e r макет s e ts 9010 0 которые соответствуют вашим требованиям если i c требованиям o r t шланг вашего […]

клиентов.

help.sap.com

help.sap.com

Стандартная версия Sistema R/3 содержит формулу счета QM_QCERT_01. Puede enlazar este Formulario con un modelo de certificado

[…]

или использовать по модели

[…] para cr ea rot ros Formularios que cumpla n c on 90 099 sus requisitos oc на лос де с нас клиентов.

help.sap.com

help.sap.com

Производство фармацевтических субстанций и медицинских средств требует обычных инженерных сооружений,

[…]

с одной стороны ставится и довольно непривычно

и […] чрезвычайно привет г ч требования o n s ur fa c e макет 9 0099 a n d чистота, […]

с другой стороны.

metaline.de

metaline.de

Los revestiientos de superficies utilizados en equipos de

[. ..]

фабрикацин фармацевтических или лекарственных средств

[…] deben cu mp lir r igu ros as exigencias en cu ant o 901 00 a calidad y чистый za .

metaline.de

metaline.de

Поэтому важно, чтобы сообщество

[…]

уполномочивает Комиссию на

[…] изменение t h e требования a p pl icable к конструкции ио н , компоновка а н d оборудование […]

скотобоен, а

[…]

сохраняя единый и высокий уровень защиты животных.

eur-lex.europa.eu

eur-lex.europa.eu

Importa, pues, que la Comunidad

[…] autorice a la Comisin a m odifi car l os requisitos ap li cab les a 9 0100 л а конструкция, л а дистрибутив [. .. ]

и Эль-Эквипо-де-лос-Матадерос,

[…]

mantenienendo al mismo tiempo un nivel uniforme y elevado de proteccin de los animales.

eur-lex.europa.eu

eur-lex.europa.eu

Следовательно, настоящим Положением должна быть предусмотрена возможность

[…]

устанавливать отступления, исключающие мобильные

[…] бойни от т ч е требования o n c 901 00 инструкция ио н , компоновка а н д оборудование бойни с.

eur-lex.europa.eu

eur-lex.europa.eu

Большой плавник, el Presente Reglamento debe prever la

[…]

posibilidad de establecer

[…] excepciones re spec to a l os requisitos so br e la con st ruc ci n, l a раздача 9 0099 el e qu ipo de [. ..]

лос матадерос мвилес.

eur-lex.europa.eu

eur-lex.europa.eu

3.12 Приложение II

[…] четко изложены t h e требования ф о р конструктив ио н , компоновка а п г оборудование скотобоен.

eur-lex.europa.eu

eur-lex.europa.eu

3.12 Эль-анексо II

[…] establece cl arame nte lo s requisitos p ara la cons tr uccin , la distribucin y el оборудование […]

де лос матадерос.

eur-lex.europa.eu

eur-lex.europa.eu

Вы можете адаптировать этот

[…] экран для вашего o w n требования b y c reati ng a компоновка v a ри ант.

help.sap.com

help.sap.com

Esta pantalla se puede

[…] Адаптер a подвеска rop ias necesidades med ian te la 9 0099 c реацин d е […]

una v ar iante de estructura de lneas.

help.sap.com

help.sap.com

По отношению к де si g n требования , компоновка a 9010 0 n d ширина шва между плитками

www3.ipc.org .es

www3.ipc.org.es

 R espec до a l as exigencias de l p roy ecto, d e л а модуляцин л анчура […]

Хунта де Колокацин

ipc.org.es

ipc.org.es

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

[. ..]

место, среди прочего

[…] вещи, спец ci f y требования a n d 901 00 стандарты, относящиеся к (a) w e b макет a n d дизайн; (б) […]

редакционный контроль и

[…]

обзор веб-контента и (c) веб-доступности.

unido.org

unido.org

El jefe ejecutivo de cada una de las organizaciones del sistema de las Naciones Unidas debera velar por que se acceptaran polticas y directrices en las

[…]

que, entre otras

[…] cosas, se esp ec ifica run lo s requisitos y № rma s rel at ivos a: a) l a Presentacin y el […]

веб-сайт сайта; б)

[…]

el control editorial y el examen del contenido de la web y c) la accesibilidad en la web.

unido.org

unido.org

Список ППМ

[…] и с по с k / требования l i st оба обеспечивают отдельный du a л компоновка ф о р оценка […]

планового прогона:

[…]

Результат планирования для списка ППМ и ситуация планирования для списка потребностей/запасов.

help.sap.com

help.sap.com

 Танто в списке MRP com o la li sta de necesidades/ sto cks prop 9 0100 или cionan una estructura […]

индивидуальный для оценки процесса

[…]

Планификацин: результат планификаций для списка MRP и положение планификаций для списка необходимых товаров/запасов.

help.sap.com

help.sap.com

Для каждой группы в t h e требования g r ou ping должен быть a макет k e y in t h e макет и с изд .

help.sap.com

help.sap.com

Para cada grupo incluido

[…] en la a gr upaci n de necesidades ti en que 9009 9 h aber una clav e de disposic i n en la disposicin ut iliza da .

help.sap.com

help.sap.com

Требования o f c состав a n 90 099 д раскладка о ф и маги взяты [.. .]

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

Albumprofesional.com

Albumprofesional.com

 L as necesidades de com posi ci n y maquetacin 900 99 de l as imgenes […]

Генераторы профессиональных фотографов — в реальности

[.

No related posts.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *