Пикейное жилетство от ИТ

[metaclass]

В процессе срачей про вечные двигатели и обсуждения доисторических языков типа хаскеля с канадскими линуксоидами посетила следующая идея: проблемы с софтовой индустрией сводятся к трем вещам:

* Качественный софт на самом деле никому не выгоден, про что упоминает vit_r

* Нормальных средств разработки UI как не было, так и нет. Просто нет, от слова совсем. Если сравнить достижения в разработке кишков софта и UI - небо и земля. Все потому, что UI надо разрабатывать, общаясь с пользователями, а еще лучше с психиатрами по эргономике, а асоциальным программистам это внутренний паук запрещает. И вообще психиаторы их всех в психушку сдадут, как только про удобный интерфейс гита узнают.

* Мейнстримные инструменты плохо умеют в целостность данных. Если бы не отцы-основатели реляционной модели, транзакции и ебические объемы данных у главных платежеспособных заказчиков типа банков, в которые ничто, кроме реляционных СУБД, толком не умеет - вся индустрия умерла бы давно, в мучениях.

Comments

[metaclass.livejournal.com]

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

[mechanician.livejournal.com]

Если пользователь поменял какой-то параметр, рядом с ним сразу поднимается галочка "закрепить". Вот и получится, что такие галочки стоят у всех, которые он редактировал. И не надо ничего отдельно запоминать и анализировать. Понятно, что перед этим хорошо бы проверять набор закрепленных параметров на допустимость и ругаться, если что.

[berezovsky.livejournal.com]

Можно сразу давать выбирать из допустимых. Но это может бесить. Например, идёт диапазон значений. Тебе надо ввести нужную цифру, а тебе не даёт, потому что не подходит под остальные параметры. Но цифру ввести надо - рука жаждет вбить, пока не забылось. Поэтому лучше дать, но потом ругнуться.

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

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

При этом если в приложении этих форм до ебени матери, всё это должно в едином стиле работать. Нельзя в одном месте окошки бросать, а в другом красные сообщения на форме рисовать. Проблемы, как всегда, в поиске баланса. А для этого надо пользователя чувствовать, смотреть на приложение его глазами.

[mechanician.livejournal.com]

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

Для поиска баланса вообще, имхо, самое главное, перестать считать пользователя идиотом. Человеку, который "подгоняет катушку индуктивности", про эти катушки по должности положено знать намного больше программиста и его программы. Так что первое, что ему надо - это просто понятный ввод и честное сообщение о его некорректности. В большинстве случаев, получив такое сообщение, он сам поймет в чем не прав.

Проблемы с интерфейсом часто начинаются тогда, когда программа вместо ввода-вывода пытается пересказать человеку всю свою тяжелую жизнь "именно по-человечески, что вот это вот не подходит потому что то-то и то-то". :)