Design Better Data Tables

https://uxdesign.cc/design-better-data-tables-4ecc99d23356

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

Эти возможности считаю однозначно полезными:

— Фиксированный заголовок, чтобы не путаться где что при прокрутке.
— Сводка данных таблицы, чтобы быстро составить представление о датасете.
— Инлайн-редактирование, если пользователи часто меняют данные.
— Быстрый просмотр, если данные, напротив, никогда не меняются.
— Сортировка и фильтрация. Здесь Эндрю забыл указать самый главный приём — поиск одной строкой по всем колонкам (быстрее и удобнее, чем расставлять отдельные условия по каждому столбцу).

Эти пригодятся в специфических ситуациях:

— Фиксированные столбцы.
— Изменение размера столбца.
— Чередование фона строк.
— Управляющие кнопки по наведению курсора на строку.
— Модальное окно с данными из строки.
— Настройка показываемых столбцов.

А эти я бы вообще никогда не использовал:

— Ручное изменение визуальной «плотности» данных (если так уж надо, пусть программа делает это автоматически, глядя на размер окна).
— Явный переход по страницам (сделайте нормальный бесконечный скролл или показывайте топ-N записей).
— Мульти-модальные окна (ноу коментс).

Как выполнить тестовое задание на вакансию ИТ-аналитика

https://medium.com/@beskov/

Источник тут https://medium.com/@beskov/%D0%BA%D0%B0%D0%BA-%D0%B2%D1%8B%D0%BF%D0%BE%D0%BB%D0%BD%D0%B8%D1%82%D1%8C-%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2%D0%BE%D0%B5-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%B2%D0%B0%D0%BA%D0%B0%D0%BD%D1%81%D0%B8%D1%8E-%D0%B8%D1%82-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0-f3e3e59b0e03

Меня периодически зовут помочь с подбором и отбором людей на позицию ИТ-аналитика.

Обычно в качестве задания мы просим написать ТЗ по каким-то исходным данным.

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

«Можно грабить корованы!»

На что я смотрю при оценке качества работы кандидата:

  1. Сделана попытка сформулировать цели доработки, выраженные в бизнес-показателях;
  2. Описана ролевая модель (какие категории пользователей будут пользоваться модулем);
  3. Задан контекст и объём программного модуля, через:
    — Диаграмму экосистемы и/или
    Контекстную диаграмму и/или
    Диаграмму юскейсов и/или
    Реестр юксейсов и/или
    Реестр функциональных требований и/или
    Карту пользовательских историй;
  4. Если используются функциональные требования, то они:
    — Атомарны;
    — Имеют уникальные идентификаторы;
    — Понятно действующее лицо, выполняющее/запускающее функцию (система или конкретная роль);
    — Понятен результат функции;
    — Указаны входные и выходные атрибуты функции или даны ссылки на словарь данных;
  5. Поведение программного модуля проиллюстрировано через:
    Диаграмму состояний и/или
    Сквозной неформальный сценарий использования
    (регламент бизнес-процесса) и/или
    Сценарии использования (use cases) и/или
    User stories и BDD-сценарии;
  6. Структурные аспекты программного модуля описаны через
    Диаграмму данных и/или
    Словарь данных и/или
    Диаграмму навигации;
  7. Поведение и структура проиллюстрированы макетами интерфейса;
  8. Нефункциональные свойства программного модуля описаны через:
    Ограничения (Совместимость по ОС/ПО, протоколы взаимодействия со смежными модулями/системами, разрешение экрана);
    Атрибуты качества, как минимум: производительность, надёжность.
  9. Бизнес-правила описаны отдельно, со ссылками на них из ФТ или юскейсов.
  10. По всем неоднозначным вопросам выше составлен перечень открытых вопросов.

Поражает, какое количество людей в ИТ, претендующих на позицию аналитика, не смогли дойти ногами до книжки Вигерса за 800 рублей.

P.S. Причём научиться делать руками всё то, что описано выше, можно буквально за 2 курса:

  1. Разработка ТЗ на ПО (24 часа)
  2. Разработка User Stories и планирование релизов (10 часов)

The Maltese Corsairs

Malta is a magnificent island in the middle of the Mediterranean sea. Our knowledge about Malta mostly link to the  Maltese Knights (did you know what the full name of Maltese Order is Sovereign Military Hospitaller order of Saint John of Jerusalem, of Rodoce, and of Malta?), but this small island also was a base for the corsairs.

The Corsair was a specific job.  Partly it was a military job, but usually, that job was fulfilled by civil people. Those people were on services for King, they paid taxes to King by stolen goods. King (or Maltese knights as it was on Malta) help them to equip a ship and then they robbed the ships of the King’s enemies. Usually, there were Muslims ships. And this was main difference from pirates. Pirates could rob and killed any ship, which they want and they left all the prey to themselves.

Almost 17% of Maltese population were corsairs and the rest supported this sort of business.

That business gave work for many generations of Maltese. Before going to sea, corsairs had to solve a lot of  problems: repair or bay the equipment for a ship, hire sailors and rowers (these guys often weren’t corsairs – they just worked for corsairs). After successful raiding, they needed a place where they could bring captured ships, store and sell stolen goods, keep the enslaved members team of the robbed ship. Thus, almost half of the population of Maltese had work to support this business.

Port still have a lot of special warehouses, every warehouse belongs to the concrete ship.

 

Name of ship is written above the entrance.

 

Corsairs had an interesting tradition: after successful raiding,  they melt copper candlesticks and made of them door hammers in the form of dolphins with tails from a trident of Neptune. Because when they were on they way home — dolphins very often accompanied their ships, and it was a sign of good luck. And the trident symbolized the protection of the god of the seas. Nowadays we can see a lot of this things on the entering doors.

Основные понятия

1.3.1 Домены

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