Документацию обычно читают на английском (а подчас только в оригинале ибо локализации нет совсем) и там этот стиль контрола называется breadcrumb. И в коде этот класс имеет точно такое же название, поэтому надежнее не переводить термин чтобы не было неоднозначности и толкований.
Пожалуйста, не стоит переводить термины которые не имеют широкоизвестных и устоявшихся аналогов в русском. "Хлебные крошки" - что? ??♂️ Понятнее было бы оставить оригинал "breadcrumbs". Иначе у вас получаются очередные "Ясные Печенья".
Видимо у них очередная эффективная сова завелась и хочет проявить себя для получения бонусов. А по факту, если я правильно читаю сводку, экономия в 1млн долларов для компании погоды не сделает.
Это гипертрофированный пример общеупотребимого интерфейса, каким он может быть предельно простым и удобным. Подобрать такой же пример для специализированного интерфейса как-то не придумывается.
Видимо это я так рассуждаю через призму своего личного опыта. Вот и не укладывается у меня в голове, что бывает классный дизайнер который еще и хороший инженер. Мне такие не встречались, а вот крайности - да, видел.
Сам в дизайн не умею вообще, но иногда приходится по работе пилить веб-морду для очередного проекта. Без слез на свое поделие потом не взглянуть. Хотя и коллеги пишут примерно так же)
Не знаком к сожалению с данной литературой, но на любительском уровне помню статьи об эргономике в журналах по радиотехнике и электронике времен позднего СССР. И там обсуждались вещи которые на западе в то время были уже давным-давно сами собой разумеющиеся. А там в статьях они преподносились как достаточные эргономические изыски (достаточные по мнению авторов для кого? кто слаще редьки ничего не видел?) выгодно отличающие тот или иной интерфейс от прочих (видимо от тех интерфейсов в которых эргономики нет от слова совсем).
Цвета приборки и шрифты думаю выбирали исключительно для надежной и безошибочной работы пилота ибо безопасность перелета и жизни пассажиров в приоритете. Подобные необходимые элементы эргономики естественно всегда учитываются в специализированных интерфейсах. А вот к примеру подстаканник для кофе как в обычных авто там у них есть? Это уже элемент удобства и для выполнения непосредственной работы пилота не связан, а значит может быть и не реализован. Я как раз про такие вещи в интерфейсах говорю, не критически важные, но удобные. Хотя это конечно субъективно все.
Легко, вот например профессиональная СВЧ печь для общепита. Только одна крутилка и все. Интерфейс максимально удобный и интуитивный для неограниченного круга пользователей. Кстати у нас в местном ТЦ точно такая же стоит, действительно очень удобно.
Ни в коем случае не хотел как-то принизить инженеров (сам по образованию инженер), а лишь подчеркнуть разницу подходов некоего "обобщенного дизайнера", который печется о конечном пользователе и думает над эргономикой и удобством и "обобщенного инженера", который печется о богатстве функциональности и максимальном контроле системы через органы управления.
Думаю что подавляющее большинство узкоспециализированных интерфейсов проектируются инженерами для инженеров (ну или спецами только для спецов, если угодно). Приборка самолета как раз и есть такой интерфейс. Дизайнерами и эргономикой там и не пахнет, потому как в случае с приборкой самолета надо в первую очередь лететь, а не шашечки.
Подход для общеупотребимых интерфейсов другой: там надо эргономику, простоту и интуитивность вывести на первые места ибо оператор не будет обучаться, а сразу приступит к работе. Что кардинально отличается от подхода к оператору самолета (пилоту) - там и обучение специальное, и экзамены, и инструктаж.
Было бы классно, соскучился по ламповым кнопочкам аля Win98)
ЗЫ: А ведь в геймдеве не так давно пошла волна на стиль 8ми битных игр (пикселизация на основе движка unity). Смотрятся и играются такие тайтлы имхо вполне лампово, но на современном железе.
Интерфейс сам по себе не нужно обновлять, его приходится обновлять по причине:
Но надо понимать, что компании постоянно расширяют аудиторию и как раз для новеньких они делают порог входа все ниже и ниже, в т.ч. и за счет упрощения UI.
Дело исключительно в деньгах для компании. Новые пользователи это новые деньги. Для этой цели бизнес и существует.
Как наблюдателю этого мульти-руля со стороны мне кажется, что тут как раз дизайнеров UI/UX и не было допущено вовсе, а руль проектировали исключительно инженеры. Видите эти наклеечки разбросанные то тут, то там и в разных ориентациях написания? Подобное только инженер может сделать на коленке. Дизайнер не будет смешивать стили прочтения надписей. Я на заре своей карьеры работал в инженерной компании и там в том числе тоже были мульти-рули с подобными аляпистыми органами управления. Да, свою функцию они выполняют, но и только. Ни о каком удобстве речи не идет.
Другой момент о котором вы говорите - багаж накопленного UX старой аудиторией продукта выкидывается без зазрения совести. Это бич современного производства ПО. Да, это всегда больно менять свои привычки. Сам бомблю от такого, когда без моего ведома меняют что-то к чему я годами привык. Но надо понимать, что компании постоянно расширяют аудиторию и как раз для новеньких они делают порог входа все ниже и ниже, в т.ч. и за счет упрощения UI. Хорошо это или плохо? Не знаю, вопрос дискуссионный. Выше я уже описал свои впечатления новичка от вида нового UI. Возможно мое мнение сильно поменяется если поработать с данным UI блендера профессионально по 8 часов в день. Но первое впечатление производит хорошее.
Однако в вашем примере как человек никогда не пользовавшийся блендером и видя два варианта интерфейса скажу, что новый выглядит субъективно лучше: иконки проще воспринимаются, не надо в них вглядываться чтобы установить мысленную ассоциацию с обозначаемым действием. Плюс в старом UI на каждой строке была иконка и в итоге весь список меню сливается визуально, перегружен. В новом иконки есть только у частых и значимых пунктов, глаз сразу цепляется за них. Вы же судя по всему просто привыкли, но старый UI был явно перегружен иконками. Здесь конкретно редизайн на мой взгляд был проведен удачно.
А для чего существует бизнес? Чтобы внезапно - зарабатывать деньги! Все остальное вторично.
И сразу первый вопрос как только о лояльности заикаются: а мне будут выплачены акции или иные активы чтобы я имел долю в компании, чтобы мог переживать за ее будущее и ее показатели? Если нет, то и суда нет.
Эта вся псевдо-корпоративная чушь работает на молодых неокрепших умом сотрудников. На условном западе это может быть оправдано как-то поддерживать подобную игру. Ведь там есть институт репутации как работника так и самой компании. Хотя там тоже деньги считать умеют и просят долю в компании за лояльность. Иначе наймите себе собаку. Совсем другой случай, что на рынке РФ репутация не значит чуть менее чем ничего. Твори ты любую дичь - всем все равно пофигу. А как показывает история последних лет даже нарушая закон в промышленных масштабах такой компании все равно ничего не будет. Например вспомним про утечки ПД и не только.
Гордятся обычно результатами своего труда или совместного труда с коллегами. Или общими достижениями фирмы, теми к чему приложил свои руки, голову, другое место, etc. Испытывать гордость за сам по себе бренд или вывеску это сродни урапатриотизму на популистские лозунги. То чем как раз всю дорогу у нас любят заниматься.
Ну так это к SQL коду непосредственно отношения не имеет. Вы здесь описываете частный случай денормализации данных, т.е. создать рядом мапу(ы) из нормализованных полей данных для ускорения поиска по частому конкретному запросу. Это скорее к теории отношений БД: как их правильно составлять и проектировать размещение данных. Никто ведь не заставляет клиентский код прибивать гвоздями к этим мапам: их можно агрегировать в соответствующие вьюхи и использовать через ORM как обычные таблицы. Вот SQL код во вьюхах и пусть оптимизирует сама БД, она и статистику соберет по запросам. И у вас выходит, что в клиентском коде зашито знание как эти данные хранятся в БД. А клиентскому коду по-хорошему знать об этих приседаниях не надо.
Другое дело, что от этого легко уйти на словах, а на практике все не так радужно. В наших проектах тоже активно используется EF и нет-нет да и прорываются запросы на голом SQL (кастомные отчеты или хитрые запросы, будь они не ладны). Те же хранимки хочешь не хочешь содержат в себе часть бизнес-логики т.е. знают как собирать данные для ответа клиенту.
Каждый раз приходя на очередной проект и видя развесистый EF спрашиваю местных: в чем сила брат? в чем преимущество использования здесь ORM'а? И обычно первым же ответом идет чтобы легче переехать на другую СУБД "если что". Причем это самое "если что" не уточняется и не случалось чуть ли не десятилетиями. Для меня же это в первую очередь продуманная инфраструктура, удобный генератор миграций, валидация моделей классов, встроенное кеширование и прочие плюшки оптимизаций запросов. Поэтому при всех недостатках ORM'а все же выступлю за его использование. Однако учитывая текущую ситуацию все же раз в пару десятков лет это самое "если что" стреляет. Вот и у нас на горизонте замаячила задача переезда с MS SQL на что-то опенсорсное.
Тоже сторонник годами проверенного софта и решений на его основе. Часть из вашей подборки так же юзаю. Для массовой редактуры тегов уже более 10 лет использую TagScanner, продукт отечественного разработчика. Софт с годами не разжирел и не утратил своего необходимого и достаточного функционала.
Не хочу обидеть автора или его коллег по цеху, однако все чаще возникает мысль, что либо дизайнеры забивают на UX, либо сознательно ухудшают его в угоду эээ, чему? Продажам? А если проект ничего напрямую пользователям не продает? И часто вижу, что дизайн сменили только ради дизайна. Например интерфейсы почт меил, яндекса: для ПК стали излишне крупными и громоздкими, сжирают много полезного пространства тупо на оверхед самого UI. А для мобилок проще и быстрее использовать клиент-приложение, а не веб версию.
Ну и моя критика как обычного юзера по советам выше.
п.1.: Никакого паралича нет если отдел маркетинга четко описал тарифы, услуги или планы для конкретной ЦА. А вот если проект мутный и непонятно что предлагает непонятно для какой ЦА - то тут да, мимокрокодилы будут тупить.
п.2.: CTA малоэффективен на мимокрокодилов. А для тех кто уже знает что он хочет это бессмысленно. Скорее даже раздражает если CTA навязчив, как например попап "вы на нашем сайте уже 15 секунд, может вам позвать в чатик нашего консультанта?". Или плагин аля живосайт справа внизу выскакивающий как по расписанию. На мобильной версии так вообще он закрывает почти весь экран. Серьезно, не надо так)
п.4.: Нет смысла лепить кучу плашек "Verified by Visa", etc ибо это обычно картинки которые никуда не ведут ни на какой оф сайт платежной системы. Таким образом они ничего юзеру не говорят и не подтверждают безопасность или аккредитацию данного способа оплаты. Гораздо важнее писать, что за платежный шлюз использует проект, его политику обработки ПД и т.п. Особенно если это не отдельная страница, а встроенная форма.
п.7: Обычно TTA сильно переоценен. Можно подумать над рациональным ускорением, но без фанатизма. Если ваш проект имеет прямые продажи и товар\услуга релевантны для пользователя он подождет загрузку и две, и три, и даже пять секунд. А если это мимокрокодил, то даже при моментальной загрузке не факт что он что-то купит.
Говорю ж это попил денег. Сначала сократить дешевых водителей, чтобы потом внедрять дорогущий ИИ для слежки за оставшимися полтора землекопами? Это так по-нашему.
Документацию обычно читают на английском (а подчас только в оригинале ибо локализации нет совсем) и там этот стиль контрола называется breadcrumb. И в коде этот класс имеет точно такое же название, поэтому надежнее не переводить термин чтобы не было неоднозначности и толкований.
Пожалуйста, не стоит переводить термины которые не имеют широкоизвестных и устоявшихся аналогов в русском. "Хлебные крошки" - что? ??♂️ Понятнее было бы оставить оригинал "breadcrumbs". Иначе у вас получаются очередные "Ясные Печенья".
Видимо у них очередная эффективная сова завелась и хочет проявить себя для получения бонусов. А по факту, если я правильно читаю сводку, экономия в 1млн долларов для компании погоды не сделает.
https://www.google.com/finance/quote/GTLB:NASDAQ
Это гипертрофированный пример общеупотребимого интерфейса, каким он может быть предельно простым и удобным. Подобрать такой же пример для специализированного интерфейса как-то не придумывается.
Видимо это я так рассуждаю через призму своего личного опыта. Вот и не укладывается у меня в голове, что бывает классный дизайнер который еще и хороший инженер. Мне такие не встречались, а вот крайности - да, видел.
Сам в дизайн не умею вообще, но иногда приходится по работе пилить веб-морду для очередного проекта. Без слез на свое поделие потом не взглянуть. Хотя и коллеги пишут примерно так же)
Не знаком к сожалению с данной литературой, но на любительском уровне помню статьи об эргономике в журналах по радиотехнике и электронике времен позднего СССР. И там обсуждались вещи которые на западе в то время были уже давным-давно сами собой разумеющиеся. А там в статьях они преподносились как достаточные эргономические изыски (достаточные по мнению авторов для кого? кто слаще редьки ничего не видел?) выгодно отличающие тот или иной интерфейс от прочих (видимо от тех интерфейсов в которых эргономики нет от слова совсем).
Цвета приборки и шрифты думаю выбирали исключительно для надежной и безошибочной работы пилота ибо безопасность перелета и жизни пассажиров в приоритете. Подобные необходимые элементы эргономики естественно всегда учитываются в специализированных интерфейсах. А вот к примеру подстаканник для кофе как в обычных авто там у них есть? Это уже элемент удобства и для выполнения непосредственной работы пилота не связан, а значит может быть и не реализован. Я как раз про такие вещи в интерфейсах говорю, не критически важные, но удобные. Хотя это конечно субъективно все.
Легко, вот например профессиональная СВЧ печь для общепита. Только одна крутилка и все. Интерфейс максимально удобный и интуитивный для неограниченного круга пользователей. Кстати у нас в местном ТЦ точно такая же стоит, действительно очень удобно.
сама печь
Ни в коем случае не хотел как-то принизить инженеров (сам по образованию инженер), а лишь подчеркнуть разницу подходов некоего "обобщенного дизайнера", который печется о конечном пользователе и думает над эргономикой и удобством и "обобщенного инженера", который печется о богатстве функциональности и максимальном контроле системы через органы управления.
Думаю что подавляющее большинство узкоспециализированных интерфейсов проектируются инженерами для инженеров (ну или спецами только для спецов, если угодно). Приборка самолета как раз и есть такой интерфейс. Дизайнерами и эргономикой там и не пахнет, потому как в случае с приборкой самолета надо в первую очередь лететь, а не шашечки.
Подход для общеупотребимых интерфейсов другой: там надо эргономику, простоту и интуитивность вывести на первые места ибо оператор не будет обучаться, а сразу приступит к работе. Что кардинально отличается от подхода к оператору самолета (пилоту) - там и обучение специальное, и экзамены, и инструктаж.
Было бы классно, соскучился по ламповым кнопочкам аля Win98)
ЗЫ: А ведь в геймдеве не так давно пошла волна на стиль 8ми битных игр (пикселизация на основе движка unity). Смотрятся и играются такие тайтлы имхо вполне лампово, но на современном железе.
Интерфейс сам по себе не нужно обновлять, его приходится обновлять по причине:
Дело исключительно в деньгах для компании. Новые пользователи это новые деньги. Для этой цели бизнес и существует.
Как наблюдателю этого мульти-руля со стороны мне кажется, что тут как раз дизайнеров UI/UX и не было допущено вовсе, а руль проектировали исключительно инженеры. Видите эти наклеечки разбросанные то тут, то там и в разных ориентациях написания? Подобное только инженер может сделать на коленке. Дизайнер не будет смешивать стили прочтения надписей. Я на заре своей карьеры работал в инженерной компании и там в том числе тоже были мульти-рули с подобными аляпистыми органами управления. Да, свою функцию они выполняют, но и только. Ни о каком удобстве речи не идет.
Другой момент о котором вы говорите - багаж накопленного UX старой аудиторией продукта выкидывается без зазрения совести. Это бич современного производства ПО. Да, это всегда больно менять свои привычки. Сам бомблю от такого, когда без моего ведома меняют что-то к чему я годами привык. Но надо понимать, что компании постоянно расширяют аудиторию и как раз для новеньких они делают порог входа все ниже и ниже, в т.ч. и за счет упрощения UI. Хорошо это или плохо? Не знаю, вопрос дискуссионный. Выше я уже описал свои впечатления новичка от вида нового UI. Возможно мое мнение сильно поменяется если поработать с данным UI блендера профессионально по 8 часов в день. Но первое впечатление производит хорошее.
Сразу оговорка: ненавижу редизайн ради редизайна.
Однако в вашем примере как человек никогда не пользовавшийся блендером и видя два варианта интерфейса скажу, что новый выглядит субъективно лучше: иконки проще воспринимаются, не надо в них вглядываться чтобы установить мысленную ассоциацию с обозначаемым действием. Плюс в старом UI на каждой строке была иконка и в итоге весь список меню сливается визуально, перегружен. В новом иконки есть только у частых и значимых пунктов, глаз сразу цепляется за них. Вы же судя по всему просто привыкли, но старый UI был явно перегружен иконками. Здесь конкретно редизайн на мой взгляд был проведен удачно.
А для чего существует бизнес? Чтобы внезапно - зарабатывать деньги! Все остальное вторично.
И сразу первый вопрос как только о лояльности заикаются: а мне будут выплачены акции или иные активы чтобы я имел долю в компании, чтобы мог переживать за ее будущее и ее показатели? Если нет, то и суда нет.
Эта вся псевдо-корпоративная чушь работает на молодых неокрепших умом сотрудников. На условном западе это может быть оправдано как-то поддерживать подобную игру. Ведь там есть институт репутации как работника так и самой компании. Хотя там тоже деньги считать умеют и просят долю в компании за лояльность. Иначе наймите себе собаку. Совсем другой случай, что на рынке РФ репутация не значит чуть менее чем ничего. Твори ты любую дичь - всем все равно пофигу. А как показывает история последних лет даже нарушая закон в промышленных масштабах такой компании все равно ничего не будет. Например вспомним про утечки ПД и не только.
Гордятся обычно результатами своего труда или совместного труда с коллегами. Или общими достижениями фирмы, теми к чему приложил свои руки, голову, другое место, etc. Испытывать гордость за сам по себе бренд или вывеску это сродни урапатриотизму на популистские лозунги. То чем как раз всю дорогу у нас любят заниматься.
Ну так это к SQL коду непосредственно отношения не имеет. Вы здесь описываете частный случай денормализации данных, т.е. создать рядом мапу(ы) из нормализованных полей данных для ускорения поиска по частому конкретному запросу. Это скорее к теории отношений БД: как их правильно составлять и проектировать размещение данных. Никто ведь не заставляет клиентский код прибивать гвоздями к этим мапам: их можно агрегировать в соответствующие вьюхи и использовать через ORM как обычные таблицы. Вот SQL код во вьюхах и пусть оптимизирует сама БД, она и статистику соберет по запросам. И у вас выходит, что в клиентском коде зашито знание как эти данные хранятся в БД. А клиентскому коду по-хорошему знать об этих приседаниях не надо.
Другое дело, что от этого легко уйти на словах, а на практике все не так радужно. В наших проектах тоже активно используется EF и нет-нет да и прорываются запросы на голом SQL (кастомные отчеты или хитрые запросы, будь они не ладны). Те же хранимки хочешь не хочешь содержат в себе часть бизнес-логики т.е. знают как собирать данные для ответа клиенту.
Каждый раз приходя на очередной проект и видя развесистый EF спрашиваю местных:
в чем сила брат?в чем преимущество использования здесь ORM'а? И обычно первым же ответом идет чтобы легче переехать на другую СУБД "если что". Причем это самое "если что" не уточняется и не случалось чуть ли не десятилетиями. Для меня же это в первую очередь продуманная инфраструктура, удобный генератор миграций, валидация моделей классов, встроенное кеширование и прочие плюшки оптимизаций запросов. Поэтому при всех недостатках ORM'а все же выступлю за его использование. Однако учитывая текущую ситуацию все же раз в пару десятков лет это самое "если что" стреляет. Вот и у нас на горизонте замаячила задача переезда с MS SQL на что-то опенсорсное.Код SQL выше уровнем, чем клиентский код его использующий? Это как? Поясните.
Тоже сторонник годами проверенного софта и решений на его основе. Часть из вашей подборки так же юзаю. Для массовой редактуры тегов уже более 10 лет использую TagScanner, продукт отечественного разработчика. Софт с годами не разжирел и не утратил своего необходимого и достаточного функционала.
Не хочу обидеть автора или его коллег по цеху, однако все чаще возникает мысль, что либо дизайнеры забивают на UX, либо сознательно ухудшают его в угоду эээ, чему? Продажам? А если проект ничего напрямую пользователям не продает? И часто вижу, что дизайн сменили только ради дизайна. Например интерфейсы почт меил, яндекса: для ПК стали излишне крупными и громоздкими, сжирают много полезного пространства тупо на оверхед самого UI. А для мобилок проще и быстрее использовать клиент-приложение, а не веб версию.
Ну и моя критика как обычного юзера по советам выше.
п.1.: Никакого паралича нет если отдел маркетинга четко описал тарифы, услуги или планы для конкретной ЦА. А вот если проект мутный и непонятно что предлагает непонятно для какой ЦА - то тут да, мимокрокодилы будут тупить.
п.2.: CTA малоэффективен на мимокрокодилов. А для тех кто уже знает что он хочет это бессмысленно. Скорее даже раздражает если CTA навязчив, как например попап "вы на нашем сайте уже 15 секунд, может вам позвать в чатик нашего консультанта?". Или плагин аля живосайт справа внизу выскакивающий как по расписанию. На мобильной версии так вообще он закрывает почти весь экран. Серьезно, не надо так)
п.4.: Нет смысла лепить кучу плашек "Verified by Visa", etc ибо это обычно картинки которые никуда не ведут ни на какой оф сайт платежной системы. Таким образом они ничего юзеру не говорят и не подтверждают безопасность или аккредитацию данного способа оплаты. Гораздо важнее писать, что за платежный шлюз использует проект, его политику обработки ПД и т.п. Особенно если это не отдельная страница, а встроенная форма.
п.7: Обычно TTA сильно переоценен. Можно подумать над рациональным ускорением, но без фанатизма. Если ваш проект имеет прямые продажи и товар\услуга релевантны для пользователя он подождет загрузку и две, и три, и даже пять секунд. А если это мимокрокодил, то даже при моментальной загрузке не факт что он что-то купит.
Говорю ж это попил денег. Сначала сократить дешевых водителей, чтобы потом внедрять дорогущий ИИ для слежки за оставшимися полтора землекопами? Это так по-нашему.
https://www.rbc.ru/business/08/06/2022/62a0dcf69a7947296d6b1a70
Экономия электричества? Три раза ха. Больше похоже, что это для обязательной установки СОРМов и штрафов за несоблюдение законодательства.