On Wed, 10 Nov 2010 12:42:22 +0100, Marek wrote:

> W dniu 2010-11-10 09:58, Michał Gancarski pisze:
>
>> Nadal nie wiemy czy to nie jest zabieg powstały po zasugerowaniu się
>> projektem grafika, a nie strukturą dokumentu. Bez treści ciężko ocenić.
>> Znajomość szerokości kolumn ułatwia rzecz.
>
> Zagadnienie jest dużo bardziej złożone. CMS generuje lub nie pewne
> fragmenty struktury i float:right jest optymalnym rozwiązaniem. Inaczej
> trzeba by pozycjonować elementy struktury za pomocą JS, a to jest chore.

Nadal tego nie jestem pewien :-) To znaczy nie wiem co to za CMS, co
generuje i co można w nim zmienić. Ale przyjmuję do wiadomości, że jest to
taki przypadek.


>> Inaczej mówiąc, dostajesz upośledzone user experience.
>
> Tak, i miliony innych osób. Liczba rośnie :-)

No rośnie, rośnie właśnie. Stąd coraz ważniejsze jest by te strony były
używalne, a nie renderowane jak na desktopie.


>> Wręcz przeciwnie. Oglądanie boiska przez lufcik nie jest niczym
>> interesującym, zarówno z punktu widzenia użytkownika jak i samego
>> właściciela strony, gdy najważniejsze linki zostaną schowane bo są trochę
>> za bardzo na prawo.
>
> Świata nie zmienisz. Póki co taka technologia zaczyna dominować. Gdy
> wyjdą ekrany holograficzne pewnie przełom nastąpi :-)

No wiesz, jako ludzie od stron akurat na to mamy kluczowy wpływ.
Ostatecznie to, że nawet na małych urządzeniach do dyspozycji dostajemy
nowoczesne przeglądarki ułatwia, a nie utrudnia pracę.


>> Ale nie jesteś jedynym użytkownikiem telefonu komórkowego. Ja, na ten
>> przykład, w ogóle nie korzystam ze stron, które zmuszają mnie do
>> przewijania poziomego. Całe doświadczenie z www na smarfonach uważam za
>> mocno upośledzone > właśnie dlatego, że dostaje się strony projektowane na
>> duże rozdzielczości, najczęściej bez żadnych prób ze strony autorów by temu
>> zaradzić.
>
> Tak zawsze będzie. Jeśli zleceniodawca nie widzi potrzeby tworzenia
> takich rozwiązań, to ja go nie zmuszę.

Nie trzeba zmuszać. Warto jednak zadać pytanie czy stać go na to, by jego
srona była bezużyteczna dla rosnącej rzeszy osób.


> Po drugie - internet w telefonie
> potrzebny jest w awaryjnych sytuacjach - gdy chcę sprawdzić kiedy pociąg
> odjeżdża bo zapomniałem.

To było dawno i nie prawda. Ja nie korzystam z internetu w komórce tylko
dlatego, że jest to mordęga z punktu widzenia użytkowego. Nawet będąc w
zasięgu sieci Wifi nie chce mi się uruchamiać przeglądarki bo wiem, że w
większości przypadków będzie to męczące doświadczenie. Z kolei znam ludzi,
którzy za normalne uważają ciągłe korzystanie z Twittera czy Facebooka
właśnie za pomocą komórki. Co więcej, jednym z szałów w aplikacjach
webowych ostatnich miesięcy jest geolokacja i usługi takie jak Foursquare,
czyli rzecz całkowicie oparta o małe urządzenia.


> Nawet z banku praktycznie nie korzystam w ten
> sposób choć ma interface dla komórek. Już nie wspomnę, że zdarzyło mi
> się na Allegro ceny sprawdzać - tam automatycznie w wersji "mobile"
> interface ładuje się. Wkurzam się szukając opcji jak to przestawić na
> normalny wygląd. Znajduję a potem dopiero zaczynam korzystać z Allegro.
> Takie mam obserwacje.

