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

do góry

** Marek <m...@s...interia.pl> wrote:

> Mam problem koncepcyjny, może ktoś z Was mnie oświeci. Otóż mamy sobie CMS a
> w nim drzewko kategorii. W tych kategoriach mamy sobie dokumenty. To po
> stronie redakcyjnej.

> Po stronie publicznej oglądacz ogląda sobie treści zaglądając do różnych
> dokumentów. Do tego samego dokumentu raz wejdzie poprzez strona
> główna/newsy/archiwalne/moj_dokument.html a innym razem strona
> główna/wyszukiwarka/moj_dokument.html.

No i to jest podstawowy błąd. Jeden zasób (dokument) powinien występować pod
jednym adresem URI. Kropka. Modulo ten sam zasób w różnych formach (np. do
wydruku, PDF, whatever).

Serio ta wyszukiwarka jest tak do dupy? Może zmień CMS w takim razie (albo
wyszukiwarkę).

> Jeszcze innym razem oglądacz wykona kilka pętli po serwisie zanim dotrze do
> tego samego dokumentu i w tym przypadku przedstawianie ścieżki jako obłędnej
> drogi jest pozbawione sensu.

Czemu uważasz, że ktoś będzie wykonywał jakieś nieokreślone pętle po Twoim
serwisie? Ludzie zupełnie inaczej działają. Najczęściej wlezą Ci na serwis to
za pierwszym razem trochę pobłądzą, za drugim razem trafią dokładnie prościutko
tam gdzie chcą (bo pamiętają), przy założeniu, że masz sensowną
nawigację/wyszukiwarkę (jedni wyszukują inni nawigują).

> Jak koncepcyjnie podejść do realizacji wyświetlania takiej ścieżki dostępu?

Normalnie. Pokazać ścieżkę dostępu. Jak silisz się na eksperymenty to możesz
przecież bez problemu zaimplementować tradycyjną (zgodną z konwencjami) metodę
nawigacji i obok jakąś wydumaną. I potem sobie zobacz, z której użytkownicy
będą korzystali. :)))

> Czy operować zawsze strukturą kategorii i dać sobie spokój z badaniem
> aktywności użytkownika?

A czy operowanie strukturą kategorii uprawnia do dania sobie spokoju z badaniem
aktywności użytkownika? Jak dla mnie to dwie różne kwestie.

> Czy rejestrowanie i przedstawienie faktycznej drogi jako przemierzył oglądacz
> ma jakikolwiek sens i czy da się w ogóle rozsądnie pokazać?

Ma i da się. Ma ponieważ nie każdy użytkownik (imagine that) jest świadomy
tego, do czego służy przycisk "wstecz". :) Również ja np. wiem do czego służy,
ale lubię taką formę.

Da się to przedstawić jako po prostu lista:

Historia Twojej wizyty: strona główna >> narzędzia >> wiertarki >> narzędzia >>
wkrętarki >> wkrętak 3000!!!

ALE to jako forma dodatkowa, nie jako podstawowa nawigacja.

> Jak realizujecie tego typu zadania?

Dokuwiki ma coś podobnego (o ile ja Cię dobrze rozumiem):
http://www.dokuwiki.org/dokuwiki

Poklikaj sobie w obrębie wiki i patrz co się wyświetla w okolicy napisu
"trace"/"ślad" - o to Ci chodzi?

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

do góry

On Mon, 09 Mar 2009 21:10:27 -0000, Marek <m...@s...interia.pl> wrote:

>> W przeglądarkach obsługujących HTTP poprawnie dostajesz poprzednią
>> stronę bez pytania i bez ponownego POST :)
>
> A jakie to? Pod IE i FF otrzymywałem zawsze zapytanie o zgodę na
> re-submit i to było przyczyną mojej decyzji dot. zastosowania sztuczki z
> location. Być może coś w bieżących wersjach zmienili...

Opera, Safari.

>> W tych, które mylą cache z historią musisz użyć sztuczki z POST +
>> status 303, żeby się głupio nie pytały.
>
> Poeksperymentuję i jeśli zadziała to zmienię choć nie bardzo rozumiem
> róznicę pomięcy samym location a location + 303.

Samo location nic nie robi. Musi być połączone z jakimś statusem. Zazwyczaj używa się
do tego 301 albo 302, ale specyfikacja zabrania odpowiadania tymi statusami na POST
(przeglądarki od tego głupieją i czasem wysyłają formularz dwa razy). Dlatego powstał
status 303, który bezpiecznie przekierowuje po POST.

