Istoriya.v.ua

Коротка шпаргалка за клавішами в IntelliJ IDEA

Як раніше повідомлялося, я почав активно вивчати можливості IntelliJ IDEA. Зокрема, я намагаюся запам'ятати найбільш затребувані хоткеї, щоб виконувати бобільшу частину роботи, не відриваючи руки від клавіатури, як це відбувається при програмуванні Vim. За моїми спостереженнями, це реально заощаджує купу часу. Я зробив собі шпаргалку по хоткеям IDEA, яку ви знайдете під катом. Думаю, вона також стане в нагоді комусь із відвідувачів даного блогу.

Примітка: Ті ж поєднання клавіш працюють і в інших продуктах JetBrains, наприклад PyCharm і CLion.

Нижче не наводяться загальновідомі і очевидні поєднання на кшталт Ctr+C, Ctr+V або Ctr+S. У IntelliJ IDEA багато хоткеї мають парний хоткей, що відрізняється тільки тим, що в ньому додатково бере участь клавіша Shift. Зазвичай вона додає у тому чи іншому вигляді виділення тексту. Наприклад, Ctr+End переводить курсор у кінець файлу, а Ctr+Shift+End виділяє код від поточної позиції до кінця файлу. Здогадатися про існування парних хоткеїв нескладно, тому вони не наводяться. Нарешті, якщо у будь-якому діалозі IntelliJ IDEA ви бачите підкреслені літери, знайте, що поєднання Alt + літера рівносильне використанню відповідного контролю (зазвичай кнопок). Наприклад, швидко запустити код у репозиторій можна шляхом натискання Ctr + K, Alt + I, Alt + P, а потім знову Alt + P.

Отже, основні поєднання такі.

Редагування:

Вікна, вкладки:

Закладки:

Підказки та документація:

Генерація коду та рефакторинг:

Інше:

Зрозуміло, у цій шпаргалці названі далеко не всі можливості IntelliJ IDEA. Всім зацікавленим особам я настійно рекомендую прямо брати і читати її чудову документацію, там дуже багато цікавого.Жаль тільки, що документація не доступна у вигляді одного великого PDF файлу.

Додаток: В останніх версіях IDEA можна використовувати декілька курсорів, розмістивши їх або за допомогою комбінації Alt+Shift+ЛКМ, або вертикальним виділенням за допомогою кліка середньою кнопкою миші. Тримаючи на озброєнні поєднання Ctr + ліворуч/праворуч, що здійснює перехід між словами, а також інші, можна дуже зручно редагувати відразу кілька рядків коду.

Ви можете надіслати коментар мені на пошту, або скористатися коментарями в Telegram-групі.

Принципи проектування інтерфейсів команди дизайнерів IntelliJ IDEA.

Середовище розробки – такий самий важливий інструмент для розробників, як графічний редактор для дизайнерів. Це саме той додаток, де можна написати код і зібрати з нього будь-яку іншу програму або сайт.

IntelliJ IDEA – популярне середовище розробки (IDE) для мови програмування Java. Можливо, ви й самі користуєтеся ним або однією з десяти IDE компанії JetBrains: WebStorm, PyCharm, GoLand, Rider і так далі. Всі ці продукти побудовані на платформі IntelliJ і мають спільний інтерфейс користувача.

UX-, UI-дизайнери у команді розробки IntelliJ IDEA допомагають робити інтерфейс зручнішим для наших користувачів. Щоб визначити, що таке «зручніше» для себе, колег-розробників і користувачів, ми використовуємо принципи проектування.

Головний екран IntelliJ IDEA: зліва всі файли проекту, праворуч код

Звідки беруться принципи

Люди задоволені продуктом, якщо відчувають, що рухаються до своєї мети і не відчувають естетичних протиріч. Просто, має бути зручно та красиво.

«Красиво» – це відповідність сучасним візуальним нормам.Наші IDE десктопні рішення в цій галузі обмежені інтерфейсами операційних систем. Тому ми частіше думаємо про «зручно».

Думаю, що «зручно» можна сформулювати так: більшість користувачів вирішує завдання максимально швидко.

Це формулювання занадто абстрактне, і його складно застосовувати на практиці. Простіше використовувати конкретні принципи, які у сумі забезпечують те саме. Ці принципи:

