Comments 230
Что-то уж больно далеко идущие выводы, видеть "кризис" в минорных недоработках - перебор даже для статей от "радужных" HR.
Так минорные недоработки - как раз следствие общего кризиса, когда все пишется "с нуля". В этом главная мысль.
Минорные недоработки - это лишь отсутствие этих пунктов в ТЗ на разработку продукта. Или отсутствие времени на их реализацию, когда имеются более приоритетные задачи.
Как Вы оценили, что это пишется "с нуля"? Почта мэйла - чуть ли не самая старая из существующих в России - думаете, они каждый раз её переписывают?
Да и Личный кабинет в Озоне существует не один год - предположу, что процесс доработок в нём у коллег отлажен
.. бюджета и порога сложности ...
Я не знаю, как там дела, но со стороны выглядит, что уж на такую доработку, которую Вы ожидаете, у компании есть и бюджеты и компетенции. Вполне может быть, что её намеренно не сделали (или даже сделали, а потом - удалили). Вам кажется, что это удобно, но как оно отражается на метриках - не очевидно
Вот, вы сами высказали это слово - бюджет.
каждая конторка пишет с нуля, нет кооперации. Нет общих библиотек, нет стандартов функционала. Про это я и пишу в статье.
Поэтому все сервисы, даже крупные, глобально недоделаны.
Вам кажется, что это удобно, но как оно отражается на метриках - не очевидно
Вот именно! Может кто-то в озоне решил (а может даже на АБ-тестах проверил) что введение поля "общая сумма заказов" ведет к уменьшению общей суммы заказов (вдруг внезапно покупатель увидит что поназаказывал всякой фигни выше крыши)
Так раскройте, в чем этот кризис состоит, я из статьи вижу только то, что 3 разных сервиса недоработали свой UI, может вследствие недостаточных тестов, может из-за отсутствия внятного фидбека, это везде такое можно найти, shit happens, как говорится. Вы в статье берете просто 3 рандомных своих жалобы (именно на то, что лично вам неудобно, но это не означает что оно так для всех), а затем накидываете тезисы что кто-то там куда-то бегает за модой и блаблабла, нытье нытье нытье. Так не работает, это просто ваше мироощущение, а не какая-то объективная реальность.
Все очень просто - нужно развивать информатику и функциональный стандарты на ее основе. И сертифицировать продукты по этим стандартам.
А там уж разработчики библиотек подсуетятся и сделают нужные библиотеки.
Банально - если есть список и действия с его элементом, значит я должен иметь возможность выделить нужные мне элементы и сделать действия последовательно с выбранными элементами, как пример. Все ли продукты пройдут такой простой функциональный тест?
Все очень просто - нужно развивать информатику и функциональный стандарты на ее основе. И сертифицировать продукты по этим стандартам.
О нет...
У нас будет российский стандарт, стандарт от Apple, Google... Стандарт от Apple к оформлению будет меняться каждый год с выходом новой OS....
Нафиг, нафиг.
Стандарт должен происходить из стен науки. И это просто проверка на функциональность. Вы же не против ISO и ГОСТов, когда речь идет о колбасе.
Стандарт должен происходить из стен науки.
О-о, похоже вы не были в стенах российской науки! Там есть "стандарты", есть. И исследования есть. И лучше бы вам их не смотреть, чтобы не получить травму...
Лучшие стандарты где-то в районе WiFi, USB... и там они, по-видимому, нужны, чтобы как-то примирять производителей друг с другом (которые, собственно, в комитете и сидят). ISO работает в части случаев, в части - не работает.
Вы же не против ГОСТов, когда речь идет о колбасе.
Безопасность здесь, тем более пищевая.
Я про функциональные стандарты.
Были такие в СССР касательно освещения, эргономики и т.п.
Наличие функциональных дыр в приложениях - следствие того, что эти стандарты не развиваются.
В итоге в супер-модном приложении вы должны тыкать по каждой строчке, вместо того, чтобы обработать их скопом. Это классика, в 2025 году повсеместно. С 1995 года не поменялось...
Информатика при смерти.
Были такие в СССР касательно освещения, эргономики
А ведь были, но, видимо секретные и необязательные. Уж что-что, а эргономикой СССР не страдал точно. Вывих плеча при переключении в шишиге - это и есть эргономический гост, или еще нет?
Были такие в СССР касательно освещения, эргономики и т.п.
например на ЖД в локомотивах считалось что кондиционер это буржуйские изыски, и летом когда на улице +35, в кабине было все +50
или компрессор воткнуть сразу за кабиной...и тугоухость у машинистов тепловозов это проф.заболевание... эргономика, да, стандарты
Когда кто-то толкает лозунги типа: должен!, пусть!, было бы правильно!, то он просто далек от реальности и никак на нее повлиять не может. Ну кроме как подписаться в своем бессилии таким вот высказыванием.
И не важно кто это говорит: анонимный пользователь на форуме или ЛПР по телевизору.
сертифицировать продукты по этим стандартам.
А там уж разработчики подсуетятся
Вот оно чё, Михалыч, вот оно чё.
Даже слов нет цензурных.
Правильно, нужен стандарт и реестр для него. Те кто его не соблюдают ждут штрафы и деградация серверов.
Нет, вообще нет.
Яндекс это большая организация, где полно команд, живущих своей жизнью. Небольшой косяк в одном из сервисов вообще ни о чём не говорит.
Мейл это сейчас кусок большого ВК
Озон живёт своей жизнью, причём тут wb?
У них есть свои признаки кризиса, но вы приводите мелочь
Повторюсь, раз вы не читали комментарии. Мелочи (функциональные дыры) - следствие большого функционального кризиса IT, когда не изучаются необходимые пользователям функции. А пишут "из головы"
А пишут "из головы"
я бы еще добавил - и сами потом этот продукт не используют
==
был у меня такой момент, там форму из 50 полей бахнули в одну колонку с прокруткой, в вебформе которая на стационарном компе отображается...на все возражения был один ответ "ну ниче, покрутят мышкой"...из 15 человек моей команды только я и один из разрабов были против такой концепции...я хз как это называется
нету на них информатики. Кстати, информатика как наука, вообще жива?
Есть исследования в разных областях computer science (у меня не поворачивается язык называть это "информатикой"). Один из их результатов - современные LLM.
Исследований UX тоже тонны.
Но где результаты этих исследований ИРЛ? Я захожу на сайты крупнейших контор и вижу "детские дыры".
Это как если увидеть офисного менеджера обкакавшегося на рецепшене.
и вижу "детские дыры".
Это ваше частное мнение, приятно вам это или нет (хотите закажем "академическое статистическое исследование"?). Куча других людей этих проблем не видит - значит, тратить ресурсы на их решение может быть нерентабельно.
Дык куча людей в том же США страдает ожирением и как бы не видит в этом проблемы.
Есть много проблем, которые люди не видят или смирились.
И это не значит, что мы должны продолжать жить в д..ме.
И это не значит, что мы должны продолжать жить в д..ме.
не живи, создай стандарт и заплати за его внедрение
все хотелки стоят денег, если всем плевать то никто деньги тратить не будет...демократия чёртеёвозьми
а при чем тут информатика? Вот вы так ловко манипулируете словом "наука", а сами при этом кроме субъективного ощущения ничего объяснить не можете.
Если дырка в UI - признак функционального кризиса в IT, то этот кризис расцвел вместе с появлением этого самого IT.
У вас в списке IT-продуктов есть выбор. Не нравится функционал X? Выберите Y. Мне вот никогда не нужно было знать общую сумму НЕСКОЛЬКИХ заказов.
Давайте я вам сейчас расскажу, какой 1С мусор неюзабельный, если он не умеет... (то, чего мне хотелось бы, чтобы он умел, просто потому что)
PS: кому в здравом уме вообще придет покупать подписку на шедеврум?
Давайте я вам сейчас расскажу, какой 1С мусор неюзабельный, если он не умеет... (то, чего мне хотелось бы, чтобы он умел, просто потому что)
В целом - согласен. Но, иногда бывают исключения. В одном продукте не было проверки времени. Это привело к уязвимости, я оформил CVE на уязвимость. Разработчик был не согласен и как раз использовал слова "я в шоке, что можно сказать - а вот оно так не умеет, давайте бахнем CVE". И даже пытался неудачно оспорить уязвимость (подробнее - в статье)
читайте мою прошлую статью про авторские права. В ее свете подписка за 100 рублей в месяц не такая уж и странная штука.
иногда субьективного чувства достаточно. 30 лет я занимаюсь IT и вижу одни и те же подходы к кодингу. Всегда с нуля, всегда с чистого листа, всегда кнопочки рисуем сами.
Упущенные десятилетия.
Кризис — это переломный, критический момент в развитии системы (будь то человек, общество или экономика), когда существующие методы решения проблем становятся неадекватными, и возникают нестабильные, опасные ситуации. Это состояние характеризуется резким изменением, нарушением равновесия и необходимостью перехода к новому качеству.
Мне кажется, что Вы не правильно используете слово кризис.
Причина ее в том, что решения пишутся с нуля.
потому что так дешевле, чем поддерживать имеющийся функционал
я вообще всеми руками за унификацию, но я прям очевидно вижу противодействие такому подходу почти на всех уровнях, от аналитиков до рядовых разработчиков
Был у меня пара проектов год назад, довольно схожие по UI и некоторой логике, я в итоге запилил там либу которая полностью отрисовывает интерфейс и мы выкинули 90% кода который в этих трех проектах дублировался... это очень тяжело далось, аналитики меня буквально на коленях убеждали так не делать со словами что "унификация ограничивает функционал"...при этом никто из них не мог объяснить как мне тянуть поддержку десятка разных костылей и что делать если еще один проект появится, тратить 100500 часов чтобы очередной код сортировки списка товаров сделать c нуля?
у нас кризис сеньоров в проектах, их тупо нет, всё делают дилетанты какието
вот, эту проблему я и подсветил. Графические интерфейсы я начал щупать студентом в 1995 году еще, с тех пор ничего не изменилось. Все пишут с полного функционального нуля. Поэтому и проколы в функционале, поэтому и приложения удовлетворяют только "среднего по больнице" пользователя.
Для конкретной разработки дешевле, для отрасли в целом и общества - беда и кризис.
Любое приложение получается неполноценным.
Приложения удовлетворяют только "среднего по больнице" пользователя не потому, что кто-то пишет так или иначе, а потому, что так работает бизнес. Потому что бизнес ориентирован именно на "среднего по больнице" пользователя. Если гоняться за реализацией каждой хотелки каждого клиента - денег не заработать. Вы же не готовы платить из своего кармана не только за то, что компания закроет лично ваши неудобства в UI/UX, но и каждого, кому неудобно расположение кнопок или не в то меню выведена цифра? Я вот не готов. А кто платить будет?
Фантазии про "если сделать унифицированные библиотеки, всё будет работать у всех и для всех" стоит оставить там, где им место - в начальных классах школы. Невозможно написать библиотеку, которая из коробки удовлетворит одновременно и потребности сервиса А, и потребности сервиса Б. Всё в любом случае придётся переписывать, перерабатывать и адаптировать. И выйдет это дольше, дороже и с куда большим количеством ошибок, что отразится как на стоимости конечного продукта, так и на его качестве.
Не чините то, что не сломано, особенно когда не понимаете, как оно работает. И не считайте себя умнее целой отрасли.
Мне кажется там ПСТР от четвертьвекового опыта работы с 1С.
Вот где единый интерфейс, универсальные библиотеки и все стандартизировано))
/s вот прямо не смог удержаться, извините))
а вы пробовали, что заявляете про невозможное?
как там? Невозожно - это лишь слово. Невозможно - это не навсегда.
В общем, Ваша позиция понятна. Люди в средние века тоже считали что невозможно летать и зачем машины, если есть лошади.
Вы даже не допускаете мысли, что возможны функциональные библиотеки для интерфейса. А с чего вы это взяли? Ах, бест практицес от инженеров и бизнеса, не нюхавших науки.
Конечно, пробовал. Любой разработчик рано или поздно сталкивается с желанием унифицировать и стандартизировать "всё" в рамках хотя бы кодовой базы одного своего проекта. И да - это не работает начиная с той точки, где требуется внести куда-то новую функцию. Даже на уровне пары компонентов - работает только до этого момента. И приходим всё к тем же "велосипедам", только потратив сперва впустую энное количество человекочасов на разработку нерабочих стандартов и "модулей для всего".
Думаете, вам первому в голову такая блестящая идея пришла? Вынужден огорчить. И не реализуется она не потому, что все ленивые и с устаревшим мышлением (вот вся отрасль прямо, системный кризис, только один человек в белом пальто на хабр статью написал!), а потому, что сталкивается с реальностью и этого столкновения не выдерживает.
Нюхать науку можете сколько угодно, только вот сильно подозреваю, что действительно научное обоснование своим идеям вы сами и не напишете, чтобы по всем методологиям, чтобы бери бизнес и ориентируйся, чтобы разработчик взял и сделал по четким правилам, максимум научности, который в формулировании этой идеи доступен - "мне неудобно, что у вас на сайте нет полезной мне метрики, хочу чтобы переделали".
Иначе бы вы взяли и написали не буквально это самое в статью, обреченную на минусы, а желаемую вами научную бумагу, от которой был бы толк.
для отрасли в целом и общества - беда и кризис.
Вы свое субъективное не выдавайте пожалуйста за все общество и за всю отрасль.
Ни одну из подсвеченных вами проблем - я не считаю проблемой. И да - я так же считаю, что интерфейсы и подходы к их реализации с 95 года изменились очень сильно, и если вы считаете иначе, то вы в них совершенно ничего не смыслите. Вы застряли в прошлом веке, и пытаетесь подходить к анализу современных ИС со своим, абсолютно устаревшим (еще в нулевые) опытом.
Стоит различать кризис и зажравшийся пох.изм. При отсутствии конкуренции, все чаще происходит "и так сойдет"
даже если исключить зажратость, на текущем уровне сделать лучше не смогли бы. Ибо нет базы... все с нуля.
Ну, я не пишу с нуля - пишу на кодовой базе, которую развиваю уже 20 лет. Все удобно, все под рукой, быстро работает (потому что оптимизировано под хостинги 2008 года).
Из минусов:
1. для больших команд, я так понимаю, это не интересно, потому что каждый приходит со своим знанием React (фронта) и свистоплюшек PHP 8+. Формально у меня легаси с оригинальной архитектурой, такое мало кому интересно.
2. На SPA и мобилках это работает с небольшим скрипом, т.к. не было тогда таких парадигм.
я не про кодовую базу. у вас есть база пользвоательского функционала, вылизываемая 20 лет?
причем там не нужно большого быстродействия, пользователь работает очень медленно по сравнению с компьютером.
у вас есть база пользвоательского функционала, вылизываемая 20 лет?
Да, кодовая + пользовательского.
Вылизываю я правда, лениво, но да - куча вещей сделано удобно (для меня). Например, генерируется CRUD-интерфейс по таблице в БД, сделал еще в 2008, с тех пор пользуюсь. И там массовых операций, увы, тоже нет - пользуюсь я ими слишком редко, а делать качественную реализацию тяжко.
Кстати, идеальная база "пользовательского функционала" - командная строка Linux, там вылизывается все очень долго. Правда да, это не визуальный интерфейс для обычных пользователей.
да, и где же результаты вашего труда ИРЛ?
Какое приложение не открой - везде функциональные дыры.
Видимо, вы переоцениваете свое влияние на мир.
Не понял, с чего такие "наезды"? У вас, что ли есть значимый личный результат ИРЛ? Или вы будете бегать по Хабру и интернету со словами "все пропало", и еще критиковать тех, кто что-то делает? И заодно молиться на абстрактную "науку", к которой вы реального отношения, видимо, не имеете, а то не упоминали бы ее как аргумент, ей-богу.
я сюда не причиндалами меряться пришел, извините. У меня за IT душа болит. Я о другом.
У меня за IT душа болит
Почему то напомнило:

