Previous Entry Share Next Entry
В защиту программистов
si14
Тут tonsky снова выступил в классическом для себя жанре «тупые программисты не умеют в дизайн». Пожалуй, выскажусь на этот счёт, потому что дальше терпеть нет сил.

Больше всего в подобных текстах плохо то, что они представляют проблему так, будто дело действительно в чьей-то лени, тупости или непрофессионализме. На деле же UI это очень сложно и нужны новые решения, алгоритмы, библиотеки и ресёрч, а не «да просто всё перепишем на технологию X и станет круто». Возьмём, например, тот же CSS. Какие проблемы решаются так или иначе текущим веб-стеком?

  • позиционирование. Да, текущая модель в CSS3, мягко говоря, неидеальна. Но какие у нас есть альтернативы? Предлагается GSS, который, по сути, Cassowary simplex solver. Простите, кто-то умеет хорошо отображать, понимать и дебажить результаты работы simplex solver'а для UI? Есть какие-то способы убедиться, что раскладка элементов по странице (NP-сложная в случае GSS!) не сожрёт батарею мобильного за три минуты? Что делать с изменением размеров элементов на странице (у нас же JS) — пересчитывать всё? Гора проблем, вытекающих из «ну сделайте нам произвольные constraint'ы, чо, жалко, что ли, тупые, что ли», и неочевидный tradeoff между вычислительной сложностью и гибкостью.;

  • текст. Текст это боль. Нет, даже не так: БОЛЬ. Хорошее, типографского качества выравнивание по ширине предполагает понимание, где можно разбить слово для переноса (очень специфично для языка; желательно с возможностью хинтинга), оптимизацию расстояний между словами минимум в параграфе (а лучше на странице); оптимизацию кернинга внутри слова; висящую пунктуацию; поддержку десятков популярных шрифтов (с информацией о микрокернинге в т.ч.). И всё это — для рендеринга на прямоугольные статичные листы А4. Теперь представим, что ко всему этому аду добавляется анимация, непрямоугольные блоки для текста и произвольные ограничения для элементов, которые текст должен обтекать. Нравится?

  • хинтинг. SVG и всякое векторное замечательно ровно до тех пор, пока из-за отображения floating point координат векторных объектов в int'ы пикселей экрана между соседними элементами не остаётся полоска в пиксель или пока линии не размазываются в мыльное месиво из-за неудачного AA. Несмотря на пропаганду «сейчас мы всё сделаем в векторе и будет круто на любом разрешении», так не получается даже просто по техническим причинам — а есть ещё и эстетические (уровень детализации должен зависеть от размера);

  • минимизация reflow. Все любят анимации, но расположение элементов на странице достаточно дорогая операция даже для сегодняшней костыльной модели позиционирования, поэтому браузеры минимизируют перерисовку страницы. Теперь представим, что мы делаем более гибкую модель позиционирования и нажатие на одну кнопку меняет положение всех элементов 60 раз в секунду. К вашему мобильному уже подключен термоядерный реактор?

Наконец, анимации. Анимации это очень хорошо, но:

  • можно, пожалуйста, перестать делать и пиарить «модальные анимации»? Даже в примере из поста совершенно бесполезная надпись «all is done» вместе со стильным появлением и исчезновением занимает примерно две секунды. Зачем? Апофеоз же этого стиля анимации показали в комментариях — трёхсекундный полноэкранный мультик при отправке письма, которую можно (и нужно) делать вообще в бекграунде;

  • совершенно нет дискуссии относительно того, как прерывать и откатывать анимацию. Вот эти 0.3–0.5 секундные переходы невероятно раздражают, если нужно вернуться на страницу, с которой совершил случайный и ненужный переход. Как рисовать все эти прелестные ease-in'ы, если пользователь ткнул пальцем на «вернуться» в «полёте»?

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

Типичная проблема софтостроения, если требования вначале были такие, потом другие, а потом совсем новые, то рожденный таким образом софт получается совсем не похожим по структуре как если бы требования изначально были в последнем варианте. Да и новые требования реализуются как-то не очень. При наличии хороших программистов это мало заметно на проектах по 1-2 гоа, но хорошо видно в течении 5-10 лет.