• Швидкість доступу до елементів інтерфейсу.
• Економія уваги.
• Інформативність.
• Знахідність.
• Звички.
• Складність розробки.

У списку немає таких понять як «відповідність цілям та сценаріям користувача», «теорія близькості» або «швидкість роботи програми» — все це має працювати за умовчанням.

Принципи залишають простір для рішень. Розберу способи прийняття таких рішень на прикладах інтерфейсів користувача в IntelliJ IDEA.

Принципи

Швидкість доступу до елементів інтерфейсу

Швидкість доступу — як швидко можна підвести курсор до елемента, наскільки швидко прицілитися. Тут діє Закон Фіттса: час прицілювання прямо пропорційно відстані, обернено пропорційно розміру об'єкта прицілювання. Тобто у велику кнопку поруч із курсором прицілитися швидше, ніж у маленьку кнопку далеко.

Така маленька кнопка була на тулбарі в головному вікні IntelliJ IDEA — кнопка з трикутником на скріншоті:

Додали кнопці лейбл "Add Configuration". Кнопка стала великою, і цілитися стало зручніше:

Часто задля досягнення мети потрібно прицілитися до кількох об'єктів поспіль. Чим більше об'єктів, тим повільніший доступ. Та сама кнопка з трикутником спочатку відкривала меню, в якому потрібно було прицілитися до єдиного пункту:

У варіанті з кнопкою прицілитися потрібно лише один раз до самої кнопки.

Економія уваги

Увага людини – ресурс, не потрібно витрачати його зазря. В інтерфейсах увага часто витрачається на перемикання контексту.

Наприклад, раніше повідомлення про валідацію полів відображалося внизу діалогу. Часто поле з помилкою виявлялося далеко від повідомлення, користувачеві доводилося бігати очима від одного місця до іншого:

До: поле з помилкою вгорі діалогу, повідомлення про помилку внизу

Виправили, щоб помилка з'являлася біля поля, де вона сталася. Тепер увага не витрачається на перемикання між різними галузями діалогу:

Після: поле з проблемою та повідомлення про помилку в одному місці

Переключення контексту часто відбувається у модальних діалогах. Модальний діалог змушує витрачати увагу, щоб зорієнтуватися у новому інтерфейсі. У IntelliJ IDEA звичайним підходом було відкрити модальний діалог, якщо потрібно збільшити область введення:

До: кнопка відкриває модальний діалог

Щоб увага не витрачалася, вирішили розширювати саме поле:

Після: кнопка розгортає немодальне поле

Ще увагу можна витратити на занадто помітний елемент інтерфейсу, коли він не повинен бути помітним. Хотіли пояснити в нотифікації, навіщо вона з'являється, і додали сірий текст:

До: довгий відволікаючий сірий текст

Але нотифікація з'являється часто, навіщо щоразу відволікати людей підказкою, яку вони вже, можливо, вивчили. Можна сховати її під менш помітний знак питання і заощадити увагу:

Після: іконка, що не відволікає, зі знаком питання

Інформативність

Інформативність – це частка корисної інформації у загальному обсязі повідомлення, тобто співвідношення сигнал/шум. Покращувати інформативність можна двома способами: додати сигнал чи зменшити шум.

Приклад із додаванням сигналу.У IntelliJ IDEA є можливість переміщатися назад/перед місцями коду, де знаходився курсор (дії Navigate Back/Forward). Не завжди легко згадати, де коду каретка була якийсь час тому, і незрозуміло, чи потрібно туди повертатися. Додали інформацію для вирішення цієї проблеми – показали шматочки коду, де був курсор, в окремому попапі:

Попап наочно показує, де коду недавно знаходився курсор

Інший приклад, коли прибираємо шум. Кілька версій тому ми мали багато тулбарів з 10–20 іконками. У такій кількості іконок важко знайти потрібну. Ми зібрали статистику кліків на тулбарах. Ті дії, які використовували менше 0,1% користувачів (темно-червоний), ми вилучили з тулбарів, інші дії згрупували або перемістили, найбільш використовувані винесли на початок тулбара. Тепер шуму менше, знайти потрібну іконку простіше:

Коли іконок менше, знайти потрібне простіше

