Сценарии пользовательские: Пользовательские сценарии: что это такое, как и для чего их нужно строить

Содержание

Пользовательские сценарии: что это такое, как и для чего их нужно строить

Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.

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

Прежде чем разработать сценарий, нужно ответить на три вопроса:

1. Кто те люди, что заходят на ваш сайт?

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

2. Почему они заходят к вам?

На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.

3. Какие цели при этом преследуют и как их достигают?

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

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

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

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

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

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

Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.

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

Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».

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

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

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

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

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

Опишите пользовательский опыт по шагам: кто, каким образом и в какой последовательности делает. Это должен быть наиболее детализированный и технически проработанный вариант.

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

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

Описание варианта использования от uxexperience.net

«Общение» пользователя и терминала по приему платежей:

Фрагмент презентации компании «Собака Павлова» о пользовательских сценариях.

Еще сценарий от uxforthemasses.com:

Как создать User Story, сценарии и кейсы | by Anastasia Purdes

Не забывайте о пользователях

Вы знаете как рассказывать User Story. Почему именно так, а не иначе? И уверены ли вы что вы делаете это правильно, а не просто потому что так сложилось.

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

Любой проект это синтез знаний — с помощью обмена знаний, появляется что-то новое и это целиком и полностью результат совместной работы.

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

Довольно проще и “дешевле” взаимодействовать заказчику с командой разработки. Но как в эту картину вписать клиента?

Для этого нужны, как минимум, две вещи:

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

И скорее всего ни для кого это не является новостью. Об этом уже написана ни одна статья. Без пользователей мы анализируем, делаем гипотезы, проектируем интерфейс основываясь на своем опыте. Но это не всегда важно для тех людей, кто будет пользоваться продуктом.

В частности любое решение должно быть обосновано: необходимость>опыт>результат.

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

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

User Story

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

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

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

Чаще всего подобные магазины имеют совершенно разных клиентов, со своими потребностями. Пользовательские истории помогают документировать практические различия этих пользователей. Если у вас персон 3–4, то пользовательских историй может быть 20, или даже больше. Но не пугайтесь. Они короткие, каждая из 1–2 предложений.

Пользовательские сценарии

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

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

Джерри помогал отцу управлять механическим цехом в Западном Массачусетсе с тех пор как он окончил школу десять лет назад. В прошлом году отец Джери ушел на пенсию и оставил свою должность на сына. Их деревянная рубильная машина — купленная до того как Джери стал управляющим, сломалась. Он подозревает, что проблема в гидравлическом рычаге. Джери находит руководство по эксплуатации этой машины и по имени производителя и серийному номеру он хочет найти в интернете запчасть. Он находит несколько сайтов по своему запросу и выбирает первый. На этом сайте он находит описание и ссылку на PDF-руководство. Он читает его, находит схему гидравлического насоса и номер детали сломанного рычага. Но на той странице, которую он читает, нет ни слова о том как эту деталь можно заказать, как ее найти в магазине (просто номер детали). Он кликает на связь с консультантом надеется, что консультант сможет ему помочь.

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

Варианты использования

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

Пример вариантов использования на примере сценария Джерри:

Рубильная машина Джерри ломается

Находит руководство пользователя, выясняет название и номер модели
Вбивает название модели и номер модели в поисковике
Нажимает энтер
Просматривает выдачу результатов, сканирует страницу в поисках совпадения названия и модели
Находит результаты, которые кажутся ему правильными
Вводит имя модели в поле поиска на сайте
Нажимает ентер
Просматривает страницу
Находит список рубильных машин
Нажимает на ссылку
Смотрит описание для машины от производителя
Сканирует страницу в поисках модели
Находит ссылку на руководство пользователя
Нажимает скачать PDF
Смотрит PDF-руководство, сканирует на поиск своей модели
Ищет ту часть, которая, как ему кажется, нуждается в обслужвании
Находит, по номеру, указанному в схеме гидравлического насоса
Пытается скопировать номер, но не получается, так как являяется частью изображения
Записывает номер на бумаге
Возвращается на веб сайт
Ищет по номеру детали в поисковой строке
Нажимает на кнопку Поиск
На странице поиска не находит результатов
Сканирует страницу на поиск контактной информации
Нажимает : “Контакты”
Страница загружается, он заполняет форму
Нажимает : отправить

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

User Flow

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

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

Как это использовать?

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

Перевод статьи

Пишем пользовательские сценариии для анализа дизайна сайта / Хабр

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

Для того что бы сценарий не получался “картонным”, притянутым за уши и заранее заточенным под пожелания, например, дизайнера важно прорабатывать персонажей гораздо более детально чем деление целевой аудитории по половому признаку или финансовому положению, т. к. например персонаж «работающая мать двоих детей» может быть как врачём скорой помощи так и дизайнером-фрилансером. Для создания более объективного и качественного персонажа нужно ответить на следующие вопросы:

Как звать? Дайте персонажу имя это заставляет сильнее верить в его реальность

Кто такой? Опишите основные характеристики: пол; возраст; финансовое положение; семейное положение; место работы

Зачем пришёл? Опишите основную (если надо, то и дополнительную) цель визита сайта

С чего начал? Придумайте с какой страницы (для каждого персонажа страница может быть разная) персонаж попал на сайт и как эта страница может помочь ему решить задачу. Рекомендую придумывать страницу входа как можно более «не типичной» т. к. не факт что зайдут через главную

Какой характер? Придумайте характер персонажу (о характерах подробнее ниже)

В книге «Call to action» посвящённой аналитике проектирования интернет-магазинов предлагается делить характеры персонажей на 4-е категории:

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

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

Гуманистический тип характера — эти люди более склонны к вдумчивому прочтению информации (например раздел «Отзывы»), просмотру элементов дизайна и пр. Они хотят знать ответ на вопрос «Кому ещё этот сайт помог решить такую же проблему?»

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

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

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

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

«Общее описание: Ирина, 35 лет, бухгалтер. По долгу службы проводит много времени за компьютером и довольно неплохо с ним справляется. Склонна методично анализировать поступающую информацию. Как и любая женщина, следит за своей внешностью, однако не любит проводить слишком много времени в магазинах.
Устройство: десктопный компьютер (или планшет).
Цель: найти конкретную модель туфель, узнать наличие в других магазинах.
История: Ирина уже была в одном из магазинов Любимая Обувь, где ей понравились очень милые черные осенние туфли. Но, к сожалению, не оказалось подходящего размера. Дома Ирина решила зайти на сайт и узнать, в каком магазине она может эти туфли приобрести. Набрав в яндексе «любимая обувь» она сразу же попала на главную страницу сайта. К сожалению, Ирина не запомнила ни бренд, ни тем более артикул модели. Поэтому она решила искать через каталог товаров. Нажала «Для женщин», затем «Туфли», после чего увидела, что может отфильтровать обувь по цвету, материалу, сезону и т.д. После выбора нужных фильтров осталось всего 3 пары туфель, одними из которых были те самые черные осенние туфли. Посмотрев фотографии модели с разных ракурсов и убедившись, что это именно та модель, Ирина нажала ссылку «Узнать где купить», увидела список магазинов Любимая Обувь и позвонила в ближайший из них. Менеджер узнала, что пара нужного размера есть в наличии в данном магазине и отложила её для Ирины.
Выводы для сайта: дать ясно понять, что узнать о наличии товара, его цене и т.д., а так же зарезервировать товар можно позвонив в любой розничный магазин Любимой Обуви.»

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

