Witam.

Proszę o opinie na temat testowej wersji mojego serwisu - Wirtualny Parlament.

http://parlament24.pl

Serwis składa się z trzech części:
- ustawy rzeczywiste - ustawy nad którymi pracował sejm, nad nimi głosują użytkownicy po głosowaniu ustalana jest zgodność internautów z Sejmem
- ustawy wirtualne - pomysły internautów na ustawy, poddawane pod głosowanie użytkowników
- projekty ustaw - pomysły na ustawy, które gdzieś pojawiły się mediach - poddawane są pod głosowania internautów.

Każda ustawa posiada na bieżąco wyświetlane statystyki głosowań z podziałem na płeć, województwo, itp. Do każdej ustawy można dopisywać jej potencjalne wady i zalety oraz komentarze. Nad każdą ustawą głosujemy 7 albo 10 dni, po tym czasie głosowanie jest kończone i przedstawiane są wyniki głosowania.

Po zalogowaniu pojawia się "tablica" użytkownika, na której widać ustawy którymi jest użytkownik zainteresowany a w których inni użytkownicy dokonali jakiś czynności. Posiada również wygodny system powiadomień emailem - każdy użytkownik wybiera co ile mają być wysyłane emaile oraz co mają zawierać (nowe ustawy, itp).

Jest to wersja testowa, w związku z czym:
- część rzeczy jeszcze nie działa w 100%
- cała treść wpisana podczas testów zostanie usunięta
- wrzucona jest tylko jedna ustawa rzeczywista, po testach będzie ich więcej
- do poprawki jeszcze zostało: strona główna, dokładniejszy opis serwisu, responsywność (układ elementów)

Wykorzystana technologia:
- PHP + Code Igniter + kilka bibliotek
- jQuery, Bootstrap

Serwis rusza za około 7-10 dni w zależności od tego ile jeszcze rzeczy będę przerabiał.

Jako że się trochę polityką interesuję to jedno mi się nasuwa na myśl... po co. Po co marnujesz czas.

@tzm

Może chłopak uczy się php? Moim zdaniem dobrze, że coś zrobił, ale szkoda że w codeigniterze...

dla mnie mocno nieczytelne chodzi o wygląd

"Ta strona u�ywa" krzaków (popraw komunikat o cookies)

artykuł porneLa chyba nigdy nie stanie się nieaktualny https://pornel.net/onclick Jak powinno być zrobione głosowanie, to możesz se zobaczyć choćby u nospora http://pr0.nospor.pl/ → każdy wpis ma odpowiedni link do głosowania, na który nałożony jest Ajaks. Tym samym zagłosuję nawet mając 20-letniego Lynksa. U ciebie wystarczy, że zechcę zagłosować w nowej karcie i zonk. Ogólnie sporo masz rzeczy JS-only, które z powodzeniem powinny obejść się bez JS. IMO im bardziej myśli się RESTowo, tym oczywistsze się to staje.

http://parlament24.pl/fb/zaloguj szkoda, że jeszcze nie zaimplementowane

Przy rejestracji muszę wyrazić zgodę na przetwarzanie danych osobowych - rozumiem, że GIODO i te sprawy załatwione? No i gdzie SSL? Podaję Ci MOJE DANE - a Ty je tak traktujesz?
Jak to jest z tymi miastami - Raciechowice w małopolskim są, a Żarek Letnisko w śląskim nie ma… Nie lepiej zrobić z tego comboboxa?
Ten kalendarzyk strasznie niewygodny… co najmniej 4 kliki, żeby ustawić swoją datę urodzenia - zdążyłbym to ręcznie szybciej zrobić!

Standardowo



Cookie z danymi usera dostępne z poziomu JS - nieładnie.


Filtr anty-XSS jest, ale jakiś taki… niedorobiony

Jestem zalogowany, a w menu wciąż "Rejestracja" i "Zaloguj"

Jak często są uaktualniane statystyki usera? Bo zagłosowałem, wbijam na swój profil i echo - wciąż "Brak głosów". Ale już na liście głosowań mój głos jest.

Czemu praktycznie wszystko działa na koncie testowym oprócz… usuwania konta?

Dziękuję za opinie, odpowiadam hurtowo:


Nie uczę się PHP. Codeigniter wybrałem z wielu względów kilka lat temu do swoich projektów. Jak dla mnie jest prosty, czytelny, lekki i szybki. Nie potrzebuje używać do takich projektów Zenda czy Symfony. Poza tym w razie potrzeby osób trzecich jest to na tyle prosty i popularny FW, że wiele osób może pomóc. Ale to chyba nie jest istotą czemu Każdy wybiera to w czym mu się dobrze programuje.