Утром мажу бутерброд -
Сразу мысль: а как народ?
И икра не лезет в горло,
И компот не льется в рот!
я родом из СССР, да
Я тоже, но в данном случае это отягчающее обстоятельство, потому что вы понятия не имеете, о чём говорите, но считаете, что самый умный.
Вам можно было бы дать развёрнутый ответ про AB-тесты, дизайнеров, аналитиков и продакт оунеров, а также о том, как эти ребята подходят к изменениям в интерфейсе, но зачем? Вы выдадите какой-нибудь глубокомысленный комментарий про говно и средневековье и всё равно не попытаетесь понять, что вам там пишут.
Вы еще не вспомнили не работающие сортировки и фильтры в яндекс маркете :)
Это точно маркетинг. Как иначе подсовывать спонсорские товары и рекламу, если человек сразу будет находить что ему нужно по лучшей цене и уходить?
ну, пример "кризиса маркетинга" с Шедеврумом я привел в тексте, спасибо и за Ваш пример.
Я.Маркет огромная помойка. Раньше хоть отзывы можно было почить и описание.
При поиске в гуголе скажем WD SN730 я обхожу две ссылки это OZON и Я.Маркет. Просто потому что в 100% это чистый развод, что бы я кликнул на ссылку, а есть там товар или нет его, всем пофигу.
Вот сейчас я кликнул по OZON ииии "По этим фильтрам ничего не нашлось" в Маркете открылось окно с кучей SSD вообще никак не относящимся к моему поиску.
ну это к теме не относится, но вынужден констатировать, что Яндекс Маркет идет по пути махинаций Ali Express.
Если Вы про aliexpress.ru то это mail.ru, а сами знаете во что превращается всё к чему они прикоснулись.
А что далеко ходить, можно вспомнить поиск в озоне, который работает только в варианте "по популярности" а по стоимости/отзывам показывает что угодно, но только не релевантные поиску карточки.
А так же озоновскую же сортировку по стоимости, которая сортирует по "изначальной" а не конечной цене, в итоге получаем сортировку вида "100, 90, 500, 120, 80, 900"
Кто вам вообще сказал что что-то пишется с нуля? На некоторых направлениях без фреимворков даже резюме ваше не смотрят
фреймворк это не совсем то
фильтры в интернет магазинах и суммы товаров из примеров, к фреймворкам отношения вообще не имеют
я про "функциональный ноль".
как там - расставляются кнопочки на форме "фильтровать, сортировать", пишется код под них.
А при функионально полной библиотеки эти кнопочки должны рисоваться сами, т.к. отображаемые данные порождают функциональность.
В веб-разработке все еще хуже...
такое поведение (с фильтрами и сортировкой) не всегда очевидно с точки зрения её реализации в автоматическом режиме
у меня была либа которая отрисовывала так интерфейс и были части системы где фильтры и сортировки были практически везде отключены, потому что их фактическая реализация была крайне сложная и тормозная, потому что данные по котором надо сортировать - это не просто таблица в БД, а очень громоздкая связка из разных сервисов неочевидно друг с другом связанных
А пользователя беспокоят Ваши проблемы? Есть функциональный стандарт, хотите "пять звезд" - напрягитесь. Отелям может тоже не нужны факсы, но без них 5 звезд не дают...
Зато человек знает, чего ожидать.
А все эти софтины они и на одну звезду не натягивают по количеству функциональных дыр.
А пользователя беспокоят Ваши проблемы?
а скольким пользователям важны эти фильтры?
тут какбы такая штука что если 95% юзеров этот фукнционал не используют - его можно не делать, а оставшиеся 5% никуда с подводной лодки не денутся
А все эти софтины они и на одну звезду не натягивают по количеству функциональных дыр
ну вы продолжите жрать кактус. потому что у нас всего три маркетплейста, вам деваться некуда
Вот. Я Вам за себя скажу, как программист.
У меня, как и у многих программистов, есть чувство перфекционизма.
На этом строится весь опенсорс, когда записываются пожелания и делаются доработки.
Но понятно, что разовую поделку никто вылизывать не будет.
А вот функциональную библиотеку - ее бы вылизали до блеска.
И разработчику нужно было бы только обновить библиотеку, чтобы реализовать "минорные" хотелки пользователя.
Но т.к. нет науки информатики, нет кооперации, каждый играет на своем баяне и оптимизировать отдельный баян нет никакого смысла.
перфекционизм это хорошо, но сервис это не про перфекционизм и не для программистов
он про бабки и конверсию лидов
если 95% юзеров пользуются и приносят деньги - всё норм
Поверьте - с возрастом префекциоизм притупляется естественным образом. Просто со временем понимаешь, что времени чтобы что метать бисер осталось совсем немного. И есть намного более важнее вещи, нежели осчастливить человечество или доказать кому-то на форуме свою правоту. Никто не оценит..
А Вы точно не путаете кризис в ИТ с пиком черных технологий в маркетинге? В озоне не видя общую сумму человек пополнит с запасом кошелек. В маил.ру больше проведет времени смотря рекламу пока сделает что ему надо. И т.д.
Во всех этих случаях наблюдается общая тенденция. Причина ее в том, что решения пишутся с нуля.
Ага, сначала на хабре плодятся статьи (поддерживаемые профи) вида "как мы за 5 дней ловко переписали основную часть сервиса с устаревшего пхп на продвинутейший гоу не зная гоу", а потом начинаются жалобы что решения написаны с нуля и зачем это надо:)
В итоге приложения реализуют только базовые потребности пользователей, а оставшиеся 20-50% функциональных потребностей пользователей остаются не удовлетворенными.
Это может легко объяснятся паретто. Базу реализовать легко, а вот дальше начинается рост сложности, в том числе из-за роста связности. Одно дело написать 3 базовые независимые функции и отладить их на 5 пользователях, другое дело добавить к ним 7 сложных взаимозависимых функций без результата вида "наташа вставай мы все уронили" на рабочем проекте.
не стоит видеть сложное в простом.
В той же почте - функции, необходимые для работы с письмами, можно сформировать за неделю работы аналитика, можно скомпилировать их из best-practicies. Но этого не делает ни наука информатика, ни частный сектор.
В итоге все почтовые системы недоделаны, но в каждой пробел в чем-то своем.
"Если бы нос Ивана Петровича к глазам Сидора Васильевича"
не стоит видеть сложное в простом.
Самое простое объяснение какого-то явления в коммерческом продукте - выгодность этого явления.
А вот выделять для объяснения причин сначала ИТ департамент, потом его уровень, потом способ разработки - это как раз сложно.
В той же почте - функции, необходимые для работы с письмами, можно сформировать за неделю работы аналитика, можно скомпилировать их из best-practicies. Но этого не делает ни наука информатика, ни частный сектор.
А сделать технику ломающейся не после окончания гарантийного срока, а работающей десятилетия это не просто можно, это уже было. Но ... сейчас такого не делает никто.
Раньше и на луну "якобы" летали. Я не про это.
А про то, что сделать приложение функционально полным без накопленной базы знаний не получится.
Поэтому мы все вынуждены пользоваться поделками. И в ближайшую пятилетку никаких изменений этого не вижу. Потому и алармирую в набат.
Не хочется снова и снова кушать не прожаренные сырые приложения.
сделать приложение функционально полным без накопленной базы знаний не получится.
Первопричина без которой его не получится сделать функциональным - отсутствие задачи у бизнеса сделать его функциональным. Остальное - следствие.
Не хочется снова и снова кушать не прожаренные сырые приложения.
Формат блогов, в частности хабра, это чисто маркетологическая фича со специально зарезанным функционалом. И ничего, лет 15 уже кушают массово, а другие форматы почти вымерли. И заметьте, Вы при всей своей критики в адрес озона - про тот же полный функционал хабра ни слова ни говорите... потому что просто привыкли и приспособились или по какой причине?
В том, что сайт пишется с нуля нет ничего плохого. Плохо то, как его пишут.
Что у озона, что у вб абсолютно неюзабельные приложения, где в карточке товара находится только реклама других товаров. А отзывы и оценки это маленькая скромная кнопка, которую попробуй найди ещё.
Да, наверно в совокупности с другими факторами это можно назвать кризисом, но точно не из-за того что сервис создан с нуля
Общая сумма заказов в озоне отображается возле штрихкода, который вы показываете сотруднику.
Не знаю правда как давно добавили
Не, не отображается. Да и вопрос я задавал неделю назад, вряд ли подсуетились.
Да и неважно это. Само наличие подобных функциональных дыр говорит о кризисе реализации функциональности над данными в IT
Буквально вчера получал.
Под штрихкодом (который общий, с главной страницы приложения) есть список товаров с ценой каждого, плюс над списком общая сумма.
Само наличие таких дыр говорит о банальных косяках, как и везде. Возьмите Apple/Google - я им о таких багах сообщал, что кажется невозможно такое не заметить. Все крупные компании - это концентрат багов и мелких проблем.
у меня нету в приложении под андроид. Может вы яблочный?
Само наличие этих дыр говорит об отсутствии фундамента. Когда дом строят на песке.
Но все уже настолько привыкли к этому, что пользовательская лягушка сварилась и не задает вопросов.
Бизнес не хочет вкладываться в науку, потому что пользователи-терпилы и так все схавают.
Да, на iOS.
Ну что поделать, бедная компания Озон ))
Бедная не компания Озон, а бедные мы.
Информатика умерла и мы пользуемся ее плодами 30-летней давности, не продвинувшись далее. За 30 лет можно было сделать много. Но сделано ни-че-го.
Вот опять же - один и тот же функционал на ИОС и Андроиде реализован по-разному. Наглядно.
За 30 лет можно было сделать много. Но сделано ни-че-го.
да ответ прост, ты лично готов за это заплатить? другие люди готовы за это заплатить? есть смысл это делать? принесет это дополнительные деньги?
друже, а за ГОСТЫ и ISO люди хотели заплатить?
А пользуются с удовольствием.
Это не люди должны решать, а государство и бизнес.
Бизнесу в конечном итоге это будет выгодно - не нужно каждый раз будет изобретать велосипед.
Но без науки бизнес это не сможет. Так и будем велосипедировать еще 30 лет. Еще 30 упущенных лет. А что, бабло пилится, всем хорошо.
В навозе тепло и уютно.
воу воу, вот не хватало нам госстандартов на интерфейсы в ПО
ГОСТ и ISO нужны там где важна безопасность, например в транспорте, пищевой промышленности, инфраструктуре
госрегуляция в интерфейсах ПО это блин квадратногнездовое мышление и вечное застревание потому что изменение госта никто согласовать не сможет годами
==
Конечно есть приятный пример стандартизации зарядок у телефонов, но там уши растут не в удобстве, а в монополизме и вытекающим из него проблем в т.ч. в экологию и т.п.
Вы зря опасаетесь стандартов на интерфейсы. Если вы помните рунет начального периода, где были в моде креативные мигающие надписи и расцветка вырвиглаз, то постепенно все перешло в другие тона, цвета и формы.
Чтобы пользователю было привычно на сайтах. В этом суть стандартов. Они не умаляют креативности, но креативность нужна не везде.
Вы же не ожидаете креативности от водителя автобуса или такси. Вам надо ехать (с шашечками или без).
А почему WB показывает?
Не понял о чем вы.
Я иду забирать товар, выдают мне его весь. Сколько мне нужно за него заплатить?
А почему WB показывает?
а он тоже некорректно показывает, если мы уж начали в частности
допустим у вас в заказе есть три товара
1) 100р не оплачен
2) 100р оплачен рассрочкой
3) 100р оплачен при заказе
= и 15р у вас лежит на кошельке
Итог 300р, и вам его назовут в ПВЗ со словами "сумма 300р, списываем"
вопрос - сколько у вас спишут с карты когда вы заберете заказ? (еще факультативный вопрос для ВБ - с какой именно карты если их несколько)
ответ - 85 рублей, и с той карты которую вы указали в заказе п.1, а не с той которая стоит "по умолчанию"..ноэтонеточно (одной Ким известно откуда будет точно)
В веб версии вообще нет штриха, только номер. К сожалению в мире где живут разработчики "веб версии" QR библиотеки ещё не изобрели.
И после этого мне рассказывают о бурном расцвете Айти, где программисты на самом деле прозябают в жутчайшем 30-летнем застое. ООП было и в 1995-м, где плоды?
Ну почему же. В веб-версии для мобильного очень даже есть. Для ПК нет, что в общем-то логично. Общая сумма заказа там, кстати, тоже указывается.
штрих был в веб версии, потом убрали что бы на приложение пересаживать.
Я тупо по номеру штрих генерил ботом и всё.
Я конечно понимаю, что автор 1с разработчик, где нет модульности и есть монополия одной компании с присущим этому уровнем кривизны, но называть такие "недоработки" кризисом очень громко. У каждой компании миллиард своих внутренних сервисов и библиотек, которые пишутся не от хорошей жизни, а потому что должны удовлетворять каким-то условиям, причем для всех они чаще всего индивидуальны (разные уровни нагрузки, отклика, хранения и т.д.). Получить идеальный инструмент под свою разработку, который ещё не будет рандомно апдейтится в неподходящий момент и не зависит от миллиона других независимых кусков - это ли не счастье разработчика?
Я в целом себе слабо представляю госты по интерфейсам, там будут проценты vue и react оцениваться, как свинина и говядина в составе колбасы? Или верстание только div? Они будут очень субъективными и отражать взгляд пишущего, а не "правильность" (если она вообще есть в случае визуала). И при этом это не даёт гарантии, что продукты из одного ГОСТ-а будут одинаковы по качеству (как пример, что скоро шоколад с 5% шоколадосодержания будет считаться продуктом одной категории с 25% шоколадом, хотя разница очевидна даже без изучения). Я нашел самый слуховой пример, но думаю если порыться - можно найти много абсурда.
И даже если неожиданно выпустят "общий гост по шакалоинтерфейсам", что это поменяет? Всё не станет работать одинаково хорошо, всё будет работать одинаково плохо, потому что люди склонны ошибаться, а какие-то вещи имеют чисто субъективное восприятие без единого правильного пути. Я бы лучше подстёгивал их конкуренцию рублем, чтобы они делали свои продукты лучше, чем убивал её наглухо. Не нравится вам что-то в продукте - платите за другой, который вас устраивает. Слабые скопытятся, хорошие станут улучшаться. Когда хорошие перестанут улучшаться - их нагонит новый конкурент. А монополия останет продукт на одном месте, где они могут мутить любую чушь и ничего им не сделаешь, потому что они прописаны как обязательное использование на вашем складке на территории нашей страны.
Стандарты пишутся, чтобы все работало хорошо.
Не вижу ничего плохого в переводе разъема лайтинга на тайп-си например.
Мы будем ожидать от приложений определенного уровня.
А то даже у крупных разработчиков получаешь поделку студенческого уровня с множеством не закрытых дыр функционала.
Не, ну если им будет нравиться мусорный рейтинг Омега у приложения, пусть выпускают с таким рейтингом.
Но я думаю при наличии таких стандартов быстро появятся библиотеки, их реализующие.
Что сложного в том, что я написал?
Это не может выявить тестировщик? На эту тему нельзя написать список требуемых функций?
Может этот список изложен в каком-то разделе информатики? Нет.
Пользователь и так схавает, бизнесу наука не интересна.
Поэтому мы до сих пор ездим на велосипедах. И надеяться что придет Форд и подарит нам автомобиль, нельзя. Без развития науки инженеры от бизнеса не прыгнут выше головы.
Есть вещи, которые осмысливаются практиками только после того, как их осмыслят теоретики. А без этого практики их даже не видят. Им и так хорошо. Бабло же течет.
Стандарты пишутся, чтобы все работало хорошо.
Не вижу ничего плохого в переводе разъема лайтинга на тайп-си например.
Вам на это уже указывали, но есть определённая разница между ГОСТ-ами на физ устройства и ГОСТ-ами на ПО. Физическое устройство можно обсчитать, вывести нужное и зафиксировать. Строгая регламентация имеет смысл там, где идет разговор не об удобстве, а о большем - безопасности, здоровье и т.д. Одно дело это регулировать, что человеку в организм попадет или загорится ли провод, пока он спит и другое когда вас возмущает отсутствие одной подписи.Да, это не гарантирует, что этот же ГОСТ кто-то просто пропихивает себе в угоду, как снижение на 20% содержания шоколада в шоколадках (с 25 до 5). Без этого получится, что всем надо делать "плохо, но по госту", даже если хочется сделать хорошо. Зачем делать рамки там, где не надо? Ваш пример с зарядками как раз про то, где вмешались там, где надо, потому что это по всем пунктам экономически целесообразно, безопаснее (меньше паленых проводов и монополии с выкрученными ценами, которая толкает покупать б/у или некачественное) и легче тестируется. Чем вам одинаковые интерфейсы везде помогут в этих целях, кроме как обучать верстальщиков однообразнее?
Повторю свой же вопрос - а что вы будете в интерфейсах считать, чтобы оно "подходило под госты" - процент js-фреймворков и количество div-ов на один html-документ? А даже если и придумают, то не удивлюсь, что это будут одинаковые кубические формы с разными цветами и логотипами. ИМХО, это даже звучит глупо.
А то даже у крупных разработчиков получаешь поделку студенческого уровня с множеством не закрытых дыр функционала.
Это даже звучит некорректно и грубо. Напишите тогда аналог mail-почты,маркетплейса и генератора картинок ,утрёте всем большим тех компаниям и людям из комментариев нос. А вообще количество функционала != качеству, делать из приложения огромную платформенную помойку ведёт к успеху в единичных случаях и чаще всего насильственно. В идеальном мире продукт из какой-то экосистемы должен нормально работать в отрыве от неё, но хорошо стыковаться с другими продуктами экосистемы при необходимости.
Это не может выявить тестировщик? На эту тему нельзя написать список требуемых функций?
А при чем тут тестировщики? У тестирования вполне конкретная задача - протестировать СУЩЕСТВУЮЩИЙ функционал на предмет работы и внесённые изменения, чтобы они не нарушили поведения. У вас все три случая "претензий" - это то, что не было сделано. Что вы хотите протестировать, если этого не существует ¯\_(ツ)_/¯?
Опять же, как разработчики того же Шедеврума должны заранее узнать, какие функции на все 100% понадобятся их пользователям? Вы пишите про какие-то 20-50% неудовлетворенности, как вы их высчитывали и измеряли? Почему вообще эта функция нужна в таком сервисе? Есть ли какая-то ли реальная ценность в вводе такой функции, если её больше нигде нет? У любого ПО/сайта/разработки есть ТЗ, которое согласуется задолго до всего этого. Если вы чего-то не видите, то на тот момент это не посчитали нужным, вот и всё. Поэтому да, на приложение как-то невозможно написать полный и исчерпывающий список требуемых функций. Вы выдаёте продукт и дорабатываете его, причем анализируя - нужна ли эта доработка и нет.
Поэтому мы до сих пор ездим на велосипедах. И надеяться что придет Форд и подарит нам автомобиль, нельзя.
В моей реальности уже есть автомобили, которые даже без человека ездят. Придумали как-то без ГОСТ-а на создание беспилотных автомобилей, удивительно. И наверно сам Форд тоже не слышал про ГОСТ-ы для машин или научные исследования на тему создания машины, вероятнее всего ¯\_(ツ)_/¯.
Есть вещи, которые осмысливаются практиками только после того, как их осмыслят теоретики. А без этого практики их даже не видят. Им и так хорошо. Бабло же течет.
Я искренне не понимаю, зачем вы приплетаете сюда то, что называете "наукой" и "информатикой", особенно в контексте визуальных интерфейсов в двух случаях из трех. Ученые сначала должны разработать "Стандарт,интерфейс и используемые функции в приложении-почте", а только потом бизнес получит право писать подобное ПО? Мне интересно, какая тут должна быть глубинная теория, кроме фактической выдачи продукта пользователю и доработки его на основе фидбека/конкурентов/баг репортой. И так примерно со всеми подобными коммерческими продуктами, для интернет магазина не надо научное обоснование - только здравый смысл и хотелки пользователей.
Инновации это способ развития и перехвата первенства, но это симбиоз бизнеса и науки. Бизнес без инноваций отстанет от бизнеса без инноваций, наука без бизнеса это бесполезное марание бумаги, а наука с бизнесом - знание, применяемое на практике. Практические технологии и научное знание двигают все вперёд только вместе, а не когда одно пинает другое (за этот простой вывод в этом году дали нобелевку по экономике). Поэтому ваше утверждение это как минимум заблуждение, особенно на фоне того, как тот же Яндекс вкладывается в науку и обучение кадров.
У меня всё больше складывается ощущение, что примеры статьи и последующие выводы это нестыкующиеся вещи, а попытка выдать придирки за какую-то глобальную проблему, которой в айти не существует - компании в целом прямо заинтересованы в удовлетворении юзеров и развитии, т.к у нас нет монополии одного тех гиганта. У айти есть кризис найма, кризис деградации производительности и перехода на облачность, потенциальный кризис ии-пузыря (если они не начнут делать прибыль), но никак уж не кризис стандартизации.
Пример одной стандартизированной платформы, где даже формочки ввода дефолтные, уже показал нам, что это легкий способ повиснуть на гос шее и мешать людям делать удобные для них вещи, потому что (вот неожиданно) у бизнеса есть специфика, которую стандарты могут не покрыть.
То, что вы хотите (заставить всех грести писать под одну гребенку) не сложно. Сложно будет потом писать нормальное ПО, которое будет помогать людям, а не мешать им. И научное обоснование чего-то тут наврятли поможет.
Я приводил пример со списками. Везде где есть список нужно давать возможность выполнить операцию над выделенными элементами, как над одним.
Чем лично Вам претит этот функциональный стандарт? Как он Вам помешает жить? Как будет умалять Вашу креативность. Расскажите, я послушаю.
А теперь сходите в те приложения, которые вы используете, и проверьте на соответствие этому стандарту. Поплачьте.
Или возможность сохранить текущий выведенный на экране список в файл, а не скриншотить. Чем плохо?
Чем лично Вам претит этот функциональный стандарт? Как он Вам помешает жить? Как будет умалять Вашу креативность. Расскажите, я послушаю.
если не требовать стандарт соблюдать - ничего не поменяется, просто будет +ещеодинникомуненужный стандарт, всё.
если его требовать соблюдать - на бизнес свалится куча затрат которые ему не нужны, ради чего? я бы лучше был за то чтобы софт писали такойже эффективный как в 80х-90х, а не как сейчас, веб форма на 10 полей с табличкой весит больше чем Windows NT4 вместе с пинболлом внутри....и при этом тормозит на 4ядерном процессоре и 8 гигабайтах оперативки. а NT4 летала на 200mmx и 64 мегабайтах...и в пинболл поиграть можно было
вот за такой стандарт я бы проголосовал ;)
Вы смотрите с позиции бизнеса, потому что бизнес не умеет делать библиотеки и пишет с нуля.
Если это будет не запретительный стандарт, а правилом приличия, то бизнес скооперируется и напишет библиотеки, где будут такие стандарты разработки.
Вы слишком привязаны к текущему состоянию дел, поэтому плачете про бизнес.
Нет, я рассказываю, как должно быть, а вы аппелируете к тому как есть.
Конечно, если пытаться жить как есть, то будете жить как сейчас. Лучше само по себе не станет.
Я за рейтинговую систему. Не реализовал стандарты - получай мусорный рейтинг, зато дешево и сердито.
Думаю, разработчики быстро подтянут инструменты, чтобы там функциональность поддерживалась.
И кодить будет легче. Нужно будет кодить функции, а не кнопки.
Это на самом деле win-win
бизнес не умеет делать библиотеки
React (facebook), Angular (google), Spring Framework (vmware) - это только то, что сходу вспомнилось и при этом промышленные стандарты.
Действительно, не умеет.
Если это будет не запретительный стандарт
То никто даже не по чешется. У крупных бизнесов из вашей статьи - бэклог на пол года вперед и техдолга столько же. Какие-то бесполезные дополнительные задачи им не нужны.
Нет, я рассказываю, как должно быть
Кто девушку кормит тот её и танцует. Голосуйте рублем за платформу где нужные функции есть, где нет - не голосуйте.
Конечно, если пытаться жить как есть, то будете жить как сейчас
Достаточно пройти посмотреть интерфейс сайтов из веб-архива, чтобы понять какой колоссальный прогресс был достигнут. Маркетплейсе грызут друг другу шеи за каждый пользовательский клик. А аналитики неустанно чешут репу и смотрят тепловые карты, чтобы понять, где у пользователей затык.
Я за рейтинговую систему. Не реализовал стандарты - получай мусорный рейтинг, зато дешево и сердито.
Ну идея положена - открывайте сайт, введите там рейтинг, многие так делают. Ifixit какой нибудь и rotten tomatos.
И кодить будет легче. Нужно будет кодить функции, а не кнопки.
Приложения собирают из готовых кирпичей - есть маленькие (html/css для веба, winForms для windows, uikit для ios, на Андроиде стандартная библиотека компонентов), есть по больше - компоненты в react, сложные ui блоки типо recyclerView в android, есть огромные - готовые конструкторы как тильда, битрикс, wordpress.
Гибкости первых хватает в 99% случаев, вторых в 70% третьих в 20%. Чем больше кирпич, тем меньше вариаций из него можно построить и сложнее из него строить детали.
Ваши кирпичи где-то между больших и гигантских - их применимость крайне сомнительна. Я не хочу затаскивать и встраивать в проект, настраивать и разворачивать автобус, ради того, чтобы была возможность включить радио. Даже страх оказаться в мусорном рейтинге на каком нибудь сайте скорее всего не сподвигнет меня выбрать автобус а не отдельное радио.
я про функциональные библиотеки, а не библиотеки кода.
Вы видимо, не поняли о чем статья.
Просто информатика не озадачилась функциональными кирпичами и за 30 лет инженеры и бизнес не продвинулись дальше полировки языков программирования.
То есть встроенные sort/min/max/reduse/filter/fold/add/remove/move и ещё масса готовых методов в языках и библиотеках, для работы с коллекциями, математикой, абстракциями разных объектов? Или вы говорите на каком-то своем языке, где функциональная библиотека - это что-то отличное от общепринятого понятия?
я говорю о функционале пользователя, а не о библиотеке функций программиста. Думаю, если вы читали статью, это очевидно.
функционале пользователя
Мы можем сыграть с вами в игру.
Т.к. ваш "подход" к функционалу пользователя оторван от контекста (вы говорите про некие функциональные библиотеки применимые во всех случах жизни, так еще и чуть-ли не сертефицированные для обязательного использования)
То мы возьмем текстовое поле. Абстрактное текстовое поле - которое может быть где угодно - как полагается оторванной от контекста части интерфейса имеющей фукнциональные возможности для пользователя.
Вы мне перечислетие согласно своему подходу функциональные требования к тектовому полю - а я буду открывать все текстовые редакторы, редакторы кода, сайты, специфические программы и прочее, где есть текстовые поля, и наваливать вам дополнительных требований потому что в моём сценарии использтвания ваше текстовое поле становится неприменимо т.к. оно не умеет форматировать текст, не умеет в интуитивную постановку надрстрочных и подстрочных, не умеет все цвета радуги и бегущую строку, не умеет автоматически заменять все строчные на заглавные, не умеет озвучивать текст для слепых и переводить на хинди для говорящих только на хинди. и т.д.
Или можем вернуться к спискам, которые вам так непонравлись судя по статье. Я начну требовать включить в функциональные требования - каскадизацию, обновление в реальном времени, сортировку на основе данных которых обновляются в реальном времени, возможность вкладывать элементы один в другой как матрешку, менять отображение со списка на плитку, с плитки на точки на сфере, строить из элементов связный граф на основе любого поля из данных и прочие восхитительные и несомненно нужные вещи.
И сколько бы времени вы не потратили - не сомневайтесь - найдется еще одна фича, которую вы не учли в функциональных требованиях, а значит они не применимы, ведь я смогу так-же как вы в статье прийти и сказать - фи, что это за дерьмоинтерфейс, который не умеет сортировать список по всем критериям где важность критерия в сотритровке задается его алфавитным порядком - идустрия в кризисе.
есть не корректность. Вы оцениваете объект вне контекста.
Если уж вы взялись описывать функциональность объектов в пользовательском интерфейсе, исследуйте все возможные сочетания. Т.е. когда поле в списке, то же текстовое.
Какие бывают списки. Какие операции над ним и т.п.
Лучше 5 лет попотеть, зато потом просто вставить элемент и он сразу задышит.
Тяжело? Понимаю. Это задача не для инженера, а для ученого.
Ну вот про реально существующий кризис производительности я писал автору, что с современными мощностями многие забивают на оптимизацию, потому что 32гб оперативы хватит. Но это проблема уже современного мира, а точнее гонки релизов и "сделать первыми", тут ничего не сделаешь никакими стандартами. А то, что продвигается автором статьи - это просто бумагомарание, которое ещё приведёт к отрицательному результату - все будет выглядеть одинаково безлико и перегружено, даже если это не нужно ни пользователю ни бизнесу.
Особенно смешно про библиотеки, когда почти лучшее из опенсорса либо открытое проприетарное, либо разрабатывается программистами крупным компаний)))
Сложно налить воду в полную чашу, подумал я, увидев ваш ответ. Вы просто привыкли так. Как есть сейчас, мне не надо рассказывать. Но это не значит, что то, что сложилось, здраво и разумно. Это серьезный кризис.
Не знаю,у кого чаша полная,раз вы уклоняетесь от ответа на вопрос,зачем есть необходимость вводить обязательный функционал с риском избыточности и не учитывать контекста бизнеса и приложения. Да и про то,как считать стандарты для граф интерфейсов тоже. Я открыт к аргументами,просто её не вижу,кроме как аппелирования к личному мнению, неподтвержженных ничем цифр и трёх недоработок в трех приложениях абсолютно разной направленности.
Никто не отрицает, что у современного айти есть проблемы, но не надо добавлять к ним ещё несуществующие.
для удобства пользователя. Клиент всегда прав.
чтобы приложения были максимально полезны пользователю.
это не избыточность, это функциональность, красота, комфорт.
Вы снова уклоняетесь от вопроса. Приведите пример стандартизации интерфейса, которая хотя бы в теории покроет все потребности абсолютно всех приложений, сайтов, программ и другим айти продуктам.
Чтобы приложение было полезно пользователю, в нем должно быть все нужное И не должно быть ненужное. Зачем вам в калькуляторе возможность звонить по сотовой связи и рассчитать индекс вашей массы тела?
1С так не любят именно потому что это огромная каша из хлама и тебя к нужным функциям заставляют тащить ещё две тонны мусора, а любая правка превращается в ад. Зачем? Аналогично - вы этим замедляете обновления, чтобы давать пользователям новые обновления, это противоречит вашей же доктрине его удовлетворения. В чем смысл?
Не понимаю, зачем вы мне грубите, это выглядит как "Гения порвало". Тот факт, что ваше мнение не принимается хабром - целиком выдуманность поданной проблемы.
Везде где есть список нужно давать возможность выполнить операцию над выделенными элементами, как над одним
Чем лично Вам претит этот функциональный стандарт?
Тем, что этот функционал не нужен 50% пользователям.
Или возможность сохранить текущий выведенный на экране список в файл, а не скриншотить. Чем плохо?
Тем, что этот функционал не нужен 99% пользователям.
Вы три разных примера привели, где докопались до трех абсолютно разных вещей - суммы товаров в списке, специфике работы фильтров/папок в конкретной почте и сохранения каких-то переменных ( в вашем случае это разрешение и части промпта). Если вас не устраивает работа конкретного приложения или его части - у вас есть опенсорс (покажите, как надо), другой продукт или сидеть пилить кастомную версию при наличии такой возможности.
Вы продвигаете какие-то вещи, которые нужны неизвестному количеству пользователей (может быть, вообще только вам), когда вам по кругу повторяют люди примерно одну и ту же здравую мысль - "Бизнес делает то, что хотят от него большинство пользователей, а не один или два человека. Вкладывать избыточный функционал дорого и неэффективно". Причем ладно редактура списков, я могу с натяжкой признать, что этот случай не такой специфический и достаточно часто бывает ситуации, когда нужно что-то редактировать множественно (хотя мне он нужен в среднем в каждом третьем приложении, которым я пользуюсь еженедельно и там, где это надо - оно реализовано, удивительно). Если люди будут давать на это фидбек (как видимо в случае озона с суммой) - фичу введут. Не будут люди говорить, что им нужно сохранять разрешение в Шедевруме - фичу не введут. Все проще некуда.
Про экспорт в файл это ещё более специфический случай, какой человек будет себе условную корзину озона в файл заносить. Сделать - можно, но зачем ради 1% использований тратить средств как на другую фичу?
Вот мы и подходим к тому, что вы зачем-то распространяете свой специфический взгляд "Делайте везде всё с избытком" как кризис айти, когда на самом деле это не выгодно примерно никому - бизнес в убытке, если фичу не юзают, а пользователи будут дольше ждать релиза или платить за избыток, даже если не используют. Может, тогда это не кризис айти, а просто рациональность? А для правки промахов с фичами, которые действительно нужны, существует поддержка продукта. И имхо, реализовать нужную фичу после запуска дешевле, чем сделать фичу с нулем использований сразу.
Как он Вам помешает жить? Как будет умалять Вашу креативность. Расскажите, я послушаю.
Я не хочу, чтобы мне насаживали реализацию того, что в моей конкретной ситуации не нужно и будет захламлять код, потратит моё время на написание этого кода, отладку и тесты лишь для удовлетворения "стандарта". Я хочу, чтобы у меня осталось право обосновать отказ от реализации, если нет никаких предпосылок к тому, что это будет использоваться и при этом у меня останется право изменить моё мнение, если мне приведут достаточно аргументов "за" реализацию. Я достаточно ленив и уважаю своё время, чтобы не делать того, что от меня не требуется и тем более не требуется для реализации бизнес-задачи. А бюрократией, ритуалами и бумажной волокитой из-за тонны регламентов я сыт по горло в половине сфер моей жизни, не надо тащить это ещё с избытком в работу. Как-то так, у меня достаточно самоуважения, чтобы не делать бесполезного и есть желание, чтобы меня не заставляли это делать бумагами. Я поддерживаю стандарты там, где они нужны и к месту(т.е там, где деньги сталкиваются с здоровьем, жизнями или правами людей), а не там, где нужен вариант формы кнопки и сколько методов из crud мне надо реализовать при необходимости только записи и чтения.
Я и не жду принятия. Перемены - это всегда больно. В родном теплом привычном навозе всегда приятно сидеть.
Я про то, как должно быть. Чтобы приложения стали по-настоящему функциональными. Пользователи будущего будут смотреть на все современные поделки как на куличи малыша в песочнице.
Я про то, как должно быть.
А почему должно быть как вы придумали? И это ваше мнение или экспертов?
Можно открыть Yahoo образца нулевых и сравнить с современными приложениями,тоже будете смотреть как реликты динозавров. При чем тут кризис и будущее - непонятно,прогресс двигается вперед в целом в большинстве сфер,только с разной скоростью.
Повторю чужой вопрос - а почему вы считаете,что вы знаете, "как должно быть"? После всего написанного вами у меня в целом сомнения насчёт вашей экспертизы если не а целом,то как минимум насчёт разработки командой и в условиях конкуренции больше чем с нулем продуктов.
Раз вы любите науку - напишите тогда научное обосновано, т к пока что эта статья в моем сознании перекочевала из спорной в попытку наложить влажные фантазии на мир, причём фантазии нелогичные и которые нас на 20 лет назад откинут.
Отличный коммент, просто человек который написал этот ПСТО работает в сфере 1С и имеет слабое представление о командной разработке вэб-приложений, современных технологиях и т. п. Судит поверхностно и предвзято. Ему бы тестировщиком тогда пойти, пусть предложения вносит потом аналитикам о том, что какой то там сортировки не хватает или в файл нельзя сохранить. Кстати вот он использует приложения по доставки пищи на дом, почему замечания что нельзя чеки от вкус-вила сохранять в файл у него замечаний нет. А то бы тоже написал - мол чек в ексель неплохо бы сохранять, чтобы потом смотреть что купил и эту таблицу заносить еще в одну таблицу и т. д. Автор просто любит все хранить - чеки, таблицы и т. п. в электронном виде. И нам, нормальным, его логики не понять. Он просто докапался, что мол гранаты не той системы, что мол цвет должен быть другой, что вот мол сортировка не та. Хотя если ему на что то указывают - это у него по воле Бога. А тут - ну надо же, кризис IT.
А так можно до любой программы или приложухи докапаться. Ну это как бывает - вышла одна версия, потом вторая, а то чего было в первой - уже нет, либо чем то заменили. Это как сравнить с автомобилем. Есть люди которые и жигулями довольны, а если нет электростеклоподъемников - дорабатывают. А есть вот вечные нытики, автор уже про кризис IT лет так 10 разглогольствует, приводя в качестве аргументов - какие то баги и отсутствие фич. Там у него кнопка не работает, здесь сортировка слиянием, а не пузырьковая, там видите ли меню выпадать должно, а не в диалоговом окне открываться. И т. д. и т. п. Т. е. что 99% народу работает и всех все устраивает - ему плевать. На это он ответит в духе "миллионы лемингов не могут ошибаться". Хотя по факту сам ни разу десктопное приложение он не написал не говоря уж о вэб приложениях на проде. Но диванную аналитику о кризисе IT дает исправно. Для чего поинтересуйтесь, ответ - для контенту токмо. Обычное IT графоманство.
Все же знают,что гранаты красного цвета быстрее летят, а фиолетовые - бесшумные. Это ещё орки из вархамера подтвердили :D
А так да,оторванный от мира и логики взгляд. Чем больше читаю ответы автора тем больше это понимаю.
Но ведь могут же. Привыкли, что только так и по другому не мыслят.
Не вкладываются в исследования функционала, все кнопочки пишут сами.
Айти заложница того, что ею занимаются только инженеры.
Это как если бы медициной занимались только врачеватели.
а в чем разница между учеными исследователями функционала и инженерами?! разве не из инженеров ученые получаются, не? или у ученых другое мышление нежели у инженеров? А кто должен заниматься по вашем IT? военные, музыканты, врачи, водители или кто? вроде как программисты занимаются, и кстати из этих программистов также получаются ученые. Вы не работали в НИИ информатики в 70-х, нет? думаете там все было по стандартам из за того, что это НИИ и там ученые сидят?. ну так вот, поинтересуйтесь сначала как вообще архтектура создавалась и программы на перфокартах.
мне больше понравился тейк про быстродействие - что оно не нужно, т.к. пользователь работает медленно. По-моему очень иронично, с учетом портфолио))
я просто видел кейс, как разработчики типовой 1С пытались ускорить печать по всем канонам науки - использование запросов вместо перебора объектов.
в итоге код модулей печати стал непонимаемым человеком-программистом, в общем, быстродействия прирост на 10%, читаемость кода ухудшилась на 80%.
А принтеры быстрее печатать не стали.
И это нормально. Запросы для этого и созданы. А бизнес-объекты они про другое
Ты просто не работал с системами, в которых сидит от 1000 человек. Вот тогда поднимать каждый объект при массовой печати будет странно
с точки зрения функционала нет разницы от количества пользователей. Пользователь может сделать определенные функции.
если количество пользователей влияет - нужно учитывать в функциональной теории возможные ограничения.
Даже в 1с это не работает. Даже - потому что взял ты оттуда.
Так вот все сильно зависит от действия. Например "копировать" и "ввод на основании" не работает с множественным выбором.
Любой функционал должен быть осмысленным и зависеть от контекста
Те действия, которые не работают с множественным выбором, не будут доступны. Не вижу проблем. Вы опять хотите урезать возможности пользователя? Чтобы что?
Везде где есть список нужно давать возможность выполнить операцию над выделенными элементами, как над одним.
Точно везде? Я на вскидку придумал три ситуации, где групповое действие недопустимо для группы, только для одного элемента, или только при выборе определённых элементов, или имеет разную механику в зависимости от выбранных элементов.
Возьмём простой пример - чат. Есть 5 контактов - если жмём "открыть чат" - одному - открывается чат с ним, если 3-м - 3 чата? - нет, открывается групповой чат. Получается исключение из общего регламента
А знаете сколько будет таких исключений? Я думаю много тысяч страниц исключений - когда - вот это можно, но если даты то нельзя, вот так можно, но если список динамический то нельзя, сумму посчитать можно, но если бонусы то не так, если рассрочка то не так, если фантики то не так...
наука это изучит, не переживайте. и функции-исключения пометит признаком "не для групповой обработки". Зато бизнесу нужно будет меньше платить программистам.
Изложите предмет и методологию хотя бы поверхностно - как учёные будут изучать и что? Дизайны существующих решений? Все возможные варианты интерфейсов и данных?
Согласно теории информации - невозможно сжать 10 бит произвольной информации в 8 без потерь. Так-же любой алгоритм способный включить в себя все сценарии использования управляемо - должен содержать в себе реализацию всех сценариев использования, и сложность его настройки будет эквивалентна написанию соответствующего кода.
То что вы предлагаете уже придумали и это называется языками программирования.
ну давайте начнем с простого.
Если пользователю предоставляется некий список с колонками, он должен иметь возможность:
Отсортировать этот список.
Сгруппировать этот список.
Наложить фильтр по любой колонке списка
выполнить одиночное действие к выбранным элементам.
Принимается подход?
Потом смотрим, как инженеры пишут код, что им мешает реализовать эти функции.
Далее, пользователь хочет скрыть колонку или чтобы ему не задавался некий вопрос с подтверждением. Причем он хочет скрыть это или для себя или для группы пользователей (своих сотрудников). Имеет право? Да.
Аналогично все касаемо ширины, пропорций колонок и т.п.
Это для затравки.
Далее изучаются все варианты работы пользователя с данными.
Если есть суммы, должны быть итоги (или возможность их включить).
Принимается подход?
Нет, подход это описание процесса исследования, а не придуманный из головы факт не имеющий под собой оснований как и доказательной базы.
Далее изучаются все варианты работы пользователя с данными.
На основе какого предмета? Имеющихся систем или все возможные?
Все возможные варианты работы с данными включают все возможные варианты работы с интерфейсом и бесконечную сложность. Например целочисленные данные можно инкрементировать и декрементировать - значит ли это что любое поле с целочисленными данными должно иметь кнопки +1 и -1? - По вашему мнению - да, ведь "имеет право". А ещё их можно складывать и вычитать с буфером обмена - значит ли это что любые поля должны включать опцию "прибавить буфер обмена" - опять да, а ещё их можно возводить в степен...
Функциональные методы обработки всех вариантов проведения уже есть в языках программирования. Применимость на интерфейсе этих операций - строго ситуативна. Больше никаких исследований и инструментов просто не требуется.
Стандарты пишутся, чтобы все работало хорошо.Не вижу ничего плохого в переводе разъема лайтинга на тайп-си например.
а считается ли кризисом то, что у одного девайса в Type-C есть DirectDisplay, аудиовывод, а у другого нет? Или что где-то есть быстрые зарядки, а где-то нет. А где-то даже Thunderbolt из коробки, но вот проблема - бывает так, что даже в ТТХ устройства об этом не будет написано и нужно читать ЖИВЫЕ обзоры от пользователей.
Так что пример не очень удачный)
К стандартам UI, нужны еще ГОСТы на мониторы, выдавать по талонам и будем сидеть все на одинаковых 4:3 800х600, и с такими же телефонами ходить Да и вообще, зачем эти почты и озоны - все в 1С загнать, чтоб и РУТУБ и ОЗОН и ГОСУСЛУГИ были на соседних вкладках!
/s (там даже игры будут)
Надо было 3 статьи писать, а то так против местных корифеев написали, они вас и заминусовали. Написали бы 3 статьи они бы против друг друга в целом все три статьи в плюсы вывели.
Тут сразу видно, если статья в хорошем плюсе, значит от крупной компании. А внутри, скорее всего, белый шум.
Про кризис - ну да, он везде.
Автора заминусовали,потому что он выдает персональное мнение как истину последней инстанции и в комментариях скатывается до личных выпады с абстрактными понятиями. Пнуть большую компанию все любят,проблема далеко не в этом.
Даже если предположить, что вы правы, почему мнение автора вы считаете не достойным быть высказанным? Он пользуется вашими услугами, он клиент, это он платит деньги в конечном счете за ваш труд, а не ваш работодатель, которому вы в попу дуете. Так что проявите уважение. Придумайте решение.
Вы тут ИТ или бригада блокировщиков идей?
Даже если предположить, что вы правы, почему мнение автора вы считаете не достойным быть высказанным ?
Никто автору не запрещал высказываться, не выдумывайте. Иначе этой статьи бы не было. Я считаю его мнение попросту необоснованным и оторванным от реальности, оттого и оценка у статьи такая, какая есть.
Он пользуется вашими услугами, он клиент, это он платит деньги в конечном счете за ваш труд, а не ваш работодатель, которому вы в попу дует
Я ни с одной компанией из статьи не связан трудовым договором и сомневаюсь, что автор пользуется услугами конкретно моей компании (она занимается управлением финансами и ИИ). Поэтому не понимаю, зачем вы вешаете ярлыки в попытке защитить статью. Ко всем трем компаниям я не питаю большой персональной любви, но продуктами их выборочно пользуюсь.
Так что проявите уважение. Придумайте решение.Вы тут ИТ или бригада блокировщиков идей?
Автор сам всецело никому не проявляет уважения, почему должен я? Вы, к слову, ушли от него недалеко в риторике.
Бремя доказательства написанного тоже висит на авторе, он над этим не потрудился. Я всё ещё жду от него примера ГОСТ-а на интерфейсы, о которых он говорит либо успешного примера мультибиблиотеки для бизнеса, где не будет фигурировать 1С, держащаяся только на счет насильного внедрения и не пользующаяся спросом вне нашей страны примерно нигде. Или хотя бы "науки" и "научного обоснования" того, о чем он говорит.
Какое решение надо придумать, если проблемы не существует? Наверно никакое ¯\_(ツ)_/¯ . Идея автора просто не стыкуется с реальностью и будет больше вредна, чем полезна, зачем думать над её реализацией. Почти каждый прогер в один момент приходит к идее "Сделаю библиотеку на все случаи жизни", которая после первой же встречи с реальностью рушится и приходится её каждый раз перелопачивать, либо прийти к выводу, что сделать универсальный "инструмент" под каждый случай невозможно. А сводить минорные недоработки различных программ под "кризис" это даже не смешно - с такой логикой можно закрывать айти, если при разработке вам понадобилось больше одного коммита на разработку, а в вашем калькуляторе нету функции селфи, взлома Пентагона и расчёта рациона вашего кота с экспортом в 3d-принтер.
надеюсь, еще через 30 лет все же функциональный подход к разработке приложений восторжествует. Покамись, похоже, человечество не в силах даже осознать, зачем он нужен, не говоря уже о реализации подхода.
Вы, к слову, ушли от него недалеко в риторике.
Соглашусь тут с вами. Принимаю за комплимент.
Высказаться то право у него есть, также как и у пользователей хабра заминусить его и отправить в ридонли.
а в чем идея то?! раз вы поняли, может просветите.
Да, я высказываю своем мнение, а минусят, потому что понимают, что я прав и все приложения функционально дырявы. В ответ летят оправдашки про бюджеты, привычные способы разработки и т.п. Ну это как детский лепет.
И будет, пока инженеры не поймут, что не справляются. И не позовут на помощь "людей в белых халатах" - ученых. Не тянут кодеры создать функциональную базу для своих разработок.
Давайте разработаем функциональную основу списка элементов.
Добавим сортировку - очевидно она нужена. По какому полю? Нельзя никакое дискриминировать - значит по любому. Подождите - у этого магазина товары с 50 полями - пользователю будет нереально найти нужное - добавим в функциональные требования возможность поиска по названию поля. Подождите - но у того магазина - часть полей может не присутствовать в части товаров - значит помимо поля нужна ещё галка - показывать элемент без поля в результатах или нет. Подождите - а у этого магазина часть полей предоставляют сторонние сервисы и они меняются в реальном времени - нужно добавлять галку что ищем по снапшоту или реактивно обновлять поиск от изменения любого из них. Подождите - но у третьего магазина - часть полей может иметь диапазон значений а не конкретное - значит надо добавить это элемент выбора диапазона. Подождите - но это все должно влезать на стандартные 800х600 ой, пока вы делали экраны уже стали 1920х1080, ой, пока вы дорабатывали - появились смартфоны с тач интерфейсом и вертикальной 480х800, ой, пока вы адаптировали - диагональ выросла с 3 дюймов до 7, поменялось соотношение сторон, ой, пока под это адаптировали требования - вышли умные очки с новым стандартом управления.
Я 4 раза видел подобные эксперементы в рамках компаний - когда они пытались разработать единый функциональный конструктор который бы позволял решать задачи используя готовые кирпичи, и каждый раз к моменту, когда конструктор достигал хоть какого-то уровня готовности - кирпичи уже не подходили и их приходилось пилить, штробить и резать - потому что мир меняется быстро, ваша сумма в корзине с постоплатой - завтра может стать беспроцентной рассрочкой, послезавтра оплатой долями, ещё через день бонусами со внутренней валютой и т.д. и пока вы только соберёте список требований (даже ещё не возьмётесь за реализацию) - потребности уйдут так далеко вперёд, что придется все начинать сначала.
вы слишком рано сдались, потому что вы инженер, а не ученый.
надо было создать упрощенный интерфейс, а расширенные функции через кнопку доп. возможностей, можно назвать ее кратко "еще".
Да и кто экспериментировал? Программисты? У них мозги не на науку заточены. Им говорят - копай, они копают. Наука о другом.