Знахідність

Фіча може бути корисною, але якщо користувачі про неї не знають – все одно, що немає фічі.

У IntelliJ IDEA можна шукати файли, класи та інші сутності проекту або дії самої IDE. Раніше було п'ять схожих пошукових інтерфейсів: свій для кожної категорії і один пошук для всіх. Потрібно було знати, як викликати кожен окремо.

П'ять попапів для пошуку різних сутностей потрібно знати про кожен

Щоб не потрібно було знаходити кожен із попапів, поєднали їх в один. Тепер достатньо одного шорткату (Shift+Shift), щоб дізнатися, які об'єкти можна шукати – всі вони перераховані в заголовку попапа, і між ними можна легко перемикатися клавішею Tab:

Один попап для пошуку всіх сутностей. Простіше знайти, ніж п'ять окремих

Або ще випадок. Одна з найкорисніших дій у IntelliJ IDEA – Show Context Actions із шорткатом Alt+Enter.Воно підказує, як зробити код правильнішим, дозволяє запустити його, снавігуватися у пов'язані сутності та багато іншого. Наприклад, можна поставити курсор на код із проблемою, натиснути Alt+Enter і побачити список дій, які виправлять код автоматично:

Контекстні дії в IntelliJ IDEA нагадують, як виправити код

Але дізнатися про Show Context Actions можна, але тільки якщо помітиш і натиснеш іконку-лампочку (вона відкриває це меню) або відкриєш контекстне меню. Обидва способи легко пропустити. Натомість після наведення курсору миші на код із проблемою з'являється тултип з описом помилки, знайти його набагато простіше:

До: тултип із проблемою в коді

Логічно пов'язати опис помилки з діями її виправлення. Додали дії в тултип, і кількість використання Show Context Actions IntelliJ IDEA зросла з 60% до 70%.

Після: тултип із проблемою та з контекстними діями — проблема і як виправити в одному місці

Звички

Дотримання звичок користувачів допомагає всім попереднім пунктам – звичні елементи швидше знайти і зрозуміти. Як ми зберігаємо звичку:

1. Використовуємо важливі інтерфейсні шаблони операційних систем. Наприклад, у macOS кнопка "OK" справа, а в Windows – зліва.

Кнопки OK та Cancel у різному порядку у macOS та Windows

1. Використовуємо один шаблон взаємодії для однакових завдань. Наприклад, раніше клавіатурні розкладки, колірні схеми редактора коду та профілі інспекцій коду керувалися трьома різними інтерфейсами, хоча для всіх дій були майже однакові:

До: три різні інтерфейси для одного способу взаємодії

Замінили на однаковий інтерфейс, щоб користувачам було простіше розібратися з керуванням новою сутністю, якщо вже стикалися зі схожою раніше. У всіх дії тепер у меню під шестернею:

Після: однаковий інтерфейс одного способу взаємодії"

1. Використовуємо знайомі рішення з навколишнього світу, якщо нічого потрібного немає у нашому власному інтерфейсі чи операційних системах. Нещодавно з'явилася можливість робити плагін до наших IDE платними. Тепер платні плагіни мають свою ліцензію, і якщо вона не активована, потрібно якось це показати. Як це зробити?

Можна намалювати іконки продукту і плагінів неактивними, але виглядає, ніби пункт списку цілком недоступний:

Значок виглядає недоступним (disabled)

Можна зробити іконки напівпрозорими, передати метафору «щось не вистачає». Але такий прийом не використовується в IntelliJ IDEA, вигляд незвичний, і метафору можуть не зрозуміти:

Метафору напівпрозорої іконки важко зрозуміти

Тому вирішили використати звичний символ знака "стоп" для значення "стій, щось не так":

Додаткова іконка «стоп» швидше передає сенс «щось не так»

Складність розробки

Дизайнер може вигадати інтерфейс, розробляти який доведеться рік. Весь цей час проблему користувачів не буде вирішено. Тому краще вигадати щось простіше і принести користь швидше.

приклад. Тексти для інтерфейсу користувача зручно записувати в окремих файлах, а не у файлі з кодом. Наприклад, це корисно для перекладу різними мовами — все, що потрібно перекласти, видно в одному місці:

