Archiwum listy

Transkrypt

1 Archiwum listy Archiwum #1.2, Dokument objęty jest licencją Creative Commons ( Aby zapisać się na listę wypełnij formularz ze stron: Archiwum listy 1 Przydatne narzędzia... 1 Platformy mobilne... 2 Kliencie, czego masz prawo wymagać... 2 WAP i RSS... 4 Pseudo-dostępność... 5 CMS... 6 Java czy.net... 7 Jak argumentować wykonanie projektu przed wykonaniem grafiki... 8 Licencja Creative Commons... 9 Przydatne narzędzia W codziennej pracy każdy z nas używa różnego rodzaju oprogramowania wspomagającego testowanie serwisów, co polecacie? Ja używam od czasu do czasu: - Browsercam.com (poprawnosc renderowania strony) - shareware - Xenu (broken links) free - WebDeveloper (toolbar do FF) free - HTTrack Website Copier (wiadomo) free Ostatnio też bawiłem się opcją Visio pozwalającą zaczytać strukturę serwisu wprost z WWW do schematu w Visio. Prawie już udało mi się poprawnie skonfigurować program, aby wrzucał do schematu tylko to co potrzebne. Bohdan R. Rau pisze: Nie polegam na browsercam - w wielu przypadkach liczy się nie tylko poprawne renderowanie ale i późniejsze zachowanie stron. Wolę użyć rzeczywistych przeglądarek, czyli: Linux - FF 1.0.6, Opera 8.2, Opera 8.10, Konqueror Windows - FF 1.0.6, Opera 8.2, IE 6.0, sporadycznie JAWS 6.10 Z narzędzi dodatkowych (używanych nie od czasu do czasu a codziennie): Tidy - Nie muszę mówić :) Fangs - Emulator screenreadera, autor stara się o maksymalną zgodność Fangsa z JAWSem

2 Mozilla Accessibility Extension - Nie jest to narzędzie developerskie, natomiast w pewnych przypadkach może pokazać błędy w strukturze strony Vischeck Panel - Wtyczka do ImageJ i Photoshopa symulująca różne odmiany daltonizmu. Polecam szczególnie Fangs - pozwala na bardzo szybkie zorientowanie się w tym co człowiek w aktualnie stworzonym arcydziele skopał dokumentnie bez konieczności uruchamiania JAWSa. I tu uwaga: Strona czytelna pod Fangsem jest na 99% czytelna pod JAWSem Strona nieczytelna pod Fangsem może w pewnych warunkach być czytelna pod nowymi wersjami JAWSa. Wojciech Krawczyk pisze: DevToolBard (toolbar do IE), odpowiedniek WebDeveloper dla FF: 2d5e1db91038&displaylang=en Platformy mobilne Śledziłem ostatnio dyskusje na W3C dotyczące usability platfrom mobilnych. U nas nie ma może jeszcze dużo tego typu serwisów jednakże zastanawia mnie jaka koncepcja projektowania ostatecznie zwycięży. Z jednej strony mamy często wręcz rozpaczliwe próby uczynienia "zwykłych" stron dostępnymi dla urządzeń mobilnych z drugiej strony systemy serwujące wersje serwisu odpowiadające danej platformie. Ta druga opcja dziś oczywiście przeważa. Jednakże instynkt podpowiadałby raczej kierowanie się ku jednemu rozwiązaniu. Zresztą dopiero co skończył się czas serwisów "wersja dla NN, wersja dla IE" i chyba nikogo nie ciągnie do ponownego rozdwojenia jaźni :) Jak się na to zapatrujecie? Jest szansa na serwisy WWW dostępne i intuicyjne w obsłudze dla każdej z platform? Powiedzmy, że naszym minimum byłby nie telefon komórkowy ale np. Windows Mobile. Co o tym sądzicie? Tomek "tom-ash" Janiszewski pisze: Wystarczy rozdwojenie arkusza styli :) Skoro można pisać osobne arkusze dla drukarek to dlaczego nie pisać osobnych arkuszy pod handheldy? Na przykład lub są dostępne na wszystkim. Swoją drogą obecnie Opera ułatwia tworzenie stron pod swoją mobilną wersję przeglądarki, poprzez umożliwienie zmiany trybu wyświetlania. Wystarczy nacisnąć SHIFT+F11 i możemy oglądać wersję dla urządzeń przenośnych. Kliencie, czego masz prawo wymagać Tomek "tom-ash" Janiszewski pisze: 1. Masz prawo wymagać od webmastera czystego semantycznie XHTML. Czystego semantycznie oznacza, że wszystkie zastosowane w dokumencie znaczniki XHTML muszą być użyte zgodnie z przeznaczeniem. Pobieżnie można sprawdzić semantykę języka XHTML uzywając Validatora ze stron W3C.

