Интерфейсы *

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

XXI век уверенно шагает по планете. Холивары вспыхивают не только в секторе Газа, но и на форумах, в комментариях, телеграмм-каналах. Лет 50 назад люди думали, что FIDO -- это лучшая система для общения людей по всему миру: быстрая и... ну, относительно, надёжная. Но какой это был кайф -- пять минут t(k)-mail мучает модем и выкачивает архивы "эх", парматоссер раскладывает всё по местам, и в финале ты запускаешь своего любимого голого деда... Тихо-тихо, GoldEd -- редактор почты, всего-лишь. Запускаешь -- и ты соединился с миром! Ты можешь общаться с миллионами людей по всему миру... в формате текста. Да-да, никаких тебе гиперссылок, картинок, крутых интерфейсов. Даже мышки нет, всё на клавиатуре.

Нет-нет, Интернеты в то время уже были. Кое-где в этих Интернетах даже были картинки, естественно -- для взрослых. Странички на сайтах были настолько простыми. что сейчас за подобную поделку в школе, в первом классе ставили бы 2. Но, имея модем и повременку особого выхода небыло. Помните знаменитое "только не дисконнект, только не дисконнект..."? Да, интерфейс был самым простым...

Сегодня всё совсем не так! Знали бы мы, сегодня в часах процессоры будут в разы производительнее, чем в те годы? Мечтали, конечно. Нам думалось, что скучный NC или, позднее, windows 95, Far, да и вообще всё в компе станет чуточку круче. Таким, как нам рисовали в фильмах -- с крутыми дисплеями, офигенными интерфейсами, космически-футуристичными... Да, мы мечтали.

А что же мы получили в итоге, и так ли это круто -- иметь супер технологичный интерфейс, безумно красивый и неимоверно навороченный, или лучше попроще, но удобный? Давай смотреть!

Привет, Хабр!

Перед следующей статьей из цикла «Приключения микропроцессоров» мы решили поговорить с вами о GUI. Из года в год система взаимодействия ОС, ПО и пользователей совершенствовалась. Аппаратные методы общения с компьютером уступили место интерфейсу командной строки. Командная строка «сдалась» под напором файл-менеджеров. И, наконец, появились полностью графические интерфейсы пользователя с привычными окнами, выпадающими меню и прочими удобствами.

Сегодня мы хотели бы поговорить о том, как развивался графический пользовательский интерфейс на протяжении последних 50 лет. Под катом рассмотрим некоторые интересные образчики применения GUI, необычные ОС и компьютеры. Как обычно, с массой фото- и видео-материалов. Потому что, как говорила Алиса, «что же это за книжка, в которой нет картинок?».

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

Как их только не называют: техписы, техрайтеры, документаторы... Хорошо, хоть не архивариусы!

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

— Кто за сутки до отправки заказчику во всей инструкции заменил manual на manul?!

Сегодня расскажу из собственного опыта, с какими проблемами сталкиваются в продвижении IT-компании и как их решить.

При создании графического интерфейса для HAProxy мы столкнулись с необходимостью решать проблемы языка. Удобный интерфейс невозможен без текстов, и удовлетворение пользователя во многом связано с тем, насколько ясно и понятно написаны тексты инструкций, подсказок, какие слова используются для описания кнопок и пунктов меню и т.п. Если все эти тексты перегружены малопонятной терминологией, содержат лексические и стилистические ошибки — о каком удобстве для пользователя можно тут говорить?

Roxy-WI —продукт очень сложный и специфический, и над текстами интерфейсов в процессе пришлось поломать голову. Этим опытом, а также некоторыми дополнительными размышлениями, мы бы хотели поделиться ниже.

Я UX/UI-дизайнер, уже два года работаю в ISPsystem. Одной из глобальных моих задач все это время было сделать нашу дизайн-систему удобной для использования.Полноценная дизайн-система — с гайдами, состояниями и борьбой с разработчиками — испытание не только для новичка в дизайне, но и для опытного проектировщика. Сейчас мы на пути к идеальной дизайн-системе, но решили поделиться опытом ее проработки - кому-то может помочь избежать наших ошибок :)

