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

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

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