GUI design

Anno mikor még azt hittem, hogy programozó szeretnék lenni, akkor Delphi-ben kódoltam. Sokan szídták, de én szerettem.

Időnként most is kell ezt-azt csinálni, főleg egyszerűbb dolgokat, néha GUI-t. De mindenhol azt látom (amivel én eddig találkoztam), legyen az Visual Studio, python vagy powershell.... Komolyan nincs egy kibaszott GUI designer, ahol delphi módjára szépen meg lehet csinálni a formot, és utána csak mögé tenni a function-öket? Tényleg nekem kell minden gomb és egyéb object méretét, pozícióját kézzel megadni, egyesével léptetve futtatni és megnézni hogy hogy néz ki a form, jó helyen van-e a gomb, és pixelenként kell szarakodni? Megáll a eszem. Visszasírom a delphit...

(Most épp a powershell-be form kreálás apropóján)

Hozzászólások

Kicsitt off: mostanában egyre jobban fizetik a Delphi kódereket (már ha van épp ajánlat), nincsenek sokan, nem is akarja nagyon senki megtanulni,  de legacy projekteket meg kell valakinek foltozgatni :)

Amúgy vannak a frameworkokhoz/toolkitekhez, de egyik sem olyan kényelmes,  mint a Delphi, pl. GTK-hoz: https://glade.gnome.org

“Any book worth banning is a book worth reading.”

Delphi irányból jövök, nagyon sokat dolgoztam vele, de a nyelvet és az egész rendszer zártságát is utáltam. Ráadásul nagyon hozzá volt drótozva a Windowshoz.

Az összes ismertebb C vagy C++ eszközt kipróbáltam (Gtk, Gtkmm, Glade, wX, Qt), de mindegyik elvérzett nálam valamin.

Akkor kezdtem az ismeretlenebbeket nézegetni és Ultimate++ konkrétan nagyon bejött.

Elég sok mindent csináltam vele, például ez az egyszerű számlázó program is szinte teljes egészében Ultimate++-on alapul.

Nekem Ultimate++ bőven kényelmesebb és főként sokkal rugalmasabb, mint a Delphi. És borzasztó megbízható programokat lehet vele írni.

A Rust-ban mostanában tolt elvek alapján épül fel az egész osztálykönyvtár, pedig a Rust még hírből sem létezett, mikor ez már régen használható volt.

Elképzelésem nincs, miért nem ismeri szinte senki, de talán pont azért, mert túl korán ment szembe a trendekkel.

Elképzelésem nincs, miért nem ismeri szinte senki, de talán pont azért, mert túl korán ment szembe a trendekkel.

Mert nem állt mögé valamelyik multi és marketingelte be sztárfejlesztőkkel és tech-divatinfluenszerekkel. Ami az általad vélt hátránya, az egyben az előnye is. Addig örülj, amíg nem ismerik a multik és nem silányítják el mindenféle túltervezett business logikás enterprise idealizmussal és az ezzel járó rengeteg bloattal. Addig lesz kompatíbilitásod, a doksik nem évülnek el egyik napról a másikra, nem áll feje tetejére az egész keretrendszer. Nem kell évente újraírni a fél alkalmazásod az erőltetett verzióváltások és divat-EOL-ok miatt és nem lesz havonta deprecated az API a fejlődés™ szent égisze alatt.

GUI-ra en QT-t szeretem. Az utobbi par evben tobb Pythonos programhoz csinaltam PyQt5-tel GUI-t, kollegaimnak is tetszett. A Qt 5 Designer eleg jo lett, KDE alatt behuzza (akar futas kozben is) a beallitott temat, lokalizacio is megoldott, plusz ha Winen kell futnia, pip3 install PyQt5, es mar megy ott is. Az atmeretezeskori "nyulas" az egyetlen nem-intuitiv dolog benne.

Masik project kapcsan a Glade-et is probaltam (LinuxCNC-hez lehetett plusz fuleket megadni), rettento bugos volt.

A Delphi jopofa, a szerkesztoje rendben van, csak valami normalis nyelv kellett volna moge a Pascal helyett. Nem tudom miert az terjedt el a C++ Builder helyett.

Egyebkent az Android Studionak is van GUI szerkesztoje, az is hasonlo. Szoval nem annyira ritkasag.

A strange game. The only winning move is not to play. How about a nice game of chess?

Desktopra 5-os Qt-t szoktam mostanaban. Ahogy irtam. Ennek a szerkesztoje a Qt 5 Designer (meg a Creator, joreszt ugyanaz). Multiplatform, tudom Linuxon fejleszteni, de fut Winen is. A Qt alapbol C++, de van binding mindenfele mashoz is, pl. Pythonhoz (Powershellt nem tudom). A szerkesztoje osszerak neked egy xml-t, utana Pythonbol vagy azt hasznalod a programhoz, vagy pyuic5 nevu scripttel Python file-t keszitesz belole, abbol leszarmazol, es kb. keszen is vagy.

Ha Qt helyett GTK-t hasznalnal, arra jo a Glade, az a GTK-s szerkeszto. Amikor hasznaltam, elegge instabil volt, de azota javithattak rajta. A GTK is alapbol multiplatform, jo mindenfele desktop rendszerekhez.

Van meg egy multiplatform, a wxWidgets, kicsit talan korulmenyesebb a Qt-nal, szerkesztojet mondjuk nem ismerem.

