Ті, хто користуються macOS починаючи з версії 11, могли помітити, що у Preview є можливість виділяти та копіювати текст з зображень. У систему вбудований непоганий розпізнавач тексту (OCR). Але не всі знають, що його можна викликати не тільки у Preview, а застосувати до будь-чого.

За допомогою Shortcuts я створив два сценарії розпізнавання тексту: з виділеної частини екрана, як при скриншоті, та з вибраного файлу у Finder. Результат копіюється образу в буфер і його можна образу вставляти куди треба. При цьому можна також додати гарячі клавіші для виклику кожного, наприклад, для розпізнавання з екрану у мене це ⌘7.

Нижче викладаю самі файли Shortcuts, які можете додати собі. Продуктивної роботи всім 🦾

• Розпізнавання з частини екрану
• Розпізнавання з файлу

Понад рік використовую Cursor для створення робочих інструменті: від окремих скриптів до робочих застосунків та плагінів для браузера. Влітку мені навіть писали з Курсору, сказали що я у «топ 1% юзерів в Києві» (хз, як вони це міряли) та запрошували на мітап 😁

І зараз вони зробили підсумки року, у вигляді красивої сторінки та красивих цифр — 3,4 тисяч агентів (чатів) та 1,69 млрд токенів. На початку найбільше використовував модель Claude, у порівнянні з іншими вона давала завжди більш робочий результат. Потім авторежим моделі, і коли він не давав потрібний результат перемикав вручну на Claude. Останнім часом пробую їхню модель Composer, яка менша і працює швидше.

Що цікавого можу відмітити за рік використання.

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

Використання будь-яких мов програмування
Є частина інструментів які створені для Python, деякі — як вебфреймворк, або ж щось під бази даних. Раніше на їх вивчення могло б піти багато часу, щоб зрозуміти, як правильно працювати з тою чи іншою мовою та технологією. Особливо це стосується веб-фреймворків, які, таке відчуття, що кожен пише свій, і тільки на те, щоб його обрати треба витратити додаткові когнітивні зусилля (а може я вже старий, бо чистий JS мені зрозуміліший). Я так збирав по частинах одну апку, де частину роботи виконують Python-скрипти, як-то транскрибація аудіо в текст за допомогою Whisper, а вже фронт зроблений на NextJS.

LLM допомагають перекласти звичайну мову у мову програм
Є багато вже розроблених програм, часто які працюють в консолі/терміналі, і які насправді можуть закривати багато поточних потреб і рутинних задач. Але у них високий поріг входу: треба розуміти як це працює і як їх використати. Так от LLM, на мій погляд, прекрасно підходять для того, щоб почати їх використовувати у повсякденній роботі. Наприклад, я зробив пачку швидких дій у MacOS які конвертують картинки чи відео в різні формати, або ж роблять відео на швидкості ×2…×4, коли я роблю скрінкаст і демо роботи чогось, роблять чи розбирають PDF, зклеює картинки тощо (якщо цікаво, окремо покажу та розпишу приклади). Зокрема по цій схемі існує цілий застосунок AI-термінал — Warp. Так і Cursor активно взаємодіє з термінальними програмами.

Ідеально для R&D та малих проєктів
Цей пункт випливає з попередніх. Це можливість швидко зібрати робочий прототип і протестувати чи все працює як задумано. І далі або розвивати далі створений інструмент чи викинути й попробувати щось робити інакше. Іноді навіть створити дашборд з візуалізацією ваших даних іноді навіть простіше і швидше згенерувавши сторінку на D3.js, ніж намагаючись зробити те саме в Екселі. Але важливо розуміти, що інструменти генерації коду, можливо, не роблять ідеальний код і тому його треба використовувати обережно у великих проєктах та проєктах, де важлива безпека.