3 2. Masz prawo wymagać, aby wygląd Twojej strony był oparty *tylko i wyłącznie na arkuszu styli CSS*. Poprawność arkusza styli względem semantyki języka można sprawdzić na stronie 3. Masz prawo wymagać, aby Twoja strona była poprawnie wyświetlana we wszystkich nowoczesnych przeglądarkach internetowych. Wykaz najpopularniejszych przeglądarek na polskim rynku możesz znaleźć pod adresem 4. Masz prawo wymagać, aby Twoja strona była dostępna dla wszystkich odbiorców. Pamiętaj, że na Twoją stronę wchodzą nie tylko w pełni sprawni użytkownicy Internet Explorer 6.0, ale także osoby niewidome, niedowidzące, z niedowładem kończyn itp. Nie możesz o nich zapominać, a lenistwo bądź niekompetencja Twojego webmastera nie mogą Ci przeszkodzić w udostępnieniu witryny całemu światu. Ciekawe informacje, które mogą stanowić pomoc dla osób stawiających pierwsze kroki w świecie dostępności i użytecznosci możecie znaleźć pod adresem Dostępność swoich stron możecie sprawdzić używając systemu Cynthia ( bądź WebXACT ( Pamiętaj jednak, ze żaden z tych testów nie daje Ci 100% pewności, iż Twój serwis jest wykonany poprawnie. Najlepiej przekonać się o jakości własnego serwisu samemu sprawdzając go w różnych warunkach, pod różnymi systemami i w różnych trybach przeglądania. Maciej Kostro pisze: Czego powinieneś wymagać? Prawdopodobnie wystarczyłby jeden punkt: powinniśmy wymagać myślenia! Jak do tej pory skupiliśmy się wyłącznie na standardach. I bardzo dobrze, bo jak mówi defincja, standard to "norma", "wzorzec". I w agencji reprezentującej pewien poziom standard powinien być standardem. Z Waszych wypowiedzi wynika, że standardy dotyczące użyteczności nie są jeszcze standardem (normą) - punkty od 1 do 4. Ale chciałbym zwrócić uwagę, że same standardy to jeszcze za mało. Standard jako taki powinien być przezroczysty. Jeżeli występuję jako klient agencji interaktywnej, mam prawo oczekiwać, że standardy są spełnione, a ja mogę skupić się na kwestiach istotnych dla serwisu jako całości (kreacja, nawigacja, content etc). Fetyszyzowanie standardów prowadzi często do sytuacji absurdalnych, nie pamiętam juz co to był za serwis - raczej niszowy ;) - ale zostałem powitany komunikatem mniej-więcej w tych słowach: niestety używasz IE, w związku z tym nie możesz zobaczyć lub zrobić czegoś tam, twoja przeglądarka nie spełnia standardów. Nie możemy obrażać się na rzeczywistość i musimy pamiętać o jeszcze innych standardach (czyli normie): ponad 73% przeglądarek to IE. Znakomita większość użytkowników internetu nie ma bladego pojęcia o tym co to jest standard W3C i po co to w ogóle jest (i lepiej, żeby tak zostało, bo przestaniemy być potrzebni!). A myślenie realizatorów projektu pomaga w stworzeniu serwisu, który nie absorbuje nas swoim serwisowym bytem, a służy wygodnemu podaniu treści. Więcej rozważań na ten temat popełniłem podczas przygotowywania serwisu przyjaznyserwis.pl.

4 WAP i RSS Marek Woźniak pisze: Moim zdaniem WAP swoje czasy świetności (raczej mizerne) ma już za sobą. Mam wrażenie że przyszłość to raczej dostęp do "dobrze zrobionych" serwisów internetowych przez urządzenia mobilne. Bardziej wierzę w optymalizacje serwisów internetowych. Zresztą jakieś 3 miesiące temu spolonizowaliśmy jako netpr.pl ciekawe narzędzie "Kieszonkowy Internet" przeglądarka internetowa + czytnik rssów na urządzenia mobilne. Przeglądarką działa w oparciu o serwer proxy... czyli wszytko co jest zaciągane przechodzi przez bramkę i to coś "przekształca" stronę internetowa w coś co jest widoczne z poziomu telefonu całkiem nieźle jakościowo. Krzysztof Safjanowsk pisze: Zgadzam się - WAP powinien odejść w niepamięć - twór chyba stworzony wyłącznie dla operatorów i utrzymania monopolistycznej pozycji z zakresu dostarczania informacji. Oczywiście, strony operatorów [eraomnix, ideawap] generują duży ruch - analogicznie do strony głównej Microsoftu, która to strona ustawiona jest standartowo w IE, rozumiecie analogię? A spróbujcoe własnym sumtem wypromować nowy serwis w technologii WAP, serwis którego nie znajdzie żadna wyszukiwarka internetowa, i skąd wziąć potencjonalnego odwiedzającego? Wyszukiwarki i katalogi sklasyfikowaly większość znanego nam internetu, dlaczego wiec odbierać możliwość poruszania się po nim właścicielom urządzeń mobilnych? A wystarczy xhtml i css przeznaczony dla urządzeń o małym ekranie. Użytkownikowi podoba się serwis www? Niech ma również możliwość korzystania z niego nie tylko przy użyciu komputera... Maciej Szymański pisze: To zależy, czy mówiąc WAP mamy na myśli język (WML) czy raczej sposób oglądania treści przez użytkownika (urządzenie przenośne - telefon, MDA, PDA etc.). Jeżeli w pierwszym, to faktycznie - jest to technologia zanikająca, chociaż pojawienie się telefonów wspierających WML 1.2. i wyświetlających kolorowe grafiki dużo pomogło. Za to rozwijająca się dynamicznie technologia xhtml jest stworzona do tworzenia serwisów dedykowanych dla urządzeń przenośnych. Trzeba tylko pamiętać o kilku zasadach tworząc takie serwisy (wyodrębniłem je po kilku latach pracy w tym temacie) 1. Telefon, to wciąż przede wszystkim telefon. Ma mały wyświetlacz, który mieści mało tekstu i grafiki. W związku z tym obecność każdego słowa i każdej grafiki musi być uzasadniona. A każdy tekst źródłowy należy obciąć nie o 25 %, jak robimy to w przypadku www, ale o 95 proc. 2. Nie istnieje coś takiego jak standardowy ekran telefonu. Nie istnieje tu wspólne dla wszystkich monitorów komputerowych rozdzielczości (np. 1024x768). Każdy producent telefonów ma kilka / kilkanaście wyświetlaczy w swojej ofercie, które różnią się rozdzielczością, wielkością plamki, liczbą kolorów, kontrastem. Grafika, tekst i kod, które dobrze wyglądają na jednym telefonie, nie dadzą się odczytać na innym. 3. Nawet pomimo faktu, że największe wyświetlacze telefonów (SE P910) mają zaledwie 210 px, a PDA standardowo 240 px (Ipaq) nie ma nic gorszego niż przewijanie w bok. Dlatego nie sprawdziła się przeglądarka Opera wbudowywana w telefon. Wypasiona aplikacja, która działa ekstra na WWW, ze względu na dużą liczbę funkcjonalności, nie sprawdzi się na WAPie - należy pozostawić tylko te funkcjonalności, które

5 są naprawdę niezbędne. 4. Dostosowanie, dostosowanie, dostosowanie - każde urządzenie mobilne (a przynajmniej te, z których korzystają nasi klienci) powinien dostać najlepszą treść i najlepszy wygląd, jaki może przyjąć. I tak mógłbym bez końca ;-), więc tu przerwę Aha. Jeszcze jedno. Potencjalnych WAPnautów mamy w Polsce lekką ręką 2 razy więcej niż internautów - policzcie sobie liczbę użytkowników telefonów komórkowych i załóżcie, że 70 proc. z nich ma telefony z przeglądarkami WAP (a te będące na rynku od początku 2003 roku są naprawdę niezłe). Pseudo-dostępność Ostatnio jeden z naszych klientów otrzymał propozycję udźwiękowienia swojego serwisu przez Intelligent Web Reader. Polega to na stworzeniu wersji programu IWR, którą można pobrać z serwisu i która pozwal na bezwzrokową nawigację w danym serwisie. Serwis musi zostać wcześniej dostosowany do przeglądarki IWR. Szczerze mówiąc zirytowało mnie takie podejście i sprzedawanie tego typu rozwiązań jako zapewniających dostępność serwisu dla niepełnosprawnych.. Uważam, że tego typu podejście mija się z celem gdyż: 1. Użytkownicy niepełnosprawni mają już swoje oprogramowanie i nie będą chcieć uczyć się nowego ani tym bardziej instalować programu specjalnie po to by czytać kilka stron. Oprogramowanie typu JAWS czy WindowsEYES jest rozwijane od lat i jest standardem. 2. Takie działanie jest sprzeczne z wytycznymi W3C oraz dyrektywam eeurope - gdyż serwis nie jest dostępny, należy instalować dodatkowe oprogramowanie - zatem pojawie się też masa dodatkowych problemów (czy jest wersja programu na Linux, MAC OS, Pocet PC?) 3. Na całym świecie dąży się do spełniania standardów, nie wymyślania własnych. Tutaj mamy przykład lokalnego pseudo-standardu, który nie służy tak naprawdę nikomu. Na stronach znalazłem też wypowiedź pracownika Polskiego Związku Niewidomych na temat przeglądarki: "Jest to więc narzędzie zawodne, ponieważ nie pozwala na swobodne korzystanie z zasobów globalnej Sieci. Wiele do życzenia przeglądarka pozostawia także pod względem ergonomii obsługi, ponieważ uczy złych nawyków osoby niekorzystające ze specjalnych programów dla niewidomych, a niewidomi, którzy na co dzień pracują z takimi programami, muszą się przestawiać na inny sposób pracy. " Jacek Zadrożny, pracownik Polskiego Związku Niewidomych

