V rámci používání filtrů se už delší dobu děje jev, který mi čím dál tím více připadá nutný řešit. Všimla jsem si toho hlavně v souvislosti s přechodem na K7 a hlavně po odklonu od klasických příznaků public/private čistě na labely u větších knihoven. Tehdy se začalo např. MZK hodně zpomalovat v rámci prohlížení (především u vyhledávání) pro obyčejné uživatele, protože Krameria začaly hodně zpomalovat interní procesy.
Jakmile uživatel zvolí nějaký filtr, tak se všechny ostatní filtry na chvíli jakoby sbalí, následně se zase rozbalí a začne se loadovat obsah dotyčné digitální knihovny. Toto na první pohled není problém (a technicky chápu, proč se to děje), pokud je digitální knihovna malá a nemá obsahu příliš mnoho. Ten proces je pak rychlý tak, že si toho většina uživatelů asi hned tak nevšimne. Ale ... začíná se to poněkud komplikovat u knihoven, který mají velký fond, např. MZK nebo potenciálně třeba u NK nebo v rámci ČDK.
U takto velkých knihoven ta rychlost načítání vypadá hodně špatně (to je samostatný problém, ale těch filtrů se to taky týká), ale jak se do toho zapojí i ty filtry, které se navíc při volbě jednoho vždy sbalí a rozbalí, při volbě dalšího totéž ... a při volbě dalšího totéž, tak to může zároveň uživatele mást a demotivovat ho, aby ty filtry vůbec používal. Aby to jakoby "nerozbil". Zejména, pokud těch filtrů potřebuje použít víc ...
Problém mi přijde jak rychlost (pro uživatele frustrující), tak to skokové sbalení a následné rozbalení (v podstatě mizení) filtrů (matoucí a zbytečné).
Zkuste si pro zajímavost porovnat rychlosti zadávání filtrů a načítání např. mezi ČDK a MZK a třeba nějakou menší knihovnou, např. SVKHK nebo SVKPK. Verze klienta na tohle vliv nemá, chová se to stejně.
Bylo by možné ty filtry od toho loadingu dokumentů nějak odstínit? Třeba optimalizovat i ten samotný dotaz na klientovi nebo na serveru? Třeba filtry nechat, dokud se nenačtou další a jen je udělat neaktivní v mezičase loadingu? Zařídit, aby se filtry. neměnily dynamicky společně s načítanými dokumenty? ... ? 🙂
Disclaimer: Je mi jasné, že by to asi pořešil jiný systém zadávání filtrů, tj. naklikat filtry a pak zadat tlačítko "hledej" nebo něco takového, ale to si nemyslím, že by ten uživatelský zážitek nějak zásadně vylepšilo, spíš naopak, protože by to zpomalilo ve výsledku to vyhledávání ještě více.
V rámci používání filtrů se už delší dobu děje jev, který mi čím dál tím více připadá nutný řešit. Všimla jsem si toho hlavně v souvislosti s přechodem na K7 a hlavně po odklonu od klasických příznaků public/private čistě na labely u větších knihoven. Tehdy se začalo např. MZK hodně zpomalovat v rámci prohlížení (především u vyhledávání) pro obyčejné uživatele, protože Krameria začaly hodně zpomalovat interní procesy.
Jakmile uživatel zvolí nějaký filtr, tak se všechny ostatní filtry na chvíli jakoby sbalí, následně se zase rozbalí a začne se loadovat obsah dotyčné digitální knihovny. Toto na první pohled není problém (a technicky chápu, proč se to děje), pokud je digitální knihovna malá a nemá obsahu příliš mnoho. Ten proces je pak rychlý tak, že si toho většina uživatelů asi hned tak nevšimne. Ale ... začíná se to poněkud komplikovat u knihoven, který mají velký fond, např. MZK nebo potenciálně třeba u NK nebo v rámci ČDK.
U takto velkých knihoven ta rychlost načítání vypadá hodně špatně (to je samostatný problém, ale těch filtrů se to taky týká), ale jak se do toho zapojí i ty filtry, které se navíc při volbě jednoho vždy sbalí a rozbalí, při volbě dalšího totéž ... a při volbě dalšího totéž, tak to může zároveň uživatele mást a demotivovat ho, aby ty filtry vůbec používal. Aby to jakoby "nerozbil". Zejména, pokud těch filtrů potřebuje použít víc ...
Problém mi přijde jak rychlost (pro uživatele frustrující), tak to skokové sbalení a následné rozbalení (v podstatě mizení) filtrů (matoucí a zbytečné).
Zkuste si pro zajímavost porovnat rychlosti zadávání filtrů a načítání např. mezi ČDK a MZK a třeba nějakou menší knihovnou, např. SVKHK nebo SVKPK. Verze klienta na tohle vliv nemá, chová se to stejně.
Bylo by možné ty filtry od toho loadingu dokumentů nějak odstínit? Třeba optimalizovat i ten samotný dotaz na klientovi nebo na serveru? Třeba filtry nechat, dokud se nenačtou další a jen je udělat neaktivní v mezičase loadingu? Zařídit, aby se filtry. neměnily dynamicky společně s načítanými dokumenty? ... ? 🙂
Disclaimer: Je mi jasné, že by to asi pořešil jiný systém zadávání filtrů, tj. naklikat filtry a pak zadat tlačítko "hledej" nebo něco takového, ale to si nemyslím, že by ten uživatelský zážitek nějak zásadně vylepšilo, spíš naopak, protože by to zpomalilo ve výsledku to vyhledávání ještě více.