Та же проблема что и с застреванием в локальном максимуме при градиентном подъеме.

Мы же не удивляемся, что старые win32 приложения плохо выглядят на современных экранах и совсем не подходят для современных смартофонов. Следующий шажок это веб. Изначально веб был статичним, и мы наконец более менее научились решать проблему со статичной раскладкой.

Да, похоже пора придумать что-то новое. Но это новое не делает бесмыссленной предыдущие решения.

>старые win32 приложения плохо выглядят на современных экранах и совсем не подходят для современных смартофонов

Зато в них есть tab, shift-tab, ctrl-tab, ctrl-со-стрелочками, alt+горячие клавиши всех видов, универсальный буфер обмена, и способность работать на 16 МБ оперативной памяти, под Windows 95. До этого удобства и богатства возможностей любому смартфону как до Пекина раком.

> между соседними элементами не остаётся полоска в пиксель

Замечу, что в gamedev эту проблему ("провалился под землю уровня через полоску в один пиксел") решают валидацией моделей на отcутствие T-vertices

Edited at 2014-12-29 11:21 am (UTC)

Дизайнеры не умеют поведения. Для программиста поведение объекта во временени, его feel по крайне мере равнозначно с его видом при первом взгляде. Дизайнеры, пршшедшие из полиграфии про то что объект динамичен часто забывают.

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

Полностью согласен. Темпоральную логику нигде не учат, от слова вообще. И 90% программистов тоже в это не умеют.

(1) По-моему, ты решительно не понял tonsky.

(2) способы убедиться про батарею называются "профайлер", и нужны уже в нынешнем CSS, который хоть и не NP-полный, но O(n^4) если мне не изменяет память, и я на это уже напарывался

(3) про текст отложим

(4) проблема хинтинга стремительно облегчается по мере распространения high-resolution дисплеев, это один из немногих случаев, когда тупое техническое решение лучше умных

(5) reflow, опять же, профайлится, как уже профайлятся paint rectangles
=============
А теперь про проблемы.

Всё это сводится к тому, что *требования к дизайну выросли*, модалки действительно гавно, инфраструктура для прерываний есть только в WPF (больше нигде не видел), тулзов катастрофически не хватает, и стоимость разработки растёт на порядок.

Всё это уже в свое время проходил игрострой. Были бюджеты в $10k и 2 разработчика, стали $250M и полтыщи разработчиков.

Ругать надо тех, кто не хочет инвестировать в тулзы.

А программистов UI, как ни странно, таки нужно учить дизайну и юзабилити... Вот только кто бы еще это умел делать...

Ну и кстати насчёт модалок, это как раз ржачная иллюстрация того, что tonsky тоже стоит вспомнить, что есть разные группы эээ пользователей, не только эпилептики и дальтоники, а и целая куча прочих ЛИЧНЫХ вкусов, и чем навороченнее дизайн, тем больше ВАРИАНТОВ этого дизайна придётся делать. Не "One True Design", а именно вариантов.

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

> А программистов UI, как ни странно, таки нужно учить дизайну и юзабилити... Вот только кто бы еще это умел делать...

Для того, чтобы можно было научить программистов UI, нужно создать математическую теорию UI. Учить программистов сколь угодно сложной математике - умеют.

Хотя вот такую всю из себя замечательную реляционную алгебру все время пытаются (и в оснвном - безуспешно) куда-нибудь спихнуть в бок, и развести какой-нибудь nosql, или хотя бы ОРМ.

С другой стороны, объектный подход в программировании до сих пор держится в основном как раз за счет того, что для UI более внятных моделей не существует. Если появится алгебра UI, функциональщики съедят объектников с потрохами.

>Если появится алгебра UI, функциональщики съедят объектников с потрохами.

Вот это -- не факт. Вон у нас, есть алгебра табличных баз данных. И что, избавило это на от объектников? Да нифига, тысячи их!

Так что если появится алгебра UI -- то, скорее всего, нынешний уй станет нишэвым решэнием для чего-то совсем мелкого. Примрно как итэраторы по рекордам кобола и пл/1. А программисты какими были, такими и останутся.

\\Вон у нас, есть алгебра табличных баз данных. И что, избавило это на от объектников? Да нифига, тысячи их!

