Post #73

Надо бы немного оживить проект, вернув его к историям. Поскольку у меня пара методичек в процессе — про погодные визуализации и про многоэкранные системы(а завяз я, как ни странно, на иллюстрациях, особенно в погоде), то попробую подкидывать какие-то мелкие фишки, которые всплывают в рабочей рутине (или подготовке этих опусов), достаточно компактные, чтобы не вогнать в сон и не потратить кучу времени на систематизацию. Думаю всё равно полезными будут. Под аппаратку или под задачи Итак, в большинстве случаев мы проектируем интерфейсы исходя из статистики того, что есть у пользователя — если это мобильные устройства, то мы смотрим чем пользуются условные 90-95% потребителей — и, разумеется, давно отшвыриваем какие-нибудь древние айфоны и андроиды. Если под десктоп — смотрим браузерную статистику и т.п. Это, конечно, верно и для профсистем, особенно более-менее платформенных, с большим количеством инсталляций, и которыми пользуются на рабочих компьютерах. Такой подход редко подврегается сомнениям, ибо завязан на коммерцию (т.е. широту охвата), но меж тем, у него есть и недостатки. Например, все эти попытки запихнуть в мобильный телефон полнофункциональное приложение — изначально компромиссные решения. В одних случаях (в первую очередь потребительских) это терпимо, но если система обладает большой информационной нагрузкой со сложными связями, либо если у нас много элементов управления и нужно максимально быстро переключаться с одной задачи на другую, особенно в реальном времени — то эта затея будет обладать большим количеством минусов. Иногда нам нужны большие экраны, чтобы видеть сразу больше и находить нужную кнопку немедленно. Если говорить о более специализированных системах, то в таких случаях мы можем выбирать аппаратные средства, ибо цена оборудования может быть намного меньше, чем цена всей системы, либо же сама система – это единый программно-аппаратный комплекс (ПАК), а то и часть еще большей инженерной системы (завод, судно, самолёт). В таком случае мы можем не отвлекаться на компромиссные решения по попытке упихнуть всё в мелкие, или масштабировать в разные устройства, а выбирать и контролировать аппаратные средства более свободным образом — то есть идти от задач, а не от техники. И прямо выбирать — если у нас несколько одновременно используемых режимов, то можно разбить их на несколько экранов, если нам нужны элементы интерфейса для свойств (“инспектор”) и инструментов к холсту (карте, изображению, видео) — лучше взять широкоформатный экран, а если у нас навигационная система для рек — то возьмем подобный экран и поставим в портретной ориентации в консоли, и так далее. То же самое со средствами управления — может стоит вынести некоторые органы управления в физику (джойстики, кнопки, слайдеры), а не полагаться как на данность на сенсорные экраны с их ограничениями или клавиатуру и мышку? Таких примеров вообще может быть много. Я хочу лишь сказать, что проектирование взаимодействия — это дорога в двух направлениях, стоит идти не только от инженерии к задачам, но и от задач к инженерии. Разумеется, ресурсы/бюджеты здесь (как и везде) являются определяющими, но учитывать это стоит. Опять же, очень многие вещи теперь доступны и в частных небольших проектах, благодаря относительно дешевой компонентной базе и возможностям аддитивной печати. На мой взгляд, это сильно недооцененное направление размышлений. #мысливслух#кудаглядеть