6 CMS Myślę, że wszyscy tutaj obecni mamy sporo doświadczenia z rożnymi systemami CMS i ich funkcjonalnościami, które nam się spodobały. Ja chętnie podzielę się tym co mi się spodobało. wbudowany walidator zgodności dokumentu z WAI - cos takiego niedawno wprowadził RedDota, fajna sprawa bo można utrzymywać standard WAI juz po wdrożeniu, kiedy sprawy przejmuje w swoje ręce klient, możliwość nadawania każdemu dokumentowi dowolnej fizycznej nazwy, dobrze działa na wyszukiwarki, np. chcemy się pozycjonować pod "konikmorski" -> :) możliwość przerzucania dokumentu wprost na okienko wysiwyg metoda przeciągnij i upuść. a jakie funkcje Wam wydały się szczególnie interesujące? Marek Słowiński pisze: Wydaje mi się, że powinno się zacząć myśleć w CMS właśnie o dostępności. Większość dużych stron jest przecież oparta o CMS, a mało który oferuje takie funkcje jak definiowanie atrybutów związanych z dostępnością stron (tabindex, access keys). Walidacja jest ok, ale trzeba dać możliwość wprowadzania poprawek. Tak na marginesie, to mam wrażenie, że więcej się mówi o dostępności niż ją faktycznie stosuje. Często projekt i wygląd jest ważniejszy. Wcale to nie musi wynikać z fantazji klienta, tylko raczej z fantazji grafika/projektanta. Przykład - pomijanie podkreślenia w linkach. Niby nic, w kolorze wszystko ładnie wygląda, ale wersja b&w już nie musi być tak samo czytelna. Tak, tak wszyscy wiedzą, że link powinien być podkreślony, ale jednak świadomie to podkreślenie usuwają. Inny przykład - prawidłowa deklaracja DOCTYPE. Jej prawidłowe zdefiniowanie też nie wymaga dużej pracy - ale wystarczy popatrzeć w kod kilku renomowanych serwisów i co... Co do drugiej części wypowiedzi, nie zgodzę się. Uważam, że panuje na razie zbyt mała presja ze strony klientów na dostępność. Mało się o tym mówi jeszcze a uważam, że tylko presja klienta jest w stanie szybko i skutecznie zmusić webdesignerów do zwracania na to uwagę. Można zuważyć, że agencja interaktywna w Polsce kojarzy się raczej z cyfrowym butikiem kreatywnym niż z działającą według sprawdzonej metodyki firmą informatyczną. Oczywiście mistrzowskie firmy postrafią wypośrodkować i wtedy mamy prawdziwą agencją interaktywną :), jednakże większość zasłania słabe usability swoich interfejsów tym, że to "odważna kreacja".

