Jak skutecznie promować stronę internetową?


30 listopada 2015 / Michał Kortas


Sposoby promocji własnej witryny w sieci są naprawdę różne. Jest to temat rozległy i nie mający jednoznacznie określonego końca. Warto jednak zatrzymać się przy nim choć na chwilę i rzucić okiem na pewne sprawdzone metody, które pozwolą zyskać potencjalnych gości. Chciałbym przedstawić Ci najlepsze, sprawdzone metody, patrząc na nie subiektywnie, dzięki którym będziesz w stanie zacząć zarabiać na swoim kawałku internetu.

Promowanie www

Czytaj dalej Jak skutecznie promować stronę internetową?


Tagi:


Prosty preloader CSS3 bez użycia Javascriptu


1 maja 2015 / Michał Kortas


Tworząc aplikacje przeglądarkowe powinniśmy zrobić wszystko, aby użytkownicy korzystający z nich czuli jak największy komfort. Powinno zależeć nam na dobrej optymalizacji skryptów, jak najmniejszej liczbie przeładowań strony oraz prostocie i intuicyjności interfejsu. Nawet jeżeli klient końcowy musi czekać, powinniśmy go o tym informować. Informacja, niezależnie od tego jaka jest, znacznie lepiej wpływa na wewnętrzny spokój aniżeli jej zupełny brak, okraszony białym ekranem przeglądarki obliczającej coś w tle. Z tego więc powodu pokażę Ci jak stworzyć prosty preloader, korzystający tylko i wyłącznie z możliwości CSS3. Do jego działania nie będzie więc potrzebna włączona obsługa Javascriptu, co jest naprawdę (uwierzcie) mile widziane.

Zobacz działanie preloadera na poniższym wideo.

Kod HTML loadera

  1. Utwórz kontener o klasie loader .
  2. Umieść w nim kilka niedużych ikon lub innych elementów (np. <div>). Ja użyłem do tego 6 identycznych sygnetów z loga WEBroad.pl

sygnets-webroad

Kod CSS loadera

Najpierw ostyluj kontener loader . Oczywiście pozostawiam Ci pełną dowolność. Ja akurat chciałem ustawić go w centrum ekranu z efektem cienia wewnętrznego.

Zajmijmy się teraz ikonkami preloadera. Pokażę Ci w jaki sposób wprawić je w ruch, tak aby spadały z góry, zatrzymywały się na chwilę na środku swojej drogi i w końcu chowały się za dolną krawędzią obszaru ograniczonego przez rodzica.

Stwórz nową animację w CSS3 o nazwie loader .

Jeżeli przypiszemy ją do każdej ikonki otrzymamy efekt spadania ale niestety w równej kolejności, co nie wygląda tak efektownie.

Dla urozmaicenia przygotowałem więc różne style dla co czwartego obiektu. Będzie je różnić tylko i wyłącznie opóźnienie wykonywania animacji. Dzięki temu najpierw „ruszy” ikona pierwsza i w ustalonych odstępach pozostałe.

Dostępność

// Akapit został dodany po dyskusji, która zrodziła się w komentarzach. Dziękuję za odzew.

Aby zapewnić dobrą dostępność powyższego rozwiązania, powinniśmy dodać do kontenera .loader  dodatkowe atrybuty:

[role] + [aria-labelledby]

Podsumowanie

Otrzymaliśmy ładny efekt preloadera, który możemy wdrożyć do naszych przyszłych i obecnych projektów. Zachęcam do modyfikacji i podzielenia się nią w komentarzach.

W powyższym przykładzie, dla zmniejszenia ilości kodu nie używałem w tworzeniu animacji przedrostków dla przeglądarek. Pamiętaj, aby je dodać w końcowym projekcie, jeżeli są potrzebne.

Zobacz DEMO


Tagi:


A co Ty zrobiłeś żeby zoptymalizować konwersję na swojej stronie?


14 listopada 2014 / Mr.Mr


Optymalizacja konwersji

Image courtesy of bplanet at FreeDigitalPhotos.net

Jak to nie wiesz co to konwersja? Dobrze. Zacznijmy od początku. Można powiedzieć, że konwersja następuje wtedy kiedy odwiedzający naszą stronę zachowuje się zgodnie z naszymi oczekiwaniami. Przykładowo zachowaniem użytkowników pożądanym z punktu widzenia właściciela sklepu internetowego będzie złożenie zamówienia, a z punktu widzenia organizacji charytatywnej złożenie dotacji wspomagającej działanie fundacji. Tak więc ostateczne cele mogą mieć rozmaity charakter, często zupełnie nie finansowy, ale w gruncie rzeczy chodzi o to samo – sprawianie by użytkownicy mogli wejść w interakcję ze stroną w określony sposób, zgodny z celami właścicieli witryny.

Czytaj dalej A co Ty zrobiłeś żeby zoptymalizować konwersję na swojej stronie?


Tagi:


Progressive Enhancement – zapomniany fundament


10 listopada 2014 / Comandeer


Progressive Enhancement - nieoficjalne logo

Każdy architekt, zapytany o tajemnicę perfekcyjnego domu, bez zająknięcia odpowie, że cała zasługa spływa na porządny fundament. O tej prastarej prawdzie nie mogą także zapomnieć dzisiejsi webmasterzy – architekci stron i aplikacji internetowych.

Warstwy stron (aplikacji) internetowych

Żeby wiedzieć jak zbudować dom, najpierw trzeba wiedzieć z czego się składa! Nie inaczej jest w wypadku stron internetowych. Tak, jak w domu mamy piętra, tak na stronie internetowej możemy wyróżnić poszczególne warstwy:

Wizualne przedstawienie warstw strony internetowej

  • treść
  • semantyka i metadane (HTML lub inny język spełniający jego funkcję)
  • prezentacja (najczęściej CSS)
  • zachowanie (najczęściej JS)

Każda kolejna warstwa nie może istnieć bez poprzedniej (tak, jak nie można zbudować 3. piętra, zapominając najpierw o parterze), lecz równocześnie każda jest całkowicie niezależna (wyobrażacie sobie, że wasz sąsiad z piętra wyżej musi codziennie przechodzić przez wasze mieszkanie?).

Przyjrzyjmy się teraz pokrótce każdej warstwie.

Treść

Treść to… treść. Jest niezbędnym elementem każdej strony internetowej (mimo że niektórzy zdają się twierdzić inaczej) i de facto nic bez niej nie może istnieć. To właśnie dla niej tworzysz stronę, bo chcesz coś ludziom przekazać. Jeśli natomiast tworzysz aplikację internetową, treścią staje się to, co jest w stanie stworzyć w niej użytkownik (zatem dajesz możliwość stworzenia treści, zamiast czegoś gotowego). Zapewne nic nowego nie odkrywam, pisząc te oczywiste oczywistości, lecz warto powiedzieć to głośno i wyraźnie: content is the king. I tyle ;)