Ale sam sobie odpowiedziałeś na pytanie - nie korzystasz nie dlatego, że
"nie jest potrzebny", tylko dlatego, że jest to zazwyczaj przykre
doświadczenie, bo zbyt mało ludzi myśli jeszcze o małych urządzeniach.
Gdyby nie było przykre (i czasem ciągle za drogie), to byłoby zupełnie
inaczej, nagle stałoby się "potrzebne".


>> Nie sądzę by dziś istniało coś takiego jak "przeznaczenie mobilne".
>> Smartfon czy netbook to urządzenia, które ilościowo sprzedaą się znacznie
>> lepiej niż duży laptop czy desktop. Są też równoprawnym narzędziem do
>> korzystania z sieci. Strona po prostu istnieje albo i nie istnieje i
>> korzysta się z niej dobrze albo nie. To, że w ogóle jeszcze patrzymy na coś
>> takiego jak "przeznaczenie mobilne" (to także mój grzech), jest zwykłym
>> błędem.
>
> Eeeee... to to mnie zagiąłeś. Powyżej forsowałeś ideę konieczności
> tworzenia layoutu umożliwiającego prezentację na "prowizorycznych"
> przeglądarkach mobilnych.

Nigdy niczego takiego nie forsowałem. Kilkukrotnie zaznaczałem, że chodzi o
jak najbardziej nowoczesne przeglądarki w urządzeniach z małymi ekranami.


>> I mają "pełne" ekraniki? Nie sądzę. Ciągły wyścig po większe rozdzielczości
>> nic tu nie zmieni, bo telefon ma być telefonem i nawet gdyby cały składał
>> się z ekarnu, będzie mały.
>
> Ale CSS będzie interpretował coraz częściej o ile już to nie jest
> standardem.

Ej, mam wrażenie, że nie czytasz tego co piszę tylko odbierasz to co
chciałbyś, żebym napisał. Cały czas mówię, że chodzi o nowoczesne
przeglądarki.


> Strony będą w nim wyglądały normalnie a nie ogołocone z
> layoutu. Nawet niedawno nabyłem drukarkę (tak, drukarkę!), w której na
> małym wyświetlaczu jakieś strony można oglądać :-))))

Powtarzam - nie chodzi o "ogołocenie z layoutu" (zawsze istnieje jakiś
layout) tylko o to, by nie upośledzać serwisu każąc domyślać się
przeglądarce co ona powinna z nim w zasadzie zrobić. Bo albo wyświetli
rzecz w pełni (w końcu jest nowoczesna) i wtedy zazwyczaj oglądamy boisko
przez lufcik albo też zastosuje własne style na życzenie użytkownika i
wtedy jakakolwiek kontrola designera nad wyglądem się kończy.


>> To jest trochę niepełny przykład, bo jeśli niezależnie od layoutu w
>> dokumencie istnieją trzy logicznie oddzielne sekcje, to markup powinien
>> IMHO wyglądać tak:
>>
>> <div id="container">
>> <div id="section1">tu teksty</div>
>> <div id="section2">tu teksty</div>
>> <div id="section3">tu teksty</div>
>> </div>
>
> I to właśnie nazwałem sztywnym portalowym podejściem, gdzie musi być
> miejsce na bannery o ustalonych rozmiarach, nawigację, jakieś newsy i
> zawsze te sekcję tam będą.

Tzn. co tu jest "sztywnego"?


> DLatego to szczególny przypadek. Na co dzień
> takie projekty nie powstają. Każda firma chce mieć zupełnie inny layout.

Layout to nie to samo co struktura dokumentu. Layout powstaje gdy
przeglądarka dostaje instrukcje jak strukturę dokumentu przekształcić do
formy wizualnej, a nie z samej informacji o zagnieżdżeniu elementów. Stanem
idealnym byłaby możliwość kompletnej separacji jednego i drugiego. Stan
nieosiągalny ale można się próbować do niego zbliżyć i nie patrzeć na
strukturę dokumentu jak na layout. Elementy semantycznie neutralne jak DIV
czy SPAN są po prostu niezbędnym kompromisem. Ale niczym więcej.


