W dniu 2010-12-13 19:08, Paweł Piskorz pisze:

> Dla Ciebie i dla mnie tak, ale są ludzie którzy słuchają stron - czy dla
> nich wyróżnienie jest nieważne? MZ jest to ważne dla każdego kto szuka
> informacji o danym produkcie, niezależnie od tego w jakiej postaci je
> dostaje.



>
>> Jednakże naszym celem nie jest promowanie przeciwwskazań.
>
> To strona a nie strong ma promować produkt ;)

Tak się składa, że strong jest ważnym elementem promocji :-) To podstawy
pozycjonowania.

> W takim razie co wrzucasz w stronga? Nazwę produktu? Przecież to
> semantycznie bez sensu, a tylko robienie pod wyszukiwarki (o ile to
> biorą pod uwagę), a fe!

Pod wyszukiwarki tak, to prawda. Nie wiem czy to jest "fe" bo w końcu
promując meritum sprawy obniżam ranking dla treści mniej istotnych. To
ja wiem dla kogo strona jest zbudowana i chcę trafiać do ludzi
najbardziej tematyką zainteresowanych. Chcę aby jak najmniej ludzi
szukających zaledwie wspomnianych w dokumencie wątków trafiało w ich
poszukiwaniu do mnie. Po co mają czuć się sfrustrowanymi z powodu, że
trafiają na małowartościową stronę w tej tematyce?

Staram się tworzyć tak treść aby to co najważniejsze (czyli tematyka
strony) była promowana a tematy poboczne zawarte w tym dokumencie -
zdecydowanie nie.

Troszkę mnie dziwi Twoje stanowisko w tej sprawie. Czytałem zalecenia
Googli na temat zasad budowania treści stron, a także AdWords i
Analytics. Implementowałem mechanizmy badające jakość treści stron.
Dobrym parametrem jakości treści strony może być współczynnik konwersji.
Strona będąca workiem słów (tak jak proponujesz) - pozwalająca się
znajdować gdy szukamy czegokolwiek (przekontrastowuję trochę) ma bardzo
niski współczynnik konwersji przy jednocześnie wysokiej liczbie
odwiedzin. A to jednoznacznie świadczy o tym iż zdecydowana większość
odwiedzających opuściła tą stronę niezadowolona. Tymczasem ta sama
strona po drobnych zabiegach promujących (w tym strong) straciła na
ilości odwiedzin jednakże współczynnik ten wzrósł z 0.5% do 15%!!!
Okazało się, ze w praktyce z mniejszej ilości odwiedzin uzyskano większą
ilość klientów. Wszyscy są zadowoleni: oferent bo ma lepszą sprzedaż,
klient bo nie błądzi i nie klika dziesiątek śmieciowych stron zanim
trafi w cel więc skąd Twoje "fe"? ;-)

do góry

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.

do góry

W dniu 2010-12-13 23:41, Marek pisze:

> 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.

Używałem kiedyś edytora Epoz - miał możliwość edycji (wyświetlania)
treści z zadanym css - użyłem tego w serwisie, gdzie każdy dział miał
inne grafiki tła i kolory treści, i bardzo ładnie to działało.

Epoz już nie jest rozwijany, jego następcą jest Kupu używany w Plone i
wielu innych CMS-ach - też umożliwia edycję z zadanym css. Podejrzewam,
że jest takich edytorów więcej.

do góry

On Sun, 12 Dec 2010 15:31:33 -0000, porneL wrote:

[...]

> Semantyczność <span> i <b> jest w obu przypadkach bylejaka, ale kod z <b>
> przynajmniej działa bez CSS, jest krótszy i jak pogrubienia w kodzie
> zaczną ci przeszkadzać, to będzie łatwiej zmienić/usunąć <b>, niż parsować
> style w <span>.

Eee, chyba łatwiej po prostu zmienić styl dla klasy w spanie i w ogóle nie
ruszać HTMLa?


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

On Mon, 13 Dec 2010 22:33:24 +0100, Marek wrote:

> W dniu 2010-12-13 17:06, Michał Gancarski pisze:
>>> Jednakże nieistotny dla tego samego człowieka siedzącego w
>>> Googlach w celu znalezienia produktu.
>>
>> Ale skąd pomysł, że wiesz czego szukają ludzie, którzy powinni trafić na tę
>> stronę?
>
> Odwrotnie: wiem jako redaktor dla kogo content jest dedykowany.

No właśnie nie do końca. To jest dość powszechna iluzja w sieci. Każdy ma
pewne wyobrażenie o tym dla kogo przeznaczona jest jego strona ale nie ma
zielonego pojęcia o tym kto może być nią zainteresowany. To są dwie
przeciwne relacje. O ile można uwypuklić pewne treści, o tyle nie można
zadecydować kto uzna stronę za wartościową, bo ta decyzja leży już po
drugiej stronie.


> Kompletnie nie zależy mi na grupie osób szukających przeciwwskazań do
> promowanej usługi.

Co nie znaczy, że wiesz, że takie osoby nie będą zainteresowane tą stroną.
Nie ma sensu utrudnianie dotarcia im do niej. Jak się zresztą okazuje, oba
znaczniki, b i strong mogą mieć podobną siłę:

http://www.seomoz.org/article/search-ranking-factors
#ranking-factors


> Szeroko na ten temat piszą inne źródła a moja strona
> zawiera tylko wzmianki na ten temat bez szczegółowych objaśnień. Jeśli
> ktoś szukający przeciwwskazań trafi na moja stronę będzie zawiedziony
> ogólnikowością informacji i potraktuje tą stronę jako śmieciową w tej
> tematyce.

Ale skąd wiesz?


> Po co mam przebijać lepsze źródła, a które np. nie zadbały
> prawidłową semantykę i są daleko w wynikach?

Jeśli nie można ich znaleźć to automatycznie nie mogą być lepsze. Z punktu
widzenia internauty źródła, do których nie może dotrzeć albo dotrzeć nie
chce (bo są daleko), w zasadzie są bezużyteczne i nieistniejące.


>> O ile można stwierdzić jakie frazy są interesujące dla Was, o tyle
>> w żaden sposób nie da się stwierdzić jakie informacje mogą być ważne dla
>> internautów w powiązaniu z Waszymi produktami.
>
> Wiesz... jestem przeciwnikiem zaśmiecania internetu. Takie podejście
> traktuję jako naganne. Wiele razy udawało mi się trafić szukając czegoś
> na strony, które tylko wzmiankowały o tym. Przykładanie się do
> jakiegokolwiek promowania treści zaledwie wzmiankowanych w dokumencie
> nazywam tworzeniem spamu.

Równie szkodliwe jest ukrywanie treści, która może być wartościowa. To, że
macie na stronie jedynie wzmiankę o czymś nie znaczy, że ktoś nie uzna jej
za wartościową. Skoro informacja znajduje się na tej stronie i jesto godna
wyróżnienia to trudno stwierdzić, że wartości nie ma.


>> I jeśli trafi do Was człowiek szukający przeciwskazań to co dokładnie się
>> stanie?
>
> Wkurzy się, że trafił na kolejną bezwartościową stronę.

Tego nie wiesz, chyba, że dokładnie to sprawdziłeś, tzn. przekonałeś się,
że macie całą masę odwiedzających, którzy wchodzą przez frazę
"przeciwskazania cośtam" i potem od razu wychodzą, a przynajmniej nie
podrużują po stronie tak intensywnie jak reszta odwiedzających.


>> Co najwyżej zamówi produkt.
>
> Serio? :-D No tak, to chyba jakaś nowoczesna forma marketingu :-D
> Konkretniej zatem: kosmetyczka szuka informacji w internecie na temat
> usługi, którą zamierza świadczyć. Chce wiedzieć jakie są doświadczenia
> innych, jakie problemy mogą wystąpić i czy warto inwestować dziesiątki
> tys. zł w sprzęt do jakiegoś zabiegu. W zamian dostaje stronę j/w i
> potem kolejną i kolejną. Niczego się nie dowiedziała po godzinie
> spędzonej przed monitorem. Przyglądałem się jej pracy i zdumiony byłem
> ilością śmieci i to w dość wąskiej dziedzinie kosmetologii. Tworząc jej
> serwis przyłożyłem się do tego aby nie stał się kolejnym śmieciem. Jeśli
> ktoś szuka usługi jaką ona świadczy: znajdzie ją szybko. Jeśli ktoś
> szuka TREŚCIWYCH przeciwwskazań do tej usługi - znajdzie je w lepszych
> miejscach.

No właśnie nie znajdzie, z tego co opisujesz. Zamiast walczyć z brakiem
informacji w sieci poprzez jego pogłębienie (!), można było ten fakt
wykorzystać i skrótowo umieścić ją także na tej stronie (z odpowiednimi
linkami), promując ją jako dobre wstępne źródło informacji i naprawiając
częściowo problem. A tak nie dość, że nic nie naprawiłeś (zamiast tego
próbując powstrzymać przeglądarki od reagowania na znaczącą bo wyróżnioną
frazę), to jeszcze zmniejszyłeś prawdopodobieństwo tego, że ktoś znajdzie
informację pod frazą "zabieg przeciwskazania". Ta informacja na stronie
kosmetyczki się przecież znajduje. Skrótowo i zwięźle podana ale ona tam
jest i być może wystarczy to komuś kto tę stronę odwiedzi. Zwłaszcza gdy,
jak sam piszesz, "lepsze źródła" są tak naprawdę niewidoczne, czyli
bezużyteczne.


>> W dodatku znajdzie go po treści ważnej
>> nie tylko dla niego samego (bo wpisał frazę w wyszukwiarkę) ale i znaczącej
>> z punktu widzenia użytkowania produktu (bo tekst został, z jakichś powodów,
>> przez redaktora serwisu specjalnie oznaczony).
>>
>
> A'propos... czy na poziomie bloku można dla Googli (przede wszystkim)
> zdefiniować nieindeksowanie?

Na poziomie "bloku"?


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

Ciekawe to co piszesz. W jaki sposób to działała, że podpięcie obcego
CSS nie rozwala okna edytora lub że w ogóle to może funkcjonować?

Są tu dwa aspekty: CSS działa relatywnie do miejsca, w którym jest.
Czyli np. jeśli CSS czerpie obrazki z podkatalogu skórka/nazwa/obrazki a
edytor mieści się w katalogu /edytor to zaciągnięcie takiego CSS bez
modyfikacji ścieżek w nim nie wyświetli obrazków. Ale to pikuś bo ew.
ścieżki może jakiś automat zmienić (czy tak się to robi?).

Po drugie: samo podpięcie CSS bez zachowania struktury HTML nie ma
sensu. Np. Jeśli mamy z jakiś powodów dokument:

<div class="czerwony">
tu treść, która jest w bazie danych dostępna dla edytora
</div>

i klasę:

.czerwony {color:red}

to w edytorze tekst nie wyświetli się nam na czerwono: czyli tak jak w
dokumencie o ile nie przeniesiemy do edytora całej struktury HTML
dokumentu powyżej i poniżej edytowanego miejsca - czyli bez dodania
otaczającego DIVa z powyższego przykładu. DIV stanowi element formatki a
nie wprowadzanego edytorem kodu.

Jeszcze jedno pytanie na koniec: skąd edytor wie, jakie klasy/style może
z pliku CSS udostępnić? Nie ma sensu pokazywać całości CSS, który
narzuca styl formatki (kontener, sekcje w kontenerze itp) kiedy np. 3
klasy ze 50 w CSS mogą być udostępnione redaktorowi.

do góry

W dniu 2010-12-14 09:25, Marek pisze:
> Ciekawe to co piszesz. W jaki sposób to działała, że podpięcie obcego
> CSS nie rozwala okna edytora lub że w ogóle to może funkcjonować?
>
> Są tu dwa aspekty: CSS działa relatywnie do miejsca, w którym jest.
> Czyli np. jeśli CSS czerpie obrazki z podkatalogu skórka/nazwa/obrazki a
> edytor mieści się w katalogu /edytor to zaciągnięcie takiego CSS bez
> modyfikacji ścieżek w nim nie wyświetli obrazków. Ale to pikuś bo ew.
> ścieżki może jakiś automat zmienić (czy tak się to robi?).

Stosowałem to tak:
obrazki i css: skórka/nazwa/css, skórka/nazwa/obrazki
widok artykułu: ścieżka/nazwa-artykułu
edycja: ścieżka/nazwa-artykułu/edycja
więc oba widoki widziały te same ścieżki do obrazków i css

> Po drugie: samo podpięcie CSS bez zachowania struktury HTML nie ma
> sensu. Np. Jeśli mamy z jakiś powodów dokument:
>
> <div class="czerwony">
> tu treść, która jest w bazie danych dostępna dla edytora
> </div>
>
> i klasę:
>
> .czerwony {color:red}
>
> to w edytorze tekst nie wyświetli się nam na czerwono: czyli tak jak w
> dokumencie o ile nie przeniesiemy do edytora całej struktury HTML
> dokumentu powyżej i poniżej edytowanego miejsca - czyli bez dodania
> otaczającego DIVa z powyższego przykładu. DIV stanowi element formatki a
> nie wprowadzanego edytorem kodu.

Z tego co pamiętam, to edytor doklejał w locie jakąś strukturę
nagłówkową (można ją było zdefiniować, nie byłe widoczna dla redaktora),
a później podczas zapisu do bazy to usuwał, ale nie pamiętam szczegółów.

> Jeszcze jedno pytanie na koniec: skąd edytor wie, jakie klasy/style może
> z pliku CSS udostępnić? Nie ma sensu pokazywać całości CSS, który
> narzuca styl formatki (kontener, sekcje w kontenerze itp) kiedy np. 3
> klasy ze 50 w CSS mogą być udostępnione redaktorowi.

Tego nie używałem, ale z tego co pamiętam, to można było zdefiniować
listę klas udostępnianych w edytorze. Zerknij np. tutaj:
http://www.contentmanagementsoftware.info/plone-book
/kupu/styles

do góry

grudzień roku pamiętnego 2010, prawdopodobnie 14. Wielka mądrość na
czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:

> > A'propos... czy na poziomie bloku można dla Googli (przede
> > wszystkim) zdefiniować nieindeksowanie?
>
> Na poziomie "bloku"?

No na poziomie bloku. Coś na zasadzie:

<div robots="User-agent: *; Disallow: this;">
<p>Tutaj jakieś treści o których wiemy, że nie chcemy aby były
indeksowane.</p>
<p>I jeszcze jeden akapit, żeby nie było że div jest zbędny.</p>
</div>
--
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
Mirosław Zalewski

do góry

On Tue, 14 Dec 2010 11:21:22 +0100, Mirosław Zalewski wrote:

> grudzień roku pamiętnego 2010, prawdopodobnie 14. Wielka mądrość na
> czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:
>
>>> A'propos... czy na poziomie bloku można dla Googli (przede
>>> wszystkim) zdefiniować nieindeksowanie?
>>
>> Na poziomie "bloku"?
>
> No na poziomie bloku. Coś na zasadzie:
>
> <div robots="User-agent: *; Disallow: this;">
> <p>Tutaj jakieś treści o których wiemy, że nie chcemy aby były
> indeksowane.</p>
> <p>I jeszcze jeden akapit, żeby nie było że div jest zbędny.</p>
> </div>

Ach. Nie spotkałem się. Poza tym to już chyba podpada pod:

"Make pages primarily for users, not for search engines. Don't deceive your
users or present different content to search engines than you display to
users, which is commonly referred to as "cloaking.""


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-12-14 11:45, Michał Gancarski pisze:
> On Tue, 14 Dec 2010 11:21:22 +0100, Mirosław Zalewski wrote:
>
>> grudzień roku pamiętnego 2010, prawdopodobnie 14. Wielka mądrość na
>> czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Michał Gancarski:
>>
>>>> A'propos... czy na poziomie bloku można dla Googli (przede
>>>> wszystkim) zdefiniować nieindeksowanie?
>>>
>>> Na poziomie "bloku"?
>>
>> No na poziomie bloku. Coś na zasadzie:
>>
>> <div robots="User-agent: *; Disallow: this;">
>> <p>Tutaj jakieś treści o których wiemy, że nie chcemy aby były
>> indeksowane.</p>
>> <p>I jeszcze jeden akapit, żeby nie było że div jest zbędny.</p>
>> </div>

Można gdzieś znaleźć opis tego i jakie roboty to respektują?
To jakiś standard?

> Ach. Nie spotkałem się. Poza tym to już chyba podpada pod:
>
> "Make pages primarily for users, not for search engines. Don't deceive your
> users or present different content to search engines than you display to
> users, which is commonly referred to as "cloaking.""

To może być użyteczne np w katalogach, gdzie mamy rozbudowane menu
kategorii, które powtarza się na każdej stronie i jest z punktu
widzenia wyszukiwania treści na stronie zupełnie nieistotne
Np. mam katalog książek, strona wyświetla opis książki historycznej
a obok lista innych kategorii w katalogu - sensacja, horror, technika
itd. - aż się prosi, żeby wyłączyć indeksowanie tego menu przez
wyszukiwarki.

Patrząc na to inaczej - to menu nie jest fragmentem treści strony, jest
fragmentem interfejsu użytkownika, nie powinno być uwzględniane jako
treść w wyszukiwarce.

do góry