В ЯДиске до сих пор не могут сделать сортировку альбомов по алфавиту и добавить возможность отображения фото на картах по геометкам 🤦♂️
"в продукте нет того, чего я бы хотел и теперь я объявляю кризис этих компаний."
Я согласен с наличием проблемы, но не согласен с выводом автора о причине. Основная причина - низкий уровень конкуренции, что приводит к возможности выпускать продукт "и так сойдет".
Например в "МойСклад" чтобы получить УПД надо создать Счет-фактуру. Год назад этот документ отменили и заменили на УПД, а предупредили о переходе еще на год раньше, но "МойСклад" не напрягается, а поддержка говорит, что это базовая логика программы и без ненужного документа нельзя.
В англоязычном и американско законодательном мире более 5000 аналогов "МойСклад" (по выдаче ИИ поисковика) и они вынуждены совершенствовать свои продукты, а в России, особенно в силу известных событий, нахрен не уперлось тратиться на доработки. И так сойдет.
конкуренция не поможет. Инженеры не смогут победить, нужно выходить на другие инструменты разработки. Но программистам это тяжело - они привыкли.
Бизнес не хочет скидываться на науку.
Государство вообще не понимает, зачем это надо. Вроде и так все работает. Неудобно конечно, некрасиво, но вроде пипл привык, не скулит.
На Западе как раз учет стабилен, потому и 5000 аналогов. Вариации на тему vendors + customers можно даже в голимом Акцессе сделать. Вот нашу российскую товароучетку сложно автоматизировать с кондачка.
Третьего дня мне в шаурму помидор не положили. Налицо кризис сельского хозяйства и системы общепита! А все потому, что каждую шаурму с нуля делают и не изучают потребности пользователя.
Кризис в голове.
Да зависит от ТЗ и хотелок бизнеса/заказчика. Озон, ВБ, Авито разбалованы, что говорить, они лучше других почему то и попали в белый список минцифры, их сайты работают, когда блочат интернет. А вот как мой сайт туда добавить? Договрнячек?
А вот тот же АлиЭкспресс. Просто взяли у урезали функционал. Не фильтров, кнопка спора убрана в ...ня, счётчик безопасной сделки?... Явно не кризис, а хотелки бизнеса.
Сергей, это кризис не в ИТ. Это кризис всей инвестиционной системы, всей капиталистической базы - это вот ее, системы, возможный потолок. А возможно это вообще и не кризис, а доступный оптимум. То что вы видите - это круги на воде, притом очень далекие круги. Та же картина в основных фондах, в ниокре, куда глубоко не копните плюс минус то же самое.
Если я могу представить, как ДОЛЖНО быть, а потом сравниваю с тем как ЕСТЬ, то увы, кризис. Юра, мы все потратили за эти 30 лет. Надо было не на Луну летать, а обдумывать новые подходы разработки.
Не, так то не плохо конечно, все работает. Дышит, вертится. Очень криво, конечно, но все же.
Жить можно. Если выключить индикаторы боли.
Заголовок: "IT в кризисе"
Ожидание: компании терпят убытки, увольняют персонал, режут инвестиции
Реальность: в интерфейсе приложения не показали сумму, которую нужно положить на счёт
Статья не понравилась. Каждому пользователю нужны свои хотелки. Мне например, 80% из перечисленного в статье не нужно, а кому-то нужно. Почтой mail.ru пользуюсь с 2003 года, если что.
Мне кажется, тут решение может лежать не в области стандартов, а в области плагинов. Если бы у mail.ru была бы возможность добавлять стороннюю функциональность в интерфейс, сторонние разработчики могли бы написать плагин и продать подписку на него Гению.
в кризисе
он говорит, что это было в экстазе, а я точно помню, что это было в сарае (с)
Хорошо ли использовать почтовые ящики не на своих почтовых серверах, а на чужих - эту тему я тут сейчас затрагивать даже не буду (хотя вообще-то немного затронул уж :-) ): кому-то это хорошо, а кому-то доверять свою почту чужим серверам - ни разу не хорошо.
Тему тут хотел бы затронуть немного другую:
Даже если и использовать почтовые ящики на серверах не своих, а чужих, то удобнее ли с ними работать через веб-интерфейс (например, как тут в статье говорилось про пример с mail.ru), чем получать всю почту в свою почтовую программу и работать с ней на своём компьютере локально уж?
Не согласен с автором.
Считаю что причина в том, что основной ресурс вкладывается в новые фичи и продукты. На доработку старых и технический долг, выделяется минимальное количество ресурсов.
Из-за этого мы имеем монструозное ПО, ПО на Электроне, недоработки интерфейса.
Как это лечить? Здоровой конкуренцией!
Примеры:
Телеграм. Откусил огромный кусок пирога на рынке мессенджеров за счет качественного ПО.
Тинькофф Банк. Изначально розничный банк вошел в тройку крупнейших за счет удобства ПО и качественного сервиса.
Озон скорее всего сделает доработку.
Mail уже проиграл конкуренцию за почту. Скорее всего там значительно урезаны ресурсы.
Яндекс сменил владельцев и переживает кризис. Ожидаемо что где-то начнет все сыпаться.
создает новые языки программирования, но не развивает базу.
Куда уж базированнее то?
Автор приведите пожалуйста, примеры стандартов которые вы бы хотели чтобы были введены и как бы они решили, указанные вами проблем? А то мне кажется что у нас у всех разные понимания слова стандарты в ИТ
Почему-то мне кажется, что автор понятия не имеет, что такое UI/UX и как эти чудесные буквы вписываются в современную разработку.
Повылазили защитнички, наверное такие же бездари, о ком пишет автор. Постоянно с такими "мелочами" сталкиваюсь. Пример 1: WB - перевел лишние деньги, пытаюсь зайти в их кошелек, чтобы вывести, просят подтвердить личность по смс, ок, по работе отвлекся, повторяю процедуру, далее введите пин, блин забыл, восстанавливаю - опять подтвердите личность, а повторное смс через 4 часа. Офигеть, да? Отличный сервис.
Пример 2: FixPrice - есть старая карта лояльности привязанная к телефону, полученная когда ещё не было их приложения. Пытаюсь зайти в это их приложение, требуют номер телефона и, тадам, имя. Какое ещё имя? Я уже не помню там он вообще указывалось при заведении карты? Короче реальное имя не подошло, говорят ты никто и ничего с этим не сделать - ты не зайдешь. Отличный сервис.
Конкуренцию душат законами, никакого фидбека, в общем полный мрак. Я ещё про наш локомотив IT отрасли - Яндекс не говорю. Это вообще тема для отдельной диссертации.
Не гуглите автора... не повторяйте моих ошибок.
прочитал статью, прочитал комменты. Так и не понял, почему автор называет вышеуказанное "функциональными дырами"? Речь идет первоначально об интерфейсах, и даже у некрупных компаний есть метрики, в рамках которых выставляются приоритеты по доработкам или исследованию того, что необходимо доработать (туда же и багтрекер, обращения, и т.д.).
Довольно яркий пример с IE версии до 9-ой, например. Если компания видит, что метрика с этим браузером <0.01% (число для примера), то она перестает поддерживать этот браузер и вешает заглушку "обновись".
Особенно в екомерсе - почти всё выстроено от того, что нужно сделать, чтобы клиент принёс больше денег (и пользовательский опыт, а в это точно входит UX/UI). И если яндекс и мейл могут на это (условно) чуть подзабить, то уж Озон - я на 99% уверен, что в этом направлении работает очень активно.
Возможно процент пользователей, который делает постоплату и создаёт несколько заказов не настолько большой, чтобы думать о том, насколько этим людям нужно разбивку цены по заказам (это пример, возможно всё и не так - но думаю мысль понятна).
Компании не тратят деньги на то, что по их мнению не принесет им денег (то, что не улучшит пользвоательский опыт), а вы хотите потратить (причем, видимо гос.денег) на то, чтобы: провести НИОКР, создать методологию, написать стандарты, выпустить гайды по ним? Основываясь на единичной выборке - это на мой взгляд прям сильно недальновидно и расточительно(
Вы смотрите с позиции инженера, к тому же находящемуся внутри процесса. Попробуйте созерцать процесс с точки зрения науки.
т. е. вы с точки зрения науки созерцаете?! а в чем разница между созерцанием инженера и науки? объясните..., и откуда вы знаете как наука созерцает?
а как вы определяете разницу между созерцанием процесса инженера и науки? и в чем эта разница?
что является предметом научного познания и какие методы верификации используются?
Ozon, Mail, Yandex — все в кризисе IT