Компоновка
Jan. 28th, 2016 05:23 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouthМеня внезапно осенило, почему лишь очень небольшая часть хороших программистов в состоянии делать хорошие юзер-интерфейсы.
Дело в том, что хороший интерфейс – это система, в которой основную роль играет качество компоновки, а не качество реализации внутренних подсистем как таковых. В отличие от, скажем, программ командной строки или серверных решений, экспортирующих API.
В UI компоновка не просто определяет качество решения, компоновка и есть решение. Причём ограничения на компоновку весьма жесткие, не в пример суровей типипчных ограничений на компоновку программ без графического UI. Я думаю, тут уместна будет аналогия с компоновкой летательных аппаратов, там тоже внешние обводы и диапазон центровки – непреодолимые ограничение, любые подвижки в которых очень тяжело даются.
Типичная программа редко приближается к ограничениям окружения – обычно имеется существенный резерв, нередко на порядки. Да и самих ограничений рантайма не так и много: CPU, IO, RAM, overall response time.
С UI всё совсем не так – ограничения на время отклика отдельных частей, геометрию, да просто количество элементов, на связность и сгруппированность их, очень жесткие, никаких «туда-сюда на порядок» там нет в помине. Плюс целевые системы могут очень отличаться по производительности и, например, размерам экрана.
Задачи на связность и группировки, если их решать в лоб, моментально дают комбинаторный взрыв – а компоновка как раз такая задача.
Наилучший способ решения таких задач – это использовать мозги для того, что они (нейронные сети) умеют лучше всего, и это совсем не логическое мышление. Это навигация по ландшафту. В этом случае, ландшафту вариантов решений, образованных этим самым комбинаторным взрывом.
Сначала выбирается стратегия, а затем итеративно строится путь, причём возврат «назад», к началу, стóит существенно дороже, чем движение вперёд. Примерно так мы играем в шахматы. Примерно так выглядит процесс обучения, когда мы учимся самостоятельно.
Компоновка – это игра, а программисты нередко слишком серьёзные )
Дело в том, что хороший интерфейс – это система, в которой основную роль играет качество компоновки, а не качество реализации внутренних подсистем как таковых. В отличие от, скажем, программ командной строки или серверных решений, экспортирующих API.
В UI компоновка не просто определяет качество решения, компоновка и есть решение. Причём ограничения на компоновку весьма жесткие, не в пример суровей типипчных ограничений на компоновку программ без графического UI. Я думаю, тут уместна будет аналогия с компоновкой летательных аппаратов, там тоже внешние обводы и диапазон центровки – непреодолимые ограничение, любые подвижки в которых очень тяжело даются.
Типичная программа редко приближается к ограничениям окружения – обычно имеется существенный резерв, нередко на порядки. Да и самих ограничений рантайма не так и много: CPU, IO, RAM, overall response time.
С UI всё совсем не так – ограничения на время отклика отдельных частей, геометрию, да просто количество элементов, на связность и сгруппированность их, очень жесткие, никаких «туда-сюда на порядок» там нет в помине. Плюс целевые системы могут очень отличаться по производительности и, например, размерам экрана.
Задачи на связность и группировки, если их решать в лоб, моментально дают комбинаторный взрыв – а компоновка как раз такая задача.
Наилучший способ решения таких задач – это использовать мозги для того, что они (нейронные сети) умеют лучше всего, и это совсем не логическое мышление. Это навигация по ландшафту. В этом случае, ландшафту вариантов решений, образованных этим самым комбинаторным взрывом.
Сначала выбирается стратегия, а затем итеративно строится путь, причём возврат «назад», к началу, стóит существенно дороже, чем движение вперёд. Примерно так мы играем в шахматы. Примерно так выглядит процесс обучения, когда мы учимся самостоятельно.
Компоновка – это игра, а программисты нередко слишком серьёзные )