Amiket irtam, azok kozul az Android Studio az, ami nem kifejezetten desktophoz van (bar a Qt-t Androidon is talan be lehet uzemelni).

A strange game. The only winning move is not to play. How about a nice game of chess?

"Most épp a powershell-be form kreálás apropóján"

A powershell Studio nem erre van?

“Any book worth banning is a book worth reading.”

hamarosan te leszel a Borlandot az Embarcaderót agyonra károsító warezpistike-feketebárány

Ó, nem, az ingyenes Visual Studio és a Borland C/C++ platformon való gyengesége végezte ki gyakorlatilag, még a C#/.NET előtt kicsivel, mert bevétel hiányában kiszorultak a piacról (lásd sose volt ingyenes hozzászólás).

Akkor meg ingyen volt, pedig meg torrent sem volt.

Emlékeim szerint soha nem volt ingyen (kivéve oktatási célokra), csak nem volt semmilyen védelemmel ellátva.

Fiatal voltam, kellett a penz.

Én egyszer kaptam a Borland-tól egy Borland címkés bort is. Csak elkevertem valahova valamelyik költözésnél... :)

Ha környezet, fordító van ingyen, akkor gondolnám hogy tool-ok is akadnak.

Valamiből a tool gyártóknak is élniük kell, az ilyen feature is, amit keresel, tipikusan pénzért van. Az általad visszasírt régi időben _minden_ csak pénzért volt, alig voltak freeware vagy shareware programok.

Na én ezért szeretem a már eltemetett, de apacs légzőcsőn levegőztetett NetBeans-t. Igaz, hogy a Swing App Framework halott, de a sima Swing a legutolsó JDK-val is működik, ahogy az Apache inkubátoros NB-ben az alap GUI (JForm/JDialog) editor is.

A Basiceket, Pascalt, Delphit én is szerettem. De mivel vagy csak szaros interpreterek meg proprietary, zárt forráskódú, platform lock-in fordítók voltak hozzá, amik egy csomó libtől is függtek, ezért egy ideig elvegetáltak ezek a nyelvek tanulónyelvként, majd kimentek a divatból. Pedig annyira nem voltak komolytalanok, mint sokan tartják őket. Ennek ellenére a Delphi nem teljesen halt ki, ritkán azért keresnek Delphi-fejlesztőket, és jól meg is fizetik, mivel nincs belőlük sok. Meg még van mindig 1-2 híresebb projekt, amit Delphiben írnak, pl. Total Commander, Double Commander, Nero, egy ideig a Skype (mielőtt Elektron-alapra helyezték), stb..

Ahogy írták, Qt-re vannak eszközök, pl. QtCreator, meg .NET-re is van ilyen tool, ha csak Windows alá kell. Szóval ma sem idegen. Bár én nem tartom szükségesnek, semmit nem kell pixelezni, lehet stíluslapot használni, meg absztraktan leírni a GUI elemeket, hogy mennyi hely maradjon ki, középre legyen rendezve a két gomb, stb.. Nem kell azt kézzel rakosgatni meg designolni.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ha C++ neked OK, akkor Ultimate++-t nézd meg!

Rendes grafikus form-tervező van benne.

Maga a layout egy C++ fájl, amit a tervező tart karban.

Ebből kell neked egy konkrét osztályt származtatni, amiben sima memberekként ott vannak a felületi elemek.

Ez lehet egy ablak vagy egy új, összetett felületelem, amit aztán más layoutokra is rápakolhatsz.

A kódot is megírja, ha akarod.

Borzasztó egyszerű használni.

Az eseménykezelés is tök egyszerű, member függvényeket vagy akár lambda függvényeket is ráköthetsz az eseményekre.

Ha telepíted, rengeteg példa van, amiket ki tudsz próbálni, át tudsz írni.

Ez egy jó Ultimate++ bevezető.

Windows, Linux, Mac, BSD rendszereken megy.

QtCreator -> new QtWidgets Application

Duplaklikkel megnyitod a mainwindow.ui fájlt

Felhányod ízlésesen a formodra a kívánt widgeteket

Widgeteken jobbeger goto slot -> és már generálja is a függvényt a cpp fájlodba

Megírod a slotokba a kívánt kódot

Profit!

Én mindig a Delphi-t hozom az "öregeknek" ellenpontként a jelenlegi fancy fejlesztési módszerekkel szemben. Ott el tudtad helyezni a kontrollt, a layout méretét is te adtad meg (=ablak). Most pedig tetszőleges layoutra kell xs, sm, md, lg reszponzivitás mentés megvalósítani mindent. Nem is csoda hogy külön szakmai lett a frontend. És ők még csak nem is írnak kliens JS kódot, csak a layout-ot rakják össze (néha csak elméletben).

Mindezekre rátett egy lapáttal a nagy céges layout misztériuma: Osx/iOS layout design, Google material layout (vagy mi a fene a neve), ahol a betűkészlet választást külön projektbe teszik. Hol van már a régi D(elphi)5/D7 Tahoma vs. Arial döntés 4 percben?

Szerkesztve: 2021. 05. 20., cs – 19:32

(Most épp a powershell-be form kreálás apropóján)

Windows Forms vagy WPF? Ha utóbbi, akkor a Visual Studioban van form designer amivel létre tudod hozni az XAML file(oka)t.