Простіше починати одразу з коду, а не з макета у Figma
Помітив за собою що вже не так хочеться робити макети у Фігмі, які потім потрібно якось ще переносити у код, і набагато простіше одразу почати роботу з кодом, отримуючи вже інтерактивний інструмент, замість придумування і малювання окремих версій усіх елементів. Так AI/LLM може понапридумувати аж занадто своєрідний стиль, особливо якщо не сильно описати бажаний результат, але за кілька ітерацій результат вдається стабілізувати. Тут у нагоді може стати подивитись як запит обробляє Firebase: детально описує стиль тексту та іконок, кольори, анімацію.

Результат обмірковування моделі перед створенням самого коду застосунку

Залежність від інструментів
Але є і суттєвий мінус: коли щось трапляється з оплатою, або немає можливості підключитись для використання моделей — вважайте що лишаєтесь безпорадними, не в змозі продовжувати активну роботу. На відміну від знання мови, яке можна використати не залежно від наявності підписки. Сюди ж можна додати використання будь-яких мов у різних проєктах — поступово просто перестаєш пам’ятати як влаштовані різні проєкти і через це більше потребуєш моделей, які мають то все зчитувати.

Особливості роботи з генерацією коду

Написання документації та інструкцій
Щоб Курсор чи інші моделі згенерували вам найбільш точний результат — йому потрібно якомога точніше описати, що вам треба. Тобто як і в класичному процесі розробки — створити документацію. І цей крок має бути першим. Це іноді трохи лінь робити, бо доводиться описувати наче очевидні речі. В принципі, для цього у тому ж Курсорі присутній режим Планування — на ваш запит і опис модель створює план (як звичайний ntrcnjdbq md-файл) з описом кроків. Що дає змогу почати. Або ж іти меншими кроками нарощуючи потрібні функції і потрібний вигляд саме почерговими запитами.

Знання бази та перевірка результату
Як і результат будь-яких мовних моделей результати створення коду треба перевіряти на галюцинації. І бажано орієнтуватись хоча б базово це цикл, де умови, де змінні та функції тощо. Ну і просити модель просто поміняти колір елементу через запит — це не ефективне використання ресурсів.

Що почитати

Українською не так багато матеріалів на тему, але оці цікаві:

• Технічна база для дизайну — те, про що соромно запитати у розробників. Для дизайнерів без досвіду розробки у цій статті від роз’яснення основ, до початку використання цього у роботі разом
• Cursor Rules: як навчити AI працювати з вашим проєктом. Поради по тоншому налаштуванню Cursor: використання правил .cursorrules, AGENTS.md тощо.

Душний p.s.

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

Процес проєктування більш схожий на сцену з Залізної людини, коли Тоні Старк проєктує в голові загальну концепцію і розуміє, що конкретно треба, але всю реалізацію бере на себе Джарвіс. Так і з Курсором: проєктуючи у себе в голові, цеглинка за цеглинкою складається і розвивається готове рішення.

Q: Привіт! Хотів спитати, бо я іноді заходжу на твій сайт, і часто бачу кодінг. Як взагалі відносишся до кодінгу у дизайні? думаю, може варто вивчити щось і закодіть, бо я бачу ти часто використовуєш програмування у дизайні

A: В принципі, для дизайну, як такого, кодінг не потрібен. Це просто додатковий інструмент для спрощення деяких видів задач у повсякденній роботі. Або ж можливість самостійно можна закривати більшу частину рутини, без додаткової комунікації (комусь, як мені, це в плюс 😅).

Мені нещодавно сказали, що вже є термін Design Engineer, про дизайнерів-кодерів. Виходить це оформлюється в цілий напрям, особливо з розвитком технічних інструментів.

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

Основне — розуміти алгоритми, як взагалі працюють будь-які програми (змінні, умови, цикли, типи даних тощо). З цим знанням вже можна пошукати в Гуглі рішення чи приклади коду на Stackoverflow в цей алгоритм. Зараз все частіше ще питаю у ChatGPT/Gemini/Claude3 і вони все частіше видають робочий код.