Całość serwisu czy jakaś część?


Poprawiłem, dziękuję.


JS i jQuery jest wygodne i szybkie. Wiele zabezpieczeń związanych z podwójnymi głoswami jest po stronie PHP. Ale popatrzę na nospora i pomyślę jak u siebie usprawnić głosowanie.


W wersji produkcyjnej będzie SSL i strona będzie zgłoszona do GIODO. Rozumiem, że takie dane które są tutaj podawane są objęte ustawą i taka strona musi być w GIODO? Ktoś z Was ma jakieś doświadczenie w tym temacie?


Ta infomacja dotyczy zgodności głosowań z ustawami - zgodność ta jest liczona dopiero po tym jak ustawa zostanie już przegłosowana i będzie przyjęta albo odrzucona, ale poprawnie opis aby był czytelny.



Nie rozumiem trochę o co chodzi? W ciasteczku trzymam tylko informacje o sesji, zmienne sesyjne trzymane są w bazie danych.

Ale niekoniecznie JS musi działać. http://kryogenix.org/code/browser/everyonehasjs.html no i jeśli wszystko ma własny link, to może to działać bez JS

W ciachu jest m.in. id sesji i IP usera. Całość nie leci przez SSL, więc istnieje możliwość przechwycenia ciacha, a tym samym sesji. Słanie ciacha z flagami http-only + secure bardzo sprawę utrudniają

Strona bez szans na sukces. Jeśli nabrała by popularności głosowaniami manipulowały by sztaby od propagandy.

Jeśli chodzi o działanie to nie zauważyłem żadnej reakcji serwisu na kilkanaście prób błędnego logowania. Pozwalasz na brute force.
W rejestracji jako hasło mogę podać tak jeden znak jak i wsadzić całą biblię.

Brak strony 404

Sam wygląd trochę jak darmowy szablon.

Dzięki za wytłumaczenie. Znalazło się na liście do poprawek.




Dzięki za uwagę w sprawie logowania, dopisałem do listy poprawek. Strony 404 oczywiście będą.

tam gdzie Ty sie pojawiasz to ludzie uciekaja bo jestes upierdliwy i wydaje Ci sie, ze smieszny. Ale jestes w bledzie, odejdz i wracaj na swoj forumweb glupcze

@valkirek może jednak podyskutujemy merytorycznie? Jak na razie na tym forum głównie częstuje się mnie bez żadnej przyczyny atakami ad personam - brakuje argumentów do normalnej rozmowy?

@Comandeer Przytoczony link to też nie merytoryczna dyskdyskusja, a jedynie subiektywne zdanie autora. To, czy ktoś decyduje się na JS lub nie, jest zależne tylko i wyłącznie od rodzaju aplikacji i targetu. No i jeszcze od bardzo prostego przelicznika koszty/dochody. Nikt o zdrowych zmysłach nie będzie implementował fallback-u do no-js dla zasady. W zależności od projektu to mogą być tak wysokie koszty, że nikomu nie uda się tego ekonomicznie uzasadnić.

Niestety świat nie jest taki prosty i w realnych projektach wszystkie rozwiazania muszą być uzasadnione ekonomicznie.

@Xelah, nie zgodzę się, że jest to subiektywne zdanie autora, gdyż przeczą temu trzy rzeczy:

• wszystkie opisane tam rzeczy oparte są na obserwowalnych faktach związanych z działaniem przeglądarek. Z tego też powodu opisane tam problemy dotknąć mogą wszystkich aplikacji i stron internetowych. W przypadku stron internetowych problem jest o tyle mniejszy, że wszystko opiera się na linku, więc obsługa tego bez JS jest banalnie prosta
  
• zdanie to nie jest odosobnione i przykładów można przytoczyć bardzo dużo - choćby:
  
  • http://jakearchibald.com/2013/progressive-...ment-is-faster/
    
  • http://ponyfoo.com/articles/stop-breaking-the-web
    
  • http://www.paulirish.com/2009/avoiding-the-fouc-v3/
    
  • http://riddle.jogger.pl/2007/11/07/kto-nor...cza-javascript/ (tak, z 2007, ale problem wciąż jest aktualny!)
  
  Z tego też powodu stanowisko to zasługuje na nazwę stanowiska intersubiektywnego, a ze względu na to jakie osoby o tym mówią/piszą jestem w stanie wręcz zaryzykować stwierdzenie o tzw. best practice.
  