Hát, én is Turbo Pascal majd Delphi vonalon kezdtem nagyon régen (új dolog votl a Dephi, olyan régen), és én is szerettem a Delphi hozzáadott eszközeit. Aztán mikor pár éve kellett újra kicsit komolyabb programot írni, akkor a Delphi-t nem akartam megvenni miatta, így lett Lazarus (Free Pascal-t használó Dephi klón), amiben van ugyan úgy form designer, csak legalább multi-platform (a fejlesző is és a kész progit is lehet mindenhol fordítani). Persze nem teljesen Delphi kompatibilis (nem lehet minden Dephi kódot lefordítani hozzányúlás nélkül), de szerintem jól működik, és fejlődik.

Aztán kellett csinálnom egy másik kisebb programot, de az volt az elvárás, hogy az webes legyen, tableten legyen használható (beérkező áru minőség ellenőzzést rögzítették vele), ennek a kliens oldala JS kód és Bootstap megjelenítés lett, és akkor jöttem rá, hogy mennyire kirány, ha csak definiálom, mit szeretnék, és a böngésző rakja ki a dolgokat a szabályaim alapján, nem nekem kell mindent széthúzogatni, újra elrendezni, ha plusz egy mezőt fel szeretnék venni. És még jól is néz ki a végén hs arra is figyel az ember. Szóval azóta már nagyra értékelem a WPF-et is (VS-ban van form designer mondjuk), pedig az elején nagyon utáltam amiatt, hogy "kódolni" kell a GUI-t lkeginkább, nem "megrajzolni".

Hát ezt két irányból lehet nézni

Az egyik, hogy a feladatok jelentős részét elvitték a ZohoCRM szerű rendszerek (esetleg Zoho Creator). Az pont olyan amit mondasz, egymás alá behúzod az elemeket, aztán ha kell saját logika akkor megirod, pont.

A másik, hogy a többi feladatban a fejlesztőt már az után hívják oda sokszor, hogy a UI készen van - azon keresztül egyeztettek az ügyféllel. Tehát van egy pixelpontos dizájn amit egy erre szakosodott gárda átfordít HTML-be, és egy másik csapat mögé pakolja ezeket a function-öket.

A kettő közt néha van ilyen XML-ből generálós scaffolder, de egyre ritkább vagy UI-on összepakolod a fél appot de az rögtön logikát is pakol mögé, vagy egyesével huzogatsz mindent pixelre, és az elképzelés az, hogy nem te vagy a logikás ember, neki csak a keze alá dolgozol.

szóval ezért.

Visual Studio-val speciel pont rohadt egyszerű - ha .NET-re fejlesztesz. 20 év alatt majdnem utolérték a Borland cuccait :)

Ha jól tudom, a powershell az speciel pont .NET, és WPF UI-t lehet csinálni benne. Visual Studio-val eléggé könnyű WPF képernyőket csinálni WYSIWYG editor van benne - habár én rászoktam, hogy inkább az XML-t szerkesztem, mert ott könnyebb a layout struktúráját összerakni-átalakítani, és nem vagyok hajlandó megadogatni a méreteket és a pozíciókat - oldja meg a layout kód.

Szerkesztve: 2021. 05. 21., p – 10:31