Для чего все затевается

ISPsystem создает программное обеспечение для управления IT-инфраструктурой: физическим оборудованием, серверной виртуализацией, веб-сервером и сайтами. Сейчас существует четыре продукта со схожей дизайн-системой (VMmanager, DCImanager, ISPmanager и BILLmanager) и один — со своей собственной (billix).

Этот текст мы посвящаем всем, кто никогда не работал с редактором или только начал с ним работать. А ещё этот материал будет полезен начинающим UX-редакторам, так как будем обсуждать hard skills на реальных кейсах, которыми важно обладать хорошему специалисту.

В статье я расскажу о том, как разрабатывать дизайн доступных (т. е. отвечающих требованиям доступности) компонентов, об основных руководствах по доступности и о ключевых моментах, на которые стоит обратить внимание, а именно: о порядке фокуса, о клавиатурном взаимодействии и об ARIA-атрибутах.

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

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

- разные отступы у элементов;

- не прорисованы состояния кнопок;

- не хватает нужных элементов и т. д.

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

Зачем вообще в 2021 году заниматься банкоматами? Кажется, что уже все кто только можно перешли на безнал. Но на самом деле количество пользователей банкоматов Тинькофф растет, причем быстрее, чем количество клиентов. То есть людям все равно нужен нал: они платят за квартиру или получают зарплату на счет в другом банке и перекладывают ее в Тинькофф. 

Сейчас в сети Тинькофф больше 2500 банкоматов, и около 27% аудитории банка регулярно ими пользуется. 

Интерфейс банкоматов, который работал все это время, — довольно хороший. Он занимает призовые места в рейтингах, и пользователи им довольны.

Но мы решили его поменять. 

В этой статье мне бы хотелось поделиться пользовательским опытом, связанной с Windows 11, которой я на момент написания статьи пользуюсь примерно месяц с лишним.

Эта статья является продолжением моего «крестового похода» против ветряных мельниц убогих современных тенденций в разметке и оформлении веб-приложений (статья1, статья2). И, поверьте — солидная ее часть — это толерантная, такая, чтобы никоим образом не нарушить NDA, переработка реального доноса код-ревью кода важного боевого проекта для руководства одной из команд в которых мне приходилось участвовать. До этого момента я породил уже три достаточно злых, токсичных длиннопоста для сообщества, и, о чудо — ни один из них не умудрился скатился в минус (но последний был близок). И на этот раз — я готов! Ибо этот пост именно о тех технологиях и подходах к верстке, которые мне[, конечно же, на основе коммерческого опыта] кажутся весьма неудачными и неэффективными, неадекватными в очень многих ситуациях. Конечно, существуют команды, проекты, требования когда каждый из этих подходов может окажется вполне приемлемым и уместным. Но на деле, чаще всего, имхо, оказывается, что поборники данных методов — безальтернативно «подсаживаются на любимую иглу» и упорно не хотят знать и уметь, использовать ничего другого... Мне вообще кажется что мир вокруг нас сейчас это, утопия, практически целиком, максимально упрощенная тотальным засильем пролоббированного рептилоидами, мировой закулисой корпорациями тоталитарного глобального мейнстрима, и это одинаково касается всех сфер жизни, культуры, вот тут можно почитать мою философскую статью на тему применительно как раз к интерфейсам Куда подевались социальные сети? Пропаганда и реклама вместо общения... И даже наш любимый журнал о технической культуре, по сути, превратился в рекламную помойку, по большей части, унылое отражение глобального общественного тренда... Но, как известно — «главное попытаться», поэтому — поехали!

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

В свое время Алан Купер сформулировал «метод персон» (или персонажей) — фреймворк, в рамках которого разрабатывается усредненный портрет типичного пользователя какого-либо интерфейса. По мнению автора, только проявив эмпатию, поняв цели и задачи людей, можно придумать какое-либо решение и разработать удобный продукт, который им понравится.

Несмотря на то что с момента появления книги было написано большое количество гайдов по персонам, отрасль не стояла на месте. Появлялись новые методы проектирования и другие интересные фреймворки. И вроде бы персонажи отошли на второй план, уступив место новым механикам. Например, многие сторонники Jobs-To-Be-Done убеждены в том, что их методология значительно превосходит персоны в плане практического применения. Но так ли это?