7 Java czy.net Jan Blew i Sławomir Marcinkowski piszą: Obie są porównywalne. Różnica jest taka, że w USA zadają pytania raczej na zasadzie "Czy JAVA ma szansę stać się konkurencją dla.net'u.. ;) - zwłaszcza w firmach z młodszą kadrą.. Wadą.NETu jest to, że jest zamknięty - powstają niby jakieś alternatywne rozwiązania ale są daleko w tyle za wersją MS. Skalowalność.NET jest taka, jak w javie, ale w javie kosztuje o niebo mniej (...tyle co serwer lub jego utrzymanie;) ). Oczywiście można kupić np. Oracle Application Server, ale nie trzeba. Dużą skalowalną sieć można budować w oparciu o Apache'a i JBossa. W przypadku.net potrzebujemy już wszędzie W2K Advanced Server (zdaje się ok. 8K pln od licencji)....choć oczywiście gdyby sprawa była taka prosta, to MS już dawno by nie było...;) Generalnie - można argumentować i za jednym i za drugim - obydwie tezy mógłbym udowodnić z równą skutecznością ;).NET jest jak najbardziej konkurencją dla Javy. W Polsce nie powstają dedykowane serwisy w.netcie bo dotnet jest drogi - wymaga Windowsa 2k Server lub Advansed server (ten drugi to ok. 7k). Narzędzia deweloperskie są w cholernie drogie, taka subsykpcja MSN to jakieś 10k PLN rocznie (piszę z głowy - mogłem się mocno przestrzelić jeśli o aktualne cenniki). Ale.. zaletą jest co by nie powiedzieć SOLIDNE w wsparcie microsofta - bardzo dużo dokumentacji. Na polski rynek nie warto, na zachodni można. W przypadku polskiego rynku - warto tylko tam, gdzie trzeba robić bardzo ściśle dedykowane rozwiązania - ale np. nie uświadczymy raczej czegoś takiego jak: Dla klienta to z reguły obojętne... (poza kosztem - ale to trzeba wyliczać pod każde rozwiązanie oddzielnie). Dla developera, który zna jedno i drugie, Java daje większe możliwości bo jest zdecydowanie więcej bibliotek dla niej. Na zachodzie można, bo jak jest na projekt np. 100k EUR/USD to 5k-50k można wydać na licencje... Z naszego punktu widzenia.net (pomimo, że można pisać w bardzo wielu językach) jest za mało modułowy. Do.NETa nie ma takiego frameworka jak dla javy czy nawet php (smarty, struts, cocoon). Tak jak pisałem zawsze będzie 100 argumentów za i przeciw. Ale prosty przykład - kiedyś potrzebowaliśmy czegoś co będzie sobie radziło z czytaniem kodów paskowych. Do.Neta znaleźliśmy biblioteki po 2k USD, dobrze czytające zeskanowane i _wskazane_ na scanie kody. Ale do Javy wykorzystaliśmy bibliotekę, która po podrasowaniu potrafiła odnajdywać kody na zdjęciu (np. zdjęcie puszki na biurku)... i to chyba jest najlepszy przykład... Jeszcze z innych rzeczy - Java ma mechanizm JDO - czyli Java Data Objects, coś co pozwała łatwo i szybko rzutować obiekty do bazy danych i w drugą stronę. Dla.NETa nie znamy takiego rozwiązania (stabilnego!). Niby drobnostka, ale potrafi zaoszczędzić 75% czasu poświęconego na zapisywanie/odczytywanie np. koszyka produktów do bazy. Mimo to, i java i.net świetnie sobie radzą z bazami danych - ale to wynika z kolei bardziej z ich ustandaryzowania...