Используемая литература: «Call to action» (авторы.: Брайан Айзенберг, Джефри Айзегнберг. Издат. «Манн, Иванов и Фербер»)

Артефакты: сценарии | UXExperience

Описание

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

В терминологии есть некоторая путаница – под «сценариями» могут иметь в виду разные инструменты, от пользовательских историй и до вариантов использования. Авторы книги Designing Interactive Systems — People, Activities, Contexts, Technologies Benyon, Turner и Turner предложили отличное объяснение того, как разные виды сценариев связаны между собой и для каких целей служат. Они выделяют 4 вида сценариев в зависимости от этапа проекта и целей их создания: пользовательские истории, концептуальные сценарии, конкретные сценарии и варианты использования.

Соотношение между разными видами сценариев:

На каждой последующей стадии особенностям интерфейса уделяется все больше внимания.

Пользовательские истории (user stories, несмотря на полное совпадение по названию, не имеют ничего общего с историями из гибких методологий разработки) описывают идеальный опыт взаимодействия пользователей в свободной форме и включают информацию о среде использования. Пользовательские истории могут быть представлены в самых разных форматах: от дневниковых записей, результатов наблюдения и интервью до фотографий и даже видео (пример http://vimeo.com/40533396).

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

Чаще всего история рассказывается не от лица абстрактного пользователя, и даже не от лица персонажа, а от лица реального человека (либо от лица того, кто ведет наблюдение/проводит интервью). Истории, как правило, содержат очень много деталей, которые сами пользователи редко упоминают, если их спрашивать «в лоб», но всплывают при наблюдении за процессом и/или в свободном рассказе, не привязанном к списку вопросов и не ограниченном ими.

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

Пример:

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

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

Хорошо бы посоветовал кто-нибудь, кто в этом разбирается. А то я кроме «красное/белое» и «сухое/сладкое» даже не знаю, на что ориентироваться.

Ну и хорошо бы магазин поближе к работе был, чтобы в обед можно было заскочить. На худой конец – доставка домой после 19:00 тоже подойдет, но тогда лучше бы оплатить заранее – вдруг налички не будет.

Да, и главное – начальника впечатлить и удивить подарком, может как-то вручить оригинально.

Несколько историй могут быть представлены одним концептуальным сценарием.

Концептуальные сценарии (conceptual scenarios) создаются из пользовательских историй при помощи абстрагирования. Все мелкие детали отбрасываются, похожие истории объединяются в одну. Оставшееся описание практически полностью лишено технических подробностей.

Пример:

Заказ вина

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

Концептуальные сценарии важны для генерации идей и определения требований. На этом этапе полезно собраться с командой (и заказчиком, если он есть) на мозговой штурм и поискать ответ на вопрос «Как улучшить опыт [Название задачи]». Алан Купер рекомендует вообще представить, что интерфейс волшебный и в нем можно реализовать все, что угодно, чтобы выйти за рамки привычного. Ничего, если какие-то из идей будут казаться на первый взгляд нереализуемыми. Технические ограничения окажут свое влияние на следующем этапе. И, в конце концов, «Любая достаточно продвинутая технология неотличима от волшебства» 🙂

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

Конкретные сценарии (concrete scenarios) создаются на основе абстрактных, включают детали реализации и используются для проектирования. Именно в конкретных сценариях появляются технические подробности. Конкретные сценарии пишутся от лица персонажа.

Пример:

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

Заказ вина

Борис Пожарский хочет купить вино в подарок начальнику на этой неделе. Вино должно быть «проверенным» (т.е. его качество должны подтверждать отзывы от других покупателей, награды и рейтинги экспертов). У вина должна быть красивая легенда, чтобы впечатлить начальника при вручении.

Борис выбирает вино с планшета (iPad), параллельно отвлекаясь на другие дела. Ему точно не хочется заполнять слишком много полей. Так что оплатить заказ лучше на месте.

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

Главное, чтобы выбранное вино было в наличии, когда он приедет.

Несколько конкретных сценариев могут быть формализованы и объединены в один вариант использования (use case).

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

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

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

В то же время создавать варианты использования без предварительной проработки сценариев нежелательно по главной причине: применение в них абстрактных ролей, которые не вызывают эмпатии и ничего не сообщают проектировщикам о пользователях и контексте их работы. Из-за этого все возможные взаимодействия (включая альтернативные и исключительные сценарии) рассматриваются как одинаково важные и возможные. А это приводит к тому, что, грубо говоря, вместо того, чтобы вложить 80% усилий в те 20% сценариев, с которыми пользователи будут работать много и часто, внимание проектировщика размазывается по всем возможным сценариям, делая их «средними» по качеству.

Пример:

В целях экономии времени привожу фрагмент варианта использования:

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

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

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

Подводные камни

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

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

В зависимости от исследуемой деятельности анализ и документирование пользовательских историй может занять от 1-2 часов (простые задачи, либо весь набор действий воспроизводится за это время) до 8 часов (рабочий день), реже – дольше. Чтобы можно было говорить о каких-то закономерностях в поведении, количество пользователей для исследования должно быть не меньше 7. Анализ результатов и поиск закономерностей может занимать 8-16 часов. Итого примерные затраты по времени на самый первый этап – порядка 30-70 часов. Все последующие этапы занимают как правило значительно меньше времени. Абстрактные сценарии можно создать за ~8 часов (зависит от доступности команды для мозгового штурма), конкретные – за 8-16 часов (очень зависит от количества персонажей и способов взаимодействия). Все это, конечно же, средние оценки.

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

И напоследок вопрос на засыпку: как вы считаете, к какому типу сценариев можно отнести те самые user stories из гибких методологий?

Полезные ссылки и инструменты

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

Пользовательские сценарии Джейсон Арбон. Как тестируют в Google

Пользовательские сценарии в SEO – статьи про интернет-маркетинг

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

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

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

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

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

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

3. Заинтересованные покупатели. Представители этой последней группы ищут совершенно определённую информацию. Если мы говорим о покупателях, то они уже знают не только производителя, но и основные характеристики товара, которые тоже попадают в поисковой запрос. Эта группа использует поисковые фразы длиной от 4 до 6 слов, которые максимально точно описывают искомое, чтобы заведомо отсеять нерелевантные страницы.

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

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

При описании персоны необходимо учесть следующие характеристики:

пол и возраст;

образование и социальное положение;

семейное положение и наличие детей;

место работы, должность, обязанности;

увлечения.

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

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

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

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

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

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

Остаётся добавить, что пользовательские сценарии — не одноразовая работа. Их необходимо периодически обновлять и отшлифовывать. Самая очевидная тому причина — постоянные изменения в SERP популярных поисковиков, которые оказывают заметное влияние на поисковое поведение пользователей.

При подготовке статьи использовался материал публикации Стоуни Дегейтера
«Optimizing Your Online PR Strategy for Search & Social, Part 3: Background Research».

Поиск новых ниш

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

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

1. Выберите то, что вам по-настоящему интересно

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

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

2. Решайте проблемы

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

3. Как много вы знаете?

Посмотрите ещё раз на полученный список и задайтесь вопросом, насколько полны ваши знания по каждой из тем. Если ваши потенциальные клиенты знают об этом бизнесе заметно больше вас, стартап может не «выстрелить».

4. Какой тип операций вам больше всего подходит?

Пять наиболее распространённых способов монетизации сайта — размещение рекламы, создание аффилированной компании, продажа услуг, продажа информации и продажа продуктов. Разумеется, их можно комбинировать. У каждого варианта есть свои плюсы и минусы в зависимости от обстоятельств. Есть ли у вас склад? Нравится ли вам прямой контакт с клиентами? Нужен ли вам полный контроль, или же вам проще отдать исполнение на аутсорс? Есть в избранной нише подходящие поставщики?

5. Есть ли у избранной ниши потенциал для онлайнового развития?

Может казаться и без того очевидным, что не всё можно продавать через Интернет. Так что у незанятости некоторых ниш в Интернете можно быть вполне простое и логичное объяснение. Именно поэтому необходимо предварительно изучить рынок. Вы можете попробовать организовать PPC-кампанию для сайта, точкой конверсии на котором будет подписка по электронной почте. Это поможет вам приблизительно измерить интерес рынка без особых затрат. От бесперспективных идей лучше сразу отказаться.

6. Кто ваши покупатели?

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

7. Есть ли у посетителей сайта коммерческий интерес?

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

8. Оцените вероятный объём рынка

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

Если же ниша до сих пор никем не замечена, предложений в AdWords будет крайне мало, конкуренция между предложениями будет низкой, и сразу оценить трафик будет невозможно. Здесь снова можно прибегнуть к пробной кампании через контекстную рекламу. Как только у вас появится оценка трафика, вы сможете взять за основу типичную рыночную конверсию в 3-8% и сделать приблизительные расчёты. Разумеется, конверсия может оказаться весомее, если спрос будет существенно выше предложения.

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

9. Тенденции рынка

Что происходит с рынком, на который вы рассчитываете вступить? Он на подъёме или падает? Заработать деньги можно и в том, и в другом случае, но большинство всё же предпочитает входить на быстро растущий новый рынок, или, как минимум, на рынок со стабильным спросом. Для оценки тенденций можно воспользоваться Google Trends, Trendistic и прочими схожими инструментами.

10. Чем занимаются ваши конкуренты?

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

Выясните, кто даёт объявления в контекстной рекламе и кто занимается поисковым продвижением в вашей нише. Насколько агрессивно они продвигаются? Какой подход они избрали? Можете ли вы сделать лучшее предложение? Можете ли вы немного изменить нишу так, чтобы не конкурировать напрямую? Потенциальные клиенты обязательно будут сравнивать предложения, и ваше должно оказаться конкурентоспособным. Для анализа действий конкурентов можно воспользоваться сервисами Spy Fu, KeywordSpy и SEMRush.

В статье использованы материалы сайта SEO Book.

Сценарии и истории пользователей в UX-дизайне

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

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

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

Что такое история пользователя и сценарий поведения?
Чем они отличаются друг от друга?
Какова роль пользовательских историй и сценариев в UX-дизайне?

ЧТО ТАКОЕ ИСТОРИЯ ПОЛЬЗОВАТЕЛЯ?

Есть такая американская пословица: «Понадобится тысяча голосов, чтобы рассказать одну историю». То есть, для того, чтобы понять масштаб какого-либо события, понадобится взглянуть на него со многих точек зрения. Точно также действуют современные дизайнеры – они стараются услышать отзывы многих (а порой очень и очень многих) пользователей для того, чтобы понять их основные потребности и превратить их в пользовательские истории.

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

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

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

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

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

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

ЧТО ТАКОЕ СЦЕНАРИЙ ПОВЕДЕНИЯ ПОЛЬЗОВАТЕЛЯ?

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

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

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

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

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

КАК ПОВЫСИТЬ ЭФФЕКТИВНОСТЬ ИСТОРИЙ И СЦЕНАРИЕВ В UX?

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

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

ВМЕСТО ЗАКЛЮЧЕНИЯ

Сегодня дизайнерам необходимо знать как можно больше о пользовательском опыте. Чем больше информации, тем выше шансы, что удастся создать действительно значимый и полезный продукт. Пользовательские истории и сценарии являются очень мощными инструментами исследования UX, которые помогают команде разработчиков лучше понять, почему они добавляют в дизайн ту или иную функцию. Хорошо продуманная история – это (с точки зрения UX) «скелет» любого дизайн-проекта, а сценарий – это его «мышцы». Вместе они позволяют создавать полезные и удобные продукты, которые успешно решают проблемы пользователей.

Источник: http://designmodo.com/user-stories-ux/

Получите комбинированные лекарства, онлайн-пополнение запасов, частные индивидуальные консультации по рецепту — лекарства для домашних животных, ветеринарные препараты | Изготовленные на заказ рецепты Lancaster

Фармацевты Custom Prescriptions of Lancaster, LLC осознают важность соблюдения принятых на национальном уровне стандартов. Все рецепты составлены в соответствии с установленными политиками, процедурами и отраслевыми стандартами, включая Фармацевтический совет штата Огайо, FDA, OSHA, USP и недавно разработанные стандарты аккредитации PCAB.

Мы соблюдаем главу 795 USP (Фармацевтическое приготовление — нестерильные препараты) и главу 797 USP (Фармацевтическое приготовление — стерильные препараты), которые устанавливают практические стандарты и описывают ответственность производителя смеси, выбор и соответствующие источники ингредиентов, контроль качества и соображения, касающиеся стабильность составных препаратов.

Также действуют две дополнительные информационные главы Фармакопеи США, в том числе Глава 1075 Фармакопеи США — Надлежащая практика приготовления смесей и Глава 1160 Фармакопеи США — Фармацевтические расчеты в рецептурных рецептурных смесях.

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

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

Finest Ingredients — Мы используем только высший сорт порошковых лекарственных препаратов и химикатов для рецептов, составленных по индивидуальному заказу. Сертификаты анализа доступны для этих фармацевтических смесей химикатов.

Для разработки рецепта, составленного по индивидуальному заказу, который будет отвечать конкретным потребностям пациента, Custom Prescritions of Lancaster будет:

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

Сборник кастомных скриптов | Пользовательские скрипты Sentinel-Hub

Репозиторий пользовательских сценариев

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

Скрипты организованы датчиками, поддерживаемыми на Sentinel Hub:

Вам предлагается опубликовать свои собственные скрипты — см. Как это сделать.

Соответствующая литература

Страж-1

Изображение Sentinel-1 обеспечивается двумя спутниками на полярной орбите, которые работают днем и ночью, выполняя радиолокационные изображения C-диапазона с синтезированной апертурой, что позволяет им получать изображения независимо от погоды.Основные области применения — мониторинг морского льда, разливов нефти, морских ветров, волн и течений, изменений в землепользовании, деформации земли среди прочего, а также для реагирования на чрезвычайные ситуации, такие как наводнения и землетрясения. Идентичные спутники вращаются вокруг Земли на 180 ° друг от друга и на высоте почти 700 км, предлагая глобальное время повторного посещения 6-12 дней в зависимости от области (см. Сценарий наблюдения). Радиолокатор Sentinel-1 может работать в четырех режимах. Пространственное разрешение зависит от режима: прибл. 5 м x 20 м для режима IW и прибл.20 м х 40 м для режима РЭБ. Подробнее см. Услуги Коперника.

Алгоритмы растительности в сельском хозяйстве

Алгоритмы управления и предотвращения стихийных бедствий

Алгоритм городского планирования

Алгоритмы среды морских и других водных объектов

Другие доступные скрипты

Прочие разновременные сценарии

Страж-2

Предназначенный для предоставления данных для служб Copernicus, Sentinel-2 оснащен многоспектральным формирователем изображений с полосой обзора 290 км.Тепловизор обеспечивает универсальный набор из 13 спектральных диапазонов, охватывающих от видимого и ближнего инфракрасного до коротковолнового инфракрасного, включая четыре спектральных диапазона на 10 м, шесть диапазонов на 20 м и три диапазона с пространственным разрешением 60 м. Поскольку индексы в основном связаны с объединением различных коэффициентов отражения полос, здесь для справки приводится таблица из 13 полос (подробности см. Здесь). Названия имеющихся в вашем распоряжении диапазонов Sentinel-2: B01 , B02 , B03 , B04 , B05 , B06 , B07 , B08 , B8A , B09. , B10 , B11 и B12 .

Индексы дистанционного зондирования

Алгоритмы обнаружения облаков

Алгоритмы снега и ледников

Алгоритмы управления и предотвращения стихийных бедствий

Алгоритмы классификации землепользования / земельного покрова

Алгоритмы растительности

Сельское и лесное хозяйство. Алгоритмы

Алгоритмы среды морских и других водных объектов

Алгоритмы городского планирования

Прочие разновременные сценарии

Другие доступные скрипты и индексы

Скрипты, включая методы машинного обучения (eo-learn)

Страж-3

Sentinel-3 — это низкоорбитальный спутник среднего размера, совместимый с небольшими пусковыми установками, включая VEGA и ROCKOT. Основная цель миссии — измерение топографии морской поверхности, температуры поверхности моря и суши, а также цвета поверхности океана и суши с высокой точностью и надежностью для поддержки систем прогнозирования состояния океана, мониторинга окружающей среды и мониторинга климата. Инструмент Ocean and Land Color Instrument (OLCI) обеспечивает набор из 21 полосы в диапазоне от видимого до ближнего инфракрасного света (400 нм <λ <1 020 нм). Sentinel-3 обеспечивает изображение с пространственным разрешением 300 м. Прибор Sentinel-3 OLCI обеспечивает непрерывность работы ENVISAT MERIS.

Sentinel-3 OLCI

Улучшенные скрипты с истинным цветом

Индексы дистанционного зондирования

VMI3 — Мониторинг растительности и земель с маской облаков
OTCI — Индекс наземного хлорофилла
Ulyssys Water Quality Viewer — хлорофилл и взвешенные отложения для визуализации качества воды
NDBI — нормализованный индекс голого льда

Sentinel-3 SLSTR

Страж-5П

Sentinel-5P обеспечивает атмосферные измерения, касающиеся качества воздуха, воздействия климата, озона и УФ-излучения с высоким пространственно-временным разрешением. Его данные используются для мониторинга концентраций оксида углерода (CO), диоксида азота (NO2) и озона (O3) в воздухе, а также для мониторинга УФ-аэрозольного индекса (AER_AI) и различных геофизических параметров облаков (CLOUD). EO Browser обслуживает геофизические продукты 2-го уровня. Прибор мониторинга атмосферы (ТРОПОМИ) на борту спутника работает в диапазоне от ультрафиолетового до коротковолнового инфракрасного диапазона с 7 различными спектральными диапазонами: УФ-1 (270-300 нм), УФ-2 (300-370 нм), VIS (370-500 нм). , NIR-1 (685-710 нм), NIR-2 (755-773 нм), SWIR-1 (1590-1675 нм) и SWIR-3 (2305-2385 нм).Его пространственное разрешение составляет менее 8 км для длин волн выше 300 нм и ниже 50 км для длин волн ниже 300 нм. Он покрывает почти весь земной шар (95% покрытия для широт в интервале [-7 °, 7 °]).

Доступные скрипты

Ландсат 8

Программа Landsat — самая продолжительная программа получения спутниковых изображений Земли, начатая с 1972 года. Последний, Landsat 8, был запущен 11 февраля 2013 года. Данные Landsat-8 имеют 11 спектральных диапазонов с пространственным разрешением от 15 до 60 метров.Названия имеющихся в вашем распоряжении диапазонов Landsat-8: B01 , B02 , B03 , B04 , B05 , B06 , B07 , B08 , B09 , B10. и B11 .

Индексы дистанционного зондирования

Другие доступные скрипты

Landsat 5 и 7

Орбиты

Landsat 7 и Landsat 5, снятые с эксплуатации, являются гелиосинхронными, с околополярными орбитами, летают на высоте 705 км (438 миль).Landsat 5 давно пережил свой первоначальный трехлетний проектный срок. Разработанный НАСА и запущенный в 1984 году, спутник Landsat 5 облетел планету более 150 000 раз, передав более 2,5 миллионов изображений земной поверхности по всему миру. Спутник Landsat 7 все еще вращается вокруг Земли по солнечно-синхронной околополярной орбите на высоте 705 км (438 миль). Спутники являются мультиспектральными, обеспечивая видимый, ближний инфракрасный, средний инфракрасный и тепловой диапазоны.

Подробнее о Landsat 5, включая доступные диапазоны, читайте здесь, а о Landsat 7 читайте здесь..

MODIS

Спектрорадиометр изображения среднего разрешения (MODIS) MCD43A4 версии 6 на Sentinel Hub размещен на Amazon Web Services (AWS). Набор данных обновляется ежедневно и предоставляет данные 500-метровой функции двунаправленного распределения отражательной способности (NBAR) для «наземных» диапазонов MODIS 1-7: B01 , B02 , B03 , B04 , B05 , B06 и B07 .

Индексы дистанционного зондирования

DEM

DEM (цифровая модель рельефа) — это трехмерное представление поверхности местности, созданное на основе данных о высоте местности.Его можно использовать для анализа местности и ортотрансформирования, что помогает повысить точность спутниковых снимков. С помощью DEM вы можете измерять и анализировать интересующую вас область или интегрировать данные в 3D-приложение в качестве источника данных о местности. Sentinel Hub использует DEM MapZen, доступную через Amazon Web Services (AWS) в США. Этот набор данных основан на SRTM30 (разрешение 30 м), но в некоторых местах улучшен локальными наборами данных. Он статичен и не зависит от даты (значения обновляются, поскольку MapZen улучшает набор данных).Прочтите сообщение в блоге о том, как изучить набор данных DEM, и ознакомьтесь с нашей документацией по API.

PlanetScope (коммерческая)

Спутниковая группировка

PlanetScope состоит из более чем 130 небольших спутников, называемых Doves. Спутники запускаются группами, что постоянно улучшает характеристики миссии, такие как время пролета, пространственное и спектральное разрешение. Данные PlanetScope дополняют Sentinel-2 лучшим пространственным разрешением (3 м) и почти глобальным ежедневным покрытием.Это отличный источник для мониторинга растительности. Для получения дополнительной информации о PlanetScope посетите нашу страницу документации.

Спектральные полосы данных PlanetScope следующие:

B1 — Синий, разрешение 3м

B2 — зеленый, разрешение 3м

B3 — Красный, разрешение 3м

B4 — ближний инфракрасный, разрешение 3 м

Airbus Pleiades (коммерческий)

Созвездие Плеяд состоит из двух спутников-близнецов, вращающихся вокруг Земли на 180 ° друг от друга. Спутники обеспечивают невероятное глобальное спектральное разрешение 0,5 м. Спутники Pleiades делят орбиту со спутниками SPOT, что позволяет объединить данные из обоих источников.
Данные Pléiades с высоким пространственным разрешением подходят для широкого спектра приложений дистанционного зондирования, таких как мониторинг растительности, точное картографирование, а также управление рисками и стихийными бедствиями. Чтобы узнать больше о Плеядах, посетите нашу страницу документации.

Спектральные полосы данных Плеяд следующие:

B0 — синий (430-550 нм, разрешение 2 м)

B1 — зеленый (490-610 нм, разрешение 2 м)

B2 — Красный (600-720 нм), разрешение 2м

B3 — ближний инфракрасный (750-950 нм), разрешение 2 м

PAN — Панхроматический (480-830 нм), разрешение 0.5м

Полосы RGB

Pleiades имеют пространственное разрешение 2 метра. Чтобы воспользоваться преимуществами полосы PAN 0,5 м, требуется процесс переточки.

Airbus SPOT (коммерческий)

SPOT 6/7 — это группировка спутников, обеспечивающая оптические изображения очень высокого разрешения и принадлежащая Airbus. Он состоит из двух спутников-близнецов, вращающихся вокруг Земли на 180 °. Спутники доставляют оптические изображения длиной 1,5 м и позволяют ежедневно посещать любую точку земного шара.Данные SPOT 6/7 с высоким пространственным разрешением подходят для ряда приложений дистанционного зондирования, таких как мониторинг растительности, точное картирование, управление рисками и стихийными бедствиями. Чтобы узнать больше о SPOT, посетите нашу страницу документации.

Спектральные полосы данных SPOT следующие:

B0 — Синий (454-519 нм, разрешение 6м)

B1 — зеленый (527-587 нм, разрешение 6 м)

B2 — Красный (624-694 нм), разрешение 6м

B3 — ближний инфракрасный (756-880 нм), разрешение 6 м

PAN — Панхроматический (455-744 нм), разрешение 1. 5м

Полосы RGB

SPOT имеют пространственное разрешение 6 метров. Чтобы использовать полосу PAN длиной 1,5 м, требуется процесс переточки.

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

Слияние данных

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

Доступные скрипты

Услуги Коперника

CORINE Земельный покров

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

Это произведение находится под международной лицензией Creative Commons Attribution-ShareAlike 4.0.

пользовательских скриптов

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

На главную> Настройка> Настройка формы> Пользовательский сценарий

1.

Как создать собственный сценарий

Создайте собственный сценарий (для этого у вас должна быть роль администратора системы):

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

2. Примечания

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

Пользовательские сценарии клиента

находятся на JavaScript, а пользовательские сценарии сервера — на Python.
Для тестирования обязательно перейдите в Инструменты> Очистить кеш и обновите после обновления пользовательского сценария.

2. Примеры пользовательских сценариев

Вот несколько примеров пользовательских скриптов:

Получить значения от мастера
Дата подтверждения
Создание кода товара на основе пользовательской логики
Сделать только для чтения после сохранения
Ограничить права отмены
Ограничение цели входа в акции
Ограничить пользователя на основе дочерней записи
Идентификатор счета-фактуры на основе идентификатора заказа на продажу
Обновить поле даты на основе значения в другом поле даты
Пользовательская кнопка
Параметры фильтра в поле выбора
Получить значение в поле дочерней таблицы
Скрыть кнопки в представлении формы
Переименовать кнопки в представлении формы
Блокировать расписания на основе даты

3.

Видео

Далее: Статьи

Определено

скриптов | Поддержка Tiger Technologies

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

На этой странице:

О пользовательских скриптах

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

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

Сценарии, выполняемые на сервере, отличаются от апплетов Java или программ JavaScript. Хотя все три позволяют использовать языки программирования для создания интерактивных веб-страниц, описанные здесь сценарии представляют собой программы, которые работают на наших серверах, в отличие от апплетов Java и программ JavaScript, которые выполняются на компьютере пользователя, посещающего вашу веб-страницу.Это делает сценарии более надежными, чем апплеты Java или программы JavaScript, поскольку вам не нужно беспокоиться о том, какой компьютер или веб-браузер может использовать ваш посетитель.

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

Откуда берутся пользовательские скрипты?

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

Следовательно, использование пользовательских сценариев включает в себя либо получение и установку сценариев, написанных кем-то другим, либо самостоятельное написание сценариев на языке компьютерного программирования (например, «Perl», «PHP» или «C»).

Использование сценариев, написанных другими пользователями

Буквально тысячи скриптов доступны в Интернете от других людей.Многие из них совершенно бесплатны.

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

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

Создание собственных сценариев

Другой вариант — создать свой собственный сценарий. Если вы планируете это сделать, вам нужно будет узнать (или научиться) что-то о компьютерном программировании. То, что вам нужно знать, зависит от сложности сценария, который вы пытаетесь написать: простой сценарий, который отображает случайную цитату на веб-странице, — это то, что многие люди могли бы понять из базового руководства и пары часов возиться, особенно если они написали какой-либо JavaScript или использовали текстовый редактор для создания HTML-страниц с нуля.С другой стороны, создание полноценной корзины для покупок и системы заказов, которая подключается к базе данных, может занять у опытного программиста несколько недель или месяцев.

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

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

Наконец, вы должны прочитать наш раздел о том, что делать дальше, если вы все еще боретесь.

пользовательских скриптов | Как добавить и выполнить пользовательские сценарии для администрирования рабочего стола Windows

Пользовательские сценарии, предоставляемые Desktop Central, позволяют выполнять до 40 предопределенных конфигураций, таких как конфигурация принтера, сопоставление дисков, управление службами, настройка политик безопасности и т. Д., который позаботится об общей повседневной деятельности администраторов по администрированию настольных компьютеров. Но существуют определенные конфигурации, специфичные для организации, которые необходимо выполнить на рабочих столах Windows, для которых могут оказаться полезными пользовательские сценарии. Это обеспечивает большую гибкость для добавления дополнительных функций в соответствии с требованиями организации.

Как добавлять и выполнять собственные сценарии

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

Пользовательские сценарии — Поддерживаемые языки

Пользовательские сценарии могут быть написаны с использованием любого из популярных языков сценариев, таких как VB Script, JScript, Perl, Python и т. Д. Поддерживаемые форматы: пакетный файл (.bat или .cmd) и любой другой язык, поддерживаемый Windows Script Host (WSH), например VB Script, JScript, Perl, REXX и Python для ОС Windows или sh, bash, ksh, csh. , tcsh и py для ОС Linux.

Как добавлять собственные сценарии в шаблоны сценариев

Desktop Central создал репозиторий из 180+ скриптов на основе взаимодействия с клиентами и отзывов службы поддержки. Вы можете добавлять собственные сценарии в виде шаблонов, в которых вам просто нужно будет передавать аргументы для сценариев. Конфигурации, созданные с помощью этих шаблонов сценариев, будут готовы к развертыванию после передачи необходимых аргументов. Список шаблонов сценариев можно просмотреть здесь: Веб-консоль Desktop Central> Конфигурации> Настройки> Репозиторий сценариев> Шаблоны .Вы можете выбрать шаблон в соответствии с вашими требованиями и щелкнуть по нему, чтобы добавить сценарий в локальный репозиторий сценариев. Эти шаблоны периодически обновляются. Для использования настраиваемого сценария сценарий должен быть доступен в репозитории сценариев. В дополнение к этому, если включить возможность совместного использования настраиваемого сценария в центре рабочего стола, сценарий будет сохранен, обработан, протестирован и предоставлен сообществу с помощью шаблонов сценариев. Вот полный список доступных шаблонов скриптов. Вы можете развернуть эти сценарии в форме конфигураций для пользователей / компьютеров.

Пользовательские скрипты — Octopus Deploy

Последнее обновление 2021-03-02T13: 37: 31.2423227 + 00: 00

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

Поддерживаемые типы скриптов

Octopus поддерживает следующие среды сценариев:

Скрипты PowerShell (.ps1)
Сценарии Bash (.sh)
Скрипты Python (.py)
Сценарии C # (.csx) с использованием ScriptCS
Сценарии F # (. fsx)

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

Что можно делать с пользовательскими скриптами

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

В контексте Octopus ваши пользовательские скрипты получают следующие дополнительные преимущества:

Как использовать собственные скрипты

Octopus поддерживает следующие способы использования пользовательских скриптов:

Где хранить ваши скрипты

Octopus может выполнять сценарии из разных мест, и все они имеют разные преимущества:

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

Как ваши скрипты выполняются Octopus

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

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

Рабочие каталоги

Когда Calamari выполняет ваши сценарии, он делает это в контексте рабочего каталога. Рабочий каталог — это временное место, которое хранится в домашней папке, которую вы настраиваете при настройке цели развертывания или работника.

Если вы выполняете сценарий, содержащийся в пакете, содержимое пакета будет распаковано и скопировано в этот каталог, но рабочий каталог — это каталог, содержащий сценарий внутри него.После завершения выполнения сценария рабочий каталог будет очищен. Узнайте о копировании содержимого рабочего каталога.

Безопасность и разрешения

Когда скрипты выполняются, это происходит в контексте учетной записи, под которой запущен агент Tentacle или сеанс SSH. Узнайте, как запустить Tentacle как другую учетную запись пользователя.

В Windows агент Tentacle по умолчанию работает как Local System , который имеет обширные локальные привилегии, но обычно не может получить доступ к общим файловым ресурсам, удаленным базам данных SQL или другим внешним ресурсам.Если вам нужны более широкие разрешения, вам нужно настроить Tentacle для работы под индивидуальной учетной записью пользователя.

Целостность скрипта

Octopus не поддерживает целостность скриптов. Хотя это может показаться тревожным, для такого подхода есть очень веские причины.

Например, когда Calamari вызывает PowerShell.exe, он использует для сеанса политику выполнения Unrestricted . Вы можете увидеть, как выполняются сценарии PowerShell более подробно, просмотрев проект Calamari с открытым исходным кодом.

Узнайте о целостности скрипта.

Разработка и тестирование скриптов

Мы рекомендуем следующие подходы для разработки и тестирования ваших скриптов в порядке предпочтения:

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

Отладка скриптов

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

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

Скрипты, блокирующие развертывание

Иногда сценарий запускает службу или приложение, которые работают непрерывно. В этом случае сценарий не завершится до завершения работы приложения. Когда сценарий запускается в процессе Octopus, задача Octopus будет продолжать выполняться, пока сценарий не завершится. В большинстве случаев это нежелательно. Чтобы избежать такого поведения, службу или приложение следует запускать в отдельном процессе или сеансе, позволяя остальной части процесса продолжать выполнение.Например:

  экран -d -m -S "MyService" MyService

Сценарии, перезапускающие целевую операционную систему

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

В разделе

В этом разделе подробно рассматриваются следующие темы:

Была ли эта страница полезной?

🙂 Да, спасибо!

😞 Не совсем

Сожалеем, что эта страница вам не помогла!
Мы проверяем ваши ответы каждый месяц, чтобы найти способы улучшить эти документы.Как мы можем это улучшить?

Отправить

Спасибо, что нашли время оставить отзыв!

Нужна поддержка? Мы здесь, чтобы помочь.

Пользовательские сценарии — Документация NetBox

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

Автоматически заполнять новые устройства и кабели при подготовке к развертыванию новой площадки
Создать диапазон новых зарезервированных префиксов или IP-адресов
Получить данные из внешнего источника и импортировать их в NetBox

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

Написание собственных сценариев

Все настраиваемые сценарии должны быть унаследованы от базового класса extras.scripts.Script . Этот класс предоставляет функциональные возможности, необходимые для создания форм и регистрации активности.

  из extras.scripts import Script

класс MyScript (сценарий):
    ...

Сценарии

состоят из двух основных компонентов: набора переменных и метода run () . Переменные позволяют вашему сценарию принимать вводимые пользователем данные через пользовательский интерфейс NetBox, но они не являются обязательными: если ваш сценарий не требует ввода каких-либо данных пользователем, нет необходимости определять какие-либо переменные.

Метод run () — это место, где живет логика выполнения вашего скрипта. (Обратите внимание, что ваш сценарий может иметь столько методов, сколько необходимо: это просто точка вызова NetBox.)

  класс MyScript (сценарий):
    var1 = StringVar (...)
    var2 = IntegerVar (...)
    var3 = ObjectVar (...)

    def run (self, data, commit):
        ...

Метод run () должен принимать два аргумента:

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

Примечание

Аргумент фиксации был введен в NetBox v2. 7.8. Обратная совместимость поддерживается для сценариев, которые принимают только аргумент data , но начиная с v2.10 NetBox потребует, чтобы метод run () каждого сценария принимал оба аргумента. (Любой аргумент в методе все еще можно игнорировать.)

Определение переменных сценария необязательно: вы можете создать сценарий только с методом run () , если пользовательский ввод не требуется.

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

Атрибуты модуля

наименование

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

Атрибуты скрипта

Атрибуты скрипта определены в классе с именем Meta внутри скрипта. Это необязательно, но рекомендуется.

наименование

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

описание

Понятное для человека описание того, что делает ваш скрипт.

commit_default

Флажок для фиксации изменений базы данных при выполнении сценария установлен по умолчанию.Установите для commit_default значение False в классе Meta скрипта, чтобы по умолчанию этот параметр не отмечен.

  commit_default = Ложь

Доступ к данным запроса

Подробная информация о текущем HTTP-запросе (выполняемом для выполнения сценария) доступна как атрибут экземпляра self.request . Это может быть использовано, например, для определения пользователя, выполняющего сценарий, и IP-адреса клиента:

  имя пользователя = self.request.user.username
ip_address = self.request. META.get ('HTTP_X_FORWARDED_FOR') или \
    self.request.META.get ('REMOTE_ADDR')
self.log_info (f "Запуск от имени пользователя {username} (IP: {ip_address}) ...")

Полный список доступных параметров запроса см. В документации Django.

Чтение данных из файлов

Класс Script предоставляет два удобных метода чтения данных из файлов:

Эти два метода загружают данные в формате YAML или JSON, соответственно, из файлов по локальному пути (т.е.е. SCRIPTS_ROOT ).

Лесозаготовка

Объект Script предоставляет набор удобных функций для записи сообщений разной степени важности:

log_debug
log_success
log_info
log_warning
log_failure

Сообщения журнала возвращаются пользователю после выполнения сценария. Рендеринг Markdown поддерживается для сообщений журнала.

Ссылка переменной

Параметры по умолчанию

Все пользовательские переменные скрипта поддерживают следующие параметры по умолчанию:

default — Значение поля по умолчанию
описание — Краткое и понятное описание поля
label — Имя поля, которое будет отображаться в визуализированной форме
обязательно — Указывает, является ли поле обязательным (по умолчанию все поля обязательны)
widget — Класс используемого виджета формы (см. Документацию Django)

StringVar

Хранит строку символов (т.е.е. текст). Варианты включают:

min_length — Минимальное количество символов
max_length — Максимальное количество символов
regex — Регулярное выражение, которому предоставленное значение должно соответствовать

Обратите внимание, что min_length и max_length могут быть установлены на одно и то же число для создания поля фиксированной длины.

TextVar

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

IntegerVar

Хранит числовое целое число. Варианты включают:

min_value — Минимальное значение
max_value — Максимальное значение

BooleanVar

Флаг «истина / ложь». В этом поле нет параметров, кроме значений по умолчанию, перечисленных выше.

ChoiceVar

Набор вариантов, из которых пользователь может выбрать один.

вариантов выбора — Список из (значение, метка) кортежей, представляющих доступные варианты.Например:

  ВЫБОР = (
    ('п', 'север'),
    ('s', 'Юг'),
    ('е', 'Восток'),
    ('ш', 'Запад')
)

direction = ChoiceVar (choices = ВЫБОР)

В приведенном выше примере при выборе варианта с меткой «Север» будет отправлено значение n .

MultiChoiceVar

Аналогично ChoiceVar , но позволяет выбрать несколько вариантов.

ObjectVar

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

model — Модель класса
display_field — Имя поля объекта REST API для отображения в списке выбора (по умолчанию: 'name' )
query_params — Словарь параметров запроса для использования при извлечении доступных опций (необязательно)
null_option — Метка, представляющая «нулевой» или пустой выбор (необязательно)

Аргумент display_field полезен при ссылке на модель, у которой нет поля name . Например, при отображении списка типов устройств вы, скорее всего, будете использовать поле model :

  device_type = ObjectVar (
    model = DeviceType,
    display_field = 'модель'
)

Чтобы ограничить выбор, доступный в списке, можно передать дополнительные параметры запроса как словарь query_params . Например, чтобы показать только устройства со статусом «активный»:

  устройство = ObjectVar (
    model = Устройство,
    query_params = {
        'статус': 'активный'
    }
)

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

  регион = ObjectVar (
    model = Регион
)
site = ObjectVar (
    model = Сайт,
    query_params = {
        'region_id': '$ регион'
    }
)

MultiObjectVar

Аналогично ObjectVar , но позволяет выбирать несколько объектов.

FileVar

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

IPAddressVar

Адрес IPv4 или IPv6 без маски. Возвращает объект netaddr.IPAddress .

IPAddressWithMaskVar

Адрес IPv4 или IPv6 с маской. Возвращает объект netaddr.IPNetwork , который включает маску.

IPNetworkVar

Сеть IPv4 или IPv6 с маской. Возвращает объект netaddr.IPNetwork . Для проверки предоставленной маски доступны два атрибута:

min_prefix_length — Минимальная длина маски
max_prefix_length — Максимальная длина маски

Запуск пользовательских сценариев

Примечание

Для запуска пользовательского сценария пользователю должны быть назначены дополнительные функции . run_script разрешение. Это достигается путем назначения пользователю (или группе) разрешения на объект Script и указания действия run в пользовательском интерфейсе администратора, как показано ниже.

Через веб-интерфейс

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

Через API

Чтобы запустить сценарий через REST API, отправьте запрос POST в конечную точку сценария, указав данные формы и обязательство.Например, чтобы запустить сценарий с именем example.MyReport , мы должны сделать следующий запрос:

  curl -X POST \
-H "Авторизация: токен $ TOKEN" \
-H "Content-Type: application / json" \
-H "Принять: application / json; indent = 4" \
http: //netbox/api/extras/scripts/example.MyReport/ \
--data '{"data": {"foo": "somevalue", "bar": 123}, "commit": true}'

Пример

Ниже приведен пример сценария, который создает новые объекты для запланированного сайта. Пользователю предлагается ввести три переменные:

Название нового сайта
Модель устройства (отфильтрованный список определенных типов устройств)
Количество коммутаторов доступа для создания

Эти переменные представлены в виде веб-формы, которую пользователь должен заполнить. После отправки вызывается метод run () сценария для создания соответствующих объектов.

из django.utils.text import slugify из dcim.choices импортировать DeviceStatusChoices, SiteStatusChoices от dcim.модели импортируют Device, DeviceRole, DeviceType, Manufacturer, Site из extras.scripts import * класс NewBranchScript (Скрипт): класс Мета: name = "Новая ветка" description = "Подготовьте новый сайт филиала" field_order = ['site_name', 'switch_count', 'switch_model'] site_name = StringVar ( description = "Название нового сайта" ) switch_count = IntegerVar ( description = "Количество создаваемых переключателей доступа" ) производитель = ObjectVar ( model = Производитель, required = False ) switch_model = ObjectVar ( description = "Модель коммутатора доступа", model = DeviceType, display_field = 'модель', query_params = { "Manufacturer_id": "$ Manufacturer" } ) def run (self, data, commit): # Создать новый сайт site = Сайт ( name = data ['site_name'], slug = slugify (данные ['site_name']), status = SiteStatusChoices. STATUS_PLANNED ) site.save () self.log_success (f "Создан новый сайт: {site}") # Создать переключатели доступа switch_role = DeviceRole.objects.get (name = 'Коммутатор доступа') для i в диапазоне (1, данные ['switch_count'] + 1): переключатель = Устройство ( device_type = data ['switch_model'], name = f '{site.slug} -switch {i}', site = сайт, status = DeviceStatusChoices.STATUS_PLANNED, device_role = switch_role ) выключатель.спасти() self.log_success (f "Создан новый коммутатор: {switch}") # Создать таблицу новых устройств в формате CSV вывод = [ "название, марка, модель" ] для переключателя в Device.objects.filter (site = site): attrs = [ switch.name, switch.device_type.manufacturer.name, switch.device_type. No related posts.

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Сценарии пользовательские: Пользовательские сценарии: что это такое, как и для чего их нужно строить

Пользовательские сценарии: что это такое, как и для чего их нужно строить

Как создать User Story, сценарии и кейсы | by Anastasia Purdes

Не забывайте о пользователях

User Story

Пользовательские сценарии

Варианты использования

User Flow

Как это использовать?

Пишем пользовательские сценариии для анализа дизайна сайта / Хабр

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

Артефакты: сценарии | UXExperience

Пример:

Пример:

Пример:

Пример:

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

Подводные камни

Полезные ссылки и инструменты

Пользовательские сценарии Джейсон Арбон. Как тестируют в Google

Читайте также

Пользовательские папки

12.

3. Пользовательские регистры

Пользовательские объекты

Пример отличного кандидата Джейсон Арбон

Как отличить тестировщика от разработчика в тестировании Джейсон Арбон

Управление «пиратским кораблем» для чайников Джеймс Арбон

Пример режима сопровождения: Google Desktop Джейсон Арбон

Сингулярность:[54] легенда о происхождении ботов Джейсон Арбон

Слияние BITE с RPF Джеймс Арбон

Инновации и эксперименты в тестировании Джеймс Арбон

Пользовательские триггеры

Пользовательские качества

Пользовательские Web-интерфейсы

39.

Пользовательские сценарии в SEO – статьи про интернет-маркетинг

Поиск новых ниш

Сценарии и истории пользователей в UX-дизайне

Сборник кастомных скриптов | Пользовательские скрипты Sentinel-Hub

Репозиторий пользовательских сценариев

Соответствующая литература

Страж-1

Алгоритмы растительности в сельском хозяйстве

Алгоритмы управления и предотвращения стихийных бедствий

Алгоритм городского планирования

Алгоритмы среды морских и других водных объектов

Другие доступные скрипты

Прочие разновременные сценарии

Страж-2

Популярные RGB композиты

Индексы дистанционного зондирования

Алгоритмы обнаружения облаков

Алгоритмы снега и ледников

Алгоритмы управления и предотвращения стихийных бедствий

Алгоритмы классификации землепользования / земельного покрова

Алгоритмы растительности

Сельское и лесное хозяйство. Алгоритмы

Алгоритмы среды морских и других водных объектов

Алгоритмы городского планирования

Прочие разновременные сценарии

Другие доступные скрипты и индексы

Скрипты, включая методы машинного обучения (eo-learn)

Страж-3

Sentinel-3 OLCI

Улучшенные скрипты с истинным цветом

Индексы дистанционного зондирования

Sentinel-3 SLSTR

Страж-5П

Доступные скрипты

Ландсат 8

Индексы дистанционного зондирования

Другие доступные скрипты

Landsat 5 и 7

MODIS

Индексы дистанционного зондирования

DEM

PlanetScope (коммерческая)

Airbus Pleiades (коммерческий)

Airbus SPOT (коммерческий)

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