Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Jan Karasek 07. 04. 2022, 16:08:28
-
v článku pana Tišnovského (PyWebIO) je ukázána tvorba formulářů ve webu a jak to dělat jednoduše. Existuje ještě milion podobných nástroju, různé frameworky, kde se pracuje se vstupími prvky podobně (a to následovně):
- vstupní prvek je vesměs roztažen přes celou šíři obrazovky, i když je pro zadání potřeba pár milimetrů
- mnohdy se do vstupníhu prvku dá napsat cokoliv a po nějakém submitu je uživatel upozorněn, že tam a tam není údaj správny a po řadě se to koriguje
- čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš
- vstupní prvky např. s desettinou (čárkou) tečkou jsou zarovnány podle levého nebo pravého okraje a ne podle polohy desettiné čárky
- atd ...
Nechtěl bych si jako Sokrates teď stěžovat na mladou generaci a vykládat, jak bylo dříve všechno lepší, ale muím říct, že s podobnými formulářemi a editací by s námi zákazníci před 40 lety vyrazili dveře. Proto jsem docela překvapen, co se dá dnes všechno jako software prodat.
Rád bych se tedy zeptal:
- je nějaká vstřícnější forma editace dnes technicky nemožná? (např. javascript knihovny s vysokou podporou ineraktivní editace se skoro nevyskytují)
- bylo by to moc drahé?
- není efektivita práce dnes nutná, rozhoduje moderní vzhled?
- je to zákazníkům dnes jedno, jak budou každodenně pracovat? (v 80-letech existovaly ergonomické předpisy, jak má práce s daty na obrazovce vypadat - je ta ergonomie v rámci poptávek dnes vůbec vyžadována?)
- mohl by někdo doporučit nějakou knihovnu, kde je ta editace na solidní úrovni?
-
Vsechno je mozne. Otazka je, co si objedna zakaznik. Kazdy radek kodu stoji penize a pokud zakaznikovi staci jedno policko na jeden radek a validace na strane serveru, dostane presne to.
Muj oblibeny priklad:
Platebni brany. Vetsina z nich ma dve oddelena policka pro platnost karty a po zadani dvou cisel musim zmazknout tab, zadat 2 cisla a zase tab. Jedna (o ktery vim) brana vsak umi automaticky posouvat cloveka jakmile zada validni hodnotu do dalsiho policka a jeste k tomu zobrazuje animaci karty, kde se dana informace vyskytuje. Tzn karta se pred zadanim toho kontrolniho kodu ze zadni strany hezky otoci a zvyrazni tu cast.
-
Prepac ale velmy netusim co chces povedat.
Akoze input sa neda spravit tak aby mal presne 3 znaky?
Akoze nevies nastavit aby input bral len cisla?
Tie cisla co sa zadavaju s lava doprava co je a tom zle resp. je problem poriesit aby to slo naopak? Preco?
A vobec co tym chces povedat? Ze v 80 si mal tak rozlisenie 150x150 alebo ?
Ako moze to ci pisem pismenka s lava do prava alebo pole kde viem zadat 3 znaky ale opticky vyzera na 4 ovplyvnovat elektivitu?
a k tym knizniciam asi ich vela nie je len preto ze je to podstatne ako 0.0 prd.
Vsetko je to o peniazoch. Ak chces a mas peniaze tak programator naprogramuje aj jednorozca.
Ja vzdy hovorim zakaznikom ze vsetko sa da len otazka je kolko vedia zaplatit.
-
čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš
Ako, pre kalkulacky som mal vzdy slabost, ale taku na ktorej by sa cisla zadavali od jednotiek smero k vyssim radom(zprava do lava) som este nevidel, ani na kalkulacke s RPN. Mozete mi prezradit vyrobcu a model?
K ergonomii: no ono v tych 80 rokoch bola praca vyhradne cez klavesnicu jaksi podmienena technicky, mys alebo trackball bola skor rarita. Minula generacia uz bola klikacia a tato tukacia(do obrazovky).
K vzhladu: je to podmienene tiez technicky, v dnesnej dobe nevadi ked sa ta obrazovka prekresli desiatky krat v sekunde, naviac je pozadovana responzivita, koli sirokej skale rozliseni. Tiez je dost caste ze grafikov robia neuspesni umelci, ktory okolo UX plavali akurat v ponorke a aj to bola kalna voda...
-
Mozete mi prezradit vyrobcu a model?
Sorry za rypnutie, dnes mi to zapaluje pomaly, vy ste nemal zrejme na mysli zadavanie, ale zarovnanie inputu vlavo, ktory by pre zadavanie cisel mal byt zarovnany vpravo. To je mozne lahko upravit par riadkami v css, len dizajnerom to zrejme pride rozsypane ked polovicu poli mate zarovnanu vpravo a polovicu vlavo...
-
Osobně si myslím, že v dnešní době je oficiální postoj takový, že je to jedno a nezáleží na tom. Když jsem říkal někdejšímu kolegovi, že musíme opravit konfigurační formulář tak, aby při mačkání tab neskákal kurzor z 1. políčka na páté a že to musí reagovat na Enter (jako submit), aby nemusel uživatel tabem doskákat na tlačítko ani nemusel hledat myš, tak mně odpověděl, že nechápe, o čem mluvím. Nedokázal jsem mu to vysvětlit ani na ukázce (dle mého názoru) správného formuláře a chybného. A nebyl to hloupý člověk. Neuspěl jsem ani s argumentem, že třeba Microsoft to obvykle má (nebo aspoň tehdy měl) správně.
-
- vstupní prvek je vesměs roztažen přes celou šíři obrazovky, i když je pro zadání potřeba pár milimetrů
Pár milimetrů? To není ani jeden znak. Co zadáváte v tak malém poli? Jinak ano, políčka jsou občas o dost širší, než by bylo potřeba, což je většinou proto, aby formulář nějak rozumně vypadal. Ony "schody" přesně podle potřebných délek ztěžují orientaci ve formuláři a jsou tak neergonomické.
- mnohdy se do vstupníhu prvku dá napsat cokoliv a po nějakém submitu je uživatel upozorněn, že tam a tam není údaj správny a po řadě se to koriguje
To je částečně client / server paradigmatem. Protože data na straně serveru kontrolovat musíte. Pokud chcete mít kontrolu i na straně klienta, tak musíte vlastně duplikovat tuhle validační logiku, což znamená vyšší pracnost a riziko nekozistencí. Občas se vyskytují knihovny, které se snaží nějak řešit, že by server dokázal předávat metadata na klienta, ale nevím o ničem obecně použitelném. Takže typicky se kontroluje povinnost, občas typ (číslo / řetězec) nebo pattern, ale složitější kontroly většinou probíhají až na serveru. Také některé věci mohou vyžadovat kontrolu v DB atp., což je další komplikace.
Pokud máte na mysli tzv. maskované inputy, tak ty byly populární v devadesátkách, ale pak se od nich upustilo. Já jsem jejich hodnotu moc neviděl ani jako uživatel. Plus musíte řešit, co když do nic uživatel zkusí něco pastnout, atp.
- čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš
Jako že by se měly zadávat nejdřív jednotky, pak desítky, pak stovky... Proboha, kdo takovou šílenost vymyslel?
- vstupní prvky např. s desettinou (čárkou) tečkou jsou zarovnány podle levého nebo pravého okraje a ne podle polohy desettiné čárky
Tohle vyžaduje mít neproporcionální font, jinak to stejně vypadá blbě. Plus je to hodně crcání za malý efekt, input ve webovém prohlížeči by člověk musel dost znásilňovat.
... s podobnými formulářemi a editací by s námi zákazníci před 40 lety vyrazili dveře.
Jako že v roce 1982? Za socíku? No, když by i vyrazili, tak pak by neměli nic, protože konkurence jaksi neexistovala :-D
Pokud jste fakt tehdy nějaké aplikace dělal, tak to byly aplikace na lokálním počítači (ne-webovém), na obrazovce o přesně daných rozměrech s neproporcionálním písmem a pro zaškolené uživatele co je používali velmi často. Dnešní webové aplikace jsou pro dost jiné podmínky.
- je nějaká vstřícnější forma editace dnes technicky nemožná? (např. javascript knihovny s vysokou podporou ineraktivní editace se skoro nevyskytují)
Část je zodpovězena výše. Nějakou rozšířenou JS knihovny vyloženě na vstup dat asi nevím. Co píšu jsou React aplikace, které mají knihovnu obstarávající business logiku formulářů (final-form, formik) a UI knihovnu (Material UI, bootstrap, ...) nad kterými jsou vlastní knihovny. To je interaktivní dost :-)
-
Protože data na straně serveru kontrolovat musíte. Pokud chcete mít kontrolu i na straně klienta, tak musíte vlastně duplikovat tuhle validační logiku, což znamená vyšší pracnost a riziko nekozistencí.
Toto sa da vyriesit tak, ze na pozadi js odosle request na server, ktory vykona validaciu - presne tu istu, ktoru robi aj on a posle odpoved. Cize ziadna nekonzistentnost, validuje to jedna a ta ista funkcia.
Jako že by se měly zadávat nejdřív jednotky, pak desítky, pak stovky... Proboha, kdo takovou šílenost vymyslel?
Nie, pises normalne, ale v inpute je to zarovnane doprava.
Dnes je to najma o tom, ze formulare uz nezobrazuje len na obrazovke s presnym rastrom, ale su rozne rozlisenia, mame tu mobil/tablet a preto je lepsie mat jednotny vzhlad - napr. rovnaku sirku prvkov, aby sa to lepsie skalovalo a formular vyzeral dobre aj na malo displeji.
Co sa tyka vzhladu, tak existuje vela js frameworkov, ktore ti vedia pekne naformatovat v textovych poliach, dokonca aj podla nastaveneho prostredia, ale to uz stoji cas sa s tym piplat a v pripade velkeho firemneho sw je to tak trocha zbytocne, lebo tam ide o data, nie o vzhlad, a dolezitejsia je funkcnost.
-
Toto sa da vyriesit tak, ze na pozadi js odosle request na server, ktory vykona validaciu - presne tu istu, ktoru robi aj on a posle odpoved. Cize ziadna nekonzistentnost, validuje to jedna a ta ista funkcia.
Nechtěl jsem ze svého příspěvku dělat román výčtem úplně všech možností, ale asi budu muset :-)
Tohle se samozřejmě udělat dá. Ale má to několik nevýhod:
- Je to pracné
- Validace probíhá až se zpožděním, tedy se člověk musí tak jako tak do pole vracet
- Zatěžuje to server (občas to nevadí, občas ano)
Takže se to obecně moc nepoužívá, respektive se to používá jen na validaci nějakých specifických polí, třeba při registraci se takhle asynchronně kontroluje, zda není uživatelské jméno obsazené.
Nie, pises normalne, ale v inpute je to zarovnane doprava.
Aha, to bylo napsané tedy dost zvláštně. No, to je většinou proto, že pokud jsou ve formuláři pod sebou různě řetězce a čísla, tak vypadá blbě, když je každé zarovnané jinak. A na zadávání čísla zarovnaného doleva není nic extra neergonomického. Smysl je zarovnávat doprava má tehdy, pokud se zadává víc delších čísel pod sebou.
-
Taky mě to sere, naposled u zubaře chtěli dva archy Dotazníků, z toho jeden dokonce oboustraný!! Před 4 lety ještě nic... A to ještě operovali v respiči !
-
Vsechno je mozne. Otazka je, co si objedna zakaznik. Kazdy radek kodu stoji penize a pokud zakaznikovi staci jedno policko na jeden radek a validace na strane serveru, dostane presne to.
a kdyz si zakaznik objedna nejakou zjevnou hovadinu, ktera je sice technicky mozna ale treba mu ve vyslednem efektu vice skodi nez prospiva, tak to take dostane? To si nemyslim, ze to tak delate.
-
Mozete mi prezradit vyrobcu a model?
Sorry za rypnutie, dnes mi to zapaluje pomaly, vy ste nemal zrejme na mysli zadavanie, ale zarovnanie inputu vlavo, ktory by pre zadavanie cisel mal byt zarovnany vpravo. To je mozne lahko upravit par riadkami v css, len dizajnerom to zrejme pride rozsypane ked polovicu poli mate zarovnanu vpravo a polovicu vlavo...
chyba je na moji strane. Nevyjadril jsem se presne, takze se o to pokusim.
Zadavani napr. ciselneho udaje (7.2f ... dve mista za desetinnou teckou a max. 4 mista pred vcetne znaminka) se drive resilo tak, ze caret se pri vstupu do policka posadil na desetinou tecku a zacala se zadavat ta celociselna cast toho udaje. Pritom se caret nepohyboval a jednotlive cifry se v policku objevovaly zprava jak na kalkulacce. Pote uzivatel zmacknul znak desetinne tecky a caret se presunul do prvniho desettineho místa za tou teckou a uzivatel zadal nyni to nejvyssi desettine misto. Od desetinne tecky se to editovalo tedy jako text. Samozrejme, ze byly blokovany ty sipky a jine 'zle' znaky.
To vsechno melo ten smysl, aby uzivatel delal co nejmene chyb. K tomu byly prave ty ergonomicke studie.
Ja to nijak neobhajuji a akceptuji silu trhu. Muj pracovni étos mi to doposovad zakazoval, ale my jsme ve firme schopni se ucit dale :-)
-
Zadavani se drive resilo tak, ze caret se pri vstupu do policka posadil na desetinou tecku a zacala se zadavat ta celociselna cast toho udaje. Pritom se caret nepohyboval a jednotlive cifry se v policku objevovaly zprava jak na kalkulacce. Pote uzivatel zmacknul znak desetinne tecky a caret se presunul do prvniho desettineho místa za tou teckou a uzivatel zadal nyni to nejvyssi desettine misto. Od desetinne tecky se to editovalo tedy jako text. Samozrejme, ze byly blokovany ty sipky a jine 'zle' znaky.
Vždycky, když něco takového potkám, tak mám chuť autorům provést něco strašného. Třeba pomazat medem a přivázat do mraveniště. Nebo jim zlámat obě ruce nadesetkrát, aby už nikdy nenapsali ani řádek kódu. Nebo ještě něco děsivějšího - donutit je ten jejich neergonomický paskvil denně používat.
-
Vsechno je mozne. Otazka je, co si objedna zakaznik. Kazdy radek kodu stoji penize a pokud zakaznikovi staci jedno policko na jeden radek a validace na strane serveru, dostane presne to.
a kdyz si zakaznik objedna nejakou zjevnou hovadinu, ktera je sice technicky mozna ale treba mu ve vyslednem efektu vice skodi nez prospiva, tak to take dostane? To si nemyslim, ze to tak delate.
Ale ano, i tak se to dela. Samozrejme se mu to pokusime nejdriv vysvetlit, ale nakonec vzdycky zvitezi: Nas zakaznik, nas pan.
Ma to dva duvody:
1. vy nemusite presne rozumet tomu, co chce zakaznik delat.
2. i kdyby to byl blbec, tak mu to samozrejme nemuzete rict (a pokud pozdeji prijde, ze jste meli pravdu, tak jen dobre).
-
Samotne HTML podporuje ciselne inputy vcetne validace. Vic kmentovat nebudu. Otevrte si libovolny webovy formular, kde se zadavaji cisla.
-
- mnohdy se do vstupníhu prvku dá napsat cokoliv a po nějakém submitu je uživatel upozorněn, že tam a tam není údaj správny a po řadě se to koriguje
To je částečně client / server paradigmatem. Protože data na straně serveru kontrolovat musíte. Pokud chcete mít kontrolu i na straně klienta, tak musíte vlastně duplikovat tuhle validační logiku, což znamená vyšší pracnost a riziko nekozistencí. Občas se vyskytují knihovny, které se snaží nějak řešit, že by server dokázal předávat metadata na klienta, ale nevím o ničem obecně použitelném. Takže typicky se kontroluje povinnost, občas typ (číslo / řetězec) nebo pattern, ale složitější kontroly většinou probíhají až na serveru. Také některé věci mohou vyžadovat kontrolu v DB atp., což je další komplikace.
Nette to má by-default. Ke každému inputu, nebo formuláři se to napíše jako pravidla, a ty se potom použijí jak na serveru, tak javascriptem na klientu. Dá se tím pokrýt prakticky všechno.
Další FW to budou mít určitě taky.
-
To vsechno melo ten smysl, aby uzivatel delal co nejmene chyb. K tomu byly prave ty ergonomicke studie.
Ano, to bolo mozno super v casoch, ked sa vsetko zadavalo rucne. Ale dnes existuje aj copy&paste, a nic ma nevytoci viac, ako ked sa takto neda vlozit vstup. Dovolim zadat cokolvek, ale pri posunuti na dalsie policko ho zvalidujem. Totiz casto sa stava, ze nieco skopirujem, vlozim, a az v tom textovom poli to upravim na tvar, aky ma byt.
-
toho napsal hodne, dekuji
policko par milimetru
je jiste trochu prehnane, ale pro zadavani jednoho , dvou znaku - to je bezne v podnikovych aplikacich napr. ruzne zktratky statu, meny, mernych jednotek ...
Ergonomie take znamena, ze se usetri misto a uzivatel ma na jeden pohled mhohem vice informaci.
To je částečně client / server paradigmatem. Protože data na straně serveru kontrolovat musíte.
Na tom neco je. Drive (pred webem) se to vetsinou nedelalo a ty aplikace taky desetileti fungovaly. Dnes se rika, ze si uzivatel otevre pres F12 vyvojove prostredi webu a muze udaje manipulovat i pote, co je client zkontroloval ... no ja nevim, kdyz se to udela pres webassembly, tak bych takoveho uzivatele chtel videt.
Tohle vyžaduje mít neproporcionální font ...
Ja jsem myslel, ze cifry jsou v kazdem fontu vsechny stejne velke ...?
pro zaškolené uživatele co je používali velmi často.
ano, prave na takove aplikace myslim. Klasicke 'rich-client' aplikace
Dnešní webové aplikace jsou pro dost jiné podmínky.
na jo, to je pravda, jestlize se ma aplikace pouzivat soucasne na mobilu a na 50" obrazovce tak to chapu, ze se musi udelat nekde nejaky kompromis. A ten vede k tomu, ze efektivita prace musi byt nutne suboptimalni. Me skutecne prekvapuje, ze to jeste nikoho nenapadlo a hlavne ze zakaznici neprotestujou.
Nekdy kolem roku 1988 jsem pro nemeckeho zakaznika predelavali stavajici aplikaci, ktera byla novell-dosovska na unix a u prejimky ten sef posadil k terminalu po rade zamestnance z nakupu a odbytu a nechal je editovat ty zakazky a objednavky a meril stopkama kolik potrebujou casu. Koukali jsme jak vrany a pan sef na sdelil, ze pozadavek pri zadani projektu byl, ze jiz pri zadavani dat musi byt uspora oproti predchozimu systemu minimalne 20% casu (coz nam nas management jaksi zapomnel sdelit). Nastesti jsme se do toho zadani vesli, jinak jsme mohli balit kufry.
To ze zakaznici dnes jsou asi spokojeni, kdyz aspon neco funguje je pro programatorske firmy asi OK, ale ja se presto citim nejak nesvuj. Ale chran buh, ze bych chtel delat revoluci.
-
Samotne HTML podporuje ciselne inputy vcetne validace. Vic kmentovat nebudu. Otevrte si libovolny webovy formular, kde se zadavaji cisla.
ja ale nechci neco zadavat do nejakeho weboveho formulare. Ja potrebuji knihovnu.
Otevrel jsem tedy jqueryui.com/datepicker a v uvedenem prikladu se po me chtelo zadani datumu.
Zadal jsem tedy '//////////////2345234523423////////456345634//////' a kdybych chtel, tak zadavam jeste ted, ale presto vsechno se mi nezda, ze to co zadavam vypada jako nejake smysluplne datum.
-
To je částečně client / server paradigmatem. Protože data na straně serveru kontrolovat musíte.
Na tom neco je. Drive (pred webem) se to vetsinou nedelalo a ty aplikace taky desetileti fungovaly. Dnes se rika, ze si uzivatel otevre pres F12 vyvojove prostredi webu a muze udaje manipulovat i pote, co je client zkontroloval ... no ja nevim, kdyz se to udela pres webassembly, tak bych takoveho uzivatele chtel videt.
Tak kontrolovat na servri je dobre hoci ten klient ide na server binarne cez tcp socket, nie len pri http. Inak je to security by obscurity, dnes je dostatok nastrojov pre analyzu toho co si medzi sebou klient a server vymienaju...
-
policko par milimetru
Ergonomie take znamena, ze se usetri misto a uzivatel ma na jeden pohled mhohem vice informaci.
Ne nutně, občas je to méně přehledné. A ne vždy je těch údajů tolik, aby se místem šetřit muselo. Prostě pokud to dává smysl, tak se použije malé políčko, ale ne vždy to smysl dává.
data na straně serveru kontrolovat musíte ... Na tom neco je. Drive (pred webem) se to vetsinou nedelalo a ty aplikace taky desetileti fungovaly.
Ano, na bezpečnost se dřív hodně kašlalo. Pak z toho byly telefonáty typu "A opravdu se váš syn jmenuje Pepa'; drop table users;?" :-D
Dnes se rika, ze si uzivatel otevre pres F12 vyvojove prostredi webu a muze udaje manipulovat i pote, co je client zkontroloval ... no ja nevim, kdyz se to udela pres webassembly, tak bych takoveho uzivatele chtel videt.
Útočník si hlavně může request komplet celý vytvořit a poslat sám, nic měnit nemusí.
Ja jsem myslel, ze cifry jsou v kazdem fontu vsechny stejne velke ...?
Jak se říká: "Myslet znamená houby vědět"
pro zaškolené uživatele co je používali velmi často.
ano, prave na takove aplikace myslim. Klasicke 'rich-client' aplikace
Pak ovšem nevím, proč řešíte běžné webové aplikace, které jsou určeny pro úplně jiné podmínky a podle toho vypadají. I webové aplikace pro zaškolené uživatele se dělají, ale k těm se samozřejmě běžně nedostanete, protože jsou interní.
na jo, to je pravda, jestlize se ma aplikace pouzivat soucasne na mobilu a na 50" obrazovce tak to chapu, ze se musi udelat nekde nejaky kompromis. A ten vede k tomu, ze efektivita prace musi byt nutne suboptimalni. Me skutecne prekvapuje, ze to jeste nikoho nenapadlo a hlavne ze zakaznici neprotestujou.
A proč by měli protestovat? Jistě by bylo možné optimalizovat aplikaci pro různá zařízení od mobilu po tu 50" obrazovku, ale vývoj by byl o dost nákladnější a to se jim prostě nevyplatí. Maximálně se občas dělá mobilní verze nebo webová a mobilní aplikace, kde je to fakt užitečné.
Nekdy kolem roku 1988 jsem pro nemeckeho zakaznika predelavali stavajici aplikaci, ktera byla novell-dosovska na unix a u prejimky ten sef posadil k terminalu po rade zamestnance z nakupu a odbytu a nechal je editovat ty zakazky a objednavky a meril stopkama kolik potrebujou casu.
To je další věc. V 80. letech se běžně zaměstnávaly armády makaků, kteří nedělali celý den nic jiného, než přepisovali věci z papíru do počítače. Tam byla samozřejmě efektivita zadávání naprosto kritická. Nicméně dneska se to už dělá jen výjimečně, buď se komunikuje elektronicky, nebo to nahradilo OCR.
Zadal jsem tedy '//////////////2345234523423////////456345634//////' a kdybych chtel, tak zadavam jeste ted, ale presto vsechno se mi nezda, ze to co zadavam vypada jako nejake smysluplne datum.
A proč byste něco takového zadával do datumu? Když by to byla aplikace, tak by vám po opuštění pole vynadala, že to není platné datum, takže cajk. Optimalizovat aplikaci, aby se při takovém nesmyslném vstupu chovala "co nejlépe" je zbytečná práce.
Mimochodem, právě dělám na jedné interní aplikaci, kde je rychlost zadání v nějakých UC kritická. Takže řešíme věci jako "A když sem kliknu se shiftem, tak bude ve zobrazeném dialogu aktivní druhé políčko a ne první, abych ho mohl rovnou přepsat a ušetřil stisknutí tabu." Ale vstupy čísel jsou normální inputy, do kterých mohou napsat cokoli, žádné filtrování, zarovnávání na desetinou tečku a podobné nesmysly, dokonce ani nejsou zarovnané doprava a uživatelé jsou s tím úplně v pohodě. Kdybych jim vysvětloval, že to tak podle nějaké socialistické normy musí být, asi by koukali, jestli jsem nespadl z Měsíce :D
-
To ze zakaznici dnes jsou asi spokojeni, kdyz aspon neco funguje je pro programatorske firmy asi OK, ale ja se presto citim nejak nesvuj. Ale chran buh, ze bych chtel delat revoluci.
No, dnesny zakaznici by vonkoncom neboli spokojny s aplikaciu nakodenou vo foxpro, beziacou na novelackom servri sprostredkovanej cez rconsole. Aspom ja som bol zvedsa znacne rozladeny. Hlavne ked som si to mohol porovnat s pracou na terminali od pdp11, alebo inymi aplikaciami ktore vtedy bezali pod dosom...
-
čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš
Ako, pre kalkulacky som mal vzdy slabost, ale taku na ktorej by sa cisla zadavali od jednotiek smero k vyssim radom(zprava do lava) som este nevidel, ani na kalkulacke s RPN. Mozete mi prezradit vyrobcu a model?
HP 12C (a cela tato rada) - asi vubec nejrozsirenejsi model kalkulacek na svete, to tak ma. Vyrabeno kontinualne od 1981.
-
čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš
Ako, pre kalkulacky som mal vzdy slabost, ale taku na ktorej by sa cisla zadavali od jednotiek smero k vyssim radom(zprava do lava) som este nevidel, ani na kalkulacke s RPN. Mozete mi prezradit vyrobcu a model?
HP 12C (a cela tato rada) - asi vubec nejrozsirenejsi model kalkulacek na svete, to tak ma. Vyrabeno kontinualne od 1981.
A pardon, vy jste se bavili ne o zarovnani cisel (slabsi starsi kalkulacky doprava, HPcka doleva) ale o tom, ze se zacina/nezacina nejvyssim radem. To urcite nikdo nevymyslel, aby se zadavalo od nejnizsiho radu, to mas pravdu :)
PS: me by asi zarovnani doprava na webu stvalo, protoze kliknu/TABnu se do policka a ocekavam, ze mi tam VLEVO zacne blikat kurzor. Pokud je az nekde hodne vpravo, asi si ho jen tak nevsimnu a budu zbytecne klikat vickrat. Navic mnoho cisel vlastne nejsou cisla pro vypocty (kde to ma smysl pro soucet "pod sebou"), ale proste jen identifikatory, takze tam je zarovnani burt (treba to cislo domu a tak).
-
čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš
Ako, pre kalkulacky som mal vzdy slabost, ale taku na ktorej by sa cisla zadavali od jednotiek smero k vyssim radom(zprava do lava) som este nevidel, ani na kalkulacke s RPN. Mozete mi prezradit vyrobcu a model?
HP 12C (a cela tato rada) - asi vubec nejrozsirenejsi model kalkulacek na svete, to tak ma. Vyrabeno kontinualne od 1981.
A pardon, vy jste se bavili ne o zarovnani cisel (slabsi starsi kalkulacky doprava, HPcka doleva) ale o tom, ze se zacina/nezacina nejvyssim radem. To urcite nikdo nevymyslel, aby se zadavalo od nejnizsiho radu, to mas pravdu :)
PS: me by asi zarovnani doprava na webu stvalo, protoze kliknu/TABnu se do policka a ocekavam, ze mi tam VLEVO zacne blikat kurzor. Pokud je az nekde hodne vpravo, asi si ho jen tak nevsimnu a budu zbytecne klikat vickrat. Navic mnoho cisel vlastne nejsou cisla pro vypocty (kde to ma smysl pro soucet "pod sebou"), ale proste jen identifikatory, takze tam je zarovnani burt (treba to cislo domu a tak).
Njn, ved som pisal hned v nasledujucom prispevku ze zrejme nepojde o smer zadavania ale o zarovnanie.
Ad ps: no, hlavne by to nebolo ergonomicke, cisla zarovnane vpravo, ostatne veci vlavo by ocnemu svalstvu moc neprospeli...