Wirtualny Parlament, Głosowania nad pracami Sejmu, zgłaszanie wirtualnych ustaw Opcje

[kwiatekx]

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ł.

[Comandeer]

@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 (IMG:style_emoticons/default/wink.gif) 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" (IMG:style_emoticons/default/tongue.gif) ).

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ść (IMG:style_emoticons/default/wink.gif)

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 (IMG:style_emoticons/default/wink.gif) ). 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).