Semantyka i metadane

W praktyce ta warstwa jest tak bardzo zrośnięta z treścią, że być może sensowniejsze byłoby traktowanie ich jako jedną, nierozłączną całość. Mimo wszytko, ze względów czysto „technicznych” (ok, za dużo ostatnio naczytałem się strukturalistów…) postanowiłem ją wydzielić.

Warto się bowiem zastanowić czemu warstwa semantyki i metadanych ma służyć. Jej rodowód wywodzi się z najbardziej podstawowych założeń Internetu, jako Sieci dokumentów połączonych wzajemnymi relacjami. Relacjami na tyle skomplikowanymi, że nie biegną w żaden linearny sposób, lecz mogą się rozgałęziać, przecinać, odsyłać do siebie samych, cofać użytkownika do już odwiedzonych stron czy po prostu zapędzając w kozi róg. Ot, magia hipertekstualności. Nie jest zaskoczeniem, że w tak skomplikowanej sieci wzajemnych powiązań sama treść nie wystarcza. Internet samego tekstu byłby całkowicie niestrawny, stąd potrzeba technicznego sposobu na dodatkowe oznaczenie tego, co w treści znaczy. I tutaj na scenę wkracza najczęściej HTML (lub XML, lub – w mniejszym stopniu – Markdown, BBCode itd.).

Pierwszymi odbiorcami, którzy mogą skorzystać z dobrodziejstw HTML-a, są oczywiście użytkownicy. Dzięki niemu możliwe są tak podstawowe czynności, jak przejście na inną podstronę czy wyświetlenie pewnych danych w seksownej tabelce. Jest to o tyle ważne, że najbardziej na dobrze oznaczonej semantycznie stronie skorzystają użytkownicy niepełnosprawni – głównie niewidomi i niedowidzący, korzystający z czytników ekranowych. Dla nich nawet tak podstawowe rzeczy, jak dodanie poprawnych [alt] do obrazków może diametralnie poprawić ich komfort korzystania ze strony. Dlatego, mimo powolnej agonii starego, dobrego semantycznego HTML-a, należy go stosować (bo raczej nie chcemy być zimnymi dupkami, którzy z góry skreślają niepełnosprawnych, czyż nie?) – nawet jeśli jest to zajęcie nudne i czasochłonne.

A jeśli ten argument nikogo już dzisiaj nie rusza, to warto też zwrócić uwagę na to, że semantykę serwowaną użytkownikom reużywają także wyszukiwarki, w tym de facto monopolistyczny Google. Zatem to, co jest dobre dla naszych użytkowników, zwykle jest także dobre dla Wujka G.

Oczywiście oprócz samej semantyki i dodatkowych metadanych, HTML zapewnia całkowicie podstawową funkcjonalność stron internetowych, jak np. prymitywne sposoby przesyłania danych na serwer (formularze!) czy właśnie legendarne dziś już linki. Zatem używając tylko i wyłącznie sam HTML, można przygotować sensowny fundament dla naszej strony.

Prezentacja

Obecnie każda strona internetowa musi wyglądać ładnie, żeby przyciągnąć internautów (wszak widzieli już wszystko, prawda?). W tym celu do naszej treści należy dołożyć dodatkowo jakiś ładny, efektowny (ale nie niepotrzebnie efekciarski) wygląd. Praktycznie w każdym wypadku osiąga się to przy pomocy języka CSS. Oczywiście jest on wspomagany przez całą gamę narzędzi i zasobów, takich jak preprocesory CSS, animacje, obrazki itp. Im bardziej użytkownicy stają się wymagający, tym bardziej CSS staje się skomplikowany, ale równocześnie pozwala tworzyć coraz ładniejsze strony internetowe.

Jeśli HTML określa to, co chcemy przekazać, to CSS określa jak chcemy to przekazać.

Zachowanie

Warstwa zachowania to ostatnia z warstw, leżąca nad zarówno treścią, jak i prezentacją. Najczęściej jest implementowana przy pomocy języka JavaScript (a mówiąc jeszcze dokładniej: przy pomocy API DOM, które jest udostępniane przez przeglądarki). Najprościej ją wyjaśnić na podstawie prostego przykładu: w HTML definiujemy przycisk przy pomocy znacznika button, w CSS określamy, że ma być okrągły i czerwony, w JS natomiast mówimy przeglądarce, że po kliknięciu w niego ma się wyświetlić komunikat o nękaniu naszej strony internetowej.

JS pozwala na dodanie całkowicie nowego poziomu interaktywności do naszej strony. Przyciski w końcu będą coś robić, dane się będą przesyłać w tle a filmik będzie miał super wypasiony odtwarzacz.

Progressive Enhancement – ale że co?

I właśnie tutaj, w miejscu, w którym zdefiniowaliśmy warstwy strony internetowej, trzeba powiedzieć o technice, która łączy je w jedną, spójną całość: Progressive Enhancement – owy legendarny fundament Sieci, o którym niestety bardzo często się zapomina. A jego zasady są bardzo proste i nietrudne do wprowadzenia w życie.

Niezależność warstw

Na stronie każda z warstw powinna być od innej całkowicie oddzielna: treść + semantyka nie powinna wiedzieć nic o prezentacji a prezentacja nie powinna nawet uświadamiać sobie istnienia warstwy zachowania. Ta wiedza w innych dziedzinach programowania (czy nawet wśród programistów stricte JS-owych) jest ogólnie znana i zawarto ją w haśle loose coupling.

O co chodzi? W skrócie chodzi o to, że każda warstwa istnieje tylko i wyłącznie dla samej siebie, wykonując ściśle określone zadanie. Semantyka ma być semantyką i nie wchodzić w paradę warstwie zachowania. JS powinien jedynie zmieniać stan elementów strony (np zaznaczać która pozycja w menu aplikacji jest aktywna), ale nie mieć zielonego pojęcia jak ta aktywna pozycja wygląda (w tym wypadku takie połączenie JS ze stroną często jest także określane bardziej precyzyjnym pojęciem, jakim jest unobtrusive JS). Każdy logicznie myślący człowiek zdaje sobie sprawę z tego, że co prawda można zmieszać różne gatunki alkoholu (a nawet wypić je na pusty żołądek!), jednak prawie zawsze kończy się to dla nas źle. Nie inaczej jest w przypadku tworzenia stron i aplikacji internetowych. Początkowo mieszanie JS i HTML czy HTML i CSS (a nawet JS i CSS!) nie gryzie. Ba, do pewnego momentu jest wręcz przyjemne! A później nadchodzi potrzeba wprowadzenia jakiejś zmiany i wychodzi na to, że wygląd naszego przycisku jest definiowany w 3 różnych miejscach (w arkuszu stylów rzecz jasna, ale także w HTML przy pomocy [style] i w JS, przy pomocy elem.style) – co zmusza nas do wykonania 3 razy większej pracy. Jeśli warstwy byłyby całkowicie rozdzielone od siebie, ten problem by nie istniał (po prostu wygląd byłby całkowicie ustalony przy pomocy arkusza stylów i tyle).

