Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: hknmtt 23. 04. 2025, 14:44:38
-
Mam na webe obycajne strankovanie vysledkov, ktore mi moze vratit nieco ako [1,2,3,4,5,6,7,8,10..] a povedzme, ze si kliknem na cislo 6 a zobrazim si celu entitu.
Chcel by som co najefektivnejsie najst susedov, aby som sa mohol preklikat na predosly alebo nasledovny vysledok. Cize ak som na obsahu s ID=6 tak chcem 5 a 7.
Chcel by som vsak predist tomu, aby som opakoval strankovaciu query a len pouzit aktualne id, 5, ako limitus pre najdenie predosleho a nasledovneho id.
Je to mozne spravit nejak jednoducho, bez nutnosti dvoch query, alebo dvoch sub-query, a vlastne len spusti zase tu strankovaciu query s tym, ze poviem ze 5 je "ciel" a chcem len susedov?
-
a nechceš napsat aspoň, kterou databázi používáš?
Zpravidla tohle nejde snadno a třeba v případě mysql to znamená si tu stejnou tabulku tam připojit dvakrát znovu a najít předchozí a následující řádek podle aktuálního řazení.
-
Maria/Mysql.
-
Moc jste nepopsal, co vlastně chcete. Pokud je to opravdu tak, jak popisujete na příkladu, tedy že máte vzestupně řazená ID a jde vám jen o to získat sousední ID, tak prostě uděláte SELECT id FROM tbl WHERE id > $selectedID ORDER BY id LIMIT 1 pro následující ID, nebo SELECT MIN(id) FROM tbl WHERE id > $selectedID – normální databáze by měla pochopit, že jde o to samé a vybrat stejný prováděcí plán, u MariaDB/MySQL bych radši porovnal obě varianty, možná jedna z nich bude lepší. Tím získáte ID následujícího záznamu, pro získání ID předchozího záznamu si to snad upravíte sám. A pokud to chcete jedním dotazem, spojíte ty dva SELECTy pomocí UNION.
-
Možná mohou pomoci funkce LAG a LEAD, ty ti mohou dát hodnotu v vybraném sloupci z předchozího nebo následujícího záznamu.
https://dev.mysql.com/doc/refman/8.4/en/window-function-descriptions.html#function_lag
https://dev.mysql.com/doc/refman/8.4/en/window-function-descriptions.html#function_lead
-
Možná mohou pomoci funkce LAG a LEAD, ty ti mohou dát hodnotu v vybraném sloupci z předchozího nebo následujícího záznamu.
https://dev.mysql.com/doc/refman/8.4/en/window-function-descriptions.html#function_lag
https://dev.mysql.com/doc/refman/8.4/en/window-function-descriptions.html#function_lead
Ale to asi len dava hodnotu v kontexte tabulky odkial sa selectuje, ale nie v kontexte query ktora vracia finalne vysledky, nie?
-
Možná mohou pomoci funkce LAG a LEAD, ty ti mohou dát hodnotu v vybraném sloupci z předchozího nebo následujícího záznamu.
https://dev.mysql.com/doc/refman/8.4/en/window-function-descriptions.html#function_lag
https://dev.mysql.com/doc/refman/8.4/en/window-function-descriptions.html#function_lead
Ale to asi len dava hodnotu v kontexte tabulky odkial sa selectuje, ale nie v kontexte query ktora vracia finalne vysledky, nie?
Nevím jak v mysql, ale v např oracle je to v kontextu query.
Pokusil jse se udělat příklad a při filtraci nad tabulkou to funguje v kontextu query.
https://sqlfiddle.com/mysql/online-compiler?id=9ecc9f50-2620-480d-ad12-9186f69576b1
-
Pak je tu ještě možnost že to je opravdu průchod výsledkovou sadou toho vyhledávání (podle konkrétních kritérií včetně nějakého řazení), a ne celou tabulkou. Pak se může hodit i mít tu celou výsledkovou sadu někde vedle uloženou (ve struktuře typu (id_vysledkove_sady, poradi_vysledku_v_sade, id_vyhledaneho_objektu) - a pro procházení tou sadou ve stylu next/previous (případně i stránkování) si předávat všechny tři (next znamená např. "jsem na výsledkové sadě id 1234 na položce č. 3 což je entita s id 9999 - zmáčknu next - dám požadavek že chci ze sady č. 1234 položku č. 4 - a k tomu se pak rychle dohledá že to je entita třeba s id 1645").
Je to o výběru jestli chci mít stabilní výsledkovou sadu (a jistotu že X*next + X*prev mě vždzycky vrátí tam kde jsem začal, i když se něco mezi přidá/smaže/změní podmínky takže to vypadne z výsledků vyhledávání/...) nebo to nepotřebuju (a můžu mít jednodušší implementaci).
I stránkování se pak dělá jenom tak že si z té odložené sady řeknu o položky od nějaké pozice ( (číslo stránky - 1) x (velikost stránky) + 1) do nějaké pozice ( (číslo stránky) x (velikost stránky) ).
LAG a LEAD mi můžou při zobrazení detailu jedné entity najít ID těch sousedů, ale po přechodu na další musím udělat znova vyhledávací dotaz abych mohl najít next/prev k nové entitě ve stejném pořadí (a ještě ve výsledku hledat kde mám aktuální entitu abych věděl ke komu najít toho předchozího a následujícího? No to můžu rovnou kouknout na předchozí a následující řadek toho co mi vrátila databáze ...).
Udělat dva selekty na "největší menší" a "nejměnší větší" id co jsou v té výsledkové sadě je lepší, ale pokud se to má procházet se složitou vyhledávací podmínkou a jěště nějak seřazené tak to taky rozhodně může skončit dost pomalé.
-
Hm, ono ide o to, ze ja si sice mozem spravit "cache" tabulku s vysledkami a spravit jednoduchu query bez joinov a filtrov, len som hladal nieco univerzalne, lebo nie vzdy je to mozne urobit a teda potom neostava nic ine len pouzit dve query/sub-query na najdenie susedov.
-
Od verze 8.0 by melo MySQL mit alespon castecnou podporu ISO SQL:2008, konretne windowing functions LAG a LEAD.
-
Na subquery není nic špatného, je to univerzální a je to naprosto v pořádku. Navíc to, co popisujete vy, je to, že chcete získat jeden záznam a ID ze dvou okolních záznamů. Takže triviální implementace je získat tři záznamy a z těch dvou krajních použít jen ID. Nesnažte se optimalizovat databázové dotazy, když nevíte, zda v nich je nějaký problém.
Navíc jste pořád nepopsal, jaký konkrétní problém řešíte, tak těžko dostanete konkrétnější odpověď. A to, co jste zatím popsal, moc smysl nedává. Vypadá to, že máte nějaké master–detail zobrazení, tj. máte sadu záznamů a prohlížíte po jednom detaily záznamu. V takové situaci chce uživatel procházet fixní sadu záznamů – takže dotaz na výběr záznamů dle podmínek se udělá jen jednou, zapamatují se ID záznamů a uživatel pak prochází ten předem daný seznam ID. Podle vašeho dotazu to asi bude nějaká webová aplikace, když vás nenapadlo rovnou tu sadu výsledků si pamatovat. Ale když to má procházet uživatel po jednom, těch záznamů stejně budou maximálně desítky, při nejhorším stovky, takže není problém si to zapamatovat i ve webové aplikaci.
To, že se to dělá nad fixní sadou záznamů, je proto, že pro uživatele by to bylo matoucí, kdyby ten dotaz byl živý. Pak půjde uživatel na třetí stránku, bude tam mít záznam 4, přejde jinam, vrátí se na stranu tři a bude tam mít záznam 6. Nebo půjde na stranu čtyři, bude tam mít záznam 5, půjde na předchozí stranu a znovu tam bude mít záznam 5. To by pro uživatele bylo matoucí, proto se ta sada záznamů vybere jednou a pak se uživatel pohybuje v ní. Když jde na konkrétní záznam, stáhnou se aktuální data, může se tam zobrazit, že už záznam neodpovídá původním podmínkám, ale to je vše.
Dovedu si představit i případ, že by uživatel zpracovával výsledky živého dotazu, ale pak bude postupovat jen dopředu.
-
Od verze 8.0 by melo MySQL mit alespon castecnou podporu ISO SQL:2008, konretne windowing functions LAG a LEAD.
A mariadb myslím od verze 10.2.
Kloním se k tomu co píše Filip nademnou, pusuň offset dozadu, ztrojnásobi limit a načti si prostě 3 stránky najednou. Pak v aplikaci vykreslíš jen tu prostředí část, tak se tyhle preloady obvykle dělají. Bude to stokrát levnější než LAG/LEAD.
LAG/LEAD se hodí na to, když máš nějaké uid řádku a potřebuješ podle nějakého řazení ty předchozí, další, ale pokud máš stránkování, tj. neznáš konkrétní řádky, ale posouváš se seznamem, můžeš prostě rozšířit oblast načtení...
-
Nacti si 3 stranky najednou. Tedy 5,6,7 a zobraz jen tu 6.
Coz ale neresi problem kdyz se presunes na stranku 5. Pak ti bude chybet stranka 4.
Asi budes muset udelat cache na nejaky pocet stranek a nekdy ho budes muset nacist znova.
-
Udržiavať si stav na backende asi nie je riešenie. Predpokladám, že stránkovanie môže vracať rôzne výsledky v závislosti od nastavenia filtrov a zoradenia. Teda jeden používateľ môže mať otvorených viac tabov a v každom vidieť inak stránkované záznamy. Takže z pohľadu backendu by to malo byť stateless.
Vytiahnuť si susedov hneď s daným záznamom tiež nerieši problém úplne. Ako poznamenal Zdeno Sekerák vyššie, len po posunie problém o krok (n-krokov) ďalej.
Chcelo by to storage, ktorý je "tab-local". Ak tých záznamov nie je veľa, možno by sa celá sekvencia ID-čiek dala poslať a uložiť na frontend. Znie to obludne, ale myslím, že array s pár tisícami čísel by v praxi fungoval ok. V prípade, že ide o old school web, kde sa stránka stále načítava odznova, dalo by sa to "uložiť" ako URL query parameter ("records.html?filters=...&order=...&ids=1,2,3,4,..."). Priznávam, ešte väčšia obludnosť, ale funkčná :)
Ak je tých záznamov naozaj veľa a platí môj úvodný predpoklad, tak dodatočnej query by som sa asi nevedel vyhnúť.
-
Udržiavať si stav na backende asi nie je riešenie. Predpokladám, že stránkovanie môže vracať rôzne výsledky v závislosti od nastavenia filtrov a zoradenia. Teda jeden používateľ môže mať otvorených viac tabov a v každom vidieť inak stránkované záznamy. Takže z pohľadu backendu by to malo byť stateless.
Udržovat si stav na backendu je řešení. Věci jako session už byly vynalezeny. Každá záložka v prohlížeči si může pamatovat identifikátor své sady záznamů uložené na serveru.
Pokud s tím má uživatel nějak rozumně pracovat, budou těch záznamů desítky, v extrémním případě stovky. Takže si je může pamatovat i prohlížeč.
Vytiahnuť si susedov hneď s daným záznamom tiež nerieši problém úplne. Ako poznamenal Zdeno Sekerák vyššie, len po posunie problém o krok (n-krokov) ďalej.
Řeší to problém úplně, protože při přechodu na jinou stránku a pošle požadavek na server a načte se nová trojice.
Ak je tých záznamov naozaj veľa a platí môj úvodný predpoklad, tak dodatočnej query by som sa asi nevedel vyhnúť.
Pokud těch záznamů budou tisíce, tak je stejně nedokáže zpracovat uživatel.
Stránkování v aplikacích už bylo vyřešeno milionkrát a použitelná řešení už tu byla popsána několikrát. Jaké konkrétní řešení použít nemůžeme poradit, protože nevíme, jaký konkrétní problém hknmtt řeší (jako obvykle).
-
Když už ukládat do cache, tak spíš víc stránek, třeba 5. Pak by se nové do cache načítaly. jen když uživatel přejde na hraniční stránku.
(Anebo tlačítko Načíst další a připojit další sadu na konec tabulky - na vyžádání, ne infinite scrolling)
-
Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.
-
Udržiavať si stav na backende asi nie je riešenie. Predpokladám, že stránkovanie môže vracať rôzne výsledky v závislosti od nastavenia filtrov a zoradenia. Teda jeden používateľ môže mať otvorených viac tabov a v každom vidieť inak stránkované záznamy. Takže z pohľadu backendu by to malo byť stateless.
Udržovat si stav na backendu je řešení. Věci jako session už byly vynalezeny. Každá záložka v prohlížeči si může pamatovat identifikátor své sady záznamů uložené na serveru.
Session je jedna pre všetky taby. Implementuje sa ako ID-čko uložené v cookies, a cookies sú naviazané na adresu webu, nie na tab. Alebo máte na mysli nejakú inú formu session?
Vytiahnuť si susedov hneď s daným záznamom tiež nerieši problém úplne. Ako poznamenal Zdeno Sekerák vyššie, len po posunie problém o krok (n-krokov) ďalej.
Řeší to problém úplně, protože při přechodu na jinou stránku a pošle požadavek na server a načte se nová trojice.
Práve ste povedali, že pri prechode sa načíta nová trojica => musí sa nanovo spustiť stránkovacia query. Tomu sa predsa OP chce vyhnúť, to je podstata tejto diskusie.
-
Práve ste povedali, že pri prechode sa načíta nová trojica => musí sa nanovo spustiť stránkovacia query. Tomu sa predsa OP chce vyhnúť, to je podstata tejto diskusie.
Není mi jasné, proč se chce vyhnout opětovnému dotazu do databáze. Podle mne je to nejefektivnějším řešením.
-
Jediný dotaz stačí, když načte všechno, pošle to do prohlížeče a ta čísla [1,2,3,4,5,6,7,8,10..] budou přepínat taby ...
-
Session je jedna pre všetky taby. Implementuje sa ako ID-čko uložené v cookies, a cookies sú naviazané na adresu webu, nie na tab. Alebo máte na mysli nejakú inú formu session?
Nikoli. Session jsou data uložená na serveru pod nějakým identifikátorem, přičemž identifikátor je v prohlížeči. Identifikátor session může být klidně v URL, v paměti aplikace, v Session/Local Storage, i v té cookie.
Práve ste povedali, že pri prechode sa načíta nová trojica => musí sa nanovo spustiť stránkovacia query. Tomu sa predsa OP chce vyhnúť, to je podstata tejto diskusie.
No, co chce hknmtt nevíme, protože to tají. Z původního dotazu to vypadalo spíš že nechce pouštět celý dotaz (pravděpodobně se spoustou joinů) na získání dat pro detail, když potřebuje znát pro předchozí/následující stránku jen id. A dotazy jsou pravděpodobně nějak automaticky generované a hknmtt buď neumí nebo nemůže upravit jejich generování tak, aby vracely jen id. Ale ono je to celkem jedno, hknmtt nechce vyřešit svůj problém, proto ho nepopsal, takže je to tady spíš takové nezávazné povídání o tom, co všechno se může skrývat za pojmem „stránkovaný dotaz. Přičemž je dost možné, že hknmtt o žádné stránkované dotazy nestojí, protože za stránkované dotazy se obvykle označuje něco, co velké množství záznamů zobrazuje postupně po stránkách (v databázové terminologii se tomu říká spíš okna), zatímco hknmtt psal o tom, že zobrazuje jen jeden záznam. Takže jde spíš o master–detail zobrazení, kdy chce na detailu zároveň zobrazovat odkazy ne sousední záznamy (vzhledem k masteru).
Jinak kdyby hknmtt opravdu nechtěl znovu spouštět dotaz na celou sadu záznamů (master), jediná možnost by byla zapamatovat si celý výsledek v nějaké cache a procházet tu. Protože ať uděláte to okno sebevětší, vždy se uživatel může doklikat až na konec a pak nezbyde než ten dotaz udělat znovu. Jenže to je právě problém, že my nevíme, jaký problém hknmtt řeší a proč by nechtěl provádět dotaz znovu (a který dotaz, protože u master–detail jsou dotazy dva).
-
No, co chce hknmtt nevíme, protože to tají. Z původního dotazu to vypadalo spíš že nechce pouštět celý dotaz (pravděpodobně se spoustou joinů) na získání dat pro detail, ...
Obávám se, že OP bude mít v tom dotazu ± jeden join, jinak by se o jeho složitosti zmínil.
-
Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.
hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?
-
Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.
hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?
K čemu by bylo zobrazení tabulky, která má víc než 1 000 řádků? Bude to nějaký uživatel procházet očima řádek po řádku? Pokud chcete uživateli zobrazit tabulku s více než tisíci řádky, není potřeba řešit, jak mu to zobrazit, ale jak mu umožnit zadat takové filtrovací či vyhledávací podmínky, aby našel, co hledá.
-
K čemu by bylo zobrazení tabulky, která má víc než 1 000 řádků? Bude to nějaký uživatel procházet očima řádek po řádku? Pokud chcete uživateli zobrazit tabulku s více než tisíci řádky, není potřeba řešit, jak mu to zobrazit, ale jak mu umožnit zadat takové filtrovací či vyhledávací podmínky, aby našel, co hledá.
no ved to nechcem :)
z praktickeho hladiska je strankovanie jedna z praktickych moznosti ako to lahko a efektivne "filtrovat".
Predrecnik tvrdil, ze "strankovanie je zlo". Ale uz nedodal: musite zabit kopu casu a namahy pre vyrobenie velmi dobreho filtrovania, pretoze rozumny limit je povedzme 100 zaznamov.
-
Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.
hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?
Zobrazit 1000+ radek v prohlizeci zase neni takovy problem. Otazka je jestli o to uzivatel doopravdy stoji.
U nekonecneho scrolovani mate vyhodu ze uzivateli nerikate kolik zaznamu jste nasli.
U strankovani nekde zobrazujete x/y, kde "x" je aktualni stranka a "y" je celkovy pocet stranek. Spocitat to y byva casto velmi narocne na vykon a uzivatele to casto ani nezajima. Projde jen prvnich 3-5 stranek a pak zada jiny dotaz.
U nekonecneho strankovani si zapamatujete posledni zobrazene ID a to pak pridavate do filtru where clausule:
WHERE 1=1
and ID > :last_diplayed_id
and <... dalsi podminky hledani >
FETCH FIRST 50 ROWS ONLY;
Pokud mate dobre udelane indexy, tak se pouzije INDER RANGE SCAN a databaze nemusi znovu prochazet zaznamy ktere uz byly zobrazene predchozim dotazem. To je totiz hlavni problem se strankovanim. Pro zobrazeni x-te stranky databaze musi stejne projit stranky 1 az (x-1). Ke zobrazeni celkoveho poctu stranek databaze prochazi uplne vsechny nalezene zaznamy a pak posle uzivateli jen maly vyrez dat.
-
Zobrazit 1000+ radek v prohlizeci zase neni takovy problem.
podla mojho pozorovania spravania prehliadacov je :) jednoducho to zvycajne meratelne dlho renderuje, v nejednom pripade scrollovanie laguje a tak.
Ale som ochotny uznat, ze problem je pri vacsom pocte riadkov, nikdy som si nerobil statistiku.
Otazka je jestli o to uzivatel doopravdy stoji.
samozrejme, ze nestoji :)
problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.
(ked programator pomysli, tak samozrejme uzivatel ma k dispozicii lahko pouzitelne spravne filtrovanie a nepotrebuje zobrazovat viac nez povedzme 30 zaznamov)
U strankovani nekde zobrazujete x/y, kde "x" je aktualni stranka a "y" je celkovy pocet stranek. Spocitat to y byva casto velmi narocne na vykon a uzivatele to casto ani nezajima. Projde jen prvnich 3-5 stranek a pak zada jiny dotaz.
svet nie je len nasepkavac v googli :)
U nekonecneho strankovani si zapamatujete posledni zobrazene ID a to pak pridavate do filtru where clausule:
...
Takze ked chcem vidiet posledny 1000ci prvok, tak mi skusate nahovorit, ze mam byt nadseny, ze budem 19x riesit problem pomaleho scrollovania (kedze zakazdym doplnite 50 zaznamov), kde zakazdym bezi pomaly dotaz na server a do databazy? (bez ohladu na optimalizaciu, rezia je sama o sebe neprijemna)
---
ok, chapem, ze ak je gro vasej prace robenie veci ako nasepkavac, tak rozumiem, ze "nekonecne scrollovanie" je fajn.
Len na zaciatku ste sformulovali ultimatnu myslienku, ze to je vo vseobecnosti jedine spravne riesenie.
Tak ma zaujalo, nakolko prehanate.
Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.
-
problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.
V takovém případě je problém v tom, že uživatelské rozhraní navrhuje programátor a ne UX designer. Ostatní jsou už jen důsledky.
Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.
V tom vašem příkladu z praxe budete zobrazovat 500 záznamů třeba po 10 na jedné stránce. Uživatel bude chtít záznam s pořadovým číslem 375 (je dost nepravděpodobné, že by věděl přesně, kde v seznamu jeho záznam je, ale dejme tomu.). Spočítá si tedy, že jeho záznam bude na stránce 37. Zobrazíte uživateli čísla stránek od 1 do 50? Nebo zobrazíte pár čísle stránek kolem aktuální stránky Nebo ho necháte číslo stránky napsat? Nebude přeci jen lepší nechat návrh uživatelského rozhraní na UX designérech? Tu aplikaci asi také neprogramují obchodníci, ale někdo, kdo rozumí programování. Stejně tak by uživatelské rozhraní měl navrhovat někdo, kdo rozumí návrhu uživatelského rozhraní.
-
problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.
V takovém případě je problém v tom, že uživatelské rozhraní navrhuje programátor a ne UX designer. Ostatní jsou už jen důsledky.
Obvykla rydzo teoreticka poznamka cloveka co nevie o com hovori.
Uz Vam to tu povedalo v roznom kontexte hrst ludi, takze chapem, ze to je hadzanie hrachu na stenu.
Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.
V tom vašem příkladu z praxe budete zobrazovat 500 záznamů třeba po 10 na jedné stránce. Uživatel bude chtít záznam s pořadovým číslem 375 (je dost nepravděpodobné, že by věděl přesně, kde v seznamu jeho záznam je, ale dejme tomu.). Spočítá si tedy, že jeho záznam bude na stránce 37. Zobrazíte uživateli čísla stránek od 1 do 50? Nebo zobrazíte pár čísle stránek kolem aktuální stránky Nebo ho necháte číslo stránky napsat? Nebude přeci jen lepší nechat návrh uživatelského rozhraní na UX designérech? Tu aplikaci asi také neprogramují obchodníci, ale někdo, kdo rozumí programování. Stejně tak by uživatelské rozhraní měl navrhovat někdo, kdo rozumí návrhu uživatelského rozhraní.
odporucam citat kontext. Predrecnik povedal o "jedinom spravnom rieseni". Nic o UX dizajneroch.
-
odporucam citat kontext. Predrecnik povedal o "jedinom spravnom rieseni". Nic o UX dizajneroch.
Jenže to jediné správné řešení by měl navrhnout někdo kompetentní. Doba, kdy IT nadšenci do programovacích jazyků zobrazovali uživateli tunu informací, jen aby ukázali, že to umí, je naštěstí dávno pryč. Dneska opravdu nepotřebuju vědět, že google našel 500mil výsledků za 15ms, protože mě typicky zajímá ten první nesponzorovaný. Takže ani google ani kdokoliv jiný nemusí ve svém programu na serveru generovat půl miliardy stránek, stačí nabídnout nejlepších 100 výsledků a uživatel (já) klikne na dva.
-
Jenže to jediné správné řešení by měl navrhnout někdo kompetentní. Doba, kdy IT nadšenci do programovacích jazyků zobrazovali uživateli tunu informací, jen aby ukázali, že to umí, je naštěstí dávno pryč.
No jo, když někdo se radši svou nekompetentností pochlubí. A ještě má pocit, že je na té správné straně, protože on je přece praktik a vidí kolem sebe další podobně nekompetentní praktiky.
Samozřejmě že v nějakých malých týmech, kde ještě nepřišli na to, že mít dobré UX se vyplatí, nemusí být UX designer a jeho roli může mít někdo jiný, třeba nějaký vývojář. Ale pak by i on měl mít alespoň nějaké základní UX kompetence. A o člověku, který zastává roli UX designera, je nejjednodušší psát v diskusi jako o UX designerovi a neřešit, že má na vizitce možná napsané něco jiného. No a pokud v nějakém týmu nemá nikdo roli UX designera, je dobré vědět, že i v takovém týmu se dělají designová rozhodnutí – v drtivé většině případů špatná.