Sam używam Fireworks od bardzo dawna – od prototypowania interfejsów po projektowanie stron i mimo wielu prób oraz usilnych starań Adobe by zniechęcić – głównie użytkowników Maków – do programu, wciąż nie znalazłem wygodniejszej alternatywy dla tego programu.

Za możliwość podyskutowania dziękujemy Grześkowi Wolańskiemu – mam nadzieję, że starczy mu zapału do rozkręcania tego. Zapraszam.

Powiązane wpisy:

1. To smutny dzień. Adobe + Macromedia
2. By popular demand – I’m back.
3. Macromedia Studio 8 – wydane!

Brak podobnych wpisów.

W przeciwieństwie do projektów internetowych – z perspektywy czasu, to i tak nie ma znaczenia. Bo zabawa na pewno będzie przednia.

Powiązane wpisy:

1. Pięć rzeczy, których na pewno byście nie chcieli wiedzieć
2. …
3. Co dalej? Dokąd iść, gdzie się zwrócić?

Rozumiem myślenie życzeniowe ale z tego, co napisano na blogu Google wynika, że Google Chrome OS nie jest systemem operacyjnym, który ma na celu zagrozić pozycji Windows. Przynajmniej nie globalnie.

Czym Google Chrome OS jest/może być?

Jak możemy wyczytać, system od Google jest zbudowany z myślą o przeglądarce Chrome i przeznaczony przede wszystkim do netbooków. Ma działać na procesorach z serii x86 oraz ARM co oznacza niemal nieograniczony dostęp do netbooków, notebooków i całej masy sprzętu, który ma – mniej lub bardziej – ograniczone zasoby. Google twierdzi, że również celują w silne desktopy ale to mnie jakoś nie przekonuje.

Google targetuje swój system na użytkowników, którzy spędzają bardzo dużo czasu w Sieci i nie lubią czekać na to, aż uruchomi im się system, przeglądarka czy program pocztowy. Z GCOS wszystkie aplikacje uruchamiają się błyskawicznie. A przynajmniej tak błyskawicznie na ile pozwala łącze internetowe. Bo co jest raczej jasne, to Google tworzy system pod swoje aplikacje.

GCOS to w takim razie, potencjalnie, doskonale wpasowany system, realizujący z góry określone zadanie – szybki dostęp do najpopularniejszych usług w Internecie: Google Apps, YouTube. Do tego pewnie Twitter i Facebook. System, który ma minimalne wymagania przez co – powinien – uruchamiać się błyskawicznie i zużywać jak najmniej zasobów komputera. Jako taki, na fali popularności netbooków i szerokiego dostępu do Internetu, może odnieść duży sukces i spokojnie powalczyć z Linuksem czy Windows na polu systemów dla netbooków/handheldów.

Czym Google Chrome OS (raczej) nie jest?

Z powyższego wynika, że Google Chrome OS nie jest systemem mogącym zagrozić Windows czy nawet Linuksowi – w Google na pewno zdają sobie sprawę z tego, że stworzenie “dużego” systemu operacyjnego to karkołomne i kosztowne zadanie. Tworząc system dla Netbooków (i innych urządzeń przenośnych) Google wbija się w małowymagającą niszę, w której może w szybkim tempie stać się numerem jeden. Poza tym, Google musi zdawać sobie sprawę z czysto “pijarowych” zagrożeń – porażka takiej firmy na rynku “tradycyjnych” systemów byłaby dużo głośniejsza niż setnej dystrybucji Linuksa, która ma rzucić wyzwanie Windows.

GCOS nie jest też zbawcą Linuksa – nie spodziewałbym się mnogości aplikacji skoro wszystko jest zbudowane wokoł Google Chrome. Cel jest jasny: stworzyć system, który ma najmniejsze możliwe wymagania, startuje najszybciej jak to tylko możliwe i zapewnia jedną rzecz: dostęp do wszystkich aplikacji internetowych (w domyśle: Google). Dlatego oczekiwanie, że wraz z GCOS do Linuksa uśmiechną się producenci gier czy innej “komercji” jest – co najwyżej – myśleniem życzeniowym.