Потому что им постоянно надо мэпить эти таблици на Ю-Ай и обратно.

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

Ниша будет большая и толстая как сейчас 1С. Надо же куда-то толпы ПТУ-шников трудоустраивать. Только за программистов интеграторов 1С сейчас не очень считают. Ну и тогда программистов UI по старинке - тоже не будут за программистов считать.

Арт-директору (который понимает принципы) и сейчас платят в 5-15 раз больше, чем рядовому аниматору (у которого есть работа только потому, что easing curves не всё могут решить самостоятельно) (США, Япония)

Edited at 2014-12-29 11:31 am (UTC)

Нужно просто положить UI в базу и алгебра готова :)

Не "просто положить", а "правильно положить". Потому что примеров баз данных реляционных по названию, а на деле нарушиающих реляционую модель, в окружающей среде полно.

А чтобы разработать те правила, по которым правильно положить, нужен математический гений.

> Для того, чтобы можно было научить программистов UI, нужно создать математическую теорию UI.

Так придумывали уже, ещё Раскин в книге «The Humane Interface» (2000г), а воз и ныне там.

У Раскина там нет нифига математической теории. Есть скорее философская.

К тому же он там впал в ту же ошибку, в которую впадают многие другие исследователи систем, содержащих в качестве компонента человека (Маркс, фон Хайек etc) - вместо теории описывающей "как оно бывает", стал конструировать этическую систему, описывающую "как оно должно быть".

Ну и его представления о том, как должен выглядеть интерфейс, на тот момент устарели лет на 15.

\\хинтинг. SVG и всякое векторное замечательно ровно до тех пор, пока из-за отображения floating point координат векторных объектов в int'ы пикселей экрана между соседними элементами не остаётся полоска в пиксель или пока линии не размазываются в мыльное месиво из-за неудачного AA. Несмотря на пропаганду «сейчас мы всё сделаем в векторе и будет круто на любом разрешении», так не получается даже просто по техническим причинам — а есть ещё и эстетические (уровень детализации должен зависеть от размера);



Есть например такая штука -- http://www.antigrain.com/doc/introduction/introduction.agdoc.html

сам с ней работал, выглядит очень неплохо.

Антигрейн хороший, но ващще не о том.

Ну а что ты на меня-то наехал? Я нигде не говорю, что программисты тупые, просто часто они решают не ту задачу не теми методами. Когда вот это вот несовпадение задачи и инструмента так очевидно, есть потенциал для лучшего решения, о котором я и говорю в посте. Заметь, я не анализирую причин, почему лучшего решения до сих пор не возникло, и не занижаю сложность уже нагороженных решений, адаптированных под задачу. Задача поста — показать, что то, что считается нормой и индустриальным стандартом, едва ли оптимум. Единственное, что я себе позволяю — посмеяться над инерцией процесса стандатризации и логикой «если решение есть, надо его использовать», которое приводит к такому вот застою в вебе. Потому что я не люблю инерцию и доступными мне способами борюсь с ней. Мне лично не нравится, что из-за того, что кто-то когда-то придумал модель text flow в html, мы до сих пор в ней должны все верстать. То же самое с JS, идея компилировать в него абсурдна, тем не менее, никто не чешется. Я понимаю, что есть причины, достаточно объективные, почему даже у гугла dart не взлетел, но идея от этого менее абсурдной не становится.

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

Вот как решения накладываются на твои критерии:

— Cassowary инкрементальный, то есть идеально подходит именно для UI, живого, анимированного
— Позиционирование становится куда более простой задачей, когда блоки перестают подчиняться правилам букв. Т.е. в идеале text flow должен быть специальной опцией для очень редких блоков, в которых пишут текст, а всё остальное на странице должно позиционироваться как прямоугольники, без всей этой ереси с обтеканием. Мы упростим алгоритм, упростив постановку задачи. То, что делают сейчас браузеры, примерно соответствует тому уровню ада, который ты описал, но так сложно _не нужно_ для верстки страниц. В этом решение
— Проблемы анимации не очень понятны, по крайней мере на фоне остального, это тривиальщина какая-то. Ты пытался намекнуть, что тупые программисты без чувства стиля забывают делать прерывание у анимации?