Мы считаем, что персоны сейчас более чем актуальны и способны повысить эффективность процесса работы над цифровым продуктом. Далее в статье мы покажем, что данный метод вовсе не противоречит новым подходам, в том числе Jobs-To-Be-Done. Но, наоборот, прекрасно их дополняет, а в некоторых случаях лежит в основе. В общем, обо всем по порядку.

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

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

Легко ли разработать новый API? На что обратить внимание, чтобы не ошибиться при реализации, и к каким компромиссам стоит быть готовым?

Привет, Хабр! Меня зовут Иван Ивашковский. Я руковожу группой разработки международных проектов в Яндекс Go. Этот пост — продолжение цикла историй о вымышленном стажёре Васе. Предыдущий материал, про идемпотентность, можно почитать здесь. В посте я расскажу, как Вася разрабатывал API для новой фичи и с какими проблемами он столкнулся в процессе. В конце приведу чеклист с советами, как проверить себя на каждом этапе разработки, если вы решаете похожую задачу.

Около десяти лет назад сообщество веб-разработчиков впервые начало обсуждать концепцию "Single-Page Application" и искать способы ее реализации. К тому моменту разработка графических интерфейсов уже не являлась чем-то новым и поэтому многие вещи заимствовались у существующих решений и немного адаптировались под специфику браузеров.

Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...

Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?

Это работа является логическим продолжением моего первого подробного текста для сообщества об актуальных подходах к верстке Как верстать веб-интерфейсы быстро, качественно и интересно. Но, если в первом трактате, внимание уделялось, прежде всего, стилю кода, его качеству и эффектным современным возможностям различных препроцессоров и фреймворков, что демонстрировалось на некоторых конкретных специфических задачах, теперь хочется сфокусироваться на архитектурных или даже организационных аспектах веб-производства. Если вы не читали мой первый текст, но собираетесь при этом прочесть этот — не поленитесь перейти по ссылке и пробежать глазами самые последние разделы каждой из двух частей первого пособия: «Готовые решения» и «Песочницы». Этот текст начинает прямо с этих мест и развивает именно эти идеи: и о пагубности применения раскрученных-популярных «на все готовых» UI-«дизайн-систем»-фреймворков для создания кастомизированных веб-морд любой сложности и, о, по сути, полезности использования хотя бы минимального документирования и явных соглашений при разработке веб-GUI на фронтенде. Но я не стану тратить время, доказывая, что «ни в коем случае нельзя использовать Vuetify или AntDesign» для создания крупных UI-систем с полностью кастомным оформлением. Вам не нужно прикручивать себе огромный геморрой непроницаемый слой плохо кастомизируемого готового GUI для того чтобы написать кнопку или поле ввода! Если вам нужен датапикер — найдите и допилите что-нибудь под себя. Это понимание может только прийти или так и не придти с годами тяжелого опыта, когда вы будете постоянно тратить непростительно много своего времени на то, чтобы написать очевидно отвратительный CSS — «кряки с !important`ами поверх стилей библиотеки», выдумывать чудные костыли на javascript чтобы изменить дефолтное поведение виджетов на кастомное и хитрое-нестандартное затребованное вашими дизайнерами... И при этом ваши шаблоны, стили и js-обвязки будут превращаться во все менее читаемые запутанные нагромождения разнообразно оформленного кода, с различным подходом к наименованию и прочими бедами… Этот текст и написанный для него проект призваны наглядно показать «а как надо?».

Всегда ли обновление дизайна — это хорошо для сайта с точки зрения SEO? Нет, не всегда. Более того, часто редизайн влечет за собой ухудшение позиций. Так может, лучше не трогать то, что и так работает?

Опыт показывает, что изменение и обновление дизайна сайта раз в несколько лет — решение в очень правильное. Оно помогает улучшить юзабилити, увеличить конверсии и поднять позиции. Но почему тогда многие владельцы сайтов сталкиваются с совершенно обратным эффектом?