GCOS także nie przedstawia – w tej chwili – większej wartości dla tradycyjnych użytkowników desktopów. Jak wnoszę, system nie będzie bogaty w aplikacje – te mają być dostępne głównie przez Internet, co dyskwalifikuje go jako system “domowy”. Z drugiej strony, zdaję sobie sprawę, że przeciętnemu użytkownikowi nie trzeba wiele: wystarczy przeglądarka (+ program do torrentów) i player filmów/muzyki.

Przez chwilę zastanawiałem się jeszcze nad tym, czy brak standardowych aplikacji do obsługi chociażby poczty, nie będzie stanowił problemu w sytuacji ograniczonego dostępu do Internetu. Ale nie, jest przecież Google Gears.

Jeśli faktycznie ten system będzie tak wyglądał jak się zapowiada: czapki z głów przed Google; tempo i kierunki rozwoju produktów tej firmy muszą wzbudzać uznanie nawet u takich firm jak Microsoft.

Powiązane wpisy:

1. Windows XP Live CD
2. Google
3. Google coraz aktywniejsze

Z mojej perspektywy to krok w dobrą stronę – XHTML2 choć początkowo wydawał się być bardziej poukładany, był wg mnie zbyt mocno oderwany od rzeczywistości. Od tego, że na co dzień HTML służy do budowania stron internetowych – o często bardzo zróżnicowanej treści.

Powiązane wpisy:

1. HTML5 – rzut oka (wprowadzenie)
2. Slashdot revisited
3. InterNerw Explorer – stary błąd w nowszym wydaniu

Ponieważ miałem ostatnio kilka serwisów, które trzeba było zoptymalizować, postanowiłem przypomnieć sobie technikę CSS Sprites opisaną przez Dave’a Shea na łamach AListApart. Jeśli ktoś jej nie zna – proponuję się zapoznać. To prosta technika, z korzeniami w świecie gier komputerowych, polegająca na łączeniu wielu plików w graficznych w jeden większy, łatwiejszy w zarządzaniu i zmniejszający ilość zapytań o elementy graficzne.

Niedawno przetestowałem to rozwiązanie w kilku serwisach, które aż prosiły się o optymalizację i trafiłem na ciekawe zachowanie. Ale po kolei. Zakładając, że nasz przeciętny Jan Kowalski, czyta artykuł na ALA po raz pierwszy, skorzysta z zapisu zaproponowanego w artykule:

#panel1b a:hover {
    background: transparent url(test-3.jpg)
    0 -200px no-repeat;}
  #panel2b a:hover {
    background: transparent url(test-3.jpg)
    -96px -200px no-repeat;}
  #panel3b a:hover {
    background: transparent url(test-3.jpg)
    -172px -200px no-repeat;}
  #panel4b a:hover {
    background: transparent url(test-3.jpg)
    -283px -200px no-repeat;}

Puryści i fanatycy optymalizacji już w tym momencie powinni (już możecie) złapać się za głowę. Ale to nie nieoptymalny zapis jest problemem; prawdziwy problem rodzi się, kiedy chcemy skorzystać z tego rozwiązania w serwisie, w którym nasz plik z “duszkami” ma ponad 350kb, przeciętny obiekt wycinany z pliku ma wymiary rzędu 250×160px a takich wycinanek mamy na jednej podstronie około dwudziestu.
W przeciwieństwie do demonstracyjnego pliczku (parę kb) załadowanie takiego potworka chwilę zajmuje i – jak się okazuje – wpływa na sposób budowania strony… w Firefoxie.

Chcieliście napisać: no jasne, że w Internet Explorerze? Właśnie nie. Ten – o dziwo – renderuje stronę tak, jak byśmy chcieli: po załadowaniu pliku, pojawiają się wszystkie elementy graficzne. Od razu. Ale nie w Firefoxie; Firefox wycina je po kawałku tak, jak by nic się nie zmieniło.

Ok, co jest źle z tym zapisem? Przede wszystkim: zupełnie zbędnie powtarza się ten sam kawałek kodu tylko po to, by zmienić jedną/dwie wartości. Deklarację tła i jego powtarzanie możemy przenieść w jedno miejsce tak, by później tylko deklarować co chcemy wyciąć z tego pliku. Poprawniejszy zapis, może wyglądać tak:

#panel1b, #panel2b, #panel3b, #panel4b {
background: url(test-3.jpg);
background-repeat: no-repeat;
}
panel1b {
background-position: 0 -200px;
}

…

