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

© Юрий Михалыч, посмотреть на Яндекс.Фотках

Заметки на полях:

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

Каждая карточка для карточного тестирования должна содержать номер, название и краткое описание. Желательно ограничить количество карточек тремя десятками.

SaaS — хороший способ защиты копирайта, так как ПО не отчуждается.

Последнее время меня буквально преследует аббревиатура SaaS — software as a service: в статьях, интервью, комментах, на баннерах и в речи коллег. Мода или актуальность?

P.S. Википедия: Software as a service (SaaS) («Программное обеспечение как услуга»), или Software on Demand (SoD) («Программное обеспечение по требованию») — бизнес-модель продажи программного обеспечения, при которой поставщик разрабатывает веб-приложение и самостоятельно управляет им, предоставляя заказчикам доступ к программному обеспечению через Интернет. Основное преимущество модели SaaS для потребителя состоит в отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и программного обеспечения, работающего на нём.

Дмитрий Слиньков в блоге на slon.ru в числе прочих мыслей по поводу развития Интернета высказал следующую:

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

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

В книге «Разработка требований к программному обеспечению» Карл Вигерс приводит шаблон товарища Мура (Moore, 1991) из ключевых слов, который позволяет составить сжатое положение об образе проекта. Вот они:

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

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

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

На сайте medsputnik.ru подразумевалось, что информацию можно будет делить на части, свойственные заболеваниям или проблемам со здоровьем, которые имеют свои симптомы. Когда возникла необходимость выложить на сайт материал о головной боли, которая сама является не чем иным как симптомом, то возник вопрос чем заполнить соответствующий обязательный раздел? Решение было выбрано, прямо скажем, неудачное: концентрация слов «симптомы» и «головная боль» большая, да только в предлагаемых статьях пишется о другом. Например, статья «Головная боль при приеме алкоголя» лежит в подразделе «Как симптом» раздела «Симптомы». Хотя какие еще нужные дополнительные признаки тяжелой головы с похмелья?

К чем этот поток сознания пример? Любой интерфейс, завязанный на таксономию, должен быть ГИБКИМ и позволять исключать-добавлять-переименовывать, как минимум.

P.S.
А еще на медспутнике подраздел назван как раздел («Симпотомы Симптомы»). Отдельное фи.