> почему даже у гугла dart не взлетел

Потому что дарт - говно.

Что легче — писать оптимизирующий компилятор JS или сделать нормальный ассемблер в браузер, на который когда-нибудь все уже перейдут? Даже компания с бесконечными ресурсами не может себе позволить второе, потому что — ну не договорятся остальные браузеры никогда. Если бы в 2008 году (шесть лет назад!) Гугл вместо v8 опубликовал какую-нибудь low-level vm для браузера, мы бы сегодня в 3D игры играли в браузере. Правда, только в Хроме.

Внимание на экран: http://thedeemon.livejournal.com/92338.html

Предваряя вопросы, Dart VM, конечно, не столь mature, как V8, но уже более двух лет ей. А волшебные плюшки оптимизатору от отупления языка до состояния, когда лучше писать на каком-нибудь haXe - почему-то всё никак не наступят.

См. также на скорость работы *компилятора*, который при этом *намного* проще того же haXe по фичам и штукам вроде interprocedural optimizations.

Edited at 2014-12-29 11:44 pm (UTC)

> авторитетный источник mr_aleph сообщил, что на 64-битной Dart VM все сильно шустрее JS

О чем и речь, мы бы могли сейчас спокойно видео декодировать в браузере, не знаю, protobuf-ы парсить, gzip разжимать, вообще интернет бы летал. Но нет, пишем-с трансляторы в JS.

> видео декодировать в браузере

кстати, где там WebCL? на CPU я не хочу видео декодировать, например.

> Но нет, пишем-с трансляторы в JS.

я не возражаю насчет суперского байткода. только вот почему блин никто не осиливает нормальный джит и нормальный интероп? хотя бы уровня дотнета, он там неидеальный но он хотя бы есть.

Алсо, у них *есть* ассемблер, PNaCl то есть, советую погуглить про его проблемы ;-)

А можно в двух словах, какие у него проблемы? Принципиальные хотя бы. А то надо в тему погружаться, чтобы сквозь success stories до негативного опыта добраться, да и взвесить адекватно количество плюсов и минусов не выйдет так просто.

> какие у него проблемы? Принципиальные хотя бы

инициализация (JIT) на проектах чуть более хелловорлда занимает десятки секунд, что в современном мире неприемлемо; интероп очень тормозит (как и у asm.js, кстати); динамической линковки нету (что усугубляет инициализацию), то-сё.

> По сути, наши посты дополняют друг друга
Таки да

Что касается NP полноты, то тут тоже надо быть осторожным, чтобы не опустить руки раньше времени. С математической точки зрения ничего не сделаешь, а вот с практической можно. Во-первых, константы бывают разные, во-вторых, размер страницы весьма ограничен, и предпосылок к его росту особо нет. Плюс всегда можно чуть поднапрячь программиста и дать ему инструменты, которые сильно облегчат сложность задачи. Так существую как-то Dom diff, CSS правила. Теория не дает нам хорошего общего решения, но жить как-то можно. Так что раньше времени пугаться не стоит

> размер страницы весьма ограничен

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

> пока из-за отображения floating point координат векторных объектов в int'ы пикселей экрана между соседними элементами

А я всегда говорил, что floating point-ам нет места в программировании, кроме как в физических симуляциях на GPU. Именно поэтому. Никогда, никогда.

А animation transform тоже decimal'ом делать, да?

Оно не спасёт от однопиксельных дырок и T-junctions. От них спасает только триангуляция и фанатичный дебаг triangle filling rules.

Либо, поскольку мы не маньяки и хотим generic решение, просто делаем 2x oversamping и coverage тесты. На GPU. Вуаля, проблема решена. Причём, что характерно, всегда.

Edited at 2014-12-29 05:58 pm (UTC)

Не decimal'ом, а rational'ом.

Но 2x oversampling тоже хорошо. Особенно на 5k мониторе.

И rational не спасёт от T-junctions. Ну, серьезно. Только coverage пересчитывать. Если хочешь, как-нибудь потом продемонстрирую, почему это надо решать в pixel space.

Помимо всего откомментированного выше, все же прав tonsky, а не ты :)