I to jest rozwiązanie warte kilka sekund renderowania strony. Firefox nie lubi się z powtarzaniem całej deklaracji ładowanego tła – za każdym razem otwiera plik z grafiką, wycina i wkleja potrzebny fragment wydłużając cały proces w swoistą “nieskończoność”. W moim przypadku, zmieniając deklarację udało mi się zejść z 16-20s renderowania strony (wg YSlow) do 6.

Powiązane wpisy:

1. CSS, Opera i Firefox: Z kamerą wśród przeglądarek (wciąż je psuję)..

To, z czym kompletnie sobie nie radz,ą to zarządzanie informacją. To PR. Jest hype a grono milczy. Od razu przypomina mi się ten obrazek:

z xkcd

Powiązane wpisy:

1. Ogłoszenia parafialne, czyli grono Opery na grono.net
2. Rygorystyczna droga do doskonałości – dlaczego nie warto?
3. Kiedy pomysły umierają – dlaczego nie warto czekać?

Czytając, uświadmiamy sobie, że nadchodzi apokalipsa a Microsoft znów jest tym złym, który jeszcze śmie mówić, że tysiące stron w Internecie jest niekompatybilna z jego najnowszym produktem, kiedy to sam, przez lata, olewał standardy. Chciałoby się powiedzieć: standard. Chwytliwy tytuł jest, sensacja w treści jest, popularność leci, wierszówka też i wszystko dobrze. Ale wystarczy zajrzeć na stronę ZDNet na którą powołuje się autor artykułu, by zauważyć, że pozwolono sobie na pewne “semantyczne nadużycie”. W oryginale wspomina się bowiem o IE8 w trybie “standards-mode”, który łamie kompatybilność ze starszymi wersjami IE.

Jak wiemy, Microsoft chce nadgonić stracony czas i IE8 ma zawierać całą masę poprawek w sposobie renderowania stron zgodnych ze standardami, by w końcu przestać być utożsamianym z najbardziej problematyczną przeglądarką na rynku. Poprawienie setek błędów, które przez lata zostały uznane za standardowe zachowanie oznacza, że większość (jeśli nie wszystkie) haki na IE w IE8 przestaną działać co z kolei oznacza, że jeśli strona została źle zaprojektowana – prawdopodobnie rozpadnie się w mniej lub bardziej efektowny sposób.

Dlatego została opublikowana lista stron “niekompatybilnych”, którą można pobrać i zainstalować w IE. Jeśli zdecydujemy się na instalację i wejdziemy na “problematyczną stronę” – IE8 wyrenderuje ją w sposób zgodny z IE7.

Chcąc liczyć się na rynku przeglądarek, Microsoft musiał zdecydować się na lepszą obsługę standardów, nawet kosztem zerwania kompatybilności ze starszymi wydaniami IE.
Lista kompatybilności to dobry kompromis a dodatkowo także autorzy stron mogą powiedzieć – na przykład, za pomocą dyskusyjnego tagu X-UA-Compatibile – IE8, że nie mają czasu by odgruzowywać kod i usuwać haki, więc niech będzie tak miły i grzecznie pokaże stronę jak IE7.

Do całej sprawy odniesiono się także na oficjalnym blogu IE, podając “po prostu fakty” w notce: Just The Facts: Recap of Compatibility View, z której dowiemy się więcej na temat problemu, z perspektywy tych, którzy IE8 tworzą.

• Microsoft’s IE 8 incompatibility list: 2,400 major sites (and counting)
• Just The Facts: Recap of Compatibility View
• Microsoft: 2400 stron jest niekompatybilnych z najnowszym IE

Powiązane wpisy:

1. Internet Explorer 8 – nadgonić stracony czas
2. Błędne z-index w Internet Explorer 7
3. Quo Vadis Internet Explorer?

Jaki więc powinien być dobry beta tester?

Powinien być członkiem zespołu deweloperskiego

Niekoniecznie. Właściwie, w większości przypadków, lepiej kiedy nie bierze udziału w rozwoju aplikacji. Choć wydaje się, że powinno być inaczej, to autorzy aplikacji są zwykle najgorszymi beta testerami. Oni po prostu znają ją na wskroś i przeglądając aplikację, poruszają się po ściśle określonych ścieżkach – generują nadzwyczaj mało przypadkowych kliknięć. Jako autorzy, doskonale wiedzą gdzie należy kliknąć by osiągnąć właściwy wynik.