> Już lepiej wyłączyć cache bo cholera wie w jaki sposób user powróci: czy
> "wsteczem", czy linkiem w treści strony, czy z palca wpisze URL.

Owszem.

BTW: Z założenia (RFC 2616 13.13) wstecz nie jest nawigacją, a cofaniem w czasie,
dlatego cache (i POST) nie powinien w ogóle wpływać na cofanie.

--
http://pornel.net
this.author = new Geek("porneL");

do góry

> No i to jest podstawowy błąd. Jeden zasób (dokument) powinien występować
> pod
> jednym adresem URI. Kropka. Modulo ten sam zasób w różnych formach (np. do
> wydruku, PDF, whatever).

Niestety nie może. Ten sam dokument czasem wymaga różnych form prezentacji.
Drukowanie to jedno z zagadnień - inne to przynależność do wielu kategorii
jednocześnie. Jest więcej aspektów niż te 2. Dlatego w CMSie poza pojęciem
dokumentu istnieje możliwość tworzenia skrótów do niego. Skróty do dokumentu
mogą narzucać dokumentowi pewne cechy itp. itd.

> Serio ta wyszukiwarka jest tak do dupy? Może zmień CMS w takim razie (albo
> wyszukiwarkę).

Też nie mogę gdyż wyrzuciłbym 8 lat mojej pracy do śmietnika :-)
Nie bardzo zrozumiałem co w wyszukiwarce jest nie tak jak powinno? Nawet nie
poruszyłem tematu zasad jej działania więc skąd ten wniosek?

> Czemu uważasz, że ktoś będzie wykonywał jakieś nieokreślone pętle po Twoim
> serwisie?
> Ludzie zupełnie inaczej działają. Najczęściej wlezą Ci na serwis to
> za pierwszym razem trochę pobłądzą, za drugim razem trafią dokładnie
> prościutko
> tam gdzie chcą (bo pamiętają), przy założeniu, że masz sensowną
> nawigację/wyszukiwarkę (jedni wyszukują inni nawigują).

No i o to słowo "pobłądzą" mi chodzi. A w jaki sposób mogą pobłądzić? Bardzo
prosto. Przykładowo: mamy sklep sportowy ze sprzętem do tenisa. Po wejściu
na rakietę tenisową widzimy w sekcji "zobacz również" piłki. Klikamy na
zachęcie i lądujemy w dokumencie zgodnie ze ścieżką poruszania się:

Strona główna/wyszukiwarka/rakiety/jakas_rakieta.html/jakas
_pilka.html

Innym raze ktoś szuka piłki i dotrze do niej w inny sposób:

Strona główna/wyszukiwarka/piłki/jakas_pilka.html

Ten sam produkt i dwie różne ścieżki jakie przebył klient.

> Normalnie. Pokazać ścieżkę dostępu.

Czyli kategorię (tzn całą hierarchię), do której przynależy dokument? W
takim przypadku kliknięcie ma np. kategorii o oczko wyżej będzie prowadziłoz
dużym prawdopodobieństwem w inne miejsce niż "wstecz". Zachodzi więc
konflikt koncepcyjny.

> Jak silisz się na eksperymenty to możesz
> przecież bez problemu zaimplementować tradycyjną (zgodną z konwencjami)
> metodę
> nawigacji i obok jakąś wydumaną. I potem sobie zobacz, z której
> użytkownicy
> będą korzystali. :)))

Szczerze mówiąc nie zależy mi na eksperymentach lecz na wynikach tych
eksperymentów. Wrodzone lenistwo mnie do tego skłania :-))

> A czy operowanie strukturą kategorii uprawnia do dania sobie spokoju z
> badaniem
> aktywności użytkownika? Jak dla mnie to dwie różne kwestie.

Więc w swoich realizacjach prezentujesz 2 ścieżki? Jedną zgodną z hierarchią
kategorii a drugą zgodną z czynnościami jakie wykonał użytkownik?

> Da się to przedstawić jako po prostu lista:
>
> Historia Twojej wizyty: strona główna >> narzędzia >> wiertarki >>
> narzędzia >>
> wkrętarki >> wkrętak 3000!!!
>
> ALE to jako forma dodatkowa, nie jako podstawowa nawigacja.