• zjawisko, o którym mówimy, jest możliwe do statystycznego zbadania https://gds.blog.gov.uk/2013/10/21/how-many...pt-enhancement/ → co prawda 1.1% nie jest liczbą powalającą, lecz w zależności od targetu daje do myślenia. Warto też zauważyć, że 0.9% osób nie ma JS, bo doszło do błędu serwera/przeglądarki. Osoby, które świadomie wyłączają JS robią to… świadomie i są innym targetem (polecam popytać np. redaktorów Niebezpiecznika ile u nich osób nie ma JS i dlaczego )

Owszem, w realnych projektach każda decyzja musi mieć ekonomiczne uzasadnienie, ale uzasadniać można jedynie to, co jest znane. A wiedza na temat zapewniania dostępności bez JS jest bardzo mała i w zastraszającym tempie zanika. Przyczynia się do tego moim zdaniem:

• niezrozumienie podstawowych założeń architektury REST. W niej główną rolę odgrywa duet URI + HTTP verb, więc ten rodzaj komunikacji nie zależy w żadnym stopniu od tego, w jaki sposób żądanie jest wykonywane. Stąd już prosta droga do tego, żeby stwierdzić, że zapewnienie obsługi bez JS sprowadza się do konstruowania normalnych linków (czyli takich, o jakich wieki temu pisał porneL)
  
• propagowanie złych wzorców przez wszelkiej maści frameworki JS. Tutaj idealnym przykładem jest Angular, który po prostu całkowicie rozmija się z ideami zarówno semantycznego HTML-a, jak i izomorficznych aplikacji internetowych. To po prostu toporny parser DOM, który dodatkowo zaburzył granicę między szablonem a widokiem (jednym, jak i drugim jest sama strona i jej DOM, dzięki czemu dostajemy ładny FOUC). Nikt nie zdaje się zauważać, że Angular powstał głównie dla aplikacji one-page (a i tam można go łatwo zastąpić choćby Taunusem) i przez to kończymy z prostymi stronkami informacyjnymi JS-only, bo przecież "w Angularze jest prościej". Ale zostawmy go - akurat jego shejcono już wystarczająco Ale Polymer niestety nie jest lepszy. Wielki boom na Web Components prowadzi do takich patologii, jak wytworzenie się trendu do klupania logiki w deklaratywny sposób - patrz: tag app-router. Tak, napisano router oparty na DOM. Dlaczego? Bo nikt nie kwapi się powiedzieć devom, że Web Components powstały jako sposób na stworzenie reaktywnych GUI, a nie przepisania logiki na HTML (co już samo w sobie brzmi jak brednia…). Tym sposobem w środowisku szerzy się de facto szkodliwą wiedzę. Nie wspominając już o tym, jak kiedyś do tego przyczynił się boom na jQuery.
  
• nikła wiedza na temat dostępności. "Bo klient za to nie płaci"… Cóż, jak dla mnie coś takiego wpisuje się w podstawowe wymagania dotyczące każdej strony internetowej. Ale niestety mało kto zwraca na taką rzecz jakąkolwiek uwagę, przez co nawet serwisy "użytku publicznego" leżą na tej linii po całości - http://centrumprasowe.pap.pl/cp/en/news/in...2-0-(komunikat)
  
• nikła wiedza na temat podziału aplikacji internetowej na warstwy (pozwalam se zalinkować do własnego artykułu, bo osobiście jeszcze nie znalazłem jakiegokolwiek szerszego opracowania tego tematu w polskiej Sieci; inna rzecz, że ten artek i tak takowym nie jest :|). Jak widać w komentarzach do artykułu, spowodowane jest to boomem na nowe, trendy frameworki i ich bezkrytyczną implementacją. Dodajmy do tego "genialne" pomysły Facebooka, jak zrobienie z Reacta wielkiej kobyły (wirtualny DOM to coś pięknego, ale po co od razu trzeba było dorobić do tego pseudo-E4X, uzależnienie od ES6, wkładanie CSS wprost do JS i całą filozofię Flux, która IMO bardzo przypomina wykastrowaną architekturę eventową?) czy właśnie mega parcie na Web Components, które - przynajmniej jako Polymer - zachęcają do pchania w kod bzdurnych [on-click] (co jest gorsze od tradycyjnego [onclick], bo DOM 0 jest od dawna optymalizowany przez przeglądarki, a atrybut stringowy pozostaje… atrybutem stringowym).
  