Powinien być techniczny

Niekoniecznie. Pogląd ten bierze się z tego, że osoba techniczna szybciej i jaśniej wytłumaczy problem niż nietechniczna. I owszem, często to prawda. Równie często osoba techniczna stosuje skróty myślowe bądź pomija błędy, które w jej ocenie są “oczywiste i na pewno koledzy już nad nimi pracują”. Użytkownicy Waszej aplikacji nie muszą (zwykle: nie są) techniczni.

Powinien być ciekawski

Oglądaliście Dexter’s Laboratory? Pamiętacie sceny z DeeDee, głupiutką siostrą Dextera, która niszczyła piękny sen Dextera tekstem “Oohh, what does this button do?”. Mniejsza o to, dlaczego przycisk autodestrukcji był zawsze niechroniony i ściagający wzrok – Wasze aplikacje są lepsze, ale również nie pozbawione takich przycisków. Wy wiecie czego nie klikać a wasz idealny betatester właśnie to kliknie. I o to tu chodzi.

Powinien mieć dużo czasu wolnego

Koniecznie. Nie macie czasu? Zapomnijcie o beta testowaniu czegokolwiek. Powszechny błąd to myślenie, że “mogę się przeklikać przez tą aplikację w 15 minut”. “Przeklikać się” przez aplikację może każdy z nas, z różnymi efektami – nie o to tu chodzi. “Przeklikanie” to dopiero początek – trzeba jeszcze przekazać tę informację do zespołu i zrobić to w zrozumiały sposób. Tu zwykle okazuje się, że ochoczy beta bester “z tłumu” nie ma na to czasu albo mu się nie chce: “przecież to widać”.

Powinien… dobrze pisać

To absolutna podstawa. 37signals w Getting Real; stwierdzają “Zatrudnij dobrze piszących (Hire good writers)” i mają rację.

Dobry beta tester pisze bardzo dużo i bardzo dobrze. Raport od dobrego betatestera jest zwięzły, rzeczowy i zawiera między innymi:

• informacje o środowisku w jakim testował,
• informacje o napotkanych problemach,
• ścieżkę “krok po kroku” co zostało kliknięte, jakiego efektu się spodziewał, jaki efekt otrzymał

Pracując jeszcze przy grach komputerowych, spotkałem się z poglądem osoby, która rekrutowała betatesterów, że wybiera tylko tych, którzy potrafią się dobrze komunikować. Mogą nie mieć doświadczenia, mogą być kompletnymi laikami w sprawach którymi przyjdzie im się bawić ale nie mają najmniejszego problemu w przekazywaniu informacji. Pamiętaj, że błąd w aplikacji, nad którą zespół pracował wiele dni jest już wystarczająco stresującą sytuacją – oszczędź im kolejnych stresów związanych z próbą zrozumienia twojego zgłoszenia.

Może być twoim przełożonym

Lepiej nie. W zespołach w których nie chce się zatrudniać testerów, rolę tę przejmują przełożeni. I zwykle, jest to początek końca. Nikt nie lubi błędów a już w szczególności nie lubią ich ludzie, którzy muszą się ładnie uśmiechać do klientów/zarządu. Jeśli więc przytrafi się wam błąd, możecie być pewni, że jego znaczenie zostanie wyolbrzymione a wasze umiejętności podważone. Drugim słabym punktem jest brak czasu. Feedback przyjdzie skrótowy, enigmatyczny i z poślizgiem. Albo z informacją, że błędy są “widoczne na pierwszy rzut oka”.

Podsumowując

Błędy zdarzają się wszędzie – nie widziałem jeszcze aplikacji, która byłaby ich pozbawiona. Przyczyn tego stanu rzeczy są setki: brak czasu, brak narzędzi, brak doświadczenia, złe założenia, zmiany koncepcji w trakcie trwania prac nad kodem i tak dalej. Serio, błędy były, są i będą. Możesz jednak uniknąć części problemów, zatrudniając dobrych beta testerów. Jeśli nie stać cię na nich – możesz nimi uczynić swoich użytkowników. Z oczywistych względów, zadziała to tylko w przypadku określonego typu aplikacji.

A jeśli chcesz zostać beta testerem albo chcesz wiedzieć więcej, jak najlepiej zgłaszać błędy, poczytaj – stary już – tekst: jak efektywnie zgłaszać błędy.