Technicznie rzecz biorąc sprowadza się to do porzucenia takich wynalazków, jak atrybuty [style] i niesławne [on] w HTML czy elem.style w JS. Oczywiście musi istnieć jakiś sensowny sposób na komunikację między poszczególnymi warstwami (w bloku po prostu otwieramy okno i krzyczymy do sąsiada z góry czy z dołu; no, chyba że znamy ich numer telefonu lub pukamy miotłą w sufit). W przypadku stron internetowych takim krzykiem (telefonem) są klasy. Zmyślnie ich używając, można stworzyć swoisty system komunikacji pomiędzy HTML ↔ CSS ↔ JS. Klasa, którą nadamy elementowi w HTML (np. .button-submit) przekazuje wiadomość dalej. W tym momencie CSS już wie, że ten przycisk należy pokolorować na zielono i dodać animację mrugania, żeby użytkownik się nim zainteresował a JS już do niego dodało żądanie Ajaksem. Oczywiście to komunikacja dwustronna (no, chyba że wszyscy nasi sąsiedzi są głuchoniemi), zatem JS może zmienić stan tego przycisku nadając/usuwając mu jakąś klasę (np .button-submit--disabled), co powiadomi CSS o tym, że w tej chwili należy zmienić kolor przycisku na czerwony. Najlepszym przykładem jak dobrze tego typu komunikacja może działać, jest architektura BEM.

Małe kroczki

Drugim koniecznym warunkiem PE jest to, czemu zawdzięcza swoją nazwę: wychodzenie od rzeczy najprostszych do najbardziej złożonych. Innymi słowy mówiąc: nie można nigdy zakładać, że warstwa wyższa od najniższej istnieje.

Tak, wiem, że teraz co bardziej rozgarnięty czytelnik popuka się w czoło i stwierdzi: „JS działa zawsze”. Owszem, JS działa zawsze, chyba że nie działa.

Wyobraźmy sobie stronę internetową jako obrazek. Treść + semantyka to właśnie nasze bezcenne płótno, które chcemy chronić. Dlatego nanosimy na nie warstwę bezbarwnego lakieru (prezentacji), żeby chronić i uwidocznić wszystkie jego kolory. Następnie, w celu maksymalnej ochrony, całość dodatkowo chronimy za szkłem pancernym (warstwa zachowania). Dopiero tak zabezpieczony obraz wieszamy w muzeum. Owszem, nic się nie stanie, gdy zdejmiemy zarówno szkło pancerne, jak i warstwę lakieru (o ile nasi zwiedzający nie zapragną podpalić płótna) – obraz będzie tak samo ładny i przyjemny w odbiorze. Problem pojawia się, gdy lakier wgryzie się w płótno lub dodatkowo szkło pancerne się do niego przyklei. I choć początkowo problem ten można całkowicie zignorować, to brak zdecydowanej reakcji doprowadzi do zniszczenia naszego bezcennego obrazu (czy kiedykolwiek próbowaliście oderwać warte miliardy dolarów średniowieczne płótno od szyby?!). Te warstwy ochronne mają za zadanie ułatwiać odbiór dzieła, bez jakiejkolwiek ingerencji w nie. Właśnie tak działa PE.

Jak powyższe statystyki pokazują, co prawda osób bez JS jest ciut ponad 1%, jednakże najciekawsze są przyczyny braku obsługi tego języka. Aż 0.9% to ludzie, których przeglądarki JS obsługują, lecz nie są w stanie uruchomić skryptów na tej konkretnej stronie. Przyczyn tego stanu rzeczy może być dużo – najczęstsze to bug w nowej wersji przeglądarki czy po prostu pad naszego serwera, który dosyła nam pliki JS. Tylko 0.2% osób świadomie wyłącza JS. Co to oznacza? Że każdy może nie mieć JS – nawet ty czy ja! I to nie z naszej winy. Bardzo łatwo wyobrazić sobie sytuację podróży pociągiem i przeglądania Internetu na smartphonie. Wystarczy, że w chwili otwierania mega wypasionej super hiper pro strony wjedziemy do tunelu i tym samym na chwilę zabraknie Sieci. I co? I nie mamy JS. Taka sama sytuacja może dotyczyć także CSS.

W tym artykule przytoczyłem już przykład całkowicie czytelnej strony, zbudowanej tylko i wyłącznie przy użyciu semantycznego HTML-a. Jak widać, dało się jej używać – mimo że nie była ani piękna, ani nie dociągała tony JS. Tak wyglądają normalne strony WWW, odarte ze wszystkich dodatków. Kiedy już zaserwujemy użytkownikowi to, co go najbardziej interesuje (treść!), możemy się pomartwić o to, by była piękna (prezentacja!) i aby dodatkowo była całkiem interaktywna (warstwa zachowania!). Tym sposobem przechodzimy od rzeczy najprostszych (ale i najważniejszych!) do rzeczy najbardziej skomplikowanych (których jedynym zadaniem jest poprawa UX strony): treść → prezentacja → warstwa zachowania. Dzięki takiemu podejściu do projektowania, naturalne staje się to, że chcemy coś przekazać a nie to jak chcemy to zrobić. To, co filozofowie wiedzą od stuleci, webmasterzy zdają się wciąż dopiero odkrywać.

Rozważmy prosty przykład funkcjonalności, do której można zastosować PE: wgrywanie avatara. Podstawową funkcjonalnością, jaką należy dostarczyć użytkownikowi jest… możliwość wgrania avatara. Nie trzeba tu jakoś specjalnie dużo kombinować – to jest po prostu zwykły formularz w HTML, z polem input[type=file].

Tyle – zrobiliśmy wgrywanie avatara. Mając tę całkowicie podstawową czynność, można zająć się jej udoskonalaniem. Dodajemy zatem do naszego przycisku wysyłania fajny styl z zaokrąglonymi rogami i gradientem przy pomocy CSS.

A już szczytem spełnienia dla naszego formularza jest to super fajne wysyłanie całości przez Ajaksa.

Voilla! Prosty formularz wysyłki avatara, który rozbudowaliśmy na wszystkich warstwach. W taki sam sposób można z powodzeniem tworzyć każdy element strony. Podstawową funkcjonalność zapewniamy w HTML, do tego dodajemy ładny wygląd w CSS i wszystkie wodotryski w JS. Tym sposobem stare przeglądarki i mobilne sprzęty ze słabym netem dostaną zwykły formularz a wypasione Chrome na wypasionych Macach mega upload Ajaksem. Każdemu według potrzeb i możliwości!