• nastawienie jedynie na zysk. Nie, nie jestem antykapitalistą (ale też kapitalistą również nie), ale skręca mnie jak ktoś rzuca tekstem "a po co mi semantyka? Ważne, że Google widzi". Genialny przykład stanowi content marketing - tworzenie treści, która ma reklamować… samą siebie. Cel == środek. Tym sposobem nic dziwnego, że produkty robi się jak najmniejszym kosztem. Może jestem anachronicznym idealistą, ale mnie po prostu nóż się otwiera w kieszeni…

Co do realnych projektów i uzasadnienia: jak komuś zechce się mimo wszystko zaglądnąć do podlinkowanych przeze mnie artków (i tak wiem, że nie zaglądniecie ), to zauważy jedną, ciekawą rzecz: PE wygląda na szybsze. Czemu? Bo podstawowa funkcjonalność jest udostępniana na poziomie samego HTML. Nie trzeba czekać wieczności na wczytanie wszystkich JS ze wszystkich CDN itd. Wczytał się formularz zamówienia → można zamawiać. Niepotrzebne mi do tego zarąbiste komunikaty jQuery o tym, że moje hasło ma 3 znaki za mało - to równie dobrze może mi powiedzieć prymitywna, acz działająca walidacja HTML5 oraz serwer. A jak się przy okazji doczyta bombastyczny skrypt jQuery, to fajnie - ładne, czerwone okienko przyda uroku całości

Za ekonomicznym uzasadnieniem no-js przemawia także fakt, że Google to robi. GMail wciąż oferuje archaiczny interfejs. Dlaczego? Bo część userów nie ma na tyle szybkiego neta, żeby wczytać jego ciężką wersję (tak, Plus LTE - na ciebie patrzę…). Część userów to także userzy korporacyjni, stojący za firewallami - a te lubią JS po prostu wycinać. Do wpisania zapytania w Google również nie trzeba JS. Dzięki temu mogę poszukać artykułu o lisiej behawiorystyce nawet z poziomu lynksa. Czemu? Bo taka funkcjonalność jest wbudowana bezpośrednio w każdą przeglądarkę i nie ma sensu wymyślać koła na nowo - po prostu. Tym samym, nie robiąc absolutnie nic, podbijamy target dla naszego produktu.

Jasne, są rzeczy JS only, ale one się już kierują całkowicie innymi prawami. Taki edytor graficzny w przeglądarce to już bardziej appka offline'owa, która z serwera co najwyżej dociągnie nowe ficzery albo zapisze obrazek. Tutaj nie ma sensu wciskać obsługi no-js, bo zarżnęlibyśmy serwer. Wystarczy poinformować usera, że potrzebuje JS, aby edytować obrazek na żywo. W tym wypadku to zrozumie. Ale wymaganie, żeby miał JS tylko po to, by na przykład napisać post na forum? IMO nieporozumienie…

I na koniec - no-js również musi być wykonane dobrze, a nie po łebkach, bo jedynie będzie strzałem w kolano. Polecam zobaczyć jak np. zachowuje się ibuk.pl, gdy wystąpi jakiś błąd w JS A jeszcze lepszym przykładem jest Social Club R*, gdzie nawet nie da rady zgłosić usterki, bo… wymaga to obsługi JS.

TL;DR no-js pociąga za sobą szereg kwestii związanych z architekturą aplikacji webowych, które nam pomogą nawet w projektach js-only i może mieć uzasadnienie ekonomiczne, dlatego i tak jest to wiedza obowiązkowa

@Comandeer

Po pierwsze chciałem odnieść się do tego 0.9%. To jest wynik z badania przeprowadzonego przez instytucję publiczną. Nawet sami w tym badani przyznają, że nie wiedzą jak to się ma do, na przykład, badań Yahoo! na ten sam temat. Bo i skąd mają wiedzieć? Strona GOV ma zupełnie inny taget niż Yahoo. Tak samo inny target ma ecommerce sprzedający numizmaty, akcesoria erotyczne czy forum dla fanatyków bezpieczeństwa.
Takie badanie trzeba przeprowadzić w swojej branży, żebu sprawidzć jak duża jest rzeczywista skala problemu. Rzecz w tym, że firmy bardzo często dobrze wiedzą o jaki odsetek ludzi chodzi, bo w dużych komercyjnych rozwiązaniach ludzie się skarżą kiedy coś ine działa. Dla przydładu podam ile skarg na problemy, mogące być pochodną opisanych w przytoczonym blogu, mamy w naszym sklepie (ponad 300k zamówień rocznie - można samemu wywnioskować o jaki ruch chodzi) - 0. Nigdy nikt tego problemu nie zgłosił. To wcale nie oznacza, że on nie istnieje. Na pewno istnieje. Tylko że jest marginalny. I inwestowanie ogromnych środków na przerabianie systemu, bo kilka osób będzie poszkodowanych? Jak uda się komuś przekonać CEO, CFO i CTO do takiego kroku, to nic tylko pogratulować