• Jak efektywnie zgłaszać błędy
• Uservoice.com – aplikacja do zgłaszania feedbacku, do osadzenia na stronie.

Powiązane wpisy:

1. [Opera] Beta 3
2. Chcesz zostać webdeveloperem?
3. Ścieżkami porażek: róbcie podobnie, my nie mamy czasu

Tłumaczenie z przygodami – tak mógłbym w skrócie je określić.

Na początku tłumaczyłem GR sam, później pomagał mi Kuba Filipowski, z którym mieliśmy nadzieję wpiąć tłumaczenia w traduko.info. Niestety, na drodze realizacji tego pomysłu stanęły problemy licencyjne – padło więc na Wiki.

Mediawiki to nienajlepsza platforma do tłumaczenia książek – wszystko ponad standardową edycję i składnię jest dość zawiłe. Poza tym, to armata na komara. Jednak sam wybór wiki był dobry – umożliwiło to wprowadzenie większej liczby ludzi do projektu tłumaczenia i kontrolę nad tym, co w tłumaczeniu się dzieje.

Bardzo dobrym pomysłem było przygotowanie słowniczka trudnych pojęć i próba narzucenia sobie wzajemnie pewnego standardu tłumaczenia. A było o czym dyskutować: czy zwracać się bezpośrednio do czytelnika, czy stosować formy grzecznościowe, czy zmieniać nazwy serwisów na te, które lepiej przemawiają do naszego czytelnika (ot, choćby Facebook > Nasza-klasa). Język angielski jest elastyczniejszy jeśli chodzi o pisanie o technologii. To, co mnie osobiście rozbrajało w niektórych esejach to pseudo-metaforyczne tłumaczenia problemów, które po angielsku są oczywiste i brzmią doskonale. Po przetłumaczeniu na polski – już nie bardzo, niestety. Wypadało zgodzić się z Wolterem: “Tłumaczenia są jak kobiety – piękne nie są wierne; wierne nie są piękne” i zachowując sens i kontekst, stworzyć dany fragment od początku.

Niezłym pomysłem było także dostosowanie się do zagadnień, które zostały zawarte w książce – np.: mając już relatywnie ponad połowę tłumaczenia, postanowiliśmy zacząć wrzucać gotowe fragmenty na stronę Getting Real. I może by to pomogło, gdyby nie pewne ale.

Pierwszym problemem był czas wolny. Właściwie każdy z nas, miał pewien limit czasu wolnego, który mógł przeznaczyć na tłumaczenie.
Drugim problemem była technologia, co jak się okazało, było naszym głównym problemem. Te dwa problemy nałożyły się w momencie, kiedy wiki z tłumaczeniem, trzymane na Dreamhost – padło. Odzyskiwanie danych zajęło długie… miesiące, w czasie których wszyscy się rozeszli, pozmieniali prace, pozakładali rodziny, stali się mikrocelebrytami. Ogólnie: żyli długo i szczęśliwie.

To, co udało się odzyskać z backupów, ustawiłem u siebie i – spędzając wolne wieczory i noce – uporządkowałem, podzieliłem na kategorie i dotłumaczyłem stracone fragmenty oraz te, które nie doczekały się tłumaczenia w ogóle.

W momencie kiedy piszę te słowa, stan tłumaczenia Getting Real to ponad 70 przetłumaczonych esejów, 60 oznaczonych jako wymagające korekty i 2 nieprzetłumaczone/przetłumaczone w połowie. Faktycznie wymagających korekty jest połowa, może nawet mniej – wrzucone są do jednego worka bo i tak trzeba przeczytać je raz jeszcze.

Teraz trzeba wszystkie eseje przejrzeć raz jeszcze, uspójnić, ewentualnie poprawić interpunkcję czy stylistykę. Może świeże spojrzenie umożliwi też znalezienie lepszych tłumaczeń fragmentów już przetłumaczonych.

Jeśli więc czujesz się na siłach by pomóc doprowadzić to nieszczęsne tłumaczenie do szczęśliwego końca – przyda się Twoja pomoc.

W szczególności mile widziane są osoby, które kiedyś już tłumaczyły z nami GR, a na które nie mam już namiarów.

Powiązane wpisy:

1. Polskie Getting Real coraz bliżej
2. Getting Real po polsku
3. Co dalej? Dokąd iść, gdzie się zwrócić?