I to tyle?!

Tak, to tyle. Założenia PE są proste i nietrudne do spełnienia a są w stanie znacząco przyspieszyć proces tworzenia aplikacji internetowej oraz ją samą. Jest to na tyle pewny sposób tworzenia stron, że działa równie dobrze w przypadku zaawansowanych aplikacji internetowych. GMaila da się obsługiwać bez JS, czego doskonale dowodzi istniejąca wersja bez JS (którą Google pokazało jak bardzo nie zna PE i jak bardzo lubi dokładać se roboty ;)). Bardzo mało jest przykładów aplikacji, które nie są w stanie nic zrobić bez JS (Photoshop online? Zaawansowane komunikatory?), więc PE po prostu się opłaca. Lepiej coś użytkownikowi pokazać niźli odesłać go z kwitkiem.

PE jest znane od bardzo dawna, niemniej wciąż się o nim zapomina. Przeszło porządną ewolucję, wykształciło lepsze narzędzia i wciąż stanowi podstawę tworzenia Sieci przyjaznej wszystkim.

Bądźmy dobrymi architektami – nie zapominajmy o fundamentach!


Tagi:


Mobilna rewolucja w polskim (d)hostingu


20 października 2014 / Michał Kortas


Od dwóch lat mamy przyjemność współpracować z firmą dhosting.pl, która została naszym partnerem technologicznym. Od tamtej pory docenialiśmy ich główną, dobrą cechę, a mianowicie kontakt z klientem. Wzorowe podejście do swoich użytkowników zaowocowało tym, że dhosting.pl szturmem zaczął zdobywać coraz większą część rynku hostingowego, będąc dziś jego znacznym udziałowcem.

Z okazji swoich siódmych urodzin firma wprowadziła szereg ulepszeń w swoim autorskim dPanelu, z którego korzystają na co dzień setki administratorów stron internetowych. Kolejne modyfikacje i ulepszenia następują na bieżąco, i co najlepsze, każdy z Was ma możliwość kreowania kolejnych modyfikacji.

0001111

Co uległo zmianie? Można w skrócie powiedzieć, że wszystko, oprócz świetnej obsługi.

Wyobraźcie sobie, że Wasza witryna zaczęła rozsiewać spam lub została zawirusowana. Co w takim przypadku robicie? Odzyskujecie stronę z kopii zapasowej i wgrywacie ją na serwer, śpiesząc się jednocześnie, aby Wasz usługodawca nie zablokował Wam strony internetowej.

Dodatkowo, dzięki prostemu wykresowi „sites heart” oraz mechanizmowi powiadomień, jesteście na bieżąco informowani  w prosty sposób o wszystkich problemach, wygasających domenach (nie tylko w dhosting.pl, ale też u innych operatorów) i stanie swoich witryn. Firma dhosting, chyba jako jedyna w branży nie boi się informować swoich klientów w razie awarii lub innych nieprzewidzianych zdarzeń. To stawia ją w zupełnie innym świetle z perspektywy użytkownika. Informacja, nie ważna jaka by ona była, zawsze jest ważna. Każdy z nas lubi być informowany o wszystkim na bieżąco. Nawet jeżeli naprawa serwera poczty przedłuża się, dużo lepiej czujemy się, kiedy ktoś nam o tym powie – zabieg ten sprawia, że wiemy, że ktoś pracuje nad naszym problemem, a nie jest on zepchnięty w kąt i zapomniany.

Ale nie myślmy o awaryjności. Wiadomo, że w branży, jaką jest hosting, nie ma systemów idealnych, lecz system powiadomień powstał w dużej mierze po to, aby informować Was nie o awariach na serwerze (nie doświadczyłem tego od początku mojej przygody z dhosting), ale o problemach na „Waszym podwórku”. Jeśli na stronę, którą zarządzacie, zostanie wstrzyknięty złośliwy kod lub stanie się z nią inna, przykra sprawa, informacja dotrze do Was szybciej, niż sami zdążycie zorientować się w temacie.

Brzmi dobrze? Pewnie! Ale to tylko słowa. Spójrzcie na poniższe zrzuty ekranu. Tak w praktyce prezentują się wybrane powiadomienia.

dhosting

Nowatorskim podejściem, nie spotykanym dotąd u polskich dostawców hostingu, jest przygotowanie specjalnej aplikacji mobilnej. Od teraz nie musicie „gonić” do komputera, kiedy okaże się, że będąc w terenie potrzebna jest szybka zmiana w konfiguracji. Coraz więcej z nas korzysta głównie w smartfonów czy tabletów, więc takie rozwiązanie jest jak najbardziej na plus.

Na tę chwilę aplikacja dostępna jest na iOS i Androida, lecz w krótkim czasie pojawi się również też na smartfony z systemem Windows Phone!

Wiesz, że użytkownicy dhosting.pl mogą mieć realny wpływ na rozwój i funkcjonalność z której korzystają? W każdej chwili i Ty możesz podzielić się swoimi uwagami z dhosting.pl. W dPanelu znajduje się przygotowana specjalnie pod takie potrzeby wydzielona sekcja, w której złożyć możesz swoje pomysły.

Bardzo cieszymy się, że zachodzące zmiany są tak widoczne i rewolucyjne, konsultowane jednak z użytkownikami. Tu sprawdza się zasada, że klient powinien być zawsze stawiany na pierwszym miejscu i takie podejście zawsze wywołuje pozytywne odczucia.

Jakich doczekamy się kolejnych usprawnień? Ekipa dhosting.pl zapowiedziała, że będą na bieżąco informowali o kolejnych ważnych zmianach, które zamierzają wprowadzić dla swoich Klientów .

Moje wrażenia

Jako, że stroną zarządzam raczej „w biegu”, najbardziej ucieszyłem się z dostępu do panelu z wygodnej aplikacji mobilnej. Dużo prościej przychodzi mi też kontakt z helpdeskiem. Dotychczas korzystałem z webowego odpowiednika, co było dość niewygodne. Jeżeli mogę zrobić te same rzeczy z poziomu swojego tabletu czy smartfona, cieszę się niezmiernie. Niestety żyjemy w coraz to bardziej zabieganym społeczeństwie i każde przyśpieszenie wykonywanych czynności jest zawsze na plus.


Tagi:


Dokąd zmierza CSS?


19 października 2014 / Mr.Mr