І дивлячись на практики розробників, можна собі в дизайн роботу щось теж взяти. Наприклад CI/CD (continuous integration and continuous delivery). Це автоматична збірка коду, його тестування та публікація. Це дозволяє дуже швидко вносити зміни.

У дизайні цей приклад можна порівняти з підтримкою проєкта та оновленням макетів.

Наприклад, схема метро має кілька видів: у вагон біла, у вагон прозора, на стенди та на стінах швидкісний трамвай (при чому з відміткою на кожній станції, це 18 макетів). Коли перейменовують якусь станцію чи відбуваються якісь зміни, то потрібно оновлювати цей весь парк.

Є два основних макети в АІ: біла схема і темна. Далі всі світлі через різні шаблони в ID готуються під різні розміри (вагон, стенд, трамвай). А в кінці окремі скрипти нарізають, масштабують і перейменовують однаково всі трамвайні схеми. Щось ще перезберігається в TIFF, бо так вимагає типографія.

Налаштування цього займає певний час, але потім окупається. Бо робити це все руками при кожному оновленні займає кожен раз купу часу. Якщо ви стикаєтесь з тим що вже більше трьох разів робите одні і ті самі дії, то можна подумати як то автоматизувати. Бо один раз це випадковість, два — збіг, три — тенденція 😌

Переніс сюди свій тред про кишенькові схеми метро і доповнив ще деякими фото.

Поки збирав матеріал по кишенькових схемах на сайт, то зроблю тред. Загалом виходило 5 версій схем. Розповсюджувались безкоштовно, завдяки партнерам. Усі тиражі були розібрані.

Одна з мотивацій, чому ми хотіли паперові схеми  — фізичний артефакт набагато приємніше тримати в руках, можна було брати з собою і орієнтуватись в метро (тоді не було 3g). Ще після оновлення карток метро, були невдоволені, що зникла схема (чи вона була зручною?), тож ось.

Старі картка та проїзний

І для туристів завжди приємно взяти з собою якусь таку дрібницю про місто. Найбільш знаковий приклад і взірець — Лондон. Вони випускають кишенькову схему з 1947 року і дотепер. Від просто інформаційної брошури вона стала майданчиком для мистецьких проєктів. Розмір 300x150 мм та три вертикальних фальци (згини).

Версія 1 · 2016

Формат. Спочатку хотіли взяти формат де схема складалась в 5 згинів і мала картонні обкладинки з двох сторін. Але виявилось що це патентований формат zfold. Тож щоб зробити дешевше взяли А4 у 4 згини, щоб останній згин був зверху, щоб легше брати.

Формат zfold

А4

Дві мови окремо. У схемах завжди виклик як розмісти всю інформацію, щоб читабельно і щоб відділяти інформаційні шари. І тут друкований формат дозволив зробити окремо англійську версію. При чому на ній для іноземців можна було підказати що їм релевантно. Їх було 25% тиражу.

Українська та англійська версія першої схеми

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

З тим стендом заморочились і зробили як адресні покажчики — метал та покриття склоемаллю. Саму схему теж. Дорого-багато, дуже красиво і блищить.

Металеві стенди

Але для великої схеми непрактично оновлювати. Тож там же Петрівка просто наклеєний папірчик з назвою Почайна.

Той самий папірчик

Ладно, згин зверху з’явився в наступній. Бо хотіли, щоб коли розгортаєш кожну сторону і тримаєш схему, вся інформація була не перевернута. Але зручність діставання схеми з диспенсера була важливішою. До речі, ілюстрації на обкладинку намалювала Олена Годіна.

Перша версія

Версія 2 · 2016

За кілька місяців тираж розібрали та треба було друкувати новий. І хоч контент не змінився, все одно ми хотіли робити одразу серію: у кожної схеми своя ілюстрація на тему метро. Щоб вона стала предметом колекціювання (замашки не гірше ніж у Тартаковського, хто пам’ятає, той пам’ятає 😅)

Друга версія