Jeśli chodzi o:


to bardzo chętnie zobaczę jak to w praktyce wygląda w ecommerce, gdzie produkt należy skonfigurować przed dodaniem do koszyka i jeszcze obsłużyć płatność kartą czy przez innego PayPal-a I to wszystko bez JS. Good luck!
Oczywiście, że koniec końców wszystko się sprowadza do request-u HTTP/S. Ale najpierw trzeba jakoś ustalić jak on ma wyglądać

W kwestii separacji CSS/HTML/JS nie będę się wypowiadał, bo to jest oczywista oczywistość i jeśli ktoś nie rozumie dla czego to jest "MUST HAVE" to powinien dokształcić się w temacie "separation of concerns" i popracować gdzieś, gdzie ludzie mają trochę więcej wiedzy niż to, co wyczytali z internetowych tutoriali i wynaleźli metodami chałupniczymi Dotyczy to zarówno fronend-u jaki bacend-u.

Takie rzeczy jak kolejność ładowania (HTML -> CSS -> JS na końcu) to też nie jest nowum dla fronend-owcó.

Jedyne, czego ja nie rozumim, to uporczywe wmawianie, że wszystko da się rozwiązać bez JS, i że JS powinien być tylko dodatkiem (opcjonalną warstwą) do już działającej strony. To może i jest dobre jak mam bloga, gdzie jedyna interackja to formularz logowania i dodawania komentarzy. Ale większość bardziej rozbudowanych aplikacji (w tym każdy ecommerce, który wymaga konfigurowania produktów i obsługi przeróżnych metod płatności) nie obejdzie się bez JS. Owszem, odpowiadnia separacja HTML, CSS i JS plus ładowanie ich w odpowiedniej kolejności ma niebagatelne znaczenie, ale brak obsługi core-owej funkcjonalności takich systemów niejstety bez JS obejść się nie może.

Niektóre z przytoczonych przez Ciebie artykułów są napisane w sposób bardzo personalny i bez jakiej kolwiek styczności z przeczywistością. Firmy robią badania, żeby sprawdzić, jakie przeglądarki należy obsługiwać i czy można sobie pozwolić na no-js czy nie. To, że domorosły "freelancer" nie ma o tym pojęcia bo u niego na najnowszym chromie i ośmio-rdzeniowym Xeon-ie działa, to jeszcze nie dowód na to, że każdy tak robi. Ja sobie nie przypominam, żeby firma czy klient nie robił rozeznania w tym temacie. Bo jak by na to nie patrzeć, od tego zależ powodzenie lub niepowodzenie całego przedsięwzięcia.

Co do ułatwień dla niepełnosprawnych to pewnie zabrzmi okrutnie, ale business is business. Spytaj szefa czy C*O jakiej kolwiek firmy o to, co jest głównym celem firmy. Każdy kto odpowie inaczej niż "zarabianie pieniędzy" mówi to, bo tak wypada Ale rzeczywistość jest brutalna.

Inaczej sprawa ma się w instytucjach publicznych. Tutaj nie ma biznesu i nie ma zmiłuj. Jak ignorowanie potencjalnych petentów to nie wynik strategi biznesowej a zwykłego niedbalstwa.

I koniec końców wszytko się sprowadza do rodzaju biznesu, wymagań funkcjonalnych i targetu. Takie uogólnianie po prostu nigdy nie zadziała.

Oczywiście w takim wypadku to nie ma sensu. Twierdzę jednakże, że warto pisać produkt od początku tak, żeby zminimalizować niezbędność JS. Najbardziej podstawowe funkcje bez JS de facto zawsze da się napisać bez niego.


Ale JS i tak najpewniej korzysta z normalnego formularza jako interfejsu - więc UX na pewno ucierpi bez JS, ale większość rzeczy dałoby się zastąpić. Nie wiem dokładnie o jakich dokładnie funkcjach mówisz, ale chętnie je poznam i podejmę wyzwanie napisania tego bez JS