dokąd zmierza cssIm więcej czytam o tym jak powinno się tworzyć kaskadowe arkusze stylów tym więcej myśle w bardziej ogólnych kategoriach o tym czym jest CSS i czym mógłby być. Nie da się ukryć, że CSS jest technologią prostą, pewnie zbyt prostą jak na współczesne potrzeby i dodatkowo zmienia się relatywnie wolno. Właściwie wszystko to co wymyślamy w kwestii różnorakich metodologii i technologii (np. preprocesorów) jest odpowiedzią na bolączki CSS i, mówiąc wprost, na jego braki. Jeśli się dobrze zastanowić to można z łatwością dojść do wniosku, że język arkuszy stylów nie przystaje do potrzeb współczesnego web design’u. Wiele osób może być tym zaskoczona bo przecież dzisiejsi deweloperzy tworzą rzeczy wręcz niewiarygodne, wielke serwisy internetowe i aplikacje o skomplikowanej strukturze front end’u to codzienność dla każdego użytkownika internetu, ale zapewne nikt nigdy nie zastanawiał się jak to wszystko powstaje i co jest używane do tego by takie serwisy mogły istnieć. Jeśli wziąć to wszystko pod uwagę od razu rodzi się pytanie: dokąd CSS powinien zmierzać?

Czytaj dalej Dokąd zmierza CSS?


Tagi:


Recenzja: Testy A/B. Od kliknięcia do klienta.


30 września 2014 / Aleksandra Seredyńska


testy-ab-recenzja-webroad„Kampanie reklamowe to nie lada obciążenie dla firmowego budżetu. W dodatku badania pokazują, że zaledwie 2% osób klikających reklamę i odwiedzających Twoją witrynę staje się Twoimi klientami. Łatwo z tego wyciągnąć smutny wniosek – aż 98% z nich nie skorzysta z Twoich usług! Zmień to! Poznaj sposoby na zwiększenie współczynnika konwersji!

Istnieją narzędzia, które pozwolą Ci polepszyć ten wskaźnik. Ta książka omawia jedną z najskuteczniejszych technik – testy A/B. Polegają one na prezentowaniu użytkownikom różnych wersji strony i mierzeniu, jak reagują ci użytkownicy. W trakcie lektury tego wyjątkowego poradnika dogłębnie poznasz tę metodykę i odkryjesz najlepsze sposoby jej wdrażania. A potem dowiesz się, jakie pułapki i problemy czekają na Ciebie oraz jak sobie z nimi poradzić. Książka ta jest poświęcona niełatwym zagadnieniom, jednak ta wiedza przekazywana jest w niezwykle przyjazny i prosty sposób. Popraw wyniki swoich kampanii!

Helion.pl

O czym jest książka?

Testy a/b to metoda badawcza, dzięki której możemy sprawdzać szeroko-pojęte preferencje użytkowników. Jest to metoda do zbierania danych, na podstawie których następnie możemy optymalizować swoją witrynę, newsletter czy reklamę pod naszą grupę docelową.

Książka podzielona jest na 3 części. Pierwsza z nich wprowadza w zagadnienie testów. Dowiemy się z niej czemu optymalizacja przy pomocy testów a/b jest taka istotna, co dzięki temu możemy zyskać i jak się do tego zabrać. To tutaj omówione jest tworzenie hipotez, celów i założeń testów. Jest to część, do której z pewnością często będzie się wracać by przypomnieć sobie kolejne kroki przy wdrażaniu nowego testu.

Druga część, mimo że jej tytuł brzmi Wdrożenie testów A/B: krok po kroku dotyczy nie tyle samych testów, a raczej wytworzenia kultury testowania w firmie oraz wyboru narzędzi i rozwiązań jeszcze przed stworzeniem pierwszego testu. Znajdziemy tu informacje jak przekonać pozostałych członków zespołu do tego, że testy są ważne, jak stworzyć zespół odpowiedzialny za testy oraz kiedy warto przeprowadzić kolejny test, a kiedy nie.

Trzecia część to zbiór bardziej zaawansowanych informacji o testach a/b jak np. testowanie newslettera czy tekstów oraz co zrobić by nie zgubić własnego brandu w toku kolejnych testów.

Jako dodatek autorzy stworzyli również zbiór przykładowych testów, które można dopasować do swojego projektu oraz całkiem sporą dawkę metodologicznych podstaw przeprowadzania testów a/b.

Temat

Zacznijmy od omówienia samego tematu książki – bo czy w ogóle warto sięgnąć po zagadnienie testów a/b? Jest mnóstwo książek, artykułów i badań na temat preferencji użytkowników, czy psychologii i zachowań e-konsumentów. Czy nie szybciej i taniej byłoby skorzystać z już wykonanych badań? Dodatkowo każdy zespół projektowy ma już pewne doświadczenie w projektowaniu skutecznych rozwiązań i zbiór zasad, którymi kieruje się w pracy.

Autorzy Testów A/B przekonują, że nie powinniśmy kierować się jedynie własnymi przekonaniami, ani badaniami statystycznymi wykonanymi na nie naszej grupie użytkowników. Wiele decyzji użytkownicy podejmują na etapie podświadomości, a często nawet kompletnie niezgodnie z własnym rozsądkiem. Coś na zasadzie „mówię jedno, a robię drugie”. Dodatkowy wpływ mają czynniki specyficzne dla danej grupy użytkowników (wykształcenie, wiek, zainteresowania, narodowość etc.). Dlatego by nasza witryna była skuteczniejsza warto kierować się danymi zebranymi na użytkownikach danego serwisu. Tu natomiast z pomocą mogą przyjść testy a/b.

Do kogo kierowana jest ta książka?

Jeśli jesteś developerem, który chce opracować narzędzie do testów a/b, analizy danych ze strony itd., nie jest to książka dla Ciebie. Autorzy kierują ją raczej do szefów działów marketingowych, ludzi odpowiedzialnych za analizę działań, specjalistów UX i ogólnie do osób, które mają za zadanie zwiększanie konwersji i skuteczności strony.

Czy warto sięgnąć po Testy A/B?

Książka jest niewątpliwie ciekawą pozycją dla każdego, kto chce poprawić wyniki swojej witryny, reklamy czy newslettera. Autorzy w sposób prosty opisują zalety testów a/b, podając przy tym szereg przykładów z życia znanych marek jak Amazon, Etsy i Barack Obama ;)

Trochę zawiódł mnie rozdział o narzędziach wykorzystywanych do testów. Zdecydowanie zbyt lakonicznie został poruszony temat zaplecza testów – czyli tego co dzieje się za czerwonym i zielonym przyciskiem . Po przeczytaniu tej książki, sama idea przeprowadzania testów jest mi znana, ale nim udałabym się do przełożonego by zachęcić go do przeprowadzenia badania tą metodą, musiałabym sporo czasu jeszcze spędzić szukając informacji o dostępnych narzędziach i ich możliwościach. Wiadomo też, że czekałaby mnie konfrontacja z działem produkcyjnym (graficy, front-endowcy i programiści), a tych bez konkretów nie da się przekonać ^^

