W dniu 2010-12-13 17:16, Michał Gancarski pisze:

> A dlaczego? Bo internauta dowie się, że istnieją przeciwskazania o jedno
> kliknięcie szybciej?

Nie - ponieważ dostanie szczątkową wiedzę ponieważ strona nie jest o
przeciwwskazaniach. Są znacznie lepsze strony opisujące te
przeciwwskazania choć tragicznie zredagowane semantycznie i lądują
daleko w wyszukiwarkach. Nie chcę przeskakiwać cennych źródeł i
szukający informacji pewnie też wolą szybciej do nich dotrzeć.

> A może dostaniecie w ten sposób więcej wejść, bo
> ludzie będą szukać frazy "zabieg przeciwskazania" i jeszcze się okaże, że
> strona udzieliła znaczącej informacji i macie plus jeden do charyzmy?

Poczytaj co odpowiedziałem Tobie i Pawłowi powyżej (w sensie innej
gałązki dyskusji). W szczególności o współczynniku konwersji. Tam
przenieśmy tą konkretną tematykę dyskusji.

> Jestem dziwnie pewien, że nie dbacie o każdy możliwy znak, który mógłby ale
> nie musiał znaleźć się w kodzie strony. Skracaie nazwy klas? Wysyłacie
> stronę skompresowaną? Kompresujecie dodatkowo treść JS, wycinając puste
> znaki? Każdy obrazek idealnie zoptymalizowany? Jeśli odpowiedziałeś na te
> pytania twierdząco, to można rzeczywiście zacząć martwić się o spany.

Uśmiałem się :-D Bo faktycznie prawie wszędzie odpowiedź brzmi "TAK".
Mało tego - ze 3 miesiące siedziałem nad optymalizacją cache'owania CMS
zarówno wewnętrznego jak i w browserach w celu minimalizacji ruchu
zarówno w sieci jak i na serwerze. System CMS dba również o to co
kompresować a czego się nie opłaca. Dbam o takie pierdoły również :-D

Tak czy owak nie to wpływa na jakość dokumentu lecz właśnie struktura.
Jeśli zapuścisz validatory HTML, CSS, a przede wszystkim pozycjonerskie,
to okaże się, że te spany i inne stwarzają więcej potencjalnych
problemów. Brak kompresji JS żaden z nich nie zauważy nawet. Google tez
będą miały to gdzieś. Jeśli natomiast użyjesz <hx> lub <strong> w
oderwaniu od semantyki albo jakiegoś znacznika nie domkniesz to dużo
więcej złego się stanie :-) Tak więc ja odwróciłbym priorytety: najpierw
zastanów się nad html'em i semantyką a potem dłuuuugo nic... i na końcu
zastanawiaj się nad kompresją itp.

>> Hmmm... dziwne dla mnie byłoby takie podejście szczerze mówiąc. Przede
>> wszystkim niepotrzebnie kosztowne.
>
> Tzn. jakie podejście? Sam piszesz, że wszystko 'się dostosowuje', więc
> edytor jest automatycznie jedynie elementem tego, z czego korzysta
> redaktor.

Chodzi mi o budowanie sekcji redakcyjnej dla każdego projektu
oddzielnie. Nie wyobrażam sobie tego w szczególności, że sam na to
poświęciłem może ze 2 lata pracy w sumie dla tej sekcji. Jeśli tyle
czasu miałbym poświęcać każdemu projektowi, to wątpię, że ktoś chciałby
za to płacić.

Natomiast my omawiamy tylko jeden z elementów: wprowadzanie tekstu.

> Ale w konkretnym kontekście. Bez kontekstu ten wątek w ogóle nie powinien
> zaistnieć. No bo lepsza jest opona zimowa czy letnia? A samochód
> małolitrażowy czy monstrum 4x4?

Inaczej można by spytać w tym kontekście: czy lepszy jest samochód,
który za naciśnięciem guzika jest samochodem małolitrażowym lub monstrum
4x4 lub rowerkiem dziecięcym lub TIRem względem samochodu, który nie
potrafi ulegać metamorfozie?

Dlatego właśnie w tym przypadku wybieram a raczej dawno temu wybrałem
opcję A, która nie ogranicza mnie do kontekstowości projektu. CMS moim
zdaniem powinien taki być o ile ma być narzędziem do realizacji
projektów z nieprzewidywalnych branż i funkcjonalności.

Jednakże trzymajmy się wątku edytora treści bo nie skończymy tej
dyskusji :-)

>> Ok. Mamy serwis z białym tłem czarne litery 12px Arial. W edytorze też
>> tak widzimy. Skórka się zmienia bo ktoś umarł. Strona staje się czarna,
>> białe litery, Times 10px. Edytor wyświetla nasz dokument po staremu
>> jeśli go nie przerobimy.
>>
>> A co jeśli serwis ma N skórek do wyboru przez użytkownika? N edytorów
>> będzie potrzebnych?
>
> Ale po co? Nie ma możliwości podejrzenia w bieżącej skórce tego co zostało
> stworzone w edytorze?

Jeśli masz na myśli wygląd edytowanej treści taki jak wygląda bieżąca
skórka serwisu to nie wyobrażam sobie napisania takiego edytora. A już w
szczególności gdy będzie się zmieniać skórka. Jest możliwość oglądania w
oddzielnym oknie treści dokumentu tak jak będzie to wyglądało w
publicznej części serwisu i tylko w jednej skórce. Jednakże to wtedy nie
jest WYSIWYG. Musisz "celować" czy taką ma mieć szerokość kolumna tabeli
a może ciut inną aby wyglądało ok. Czcionka też będzie inna bo np.
edytor Ariala używa a skórka #1 Times'a a skórka #2 Tahomę. itd itp.