Jak wszyscy wiemy, URL w swoim oryginalnym kształcie, zaprojektowanym tak:
http://example.com/jakis/z/naszych/katalogow/plik?parametr1=wartosc1¶metr2=wartosc2#czesc_dokumentu
nie wygląda zbyt miło. Od jakiegoś czasu panuje trend, aby korzystać z URLów o wiele bardziej dla nas użytecznych:
http://example.com/akcja/wartosc1/wartosc2#czesc_dokumentu
To, jak sprawić, aby drugi URL znaczył (dla serwera) to samo, co pierwszy, to sprawa techniczna i tutaj jej nie wyjaśnię (proszę nieco pogooglać pod hasłem przyjazny url, przyjazny uri or mod rewrite).
To, co chciałbym omówić, to: jaki dokładnie schemat URLów jest najlepszy dla Każdego Użytkownika?
Ale po co to?
Tak, możesz nadal używać pierwszego rodzaju URLów. Sprawiać, by Twoi goście byli zdezorientowani dzięki wyświetlaniu dziwnego ciągu znaków w paskach adresu ich przeglądarek.Zmuszać ich do zwiedzenia całej strony, kiedy szukają czegoś, co widzieli już na niej wczesniej, ale nie widzą tego w historii w swojej przeglądarce. Chcieć, aby używali wolnych, głęboko zaszytych wbudowanych w stronę wyszukiwarek, które prawie na pewno nie są stworzone do przeszukiwania Twojej witryny tak, jakby tego chcieli. Nieważne.
Pamiętaj drogi webmasterze/programisto, że jesteś odpowiedzialny za to, jak łatwo korzysta się z Twojego dzieła (a może się to przekładać mniej lub bardziej bezpośrednio na pieniądze ;) ).
Ok, więc jak mogę sprawić, aby były bardziej użyteczne?
Tu jest problem. Jestem wielkim fanem ujednolicania niemal wszystkiego, więc, gdybym mógł, stworzyłbym Standard użytecznych URLów dla każdej strony.
Często używane rozwiązania to:
- styl “blogowy”:
http://example.com/rok/miesiac/dzien/tytul_artykululub styl “blogowy” #2:http://example.com/rok/miesiac/dzien/id_tytul_artykuluOczywiście, rok/miesiąc/dzień i tytul_artykulu są tu najważniejsze. W stylu “blogowym” #2, spójrz na część id, która nie przykuwa zbytnio uwagi użytkownika, a może być użyte do ujednoznacznienia sytuacji, kiedy np. permalink do artykułu uległ zmianie – ale id jest jakby “ważniejsze”, ma większy priorytet. Wtedy silnik może znaleźć artykuł przez id, być może powiadomić przeglądającego o fakcie zmiany permalinka itd. Zaleta istnienia daty w URLu to łatwiejsze znalezienie artykułu, jeśli wiemy kiedy został opublikowany, i – prawdopodobnie – kiedy pierwszy raz go przeczytaliśmy (jeśli śledzimy zmiany na stronie i czytamy wszystko, co się na niej ukazuje). A co jeśli nie? Powinna istnieć możliwość wyszukiwania artykułów nie tylko przez całą datę (rok/miesiąc/dzień), ale też przez sam rok lub rok/miesiąc. Byłoby dobrze, jeśli dałoby się przeglądać podając tylko określone dni miesiąca bez podawania miesięcy lub lat (być może zechcemy np. przejrzeć stronę biura podróży w poszukiwaniu wiadomości z lata lub wszystkich pierwszych dni miesiąca). Wtedy moglibyśmy wpisywać np. takie URLe: (pominąłem część z domeną i akcją) yyyy/07, gdzie yyyy oznacza rok – jakikolwiek rok, a 07 oznacza lipiec. - “hierarchiczny”:
http://example.com/kategoria/podkategoria/tytul_artykulu(gdzie oczywiście możemy użyć id przed tytul_artykulu z tego samego powodu, który opisałem wyżej. - “akcje”:
http://some-domain.com/moduł/akcja/parametr1/parametr2/, przykład podałem niżej.li>
Pominąłem schematy zawierające tylko id, ponieważ uważam je za wystarczająco nieprzyjazne, aby można było je odrzucić.
Inny aspekt problemu to sprawianie, aby – poza czytaniem – używać danego serwisu bardziej intuicyjnie. Np., jeśli chcemy napisać artykuł, komentarz, czy wysłać do kogoś wiadomość, czemu musimy szukać linków do tych akcji? Nie prościej byłoby wpisać http://example.com/uzytkownicy/nazwa_uzytkownika/napisz ?
To wszystko już właściwie jest dobrze znane i często stosowane. Wg mnie jednak taka praktyka powinna być:
- po pierwsze, upowszechniona (bo nadal wielu młodych webmasterów nie zdaje sobie sprawy z tego, że użytkownicy ich stron czasem patrzą na URLe)
- po drugie, ujednolicona – niesie to ze sobą wg mnie przynajmniej kilka korzyści, takich jak:
- uproszczone korzystanie z wielu serwisów
- użytkownik szybko dociera do tej części witryny, która go interesuje
- możliwość bardzo łatwego i efektywnego indeksowania
Odezwą się zapewne głosy, że trudno znaleźć złoty środek w tej sprawie, ale myślę, że jest to jak najbardziej możliwe.
Dla odwiedzających: pamiętajcie, że ja również chciałbym się rozwijać, a możecie to umożliwić komentując i przedstawiając swoje zastrzeżenia, ew. pomysły ;) Pozdrawiam.
- Informacje
- Wpis dodany 21.06.2007 o 23:51
- Kategoria: użyteczność
- Permalink
- Dodaj do
-
- Subskrybuj bloga
osobiscie we wszystkich nowych skryptach korzystam z “ladnych linkow” i to nie tylko dlatego, by user mogl wygodnie sie po niej poruszac – ma to ogroomne znaczenie dla silnikow wyszukiwarek, ktore dzieki dobremu adresowi strony indeksuja ja wyzej do tych slow kluczowych – mysle ze mogles tu nieco o tym napisac.
Z tego punktu widzenia najlepiej bedzie jezeli polaczylibysmy te metody – a wiec obowiazkowo w linku winien znalesc sie tytul artykulu – jako spacje najlepsze sa myslniki lub znaki podkreslenia. Bardzo dobrym pomyslem jest dodanie do linku nazwy kategorii, kombo w postaci kategorii glownej i kategorii podrzednej to juz calkiem miodzio. Akcja i moduł – to juz raczej wzgledy konstrukcyjne silnika strony, chociaz slowo news, artykul itede na pewno doda sens takiemu linkowi.
Apropo ujednolicenia – jest to niemozliwe – jest tylu roznych programistow o tylu roznych punktach widzenia, ze niemozliwym jest zebranie tego w jakas spojnosc. Dodatkowo ci slabsi nawet by sie nad tym nie zastanowili… Byłoby to z pewnoscia przydatne, lecz IMHO niewykonalne.
Dzięki za uzupełnienie. Niedługo jeszcze trochę o tym napiszę.
Jeżeli chodzi o konstrukcję moduł/akcja/kontroler/cokolwiek, to wg mnie jest to faktycznie przyjemne dla programisty, ale nie zawsze będzie sensowne w linku. Dlatego konieczna wydaje mi się warstwa, mocno konfigurowalna, która połączy ładny, użyteczny i czytelny link z wykonaniem określonej akcji.
Czy niemożliwe? Miałem na myśli oficjalny standard. Nie wiem, czy to naprawdę trafne porównanie, ale przychodzi mi na myśl RSS – on też jest ułożony w określony sposób, a wtedy spełnia swoje zadanie, mimo że jest tylko XML-em. A że nie każdy się do tego stosuje… tak samo nie każdy stosowałby się do takich ujednoliconych linków. A takowe poza wygodą i indeksowaniem mogłyby być np. agregowane w katalogach, wymieniane pomiędzy serwisami w różnych celach… wydaje mi się, że znalazłoby się wiele zastosowań.
owszem ale aplikacja aplikacji nierówna, wiec i cieczko byłoby oczekiwać od każdej spełniania tych samych norm.
Pierwszy taki krok z pewnością powinni stworzyć twórcy frameworków, dalej CMS-ów.
Dodatkowo trzeba jeszcze spojrzeć trzeźwym okiem – kto z tego by korzystał? Ty, ja, inni zainteresowani raczej programowaniem. Szarego użytkownika nie obchodzi takie coś, owszem ładny link lepiej wygląda, ale żeby tak jak to opisałeś, samemu wpisać sobie adres w pole adresu przeglądarki już się nie pokusi, mimo ujednoliconych standardów – bo zawsze łatwiej (przynajmniej dla jego ograniczonej wiedzy) jest to sobie wyklikać. My wiemy, że szybciej będzie jak wpiszemy, niż znajdziemy na stronie, ale dla niego jest to czarna magia.
Podobnie jest z linuxem – nie możemy pieprzyc głupot ze linux jest łatwy w obsłudze jak widnows – tam dużo rzeczy trzeba zrobić w konsoli i nigdy nie ma tak, że wszystko zrobi się menedżerami okienkowymi. Oczywiście zwykle w konsoli zrobimy to szybciej, ale przyzwyczajony do klikalności user tego nie zrozumie.
Prawdę prawicie.
Ja osobiście zapamiętuję “drogę” na serwisie – tutaj klikam, potem tutaj, potem tam i jestem.
Za cholerę nie zapamiętam takiego adresu.
Ale jeżeli taki url byłby prosty, logiczny, najlepiej we własnym języku (o tym też mogłem wspomnieć, tj. o wersjach językowych) to byłoby to dużo szybsze. Oczywiście nie dla wszystkich, tak jak nie wszyscy muszą lubić płatki owsiane.
Poza tym chciałem tutaj wejść na troszkę wyższy poziom abstrakcji, nie ograniczając się do tego co jest teraz, tzn. próbie utworzenia łatwych do zapamiętania adresów itd., ale jak dałoby się je wykorzystać przez jakieś większe silniki wyszukiwarek, może powstałoby coś alternatywnego dla nich, można by było pisać serwisy łatwiej agregujące dane z wielu innych serwisów etc.
w gruncie rzeczy przepisywanie url’u jest rzadko wykorzysytwane, bo z mojego doswiadczenia wiem, ze wiekszosc (a mowiac wiekszosc mam na mysli 9x% ludzi korzystajacych ze stron) nawet nie patrzy na ten pasek u gory, bo nie wie do czego sluzy, albo go po prostu nie interesuje, a jezeli nawet cos ciekawego jest to albo kopiuj wklej, albo dodanie do ulubionych. Przy robieniu cms’ow dosc czesto spotyka sie wymog wykorzystania mod_rewrite, ale sami zamawiajacy nie do konca rozumieja zastosowania tego (chyba… moze ktos im powiedzial, ale jak sie napisze jakis slabo wygladajacy sposob przepiasywania adresu, to nawet nic nie mowia(?) ). Wydaje mi sie, ze dla szerszego zastosowania mod_rewrite jest uzyteczny tylko dla wyszukiwarek, a to az tak wymagajace nie jest.
zalezy kto zamawia :> Ci, z którymi do tej pory pracowałem wiedzieli co wnosza przyjazne URL-e :F