Duży plus za to za wskaźniki marketingowe w dodatku. Mimo, że jak każdy, nie przepadam za statystyką, czy ekonometrią to przy tego typu badaniach już trzeba umieć wyciągać konkretne wnioski. Autorzy zamieścili podstawowe wzory dzięki którym menedżer produktu czy dział marketingu obliczą istotne dla siebie wskaźniki, jak np. przedział ufności.

Bez wątpienia przydatny jest też spis przykładowych testów. Samo przeczytanie tej listy daje już pewien obraz tego, co można zastosować w swoim projekcie.

Ogólnie oceniam książkę na plus – 8/10. Warto do niej sięgnąć nim ktoś porwie się na testy swojej witryny, by usystematyzować cele, założenia i sposób ich przeprowadzania. Trzeba być jednak świadomym, że nie będzie to wystarczające źródło by zostać specjalistą w tej kwestii i po tej lekturze może pojawić się sporo nowych pytań.

Kup książkę


Tagi:


index.jpg – życie webmastera w krzywym zwierciadle cz. 5 – A więc jesteś freelancerem…?


31 sierpnia 2014 / Mr.Mr


kobieta trzymająca napis zatrudnij mniePrzelewy do ZUS, telefony od klientów, umowy, papierki, kod, projekty graficzne, spotkania. To dużo rzeczy jak na jedną i tak już mocno zajętą głowę projektanta stron internetowych. Są jednak ludzie, którzy chcą podnieść rękawicę i samemu zmierzyć się z tym co przyniesie im los… Dzisiaj napiszemy trochę o freelancerach, wolnych strzelcach tej branży, którzy za dużo pracują i za mało zarabiają (standardowo;)… A może tak nie jest? Temat wydaje się ciekawy a zrodził się z prostego pytania, które kiedyś zadał mi znajomy – kim właściwie jest taki freelancer?

Czytaj dalej index.jpg – życie webmastera w krzywym zwierciadle cz. 5 – A więc jesteś freelancerem…?


Tagi:


Web Components – artykuł konkursowy


14 sierpnia 2014 / Comandeer


Web ComponentsWakacje! Słońce, wysoka temperatura, półnagie kobiety na plaży… Meh. To najlepszy czas, żeby zaszyć się w swojej jaskinii programisty i wyhodować jakiegoś kodowego potworka. BUHAHAHAHA!

A ci z nas, którzy nie cierpią na ostre postacie agorafobii, z chęcią lubią prezentować innym efekty swej syzyfowej pracy. Ja również należę do tych ekshibicjonistów, dlatego też postanowiłem pochwalić się ideą (ok, istnieje coś w wersji mocno prealpha, aczkolwiek używalnej ;)) rodzącą się w bólach w mym umyśle. Ale od początku!

Na początku było Słowo…

…a kilkaset milionów lat później inteligentny zlepek komórek stworzył coś, co buńczucznie nazwał HTML-em. Dzięki temu wynalazkowi dzisiaj możemy oglądać słodkie kotki! Jest on także sponsorem dzisiejszego artykułu.

Któż nie zna tego wręcz prymitywnego w swej budowie języka znaczników? Wszyscy mamy z nim do czynienia na co dzień – wszak to język, w którym do nas przemawia Sieć. Lecz czy kiedykolwiek zastanawialiście się jaka to magia kryje się za tymi niepozornymi <tagami>. Na pewno nie! No bo cóż w tym takiego magicznego?

A jeśli powiem, że w tym prostym języku tkwi niesamowity potencjał, który może odmienić oblicze Sieci, naszej Sieci? „Oszalał, chce powrotu XHTML 2!” – zakrzyknie co bardziej rozgarnięty czytelnik. Sam bym za takie myśli dał sobie w pysk jakieś 2 lata temu… Ale o tamtego czasu zmieniło się bardzo dużo, by nie powiedzieć: wszystko!

Declaratives, declaratives everywhere!

Declaratives, Declaratives Everywhere

Nie oszukujmy się: HTML nie powstał jako język dla zaawansowanych aplikacji. To język dla dokumentów – header nie ma nic wspólnego z titlebarem aplikacji a [data-action] nie są w stanie zastąpić sensownego data binding. Nic zatem dziwnego, że powstały całe potężne frameworki JS mające te braki naprawić: poczynając od standardowego, tradycyjnego i lekko trącego dziś myszką jQuery UI, przechodząc obok potężnego i nielubianego przeze mnie, przerośniętego ext.js na najnowszym dziecku Google, Angularze ze swoim sytemem modułów i nie do końca walidującym się HTML-em, kończąc. Żeby zrobić proste okienko z komunikatem (ok, w HTML 5 mamy dialog, który działa aż w Chrome 37+) ładujemy tonę JS-a, zamiast… umieścić odpowiedni kod HTML na stronie. Powiedzcie sami – czy nie ładniej zamiast

użyć po prostu:

Nie jest to jakiś nowy pomysł – w HTML de facto od zarania dziejów (tzn od powstania JS ;)) takie rzeczy istnieją. Najlepszym przykładem tego jest new Image, który równocześnie jest konstruktorem dla elementu img (a raczej – każdy tag img na stronie jest równocześnie obiektem Image w JS) czy też new Audio i tag audio. Oto mamy mały i poręczny element HTML, pod którym kryje się potężne JS-owe API. Jak bardzo jest to myślenie naturalne, wskazują dzieje Event Source API (aka Server Sent Events): jego pierwszą wersją był… tag eventsource, który nawet doczekał się implementacji w jednej z wersji Opery.

Ci, którzy znają XML, są całkowicie przyzwyczajeni do własnych tagów. W HTML jednak przez długie lata taka rzecz była niedostępna. Owszem, na upartego można było stworzyć sobie nowy tag, typu comandeertoboss, ale na tym nasze możliwości się kończyły. Nie było żadnego sensownego sposobu na stworzenie zależności, jak w parze new Imageimg. Co więcej, niektóre przeglądarki (tak, na ciebie patrzę, IE; na ciebie również, stary lisku) miały dziwne problemy ze stylowaniem tych elementów (IE potrzebował czegoś na kształt HTML5 shiv a lisek… serwowania jako XHTML). O problemach w DOM już nawet nie wspominam. Nie dało się i już. „Semantyczny” kod (tzn. taki, który po prostu dałoby się czytać) trzeba było osiągać na inne sposoby – tutaj ważne role pełniły (i wciąż pełnią!) mikroformaty oraz architektura BEM. XML-owy raj (gosh…) własnych znaczników był poza zasięgiem webdeveloperów. Do czasu…

Web Components are coming!