Приклад файлу з текстами для інтерфейсу користувача. Тексти – зелені, їх ідентифікатори – сині

У файлі з кодом, який показує текст, вказуємо звернення до ідентифікатора тексту:

Тут ідентифікатор став зеленим, це коректна поведінка, але для прикладу неважлива

Замість ідентифікатора зручно показати прев'ю тексту — зрозуміло, що буде виведено в інтерфейс.Таке прев'ю відображається в IntelliJ IDEA автоматично:

У файлі з кодом замість незрозумілого ідентифікатора показуємо зрозумілий текст

Іноді текст потрібно відредагувати. Щоб не переходити у файл, де зберігається текст, дизайнери запропонували редагувати прев'ю тексту (раніше редагувати було неможливо):

Видаляємо слово Toggle

Але виявилося, що розробити редагування тексту, який фактично зберігається в іншому файлі — складно і довго. Тому вирішили обійтися існуючими компонентами: показати поверх коду поле введення з текстом з іншого файлу, а в тултіпі підказати, як запустити редагування.

Натискаємо посилання Edit Property Value, запускається редагування

Завдання вирішене, хай і менш елегантно, але набагато швидше.

Усі принципи разом

Щоб зрозуміти, чи хороший інтерфейс, потрібно оцінити, як у ньому виконуються все принципи. Візьмемо для прикладу ту ж кнопку на тулбарі головного вікна та оцінимо новий варіант за принципами:

• Швидкість доступу: як говорилося, у велику кнопку прицілитися швидше, ніж у маленьку кнопку, та був у меню під нею.
• Економія уваги: кнопка стала помітнішою, але це невелика проблема, тому що кнопка важлива – з неї можна почати роботу, якщо потрібно запустити код.
• Інформативність: тепер на кнопці написано, що вона робить – це корисна інформація, стало зрозуміло, навіщо потрібна кнопка.
• Знахідність: тепер людям простіше знайти, як створити run/debug конфігурацію, щоб запустити код – текст на кнопці явно вказує на це.
• Звичка та складність розробки: кнопка – стандартний елемент, проблем немає.

Варіант із кнопкою — порівняно простий. Зазвичай для такого інтерфейсу досить умоглядної оцінки. Для варіантів складніше не завжди виходить оцінити в умі.

Розглянемо варіант складніше: діалог створення класу, інтерфейсу чи елемента іншого типу даних (клас та інтерфейс – поняття з програмування). У діалозі можна записати ім'я елемента та вибрати його тип у списку Kind:

Діалог створення класу та інших абстрактних типів даних у коді

За замовчуванням список типів прихований і може бути складно зрозуміти, які є варіанти. Якщо курсор знаходиться в полі Name, то Kind можна перемикати кнопками Вгору/Вниз на клавіатурі, на що натякає ↑↓ праворуч від Name. Але цей спосіб підказки незвичний, метафора іконки незрозуміла і в результаті знайти цю функціональність складно.

В одній із команд запропонували вручну вводити тип елемента в полі Name, щоб не потрібно було перемикатися до комбобоксу Kind і вибирати з довгого списку. Дизайнери запропонували ще два рішення: використовувати попап із підказкою та показувати всі типи у списку під полем Name. Усі варіанти разом:

Щоб не забути жоден із принципів у процесі порівняння, запишемо до таблички. Кольором відзначено оцінку, наскільки добре виконується принцип. Колір допомагає поглядом оцінити найбільш вдалий варіант:

По табличці видно, що з варіанта з усіма типами у списку під полем (4) найбільше зеленого, але все одно не ідеальний. Це звичайна ситуація, бо примирити усі принципи складно. У такому випадку можна вибрати найвиграшніший варіант і окремо вирішити його проблеми.

Принципи допомагають вибрати найкращий варіант інтерфейсу на етапі проектування та розробки. Але вони не гарантують, що рішення буде ідеальним – користувачів багато, цілі та способи вирішення завдань у них можуть бути різними, складно врахувати все одразу.

Тому після розробки ми завжди стежимо, як наші колеги та люди за межами компанії користуються новим інтерфейсом, проводимо UX-дослідження та доопрацьовуємо, якщо щось залишилося незручним.

Опубліковано на сайті видання "vc.ru".