Ale to IMO już nie ma nic do frontu To już jest dobre rozplanowanie API po stronie serwera.


Tego nie twierdzę. To już riddle w 2007 napisał prosto, że podstawowa funkcjonalność bez JS może się obejść bez żadnego problemu, ale jej bardziej skomplikowanej wersji bez niego nie da się już stworzyć. Podaje tam dobry przykład: wgrywanie avatara. Normalny formularz z polem [type=file] + w JS kadrowania i podgląd zdjęcia przed uploadem. Na pewno istnieją funkcjonalności, których bez JS nie ma sensu implementować, ale IMO są one w mniejszości.
Natomiast w ocenianej tutaj stronie wszystko można bez JS wykonać i to bardzo małym nakładem środków. Zwłaszcza, że system oceniania to tak naprawdę wykonanie najprostszego żądania HTTP - a to równie dobrze działać może bez JS.


Niestety to wpływa pośrednio na jakość Sieci, bo z biznesowego punktu widzenia niepełnosprawny jest tylko cyferką. Na ten problem zwróciło już dawno uwagę The Paciello Group: http://www.paciellogroup.com/blog/2015/02/...r-demand-issue/


Pewnie nie, bo - jak sam zauważyłeś, a ja z przykrością potaknąłem - business is business. Ale ja jestem perfekcjonistą i chciałbym, żeby Sieć zawsze była dla wszystkich. Może i będę kiedyś przez to przymierał głodem, może i przegram tę walkę z kretesem, ale przynajmniej będę miał poczucie spełnionego obowiązku
Poza tym - jest pewna różnica pomiędzy niestosowaniem no-js z bardzo dokładnym uzasadnieniem biznesowym i analizą kosztów, a niestosowaniem no-js, "bo nie" albo z powodu po prostu niewiedzy. Jak już mówiłem - niestosowanie czegoś trzeba umieć uzasadnić. Mogę się z takim uzasadnieniem nie zgodzić (i pewnie tak będzie ), ale przynajmniej widzę, że wiesz o co chodzi i czemu daną rzecz zrobiłeś w taki, a nie inny sposób.

Chciałbym, żeby Sieć nie była skażona biznesem i była dobrem ogólnym… No ale cóż.

Przy wskaźnikach konwersji rzędu 3% (średnia dla ecommerce) checsz powiedzieć, że to nie problem, że UX ucierpi? Ja się obawiam, że CR spadnie do 0% i całe przedsięwzięcie nie ma racji bytu



A ja chętnie zobaczę chociażby prototyp
To podam najprostszy przykład: Sprzedajemy buty. Mamy do wyboru kolor i rozmiar. Nie każdy rozmiar jest dostępny w danym kolorze i odwrotnie. Cena jest różna w zależności od wybranej konfiguracji i od ilości dodanej do koszyka. Niech będzie mega prosto
Oczywiście to muszą być formularze a nie link, bo jak wiadomo, request GET nie ma prawa zmienić stanu systemu.

To jest minimalnie skomplikowany konfigurator, który ma większość sklepów online (a sporo ma o niebo bardziej skomplikowane). Z ecommerce korzystało ponad 40% użytkowników sieci (tylko ci, którzy dokonali zakupu) więc pozwolę się nie zgodzić z z tym:

Czekam na ciekawe rozwiązanie, gdzie CR nie spadnie do 0




Też kiedyś tak myślałem i broniłem się rękami i nogami przed wszystkim co było dalekie od ideału. Po 5 latach freelancerki poszedłem do etatowej pracy. Przez ostatnie 3 lata pracuję w ecommerce i już dawno odpuściłem to idealistyczne podejście

@Xelah Twój przykład jest beznadziejny.
Rozwiązanie? Wchodzisz na stronę i masz wybór koloru. Wybierasz Kolor - klik. potem pokazują Ci się rozmiary - klik i masz cenę.
Minus? 3 razy przeładowujesz stronę. Bez JS da się, ale czy użytkownik chętnie będzie kupował jak mu się strona przeładowuje co klik? Nie sądzę.

@Pyton_000
No ale o to właśnie chodziło. To, że się technicznie da, to ja wiem. Ale cały dowcip polega na tym, żeby to zrobić bez uszczerbku na CR. To rozwiązanie spowoduje, że dla tego teoretycznego 0.9% CR spadnie powiedzmy do 0.1% (wariant bardzo optymistyczny) a firma będzie musiała zainwestować kupę kazy, żeby to w ogóle działało.