Choć aplikacje internetowe różnią się diametralnie od siebie (FB nijak się ma do Muro), pod maską tak naprawdę niewiele się różnią. Wszystkie stosują potężne frameworki JS do tworzenia interfejsów użytkownika. Takie rozwiązanie musi:

  • Udostępniać sensowny sposób tworzenia nowych elementów GUI
  • Posiadać system szablonów
  • Umożliwiać całkowitą enkapsulację (interfejs ma brać dane i tyle – co leży pod spodem, powinno być ukryte)
  • Być reużywalne (czyli można je zaimportować na każdej stronie WWW, która tego potrzebuje)
  • Posiadać system 2-way data binding lub posiadać sensowny sposób informowania o zmianach (system eventów/pub-sub)

Tylko patrząc na tą listę, każdy logicznie myślący człowiek widzi, że problemy te można rozwiązać na wiele różnych sposobów (stąd tak niesamowita liczba dostępnych frameworków JS). A jeśli powiem, że obecnie istnieje natywny mechanizm, który rozwiązuje te wszystkie problemy?

Uśmiechasz się ironicznie, prawda? Nie wierzysz mi a to już działa (tzn nie do końca, ale o tym później) i nazywa się „Web Components”. Jak sama nazwa wskazuje, składa się to z kilku elementów:

  • Custom elements – czyli sensowny sposób tworzenia nowych elementów GUI
  • Tag template – czyli sensowny system szablonów
  • Shadow DOM – czyli całkowita enkapsulacja
  • link[rel=import] – czyli całkowita reużywalność
  • Custom events – czyli sensowny sposób informowania o zmianach
  • Object.observe/DOM Mutation Observer – czyli 2-way data binding

Brzmi tak pięknie, że aż musi być haczyk, prawda? Otóż… jest, taki jak zawsze w naszym dobrym, starym webdevelopingu: kompatybilność, którą na bieżąco można sprawdzić na stronie Are We Componentized Yet?. Ale jak to zwykle bywa, istnieją polyfille. Najpopularniejsze to Polymer (którego używam i który jest o wiele bardziej rozbudowany i oprócz wspomnianych wyżej rzeczy dostajemy w prezencie Pointer Events; „minusem” jest brak wsparcia dla IE9-, ale patrząc na ranking.pl to wcale nie jest minus ;)) i X-Tags (mniej rozbudowany, skupiający się przede wszystkim na custom elements, ale za to dostajemy obsługę dla IE9+). Natywnie wszystkie te rzeczy, jak widać, działają sensownie jedynie w Chrome 36+ (no i w Operze ;)), natomiast Firefox zostaje ciut z tyłu; Safari i IE przemilczę.

Skoro już wiemy co i gdzie (nie) działa, przyjrzyjmy się bliżej wszystkim tym elementom po kolei (nie liczcie na duży tutorial – nie chce mi się ;) poza tym napisano już doskonałe – oczywiście po angielsku – do których linki podam na końcu; ten artykuł potraktujcie jako dobry overview całej technologii).

Custom elements

To najczęściej wykorzystywany element (pun intented) Web Components i ich znak rozpoznawczy. Bez tego elementu (pun not intented) cała reszta nie ma żadnego sensu. Zatem w skrócie: tak, możesz tworzyć własne elementy HTML!

I zanim polecisz tworzyć comandeertoboss, wiadro zimnej wody na ochłodę: to nie jest aż tak proste! Custom element wygląda bowiem ciut inaczej niż zwykły element:

Jak widać, nazwa składa się z dwóch części, przedzielonych myślnikiem. Ten myślnik jest konieczny. Dlaczego? Gdyż przeglądarka inaczej traktuje elementy bez niego i z nim. Bez myślnika przeglądarka po prostu uznaje to za nieznany, niepoprawny element… i na tym się kończy. Natomiast gdy w nazwie myślnik występuje, przeglądarka zaznacza sobie ten element jako „prawdopodobnie custom element”.

„Do rzeczy – my chcemy pełnoprawnego custom elementa!” – zakrzykną webdeveloperzy, nielegalnie czytający ten artykuł w pracy. A więc – żeby przeglądarka rozpoznawała nasz tag jako… nasz tag ;) należy użyć funkcji document.registerElement:

Pozwoliłem sobie zapisać wynik funkcji do globalnego konstruktora TagName (dzięki temu mamy swój własny new Image – yay!). Jak widać, document.registerElement bierze jako 2. paremetr obiekt opcji, a w nim – prototyp naszego elementu. Tutaj ważne jest to, żeby obiekt TagNamePrototype dziedziczył po HTMLElement (albo jego pochodnych). Drugą opcją, obok prototype, jest extends – dzięki temu można rozszerzać już istniejące elementy; używa się ich jednak ciut inaczej:

Bardziej doświadczeni czytelnicy na pewno od razu zapytają czemu jest bezsensowny myślnik, skoro można to było rozwiązać za pomocą XML namespaces? Otóż: XML jest martwy ;) XHTML się nigdy nie przyjął, zatem naturalnym ruchem było wykorzystanie o wiele prostszego sposobu i to kompatybilnego ze starym HTML (tzw. bożek Backwards Compatibility).

W Sieci można znaleźć pełno custom elements, od bezsensownych po całkiem użyteczne.

template

Każda większa aplikacja webowa korzysta z systemu szablonów – nic w tym dziwnego. Jeśli kilka różnych części GUI korzysta z tego samego rozwiązania, to można to wyrzucić do szablonu i jedynie podmieniać odpowiednie dane. Dotąd, z powodu ograniczeń JS, przeważająca część systemów szablonów client-side operowała na stringach. template przenosi szablony na poziom DOM. To tak naprawdę nic innego, jak osobne drzewko DOM na naszej stronie. Co więcej – całkowicie nieaktywne. Nie musimy się martwić o to, że obrazki doczytają się bez potrzeby – zawartość  template uaktywnia się dopiero po umieszczeniu wewnątrz strony. Do tego czasu wszystko w nim pozostaje nienaruszone. A jak szablonów używać?

Mogłoby być prostsze, ale i tak nie jest źle. A mamy za to natywny system szablonów!

Shadow DOM

Kto wie jak wygląda drzewko DOM dla elementu input? Pewnie większość z Was popuka się w czoło i stwierdzi, że zwariowałem – jakie drzewko? A to już Wam pokazuję jakie (wyciągnięte z Chrome):

Zszokowani? I właśnie o to chodzi! My, jako userzy, widzimy tylko efekt końcowy – pole formularza. Cała reszta siedzi pod spodem i jest obsługiwana przez przeglądarkę. Polecam spojrzeć jak bardzo złożony pod spodem jest np tag video (na pewno ma więcej kodu niż aplikacje niejednego z nas ;)). I to jest właśnie Shadow DOM – magiczny worek, ukrywający całą implementację pod ładnie wyglądającym tagiem. Do niedawna taką moc mieli jedynie twórcy przeglądarek. Jednak Shadow DOM zostało ustandaryzowane (prawie – to najczęściej zmieniająca się specyfikacja W3C ;)) i obecnie każdy z nas może tworzyć rzeczy podobne do pola input. Jak?