> позиционирование. Да, текущая модель в CSS3, мягко говоря, неидеальна. Но какие у нас есть альтернативы?

Да какие угодно альтернативы, а не то говно, что пилят ублюдки уроды из W3C. Ты честно веришь в то, что проблемы типа «разместить элемент в левом верхнем углу», «разместить произвольный элемент посередине страницы» или «устроить нормальный flow элементов» нерешаемы или нерешаемы в рамках CSS?

Главная проблема в том, что W3C не заинтересован в решении реальных проблем. Им интереснее тешить свое ЧСВ, решая сугубо теоретические и академические проблемы, предлагая максимально переусложненные решения, противоречащие друг другу чуть менее, чем во всем. Хотя они должны давать практические решения, которые покроют хотя бы 80% проблем.

Есть вот этот чувак: http://www.terrainformatica.com/htmlayout/main.whtm, является членом W3C. Поверь мне, 99% тех проблем, с которыми народ сталкивается при позиционировании элементов, решается вот этими двумя простейшими решениями: http://www.terrainformatica.com/htmlayout/fspu.whtm и http://www.terrainformatica.com/htmlayout/flow.whtm

Лет 7 тому назад он предложил это решение. Его заклевали чуваки из МС и Мозиллы, потому что он, видите ли, не подумал о 0.00001% corner cases и вообще, кто он такой, чтобы перечить авторитетам.

То есть ответить на твой вопрос "что является альтернативой CSS" можно так: сам CSS и является, если убрать из него все то говно, что в енго понадобавляли и ввести в него решения реальных проблем, а не теоретических.

> Предлагается GSS, который, по сути, Cassowary simplex solver. Простите, кто-то умеет хорошо отображать, понимать и дебажить результаты работы simplex solver'а для UI?

Прямо с сайта GSS:


Cassowary Constraint Solver — the same algorithm Apple uses to compute native layout.


Apple, видимо, умеет. И, что характерно, используется в iOS. На мобильных устройствах. И ничего, никто не умер :)

И GSS, кстати, тоже прекрасно показывает альтернативу тому пиздецу, что в народе зовется CSS. Почему вот вот это можно в мобильных устройствах и вообще в UI, а в вебе нельзя?

> текст. Текст это боль.

Нет. Не боль.

Для начала читать тут: http://www.antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION (или по-русски http://habrahabr.ru/post/112401/)

Рендерингом шрифтов должна заниматься ОС, а не программист. Опять же. iOS/Mac OS. Что-то в них никто не ноет о том, что «ой, я бедный программист, я не знаю, как выравнивать по ширине».

Я просто покажу маленькую деталь из Safari:


Все. На этом все стоны про шрифты должны закончиться. Для расположения и отображения шрифтов везде, кроме веба, уже давно есть необходимые инструменты и возможности. От того, что все это будет с анимацией и прочим, ничего не меняется. Повторяю, те же MacOS и iOS имеют сотни анимаций и никто не умер, и шрифты отображаются корректно.

> хинтинг

Да, AA и прочие радости жизни. Для начала читать халтурщики в графике от автора AntiGrain и опробовать приложения отсюда: http://rsdn.ru/forum/usability/1410442.1. Ну и http://rsdn.ru/forum/philosophy/545188.1

Это все — решаемо. И, как всегда, толкается Apple'ом через свои Retina дисплеи.

> минимизация reflow. Все любят анимации, но расположение элементов на странице достаточно дорогая операция даже для сегодняшней костыльной модели позиционирования

Не даже, а из-за. Строго и исключительно из-за. Для той же iOS (в которой, как мы уже выяснили, вполне себе работает невозможный Cassoway) многие анимации вообще делаются в одну строчку. Я умолчу про что-нибудь типа https://github.com/facebook/pop. На мобильных устройствах. Почему ты так уверен, что анимации — это что-то страшное и ужасное? Их таковыми сделал W3C.

> Все эти проблемы — реальные.

Нет — это надуманные проблемы. Большинство из них уже решено и уже работает. Но только не в вебе, увы :(

> Почему вот вот это можно в мобильных устройствах и вообще в UI, а в вебе нельзя?

Однако! "Алгебра UI", про которую выше писали, уже здесь.

Алгебраично! :)

You are viewing si14