TUI'lerin Neden Geri Döndüğü
(wiki.alcidesfonseca.com)- TUI'ler anlık geri bildirim, otomasyon kolaylığı ve işletim sistemleri arasında çalışabilme sayesinde yeniden öne çıkıyor; Claude ve Codex gibi araçlar da komut satırında büyük başarı yakaladı
- Windows, Linux ve macOS'taki yerel GUI'ler; sırasıyla tutarsız API stratejileri, araç takımı ve ortam parçalanması, geçmiş yönergelerle uyumun zayıflaması nedeniyle hem geliştiriciler hem de kullanıcılar için yükü artırıyor
- Electron uygulamalarında asıl sorun bellek kullanımı değil, görsel tutarlılık eksikliği ve klavye odaklı iş akışlarındaki boşluklar; menü ve kısayol entegrasyonu da zayıflamış durumda
- Google'ın Flutter UI girişimi ve Zed'in GPUI'si gibi yeni UI yığınları oluşturma çabaları oldu, ancak işletim sistemi entegrasyonu zayıfsa hızlı bir renderer tek başına yeterli olmuyor
- İyi bir arayüzün özü, kullanıcının daha az düşünmesini sağlayan tutarlılık; geliştiriciler ile işletim sistemi ve araç takımı üreticileri UI kuramına ve erişilebilir araç takımlarına daha fazla yatırım yapmalı
TUI'lerin yeniden öne çıkmasının arka planı
- DHH'nin Omarchy projesi, TUI, web uygulaması ve gnome tarzı yerel uygulamaların karışımından oluşuyor; TUI ise anlık geri bildirim ve “geek points” için kullanılıyor
- Yaklaşık 10 yıl önce kod editörlerinde de benzer bir eğilim vardı
- BBEdit, Textmate, Notepad++, Sublime gibi yerel editörlerden Atom, VSCode ve bunların türevleri gibi Electron tabanlı uygulamalara geçildi
- Güçlü tercihlere sahip kullanıcılar vim ya da emacs'e yöneldi; anlık geri bildirim ve yüksek kullanılabilirlik elde ettiler ama bunun karşılığında çok dik bir öğrenme eğrisini kabul etmek zorunda kaldılar
Yerel GUI'lerin zayıflama nedenleri
-
Windows
- Windows, tutarlı bir GUI kütüphanesi stratejisi oluşturamadı; bir API başarıya ulaşmayınca bir yenisini üretme döngüsünü tekrar etti
- Jeffrey Snover, Microsoft hasn’t had a coherent GUI strategy since Petzold yazısında MFC, OLE, COM ve ActiveX'in Windows geliştirme ekosisteminin geneline karmaşıklık yaydığını söylüyor
- Microsoft daha sonra WinForms, WPF, Silverlight, WinUI ve MAUI'yi denedi, ancak bunlar başarılı olamadı; birçok kurumsal ve bireysel masaüstü uygulaması hâlâ Electron uygulamalarına dayanıyor
- Windows'un görsel olarak tutarlı biçimde bütünleşik olduğu son dönem, Windows 98 ya da Windows 2000'e daha yakın bir zamandı
- Domenic Denicola, Windows Native App Development Is a Mess yazısında, birkaç yılda bir işletim sistemi ve UI API'lerini yeniden üretmenin maliyetinin yüksek olduğunu; sandboxing ve özellik kaldırma girişimlerinin de buna eklenmesiyle her yeni katmanda önceki çerçevelerde yapılabilen bazı işlerin artık yapılamadığı boşluklar oluştuğunu savunuyor
-
Linux
- Linux'taki UI tutarsızlığı, büyük ölçüde tasarımın doğal bir sonucu; farklı ekipler farklı hedeflerin peşinden gitme özgürlüğüne sahipti
- GTK ve Qt başlıca çerçeveler hâline geldi; ikisi de çapraz platform yerel geliştirmeyi hedeflese de en yaygın kullanımları esas olarak Linux tarafında kaldı
- Farklı araç takımlarıyla yapılmış Linux uygulamaları yan yana geldiğinde yine de bir dereceye kadar uyumlu görünebilir, ancak Windows'taki çok sayıdaki çerçeve bu düzeyde bir uyum yakalayamıyor
- Dağıtım, masaüstü ortamı ve donanım kombinasyonları çok fazla olduğu için test etmek zor; bu yüzden birçok şirket yerel Linux uygulaması geliştirmiyor
- Şirketler genelde Linux desteğini Electron üzerinden veriyor ya da açık bir API varsa bunu açık kaynak topluluğunun çözmesine bırakıyor
-
macOS
- Apple'ın Human Interface Guidelines, dünya çapında kullanıcı arayüzü derslerinde alıntılanacak kadar güçlü bir ölçüttü
- Xerox PARC ve Apple, iyi bir insan-bilgisayar arayüzünün ne olduğuna dair araştırmalarıyla öne çıkan kurumlar arasında sayılıyor
- Son dönemde Apple, geçmiş yönergelerle olan tutarlılığı bozan bir yöne ilerliyor
- macOS; Fitts yasasını göz ardı ediyor, pencere yeniden boyutlandırmayı neredeyse imkânsız hâle getiriyor, düzeltme girişimlerinden sonra bile sorunları sürdürüyor ve tüm menülere simge ekliyor
- macOS artık tasarımcıların huzur içinde çalışabileceği güvenli bir bölge olarak görülmekte zorlanıyor
Electron uygulamalarının sınırları
- En sık dile getirilen sorun bellek kullanımı, ancak son 10 yılda bellek kullanımı aslında düşme eğilimindeydi
- Daha büyük sorun, görsel tutarlılık eksikliği ve klavye merkezli iş akışlarının yetersizliği
- 64GB RAM'li bir MacBook Pro kullanılan bir ortamda bile Dock'ta 8 yerel uygulama ile 6 Electron uygulaması birlikte bulunuyor
- Yerel uygulamalar: TextMate ve macOS sistem yardımcı programları
- Electron uygulamaları: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
- Cursor ve VSCode gibi uygulamalarda, ajan panelinden bir özellik istedikten sonra yalnızca klavyeyle yan paneldeki ajan listesine geçmek ya da öğeleri arşivlemek doğal hissettirmiyor
- Oysa bu tür işlemler tüm macOS uygulamalarında aynı şekilde yapılabilmeli; ancak kısayol olsa bile bazen menüde gösterilmiyor
- Son 10 yılda geliştiriciler, uygulamada yapılabilen işlemleri menülere de eklemeyi giderek unutur oldu; bu da uygulamaların sandbox içindeki HTML olarak uygulanması yapısıyla bağlantılı
- Slack bu konuda diğer Electron uygulamalarından daha iyi iş çıkarıyor, ama o da kusursuz değil
Yeni UI yığınını yeniden kurma girişimleri
- Google, Dart ile birlikte Android mirası taşımayan yeni bir işletim sistemi ve yeni cihazlar için yeni bir UI araç takımı oluşturmak istemişti
- Google, Flutter UI adlı yeni bir UI araç takımı istiyordu, ancak gerçek ürün piyasaya çıkmadan projeden vazgeçti
- Bu tür girişimler ancak tekel benzeri bir konum ya da yeterince büyük bir pazar payı varsa başarılı olabilir
- Zed, Rust ile benzer bir yol seçerek kendi GPU renderer kütüphanesi olan GPUI'yi geliştirdi; bu kütüphane çapraz platformu hedefliyor
- GPUI hızlı olsa da barındırıcı işletim sistemiyle entegrasyonu tek başına yeterli değil; geliştiricilerin ihtiyaç duydukları binding'leri kendilerinin eklemesi gerekiyor
- Hızlı bir renderer yerine işletim sistemiyle iyi bütünleşen daha yavaş bir renderer tercih edilmeli
TUI'nin doldurduğu boşluk
- Apple Automator'ın gerilemesini hatırlatan bir bağlamda, TUI yeniden otomasyona uygun bir arayüz olarak önem kazanıyor
- TUI, uzaktan çalıştırma açısından da görece kolay; baş ağrıtan X forwarding'e bağımlı kalmak gerekmiyor
- Yerel UI araç takımları başarısız olduğunda insanlar temele dönüyor ve bunun sonucunda TUI bir seçenek olarak öne çıkıyor
- Claude ve Codex komut satırında büyük başarı elde etti; kullanıcılar da çevredeki işletim sistemine odaklanmak yerine etkileşimin kendisine yoğunlaşabiliyor
- TUI ile buluttaki makinelerde kod ve uygulamalarla çalışmak ya da iPad'den GPU'lu bir makineye uzaktan bağlanmak mümkün
- TUI, tüm uygulamaların birbirinden farklı göründüğü bir ortamda Apple ve Microsoft'un bıraktığı boşluğu dolduruyor
- Farklı görünümler sanat ya da bilgisayar oyunları için iyi olabilir, ancak arayüzün geri çekilip kullanıcının kendi işini yapmasına alan açması gereken amaçlar için uygun değil
Bundan sonra gereken yön
- John Loeber, Bring Back Idiomatic Design yazısında, onay kutusunun bile sistemle etkileşim kurmak için bir arayüz olduğunu ve iyi bir arayüzün kullanıcıyı daha az düşündürdüğünü savunuyor
- Kullanıcılar çok sayıda şeyle etkileşime girer; bu nedenle tutarlı bir deneyim sunan homojen arayüzlere ihtiyaç vardır
- Command+C kopyalama kısayoluysa her yerde çalışmalı; belirli durumlarda ayrıca CTRL+Shift+C ya da sağ tık → kopyala gibi seçenekleri hatırlamak zorunda kalmak rahatsız edicidir
- Tüm geliştiriciler yalnızca yazılımı değil, genel olarak iyi kullanıcı arayüzleri üretmeye yarayan kuramı da öğrenmeli
- Kullanıcı deneyimi tasarımını, yazılım mühendisliği eğitiminde önemsiz bir soft skill gibi gören yaklaşım sona ermeli
- Hangi süreç olursa olsun UI anlaşılmıyorsa proje başarısız sayılmalı; HCI derslerinde de hedef kusursuz UI olmalı
- İyi bir UI üretmenin büyük kısmı ihtiyaçları anlamaya dayanır; programlamanın kendisi ise artık zaten otomatikleşiyor
- İşletim sistemi ve araç takımı üreticileri, geliştiricilerin gerçekten kullanmak isteyeceği erişilebilir araç takımlarına yatırım yapılmasını sağlamalı ve giriş engellerini düşürmeli
- Burada mutlaka çapraz platform desteği savunulmuyor, ancak böyle en az bir çözümün varlığı bile Electron ve TUI bağımlılığını azaltmaya yardımcı olabilir
2 yorum
Ben de öyle düşünüyorum; ancak bana göre geliştirici dünyası modaya gereğinden fazla duyarlı. TUI'ye esasen düzgün bir GUI yapma becerisi ya da isteği olmayan şirketler öncülük ediyor, ama TUI'yi gerçekten kaç kişinin kullandığını bilmiyorum.
Lobste.rs görüşleri
Keşke insanlar bunun yerine yerel uygulamalar yapsa. TUI, komut satırı arayüzü ile gerçek GUI’nin kötü yanlarını birleştiren bir şey gibi görünüyor
Her TUI programı kaydırmayı baştan kendisi uygulamak zorunda kalıyor; bu yüzden terminal piksel düzeyinde kaydırmayı desteklese bile TUI programları yalnızca satır satır kaydırmayı destekliyor ve davranışları da birbirinden farklı oluyor. senpai içindeki scrollback, kullandığım diğer programlardan farklı çalıştığı için sürekli yönümü kaybediyorum
Arayüzün tek bir metin panelinden fazlası olduğuna dair terminale bilgi vermenin de bir yolu yok; bu yüzden metin seçimi sık sık bozuluyor. Fare olaylarını ele geçirerek bu mümkün oluyor ama o da ayrı bir dert. Bir TUI IRC istemcisinde metin seçebilmek için iki yandaki ıvır zıvır panelleri gizleyen bir kısayola basmam gerekiyordu ve bu epey aptalca bir süreçti
Izgaraya uymak zorunda olma kısıtı, yerleşim ve tasarım olanaklarını ciddi biçimde sınırlıyor. Tıklanabilir düğme gibi görünmesi için biçimlendirme yapma, bağlam menüsü benzeri şeyler gibi. Bir zamanlar bu sorundan şikayet etmiştim
TUI’lerin artmasını, geleneksel GUI çerçevelerinin durumunun iyi olmamasının üzücü bir sonucu olarak görüyorum. TUI çerçeveleri nispeten daha istikrarlı ve çok eski olanları kullansanız bile çok sırıtmıyor. ncurses programlarını bugün hâlâ sık kullanıyorum ama Motif programlarını kullandığımı pek hayal edemiyorum
GUI çerçevelerinde ise seçenekler o kadar fazla değil ve bakım ihtiyacı çok daha yüksek. Masaüstü ortamları değişiyor, GUI’den beklentiler de artıyor. TUI erişilebilirliğinin gerçekten kötü olduğunu düşünüyorum ama bundan tamamen emin de değilim. Üstelik değişim de çok fazla: GTK2 ile yapıyorsun, kullanım dışına çıkıyor; GTK3’e geçiyorsun, bu kez GTK4’e geç deniyor
Daha alaycı bakarsak, Omarchy gibi şeylerde başka etkenler de var. Normal bir GUI olan xfce4-taskmanager sıkıcı görünüyor ama TUI olan btop aşırı hacker işi duruyor. İnsanlar terminal estetiğini seviyor (/r/unixporn’a bakın) ve hava uğruna kullanılabilirlikten ödün vermeye de razı gibiler. btop’un süreç listesini gerçekten fade-out yapmasına bakınca bunu görebiliyorsunuz
Umarım artık giriş engeli daha düşüktür. Geliştiricilerin çoğu yüksek seviyeli dillerle yetişmişken bu çok ikna edici görünmüyor; C++’ın karmaşıklığı da beni korkutuyor olabilir
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
Matrix istemcisi Nheko ise bir seferde bir satırdan fazlasını seçmene bile izin vermiyor
Buna karşılık IRC istemcileri varsayılan olarak şunu veriyor
20:41 <username1> message1
20:42 <username2> message2
Bazen mantıklı olabiliyorlar ama ideal olarak yalnızca küçük, kısa ömürlü uygulamalarda ya da metin düzenleme gibi istisnalarda kullanılmaları daha iyi olur diye düşünüyorum
Örneğin lf, tig, kakoune kabuk betikleriyle iyi çalışıyor; aynı betikleri yeniden kullanabiliyor ve üç uygulamanın hepsinde işlevsellik genişletebiliyorsun. Hepsi alacritty içinde çalıştığı için bu üç uygulama ve kabuğun genelinde çalışan köprüler de oluşturabiliyorum
Hayal kuracak olsam, Emacs ya da acme tarzı bütünleşmeye izin veren tek renkli minimalist bir GUI araç takımı isterdim
TUI’nin nasıl olup da “otomasyonu kolay” olduğunu anlamıyorum. Konsolda gösterilen bir GUI’den farkı ne?
Bu yazı, TUI’nin “geri dönüşünün” asıl nedenini kaçırmış. Bu iddianın kendisi de şüpheli ama Claude gibi kodlama ajanlarının çok sayıda vibe coding ürünü üretmesiyle son dönemde popülerliğinin arttığı doğru gibi görünüyor
Geliştiriciler kolay yolu sever. Çünkü çapraz platform bir TUI yapmak, bir GUI yapmaktan daha kolay
Web uygulamalarının popüler olmasının nedeni de aynıydı. Tarayıcı araçlarıyla çapraz platform uygulama yapmak kolaydı; Electron’ın yükselişi de tarayıcılar arası destek yükünü ortadan kaldıran benzer bir durum. Duyarlı bir arayüz yapmak, arayüzü çapraz platform biçimde render etmek, kullanıcı girdisini özellikle erişilebilirliği de hesaba katarak ele almak zordur. Bu yüzden geliştiriciler, bunları kolaylaştıran bir şey görünce hemen üstüne atlar
Son dönemde TUI yapımını kolaylaştıran değişiklikler de oldu. Gelişmiş özellikler için çapraz platform desteği iyileşti, karmaşık ayrıntıları soyutlayan popüler kütüphaneler çıktı ve bunlar yakın zamandaki TUI rönesansına yol açmış gibi görünüyor
Bunun dışında yazının diğer noktaları biraz şüpheli. Mesela yazar, Electron uygulamalarının zayıf yanı olarak tutarlılığı gösteriyor ama popüler TUI’lerde de gelenekler dışında neredeyse hiç tutarlılık yok. Kodlama ajanları benzer kısayollar benimsedi ama bunun nedeni çoğunun aynı kaynak olan Claude’u kopyalamış olması. Bu kısayollar kodlama ajanlarının dışına pek taşmıyor ve benim kullandığım çoğu TUI’nin kısayolları ve görsel dili epey farklı
“Arayüzü çapraz platform biçimde render etmek zor” sözü de bana şüpheli geliyor. Bir uyumluluk katmanı gerekir ve desteklenen platform sayısı kadar uygulama gerekir ama bu, tek platform desteğine göre o kadar da zor görünmüyor. Elbette hedef platformların render yaklaşımı o kadar farklıysa ki ortak bir API tasarlamak zorlaşıyorsa başka; ama ekrana piksel basma seviyesinde bunun böyle olmaması gerekir. Ölçekleme gibi şeylerle uğraşmak gerekir ama onun ötesi oldukça doğrusal olmalı, olmadı SDL var
Sanırım kastedilen şey, arayüzün tüm platformlarda “yerel gibi görünmesi”. Bu da her platformun tercih edilen yerel GUI araç takımını kullanmayı gerektirebilir; bunlar hem birbirinden çok farklıdır hem de düşük seviyeli render API’lerine göre çok daha büyük ve daha az kararlı olabilir. Bunun için hayat çok kısa. Renk teması ya da grafik stilinin bazı yönlerini değiştirme imkanı bırakırdım ama bunu uygulama düzeyi ayar olarak tutardım. Her işletim sisteminin grafik ayarlarını okuyup zaman harcamak istemem
“Kullanıcı girdisini, özellikle erişilebilirliği ele almak zor” sözü de garip. Klavye ve fare olaylarını dinlemek önemsiz bir iş. Erişilebilirlik açısından düzgün klavye dolaşımı gerekir ve bu genel kullanılabilirlik için de önemlidir; standart ve özelleştirilmiş kısayolların desteği de gerekir ama genel olarak bunlar diğer şeylerden çok daha kolay görünüyor
Ekran okuyucu desteği, ilgili platformun API’sine ve platformlar arası farklara bağlı olarak zor olabilir ama bu girdi sorunundan çok render sorununa daha yakın
TUI, bir “geri dönüşten” çok, yerel GUI programlama bilgisini kaybettiğimiz için eldeki araçlarla idare etmeye çalışma haline benziyor. Bu, tutarlı geliştirme ve yatırım eksikliğinin sonucu
Qt gibi birkaç parlak istisna dışında UI medeniyeti çöktü ve sanki kıyamet sonrasında yaşıyoruz
Preventing the Collapse of Civilization konuşmasıyla kafiyeli geliyor ve artık çok fazla kodun AI tarafından yazıldığı bir dönemde bu bilgi çöküşünün daha da yayılmasından endişe ediyorum
Bilgisayar bilimi için bir tür After Virtue gerekiyormuş gibi geliyor; belki Blow’un çevrimiçi varlığı bu rolü oynuyordur. Her neyse, tutarlılık gösteren, kullanıcıya saygı duyan, öğrenmeyi ve özeni ödüllendiren bilgisayar arayüzleri dönemini özlüyorum
Bu yazının somut içeriği pek yok gibi; daha çok yazarın diğer her şeyin berbat olduğunu düşündüğünü söylüyor gibi
Şunu söyleyebilirim: Emacs, metin, klavye, düğme ve zengin medya arayüzleri için harika bir platform
İnsanlar Go, Rust ve şimdi de Zig ile ncurses yerine TUI kütüphaneleri kullanmaya başladığı için olabilir. Yine de ncurses’ın gerektirdiği o korkunç taşınabilirlik sorunlarını çözmüş oldular
Sonra insanlar yeni terminaller yapmaya ve o taraftaki teknolojiyi de ilerletmeye başladı. Kısmen bunun sebebi C yerine Go, Rust ve Zig ile yazabilmeleri
C ve C++’tan daha eğlenceli, daha az sinir bozucu iyi seçenekler sunarsanız insanlar doğal olarak daha yeni ve daha faydalı kodlar yazmaya başlar
TUI’nin geri dönmesinin gerçek nedeni, 2026’da imzalanmış ve noter tasdikli bir GUI dağıtmak için Apple’a para ödemeniz ve Windows için de bir sertifika otoritesine para vermeniz gerekecek olması
Küçük bir düzeltme: Zed’in GPU hızlandırmalı UI kütüphanesi çapraz platform API’si wgpu değil, gpui
Yazının tezini gerçekten kanıtlayıp kanıtlamadığından emin değilim ama MS-DOS dönemini yaşamış ve TUI’leri hep sevmiş biri olarak ben de araya gireyim. afl-fuzz kullandıysanız muhtemelen anlarsınız
Teoride Linux’ta TUI’nin çok daha başarılı olması gerekirdi. Metin tabanlı estetiği seven teknik bir kullanıcı kitlesi vardı ve bir de kaba, tutarsız GUI ortamı gibi bir “avantaj” söz konusuydu. Ekran kartını X sunucusunda düzgün çalıştırmak bile başlı başına sorun olan zamanlar vardı
Aynı zamanda onlarca yıl boyunca *nix yazılım geliştiricileri, eski ve egzotik terminal türlerini bile desteklemek zorundaymış gibi hissetti. Uygulama DECwriter’da düzgün render edilmezse kıyamet kopacakmış gibi davranılıyordu; böyle kısıtlar altında iyi bir TUI yapmak zordu
MS-DOS döneminde Microsoft, Borland, Norton gibi şirketler işlevsel ve hızlı tepki veren metin tabanlı arayüzleri ustalıkla yapmıştı. Linux’ta ise uzun süre TUI tasarımının “zirvesi” menuconfig denen canavardı; biraz gözünüzü kısarsanız vim’e bile TUI diyebilirsiniz. İnsanların gerçekten metin modlu konsol kullandığı dönemlerden hatırladığım iyi Linux TUI’lerden biri, Norton Commander’dan ilham alan dosya yöneticisi Midnight Commander idi