Azt kell mondjam, hogy így elnézve a kommenteket nincs azon mit csodálkozni, hogy nem készülnek desktop appok, és minden szart böngészőre csinálnak... És max böngészővel egybecsomagolt hányadékot nevezik desktop appnak... Mert egyszerűen nincs rá tool, amivel egy ember egyszerűen, gyorsan össze tudna dobni valamit. Pedig anno 15 éve kb. bármit kerestél, tool, játék, utility, akármi, találtál rá valami kis letölthető desktop appot, aminek nagyon nagy része delphiben készült. Milyen kár hogy elmúlt. :(

"Sose a gép a hülye."

Most ugyanazok a toolok .NET-ben készülnek. Ez nem változott.

Ami változott, hogy weben könnyebb upgrade-elni, nincs gond a deploymenttel, nincs gond a hülye jogosultságokkal/group policyvel, összevissza átszabott kliens OS-ekkel, elavult DLL-ekkel, stb. A bömgésző az új alkalmazás-futtató platform.

De ami a legnagyobb változás: elterjedtek a nem-Windows rendszerek is, pl. Android, iOS, MacOS.

Nem mindegyik app natív, van amikor csak a webes klienst jelenítik meg egy WebView-ban (Electron mintájára). A Google és a Microsoft már a PWA-kat is támogatja, nem lepődnék meg, ha az Apple is beadná a derekát. Sok app ráadásul csak azért létezik, hogy jobban targetálja a usert (pl. webshopok appjai), szóval nem biztos, hogy ami natív az jobb is.

Nem mindegyik app natív

Igen, azért volt ott a ™ (korporatokrata termékmenedzseri idealizmusból natívnak hazudott).

Sok app ráadásul csak azért létezik, hogy jobban targetálja a usert (pl. webshopok appjai)

A legtöbb app csak ezért létezik, úgy a 90%. A klasszikus okostelefonos alkalmazások, amik célokat szolgálnak, csekély kisebbséget alkotnak. A modern alkalmazások gyakorlatilag márkázott kémszoftverek, nyomkövetők és erőforráspazarló "legyen nekünk is sajátunk" idealizmusok.

Na, akkor az üres fröcsögésen kívül linkelheted a 10 évvel ezelőtti írásaimat a Delphi, az Ultimate++, meg a klasszikus GUI builderek ellen. Mindhárom létezett már 10 évvel ezelőtt és én is 12 éve vagyok itt.

Amúgy, azonkívül, hogy bár nettó demagógia a laggardozásod, te hogyan fejeznéd ki nem "laggard" módon azt, hogy az elmúlt 5 évben a felhasználói felületek egyre funkciószegényebb, fapadosabb, sterilebbek és ez által használhatatlanabbak a Material nevű idealizmus által?

A felületek a felhasználói igényekhez igazodnak (UX research). Ha neked nem jön be, az azt jelenti, hogy nem tartozol a többséghez. Neked ez láthatóan nagyon fáj, de mégis saját döntésed, hogy nem tartozol a célközönséghez. Pedig fröcsögés nélkül is egyszerűen el lehetne fogadni, hogy hát ez van 

Dolgoztam ilyen projecten egy Fortune 500-as cégnek, láttam, hogyan van használva a gyűjtött adat, sőt, hozzáfértem eredményekhez is. Az adat anonimizálva, továbbá aggregálva van tárolva, hogy értelmes sebességgel lehessen lekérdezni. Ha akartam volna se fértem volna hozzá személyes adatokhoz.

Csak azt hagyod ki a képletből te is, meg Fejes Jocó is, hogy az ilyen projektek a többséget alkotó egységsugarú tapicskolók igényéhez alakítják ki a felhasználói felületet, ami már telemetria előtt is egy lebutított állapotból indult. A haladó szintű tudással rendelkező kisebbség, aki képes betanulni bonyolultabb workflowkat és felfogni komplexebb feladatokat, hogy mi történik a háttérben, meg le van szarva, hiszen arra már általában nincs pénz (milliárdosék túl milliárdosok lefejleszteni).

Most épp azt nem értem, hogyan jön ezen hsz. után össze a "haladó szintű tudással rendelkező kisebbség, aki képes betanulni bonyolultabb workflowkat és felfogni komplexebb feladatokat" és a "Windows XP mindenek felett, ami újabb az csak felesleges bloat szar"?

Az Windows XP már akkor is egy szar volt, mikor új volt. Egy kisminkelt Windows 2000, ami meg egy kisminkelt Windows NT 4.0. Egy picit volt jobb, mint az elődei, de nem érdemben.
Ellenben a Windows 7 nagyságrendekkel jobb lett (pl. nagy valószínűséggel nem omlik össze örökre, ha kicserélsz egy HW komponenst, netán az alaplapot), de az már ugye szar bloatware és csak a 6000 km-ről idepöfögtetett új gépeken megy, fúúújjjj...

Az Windows XP már akkor is egy szar volt, mikor új volt.

Helyesen: A Windows XP SP1 előtt (mikor új volt) szar volt, SP1 tűrhető volt, az SP2 már egész jó volt, a Windows XP SP3 pedig a mai napig egy nagyszerű, stabil operációs rendszer.

Egy kisminkelt Windows 2000, ami meg egy kisminkelt Windows NT 4.0. Egy picit volt jobb, mint az elődei, de nem érdemben.

Azt a lényeges dolgot felejted ki, ami ahhoz is kellett volna, hogy a mondandómat, amire reagáltál, megértsd. Minden smink, minden csicsa levehető a Windows XP-ről és teljes egészében visszaállítható a Windows 2000 nézet, ami ráadásul nem csak szemfényvesztés. Konkrétan így nem eszik többet a grafikus alrendszer, mint evett Windows 2000 alatt, sőt a GDI (tudod az, amit Windows Vistától kiheréltek) optimalizációk miatt kevesebbet eszik.

nagy valószínűséggel nem omlik össze örökre, ha kicserélsz egy HW komponenst, netán az alaplapot

A Windows 7 továbbra sem portable rendszer hardverek között. Egyik Windows sem az.

de az már ugye szar bloatware és csak a 6000 km-ről idepöfögtetett új gépeken megy, fúúújjjj...

Igen, vannak olyan számítógépek, amik helyett újat kellett venni. Még több régi jó, strapabíró nyomtatót, scannert kellett a szemétbe dobni a driverek hiánya, tehát a szoftveres elavulás miatt. Olyanokat, amik sokkal nagyobb eszmei értéket képviseltek a hardver időtállósága miatt, mint a mostani kínai hulladékok öt milliliteres patronnal, amik már attól félig szétesnek, ha átrakod az asztal egyik végéből a másikba.

Aki kikapcsolja a telemetria küldést, az önként mond le arról is, hogy a szoftvert az ő felhasználási szokásait figyelembe vegyék.

Telemetriával felhasználói igényeket meghatározni olyan, mint közvéleménykutatással népszavazást eldönteni, valódi szavazás kiírása nélkül.

Az a fajta telemetria, ami az elmúlt 6-7 évben lett nagyon népszerű, főleg szoftvermultiknál, csupán az alábbi három, nemesnek távolról sem nevezhető célt szolgálja.

  1. Különféle, általában a felhasználó számára részleteiben megismerhetetlen és az adatvédelmi szerződésben is csak általánosságban fogalmazott adatok és információk begyűjtése, a felhasználói élmény™ javításának marketingleple alatt. Ezeket az információkat aztán jó pénzért lehet továbbértékesíteni marketinggel és piackutatással foglalkozó multiknak. Tehát a telemetria a felhasználói adatok kiszipolyozása és egy erre felépített profitszivattyú működtetése. Ami kifejezetten undorító, hogy a fizetős szoftvereknél, szolgáltatásoknál is bőven előfordul a kikapcsolhatatlan telemetria, főleg a SaaS vonalon.
  2. Az ami a többségnek jó, bárkinek jó idealizmusával ürügyet találni vagy gyártani az idealista termékmenedzsereknek, a piacnak és a kisebbségben maradt, eltérő gondolkodású felhasználóknak arra, hogy valamit inkább így és ne úgy kelljen fejleszteni. Tehát, pl. nyugodtan kikapcsolhatatlanná tehetők az animációk, ha eddig 80% nem kapcsolta ki, és akkor nem kell plusz egy opció fejlesztésére és tesztelésére többet™ elkölteni™. A maradék 20% meg majd alkalmazkodik™.
  3. Az emberi tényezőt mindkét oldalról minél inkább kisöpörjék a folyamatokból, hiszen a humán erőforrás drága™. Tehát, nyugodtan bezárhatjuk a hivatalos support fórumokat, ahol technikai emberek is vannak, a hivatalos hibabejelentőt meg nyugodtan feltölthetjük mindenféle egységsugarú balfaszokkal, meg indiai bérrabszolgákkal, akik majd segítenek újraindítani a számítógépet, meg oda copy-paste-elni a helpben is elérhető szöveget. A Google, a Facebook, és a Microsoft is már többé-kevésbé így működik. Csak az open-source projektjeik azok (pl. Chromium), ahol technikai embert, aki ért is hozzá, el tudsz érni és meg tudod fogalmazni neki az esetleges, szintén technikai kritikádat. A nem open-source projekteknél csak copy-paste biobotoknál tudsz bejelentést tenni, akik esetleg a harmadik-negyedik felesleges copy-paste kör után talán meg is értik, hogy mit akarsz, aztán sűrű marketingbocsánatkérések közepette közlik veled, hogy továbbították az észrevételed a termékfejlesztésnek™. Persze, ha valaki számonkéri rajtuk, akkor ja hát kérem, van telemetria, mindenkinél pontosabban monitorozzuk és követjük a felhasználói™ igényeket™.

A telemetria jelenléte valójában a nagyvállalati arrogancia jelenléte. Annak a jelenléte, hogy kizárólag a multik által meghátoroztt szempontrendszerben, kizárólag a multik által meghatározott mértékegységekkel méricskéljék a felhasználókat és aztán erre alapozva tudják sokkal jobban, hogy ők valójában mit szeretnének. Ahelyett, hogy mondjuk meghallgatnák őket, főleg a haladó felhasználókat, akik esetleg nem csak a közösségi hálókon csüngnek-lógnak-tapicskolnak, hanem értéket is teremtenek.

Telemetriával felhasználói igényeket meghatározni olyan, mint közvéleménykutatással népszavazást eldönteni, valódi szavazás kiírása nélkül.

A multivariate testing inkább a kettős vak kísérlet szoftveres megfelelője. Arra valóban nem alkalmas, hogy nem ismert felhasználói igényeket mérjen fel, de arra igen, hogy a már ismert igényekhez a legjobb megoldást megtalálja.

ami a többségnek jó, bárkinek jó

Ilyen nincs. De ez akkor is igaz, ha a szoftver a haladó felhasználókat célozza, mert akkor az egységsugarú felhasználóknak lesz túl bonyolult.

Tehát, pl. nyugodtan kikapcsolhatatlanná tehetők az animációk, ha eddig 80% nem kapcsolta ki, és akkor nem kell plusz egy opció fejlesztésére és tesztelésére többet™ elkölteni™. A maradék 20% meg majd alkalmazkodik™.

Nálunk az volt a szabály, hogy ha statisztikailag szignifikánsan rosszabb az eredmény, akkor azt nem alkalmazzuk. Ehhez pedig annyi adatot gyűjtöttünk, hogy 1% körüli eltérés a vizsgált metrikában már statisztikailag szignifikánsnak számított. (Ennél egzaktabb feltételek voltak, de ez a lényegen nem változtat.)

Az emberi tényezőt mindkét oldalról minél inkább kisöpörjék a folyamatokból, hiszen a humán erőforrás drága™.

Inkább azt mondanám, hogy megérzések helyett adatokra támaszkodva legyenek döntések meghozva. Ráadásul valós felhasználói adatokból, nem felmérésekből származó, torz eredményekből.

A nem open-source projekteknél csak copy-paste biobotoknál tudsz bejelentést tenni, akik esetleg a harmadik-negyedik felesleges copy-paste kör után talán meg is értik, hogy mit akarsz, aztán sűrű marketingbocsánatkérések közepette közlik veled, hogy továbbították az észrevételed a termékfejlesztésnek™.

Egy ellenpéldát szeretnék hozni, Slack-nek küldtem bugreportot, szépen leírva hogyan kell a hibát reprodukálni, mi az elvárt és a tapasztalt viselkedés, képernyőképekkel illusztrálva. A válaszban megköszönték a bejelentést, jelezték, hogy sikerült reprodukálni a hibát, sőt, még azt is megírták, hogy dolgoznak egy hasonló hibán, aminek van egy ismert workaroundja, próbáljam ki hátha ezt is megoldja. Nem oldotta meg, ezt szintén jeleztem. Ugyan arról nem kaptam értesítést, hogy a hibát megjavították (igaz, idő közben megszűnt az erre használt email címem), de ma már nem tudom reprodukálni ezt a hibát.

A tanulság szerintem az, hogy ha sikerül professzionálisan, megfelelő részletességgel jelezni egy hibát vagy igényt, (ahogy te elvárnád másoktól), akkor partnerek lesznek veled, akármekkora cégről beszélünk.

Az említett multivariate testing sem más, mint egy olyan arrogáns metrika, amivel a többség által jobban kedvelt működést ráerőltetik a kisebbségre. Általában az egységsugarú, konzumer, tapicskoló, digitális analfabéta többség preferenciáját a tudatosabb, hozzáértő, haladó felhasználókra.

Az eredetileg és marketingjében is erősen kihangsúlyozottan fejlesztőknek és power usereknek szánt "IRC-alternatíva" Slacknél például úgy sikerült kivitelezni a multivariate testinget, hogy bizonyos felhasználóknak beerőltettek egy hivatalosan kikapcsolhatatlan WYSIWYG editort a korábban jól megszokott markdown editor helyett. Ez maga az üzenetszerkesztő, amivel csatornákra, thread-ekre, privát csetekbe írt válaszokat fogalmazod. Egy héten belül legalább három kiegészítő lepte el a Chrome Web Store-t és legalább egy tucat thread indult, csak a Redditen.

https://quuxplusone.github.io/blog/2019/11/20/slack-rich-text-box/
https://news.ycombinator.com/item?id=21591950
https://www.reddit.com/r/hackernews/comments/dzihdv/disable_new_slack_w…
https://www.reddit.com/r/programming/comments/dzm39m/disable_the_wysiwy…
https://www.reddit.com/r/Slack/comments/dr2y5k/has_anyone_figured_out_a…
https://capiche.com/q/what-do-you-think-of-slacks-new-wysiwyg-editor
https://www.reddit.com/r/Slack/comments/dykbxl/who_else_doesnt_like_the…
https://github.com/kfahy/slack-disable-wysiwyg-bookmarklet

Kérdem én, hogy miből állt volna lefejleszteni rendesen a WYSIWYG szerkesztőt, majd a meglévő felhasználóknak opcionálisan bekapcsolhatóvá tenni és aki feliratkozott a mindenféle beépített "What's new" értesítésekre az új feature-ökről, azoknak kiküldeni, hogy már ez is elérhető. Aki meg leiratkozott róluk, azokat meg nem basztatni és hagyni dolgozni, a munkameneteik szándékos felforgatása helyett. Az új felhasználóknak pedig mondjuk alapból bekapcsolni és majd ők eldöntik, hogy átváltanak-e helyette a markdown-szerkesztőre vagy sem, miután felfedezték a Preferences menüt.

Semmiből nem állt volna, mivel pontosan ezt csinálták később, avagy a Slack később tanult a hibájából, és kivételesen hallgatott a felhasználókra, még ha ez a multiknak nem is szokása. Viszont összeadva több tízezer értékes órát pazaroltattak el azokkal az emberekkel alternatívák, hackek, megoldások keresésére, akiknek az arrogáns A-B tesztjükkel szándékosan felforgatták a munkamenetüket. Mindamellett, hogy maga a Slack is rengeteg felesleges erőforrást elpocsékolt egy lila UX-ködben élő termékmenedzser idealizmusaira, ahelyett hogy egyből legkézenfekvőbb és legkevésbé kártékony megoldást választotta volna. Azt senki ne magyarázza be nekem, így kérlek te sem, hogy egy Slack méretű és profilú cég egy ilyen változtatás hatásait nem képes józan ésszel felmérni, pont olyan haladó felhasználók körében, akik allergiásak a mindenféle felület-okosításra, meg inkább markdown-ban írnak meg minden formázást, mintsem WYSIWYG editorban. Mert ha ez így van, akármelyik cégnél, ott rettentő nagy problémák vannak.

lehet, hogy én voltam valami extra csoportban, de mikor nekem roll-outolták a rich editort, bementem a preferencesbe, és ott ki tudtam kapcsolni.

de a munkahelyemen csak én használom így. és meg is értem, hogy kényelmesebb a főnökségnek, hogy használhatják a gombokat.

aki "power user", annak nem okoz nagy gondot az egyszer 15 másodperc, míg kiveszi a pipát

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

lehet, hogy én voltam valami extra csoportban, de mikor nekem roll-outolták a rich editort, bementem a preferencesbe, és ott ki tudtam kapcsolni.

Igen, ez lett később, a felháborodások után, de bizonyos csoportoknak előtte kikapcsolhatatlan volt.

de a munkahelyemen csak én használom így. és meg is értem, hogy kényelmesebb a főnökségnek, hogy használhatják a gombokat.

Ismételném magam: A felhasználói igények nagyban különböznek egymástól a felhasználók előzetes tudásától, illetve a felhasználás céljától függően.

aki "power user", annak nem okoz nagy gondot az egyszer 15 másodperc, míg kiveszi a pipát

Az nem, de a kikapcsolhatatlan WYSIWYG okozott. A kritika a Slack arrogáns A-B tesztelésének és az először bemutatott kikapcsolhatatlan WYSIWYG editornak szólt. Kicsit úgy tűnik, mintha a hozzászólásom második felét nem olvastad volna el.

AZ MVT-nek pont az a lényege, hogy nem rolloutolod az új verziót az összes felhasználónak. Ha volt erre rendes teszt, akkor a felháborodásból arra következtetnék, hogy szignifikáns számú felhasználónak nem nyerte el a tetszését. Azt nem tudom, hogy Slack esetén erre mi lenne az ideális metrika (mi legtöbbször a bevételt használtuk, de ez itt nem játszik), de abból látszania kellett volna, hogy ebben a formában nem szabad rolloutolni. Én arra tippelek, hogy ezt a Slack soha nem tesztelte, és abban sem vagyok biztos, hogy vannak tesztjeik.

Egyébként én úgy emlékszem, hogy a WYSIWYG editor a kezdetektől támogatja a megszokott Markdown-jellegű (mert soha nem volt valódi Markdown) formázási utasításokat, amiket az editor felismer és alkalmazza a megfelelő formázást. Vagyis továbbra is használhatod a megszokott formázási karaktereket, nem kell az editor gombjait használni a formázáshoz. Nekem ez így megfelel, de azt is el tudom fogadni, hogy van, akit ez zavar.

AZ MVT-nek pont az a lényege, hogy nem rolloutolod az új verziót az összes felhasználónak.

Igen, és itt vissza is kanyarodhatunk ahhoz, hogy közvéleménykutatás eredménye alapján akarunk népszavazást igénylő kérdést eldönteni, vagy olyasvalamit ráerőltetni tömegekre, amiben nincsen konszenzus.

Amit a Slack művelt az nem csak ebből a szempontból volt szakmaiatlan, hanem, hogy valamennyire saját magát is szembeköpte. Az IRC és az XMPP kiyírása után is elég sok power user és developer haragudott rájuk, pláne, amikor még 2+ GB memóriát zabált fel fél nap használat után a régi, bloated, mindent leakelő webes kliensük, amit aztán szerencsére újraírtak. Ezt megkoronázták még azzal, hogy jónéhány markdown-t preferálónak kötelezővé és kikapcsolhatatlanná tették a WYSIWYG editort.

Ilyet nem csinálunk. Lehet magyarázni mindenféle UX-idealizmussal, meg modern, felhasználói élményt segítő tudománnyal, a lényeg nem változik: Ilyet nem csinálunk.

Arról nem beszélve, mondom még egyszer, hogy amennyi erőforrással kivitelezték ezt az MVT-t, simán belerakhatták volna először magát a beállítási lehetőséget és azt telemetriázva (nem is kell, hisz a szerveren tárolódik) kaptak volna egy teljes képet arról, hogy ki milyen százalékban preferálja melyiket. De nem érdekelte őket. Jobban a dolgok mögé nézve, a háttérben felsejlik a termékmenedzseri szélsőséges idealizmus, miszerint először a WYSIWYG editort preferáló menedzsereket kell meggyőzni, hogy a Slack az milyenjó™, mert ők vannak döntési pozícióban és ők döntenek arról, hogy meghosszabbítják-e az előfizetést, vagy ha látják másnál, a saját cégüknek is rendelnek egyet. Egy háromműszakos családanya éves fizetéséből vett öltönyben léptető, márkás órát hordó, iPhone-t tapicskoló, sikeres™ top menedzser szemében milyen béna™ dolog már, hogy a kilencvenes évek Word 5.0-ját, meg a web hőskorát idézve szimbólumokkal (markdown) lehet csak formázni a szöveget. A fejlesztők meg kit érdekelnek, majd hozzászoknak™.

Az arroganciára nincs mentség.

Egyébként én úgy emlékszem, hogy a WYSIWYG editor a kezdetektől támogatja a megszokott Markdown-jellegű (mert soha nem volt valódi Markdown) formázási utasításokat, amiket az editor felismer és alkalmazza a megfelelő formázást.

Ami pont azért volt katasztrófa, mert utána már nem tudod markdown-ként látni, így onnantól már csak kattintgatással tudtad formázni a beírt szöveget. Ráadásul az így bevitt formázás semmilyen módon nem volt átjárható a Slack és más rich-text-et vagy markdown-t támogató alkalmazások között.

A felhasználói igények nagyban különböznek egymástól a felhasználók előzetes tudásától, illetve a felhasználás céljától függően. Attól, hogy 80% tapicskoló egységsugarú ösztönlény, akiben a tech-multik sokkal inkább csak a fogyasztót és nem a tudatos felhasználót látják, egy dolog. Alapvetően egy társadalmi hiányosságot, illetve az informatika oktatás katasztrofális helyzetét szerte a világon használják fel ürügynek arra, hogy óvodás szintű felhasználói felületeket készítsenek, egységsugarú tapicskolóknak, akiknek ez által esélyük nincs nem egysésugarú tapicskolóknak lenni, hiszen minden technikai részlet el van rejtve előlük, nehogy esetleg átlássák, hogyan működik. Elég, ha használni tudják.

Leegyszerűsítve szemléltetve: windowsvsmacintoshvslinct8.jpg

Amióta az Apple kijött az iPhone-nal, azóta mindenki próbál egy kicsit hasonlítani rá, mindenben, és ezzel lehet, hogy egy kicsit több profitot realizálnak, de sokkal több kárt okoznak az egyes ökoszisztémáknak és megannyi helyen rontják a felhasználás hatékonyságát a nem kezdő tudaással rendelkező felhasználók körében.

Pedig fröcsögés nélkül is egyszerűen el lehetne fogadni

A fröcsögés két dologra vonatkozik, és arra jogosan.

  1. Nem képesek, még a drágább okostelefonoknál, tableteknél sem haladó szintű UI-t készíteni, csak tapicskolóknak szánt, animációbuzi konzumer UI-t. Mindezt úgy, hogy általában milliárdos nagyvállalatok állnak a projektek mögött, akik megengedhetnék maguknak.
  2. A desktop alkalmazásokat is egyre inkább mobile-first dizájnolják, amivel nehezítik a még mindig dominánsan egérrel és billenytűzettel való használatot, monitor előtt, amellett, hogy a desktop alkalmazásokra jellemző átláthatóságot, kompaktságot is rituálisan feláldozzák a UX-trendek oltára előtt.
Szerkesztve: 2021. 05. 21., p – 10:46

Komolyan nincs egy kibaszott GUI designer, ahol delphi módjára szépen meg lehet csinálni a formot, és utána csak mögé tenni a function-öket?

De van: úgy hívják, Lazarus. Pont ugyanúgy működik, mint a Delphi, csak épp cross-platform és persze már sokkal fejlettebb.

ha az egesz KDE-t meg tudtak csinalni Qt-ban akkor nem lehetetlen

neked aztan fura humorod van...

Évekkel ezelőtt össze kellett dobnom egy primitív GUI-t. A VS 2013 szerkesztőjében voltak hasznos konténerek. Nem tudom biztosan, hogy a "Tényleg nekem kell minden gomb és egyéb object méretét, pozícióját kézzel megadni, egyesével léptetve futtatni és megnézni hogy hogy néz ki a form, jó helyen van-e a gomb, és pixelenként kell szarakodni?" mit jelent, de szerintem nem tapasztaltam. Voltak konténerek, amikben maguktól rendeződtek az objektumok. Ezeket okosan használva létre lehetett hozni egy átméretezéskor megfelelően rendeződő tartalmú felületet. Nyilván egy-két alap dolgot be kellett állítani, de elég volt egyszer, utána csak többszörözni kellett az objektumokat. Hasonlított egy vizuális CSS szerkesztőre.

:)

