Post #354

Вопрос "кем является система" для меня связан с вопросом "какие социальные взаимодействия поддерживает система"? Проще говоря, как у вас люди общаются друг с другом через систему. В российской практике профессиональной ориентации очень часто применяют типологию профессий Е.А.Климова: вот эти вот ЧЕЛОВЕК-ПРИРОДА, ЧЕЛОВЕК-ТЕХНИКА, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, ЧЕЛОВЕК-ЧЕЛОВЕК. Вы, возможно, помните из школы. За пределами пост-советских стран такая типология, правда, не встречается. Так вот — работа с информационными системами, это, конечно, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, но в современных реалиях это почти всегда ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА-ЧЕЛОВЕК. Вы через систему взаимодействуете с другими людьми опосредовано. Система может вам помогать это делать, а может мешать или диктовать свои способы взаимодействия, часто неестественные. У Джоела Спольски, которого я считаю одним из лучших авторов по проектированию интерфейсов, есть книга: User Interface Design For Programmers, в русском переводе Руководство по UI дизайну для программистов (тут сразу pdf). Это 2001 год, а примеры там вообще из 90-х. Но принципиально ничего не поменялось... в интерфейсах. А вот в проектировании поменялось — теперь мы почти всегда проектируем социальные системы. Джоел написал об этом в 2004: It’s Not Just Usability, перевод: Не юзабилити единым, а ещё раньше в 2003: Building Communities with Software, перевод не нашел. Один из примеров — интерфейс Napster (если вы помните такое приложение, кхе-кхе). Интерфейс был ужасен. Программа работала только на Windows. Это было одно из самых популярных приложений в мире. В 2000 году Napster создавал от 40 до 60% трафика в частных сетях и в сетях университетов. Если вы делаете то, что нужно людям — они будут мириться с любым интерфейсом. Сейчас, наверное, можно привести в пример красноглазые интерфейсы в области крипты. Вывод: проектировать нужно не значки на экране, а взаимодействие между людьми. Что они делают друг для друга. Как они относятся друг к другу. Что нельзя делать по отношению друг к другу. Как сообща бороться с вредоносными участниками. Есть масса приложений с красивыми интерфейсами, совершенно не учитывающими — как именно люди общаются и взаимодействуют в каком-то процессе. Школьные дневники. Запись ко врачу и хранение истории приемов. Социальные сети (нечеловеческий LinkedIn чего стоит!). Системы приема докладов на конференции. Системы управления задачами и документацией. Джоел приводит в пример свой FogBugz — багтрекер, в котором люди действительно работали над исправлением дефектов, в отличие от других систем, которые "was never getting used, because it did not align with the way people wanted to work together" (кстати, не доверяйте переводам, там эта фраза переврана до противоположного смысла). Про FogBugz не знаю, не видел, а Trello, разработанная в той же компании, конечно, почти эталонная по интерфейсу легковесная система управления задачами. Практически невозможно спроектировать хорошее социальное взаимодействие, если смотрите изнутри системы. Поэтому я считаю почти бесполезным описание вариантов использования в виде CRUDL вокруг сущности. Не поняв, в чем смысл каждой операции — в чем её социальный смысл! — вы не сможете определить функции и отсутствие функций, которые сформируют и определят нужное поведение. В принципе, можно было бы отмахнуться от рассуждений какого-то там очередного программиста-предпринимателя. Ну он же не дизайнер и не психолог, что нам втирает. Если бы не одно "но": Джоел Спольски — создатель StackOverflow. Социального сервиса, который собрал крупнейшее сообщество разработчиков и в определенном смысле перевернул способ обучения програмиированию и разработки. Я бы прислушался.