Tu nie chodzi o to, czy się da coś zrobić bez JS czy nie. Chodzi o to, żeby bez JS funkcjonalność była taka sama i i CR czy bounce rate nie spadały. A tutaj jest oczywieste, że to po prostu nie ma ekonomicznego uzasadnienia. Taka sztuka dla sztuki.

@Xelah mam wrażenie, że nie do końca się zrozumieliśmy… Nie jestem purystą tylko po to, by być purystą - aż tak mi nie odwaliło Twierdzę natomiast, że jeśli zacznie się projektować stronę w taki sposób, jak gdyby JS nie było, to bardzo łatwo można dojść do rozwiązań, które bez JS co prawda nie działają identycznie, ale użytkownikowi zapewniają podstawową funkcjonalność.

Twój przykład e-commerce: podstawowa funkcjonalność to możliwość kupienia i ona powinna działać bez JS. Gdy user tego JS-a nie ma, proces jest bardziej skomplikowany (np. walidacja danych zachodzi jedynie na serwerze, a sam formularz zamówienia nie jest rozłożony na etapy), ale możliwy. Jasne, jak chce se skomponować własny wzór na kafelkę w łazience, to należy mu grzecznie wytłumaczyć, że bez JS się nie da i najlepiej od razu dać mu krótki poradnik jak ten JS włączyć. Ale jak chce kupić ordynarną kafelkę ze standardowego zestawu, to raczej nic nie stoi na przeszkodzie, żeby mógł to zrobić. Wszak kupno jest głównie wysłaniem odpowiedniego żądania do serwera. W tym wypadku wysyłamy info o normalnej kafelce.

no-js dla samego no-js to sztuka dla sztuki. no-js jako fallback dla newralgicznych funkcjonalności systemu to best practice (nawet jest to opisane jako best practice w zbiorze JS-owych best practices dla projektów "where cost and schedule are key factors" ).

Co do Twojego przykładu: jedyny problem, jaki mam, to jak uzależnić cenę od ilości towaru w koszyku. Reszta jest bardzo prosta do zrobienia w samym CSS (gdyż duet HTML + CSS jest Turing complete, co ponoć udowodniono na tegorocznym FT ponad wszelką wątpliwość, odtwarzając bez JS-a interfejs GMaila). Proof of concept: http://bzdety.comandeer.pl/no-js.html
Tym sposobem wszystkie opcje mamy w HTML i obsługa ich w JS będzie równie przyjemna, jak obecnie przez CSS. No i najważniejsze: opcja no-js (czyli to, co tu jest) jest fallbackiem dla tych, którzy tego JS nie będą mieli. Wygląd poszczególnych elementów jest w pełni definiowany przez CSS, więc dla JS zostanie tylko dodanie przyjemnego zachowania do tego. Co do ceny - przelicznik dla ilości po stronie klienta wygodniej zrobić w JS. w tym wypadku przeliczy to serwer, a userowi musi wystarczyć informacja co ile i jak zmienia się cena (chociaż - jak się uprzeć i wykorzystać counters z CSS, to pewnie i cenę dałoby się liczyć!)

Co do CR - zdecydowaną większość z niego wypracowują klienci z włączonym JS, dlatego jeśli zadba się dodatkowo dla tych, którym JS nie dojdzie/wywali błąd to raczej może się tylko podnieść

Jeszcze raz powtórzę, żeby być dobrze zrozumianym: no-js dla samego no-js to sztuka dla sztuki. Natomiast zrobienie strony w taki sposób, żeby w razie błędu JS wciąż dało się na niej wykonać podstawowe czynności w niespartańskich warunkach w zależności od projektu może mieć ekonomiczne uzasadnienie (we własnych projektach nie widzę powodu, dla którego nie moglibyśmy sobie na tego typu rzeczy pozwolić - no chyba że ktoś jest właścicielem Allegro ). Nie piszę stron, które działają bez JS, "bo tak" - piszę je, żeby jak najwięcej osób mogło skorzystać z mojej strony. A dobre działanie bez JS to w 98% przypadków również dobre działanie z JS (tzw. minimal GUI - patrz: Zakas i jego eksperymenty; całość projektu jest w HTML + CSS, a JS dodaje jedynie lekką warstwę zachowania) i prawdopodobnie wyższe accessibility (o które mało kto dba z powodów ekonomicznych).

@Comandeer