> Nierzadko jakieś Flashe są stosowane: jedne wzdłuż, inne w pionie a
> jeszcze inne bardziej fikuśne. Kombinacji jest tak dużo, że taki layout
> jak w/w nie sprawdzi się zupełnie.

To nie jest layout. To jest struktura. Layout został zdeterminowany
dwukrotnie w sposób zupełnie odmienny, bez naruszenia samego dokumentu. O
ile nie da się na podstawie takiej struktury stworzyć dowolnego layoutu
(nigdy tak nie twierdziłem), o tyle da się ich skonstruować całkiem sporo.


> Projekt graficzny bardzo rzutuje na
> strukturę HTML'a przecież.

Raczej CSSa. Jeśli myślisz o dokumencie przez pryzmat designu to popełniasz
IMHO pierwszy błąd. Nie można tego wpływu całkowicie wyeliminować ale można
przynajmniej nie upośledzać dokumentu zamieniając kolejność elementów tak,
że sam dokument przestaje mieć sens. To ma znaczenie gdy np. podejmujesz
decyzję o tym czy element graficzny jest częścią treści czy tylko
ozdobnikiem. Jeśli jest ozdobnikiem, prawdopodobnie w samym HTMLu nie
powinien się, o ile to możliwe, pojawić. Skrajnym przypadkiem błędnego
podejścia w czasach tabel łupanych były jednopikselowe gify służące
formatowaniu. To niewiarygodne co człowiek wrzucał w kod gdy myślał tylko o
wyglądzie.


> Najbardziej banalna komplikacja:
>
> <div id="container">
> <div id="section1">tu teksty</div>
> <div id="containterDlaJakiegosTlaTylkoWTymProjekcie">
> <div id="section2">tu teksty</div>
> <div id="section3">tu teksty</div>
> </div>
> </div>

Nie rozumiem przykładu. Pokazałeś jakiś dokument ale nie wiem do czego
slużą poszczególne elementy. Co chcesz nimi osiągnąć?


>> Nie da się i nie jest to potrzebne. Chodzi raczej o unikanie niepotrzebnej
>> roboty. W kontekście wątku jest to właśnie display: table zamiast TABLE.
>
> Aaahaaa - no to się nie dogadaliśmy. :-)
> Kontekst jest co prawda zupełnie inny: pytanie było czy tabela na DIVach
> i CSS jest dopuszczalną formą tworzenia layoutu bo tabel w sensie
> znaczników HTML - nie jest.

Ale chodzi o to, że to nie jest "tabela na divach". TABLE to TABLE, DIV to
DIV. Sposób wyświetlania jest kwestią drugorzędną. Gdyby to była "tabela na
divach", to równie dobrym (albo równie złym) rozwiązaniem byłaby po prostu
tabela.


> Tak więc nasza dyskusja jest mocno nie na temat :-)
>
>> Do galerii? No ja bym już czegoś takiego we Flashu nie robił, chyba, że
>> miałaby to być prezentacja, a nie strona.
>
> Strony w większości moich realizacji (o ile nie we wszystkich) pełnią
> funkcje prezentacyjne w jakiejś części funkcjonalności.

Ale "bycie prezentacją", a "pełnienie roli prezentacyjnej" to nie to samo.
Strona zawsze pełni "rolę prezentacyjną". Np. gdy połowa z niej znika na
iPhonie.


> Nigdy nie
> robiłem strony z dokumentacją techniczną np. Praktycznie zawsze istnieje
> potrzeba pokazywania jakiejś galerii.

Co nie jest równoznaczne z potrzebą wykorzystywania Flasha. Nadal nie
rozumiem, przynajmniej patrząc na opis, gdzie on tam był potrzebny.