Jedyny kontrargument jaki mi do głowy przychodzi to fakt, że ta ścieżka po
15 minutach chodzenia po serwisie będzie tak długa, że zajmie większość
treści strony. Przyglądałem się aktywności klientów w hurtowni podzespołów
elektronicznych, w której przeciętnej wielkości zamówienie ma na oko 50-100
pozycji. Wiele kliknięć temu towarzyszyło... A do tego jeśli serwis ma
bardziej złożoną strukturę (jak niżej), to wtedy długość ścieżki rośnie w
nieskończoność.

> Dokuwiki ma coś podobnego (o ile ja Cię dobrze rozumiem):
> http://www.dokuwiki.org/dokuwiki
>
> Poklikaj sobie w obrębie wiki i patrz co się wyświetla w okolicy napisu
> "trace"/"ślad" - o to Ci chodzi?

Dokładnie o to :-) Tyle tylko, że ten serwis ma najbardziej banalną
nawigację. Gdy zagłębisz się w jakiś poziom to jedynym sposobem powrotu jest
"wstecz". W praktyce - np. w sklepach internetowych zazwyczaj tak nie jest i
nawet z poziomu końcowego ogniwa łańcucha (np. karty katalogowej produktu)
da się przejść do innych sekcji / produktów. Wtedy sprawy się mocno
komplikują.

do góry

Dnia 10-03-2009 o 01:42:56 Marek <m...@s...interia.pl> napisał(a):

>> Normalnie. Pokazać ścieżkę dostępu.
> Czyli kategorię (tzn całą hierarchię), do której przynależy dokument? W
> takim przypadku kliknięcie ma np. kategorii o oczko wyżej będzie prowadziłoz
> dużym prawdopodobieństwem w inne miejsce niż "wstecz". Zachodzi więc
> konflikt koncepcyjny.

A komu przyjdzie do głowy, że przyciski "w górę" ma taką samą
funkcję jak "wstecz"? Jeśli chce wrócić do rakiet, bo piłki mu
się nie podobają, to klika wstecz na pasku przeglądarki. Jeśli
jednak woli pooglądać jeszcze inne piłki, klika na kategorię
"piłki" w breadcrumbsach.

>> Poklikaj sobie w obrębie wiki i patrz co się wyświetla w okolicy napisu
>> "trace"/"ślad" - o to Ci chodzi?
> Dokładnie o to :-) Tyle tylko, że ten serwis ma najbardziej banalną
> nawigację. Gdy zagłębisz się w jakiś poziom to jedynym sposobem powrotu jest
> "wstecz". W praktyce - np. w sklepach internetowych zazwyczaj tak nie jest i
> nawet z poziomu końcowego ogniwa łańcucha (np. karty katalogowej produktu)
> da się przejść do innych sekcji / produktów. Wtedy sprawy się mocno
> komplikują.

Wiki ma dowolną formę dotarcia do artykułu. Czy to wzdłuż, czy w poprzek
hierarchii. A powrót to zawsze wstecz, niekoniecznie "w górę".
Poza tym ta nawigacja jest dla mnie denerwująca w dokuwiki (a używam tego
wiki w kilku projektach na codzień). Podejrzewam, że większość użytkowników
sądzi podobnie. Zrób prosty test - posadzi przed takimi breadcrumbsami
użytkownika, każ mu pochodzić po serwisie, a w którymś momencie każ mu
wrócić do strony "X", którą odwiedził trzy PV wcześniej. Zobacz, ilu z nich
użyje "wstecz", a ilu zauważy ten pasek. I odwrotnie - kaz wejsc o poziom
wyzej i sprawdz, ile osob bedzie szukalo na tym pasku ogolnych kategorii,
ktorych tam nie bedzie.
A, o zgrozo - za pierwszym i drugim razem sie pojawia, a potem user
przyjdzie inna sciezka i nie bedzie tam tego, czego szukal. "Zepsuty ten
serwis" - zaloze sie ze krzyknie.


--
Maciej Łebkowski

do góry

porneL pisze:
> Samo location nic nie robi. Musi być połączone z jakimś statusem.
> Zazwyczaj używa się do tego 301 albo 302, ale specyfikacja zabrania
> odpowiadania tymi statusami na POST (przeglądarki od tego głupieją i
> czasem wysyłają formularz dwa razy). Dlatego powstał status 303, który
> bezpiecznie przekierowuje po POST.

Dodam, że PHP robi trochę magii i sam ustawia 302 do Location.
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.

artur

do góry

> Dodam, że PHP robi trochę magii i sam ustawia 302 do Location.

Pewnie dlatego mi to działa :-)))

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

do góry

> Dodam, że PHP robi trochę magii i sam ustawia 302 do Location.