Przyznaję, że czegoś takie się nie spodziewałem. Nawet nie wiedziałem, że to można w ten sposóbu rozwiązać. Pewnie dla tego, że moja specjalność to backend a nie frontend.
Ale uczciwie przyznaję - rozwiązanie wygląda interesująco i pewnie w wielu przypadkach może się sprawdzić.

Jedyne, co mnie martwi to jak przekonać management do zainwestowania w takie rozwiązanie. Jak robimy stricte pod JS to nie musimy w ogóle zastanawiać nad tym "a co, jak ktoś nie ma JS". Do tego dochodzi sporo innych ficzerów na stronie, które bez JS nie działają i trzeba jakoś zaplanować co będzie jak nie będzie JS. To wszystko są koszty i pytanie, czy dochody z no-js to pokryją... Trzeba by przeprowadzić jakieś A/B testy, żeby ocenić czy to ma ręce i nogi... Może jakiś ecommerce się tego podejmnie

No ale to już zagwozdka dla project managerów i zarządu firm U nas nie przejdzie, bo każdy produkt jest konfigurowany albo we Flash-u albo w JS-ie. Po prostu inaczej się nie da.

Jee... To już chyba gorsze niż no-js

IE wiecznie żywy Do końca roku zostanie tylko JS-owy konfigurator. Firma uznała, że trzeba poświęcić troche dochodów na jaiś czas. Problem w tym, że my bardzo intensywnie korzystamy z canvas i różnych nowych ficzerów, których w nie ma nawet w IE 8 czy 9 albo są nieprawidłowo obsługiwane. I dla tego ciągle mamy Flasha.
Ale to jest legacy, które pójdzie w niepamięć po uruchomieniu nowej platrofmy w ostatnim kwartale tego roku.

A VML? Nie wiem jak z wydajnością względem Flasha, ale canvas mogłoby zastąpić bez problemu… chyba że potrzebujecie do tego socketów to już większy problem

https://msdn.microsoft.com/en-us/library/hh...3(v=vs.85).aspx

Nie przejdzie. Myśleliśmy i SVG ale póki co skończyło się na kilku prostych konceptach, które powierdziły, że to nie takie proste. SVG w przeglądarkach jest strasznie prymitywny i póki co odłożyliśmy temat na bliżej nieokreśloną przyszłość. Ale pewnie temat keidyś wróci.
http://www.kartenmacherei.de/hochzeitseinl...ke.html?jessi=1

a potem klikamy na "Jetzt gestalten"

Żeby było wiadomo, o czym mówimy

Witam.

parlament24.pl - ruszył

Dziękuje wszystkim za przekazane wcześniej opinie.

Od czasu wersji testowej zmieniło się sporo, przede wszystkim:
- wyleciał pomysł zgłaszania "wirtualnych ustaw", od tej pory głosujemy tylko nad tym co pojawiło się w Sejmie, zostało odrzucone przed głosowaniem bądź pojawiła się jakaś informacja w mediach
- kosmetyczne zmiany serwisu
- pojawiło się opcja "do zagłosowania" po zalogowaniu - wyświetla się lista ustaw nad którymi użytkownik nie głosował
- dodany system tagów do ustaw
- integracja z Facebook
- i wiele wiele innych.
- dodałem na początek kilkanaście ustaw i projektów do przegłosowania przez użytkowników

Zapraszam

Konta testowe zostały usunięte.

Dzisiaj mi przyszedł mail z parlament24 i ze zdziwieniem stwierdziłem, że da się zalogować na konto, które stworzyłem do testów. Ba, opcja "usuń konto" dalej nie działa i wyświetla informację o blokadzie na koncie testowym…

Zdjąłem blokadę (była założona na wszystkie konta o nazwie test), a usuwałem tylko swoje konta testowe. Można już usunąć.

To po co piszesz że konta testowe zostały usunięte

Konta testowa, które ja założyłem usunąłem. Nie usuwałem kont założonych przez inne osoby, nawet jak miały wpisane test w nazwie. Jest opcja usuwania konta wraz z wszystkimi danymi, więc jak ktoś chce może sam usunąć, jak ktoś chce może nadal korzystać z konta. Stwierdziłem, że nie będę usuwał treści wrzuconych przez innych użytkowników.

Popracuj na szybkością, bo ładuję się dłuuugo..

Lepiej sam sprawdź czy Ci internet dobrze działa U mnie strona działa błyskawicznie.

Wczoraj był pad w serwerowni stąd były problemy ze stroną. Strona ładuje się szybko.