8 Z kolei jak wspomniałem siłą.net jest dokumentacja i świadomość zaplecza/wsparcia z którego można skorzystać (skoro się płaci za to). Mam również wrażenie, że Microsotf może być większym gwarantem bezpieczeństwa pewnych rozwiązań. Choć na razie jakoś specjalnie tego nie odczuwamy... Jak argumentować wykonanie projektu przed wykonaniem grafiki Wojciech Kuśmierek pisze: Nielsen podaje przykład, jak to dobranie złego nagłówka newsa w intranecie dużej ( osób) firmy spowodować stratę kilku tysięcy dolarów (Nielsen, Projektowanie Funkcjonalnych Serwisów Internetowych, str. 110). Trzeba iść tym tropem i wskazywać, że to się przekłada na pieniądze. Pomocne mogą być "slogany" w stylu: "lepiej, żeby użytkownik znalazł daną informację, niż żeby była ona ładna, ale jej nie znalazł" "jeśli użytkownik nie znajdzie danej informacji[w tym: opisu produktu], to tak, jakby jej nie było, pójdzie do konkurencji i kto inny na nim zarobi" "nieużyteczne strony denerwują ludzi, więc ci przestają ich używać" Do tego informacje o niewidomych, niepełnosprawnych itd. ale to (niestety) raczej będzie działać tylko na strony (samo)rządowe, bo ich obowiązują jakieś regulacje. Z resztą AFAIK Unia wprowadza jakieś ostre regulacje niedługo, może tu była jakaś mowa o tym. Natomiast smutna prawda jest taka, że użyteczność po prostu kosztuje czas i pieniądze. Dlatego pewnych (zwłaszcza mniejszych) projektów po prostu na to nie stać. I tu się chyba tego nie przeskoczy, ale jestem też ciekaw innych pomysłów na przekonujące uzasadnianie potrzeby uwzględniania użyteczności. Bohdan R. Rau pisze: Z tym się nie do końca zgodzę. Mały projekt o prostej strukturze zaprojektowanej od początku z myślą o użyteczności i dostępności będzie kosztował dokładnie tyle samo czasu/pieniędzy co ten sam projekt tworzony bez takich założeń. Dalej trzeba po prostu uważać aby nie zepsuć tego co było w założeniach. Przy dużych projektach oczywiście koszt wzrasta - ale chyba nie na tyle, aby było to barierą dla użyteczności?

9 Licencja Creative Commons Dokument objęty jest licencją Creative Commons ( Uznanie autorstwa-na tych samych warunkach 2.0 Polska Wolno: kopiować, rozpowszechniać, odtwarzać i wykonywać utwór tworzyć utwory zależne użytkować utwór w sposób komercyjny Na następujących warunkach: Uznanie autorstwa. Należy zamieścić informację o autorze utworu. Na tych samych warunkach. Jeśli zmienia się lub przekształca niniejszy utwór, lub tworzy inny na jego podstawie, można rozpowszechniać powstały w ten sposób nowy utwór tylko na podstawie takiej samej licencji. W celu ponownego użycia utworu lub rozpowszechniania utworu należy wyjaśnić innym warunki licencji, na której udostępnia się utwór. Każdy z tych warunków może zostać uchylony, jeśli uzyska się zezwolenie właściciela praw autorskich. Powyższe postanowienia w żaden sposób nie naruszają uprawnień wynikających z dozwolonego użytku ani żadnych innych praw. Ten tekst to przystępne podsumowanie Tekstu prawnego (pełna licencja).