Ілюстрація з відсилкою до оздоблення вестибюля станції «Хрещатик». Одна з перших станцій, центральна і на якій безпосередньо був один з перших стендів. Ілюстрацію робив Ігор Скляревський. Взагалі архітектура майже станцій гарна, можна знаходити оці гарні детальки.

Вестибюль станції «Хрещатик»

Версія 3 · 2017

За пів року друкували ще тираж. На цей раз ілюстрацію робив Дмитро Шевченко, а курував Влад Кулик. Це теж «Хрещатик» та керамічний декор у залі станції, авторка — Оксана Грудзинська. Правда дещо творчо переосмислена. А чому б і ні.

Третя версія

Фото керамічного декору

Фото Олег Тоцький

Версія 4 · 2017

Наступний тираж випустили перед Євробаченням, яке проходило в МВЦ на Лівобережній. Тому для обкладинки використали елементи саме цієї станції, а кольори — як у брендбуці самого ЄБ. Тоді ще оновили опції оплати тому весь розворот був присвячений їм. Ілюстрація — Олена Годіна.

Четверта версія

Досі подобається, як всі методи оплати вмістили. За формулювання, і взагалі за роботу над всіма англійськими, текстами я щиро дякую Олександру Клейменову.

Фото оригінальної плитки:

Фото Олег Тоцький

Тоді на ЄБ проводили капітальний ремонт самої станції. Через який втратили автентичний декор, бо що вийшло це сором. А зусилля з впровадження навігації були марними. Тож все вийшло, як зажди (🥊👹)

Понівечені колони та решки оригінальної плитки

Версія 5 · 2018

Остання версія вийшла через рік, під фінал Ліги Чемпіонів, який проходив в Києві і спонсором якого був Мастеркард. І вимогою було використати графіку кампанії для ЛЧ, тому це єдина схема яка не у загальному стилі.

П’ята версія

З приємного:

1. схему можна було знайти в аеропортах;
2. працював з новим брендбуком Мастеркарда від Пентаграма, і все стало виглядати доволі свіжо.

Стенди в аеропортах

Процес роботи

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

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

А це прототип оновленого диспенсера з ПВХ.

Не знаю, навіщо вам цей факт, але: на всіх картинкою я намалював свою руку, бо мені треба було правильний ракурс 😅

Знайшов фото, де пластикові диспенсери відламані. Тому і вирішили робити металеві.

А це зразок одного з нових стендів, де диспенсер не пластиковий, а більш витривалий металевий.

Бонус

Обкладинки, які не вийшли:

1. Варіант, який хотіли як раз на 5 версію, бо це саме «Олімпійська» і тема шикарної мозаїки зі станції.
2. Теж «Хрещатик» без абстракцій (кольори просто 🤌)
3. Старе оздоблення станції «Нивки»

Їх, як і 1 та 4, намалювала Олена Годіна.

Олімпійська

Хрещатик та Нивки

А це, якийсь ще один з перших концепт обкладинки:

Відгуки

Ну і наостанок поділюсь відгуком, який зберіг. Якщо у вас є схеми, то можете теж щось про них написати і сфоткати. І для історії, і просто приємно буде.

І залишу тут на згадку фідбек з твітера:

Кінець 2016 року, в гості до «Агентів змін» приходить Дмитро Гурін та каже, що МОЗ запускає Національну службу здоров’я і треба логотип. Такий, щоб всім був зрозумілий і не нагадував аптеку. Кілька ітерацій і вийшов гарний простий символ, який є у кожній лікарні. Макети у векторі.

Застосування:

Лого на інформаційних плакатах і навіть значки

А це працює навіть сама форма, в якій розміщене основне повідомлення.

Наліпка

А у 2018 зробили комунікацію про сімейних лікарів. Як рекламні плакати, сітілайти, білборди, так і пояснювальні плакати, з порядком дій.

Фото наживо з різних лікарень України:

Ну і Дмитро у твітері згадав кілька цифр з цієї кампанії. Дуже потужна була тоді робота команди МОЗ.

P. S. А могло бути і щось таке. Фінальний результат краще :)