Pewnie dlatego mi to działa :-)))

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

do góry

> A komu przyjdzie do głowy, że przyciski "w górę" ma taką samą
> funkcję jak "wstecz"? Jeśli chce wrócić do rakiet, bo piłki mu
> się nie podobają, to klika wstecz na pasku przeglądarki. Jeśli
> jednak woli pooglądać jeszcze inne piłki, klika na kategorię
> "piłki" w breadcrumbsach.

Czyli reasumując - proponujesz takie samo rozwiązanie jak koledzy w
niniejszym wątku: niech "wstecz" robi swoje a ścieżka pokazuje
umiejscowienie dokumentu w drzewie kategorii?

> A, o zgrozo - za pierwszym i drugim razem sie pojawia, a potem user
> przyjdzie inna sciezka i nie bedzie tam tego, czego szukal. "Zepsuty ten
> serwis" - zaloze sie ze krzyknie.

:-)))))
Tak, masz rację. Sam krzyczałbym podobnie.
Cały ten wątek wziął się stąd, że w jednym z projektów klient zażyczył sobie
ścieżkę do produktu bardzo wymyślną. Oczywiście przestała ona funkcjonować
intuicyjnie - jak przewidywałem. W związku z moim doświadczeniem
postanowiłem albo dowiedzieć się czy są jakieś inne dobre sposoby nawigacji
poza przemierzaniem hierarchii albo zdobyć argumentację przeciwko takim
wybrykom jak dynamiczne ścieżki powrotu.

do góry

** Marek <m...@s...interia.pl> wrote:

>> No i to jest podstawowy błąd. Jeden zasób (dokument) powinien występować
>> pod jednym adresem URI. Kropka. Modulo ten sam zasób w różnych formach (np.
>> do wydruku, PDF, whatever).

> Niestety nie może. Ten sam dokument czasem wymaga różnych form prezentacji.

Dlatego dałem modulo.

> Drukowanie to jedno z zagadnień - inne to przynależność do wielu kategorii
> jednocześnie.

Nie kategorii tylko umiejscowienia (lokalizacji) na drzewie. Według mnie to
jeżeli masz dany dokument w wielu lokalizacjach np.

/produkty/wkretarki/wkretarka-turbo-3000
/promocje/2009/wkretarka-turbo-3000

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

> Jest więcej aspektów niż te 2.

Jasne, nawigację można zagmatwać bardzo spektakularnie, a aspekty mnożyć. To
nie jest trudne. Trudne jest natomiast (chociaż w sumie mnie to dziwi bo dla
mnie zawsze było to oczywiste) stworzenie takiej nawigacji coby była po prostu
normalna po ludzku.

> Dlatego w CMSie poza pojęciem dokumentu istnieje możliwość tworzenia skrótów
> do niego. Skróty do dokumentu mogą narzucać dokumentowi pewne cechy itp. itd.

No to jak w każdym sensownym CMSie.

>> Serio ta wyszukiwarka jest tak do dupy? Może zmień CMS w takim razie (albo
>> wyszukiwarkę).

> Też nie mogę gdyż wyrzuciłbym 8 lat mojej pracy do śmietnika :-) Nie bardzo
> zrozumiałem co w wyszukiwarce jest nie tak jak powinno?

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

> Nawet nie poruszyłem tematu zasad jej działania więc skąd ten wniosek?

Wniosek z tego co napisałeś.

>> Czemu uważasz, że ktoś będzie wykonywał jakieś nieokreślone pętle po Twoim
>> serwisie? Ludzie zupełnie inaczej działają. Najczęściej wlezą Ci na serwis
>> to za pierwszym razem trochę pobłądzą, za drugim razem trafią dokładnie
>> prościutko tam gdzie chcą (bo pamiętają), przy założeniu, że masz sensowną
>> nawigację/wyszukiwarkę (jedni wyszukują inni nawigują).

> No i o to słowo "pobłądzą" mi chodzi. A w jaki sposób mogą pobłądzić?

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

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

> Bardzo prosto. Przykładowo: mamy sklep sportowy ze sprzętem do tenisa. Po
> wejściu na rakietę tenisową widzimy w sekcji "zobacz również" piłki. Klikamy
> na zachęcie i lądujemy w dokumencie zgodnie ze ścieżką poruszania się:

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

> Strona główna/wyszukiwarka/rakiety/jakas_rakieta.html/jakas
_pilka.html Innym
> raze ktoś szuka piłki i dotrze do niej w inny sposób:

> Strona główna/wyszukiwarka/piłki/jakas_pilka.html

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

> Ten sam produkt i dwie różne ścieżki jakie przebył klient.

Ojej odkrywasz coś co od dawna jest oczywiste - jedni wyszukują inni nawigują.

>> Normalnie. Pokazać ścieżkę dostępu.

> Czyli kategorię (tzn całą hierarchię), do której przynależy dokument?

Tak - hierarchia to od dawien dawna (nie tylko na WWW) przyjęta konwencja, z
którą użytkownik jest obeznany.

> W takim przypadku kliknięcie ma np. kategorii o oczko wyżej będzie
> prowadziłoz dużym prawdopodobieństwem w inne miejsce niż "wstecz". Zachodzi
> więc konflikt koncepcyjny.

Nie zachodzi. Chyba nie rozumiesz do czego służy przycisk wstecz oraz dowiedz
się też jak on jest używany (40% kliknięć to "wstecz").

>> Jak silisz się na eksperymenty to możesz przecież bez problemu
>> zaimplementować tradycyjną (zgodną z konwencjami) metodę nawigacji i obok
>> jakąś wydumaną. I potem sobie zobacz, z której użytkownicy będą korzystali.
>> :)))

> Szczerze mówiąc nie zależy mi na eksperymentach lecz na wynikach tych
> eksperymentów. Wrodzone lenistwo mnie do tego skłania :-))

To kup sobie książki o temacie.

>> A czy operowanie strukturą kategorii uprawnia do dania sobie spokoju z
>> badaniem aktywności użytkownika? Jak dla mnie to dwie różne kwestie.

> Więc w swoich realizacjach prezentujesz 2 ścieżki?

To zależy... :)))

> Jedną zgodną z hierarchią kategorii a drugą zgodną z czynnościami jakie
> wykonał użytkownik?

Jak napisałem wyżej - to zależy od koncepcji, np. konwencję nawigacji kolejno
po czynnościach stosuje się często przy transakcjach przykładowo: kompletowanie
zamówienia -> uzupełnianie danych -> forma płatności -> potwierdzenie.

>> Da się to przedstawić jako po prostu lista:

>> Historia Twojej wizyty: strona główna >> narzędzia >> wiertarki >> narzędzia

>> ALE to jako forma dodatkowa, nie jako podstawowa nawigacja.

> Jedyny kontrargument jaki mi do głowy przychodzi to fakt, że ta ścieżka po 15
> minutach chodzenia po serwisie będzie tak długa, że zajmie większość treści
> strony.

Naprawdę zakładasz, że użytkownik będzie chodził 15 min. po Twojej stronie?
:))) Jesteś ogromnym optymistą. Jak w 15 sek. nie znajdzie tego czego
potrzebuje to pójdzie gdzie indziej (well uproszczenie - zależy od tego jakiej
wagi informacji szuka - jeżeli chodzi o wiertarkę to wybędzie momentalnie).

> Przyglądałem się aktywności klientów w hurtowni podzespołów elektronicznych,
> w której przeciętnej wielkości zamówienie ma na oko 50-100 pozycji. Wiele
> kliknięć temu towarzyszyło... A do tego jeśli serwis ma bardziej złożoną
> strukturę (jak niżej), to wtedy długość ścieżki rośnie w nieskończoność.

Nie rośnie - jeżeli nie duplikujesz tego co tam się wyświetla to możliwa
długość ścieżki będzie taka ile jest w ogóle możliwych elementów na stronie,
czyli jak najbardziej skończona.

>> Dokuwiki ma coś podobnego (o ile ja Cię dobrze rozumiem):
>> http://www.dokuwiki.org/dokuwiki

>> Poklikaj sobie w obrębie wiki i patrz co się wyświetla w okolicy napisu
>> "trace"/"ślad" - o to Ci chodzi?

> Dokładnie o to :-) Tyle tylko, że ten serwis ma najbardziej banalną
> nawigację.

Bo to wiki.

> Gdy zagłębisz się w jakiś poziom to jedynym sposobem powrotu jest "wstecz".

W dokuwiki? Nie, masz i you are here, to co wymieniłem wyżej i breadcrumbsy.

> W praktyce - np. w sklepach internetowych zazwyczaj tak nie jest i nawet z
> poziomu końcowego ogniwa łańcucha (np. karty katalogowej produktu) da się
> przejść do innych sekcji / produktów. Wtedy sprawy się mocno komplikują.

Na tym polega dobra nawigacja.

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

do góry