Tym sposobem stworzyliśmy akapit z niewidzialnym tekstem (sympatyczny kod? ;)) – nie ma go w źródle strony a inspektor elementów też niekoniecznie go pokazuje (dopóki nie zaznaczym odpowiedniej opcji w dev-tools). Oczywiście nic nie stoi na przeszkodzie, żeby włożyć tam coś bardziej skomplikowanego (Shadow DOM bardzo lubi tag template ;)) czy nawet… kolejne cieniste drzewko (because we always must be able to go deeper…).

Zalety? Całkowita enkapsulacja! Co więcej – Shadow DOM można podpiąć pod accessibility API (czyli czytniki ekranowe to widzą) i wykorzystywać na nim ARIA. Niemniej jest to sposób na rozdzielenie prezentacji naszego custom elementu od jego treści – treść podajemy normalnie w tagu (jak zawsze), natomiast cały sposób prezentacji zamykamy w Shadow DOM (a obsługa treści w Shadow DOM jest banalna, bo wystarczy w odpowiednim miejscu wstawić tag content). Proste i skuteczne.

Największa przewaga GUI w JS nad GUI w HTML? Możliwość importu tylko tych rzeczy, których potrzebujemy, w prosty, asynchroniczny i przyjemny sposób (patrz: AMD, CJS, UMD, ES6 Modules). W HTML takiej możliwości nie było… do niedawna. Od niedawna „moduły HTML” są jeszcze prostsze do wykorzystania niźli moduły JS (i mówi Wam to wielki fanatyk JS-a!). Wyobraźmy sobie, że stworzyliśmy super wypasiony custom element, z Shadow DOM, szablonami i całym potężnym API… I mamy problem: jak go załączać na wszystkich naszych stronach? 1. myśl – inline’ujemy – odpada w przedbiegach: 1000 linijek HTML-a to jednak nie to, co tygryski lubią najbardziej. 2. myśl – AJAX i wkładanie odpowiednich zasobów w odpowiednie miejsca. Działa a my mamy asynchroniczny lazy loading… Niemniej wymaga to ciut pracy i nie zawsze musi działać.

Zatem jesteśmy pokonani? Oczywiście, że nie! Z pomocą nadchodzi link[rel=import]! Pozwala on wydzielić z naszego kodu „moduł HTML” (zatem custom element oraz to wszystko, czego potrzebuje do działania) i dołączać go do wszystkich innych dokumentów (skoro nasze API przepisaliśmy na tag, to czemu nie mamy załączać go dzięki tagowi?). Wyobraźmy sobie kod naszego wypasionego custom elementu:

Po pewnym czasie może się to bardzo rozrosnąć… Dlatego wystarczy cały ten kod przerzucić do osobnego pliku .html i importować:

I tyle! Do całej zawartości zaimportowanego pliku dostaniemy się przez własność import owego link[rel=import] (tak, jak w przypadku template, tutaj również otrzymamy drzewko DOM). Tym prostym sposobem stworzyliśmy nasz 1. „moduł HTML”. Czekam z niecierpliwością kiedy Facebook i inne portale będą tak udostępniać swoje widgety.

Custom events

Każdy szanujący się custom element powinien rzucać jakieś zdarzenia. A czy jest jakiś lepszy sposób od użycia tutaj custom events?

Jak widać, można nadać zdarzeniu dowolną nazwę. Jedynym ograniczeniem jest to, że wszystkie dodatkowe dane zdarzenia są przekazywane jako event.detail. Niemniej jest to potężny DOM-owy element, pozwalający kontrolować działanie elementu (no przecież każdy z nas doskonale to wie! :D).

Object.observe/DOM Mutation Observer

Data binding w JS? Object.observe – służy do obserwowania zmian zachodzących w danym obiekcie JS i w chwili jakiejkolwiek zmiany, wykonuje daną czynność.

Coś pięknego prawda? Jeśli chodzi o same DOM, tutaj tę rolę pełni Mutation Observer, którego używanie już tak przyjemne nie jest, dlatego odeślę zainteresowanych do MDN ;)

Co prawda same te mechanizmy nie tworzą nam 2-way data binding out of box, ale wystarczy kilka minut, żeby takie rozwiązanie na ich podstawie przygotować. Jeśli chodzi o ES5 – tutaj można się ładnie pobawić przy pomocy getterów/setterów i eventów, by uzyskać podobne rozwiązanie.

Co dalej?

Jaki obecnie jest najlepszy sposób na tworzenie własnych custom elements? Użycie custom elementu polymer-element!

Chyba żartujesz?

Wszystkich zainteresowanych tym rozwiązaniem zapraszam do zapoznania się z projektem untitled-element, który jest bardzo ciekawym wrapperem dla polymer-element, generującym automatycznie dokumentację dla naszego custom elementu oraz używającym Bowera jako systemu rozprowadzania (Polymer stworzył niebotyczny ekosystem i de facto „czyste” custom elements są w zdecydowanej mniejszości).

Osobiście sam używam untitled-element, który jest podstawą mojego projektu dGUI (declarative GUI) – na razie są dwa nieskończone elementy, ale na dysku już mam zalążki kolejnych custom elementów, które w ostateczności złożą się na rozbudowane GUI aplikacji a’la desktopowej i nie tylko (node-webkit, yay!).

Większość devów oszalała na punkcie Web Components i nic dziwnego. Przepisano już połowę Sieci na nie: routery, asynchroniczne formularze, przycisk FB a nawet… console.log. Czy Web Components się przyjmą? Już to zrobiły. Czy ludzie je polubią? Już z nimi sypiają! Czy to dobrze? Tak i nie… Możliwości są bardzo duże, a wraz z nimi przyszła wielka odpowiedzialność (ale o niej to może innym razem!). Niemniej dobrze użyte WebComponents są przyszłością aplikacji webowych!

Linki i inspiracja:

Image courtesy of twobee at FreeDigitalPhotos.net


Tagi:


Jak uczyć się JavaScript? – książki, kursy i inne cuda…


10 sierpnia 2014 / Mr.Mr


logo języka JavaScriptBoom na uczenie się JavaScript nie mija. Cały czas co raz większe rzesze ludzi chcą wiedzieć jak działa ten język i jak używać go do budowania aplikacji internetowych (zresztą nie tylko internetowych). Sieć pełna jest rozmaitych zasobów, ale jak to zwykle bywa nie wszystkie są warte uwagi, inne są przeterminowane, a jeszcze inne np. niekompletne. Widać więc, że na szukającego wiedzy czycha wiele niebezpieczeństw. Ale nie bójcie się, jeśli dopiero zaczynacie Webroad.pl pomoże Wam znaleźć dokładnie to czego potrzebujecie!

Czytaj dalej Jak uczyć się JavaScript? – książki, kursy i inne cuda…


Tagi: