** Maciej Łebkowski <m...@e...com> wrote:

> Poza tym ta nawigacja jest dla mnie denerwująca w dokuwiki (a używam tego
> wiki w kilku projektach na codzień).

Też zdarzało mi się używać - ta nawigacja jest fajna jako *dodatkowa*, wtedy
zamiast np. klikać 5 razy "wstecz" mam widoczną historię na stronie i mogę
sobie tam kliknąć. Takie ułatwienie, ale absolutnie nie forma podstawowej
nawigacji.

No i faktycznie najwięcej sensu ma to w przypadku wiki.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

On 09.03.2009, Marek <m...@s...interia.pl> wroted:

>> Bo to jest prosty przypadek, pokrywający się z kategorią w serwisie. Ale
>> bodajże jakieś TikiWiki ma już takie dowolnie definiowane
>> "cross-kategorie",
>> gdzie możesz np. książkę i film opatrzyć tagiem "dokumentalny" i szukać
>> tylko w obrębie takich dodatkowych, luźnych kategorii bez budowania
>> oddzielnej hierarchii.
>
> Noooo... ale czym to się różni od słów kluczowych? Wspomniałeś, że tagi to
> zupełnie coś innego.

Nie, mówiłem tylko o węższym znaczeniu. "Słowo kluczowe" to termin stosowany
w wielu więcej okolicznościach, "tagi" są bardziej precyzyjne (etykiety).
Kwestia terminologii.

> Przykładowo: mam w swoich realizacjach centrum handlowe
> z mnóstwem róznych sklepów wewnątrz. Wśród tych sklepów jest np. kiosk
> ruchu. Do dokumentu opisującego ten kiosk wpisuję słowo np. papierosy. Ktoś
> szukający papierosów wpisze to słowo i znajdzie m.in. w/w kiosk bo ma on w
> słowach kluczowych to wyrażenie choć nigdzie w treści nie występuje ono. Ja
> to nazywam słowem kluczowym. A jak inaczej działa wobec tego tag o jakim
> mówimy?

Dokładnie tak samo, chodzi tylko o wieloznaczność "słowa kluczowego", jest
używane choćby np. w sensie "termin wyszukiwania", czyli słowo wprowadzone
do formularza wyszukiwania. "Tag"/"etykieta" jest bardziej precyzyjne.
Takie etykiety można też np. udostepniać w formularzu wyszukiwania jeśli
nie jest ich zbyt wiele i w ten sposób wprowadzać powiązania między
dokumentami bez potrzeby tworzenia pełnej hierarchii klasyfikacji nadającej
się na breadcrumbsy.

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

do góry

Marek pisze:
>> Dodam, że PHP robi trochę magii i sam ustawia 302 do Location.
>
> Pewnie dlatego mi to działa :-)))

Ale porneL już ci napisał, że dla POST 302 to źle, powinno być 303 :-)

>> Jeśli można dodać własne 3 grosze do dyskusji - kwestia używania GET
>> do wyszukiwania i filtracji.
>> GET w formularzach jest dla mnie nieco kłopotliwe, bo trzeba w
>> ukrytych polach powtórzyć wartości z query (wartości z formularza
>> zastępują query). Druga wada, to ten skrajny przypadek, o którym pisał
>> Colin. Mniej istotna, ale w przypadku filtracji (po wszystkich polach,
>> lista checkboxów itp, IE ma defaultowo ograniczenie do 2KB) może się
>> zdarzyć.
>> Poza tym zwykłe wygodnictwo - kiedy się już napisało kod do obsługi
>> zwykłych formularzy, to chciałoby się go używać do wszystkiego, a nie
>> dokładać obsługę kolejnych przypadków.
>
> Głównie z tego powodu stosuję metodę POST. Mam sporo obiekcji związanych
> z realizacją wyszukiwarki na GET mimo płynących korzyści. Bardzo obawiam
> się, że w jakiejś realizacji zostanie przekroczony limit długości URL i
> wtedy znów będę musiał wrócić do POST. Jałowa praca, za którą nikt nie
> zapłaci.

Tylko z drugiej strony, pomyśl co by było, gdyby powiedzmy Google
używało POST-a. Nici z dzielenia się wynikami wyszukiwania. Pół biedy,
jeśli to serwis intranetowy z dostępem po zalogowaniu. Aczkolwiek też
przy dobrym designie powinno dać się zapamiętywać "ulubione" miejsca.
Dlatego oficjalnie wypada poprzeć porneLa i RFC, a nie dorabiać średnio
uzasadnionej ideologii do własnych błędów :-)

artur

do góry

> Ale porneL już ci napisał, że dla POST 302 to źle, powinno być 303 :-)

Ups faktycznie, przepraszam za gapiostwo.

> Tylko z drugiej strony, pomyśl co by było, gdyby powiedzmy Google używało
> POST-a. Nici z dzielenia się wynikami wyszukiwania.

Tak, tak. To prawda. Google mogą sobie pozwolić na GET bo mają gwarancję, że
zmieszczą się w limicie ilości znaków. Kryteria wyszukiwania są tam bardzo
proste i w niewielkiej ilości. Tymczasem w sklepie z telefonami komórkowymi
sprzedawanymi wraz z umowami tych kryteriów może być masa.


> Pół biedy, jeśli to serwis intranetowy z dostępem po zalogowaniu.
> Aczkolwiek też przy dobrym designie powinno dać się zapamiętywać
> "ulubione" miejsca. Dlatego oficjalnie wypada poprzeć porneLa i RFC, a nie
> dorabiać średnio uzasadnionej ideologii do własnych błędów :-)

Sęk w tym, że wyszukiwarkę miałem zawsze w GETcie zrobioną aż do momentu gdy
nie zaczęła się sypać w paru pokręconych realizacjach. Pewnie nie śledziłeś
całej dyskusji więc przypomnę, że w swoim CMSie daję możliwość adminowi na
dowolne definiowanie cech dokumentów/produktów oraz dołączanie ich jednym
kliknięciem to kryteriów wyszukiwania poszczególnych wyszukiwarek w serwisie
WWW (czasem jest ich kilka). Gdy po roku oglądam swoje dzieło to nie poznaję
go bo właściciel sobie podorzucał to i owo :-) W konsekwencji zdarzało się,
że wyszukiwarka przestawała działać gdy limit GET'a został przekroczony.
Stąd POST. Ponadto zazwyczaj w serwisach, które nie przypominają Googli (a
więc zdecydowanej większości) raczej nie ma po co dawać linku do
wyszukiwarki z listą czegoś tam lecz do konkretnej pozycji - np. produktu w
sklepie czy artykułu w portalu. Tak więc POST nie jest dużym złem w mojej
opinii.

do góry

Chyba załapałem. Tagami mozna uznać bardziej pieczołowicie dobrane słowa
kluczowe różniące się formą prezentacji. Słów kluczowych zazwyczaj nie
publikuje się w treści (artykułu lub wyszukiwarki) a tagi owszem. Słowa
kluczowe rozumiałbym jako ciąg znaków wprowadzonych do jakiegoś pola w bazie
danych powiązanego z artykułem. Tagi to oddzielna tabela oraz druga
linkująca tag z artykułem. Czy dobrze zrozumiałem ?

do góry

> To nawigacja powinna prezentować ten fragment drzewa, przez który
> użytkownik
> dotarł do dokumentu.

Dobrze, zostawmy to. Generalnie w paru wątkach tej dyskusji wniosek był
identyczny. Będę wybijał z głowy klientom inne podejścia :-)

> Powinna zwracać link do konkretnego zasobu, a nie prezentować go wewnątrz.

Nie da się z uwagi na nieprzewidywalność długości GET jaką wygeneruje
zapytanie. Ze 2x w tej dyskusji pisałem, że w moim CMSie redaktor sam
określa cechy produktów/artykułów oraz to, które z nich będą stanowiły
kryteria wyszukiwania. Nie mam pojęcia co wyklika redaktor. Musiałbym
stosować jakieś obejścia z podawaniem w GET ID wyszukiwania i trzymanie tych
kryterów w jakimś pliku. To byłoby chore trochę....

> Jeżeli tego nie wiesz tzn. że nie robiłeś testów funkcjonalnych. Zbierz
> kilka
> osób, posadź ich przed Twoją stroną i zleć im wykonanie kilku scenariuszy
> i
> obserwuj. Idę w zakład, że będziesz bardzo zdziwiony. :)

Obserwacje często robię. Mam niezły poligon do działania. W jednym z centrów
handlowych jego klienci korzystają z nawigacji, którą wykonałem w formie
CMS. Rejestruję też w statystykach ścieżki jakimi poruszają te osoby, jakich
słów szukają - właśnie w celu optymalizacji. W konsekwencji ograniczyłem się
do dwóch sposobów dotarcia do informacji (z planu centrum i z wyszukiwarki).
Więcej usprawnień utrudnia korzystanie.

> Inną opcją jest zaimplementowanie sobie mechanizmów śledzenia click-trough
> i
> patrzenia jak to realnie wygląda, a nie jak Ci się wydaje.
>
> Ergo: przetestuj to będziesz wiedział jak błądzą.

Ergo? Co to takiego?

> Od początku brakuje Ci podstawowego założenia - większość użytkowników nie
> wchodzi na Twoją stronę bo im się nudzi tylko wchodzi aby uzyskać
> określone
> informacje, jeżeli szukają rakiet to można przyjąć, że dopóki tej rakiety
> nie
> znajdą to mało ich piłki obchodzą.

Jednakże ok 30% osób kupujących rakietę tenisową decyduje się na wybór
produktu dowiązanego.

> I czemu tak? Powinien trafić z wyszukiwarki na stronę kategorii. W każdym
> serwisie tak jest. Weź największych - w każdym serwisie tak jest - Google,
> Amazon, eBay, Allegro etc. To co Ty wymyślasz to po prostu jakieś
> cudowanie nie
> wiadomo po co, które tylko użytkownika wprowadzi w zakłopotanie i zagmatwa
> problem, który w zasadzie nie powinien istnieć.

Jeśli w Allegro wpiszę "pasta do zębów" to nie otrzymuję strony kategorii
lecz listę produktów. Kliknięcie na linku wyświetla konkretny produkt. No i
tak działa moja wyszukiwarka - szuka produktów a nie kategorii. Jedynie jako
dodatkową opcję masz informację o kategoriach w jakich produkry znaleziono.
Ja to nazywam sekcją kryteriów wyszukiwania. Chyba czegoś nie zrozumiałem z
Twojej wypowiedzi.

> Naprawdę zakładasz, że użytkownik będzie chodził 15 min. po Twojej
> stronie?

W jednej z realizacji (hurtownia częci elektronicznych) przeciętny czas
spędzony przez klienta na stronie to 20 minut. Bywają również przypadki, w
których osoby bywają na stronie przez cały dzień roboczy i to każdego dnia.
Non-stop wykonują jakieś czynności na stronie.

do góry

Marek pisze:
> Ponadto zazwyczaj w serwisach, które nie przypominają Googli (a więc
> zdecydowanej większości) raczej nie ma po co dawać linku do wyszukiwarki
> z listą czegoś tam lecz do konkretnej pozycji

Cały urok internetu polega na tym, że każdy korzysta tak jak chce/ jak
mu wygodnie. Jeden sobie doda stronę z wynikami wyszukiwania do
zakładek, żeby sprawdzić kiedy będzie nowy produkt danej serii w
sklepie/kolejny artykuł na dany temat w serwisie. Inny podeśle linka
jakiemuś noobowi z wynikami wyszukiwania dla pytania które zadał na
forum. Jeszcze inny podeśle linka do wyników wyszukiwania w porównywarce
cenowej znajomemu, który wcześniej mu podesłał wyniki wyszukiwania na
allegro z wyrzutem "mówiłeś, że max 100PLN". A jeszcze inny podeśle
kumplowi z woja linka do pociągów którymi może dojechać na miejsce
zbiórki. Ups, wróć, nie podeśle rozkładu jazdy pociągów, bo jakiś
geniusz zrobił wyszukiwarkę opartą na sesji.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

> Cały urok internetu polega na tym, że każdy korzysta tak jak chce/ jak
> mu wygodnie. Jeden sobie doda stronę z wynikami wyszukiwania do
> zakładek, żeby sprawdzić kiedy będzie nowy produkt danej serii w
> sklepie/kolejny artykuł na dany temat w serwisie. Inny podeśle linka
> jakiemuś noobowi z wynikami wyszukiwania dla pytania które zadał na
> forum. Jeszcze inny podeśle linka do wyników wyszukiwania w porównywarce
> cenowej znajomemu, który wcześniej mu podesłał wyniki wyszukiwania na
> allegro z wyrzutem "mówiłeś, że max 100PLN". A jeszcze inny podeśle
> kumplowi z woja linka do pociągów którymi może dojechać na miejsce
> zbiórki. Ups, wróć, nie podeśle rozkładu jazdy pociągów, bo jakiś
> geniusz zrobił wyszukiwarkę opartą na sesji.

Tak, to prawda. GET daje możliwości linkowania, bookmarkowania itp.
Przemyślę jak zrobić automat przestawiający wyszukiwarkę w tryb POST gdy GET
byłby zbyt długi.

do góry