>> Ale na co nie pozwala rezygnacja z Flasha? Masz jeszcze do dyspozycji JS
>> aby dorzucić efekty.
>
> O rany :-) Serio piszesz? :-) Dżdżownicą też się da buta zawiązać :-D

Ale w jaki sposób JS jest gorszy od AS? To są dwie implementacje tego
samego języka. Dodatkowo, każde medium ma swoją specyfikę. Nikt nie dziwi
się, że gazety nie wydają dźwięków. W momencie gdy okazuje się, że do
zaimplementowania rzeczy tak prostej jak galeria niezbędny jest flash,
należałoby raczej pogadać z projektantem interfejsu czy trochę nie
przesadził. Gra? Oczywiście. Film albo odtwarzacz muzyki? Póki co nie ma
lepszego wyjścia niż Flash. Galeria, na litość Boską, obrazków?
Prawdopodobnie gdzieś ktoś uparł się na jeden efekt za wiele.


>> Chodzi o to, bym sobie mógł skopiować URLa, który sprawi, że flaszyk poda
>> mi konkretny eksponat, bez przeklikiwania się. Powiedzmy, że właściciel
>> galerii pisze maila do potencjalnego klienta i w nim zawarte jest coś
>> takiego:
>
> Tak, oczywiście :-) Flash to tylko prezentacja a nie layout i logika
> systemu.

Ale da się? Możesz podać link?


>>> Na czym błąd Twoim zdaniem polega bo nawet nie jestem w stanie domyślić
>>> się toru rozumowania. :-)
>>
>> Nie wiem czy tam był błąd, nie zrozum mnie źle. Niemniej z Twojego opisu
>> nie wynika nic co wymagałoby Flasha, łącznie z "wyszarzaniem" miniaturki.
>> Tu powinien wystarczyć JS. Powstaje też pytanie na ile, z czysto
>> biznesowego punktu widzenia, właściwe jest uniemożliwienie obejrzenia
>> galerii użytkownikom iPhonów albo iPadów. Im dalej za zachodnią granicę tym
>> gorzej. Pokazanie "ciekawe" to także coś, co może oznaczać "bardziej
>> wkurzające", gdy ten sam klient wraca na stronę po raz dziesiąty.
>> Uprzedzając Twoje pytanie - tworzyłem już pełne flashowe galerie
>> pobierające dane z XMLów generowanych przez CMS.
>>
>> *Nigdy więcej* :-)
>
> Ciekawe :-) Bo ja nie odczuwam takiego obrzydzenia :-)
> Nawet nie bardzo sobie wyobrażam jak poradziłbyś sobie w JS np. z
> nazwijmy "pseudo" virtual trip'em po N-poziomowym planie budynku, na
> którym prezentowane są mieszkania, które są do sprzedaży, albo zostały
> już sprzedane, albo są zarezerwowane (zabarwiają się wtedy poszczególne
> lokale na właściwy kolor).

Ponoć mówiliśmy o galerii obrazków. Dopóki nie znam dokładnego projektu
tego "wirtualnego tripu", to nie za bardzo wiem co można z tym zrobić.
Jeśli chodzi zaś o zwykłe wskazanie, że dane mieszkanie jest zajęte, to
trochę nie rozimiem problemu, bo nie widzę tutaj pola na żaden "trip". Do
wygenerowania rysunku i nałożenia linków Flash nie jest potrzebny.


> Potem to wszystko dla X osiedli :-) Należy
> pamiętać, że redaktorzy na bieżąco nanoszą statusy mieszkań a więc JS
> musi z serwerem gadać cały czas. Serio w JS robiłbyś to?

Dopóki nie widzę konkretnego projektu i rozwiązania to nie mogę się
wypowiedzieć, niemniej to, że coś dzieje się "dla X osiedli" raczej żadnych
zmian nie wprowadza.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!