Разработчик: Эта фича интуитивно понятна, не буду писать документацию на нее. Конечный пользователь: / it-юмор :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)
Это не тупость, это какое-то альтернативное мышление. Они находят какие-то альтернативные способы использования софта, очень странные и изощренные. В итоге, когда происходят баги, ты не понимаешь, как это вообще оказалось возможным, потому что вроде везде защита. Но пользователи - это как муравьи, как вода. Твою программу они воспринимают как головоломку, которую нужно сломать, и если один находит дыры, то сразу делится с остальными. Этот коллективно-деструктивный общественный разум победить можно административными способами.
Я на эту тему как-то давно слушал лекцию. Независимо от того, что ты, как разработчик, предусмотрел и запланировал, пользователи всегда будут стараться максимально упростить работу с приложением, даже себе во вред. И да, они будут делиться друг с другом найденными упрощениями.
Бороться с этим бесполезно. Упрощать себе во вред будут даже грамотные специалисты с хорошим высшим IT-образованием. отдельные фрики не считаются.
Единственный правильный способ - скорректировать работу с приложением и самостоятельно упростить его пускай и с негативными последствиями, но минимизируя их.
Я в сфере корпоративного софта работаю, где надо не как удобно, а как надо. В итоге, перед пользователями стоят ограничения в плане того, что им делать можно, а что нет. Все, конечно, хотят сделать кнопку "сделать все хорошо", и я сам за простоту и удобство, но есть определенные бизнес-процессы, и мимо них работать нельзя. А если эти бизнес-процессы кривые и неудобные, нужно их пересматривать, а не пытаться извращать программу.
И я на 99.99% уверен, что этим корпоративным софтом кто-то пользуется криво-косо.
Невозможно предусмотреть уебанство пользователя, движимого ленью. И чем комплекснее программа, тем больше там мест, где пользователю захочется упростить.
По моему опыту любой корпоративный софт для внутреннего пользования - это избушка на курьих ножках, которая со временем превращается в многоэтажный пиздец с килотоннами легаси-кода.
Про UI вообще молчу. "Как надо", в корпоративном софте как правило означает "нахуй дизайнера UI, платить ему еще, без него справимся".
Та, программа, про которую я говорю, эксплуатируется как минимум с 2003 года, и комплексная настолько, насколько это возможно. Т.е. полностью охватывает всю работу целых отделов, имеет входы и выходы к другим системам, сервисам, в том числе и государственным. Я оттуда уволился, вообще, по сути, организация с уходом специалистов потеряла значительную часть компетенции. Недавно рассказывал, как оно все работает, и самому было смешно рассказывать посторонним людям, как что устроено, и почему это так получилось. Насколько от этого охреневали те люди, я не знаю, возможно, им было не так весело понимать, во что они ввязались.
UI дизайнера там не было (еще чего!), в целом стиль был задан изначально (софт писала сторонняя фирма, но исходники в итоге отдали), свое дизайнили, конечно, тоже, разной степени страшности. В целом, с точки дизайна программа свои задачи выполняла, хоть и была здорово перегружена. Но мне лично не встречались нормальные дизайнеры, заказанные дизайны, например, внешнего сайта, заставляли испытывать испанский стыд, а книжки по дизайну, которые я пытался почитать, оказывались какой-то пустой водой, причем, очень протухшей.
Это не секрет. В Блендере все можно настроить при желании, только пока настроишь, задолбаешься. Выбор правой кнопкой от этого менее уебанским не становится. Там кроме этого хватало настроек, которые приходилось под себя часами настраивать. Да и сейчас еще хватает, но стало проще.
№ап ОгевИткоу
(срюгезИтксл/
Если в телеграмме послать в чат баклажан и потом на него тапнуть, то экран заляпает белым.
Если вам кажется, что вы на работе занимаетесь какой-то хуйнёй, то радуйтесь, что по-крайней мере вам не надо рисовать, программировать, тестировать или деплоить анимированную м
/* Isn't C a wonderful language? */ switch (mode) {
case 0: if (gloop(a, b)) {
case 1:
result = arfle(a, b) break;
} else {
;e 2:
result = barfle(a, b) break;
}
return (result)
Круговорот багов в коде
Костыль
Образование фич
Фичи
Океан багов
Испарение багов
Осадки фич в виде дождя
Подводные баги
Стокй через реки
Осадки фич в виде снега
Фичи
Фичи
* * ■ • • • • Подземные баги
• ш ■ *
Бороться с этим бесполезно. Упрощать себе во вред будут даже грамотные специалисты с хорошим высшим IT-образованием. отдельные фрики не считаются.
Единственный правильный способ - скорректировать работу с приложением и самостоятельно упростить его пускай и с негативными последствиями, но минимизируя их.
Невозможно предусмотреть уебанство пользователя, движимого ленью. И чем комплекснее программа, тем больше там мест, где пользователю захочется упростить.
По моему опыту любой корпоративный софт для внутреннего пользования - это избушка на курьих ножках, которая со временем превращается в многоэтажный пиздец с килотоннами легаси-кода.
Про UI вообще молчу. "Как надо", в корпоративном софте как правило означает "нахуй дизайнера UI, платить ему еще, без него справимся".
UI дизайнера там не было (еще чего!), в целом стиль был задан изначально (софт писала сторонняя фирма, но исходники в итоге отдали), свое дизайнили, конечно, тоже, разной степени страшности. В целом, с точки дизайна программа свои задачи выполняла, хоть и была здорово перегружена. Но мне лично не встречались нормальные дизайнеры, заказанные дизайны, например, внешнего сайта, заставляли испытывать испанский стыд, а книжки по дизайну, которые я пытался почитать, оказывались какой-то пустой водой, причем, очень протухшей.
Вообще, есть такая хрень UCD, ОПП по-русски.
https://en.wikipedia.org/wiki/User-centered_design
Все это очень сложно на самом деле. Толковых специалистов в этой области можно по пальцам пересчитать.
Вот сравнение. Было стало.
Более того, открою великую тайну...