Free Pascal es a Lazarus a mai napig fejlesztes alatt all es megy is szepen, fut kb. mindenen. Fpcupdeluxe-al lehet beloluk olyat buildelni, amilyet akarsz. Siman csinal a jelenlegi SVN trunk-bol lazarus+fpc kombot.

+1 Lazarus fpc.

Én is szerettem a Delphit, bár most is van ingyenes változata. A Lazarus-ban viszont a platformfüggetlensséget szeretem.

A Borland által kitalált RAD technológia nagyon jó volt.

Szerkesztve: 2021. 05. 21., p – 16:20

Le™ vagy™ maradva™.

Már nem divat kompakt, használható, jól átlátható GUI-kat csinálni.

Mobile-first™ tapicskoldát tessék, Material alapon, animációkkal, szemkifolyató webfontokkal, alacsonykontrasztú betűszínekkel, színtelen-szagtalan, steril körvonalas ikonokkal, végtelen paddinggal, óvodásoknak készített 16 színes rajzokkal, természetesen 4K-ban, élsimítással, realisztikusnak, professzionálisnak csak a Netflix-sorozatok helyszínei és az agyon CGI-zott akciófilmek tűnhetnek a minél nagyobb felbontású megjelenítőn. Lehetőleg minél kevesebb információt, minél nagyobb pixelszámú felületen megjeleníteni, Full HD alatt ne férjen ki semmi sehová. Lehetőleg óvodás szintjére butítva az egészet. Ja és legalább 4 magos processzor, meg 16GB memória kelljen hozzá, natív kódot pedig ne tartalmazzon, a grafikát CSS-sel oldd meg, az üzleti logikát pedig valamelyik menő™ JS-frameworkkel.

Most pedig, hogy túljutottunk a szarkazmuson, respekt, hogy ragaszkodsz a normális GUI-khoz és ha elfogadsz egy tanácsot, akkor maradj a Delhpinél, vagy ha ez nem megoldható, akkor valamelyik open-source alternatívájánál. A világ egyik legjobb és legidőtállóbb szoftverét, a Total Commandert a mai napig Delphi 2-ben (32-bites változatot) és Lazarus-ban (64-bites változatot) fejleszti a készítő és úgy került bele rengeteg funkció az évek alatt, hogy a régieket nem sikerült elbaszni.

Bár nem divat mostanság, a Java világban több ilyen is van (desktop appokhoz is használhatók, csak a szívások elkerülése végett érdemes lehet hozzácsomagolni a megfelelő JRE-t is):

Nem tudom, melyik mennyire friss, mert nem javázom egy jó ideje, de azért van ilyesmi. (Persze, ez a powershelles problémán nem feltétlenül segít, csak az általános témához írtam ezeket.)