wydział informatyki katedra organizacji i zarządzania

Transkrypt

WYDZIAŁ INFORMATYKI
KATEDRA ORGANIZACJI I ZARZĄDZANIA
Politechnika Szczecińska
Wydział Informatyki
PRACA DYPLOMOWA
PROJEKT OPARTEGO
O TECHNOLOGIĘ WWW
SERWISU INFORMACYJNEGO
DLA STUDENTÓW I PRACOWNIKÓW
WYDZIAŁU INFORMATYKI
POLITECHNIKI SZCZECIŃSKIEJ
autor:
Marcin Wichary
promotor:
dr hab. in. Antoni Wiliński, prof. PS
Szczecin, 2002
Oświadczam, e niniejsza praca została przygotowana samodzielnie.
Wszystkie dane, istotne myśli i sformułowania pochodzące z literatury są
opatrzone odpowiednimi przypisami.
Praca ta nie była w całości ani w części przez nikogo przedłoona do adnej
oceny, nie była równie publikowana.
............................
Spis treści
Wstęp
6
1.
World Wide Web
8
1.1. Początki i rozwój tandemu HTML/WWW
9
2.
1.2. Współczesne witryny internetowe
10
1.3. Intranetowe serwisy informacyjne
12
Serwisy informacyjne a uczelnie wysze
23
2.1. Aktualne zasoby informacyjne Wydziału Informatyki Politechniki
Szczecińskiej
24
2.2. Witryny innych uczelni
28
2.2.1.
Uczelnie w Polsce
29
2.2.2.
Uczelnie na świecie
33
2.3. Oddolne inicjatywy studentów
37
2.4. Zasadność tworzenia serwisu informacyjnego
39
2.4.1.
Badania przeprowadzone przez autora
40
2.4.2.
Badania przeprowadzone przez Massachusetts
Institute of Technology
49
2.4.3.
Wywiady z dydaktykami
51
2.4.4.
Zagroenia przy tworzeniu i eksploatacji serwisu
informacyjnego
53
Wnioski
54
2.4.5.
Spis treści 5
3.
Projekt serwisu informacyjnego
56
3.1. Załoenia
57
3.2. Przykład wykorzystania
59
3.3. Wymagania dotyczące interfejsu
60
3.4. Projekt poszczególnych elementów serwisu
70
3.4.1.
Uwierzytelnianie i autoryzacja
70
3.4.2.
Strona główna
72
3.4.3.
Plan zajęć
76
3.4.4.
Wiadomości
84
3.4.5.
Konto
89
3.4.6.
Fora dyskusyjne
91
3.4.7.
Informacje o wykładowcach
96
3.4.8.
Informacje o studentach
98
3.4.9.
Materiały dydaktyczne/naukowe
99
3.4.10. Profil
101
3.4.11. System pomocy
102
3.4.12. Inne
102
3.4.13. Administracja
106
3.5. Integracja z innymi usługami
107
3.6. Moliwości rozwoju
109
3.7. Wskazówki dotyczące implementacji
113
Podsumowanie
118
Aneks: Adresy witryn WWW wyszych uczelni w Polsce
119
Bibliografia
130
Spis rysunków
134
Spis tabel
135
Spis wykresów
135
Indeks
136
Wstęp
W ciągu ostatnich dziesięciu lat Internet z mało znaczącego zlepka dwóch
słów przeistoczył się w potęną machinerię, która na zawsze zmieniła oblicze
informatyki. Nie tylko informatyki zresztą – globalna pajęczyna zadomowiła się
ju w codzienności milionów zwykłych ludzi i w bardziej lub mniej widoczny
sposób wpisuje się w coraz więcej dziedzin ycia. Przyznać oczywiście naley,
i ta obecność nie zawsze bywa mile widziana, ale nie mona te zaprzeczyć,
e miriady pomysłów i technologii stworzonych na potrzeby Internetu lub
rozkwitłych wraz z nim pozwalają na tworzenie i wykorzystywanie rzeczy,
o których wcześniej mona było tylko marzyć. Zresztą nawet na tego kalibru
marzenia mogli sobie pozwolić nieliczni...
Wstęp 7
Dzisiaj, kiedy adres strony internetowej firmy często bywa równoznaczny z jej
nazwą, kiedy obycie w tajnikach Sieci nie jest luksusem lecz koniecznością,
kiedy nawet urządzenia AGD podłącza się do Internetu, nie mona sobie
pozwolić na tego Internetu zignorowanie. A jeeli mowa jest o Wydziale
Informatyki Politechniki Szczecińskiej, który kształci parę tysięcy studentów,
naleałoby oczekiwać czegoś więcej – wytyczania szlaku oraz uświadamiania
innym, jakie korzyści płyną z pełnego wykorzystania moliwości dawanych
przez Sieć.
Praca ta jest taką właśnie próbą. Przedstawiono w niej projekt opartego
o technologie internetowe serwisu informacyjnego dla studentów
i dydaktyków Wydziału Informatyki Politechniki Szczecińskiej właśnie.
Serwisu, który nie tylko ułatwiłby im codzienną pracę, ale i pokazał, jak
rozwiązania oraz technologie o jakich uczą (bądź są uczeni) mogą zostać
wykorzystane w praktyce.
Praca podzielona jest na trzy części. W pierwszej z nich przedstawiona została
krótka historia najwaniejszej części Internetu, jaką jest sieć World Wide Web,
podstawowe informacje o witrynach internetowych oraz generalne załoenia
dotyczące serwisów informacyjnych. Rozdział ma na celu przede wszystkim
zarysowanie technologii, na których będzie bazował projektowany serwis.
Drugi rozdział to opis i wnioski wysnute z odbytych badań: przede wszystkim
ankiety rozpisanej wśród studentów Wydziału Informatyki, ale take zblionej
ankiety przeprowadzonej przez informatyków z Massachusetts Institute
of Technology oraz innych badań wykonanych przez autora. Oprócz tego
przeanalizowana jest aktualna sytuacja dostępu do informacji na Wydziale
Informatyki Politechniki Szczecińskiej.
Trzeci, najwaniejszy rozdział, to przedstawienie projektu serwisu
w oparciu o technologie opisane w rozdziale pierwszym i wnioski wynikające
z rozdziału drugiego. W projekcie omówione zostaną kolejne sekcje serwisu,
ze szczególnym naciskiem na te uznane w świetle badań za najwaniejsze.
Rozdział oraz pracę zakończy przedstawienie moliwości rozwoju serwisu
oraz kilku wskazówek dotyczących jego implementacji.
Podczas tworzenia pracy oprócz wyników wspomnianych wyej badań oparto
się przede wszystkim o profesjonalne serwisy internetowe zajmujące się
problematyką WWW – głównie anglojęzyczne – a take fachową literaturę.
Wykorzystano równie wieloletnie doświadczenie autora na polu tworzenia
witryn WWW, a do opracowania pewnych danych posłuono się zapisami
systemów (logami) z istniejących serwisów. Całość ubarwiona została
cytatami z wypowiedzi studentów i dydaktyków.
1.
World Wide Web
Czy potrafilibyśmy wyobrazić sobie Internet bez WWW i przeglądarek?
Wydaje się to wątpliwe, chocia dziesięć lat temu pajęczyna witryn była
w powijakach i było ich zaledwie kilkadziesiąt. Przez tę dekadę sieć WWW
rozrosła się jednak na niespotykaną skalę i w tym rozdziale przedstawiony
zostanie zarys jej historii, a take opis technologii wykorzystywanych przy
tworzeniu witryn oraz najwaniejszych ich elementów, ze szczególnym
uwzględnieniem serwisów informacyjnych.
World Wide Web 9
1.1.
Początki i rozwój
tandemu HTML/WWW
HTML, czyli HyperText Markup Language, powstał w 1989 roku jako dzieło
Tima Bernersa-Lee, który stworzył go w powiązaniu z protokołem HTTP (ang.
HyperText Transfer Protocol) obsługi powstałej trzy lata później sieci WWW
(ang. World Wide Web) oraz sposobem adresowania stron, znanym jako URI
(ang. Universal Resource Identifier)1. Język HTML miał słu
słuyć
yć do opisywania
stron obecnych w sieci WWW – przede wszystkim powiązań między nimi
oraz podstawowego formatowania tekstu.
Naley zauwayć, i wiele osób utosamia WWW z Internetem, jednak
ten powstał ju w 1982 roku, a fazy jego projektowania i rozwoju sięgają
początku lat siedemdziesiątych2. Z początku wykorzystywany głównie
dla czterech najwaniejszych usług – poczty elektronicznej e-mail, grup
dyskusyjnych Usenet, protokołu przesyłu plików FTP oraz protokołu zdalnego
dostępu do komputerów telnet – oraz kilku pobocznych (część z których, jak
np. Gopher, jest ju praktycznie nie wykorzystywana), Internet szybko został
zdominowany przez WWW, a adres postaci www.domena.kraj zadomowił się
na dobre take w świadomości osób nie związanych z informatyką3.
Jeeli w połowie 1993 roku przesył danych związanych z oglądaniem stron
WWW stanowił jedynie pół procenta całościowego ruchu w Internecie, tak
ju dwa lata później udział ten wzrósł do 25%, przeganiając zawsze do tego
momentu najbardziej obciąający łącza protokół FTP4. Jednak był to dopiero
początek i sieć witryn rozrastała się jeszcze gwałtowniej w kolejnych latach
– i chocia tempo z czasem znacznie osłabło, tendencja ta trwa do dziś5.
Rozwojowi sieci towarzyszył take rozwój języka HTML – który z prostego
zestawu kilkunastu słów kluczowych ewoluował do skomplikowanego
języka obudowanego wieloma pobocznymi mechanizmami (część z których
będzie omówiona w rozdziale 1.2) – oraz przeglądarek, takich jak Netscape
czy Internet Explorer, które stały się bezsprzecznie jednymi z najczęściej
wykorzystywanych przez uytkowników programów.
HTML zyskał taką popularność z dwóch powodów. Po pierwsze, praktycznie
kada platforma komputerowa ma co najmniej jedną przeglądarkę obsługującą
1
2
3
4
5
Stephanos Piperoglou, Take a stand and understand the standard, sierpień 1999,
serwis WebReference (http://webreference.com/html/watch/standards), wstęp.
Tim Berners-Lee, Tim Berners-Lee – frequently asked questions, 2000, serwis W3C
(http://www.w3c.org/People/Berners-Lee/FAQ.html).
Harry M. Kriz, Internet services, maj 2000, serwis VirginiaTech
(http://learning.lib.vt.edu/wintcpip/services.html).
Matthew Gray, Web growth summary, 1996, serwis Massachusetts Institute of Technology
(http://www.mit.edu/people/mkgray/net/printable/web-growth-summary.html).
The size of the World Wide Web, październik 2001, serwis Pandia
(http://www.pandia.com/sw-2001/57-websize.html).
World Wide Web 10
ten format – a zazwyczaj jest ich kilka (nie tylko zresztą platforma
komputerowa w klasycznym rozumieniu tego słowa, gdy HTML wkroczył
ju take do m.in. telefonów komórkowych i telewizorów). aden inny język
czy format nie zyskał w Internecie takiej popularności, tak więc tworząc
serwis zgodny z HTML mamy pewność, i kady z odwiedzających będzie
mógł z niego bezproblemowo korzystać6.
Drugi powód jest jeszcze bardziej prozaiczny – w przeciwieństwie
do innych rozwiązań, HTML jest darmowy. Kady moe bez problemu znaleźć
odpowiednią dokumentację, przeczytać ją, stworzyć stronę WWW i umieścić
na serwerze bez dodatkowych opłat instalacyjnych czy licencyjnych7. HTML
jest zresztą w swojej podstawowej postaci bardzo prosty i opanowanie go
wymaga jedynie pewnej dozy wytrwałości.
Nic więc dziwnego, i o ile w początkach istnienia Sieci liczba witryn
mierzona była w setkach, aktualnie zblia się powoli do dziesięciu milionów8.
W Sieci znajdziemy witryny prywatne, domowe, akademickie i komercyjne,
przeszukiwarki, fora dyskusyjne, sklepy, tak swego czasu nagłośnione
portale i wortale... W momencie pisania tego tekstu na świecie jest ju
prawie 680 milionów uytkowników Internetu9 i dla większości WWW jest
jego najwaniejszym składnikiem (chocia naley zauwayć, i niezmiernie
popularny HTML wykroczył take poza Internet – budowane są w nim take
wewnętrzne witryny intranetowe lub wręcz samodzielne aplikacje10).
Współczesne witryny internetowe
1.2.
W miarę rozwoju sieci World Wide Web okazało się, i zwykły HTML nie
wystarcza do wielu zastosowań, przede wszystkim ze względu na swoją
statyczność – raz stworzona strona ma stały adres i stałą zawartość, co
w oczywisty sposób ogranicza twórców witryn WWW. Na przestrzeni lat
powstało więc wiele rozwiązań, które miały zaradzić tym ograniczeniom.
JavaScript, skryptowy język programowania, pojawił się w 1995 roku (jeszcze
pod nazwą LiveScript) w drugiej wersji przeglądarki Netscape Navigator.
Został opracowany przez twórców przeglądarki, Netscape Communications
Corp. oraz firmę Sun Microsystems, które wyszły z C++, ukierunkowując
go jednak jeszcze bardziej w stronę języka w pełni obiektowego. Począwszy
od wersji 3.0, równie Internet Explorer obsługuje ten język. JavaScript to
język interpretowany wykonywany przez przeglądarkę po stronie klienta11,
6
7
8
9
10
Oczywiście biorąc pod uwagę ciągłe problemy z ustaleniem standardu HTML jako takiego.
Stephanos Piperoglou, Take a stand..., op. cit., str. 4.
The size of the World Wide Web, op. cit.
Evaluating the size of the Internet, kwiecień 2002, serwis Telcordia Technologies
(http://www.netsizer.com).
Introduction to HTML Applications (HTAs), kwiecień 2002, serwis Microsoft
(http://msdn.microsoft.com/workshop/author/hta/overview/htaoverview.asp).
World Wide Web 11
najczęściej wkomponowany bezpośrednio w kod HTML i słuący m.in.
do manipulowania zawartością strony ju po tym, kiedy zostanie ściągnięta
z serwera i wczytana przez przeglądarkę. Takie działanie określa się take
akronimem DHTML (Dynamic HTML).
Z kolei powstałe nieco wcześniej CGI (ang. Common Gateway Interface)
to określenie programów uruchamianych z poziomu serwera, które
w odpowiedzi na zapytanie przeglądarki zamiast skierować ją do odpowiedniej
strony HTML, generują ją w czasie rzeczywistym. Technologia oryginalnie
stworzona z myślą o obsłudze formularzy,12 jest dzisiaj wykorzystywana
w duo szerszym zakresie, przede wszystkim wszędzie tam, gdzie
prezentowany serwis WWW ma być dynamiczny, czyli jego zawartość
powinna się zmieniać w zaleności od dnia (a nawet godziny), upodobań
oglądającego czy innych parametrów.
Skrypt CGI, który moe być napisany w dowolnym języku obsługiwanym
przez serwer, ma za zadanie wygenerowanie strony HTML, której oczekuje
uytkownik (a właściwie jego przeglądarka). Siłą skryptów CGI jest ich
interakcja z otoczeniem – mona im przekazywać parametry działania za
pomocą formularzy bądź odpowiednio sformatowanego adresu URL13, dostają
one równie szereg danych o kliencie i serwerze przekazywanych za pomocą
zmiennych środowiskowych.
Z początku do pisania skryptów CGI wykorzystywano „klasyczne” języki
programowania, takie jak C czy C++ (a nawet BASIC), jednak naturalną
koleją rzeczy powstały i języki „dedykowane”. Z początku wielką popularność
zyskał sobie Perl, obiektowy język niejako zaadaptowany do potrzeb CGI
w 1995 roku14, będący swoistym połączeniem C, BASIC-a i paru uniksowych
języków skryptowych.
Ostatnio jednak bez wątpienia popularniejszy jest język PHP (PHP: Hypertext
Preprocessor), w marcu 2002 roku będąc ju zainstalowanym na ponad
1,1 milionie serwerów internetowych15. Do jego wielkiej popularności
przyczyniły się m.in.:
dua ilość wbudowanych funkcji ułatwiających pisanie skryptów CGI
(które w innych językach trzeba tworzyć samodzielnie lub instalować
w postaci zewnętrznych bibliotek),
składnia przypominająca C, jednak duo mniej restrykcyjna,
11
12
13
14
15
Nie naley go mylić z językiem Java, por. Java vs. JavaScript, 2002,
serwis First Step Communications
(http://www.firststep.com.au/education/solid_ground/javadiff.html).
Historię CGI, a take dokładną specyfikację mona znaleźć na stronie W3C
(http://www.w3.org/CGI).
Ang. Universal Resource Locator – w szczególności adres internetowy postaci
http://www.domena.kraj/katalog/strona?parametry.
Elaine Ashton, Perl timeline, kwiecień 2002, serwis Perl Mongers
(http://history.perl.org/PerlTimeline.html).
PHP usage stats, marzec 2002, serwis PHP.net (http://www.php.net/usage.php).
World Wide Web 12
zintegrowanie języka z samym kodem HTML,
brak konieczności kadorazowej kompilacji kodu po jego zmianie,
funkcje ułatwiające współpracę z rónorakimi bazami danych (przede
wszystkim MySQL)16.
Zaradzono take odwiecznemu problemowi będącego podstawą WWW
protokołu HTTP – jego swoistej „incydentalności”. Zasada działania protokołu
jest prosta: klient nawiązuje połączenie z serwerem, przesyła zapytanie,
odbiera dane, po czym zamyka połączenie. Kada kolejna strona, a nawet
kady kolejny obrazek na tej stronie to nowe, niezalene połączenie. Klient nie
utrzymuje stałego kontaktu z serwerem, przez co praktycznie bardzo trudne
jest zidentyfikowanie jednej konkretnej osoby. Jednak dzięki mechanizmowi
ciasteczek (ang. cookies)17 i/lub identyfikatorów sesji zapamiętywanych na
serwerze dało się zniwelować i tę niedogodność, bez której nie mona byłoby
nawet marzyć np. o sklepach internetowych.
Na statyczność innego rodzaju – wizualną – remedium okazała się technologia
Macromedia Flash18, uznana wprawdzie przez wielu webmasterów za
kontrowersyjną, umoliwiająca jednak bez wątpienia tworzenie płynnych
i szybko wczytujących się animacji, prezentacji oraz ilustracji i obsługiwana
ju przez praktycznie wszystkie przeglądarki.
Zresztą i sam HTML doczekał się następcy – to XML, język opisu dokumentów
zawierających uporządkowane strukturalnie informacje, zdobywający ostatnio
duą popularność, głównie dzięki dwóm inicjatywom: .NET komputerowego
giganta Microsoftu19 oraz Semantic Web twórcy WWW, Tima Bernersa-Lee20.
Podobnie jak HTML, XML wywodzi się z SGML, jednak XML umoliwia
obejście wielu ograniczeń i usterek nękających jego poprzednika21.
Oczywiście to tylko wycinek tego, czym stała się sieć WWW dekadę od jej
powstania. Do tego dochodzą streaming audio i video, web services, VRML, Java,
aplikacje HTA i parędziesiąt innych mniej lub bardziej rozpowszechnionych
technologii, wykraczających ju jednak poza ramy tej pracy.
Intranetowe serwisy informacyjne
1.3.
Z wielością stosowanych technologii idzie w parze rónorodność spotykanych
w sieci witryn. Krótka nawet wędrówka po Sieci moe uświadomić, i strony
WWW bywają tak róne, jak to tylko moliwe – porównanie malutkiej strony
stworzonej przez początkującego internautę z ogromnym, profesjonalnym
16
17
18
19
Why PHP?, marzec 2002, serwis Zend (http://www.zend.com/why-php.php).
David Whalen, The unofficial cookie FAQ, maj 1999, serwis Cookiecentral.com
(http://www.cookiecentral.com/faq).
Jedyna komercyjna z opisywanych tu technologii, zresztą jedna z wielu pokrewnych firmy
Macromedia, por. http://www.macromedia.com.
Microsoft .NET, kwiecień 2002, serwis Microsoft (http://www.microsoft.com/net).
World Wide Web 13
portalem daje duo do myślenia, a przecie to tylko jeden przykład.
Poniewa w tej pracy zostanie opisany projekt konkretnego rodzaju witryny –
intranetowego serwisu informacyjnego – w kolejnych rozdziałach konieczne
będzie skupienie się przede wszystkim na wyróniających go cechach.
1.3.1.
Klasyfikacja witryn
Istniejące w Sieci witryny (strony) WWW mona podzielić ze względu
na wiele kryteriów. Pierwszym z nich będzie zawartość witryny i mona tu
wyrónić następujące rodzaje:
witryny informacyjne (np. artykuły, portale, katalogi),
witryny biznesowe (np. prezentacja oferty, aukcje),
witryny komercyjne (np. sprzeda produktów, sklepy internetowe),
witryny „socjalne” (np. fora dyskusyjne).
Witryny moemy take podzielić ze względu na jednostkę zakładającą
i opiekującą się stroną. Wyróniamy tu:
witryny organizacji,
witryny edukacyjne,
witryny rządowe,
witryny firm komercyjnych,
witryny prywatne (domowe)22.
Ze względu na dostęp do informacji witryny moemy podzielić na:
witryny ogólnodostępne,
witryny „ukryte” (których obecność jest rozgłaszana tylko w ściśle
określonych kręgach osób),
witryny intranetowe (do których dostęp mają jedynie członkowie danej
organizacji23),
witryny ekstranetowe (jak witryny intranetowe, jednak częściowo
udostępniane wybranym firmom zewnętrznym, np. partnerom
biznesowym24).
20
21
22
23
24
Semantic Web, maj 2002, serwis W3C (http://www.w3.org/2001/sw).
Simon St. Laurent, Why XML?, kwiecień 2002, serwis Simon St. Laurent
(http://www.simonstl.com/articles/whyxml.htm).
Mona zauwayć, i klasyfikacja ta dość dokładnie odpowiada schematowi podziału domen
pierwszego rzędu – poszczególnym kategoriom przyporządkowane są domeny: .org, .edu,
.gov oraz .com (witryny prywatne mona znaleźć w kadej z ww. domen).
Internets and intranets, luty 2002, serwis Consumer Protection Board
(http://www.consumer.state.ny.us/clahm/internet.htm).
Extranet, kwiecień 2002, serwis Webopedia.com
(http://www.pcwebopaedia.com/TERM/e/extranet.html).
World Wide Web 14
Strony WWW moemy take dzielić ze względu na wielkość („wizytówki”,
małe strony, due serwisy), stosowane technologie (np. HTML, XML,
Flash) oraz rodzaj zawartości (statyczna, dynamiczna), a take wiele innych
kryteriów. Oczywiście przynaleność do kadej z opisanych kategorii wiąe
się z czasem zupełnie odmiennymi załoeniami dotyczącymi struktury,
wyglądu oraz informacji zawartych w danej witrynie.
1.3.2.
Podstawowe załoenia
W niniejszej pracy opisany zostanie projekt intranetowego serwisu
informacyjnego, prowadzonego przez jednostkę edukacyjną (Wydział
Informatyki Politechniki Szczecińskiej). Moemy przyporządkować go do
kadej z trzech głównych kategorii wymienionych wyej. Będzie to:
witryna informacyjna – zawierająca dane przydatne studentom
i dydaktykom Wydziału Informatyki,
witryna edukacyjna – co w naturalny sposób wynika z umieszczenia jej na
serwerze Politechniki Szczecińskiej,
witryna intranetowa – dostęp do niej mają mieć jedynie studenci
i dydaktycy uczelni.
W kolejnych rozdziałach zostaną omówione podstawowe załoenia wynikające
z przyporządkowania witryny do tych właśnie kategorii, natomiast bardziej
uszczegółowione wytyczne przedstawione zostaną w rozdziale 3.1.
1.3.3.
Zawartość
Jakie informacje powinny być zawarte w intranetowym serwisie
informacyjnym? Nie ma na to uniwersalnej recepty – wszystko zaley od
jednostki, w której wdraa się taki serwis, od tego, czego się po nim oczekuje
i od ułatwień i korzyści, jakie ma przynosić.
Dla przykładu, w firmie będącej dostawcą usług internetowych najwaniejsza
będzie lista podłączonych do wewnętrznej sieci urządzeń wraz z moliwością
ich konfiguracji i reakcji na awarie, lista klientów wraz z podstawowymi
informacjami o nich, a take dostęp do rónorakiej dokumentacji. Jak łatwo
mona się domyślić, w przypadku np. gazety czy wydawnictwa, oczekiwania
co do informacji w serwisie będą zupełnie inne.
Wspólne dla większości serwisów intranetowych pozostają platformy do
komunikacji i przesyłania informacji między uytkownikami serwisu. Jest to
niezmiernie wana część serwisu, do projektowania której naley przyłoyć
duą wagę, gdy będzie miała ona ogromny wpływ na jego przydatność.
Podobnie jest z podsystemem dotyczącym przechowywania informacji
o rónorakich wydarzeniach, które miały, mają, bądź będą miały miejsce.
Naley wziąć take pod uwagę, i o ile część z informacji moe być ju
przechowywana i przekazywana przy uyciu komputerów (stron WWW,
WWW
World Wide Web 15
poczty e-mail), to czasami wcią wykorzystywane są bardziej tradycyjne
metody (papierowe okólniki, tablice ogłoszeń, zebrania itd.). Konieczne jest
dokładne zastanowienie się, które z nich i w jakiej kolejności powinny być
zebrane w serwisie informacyjnym oraz w jaki sposób ze sobą powiązane.
Badaniom rodzaju przechowywanych informacji w Wydziale Informatyki
Politechniki Szczecińskiej oraz oczekiwaniom studentów oraz pracowników
co do serwisu będzie poświęcony cały drugi rozdział tej pracy.
1.3.4.
Interfejs
Czym jest interfejs? Według jednej z definicji jest to „styk umoliwiający
porozumienie się dwóch niezalenych systemów”25. Tymi systemami mogą
być np. dwa urządzenia lub, jak w tym wypadku, system komputerowy
z jednej strony, a obsługujący go człowiek z drugiej.
W przypadku stron internetowych interfejs pełni równie waną rolę, jak
zawartość strony. Nawet niezmiernie interesujące materiały nie będą miały
najmniejszego znaczenia w witrynie, której interfejs jest nieczytelny bądź
trudny w obsłudze i vice versa – nawet świetny interfejs nie zrekompensuje
ubogiej zawartości strony.
Interfejs nie powinien być sprawdzianem inteligencji dla odwiedzających
witrynę. Kady jego element powinien słuyć komunikacji człowieka
z komputerem, powinien być jak najłatwiejszy w uyciu, jak najbardziej
intuicyjny w obsłudze i jak najszybszy do opanowania.
W bardzo ogólnym załoeniu na interfejs strony WWW składają się26:
wygląd i styl witryny,
sposób poruszania się w obrębie witryny,
struktura witryny,
proporcje między tekstem a grafiką.
Oczywiście przy projektowaniu interfejsu naley wziąć pod uwagę wszystkie
te podstawowe załoenia, o których była mowa w poprzednich rozdziałach.
Interfejs powinien być dostosowany do:
rodzaju strony – naturalnym jest, i w przypadku prywatnej strony
domowej wymagania dotyczące interfejsu są duo mniej restrykcyjne
ni dla strony firmowej, którą mogą np. odwiedzać klienci bądź przyszli
klienci firmy,
profilu osób odwiedzających witrynę – dla przykładu, strona
dla komputerowych fachowców moe stosować duo bardziej
25
26
Interface, maj 1996, serwis The Free On-line Dictionary of Computing
(http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=interface).
Thea Partridge, What is an interface?, 2001, serwis Techbabes
(http://www.techbabes.com/WebTech/Interface/whatis.html).
World Wide Web 16
zaawansowane mechanizmy ni, dla przykładu, witryna dla emerytów
i rencistów,
przewidywanego
rodzaju
osprzętu
wykorzystywanego
przez
odwiedzających – jeśli np. wiadomo, i odwiedzający mają raczej starsze
komputery, naley przystosować witrynę do odpowiednich wersji
przeglądarek; podobnie projektant witryny, która ma być oglądana przy
uyciu telewizorów WebTV, musi wziąć pod uwagę pewne ograniczenia tej
platformy,
rodzaju łącza z Internetem – jeeli, dla przykładu, uytkownicy korzystają
z wolnych modemów, naley ograniczyć ilość grafiki do minimum,
poniewa w przeciwnym wypadku transfer strony z serwera na komputer
odwiedzającego będzie bardzo wolny, a w rezultacie strona stanie się
bezuyteczna.
Dla przykładu, nawet w przypadku jednej kategorii – dostępu do informacji –
istnieje dua ilość rónic pomiędzy witrynami internetowymi a intranetowymi,
które naley wziąć pod uwagę w przypadku projektowania interfejsu27:
rónice pomiędzy osobami odwiedzającymi witrynę – odwiedzający
serwis intranetowy to zazwyczaj pracownicy firmy, którzy wiedzą o jej
wewnętrznych mechanizmach dość duo, strona internetowa natomiast
przeznaczona jest raczej dla klientów, którzy wiedzą o firmie mało i tak
naprawdę niewiele ich to obchodzi,
rónice pomiędzy zadaniami – intranet jest wykorzystywany do
codziennej pracy w firmie, natomiast strona internetowa słuy głównie do
informowania o produktach,
rónice w ilości informacji – typowo na stronie intranetowej znajduje się
od 10 do 100 razy więcej dokumentów ni w publicznym serwisie internetowym.
rónice w szybkości łącz i konfiguracji komputerów – dostęp do serwisu intranetowego cechuje się zazwyczaj duo większą szybkością (lokalna sieć), ponadto informacje o zastosowanej bazie sprzętowej są duo
dokładniejsze, stąd i względy zgodności odgrywają mniejszą rolę.
Równie i inne kryteria (witryna informacyjna, witryna edukacyjna) niosą ze
sobą pewne wytyczne dotyczące interfejsu – bardziej konkretnie zostaną one
omówione w rozdziale 3.3, natomiast tutaj zostaną jeszcze poruszone dwie
bardzo istotne rzeczy.
Pierwszą z nich są spójność i jednolitość interfejsu. Te same elementy
interfejsu powinny wyglądać podobnie i odpowiadać za te same funkcje
w obrębie całej witryny28. Podobnie naley myśleć w szerszym kontekście
27
28
Jakob Nielsen, The difference between intranet and Internet design, wrzesień 1997, serwis
useit.com (http://www.useit.com/alertbox/9709b.html).
Jeffrey Zeldman, Where am I? Navigation and interface, kwiecień 2002, serwis
WebReference (http://www.webreference.com/authoring/design/talent/chap3/1), str. 4.
World Wide Web 17
– jeśli od początków istnienia WWW podkreślony tekst oznacza odnośnik, na
którym mona kliknąć, zmiana tej konwencji (nawet w imię kreatywności)
pociągnie za sobą najprawdopodobniej tylko zagubienie odwiedzających
witrynę.
Drugim wanym elementem serwisu jest nawigacja. Serwis WWW jest
zbiorem wielu dokumentów (stron) i niezmiernie wany jest sposób ich
wzajemnego powiązania ze sobą. Odwiedzający zawsze powinien dokładnie
wiedzieć, w którym miejscu serwisu się znajduje i w jaki sposób moe
dotrzeć do innych jego fragmentów – szczególnie tych powiązanych
z informacjami, jakie aktualnie ogląda. W tym celu naley skupić się na jak
najlepszym zaprojektowaniu takich elementów jak:
menu nawigacyjnego,
uporządkowanej i moliwej do wyświetlenia hierarchii serwisu (zwanej
take mapą serwisu),
mechanizmu wyszukiwania informacji w serwisie na podstawie rónych
kryteriów.
Naley przy tym pamiętać o „zasadzie trzech kliknięć” – wszystkie wane
informacje powinny być dostępne nie dalej ni o trzy kliknięcia od głównej
strony serwisu, w przeciwnym wypadku statystyczny uytkownik uzna, i
informacja jest najprawdopodobniej niedostępna29 – oraz o wykorzystaniu
moliwości dawanych przez WWW, w tym szczególnie przez język opisu
HTML. Jak z samego rozwinięcia akronimu wynika, jedną z waniejszych
cech języka HTML jest jego hipertekstowość, tj. moliwość tworzenia
wzajemnych powiązań pomiędzy poszczególnymi stronami. To dzięki tej
właściwości WWW wyewoluowało w kierunku kolekcji niesamowitej ilości
stron, w duej części ze sobą powiązanych.
Nie naley więc zapominać o korzystaniu z dobrodziejstw hipertekstu tam,
gdzie tylko to moliwe. Twórcy witryn często o tym zapominają, znakomicie
utrudniając swobodne zwiedzanie ich dzieł i upodabniając je do klasycznych
materiałów tekstowych30. Oczywiście, naley stosować umiar i zdrowy
rozsądek – nikt nie spodziewa się, e kliknięcie na c z y m k o l w i e k
powinno przynosić jakiś rezultat. Odwiedzający stronę powinien spodziewać
się, co stanie się, jeśli skorzysta z danego odnośnika i, co równie wane,
witryna powinna reagować zawsze tak samo. Dla przykładu: jeśli na jednej
z podstron kliknięcie na nazwisku danej osoby przenosi do informacji o jej
danych, na wszystkich innych podstronach klikanie na nazwiskach powinno
29
30
Jeffrey Zeldman, Taking your talent to the Web, kwiecień 2002, serwis WebReference
(http://www.webreference.com/authoring/design/talent/chap3/2), str. 3.
Sztandarowym przykładem wydają się tu być podstrony „what’s new”, gdzie przedstawiana
jest lista nowości na stronie, jednak bez adnych odnośników i aby je zobaczyć, naley
naszukać się korzystając ze standardowego menu nawigacyjnego. Podobnie
na stronie WWW Wydziału Informatyki umieszczona jest informacja „Plan zajęć na
http://plan.wi.ps.pl”, jednak adresu nie zamieniono w odnośnik, co zmusza odwiedzających
do ręcznego przekopiowania go lub przepisania.
World Wide Web 18
dać taki sam rezultat; naley równie zadbać o to, aby w miarę rozsądku
wszystkie nazwiska na wszystkich podstronach zamienione zostały w takie
właśnie odnośniki. W tym wypadku uytkownik szybko przyswoi sobie tę
przydatną funkcję naszej witryny.
Mając powysze na uwadze, trzeba take pamiętać o tym, i odnośniki
powinny mieć znaczenie same w sobie – naley unikać syndromu „kliknij
tutaj”, tzn. tworzenia dodatkowych zdań czy pól po to jedynie, aby wyposayć
je w odnośniki31.
Niepoprawne odnośniki
Poprawne odnośniki
Masz zajęcia z programowania
obiektowego w czwartek o godzinie
12:00 w sali 315.
Masz zajęcia z programowania
obiektowego w czwartek o godzinie
12:00 w sali 315.
Informacje o przedmiocie znajdziesz
tutaj.
tutaj
Tabela 1
Syndrom
„kliknij tutaj”
Aby uzyskać listę wszystkich zajęć
w czwartek kliknij tutaj
tutaj.
W powyszej tabeli w pierwszym przykładzie widać, i aby stworzyć odnośniki
dopisano dwa dodatkowe zdania, które zmniejszają czytelność tekstu,
a ponadto określenie „tutaj” nie powie nic odwiedzającemu na pierwszy
rzut oka i będzie on musiał stracić duo czasu, aby umiejscowić odnośnik
w odpowiednim kontekście.
Z kolei drugi przykład realizuje esencję hipertekstu – jest to po prostu zwykły
tekst, którego najbardziej znaczące w danym kontekście słowa prowadzą
do dalszych informacji. Internauta odruchowo skojarzy fakt, i odnośnik
zaprowadzi go do podstrony z informacjami odpowiednio o przedmiocie
i dniu. Dodatkowo naley oczywiście zapewnić dokładną wskazówkę, co
przyniesie kliknięcie na danym odnośniku – najlepszym do tego celu wydają
się być etykietki (ang. tooltips), pojawiające się po najechaniu na odnośnik
i poczekaniu ok. sekundy32.
Zachowanie organizational identity
1.3.4.1.
Amerykańskie pojęcia corporate identity, brand identity oraz organizational
identity odnoszą się do wizerunku: korporacji, marki czy organizacji.
Wizerunku, który budowany jest poprzez wiele mniej lub bardziej znaczących
działań – takich jak na przykład określenie tosamości, wizji, celu oraz misji
firmy33.
31
32
33
Eric Tilton, Composing good HTML, lipiec 1998, serwis ology.org
(http://www.ology.org/tilt/cgh).
Mona je zrealizować dzięki parametrowi title w HTML.
Stephanie Autrey i Scott Harper, Discovering organizational identity, 2001, serwis
link&learn (http://www.linkageinc.com/newsletter/archives/od/reliant_1.shtml).
World Wide Web 19
W znakomitej większości wykraczają one poza zakres tej pracy, nie naley
jednak zapominać o tym, i ogólnodostępna witryna WWW oraz witryna
intranetowa są równie widoczną częścią wizerunku, podobnie jak np. wystrój
budynku, „papierowe” materiały (chociaby reklamowe lub papier firmowy),
wizytówki, tabliczki na drzwiach, prezentacje... Wszystko to powinno składać
się w jedną, spójną, harmonijną całość, przedstawiającą firmę lub organizację
w jak najlepszym świetle.
Jednym z przykładów
moe być witryna firmy
Apple, umieszczona pod
adresem www.apple.com.
Korzysta ona z interfejsu
będącego wiernym odwzorowaniem interfejsu
Aqua, znanego z systemu
operacyjnego Mac OS
X, instalowanego na
większości Macintoshy
(flagowych komputerów
firmy). Stosowane są
dwie czcionki: Lucida Grande z tego właśnie systemu oraz Apple Garamond
(od wielu lat wykorzystywana przez Apple do opisu produktów34).
Rysunek 1
Witryna firmy Apple
Innym przykładem będzie serwis Transport for London (www.transportforlondon.gov.uk) informujący odwiedzających o rónych moliwościach
transportu wewnątrz stolicy Wielkiej Brytanii. Całość ponownie umiejętnie
korzysta z symboli i skojarzeń utrwalonych w pamięci londyńczyków od ponad
wieku. Podobnie jak w oznakowaniach przystanków autobusowych i stacji
metra, na plakatach czy w materiałach reklamowych, take i tutaj stosowane
jest charakterystyczne
okrągłe logo (zwane przez
Anglików
bullseye35)
oraz kojarząca się jednoznacznie z miejskim
transportem
czcionka
36
New Johnston .
Dzięki takim właśnie jak
powysze zastosowaniom
budowane jest przywiązanie internautów do
firmy, a odwiedzający
witrynę uytkownicy jej
Rysunek 2
Witryna
Transport for London
34
35
36
Apple Garamond, maj 2002, serwis MacParc
(http://www.macparc.ch/nostalgia/applegaramond).
David Lawrence, A logo for London, Capital Transport Publishing, Londyn 2000.
Justin Howes, Johnston’s underground type, Capital Transport Publishing, Londyn 2000.
World Wide Web 20
produktów czy usług czują się „jak w domu”. Naley o tym pamiętać nie
tylko w przypadku firm komercyjnych, ale take i innych organizacji, w tym
wyszych uczelni.
To tylko jeden z wielu podobnych komentarzy
dotyczących
aktualnej
witryny
WWW
37
Wydziału Informatyki . Chocia ze względów
kolorystyka rodem
bezpieczeństwa i poufności informacji wygląd
ze stron z pirackim
witryny intranetowej powinien rónić się w
oprogramowaniem.”
znaczący sposób od publicznej strony WWW
(po to, aby odwiedzający zawsze wiedzieli,
z której witryny aktualnie korzystają38), to jednak konieczne jest zapewnienie
pewnej spójności obu witryn, a take innych wizualnych materiałów uczelni
(np. ulotki reklamowe, tabliczki na drzwiach). Niestety, aktualnie na stronie
nie jest wyrónione nawet nowe logo wydziału39.
„Beznadziejna
1.3.4.2.
Poprawność językowa
Językiem kadego komputera, począwszy od ponadpięćdziesięcioletniego
ju ENIAC-a, są… cyfry. Uściślając: dwie cyfry. Oczywiście jest to daleko
posunięte uproszczenie, ale porównując obszerne woluminy słowników
któregokolwiek ze współczesnych języków ze słownikiem składającym się
z dwóch zaledwie pozycji – zera i jedynki – nie sposób sobie wyobrazić pary
bardziej od siebie odległych światów.
I tak jest w istocie – oba te światy są oddalone i pewna, czasami dość znaczna
część pracy programistów ma na celu stworzenie pomostu umoliwiającego
uytkownikowi zrozumienie komputera, a komputerowi poprawne
odszyfrowanie intencji uytkownika40. Od momentu upowszechnienia się
monitorów komputerowych nie jest ju oczywiście problemem wyświetlenie
poądanej informacji relatywnie małym kosztem, jednak w parze
z dostępnością informacji nie idzie jej przystępność i w Internecie wcią
mona napotkać mniej lub bardziej powane błędy lub uproszczenia
językowe.
Przyczyny takiego stanu rzeczy są rónorakie. Pierwszym z nich wydaje
się fakt, i zaawansowane strony internetowe połączone z bazami
danych tworzą zazwyczaj programiści – osoby od lat stykający się ze
środowiskami pracy, w których poprawność językowa ustępuje miejsca
efektywności. Języki programowania z językami naturalnymi nie mają zbyt
wiele wspólnego, a składnia poleceń niektórych popularnych systemów
37
38
39
40
Komentarze były częścią ankiety przeprowadzonej wśród studentów, która zostanie
omówiona dokładniej w rozdziale 2.4.1.1.
Jakob Nielsen, The difference between intranet and Internet design, op. cit.
Więcej uwag na temat witryny znajdzie się w rozdziale 2.1.3.
Jak złoone moe to być zagadnienie świadczy przykład, i wśród naukowców pokutuje
przekonanie, e stworzenie systemu mogącego rozumieć i syntetyzować mowę ludzką
wymagałoby stworzenia systemu o złooności odpowiadającej... ludzkiemu mózgowi.
World Wide Web 21
operacyjnych przypomina bardziej wzory matematyczne ni ludzką mowę.
Dla informatyków operowanie dziesiątkami akronimów, skrótów językowych,
a i wręcz powstających w rónych kręgach nowych argonowych określeń41
jest czymś naturalnym i trudno się temu dziwić, jednak oczywistym jest
te, i część z nawyków wyniesionych przy styczności z komputerami
przedostaje się do „świata rzeczywistego”. Mimo powtarzanych od wielu
lat apeli purystów językowych42, jest to element projektowania witryn
internetowych, do którego przykłada się relatywnie małą wagę. A to powany
błąd, gdy większość witryn z oczywistych względów nie będzie oglądana
jedynie przez informatyków.
Co więcej, mechaniczna precyzja stoi często w sprzeczności z płynnymi
zasadami języka naturalnego. Spójrzmy na poniszą tabelkę:
Tabela 2
Zapis mechaniczny
a zapis naturalny
Zapis mechaniczny
Zapis naturalny
0 dzień/dni temu
dzisiaj
1 dzień/dni temu
wczoraj
2 dzień/dni temu
przedwczoraj
3 dzień/dni temu
w środę
4 dzień/dni temu
we wtorek
5 dzień/dni temu
w poniedziałek
6 dzień/dni temu
w niedzielę
7 dzień/dni temu
tydzień temu
8 dzień/dni temu
w poprzedni piątek
9 dzień/dni temu
w poprzedni czwartek
10 dzień/dni temu
w poprzednią środę
11 dzień/dni temu
w poprzedni wtorek
Nietrudno zauwayć, i zapis mechaniczny – chocia ewidentnie łatwiejszy
do zaimplementowania – jest dla człowieka duo mniej czytelny ni
odpowiadające mu określenie „naturalne”. Nietrudno równie domyślić
się, i wysiłek włoony w odpowiednie przygotowanie witryny pod kątem
językowym zaprocentuje później w postaci duo łatwiejszego i szybszego
przyswojenia informacji przez odwiedzające tę witrynę osoby. I vice versa –
wprawdzie mechaniczne zakodowanie niektórych rzeczy moe się wydawać
duo łatwiejsze, jednak kosztem czasu tych osób, które potem będą musiały
41
42
O czym znakomicie na przykładzie języka angielskiego opowiada leksykon Erica S.
Raymonda The New Hacker’s Dictionary, dostępny take pod adresem internetowym
http://tuxedo.org/~esr/jargon.
e mona tu wspomnieć chociaby o niegdysiejszej znakomitej rubryce Stanisława Marka
Królaka Terminator terminologiczny lub próbie stworzenia przez Kubę Tatarkiewicza
uniwersalnego słownika angielsko-polskiego w czasach wchodzenia Macintoshy na polski
rynek.
World Wide Web 22
te informacje mniej lub bardziej świadomie „przełoyć” sobie na język
ludzki.
Kolejnym czynnikiem jest wszechobecny w technologiach komputerowych
język angielski, ze swojej natury duo łatwiejszy od polskiego, którego
chociaby mnogość przypadków przyczynia się do wielu problemów przy
pisaniu algorytmów mających dawać w rezultacie poprawny językowo
tekst. Pierwszym z brzegu przykładem moe być witryna NSS Integrator
(http://www.nss.pl), na której moemy odnaleźć takie błędy czy
uproszczenia językowe, jak:
„Na naszych stronach: 1 gość(ci) i 0 zarejestrowany(ch) uytkownik(ów)”,
„Sobota: grudzień 01, g.22:17:09”,
„głosów: 1”,
czy „24 razy przeczytany”,
wynikające przede wszystkim z bezkrytycznego przełoenia anglojęzycznych
komunikatów na język polski.
Kolejnym problemem – nie tak ju moe powszechnym jak niegdyś, ale wcią
widocznym – są problemy związane z polskimi znakami diakrytycznymi,
czyli potocznymi „ogonkami”. Wprawdzie upowszechnienie się w polskim
Internecie standardu ISO 8859-2 nie daje ju twórcom witryn adnych
wymówek, jednak czasami wcią łatwiej lub wygodniej jest polskie znaki po
prostu... pominąć43, a i często przy przeglądaniu witryn widać ewidentne
problemy z konwersją pomiędzy alternatywnymi stronami kodowymi
Windows 1250 i ISO 8859-2.
Warto jest mieć te wszystkie uwagi na myśli podczas projektowania
witryny internetowej, szczególnie jeśli jest ona tworzona dynamicznie.
Zaprojektowanie odpowiednich, uwzględniających wszystkie niuanse polskiej
gramatyki algorytmów moe być praco- i czasochłonne, ale znakomicie
ułatwi i uprzyjemni korzystanie z naszej witryny wszystkim odwiedzającym.
Szczególne znaczenie powinno mieć to właśnie w serwisach informacyjnych,
w których duą rolę odgrywa jak najszybszy i najbardziej naturalny dostęp do
zgromadzonych w serwisie danych.
43
Co daje czasem tak nieczytelne i absurdalne przykłady, jak legendarne ju wśród polskich
informatyków „zadanie kata na lace”.
2.
Serwisy informacyjne
a uczelnie wysze
Czy zastosowanie serwisów informacyjnych na uczelniach wyszych ma
jakikolwiek sens? Ten rozdział pracy będzie próbą odpowiedzi na to pytanie.
Na początku zanalizowane zostaną dotychczasowe zasoby informacyjne
Wydziału Informatyki Politechniki Szczecińskiej – począwszy od tradycyjnych
a po elektroniczne. Następnie opisane zostaną wyselekcjonowane witryny
internetowe polskich i zagranicznych uczelni, wraz z tymi stworzonymi przez
samych studentów. Rozdział zamknie omówienie badań (przeprowadzonych
z jednej strony przez autora, a z drugiej przez amerykańską uczelnię
Massachusetts Institute of Technology), oraz wyciągnięte z ich wyników
wnioski.
Serwisy informacyjne a uczelnie wysze 24
2.1.
Aktualne zasoby informacyjne
Wydziału Informatyki Politechniki
Szczecińskiej
Nietrudno wyobrazić sobie, i w placówce, w której ok. 300 dydaktyków
kształci dziewięciokrotnie więcej studentów poprzez skomplikowaną i wcią
zmieniającą się siatkę rónorakich zajęć, obieg informacji jest kluczowy dla
jej funkcjonowania. W poniszych rozdziałach zostaną omówione istniejące
mechanizmy dbające o przepływ informacji.
2.1.1.
Tablice i gabloty informacyjne
Podstawowym źródłem informacji dla studentów Wydziału Informatyki jest
zestaw tablic i gablot, rozmieszczonych przede wszystkim na parterze budynku
(tablice z informacjami oraz ogłoszeniami,
plan zajęć, regulaminy, podziały na grupy,
„Moje wraenia są takie,
informacje dla kandydatów na studia, tablica
e nie jest to Wydział
ogłoszeń dla studentów, wyniki zaliczeń)
oraz na pierwszym i drugim piętrze przy Informatyki, a co najwyej
odpowiednich
katedrach
(informacje
Wydział Tablic Przy
o osobach zatrudnionych w katedrach,
Odpowiednich Salach.”
ogłoszenia, wyniki zaliczeń). Chocia jest
to rozwiązanie obecne chyba we wszystkich
uczelniach w Polsce i mające za sobą całe dziesięciolecia tradycji, nietrudno
wyobrazić sobie wiele problemów oraz niedogodności wynikających z jego
stosowania.
Przede wszystkim, aby przeczytać informacje znajdujące się na tablicy i być
z nimi na bieąco, naley z oczywistych względów pojawiać się osobiście
w budynku Wydziału. O ile wydaje się to naturalne dla studentów studiów
dziennych pierwszych lat, naley pamiętać, i studenci zaoczni są na uczelni
tylko w soboty i niedziele, a i na przykład podczas dziewiątego semestru
studiów magisterskich dziennych zajęcia mogą się odbywać jedynie raz na
tydzień. W takim wypadku kontakt studentów z informacjami dziekanatu
i władz wydziału jest ograniczony, i na porządku dziennym zdarzają się na
przykład takie sytuacje, i studenci o odwołanych zajęciach dowiadują się...
dopiero piętnaście minut przed godziną ich planowanego rozpoczęcia.
Oprócz tego zdarzają się sytuacje, i w zalewie informacji dla studentów
wszystkich lat i kierunków te istotne po prostu giną – wprawdzie najwaniejsze
ogłoszenia (takie jak np. indywidualne wezwania do dziekanatu w trybie
natychmiastowym) są specjalnie wyróniane, ale te i trudno wymagać od
kadego, aby codziennie śledził dokładnie wszystkie pojawiające się na
tablicy kartki.
Sytuację komplikuje te fakt, i potrzebne niekiedy informacje wieszane są
na tablicach odpowiednich katedr i poszukiwanie wyników zaliczenia czy
kolokwium w sytuacji, gdy studenci nie są pewni tego w jakiej katedrze
zatrudniony jest dany wykładowca, wymaga obejścia wszystkich pięter
budynku. Nie wspominając o tym, i na uczelni nie istnieje ju jeden
zbiorczy, ogólnodostępny spis zatrudnionych osób z podziałem na katedry
i zajmowane gabinety – w poszukiwaniu danych konkretnego dydaktyka
znów trzeba odbyć podró przez większą część Wydziału.
Oczywiście tablice informacyjne nie są jedynym źródłem informacji dla
studentów. Pomocny moe być oczywiście dziekanat, jednak jest on
dostępny tylko w określonych godzinach (10:00-13:00) i w określone dni
(z wyłączeniem czwartku). Ponadto ilość osób czekających na przyjęcie do
dziekanatu czasami44 bywa tak dua, i praktycznie uniemoliwia w miarę
szybkie i sprawne zdobycie informacji.
Naturalnym jest te, e studenci wymieniają informacje między sobą, jednak
tutaj musi równie zaistnieć swoiste „budowanie druyny” (co przekłada
się na wymianę personaliów, numerów telefonów oraz adresów poczty
e-mail), tak więc na początku studiów czy tych semestrów, w których zmienia
się konfiguracja grup,
ta metoda dzielenia się
informacjami – ju zresztą
i w samych załoeniach
dość zawodna – moe być
mało skuteczna.
Nadmienić naley te, i
od 2001 roku w holu na
parterze zainstalowana
jest równie elektroniczna tablica informacyjna (patrz rysunek
3), na której czasami
wyświetlane są wprawdzie
wane informacje (niestety, w nader skromnych ilościach, brakuje nawet
chociaby elektronicznego zegarka), aczkolwiek często na tablicy widnieje
tylko adres uczelni oraz kierunki studiów, co – jak mona przypuszczać – nie
jest zbytnio przydatne w codziennym yciu studentów45.
Rysunek 3
Elektroniczna tablica
informacyjna
na Wydziale
Informatyki
2.1.2.
Plan zajęć
Osobna uwaga naley się planowi zajęć, mającemu chyba największy wpływ
na rytm ycia zarówno studentów, jak i wykładowców. Plan zajęć jest
tradycyjnie wywieszany w ogólnodostępnym miejscu w gablotach na parterze
44
Szczególnie w newralgicznych okresach, takich jak składanie indeksów i podań o przyjęcie
na studia.
i podzielony najpierw na kierunki oraz rodzaje studiów, a następnie na
poszczególne lata. Oprócz tego identyczne wydruki są do nabycia w zakładzie
kserograficznym na terenie Wydziału, co jest sporym udogodnieniem,
uwalniającym studentów
od konieczności przepisywania szczegółów interesujących ich zajęć.
Niestety, nowy plan jest
podzielony tylko na lata
– student otrzymuje listę
zajęć dla wszystkich grup
ze swojego roku i dopiero
musi sobie podkreślić
albo w inny sposób
zaznaczyć jedynie swoje
zajęcia. Często zdarza się
więc, i studenci i tak wypisują waną jedynie dla nich część planu na osobnej,
bardziej poręcznej kartce. Dodatkową motywacją dla takiego postępowania
jest fakt, i niejednokrotnie zdarzało się ju zasłanianie części planu zajęć
na tablicy przez ogłoszenia – a umieszczenie go w gablocie uniemoliwia
„podejrzenie” zasłoniętych kartek.
Rysunek 4
Plan zajęć
dla studentów
Trzeba te przyznać, i w stosunku do poprzedniego wyglądu ogólnodostępnego
planu, tworzonego jeszcze ręcznie, ten nowy ma kilka wad. Przede wszystkim
tamten był nieco bardziej czytelny – kolorowy (barwami były odznaczane
róne typy zajęć46) i z podziałem na grupy – aczkolwiek z drugiej strony
sposób przedstawiania dydaktyków za pomocą inicjałów i odpowiedniej
legendy a prosił się o zmianę i był przyczyną wielu nieporozumień.
2.1.3.
Istniejąca witryna WWW
Sytuacji nie poprawia witryna WWW Wydziału Informatyki, umieszczona pod
adresem http://www.wi.ps.pl. Z wymienionych w poprzednich akapitach
informacji dostępne są tam niestety jedynie plan zajęć i dane katedr – a i do
obu mona mieć wiele zastrzeeń.
Plan zajęć, mimo i bazuje na tych samych danych co jego drukowana
i umieszczana na tablicach informacyjnych edycja, jest duo mniej czytelny.
W ramach roku poszczególne zajęcia są posortowane w bardzo nienaturalny
sposób i odnalezienie przedmiotów swojej grupy sprowadza się do przejrzenia
listy przedmiotów dla całego roku, a następnie – bo do tego momentu procedura
wygląda to tak samo, jak dla planu papierowego – dodatkowego poukładania
ich w kolejności chronologicznej. Cała procedura jest mudna i właściwie
45
46
Dla porównania, na identycznej tablicy w budynku Colegium Maximum Akademii Rolniczej
w Poznaniu znajduje się stale m.in. rozkład jazdy pobliskich linii tramwajowych.
Takie jak ćwiczenia, laboratoria czy wykłady.
niepotrzebna, gdy trudno w jakikolwiek sposób racjonalnie uzasadnić taki
układ planu. Potwierdzają to wyniki przeprowadzonej wśród studentów ankiety,
w
której
krytyka
skupiła się w duej
mierze właśnie na mało
intuicyjnym
układzie
zajęć na stronie WWW47.
Studenci
gremialnie
narzekali
take
na
brak tak podstawowej
informacji, jak rodzaj
tygodnia
–
parzysty
lub nieparzysty (która
nie jest tak oczywista,
szczególnie w okresie
poświątecznym), a drobiazgiem ju w takiej sytuacji wydają się ewidentne
kłopoty z kodowaniem polskich liter.
Rysunek 5
Witryna Wydziału
Informatyki
Politechniki
Szczecińskiej
Informacje o katedrach i zatrudnionym w nich personelu są równie dalekie
od ideału. Naley zacząć od faktu, i dwie z dziewięciu katedr w ogóle nie
mają swoich podstron, tak więc zdobycie jakichkolwiek wiadomości o nich
z poziomu WWW jest po prostu niemoliwe. Strony jedynie t r z e c h
katedr zawierają kompletny spis pracowników ze wszystkimi potrzebnymi
danymi (imię i nazwisko, stopień naukowy, e-mail, telefon słubowy), jednak
w adnej nie udało się znaleźć terminów konsultacji dla studentów.
Wobec braku jakiegokolwiek mechanizmu wyszukiwania informacji na
stronach Wydziału Informatyki, znalezienie szukanego pracownika sprowadza
się do komputerowej odmiany „chodzenia po piętrach”, czyli ręcznego
odwiedzenia witryny kadej z katedr.
Oprócz tego na stronie Wydziału z interesujących studentów opcji znajdziemy
dość niewiele: dostęp do poczty e-mail poprzez WWW oraz elektroniczną
tablicę ogłoszeń (mało zresztą aktywną).
2.1.4.
Sieć komputerowa Wydziału
Do komunikacji między studentami i/lub dydaktykami słuy równie
oczywiście obecna na Wydziale sieć komputerowa, podłączona do Internetu.
Kady student i kady pracownik ma domyślnie załoone adresy e-mailowe
postaci [email protected] oraz [email protected] (gdzie login jest
zazwyczaj złoeniem pierwszej litery imienia i nazwiska), tak więc nie
jest problemem dotarcie do osoby, jeeli znamy jej personalia. Niestety, to
ostatnie załoenie wcale nie jest tak oczywiste. Tak, jak wspomniano ju
wcześniej, proces zaznajamiania się osób z tej samej grupy lub roku moe
czasem potrwać dość długo. W jeszcze gorszej sytuacji są wykładowcy,
47
Wyniki ankiety omówione są w rozdziale 2.4.1.1.
którzy czasem w kadym kolejnym semestrze uczą zupełnie nowe grupy,
i o personaliach studentów dowiadują się zazwyczaj z… listy sporządzanej
przez nich samych.
Oprócz tego kady rok ma własny katalog w lokalnym systemie plików
(nazywany potocznie od jego angielskiej nazwy „komonem”), do którego
dostęp mają tylko wszyscy studenci z tego roku – co jest i zaletą (wiadomo,
gdzie szukać ewentualnych materiałów), jak i wadą (wspólny katalog dzieli
niekiedy ponad 120 studentów, co w oczywisty sposób wprowadza bałagan
poprzez obecność wielu plików interesujących tylko wąskie grupy osób).
Niestety, podobnego mechanizmu nie ma w przypadku materiałów
udostępnianych studentom przez wykładowców i istnieje tu dość dua
dowolność – część dydaktyków umieszcza materiały na stronach katedry,
część udostępnia je poprzez anonimową usługę FTP Wydziału, część korzysta
z własnych stron domowych, natomiast jeszcze inni po prostu przegrywają
je na dyskietkę lub płytę CD i proszą studentów o dalsze rozprowadzenie
materiałów.
2.1.5.
Wnioski
Jak widać z powyszego opisu źródeł dostępu do informacji, daleko im jeszcze
do doskonałości. Osobiste doświadczenia autora tej pracy, podobnie jak
chyba większości innych studentów, mogą świadczyć za konkretne przykłady.
Z waniejszych mona wymienić: trudności z dotarciem do prowadzącego
zajęcia i do reszty studentów z tej samej grupy, trudności z przekazaniem
podległym studentom informacji o zakresie zaliczenia, wielokrotne przyjazdy
na odwołane uprzednio zajęcia, brak widocznej informacji o badaniach
lekarskich, oraz niejasny podział na grupy w przypadku seminarium
dyplomowego (co zaowocowało dwukrotną nieobecnością).
Dość skromnie są równie wykorzystywane bogate moliwości informowania
studentów i pracowników poprzez pocztę e-mail czy WWW, szczególnie
jeśli weźmiemy pod uwagę, i chodzi tu o Wydział Informatyki, tak więc
stopień i częstotliwość korzystania z komputerów przez studentów będą tu
w naturalny sposób większe ni w przypadku innych wydziałów48.
2.2.
Witryny innych uczelni
Kolejnym etapem zbierania informacji było sprawdzenie, czy omawiane
w pierwszym rozdziale serwisy informacyjne nie są ju wykorzystywane
w innych uczelniach wyszych. Z oczywistych względów większy nacisk
połoono na uczelnie znajdujące się w naszym kraju, nie zapominając jednak
o uczelniach zagranicznych – szczególnie z USA – w przypadku których
istniało większe prawdopodobieństwo korzystania z serwisu informacyjnego
przeznaczonego dla studentów i pracowników, wynikające przede wszystkim z
większej „świadomości informatycznej” tamtejszych osób (oraz instytucji)49.
2.2.1.
Uczelnie w Polsce
W celu zorientowania się co do istnienia i ewentualnej rozległości
implementacji serwisów informacyjnych w polskich uczelniach,
odwiedzono ponad 200 stron i rozesłano pocztą elektroniczną ponad
150 indywidualnych e-maili do webmasterów opiekujących się witrynami
wyszych uczelni w Polsce50 (oprócz uczelni wybrano take bezpośrednio
wydziały i instytuty powiązane z informatyką, wychodząc z załoenia, i
prawdopodobieństwo istnienia serwisów informacyjnych w placówkach tego
typu jest największe). W listach pytano o to, czy w uczelni lub placówce
istnieje serwis informacyjny dostępny poprzez WWW, przeznaczony dla
studentów i pracowników, zawierający informacje o planie zajęć, stanie
płatności, ocenach, wydarzeniach itp., przy czym zaznaczano, i chodzi
o wydzielony system, być moe nawet dostępny jedynie w wewnętrznej sieci
uczelni, z uwierzytelnianiem za pomocą loginu/hasła lub alternatywnych
metod (biometria51 lub karty chipowe). W razie obecności ser wisu zadawano
pytania o zakres jego funkcjonowania oraz korzyści i problemy związane
z jego wprowadzaniem oraz wykorzystywaniem.
Odzew był duo większy
od spodziewanego, gdy
na list odpowiedziało
ponad 50 osób, czyli
ok.
jednej
trzeciej
zapytanych52. Znakomita
większość respondentów
(82%)
odpowiedziała,
i w ich uczelni nie
ma takiego serwisu,
bądź – w przypadku
jednej czwartej z nich
– jest on planowany bądź
w trakcie realizacji.
W przypadku pozostałych odpowiedzi serwis informacyjny, w mniej lub
bardziej rozbudowanej formie, istnieje. Te proporcje mona dokładniej
zaobserwować na wykresie 1.
Wykres 1
Obecność serwisów
informacyjnych na
wyszych uczelniach
w Polsce
Większość z osób, które odpowiedziały twierdząco, podało wiele przydatnych
uwag co do funkcjonowania serwisów i ich wdraania. Zostaną one
48
49
50
51
Szczegółowe dane potwierdzające tę obserwację są zamieszczone w rozdziale 2.4.1.
Według raportu Computer Industry Almanac Inc. dostępnego na stronie
http://www.c-i-a.com/pr0701.htm, w USA jest a ponadtrzykrotnie więcej komputerów
ni w drugiej pod tym względem Japonii.
Wykaz uczelni i odpowiadających im adresów jest załączony w aneksie.
Biometria – wykorzystywanie wrodzonych cech fizycznych i zachowania do identyfikacji
poszczególnych osób, za: Rafał Piecuch, Biometria – Technika identyfikacji człowieka,
marzec 2002, serwer republika.pl (http://biometria.republika.pl).
przytoczone w dalszej części pracy w odpowiednim kontekście (szczególnie
w rozdziale 2.4.4), poniej natomiast zostaną wymienione i opisane
najbardziej interesujące serwisy wśród polskich uczelni.
Wysza Szkoła Biznesu – National-Louis University
2.2.1.1.
Jednym z najlepszych istniejących w Polsce serwisów informacyjnych moe
się najprawdopodobniej pochwalić Wysza Szkoła Biznesu – National-Louis
University w Nowym Sączu. Najprawdopodobniej, gdy niestety autorzy
serwisu nie zechcieli odpowiedzieć na wysłany do nich list, tak więc jedynie
z załączonego na witrynie zrzutu ekranowego mona wywnioskować, i
w wewnętrznym serwisie informacyjnym przeznaczonym dla studentów
i pracowników znajdują się m.in:
aktualności z ycia uczelni,
wykłady i inne materiały dydaktyczne przeznaczone dla studentów,
dostęp online do zasobów biblioteki,
forum dyskusyjne dla całej społeczności uczelni,
dostęp do poczty elektronicznej,
tablica ogłoszeń.
Oprócz tego w ogólnodostępnej strefie znajdziemy take wykaz
pracowników i katedr
oraz szczegółowe plany całego kampusu.
Całość utrzymana jest
w stonowanej i eleganckiej oprawie graficznej. Strona znajduje
się
pod
adresem
http://intranet.wsbnlu.edu.pl,
istnieje
take
dedykowana
byłym
absolwentom
uczelni sekcja http://
alumni.wsb-nlu.edu.pl.
Rysunek 6
Wirtualna Szkoła
Wyszej Szkoły
Biznesu w Nowym
Sączu
52
A nawet więcej, biorąc pod uwagę, i ponad 30 listów zostało z rónych powodów
zwróconych przez serwer pocztowy jako niedoręczone.
2.2.1.2.
Rysunek 7
System SUSZI
Wyszej Szkoły
Zarządzania
i Bankowości
w Krakowie
2.2.1.3.
Rysunek 8
Student Info – witryna
WETiI Politechniki
Gdańskiej
Wysza Szkoła Zarządzania i Bankowości w Krakowie
Systemem o wdzięcznym akronimie SUSZI (Studencki Uczelniany
System Zarządzania Informacją), umieszczonym pod adresem
https://suszi.wszib.edu.pl moe pochwalić się Wysza Szkoła Zarządzania
i Bankowości w Krakowie. Niestety, witryny tej nie mona oglądać nie
będąc studentem bądź
pracownikiem uczelni,
jednak
z
informacji
udostępnionych
przez
webmastera wynika, i
w systemie znajdują się
informacje o ocenach
z egzaminów, kolokwiów
i zaliczeń, informacje
nt. złoonych podań,
komunikaty uczelni, informacje o konsultacjach i inne wiadomości od wykładowców, a take wiele
innych informacji „niemal zupełnie odciąających dziekanat i rektorat od
studenckich spraw”. System według korzystających z niego osób naprawdę
ułatwia ycie studentom i władzom uczelni.
Wydział Elektroniki, Telekomunikacji i Informatyki
Politechniki Gdańskiej
Nieco innym systemem dysponuje Wydział Elektroniki, Telekomunikacji
i Informatyki Politechniki Gdańskiej. Umieszczona pod adresem
http://student.eti.pg.gda.pl, funkcjonująca od pół roku witryna Student
Info zorientowana jest przede wszystkim na zapisy na przedmioty obieralne
(z uwzględnieniem priorytetów oraz ograniczeń na liczbę osób) oraz informacje
o otrzymanych ocenach. Toczone są prace nad rozszerzeniem systemu
o informacje o strukturze wydziału, program studiów oraz plan zajęć, jednak
nawet w obecnej postaci
system okazuje się bardzo
skuteczny w ograniczaniu
niepotrzebnego
ruchu
w dziekanacie uczelni.
Niestety,
mona
by
mieć parę zastrzeeń do
nieco topornego i mało
czytelnego
interfejsu
zaproponowanego przez
twórców witryny.
2.2.1.4.
Polsko-Japońska Wysza Szkoła Technik Komputerowych
Polsko-Japońska Wysza Szkoła Technik Komputerowych udostępnia
dwa dynamiczne serwisy. Pierwszym z nich jest ogólnodostępny Serwer
Studencki, portal umieszczony w Internecie pod adresem http://www.studenci.pjwstk.edu.pl. Mona tam znaleźć:
swiee informacje dla studentów,
ogłoszenia Samorządu Studenckiego,
plany zajęć,
poradniki,
dostęp do serwera FTP z materiałami dydaktycznymi,
narzędzia i przydatne odnośniki.
Rysunek 9
Serwer studencki
PJWSTK
2.2.1.5.
Oprócz tego uczniowie i dydaktycy uczelni mają dostęp do Sekretu
– szyfrowanego serwisu
zawierającego
m.in.
moliwość składania oświadczeń o wniesionych
opłatach (i weryfikacji
stanu płatności) oraz
informacje o postępach w
nauce i przynaleności do
grup, a take wiadomości
istotne dla pracowników
dydaktycznych.
Wysza Szkoła Informatyki Stosowanej i Zarządzania
Wysza Szkoła Informatyki Stosowanej i Zarządzania w Warszawie oferuje
studentom i dydaktykom rozbudowany system Szkoła (https://dziekanat.wsisiz.edu.pl), umoliwiający m.in.:
zbieranie i przetwarzanie danych studentów
i rejestrację procesu
nauczania od momentu
rekrutacji a do uzyskania
dyplomu,
sprawdzenie
planu
zajęć przez studentów,
Rysunek 10
System Szkoła
Wyszej Szkoły
Informatyki
Stosowanej
i Zarządzania
sporządzanie umów,
rachunków i rozliczanie
prowadzących,
udostępnianie dokumentów ogólnych i dydaktycznych,
rozsyłanie grupowych powiadomień przez dziekanat i prowadzących,
rozliczanie finansowe studentów,
zgłaszanie problemów przez studentów.
W planach jest take rozszerzenie systemu o integrację z pocztą WWW,
tablicę ogłoszeń, wybór przedmiotów obieralnych.
2.2.1.6.
Rysunek 11
Wirtualna Uczelnia
Wyszej Szkoły
Informatyki
i Zarządzania
2.2.2.
Wysza Szkoła Informatyki i Zarządzania
Ostatnia z omówionych polskich uczelni, Wysza Szkoła Informatyki
i Zarządzania w Rzeszowie, umoliwia korzystanie z systemu Wirtualna
Uczelnia za pomocą
kiosków internetowych
znajdujących się na
terenie kampusu (alternatywnie jest on dostępny
pod adresem http://
www.wsiz.rzeszow.pl).
Uwierzytelnianie
następuje za pomocą
kart chipowych oraz
numeru albumu i hasła,
a w systemie znaleźć
mona informacje zarówno z dziekanatu (plan zajęć, prowadzący, oceny) jak
i z kwestury (płatności).
Uczelnie na świecie
Oprócz stron WWW krajowych uczelni odwiedzono kilkadziesiąt witryn
szkół wyszych spoza Polski (głównie z USA i Wielkiej Brytanii). Poniej
przedstawiono kilka tych, które z punktu widzenia zakresu i tematyki pracy
warte są uwagi.
2.2.2.1.
University of Washington
University of Washington w USA udostępnia studentom i pracownikom
wewnętrzną witrynę MyUW pod adresem http://myuw.washington.edu.
Na dość skromnej, lecz eleganckiej stronie znajdziemy przede wszystkim
wiadomości z ycia uniwersytetu i jego katedr/placówek (a take
z zewnętrznych agencji prasowych), wydarzenia, którymi yje kampus
i całe miasto oraz odnośniki do zewnętrznych stron i źródeł informacji
(w tym bardzo wygodnej i eleganckiej interaktywnej mapy). Oprócz tego
w zaleności od statusu zalogowanej osoby (student, wykładowca, pracownik,
dawny wychowanek uczelni53) moe być take dostępny plan zajęć, stan konta
i płatności oraz wyciąg
z ksiąki adresowej.
Do tego na stronie
znajduje się prognoza
pogody, bogate informacje o komunikacji
miejskiej i widoki z kamer
umiejscowionych
w kampusie, a take dość
szczegółowa
pomoc.
Wszystko oparte jest
o system uwierzytelniania (z dostępnym kontem gościa) i z moliwościami
personalizacji zawartości strony głównej.
Rysunek 12
MyUW – witryna
dla studentów
i pracowników
University of
Washington
Pracownicy mają take dostęp do finansowo-socjalnego serwisu ESS
((Employee Self-Service, https://www.washington.edu/user/ess/demo.cgi),
gdzie mogą dowiedzieć się m.in. o zarobkach, podatkach, ubezpieczeniach
i urlopach.
2.2.2.2.
University of California
Dość nieciekawa graficznie, jednak bardzo
rozbudowana pod innymi
względami jest strona
intranetowa
Uniwersytetu Kalifornijskiego
MyUCLA (http://my.ucla.edu). Po zalogowaniu
się jako student bądź
pracownik (jest te konto
dla gościa) do wglądu są
m.in.:
Rysunek 13
MyUCLA Portal –
witryna dla studentów
i pracowników
University of
California
plan zajęć (bardzo szczegółowy i dostępny take w klasycznej postaci
„siatki”),
zapisywanie się na zajęcia poprzez WWW,
listę umówionych spotkań (np. badań zdrowotnych),
kalendarz z moliwością dodawania własnych wydarzeń,
kalendarze rónych uniwersyteckich placówek,
ksiąkę adresową wszystkich zatrudnionych na uczelni osób oraz
studentów,
53
Ang. alumni.
podzielone na róne kategorie fora dyskusyjne,
chat oraz zdalne rozmowy z wieloma doradcami,
a nawet
moliwość bezpośredniego zakupu w uniwersyteckiej
potrzebnych w danym semestrze podręczników.
księgarni
Z drobniejszych rzeczy dostępne są take: poczta poprzez WWW (z ksiąką
adresową), e-kartki, mapy kampusu oraz rozbudowana pomoc.
2.2.2.3.
Rysunek 14
Portal my.harvard
dla studentów
i pracowników
University of Harvard
Harvard University
Portal my.harvard Uniwersytetu w Harwardzie (http://my.harvard.edu)
swój główny nacisk kładzie na informowanie
o uczelnianych wydarzeniach
i
akcjach
poprzez szeroki zestaw
konfigurowalnych
kalendarzy, do których
mona dopisywać równie
własne
wydarzenia.
Oprócz tego na stronie
znajdziemy
informacje
o komunikacji, pogodzie,
wynikach
sportowych
oraz posiłkach na terenie kampusu, a take wyciąg z uniwersyteckiej gazety.
Całość dostępna jest po zalogowaniu się i dopiero potem konfigurowalna,
jednak część informacji moe oglądać kady chętny.
2.2.2.4.
Stanford University
Rysunek 15
MyStanford – witryna
Uniwersytetu w
Stanford
Bardzo elegancka witryna Uniwersytetu w Stanford nazwana, zgodnie
z widoczną ju zapewne tendencją, MyStanford (http://my.stanford.edu),
daje dość ograniczony dostęp osobom spoza uczelni. Jednak na jedynej
dostępnej stronie mona zauwayć moliwość poszukiwania konkretnej
osoby na uczelni lub
przeszukania całych jej
zasobów internetowych,
kalendarz z zaznaczonymi
d z i s i e j s z y m i
wydarzeniami i spotkaniami54, nowości ze
świata i z uniwersytetu,
linki do wanych stron
oraz informacje o pogodzie i dostęp do poczty
internetowej. Dostępne są take do wglądu własne oceny, a witrynę mona
(w ograniczony sposób) dopasowywać do własnych wymagań.
2.2.2.5.
California Institute of Technology
Kolejną witryną, której
warto się przyjrzeć, jest
portal California Insitute
of Technology, dostępny
pod adresem http://
my.caltech.edu. System
nie przewiduje logowania
się, w zamian na początku
mamy wybór pięciu
rónych wersji portalu
(m.in. dla studentów
i pracowników), które
rónią się obecnością i ułoeniem rónych elementów serwisu. Wśród nich
znajdują się:
Rysunek 16
Portal dla studentów
i pracowników
Caltech
nowości i oświadczenia prasowe,
informacje o najwaniejszych projektach,
wydarzenia dziejące się w kampusie,
kalendarz,
wyszukiwanie osób zatrudnionych na uczelni i/lub studentów,
odnośniki do wielu uczelnianych bibliotek i dostęp online do ich
zasobów,
odnośniki do poszczególnych wydziałów i jednostek California Institute
of Technology,
odnośniki do wewnętrznych i zewnętrznych witryn (w tym do popularnych
wyszukiwarek).
Zwrócić uwagę naley te na dość skromny, lecz przejrzysty i utrzymany
w przyjemnych dla oka barwach interfejs.
University of Toronto
2.2.2.6.
Ostatnią przedstawioną bliej witryną będzie strona Uniwersytetu w Toronto,
którą mona znaleźć pod adresem http://my.utoronto.ca. Znajdują się na
niej głównie nowości i wydarzenia z wielu wydziałów i jednostek uczelni.
54
Uczelnia jest właśnie w trakcie tworzenia rozbudowanego, jednolitego,
międzywydziałowego systemu informowania o wydarzeniach, o czym mona przeczytać pod
adresem http://calendar.stanford.edu.
Mona wybrać kolejność
pojawiania się newsów,
a take zawęzić je do
jedynie tych wydziałów,
które są interesujące.
Z drobniejszych rzeczy
jest take zmieniający
się cytat dnia oraz
– po zalogowaniu się
– moliwość sprawdzenia
zawartość
skrzynki
Rysunek 17
Witryna
my.utoronto.ca
Uniwersytetu
w Toronto
pocztowej bezpośrednio z przeglądarki WWW.
2.3.
Oddolne inicjatywy studentów
W sytuacjach, gdy „oficjalna” witryna internetowa uczelni nie spełnia
pokładanych w niej oczekiwań, naturalnym wydaje się fakt, i czasami
zainteresowana grupa studentów sama tworzy własną witrynę, której
zadaniem będzie uzupełnienie istniejących braków. Wydaje się to być
widoczne szczególnie w przypadku studentów studiów zaocznych,
którzy spotykają się rzadziej i z oczywistych względów muszą zapewnić
sobie alternatywne metody komunikacji. W czasach, gdy dzięki gotowym
i bezpłatnym narzędziom55 stworzenie nawet dość bogatej w opcje witryny
i umieszczenie jej w Sieci nie jest ju problemem, takie rozwiązanie jest dość
kuszące – szczególnie, i studenci mogą tworzyć swoją stronę w zupełnym
oderwaniu od witryny uczelni, co pozwala na pełną swobodę zarówno jeśli
chodzi o jej wygląd, jak i zamieszczane treści.
Jednym z przykładów jest załoona przez studentów studiów zaocznych na
Wydziale Informatyki Politechniki Szczecińskiej witryna ELITA Exclusive Club
(http://elita.home.pl),
na której zwraca uwagę
przede wszystkim bardzo
czytelny plan zajęć,
przygotowany za pomocą
specjalnie stworzonego
o p r o g r a m o w a n i a 56.
Główną rolę odgrywa
strona z wiadomościami,
gdzie
pojawiają
się
informacje na temat
Rysunek 18
Elita Exclusive Club
55
56
Takim jak chociaby ultrapopularny język PHP i oparte na nim systemu do łatwego
tworzenia portali, np. PHP-Nuke (http://www.phpnuke.org).
Zresztą na podstawie danych pobieranych ze strony Wydziału Informatyki, przedstawiając
je tylko w duo bardziej przystępny i wygodny sposób.
terminów i wyników zaliczeń, a take rónorakie materiały konieczne
do ich zdania. Oprócz tego dostępne jest forum, ankieta i odnośniki do
najwaniejszych z punktu widzenia studenta serwisów.
Studenci
II
roku
informatyki tego samego
Wydziału
Informatyki
równie mają swoją
własną witrynę, nazwaną
Studenckim Systemem
Wymiany
Informacji
(adres to obwieszczenia.internetowe.pl).
Jest to nic innego, jak
księga gości, dopisywanie
się do której jest
ograniczone do osób mających załoone konta (w praktyce: osób z drugiego
roku Wydziału Informatyki). Wpisy to głównie informacje o zaliczeniach i ich
wynikach, materiałach do nauki oraz wane bieące obwieszczenia (spotkania,
zmiany w planie zajęć), a take incydentalne posty na inne tematy. Oddajmy
zresztą głos autorowi serwisu, Jakubowi Reiterowi:
Rysunek 19
Studencki System
Wymiany Informacji
– serwis II roku
informatyki
„Na początku pierwszego roku studiów przepływ informacji między studentami
Wydziału Informatyki wydawał mi się zdecydowanie niewystarczający.
Często tylko część studentów była poinformowana o odwołanych zajęciach
czy zaliczeniach. Postanowiłem zrobić to co potrafiłem, aby to zmienić.
A e potrafiłem akurat pisać skrypty server-side zrodził się w mej głowie
pomysł strony połączonej z listą mailingową, która byłaby wirtualną tablicą
ogłoszeniową, na którą obwieszczenia mogliby wysyłać studenci i wykładowcy.
Od samego początku zakładałem, e docelowo dostęp do serwisu ma mieć
całe WI. Oczywiście najbardziej zaleało mi na tym aby dostęp miał mój rok
(rocznik 2000, studia magisterskie), bo informacje dotyczące mojego roku
były mi zdecydowanie najbardziej potrzebne. Najpierw konta dostała moja
grupa (14) oraz pani dr Ignaczak i dr Lizak. Konto miała te nasza starościna,
która wysyłała sporo przydatnych informacji.”
Wpisy moe czytać kady zainteresowany, nawet nie posiadający konta.
Oczywiście trudno sobie wyobrazić korzystanie z systemu przez „całe WI”
(aktualnie nie istnieją adne sposoby filtrowania wyświetlanych informacji),
jednak w jego obecnej postaci wydaje się bardzo przydatny dla zamkniętej
grupki studentów57.
57
W lutym 2002 roku codziennie przybywało średnio a 1,5 wpisu.
Rysunek 20
Strona II roku
Informatyki
Politechniki
Poznańskiej
Tę witrynę, umieszczoną
pod adresem http:
//www.putinf.dhs.org,
nazwano
po
prostu
Stroną II roku Informatyki
Politechniki Poznańskiej.
Tutaj
równie
na
pierwszej stronie znajdziemy
informacje
o materiałach do zaliczeń
i wynikach tyche. Oprócz
tego zamieszczone są:
graficzny plan zajęć, lista studentów wraz z namiarami na nich (e-mail, strona
WWW), forum dyskusyjne, a take nieco stricte studenckich informacji – opisy
wykładowców i przedmiotów przez nich wykładanych, cytaty zasłyszane na
uczelni oraz... zdjęcia robione ukradkiem podczas zajęć.
Podobnych „nieoficjalnych” stron w polskim Internecie mona bez problemu
znaleźć co najmniej dwadzieścia, co pozwala przypuszczać, i jest ich duo
więcej (część moe być z oczywistych względów mało upubliczniona).
Przeglądając je wyraźnie mona zauwayć, i studentom zaley na szybkiej
i niekłopotliwej komunikacji w obrębie własnej grupy lub własnego roku,
w celu przekazywania sobie najwaniejszych informacji – o terminach
kolokwiów i zaliczeń, o ich wynikach, o odwołanych lub przełoonych
zajęciach, nawet o rozkładach jazdy PKP, i oczywiście o wszelakich
wydarzeniach „okołostudenckich”. Metody są róne, czasami zadziwiające
swoim stopniem zaawansowania, czasami – prostotą (jak np. po prostu
z d j ę c i a niektórych informacji z gablot umieszczone na Stronie studentów
informatyki, http://www.informa.gda.pl).
2.4.
Zasadność tworzenia serwisu
informacyjnego
Czy to, i a) pewna – niewielka – część polskich uczelni ma system
informacyjny lub jego zaląki, b) studenci sami tworzą strony spełniające
część zadań, które mogłyby być dostępne na stronie internetowej uczelni
i c) wiele uczelni w bardziej zinternetyzowanych krajach ma ju takie systemy
wystarczy, aby uzasadnić tworzenie takiego systemu na Wydziale Informatyki
Politechniki Szczecińskiej?
Wprawdzie mogą być to przesłanki, jednak naleałoby je poprzeć bardziej
konkretnymi badaniami, które zostaną opisane w poniszych rozdziałach
pracy.
2.4.1.
Badania przeprowadzone przez autora
W celu zorientowania się co do przydatności serwisu informacyjnego
i zebrania dodatkowych danych pomocnych (jeśli nie koniecznych) przy
jego ewentualnym tworzeniu, przeprowadzono dwa rodzaje badań: ankietę
(omówioną w rozdziale 2.4.1.1) oraz obserwację (rozdziały 2.4.1.22.4.1.4)58.
Ankieta wśród studentów Wydziału Informatyki
2.4.1.1.
Ankieta została przeprowadzona wśród studentów Wydziału Informatyki.
Pytania w niej zawarte dobrano tak, aby wyniki pozwoliły wyciągnąć jak
najwięcej przydatnych wniosków co do zasadności i ewentualnego kształtu
projektowanego systemu informacyjnego. Oto one:
„1.
Czy korzystasz z innego ni uczelniany komputera do łączenia się
z Internetem?
¡ tak
2.
Czy korzystasz z innego ni uczelniane konta e-mailowego?
¡ tak
3.
¡ nie
¡ nie
Z jakiej przeglądarki/przeglądarek korzystasz? (mona zaznaczyć kilka
odpowiedzi)
4.
5.
¨ Internet Explorer
¨ Netscape
¨ Mozilla
¨ Opera
¨ tekstowa (np. Links)
¨ inna (jaka?)
Jaką formę dyskusji preferujesz:
¡ e-mailowa lista dyskusyjna
¡ forum na WWW
¡ grupa dyskusyjna (news)
¡ nie mam zdania
Oceń przydatność aktualnej strony WWW Wydziału:
¡ mało przydatna
58
¡ średnio przydatna
¡ bardzo przydatna
E. Duliniec, Badania marketingowe w zarządzaniu przedsiębiorstwem, PWN, Warszawa
1999, str. 27.
6.
Oceń przydatność poniszych elementów, które wchodzą/mogłyby
wchodzić w skład strony WWW Wydziału Informatyki:
Plan zajęć
¡ mało przydatny
¡ średnio przydatny
¡ bardzo przydatny
Odwołane zajęcia/godziny rektorskie
¡ mało przydatne
¡ średnio przydatne
¡ bardzo przydatne
Informacje o terminach egzaminów/zaliczeń
¡ mało przydatne
¡ bardzo przydatne
Wyniki kolokwiów/zaliczeń/egzaminów
¡ mało przydatne
¡ bardzo przydatne
Informacje o wykładowcach (godziny przyjęć studentów, numery sal,
katedry)
¡ mało przydatne
¡ bardzo przydatne
Informacje o studentach (e-maile, strony WWW, numery ICQ i GaduGadu)
¡ mało przydatne
¡ bardzo przydatne
Listy dyskusyjne (m.in. dla studentów z tego samego roku/z tej samej
grupy)
¡ mało przydatne
¡ bardzo przydatne
Kalendarz (wydarzenia uczelniane i własne)
¡ mało przydatny
¡ bardzo przydatny
¡ średnio przydatna
¡ bardzo przydatna
Tablica ogłoszeń
¡ mało przydatna
Informacje o wypełnianiu indeksu i kart zaliczeniowych
¡ mało przydatne
¡ bardzo przydatne
Stan płatności (wpisy warunkowe, studia płatne)
¡ mało przydatny
¡ bardzo przydatny
Zastosowano przede wszystkim pytania alternatywne i wieloalternatywne59,
mając na uwadze wygodę ankietowanych z jednej strony, a precyzję wyników
z drugiej. Oprócz tych pytań poproszono o ewentualne luźne uwagi i sugestie
dotyczące strony WWW Wydziału Informatyki.
Anonimowa ankieta została umieszczona na stronie WWW pod łatwym
59
George E. Breen, Albert B. Blankenship, Badania marketingowe w twojej firmie, PWE,
Warszawa 1995, str. 186-187.
do zapamiętania adresem (http://www.wi.ps.pl/ankieta), a prośbę
o jej wypełnienie dopisano do informacji pojawiających przy logowaniu się
uytkowników do większości dostępnych na Wydziale systemów, a take
w informacjach na głównej witrynie Wydziału. Dodatkowo ankietę
w tradycyjnej papierowej wersji rozdano sposób wśród osób z grupy 541 na
piątym roku informatyki (był to swego rodzaju test kwestionariusza60).
W przeciągu tygodnia od umieszczenia ankiety na stronie do autora spłynęły
132 odpowiedzi61, a po tym czasie pojawiło się ich jeszcze prawie dwieście,
dając łączny wynik 314 wypełnionych ankiet. Wprawdzie jest to ok. 12%
studentów Wydziału Informatyki62, jednak naley mieć na uwadze fakt, i
wypełnienie ankiety zaleało tylko od dobrej woli pytanego (nie przewidziano
adnych nagród), który zresztą w natłoku zajęć mógł po prostu nie dotrzeć
do informacji o jej istnieniu. Ponadto czas trwania ankiety pozwolił wziąć
w niej udział studentom wszystkich rodzajów studiów na Wydziale, a ponad
300 osób to ju reprezentatywna próba pozwalająca na zignorowanie błędów
pomiaru i wyciągnięcie wiarygodnych wniosków.
Godny zauwaenia jest fakt, i 62 osoby (prawie jedna piąta ankietowanych)
zamieściły przy swoich ankietach komentarze, niekiedy bardzo obszerne,
które oprócz informacji przydatnych autorowi pracy (niekiedy zwracających
uwagę na problemy i tematy, które mogłyby inaczej zostać pominięte)
pozwoliły dowiedzieć się o wielu interesujących obserwacjach dotyczących
funkcjonowania strony WWW wydziału czy te wewnętrznej sieci
komputerowej63. Część z tych uwag jest zamieszczona w odpowiednich
rozdziałach tej pracy.
W pierwszym pytaniu studenci mieli odpowiedzieć, czy dostęp do Internetu
mają jedynie dzięki komputerom na Wydziale Informatyki. Wyniki prezentuje
wykres 2. Widać na nim, i a 89% studentów ma dostęp do Internetu take
poza Wydziałem. Jak
łatwo się domyślić, jest
to zasługa komputerów
w domu, w akademiku,
albo – na późniejszych
latach studiów – ju
w pracy.
Niemal
identycznie
przedstawia się rozkład
odpowiedzi na drugie
pytanie – o posiadanie
własnego konta pocztowego, niezalenego od
Wykres 2
Dostęp studentów
do Internetu
60
61
62
63
Tame, str. 196.
Wliczając w to ankiety „papierowe”.
W roku akademickim 2001-2002 na Wydziale Informatyki studiowało ok. 2700 studentów.
Komentarze te zostały przekazane odpowiednio webmasterom i administratorom sieci.
tego na uczelni (konto
e-mail
na
Wydziale
Informatyki
dostaje
automatycznie
kady
nowo przyjęty student
i dydaktyk).
Wyniki zaprezentowane
są na wykresie 3.
W tym przypadku równie
89% respondentów deklaruje posiadanie swojego własnego, „zewnętrznego” konta e-mail64.
Wykres 3
Posiadanie własnego,
niezalenego od
uczelnianego konta
pocztowego
W trzecim pytaniu ankietowani mieli za zadanie wybrać te przeglądarki,
z których korzystają. Wyniki przedstawiono na wykresie 4 (poniewa badane
osoby mogły zaznaczyć więcej ni jedną przeglądarkę, wyniki nie sumują się
do 100%).
Z wykresu wynika, i
zdecydowana większość
osób (90%) korzysta
z
aplikacji
Internet
Explorer. Druga pod
względem popularności
jest przeglądarka Netscape z wynikiem 49%,
natomiast następny najczęściej wykorzystywany browser to przeglądarka
tekstowa (z reguły Lynx lub Links) – korzystanie z niej deklaruje 37% badanych.
Te dwie ostatnie liczby mogą być zaskakujące, jednak po części tłumaczą
je wykorzystywane na
Wydziale
Informatyki
systemy
operacyjne
(vide rozdział 2.4.1.3).
Naley
te
zwrócić
uwagę, i zadane pytanie
było bardzo ogólne65
i jego głównym celem
było
sprawdzenie,
z ilu ł ą c z n i e rónych
przeglądarek korzystają
badani, co przedstawia
wykres 5.
Wykres 4
Przeglądarki
wykorzystywane przez
ankietowanych
Wykres 5
Liczba
wykorzystywanych
przez badanych
przeglądarek
64
65
Jako ciekawostkę mona wymienić fakt, i zbiory osób, które odpowiedziały „tak” na
pytania 1 i 2 pokrywają się jedynie w 85%.
W rozdziale 2.4.1.3 opisano wyniki bardziej szczegółowych badań dotyczących
wykorzystywanych przeglądarek.
Widać, i jedynie 32% osób korzysta z jednej przeglądarki (dla 94% z nich
jest to Internet Explorer). Pozostali uywają dwóch, trzech, a w niektórych
przypadkach nawet czterech i pięciu przeglądarek! Są to statystyki bardzo
istotne przy oprogramowywaniu interfejsowej części serwisu informacyjnego,
poniewa nie pozwalają ograniczyć się tylko do jednej przeglądarki, a wręcz
przeciwnie – niejako „wymuszają” dbanie o zgodność z szerszą gamą
oprogramowania.
Naley nadmienić równie, i ankietowani mogli w tym pytaniu wpisać
nazwę innej, nie wymienionej przeglądarki, jeśli tylko z niej korzystają.
Jedynie niecałe 4% skorzystało z tej moliwości, wpisując takie produkty, jak
Voyager, AWeb i IBrowse (przeglądarki pod systemem AmigaOS), Arachne
(graficzna przeglądarka DOS-owa), Galeon i Konqueror (odpowiedniki nowej
Mozilli) oraz przeglądarka WebTV – na nie wszystkie oddane były właściwie
pojedyncze głosy.
W kolejnym, czwartym pytaniu, ankietowani mieli określić, jaką formę
dyskusji preferują. Do wyboru były trzy: najdłusza staem e-mailowa
lista dyskusyjna, Usenetowa grupa dyskusyjna (czyli popularne „newsy”)
oraz stosunkowo jeszcze młode forum umieszczone na WWW. Oto, jak
przedstawiają się wyniki:
Wykres 6
Preferowana forma
dyskusji w Internecie
Jak widać, ankietujący
podzielili się na cztery
prawie równoliczne grupy – praktycznie kada
z trzech form dyskusji
uzyskała
taką
samą
liczbę
zwolenników
(jedynie za forum na
WWW opowiedziała się
nieco mniejsza grupa
27%
zdecydowanych
ankietowanych),
natomiast ostatnią ćwiartkę stanowiły osoby, które nie potrafiły opowiedzieć się jednoznacznie za
adnym konkretnym rozwiązaniem.
Piąte pytanie dotyczyło oceny przydatności aktualnej strony WWW i było
pierwszym z dwu pytań, których wyniki stanowiły o celowości stworzenia i
kształcie systemu informacyjnego. Odpowiedzi ankietowanych przedstawione
są na wykresie 7.
Ponad 60% osób uznało, i przydatność aktualnej strony WWW Wydziału
Informatyki jest „średnia” (mona tę odpowiedź uznać równie dobrze za
„nie mam zdania”), a według prawie jednej trzeciej badanych strona jest
mało przydatna. Jedynie 6% odpowiedziało, i witrynę uwaają za bardzo
przydatną.
W ostatnim i najwaniejszym pytaniu ankietowani mieli za zadanie ocenić
przydatność rónych elementów, które mogłyby się znaleźć na stronie
WWW (czyli w serwisie
informacyjnym). Pytanie
zostało
rozdzielone
na 11 części, traktujących
oddzielnie
o
poszczególnych
elementach (takich jak
np. plan zajęć czy dane
wykładowców)66. Zebrane
wyniki są przedstawione
na wykresie 8.
Wykres 7
Przydatność aktualnej
strony WWW
Wydziału Informatyki
Jak wynika z tego
wykresu, bezsprzecznie
najwaniejsze dla studentów byłyby informacje dotyczące planu zajęć:
prawie 80% z nich uwaa je za bardzo, natomiast jedynie 3% za niezbyt
lub mało przydatne. Równie wane według ankietowanych są: informacje
o egzaminach i zaliczeniach (ponad 76% osób uwaa je za bardzo przydatne),
wyniki tyche (równie 76%) i informacje o odwołanych zajęciach (74%).
Kolejne dwa miejsca zajmują dane wykładowców (są uwaane za bardzo
przydatne przez 48,1% osób) i informacje o wypełnianiu indeksu (46,5%).
Najmniej
przydatne
według ankietowanych są:
kalendarz, stan płatności
i informacje o studentach,
jednak naley zauwayć,
i nawet te ostatnie są
uwaane za bardziej
ni mniej przydatne
(znormalizowanie
wszystkich odpowiedzi
daje nieco ponad 50%
poparcia).
Wykres 8
Przydatność usług
oferowanych przez
system informacyjny
Badanie wykorzystywanych systemów operacyjnych
2.4.1.2.
Dzięki wykorzystaniu mechanizmów udostępnianych przez skrypty CGI (ang.
Common Gateway Interface)67, moliwe było równie zachowanie informacji
o tym, z jakich przeglądarek WWW i systemów operacyjnych korzystają
osoby wypełniające ankietę. Dodatkowo na okres dwóch tygodni na głównej
stronie Wydziału Informatyki (http://www.wi.ps.pl) został zainstalowany
przezroczysty dla odwiedzających skrypt, na tej samej zasadzie zapamiętujący
dane osób odwiedzających witrynę68. Oprócz tego zachowywany był adres
66
67
Klemens P. Białecki, Marketing, WPE Infor, Warszawa 1998, str. 214.
CGI environment variables, luty 2002, serwis National Center for Supercomputing
Applications (http://hoohoo.ncsa.uiuc.edu/cgi/env.html).
IP komputera, co pozwalało na późniejsze oddzielenie komputerów
z wewnętrznej sieci Wydziału od tych łączących się z nią za pomocą Internetu,
a take – w przypadku tej drugiej grupy – zbadanie metod dostępu do Sieci
(vide rozdział 2.4.1.4).
Wprawdzie sama wiedza o stosowanych systemach operacyjnych nie
jest przydatna w bezpośredni sposób, jednak pozwala oszacować
poziom technologiczny komputerów uywanych przez ankietowanych
i odwiedzających, co będzie pomocne przy tworzeniu niektórych
elementów serwisu (np. interfejsu). Naley take pamiętać, i stosowany
system operacyjny implikuje konkretny zbiór moliwych do wykorzystania
przeglądarek WWW69.
Poniewa z oczywistych względów (głównie finansowych) zasoby sprzętowe
Wydziału Informatyki są odmienne od tych stosowanych prywatnie
przez studentów, w poniszych akapitach te dwie grupy będą rozwaane
oddzielnie.
Wykres 9 prezentuje systemy operacyjne zainstalowane na komputerach
spoza uczelni:
Widać bezsprzecznie, i
prym wiedzie Microsoft
Windows,
którego
róne
odmiany
są
zainstalowane na łącznie
ponad 96% komputerów.
Pierwszy w kolejności
jest tutaj Windows 98/
Me (58,8% komputerów),
drugi – Windows 2000
(18,6%), natomiast trzeci
– Windows XP (9,7%).
System operacyjny Linux jest zainstalowany
zaledwie na 3,1% komputerów, natomiast ciekawostką właściwie jest Mac
OS, obecny w 0,4% komputerów.
Wykres 9
Systemy operacyjne
komputerów spoza
W przypadku komputerów na Wydziale Informatyki sytuacja prezentuje
się zgoła inaczej. Wprawdzie większość z nich równie korzysta z systemu
operacyjnego Microsoft Windows, jednak jego udział to jedynie 76,4% całości,
a i rónice w wersjach są znaczące. Najnowsze edycje systemu – Windows
2000 i Windows XP – stanowią łącznie jedynie 2% systemów, natomiast
nieobecny na poprzednim wykresie Windows 3.x ma ponad 25% udziału,
a Windows NT – 27,8% (poprzednio 4,5%). Duo częściej, czego mona
68
69
Zapamiętano ponad 2500 wejść na stronę, wykorzystując do tego celu zmienną
środowiskową HTTP_USER_AGENT.
Np. Linux nie doczekał się jeszcze swojej wersji najpopularniejszej przeglądarki Internet
Explorer.
było się spodziewać,
występuje system Linux,
wykorzystywany
przez
prawie 24% osób.
Wykres 10
Systemy operacyjne
komputerów na
Wydziale Informatyki
2.4.1.3.
Widać więc, i o ile
w przypadku komputerów
„domowych”
wykorzystywane
systemy
operacyjne
są
dość
zaawansowane i w miarę
nowoczesne
(jedynie
ok. 10% z nich nie jest
ju wspierana przez
producentów), o tyle na Wydziale Informatyki naley liczyć się z obecnością
dość ju archaicznych systemów, takich jak Windows 3.11 oraz Windows
NT 4.0 (oba wykorzystywane są w salach laboratoryjnych dla studentów).
Nieliczne komputery z najnowocześniejszymi systemami operacyjnymi
(Windows 2000 i Windows XP) są zapewne wykorzystywane przez
dydaktyków w ich gabinetach.
Badanie wykorzystywanych przeglądarek
W podobny sposób zbadane zostało procentowe wykorzystanie poszczególnych
przeglądarek wśród odwiedzających witrynę Wydziału Informatyki
i wypełniających ankietę. Tak samo jak uprzednio, wyniki dla komputerów
z wewnętrznej sieci Wydziału zostaną przeanalizowane oddzielnie.
Wykres 11
Przeglądarki na
komputerach spoza
W pierwszej kolejności
przedstawiona zostanie
sytuacja w przypadku
komputerów
spoza
Wydziału. Jak wynika
z wykresu 11 palmę
pierwszeństwa dziery
tutaj Internet Explorer
– jego wszystkie wersje
stanowią prawie 95%
uywanych przeglądarek.
Najnowsza edycja (6.0)
jest
wykorzystywana
na
jednej
trzeciej
komputerów, pozostałe
zadowalają się w większości wersjami 5.0 i 5.5; jedynie na nieco ponad
3% komputerów zainstalowana jest edycja 4.0 programu. Szczątkowo
wykorzystywane są: Netscape 4.x (2,3%), nowa Mozilla i pokrewne
przeglądarki (2,0%), oraz szósta wersja Opery (0,4%) i przeglądarki tekstowe
typu Links i Lynx (1,1%).
Mona się spodziewać, i z powodu opisanych w poprzednim rozdziale
powanych rónic w wykorzystywanych systemach operacyjnych, sytuacja
w Wydziale Informatyki będzie odmienna. Poniszy wykres moe upewnić
w tym przekonaniu:
Wykres 12
Przeglądarki
dostępne w Wydziale
Informatyki
2.4.1.4.
Wykres 13
Rodzaje połączenia
z Internetem
Widać na nim, i
przeglądarka Netscape
w wersji 4.x jest na
Wydziale a dwudziestokrotnie bardziej popularna, osiągając prawie
48% udziału – jest to
bezpośrednią pochodną
powszechnej obecności
systemu Windows 3.11
w salach laboratoryjnych
dla studentów. Przeglądarka Internet Explorer
wygrywa wprawdzie i tutaj, jednak marginalnie, będąc wykorzystywana przez 48,9% badanych. Bardzo
rzadko wykorzystywane są: trzecia wersja Opery (1,5%) oraz przeglądarki
tekstowe (łącznie 2,1%).
Badanie rodzaju wykorzystywanego połączenia
z Internetem
W celu jak największego
uproszczenia omówionej
w rozdziale 2.4.1.1
ankiety (a co za tym idzie
uzyskania jak największej
liczby
odpowiedzi),
pytanie o własny dostęp
do Internetu było tam
ograniczone tylko do pary
wariantów odpowiedzi
„tak/nie”. W podobny
jednak sposób, co informacje o przeglądarkach i systemach operacyjnych, mona było zbadać rodzaj
uywanego przez studentów połączenia z Internetem.
Jak było do przewidzenia, prawie dwie trzecie studentów (dokładnie 61,8%)
wypełniało ankietę z komputerów umieszczonych na Wydziale Informatyki.
Jedna piąta pozostałej grupy łączyła się z Internetem za pomocą modemów
i numeru dostępowego Telekomunikacji Polskiej SA, prawie 27% z nich
korzystało z usługi SDI, niecałe 2% z niedawno udostępnionej Neostrady,
natomiast pozostałe 53,2% (20,4% całości) łączyło się za pomocą innych
providerów (np. słubowych sieci komputerowych lub sieci osiedlowych).
2.4.2.
Badania przeprowadzone przez
Massachusetts Institute of Technology
Oprócz własnych badań autora niezmiernie interesująca okazała się
ankieta jednej z najbardziej prestiowych uczelni technicznych na świecie,
Massachusetts Institute of Technology w USA (zwanej dalej MIT), które
została przeprowadzona latem 2000 roku przez Instytut Informatyki wśród
studentów uczelni70. Miała ona dać odpowiedź na pytanie, czy uzasadnione
jest stworzenie portalu dla studentów i pracowników, oraz jakie informacje
powinien on zawierać.
Mimo i wniosków wynikających z tamtej ankiety nie da się w bezpośredni
sposób przełoyć na polskie warunki – chociaby z racji rónic w skalach
uczelni i dostępie do technologii informatycznych wśród studentów – jednak
część z nich będzie mogła być w pewien sposób interesująca.
Ankieta była reklamowana przez trzy dni kwietnia 2000 roku na głównej
stronie WWW uczelni i odpowiedziały na nią 534 osoby (76% z nich stanowili
studenci). Jednym z pierwszych było pytanie o preferowany sposób dostępu
do portalu dla studentów. Oto jego wyniki:
Jak wynika z wykresu,
z d e c y d o w a n i e
najpopularniejszy
jest
dostęp do portalu poprzez
przeglądarkę
WWW,
czy to z komputerów
stacjonarnych na terenie
uczelni, czy prywatnych
notebooków – a 83%
osób odpowiedziało, i jest on bardzo przydatny . Drugi pod względem
popularności i z kolei ostatni uwaany przez ankietowanych za przydatny
sposób dostępu to komputery przenośne ((palmtopy), u nas dopiero
zdobywające popularność. Trzecia moliwość to umieszczone w kampusie
samodzielne stanowiska (kioski) internetowe, które za bardzo przydatne
uznało jednak jedynie 15% pytanych – zapewne ze względu na ich małą ilość.
Dwie ostatnie opcje to telefony komórkowe z dostępem do Internetu (nawet
dziś jeszcze rzadko wykorzystywane i mało wygodne) oraz praktycznie
w Polsce nieobecne automatyczne systemy telefoniczne sterowane głosem.
Wykres 14
Preferowany sposób
dostępu do portalu
MIT
W kolejnym pytaniu ankietowani mieli wypowiedzieć się na temat
przydatności usług, które mogłyby być oferowane przez portal. Odpowiedzi
na to pytanie przedstawione zostały na wykresie 15. Widać na nim, i za
najbardziej przydatne w portalu – podobnie jak w ankiecie przeprowadzonej
wśród studentów Wydziału Informatyki Politechniki Szczecińskiej – okazały
się według ankietowanych informacje o zajęciach. Chocia za „bardzo
70
Oryginalne załoenia i wyniki ankiety są dostępne w Internecie pod adresem
http://web.mit.edu/is/discovery/portals/index.html.
przydatne” uznało je
jedynie 57% osób, co
mogłoby się to wydawać
liczbą małą w porównaniu
do 80% analogicznych
odpowiedzi studentów
Wydziału
Informatyki,
jednak naley wziąć pod
uwagę, i informacje
o zajęciach były ju
wcześniej w MIT obecne
w postaci elektronicznej,
jednak nie na witrynie
WWW71.
Wykres 15
Przydatność usług
oferowanych przez
portal MIT
Pod względem popularności za kolejne uznano:
informacje o studentach i pracownikach uczelni oraz kontakty z nimi,
kalendarz z zaznaczonymi wydarzeniami kampusu,
informacje o wynikach zaliczeń, ocenach i wszystkich danych związanych
z procesem nauczania studenta,
informacje o egzaminach, zaliczeniach oraz innych wanych datach
i terminach.
W środku listy znalazły się m.in. poczta elektroniczna, stan płatności
oraz systemy komunikowania się między grupami osób, natomiast jako
nieprzydatne oceniono jedynie dwie ostatnie pozycje: pokoje z rozmowami
(ang. chat) i listy/grupy dyskusyjne.
Widać tutaj dość due podobieństwo do wyników ankiety przeprowadzonej
wśród studentów Politechniki Szczecińskiej, aczkolwiek przebywający na
terenie MIT za bardziej przydatny uznają kalendarz (zapewne z powodu
bogatszego ycia naukowego i kulturalnego na kampusie) oraz stan finansów
(co jest oczywiste w świetle innego systemu płatności za studia w USA).
Komentarze zostawiane przez część ankietowanych równie były interesujące
– oto przetłumaczone na polski najciekawsze z nich:
„Przy projektowaniu portalu weźcie pod uwagę fakt, i w ciągu dwu lat
większość osób z MIT będzie łączyła się z Internetem bezprzewodowo.”
„Portal powinien działać z kadego miejsca na Ziemi.”
71
Odpowiada za to tekstowy spersonalizowany system Athena.
„Upewnijcie się, i strona główna będzie się ładowała naprawdę szybko.”
„Korzystajcie z SSL.72”
„Udostępniajcie część danych w formatach łatwych do przetworzenia przez
skrypty w Perlu i CGI, aby mona było je zaadaptować na potrzeby własnych
prywatnych stron.73”
„Jedną z najwaniejszych rzeczy w takich portalach są kwestie
bezpieczeństwa.74”
„Newsy, pokoje do pogawędek, pogoda oraz listy dyskusyjne nie powinny
wchodzić w skład portalu, gdy mona je znaleźć w wielu innych miejscach.
Skupcie się na rzeczach związanych z MIT.”
„Niech wana będzie moliwość dostosowania informacji do własnych potrzeb
– na przykład nie kadego muszą interesować informacje ze świata.”
„Byli studenci powinni wcią mieć dostęp do portalu, nawet jeśli na
ograniczonych warunkach.”
W podsumowaniu autorzy ankiety doszli do wniosku, i studenci MIT są
bardzo zainteresowani portalem zawierającym informacje i usługi ich uczelni,
który powinien spełniać następujące warunki:
działać tak szybko, jak to jest moliwe,
być dostępny przez całą dobę,
być niezaleny od zewnętrznych firm i wolny od komercjalizacji (brak
reklam i ofert sprzeday produktów).
2.4.3.
Wywiady z dydaktykami
Oprócz badań wśród studentów przeprowadzono take parę wywiadów z
osobami mającymi zajęcia ze studentami (głównie z dydaktykami Wydziału
Informatyki Politechniki Szczecińskiej). Zgłosili oni parę uwag dotyczących
72
73
74
Warstwy zapewniającej bezpieczną wymianę danych przez protokół HTTP – więcej
informacji w rozdziale 3.4.1.
Zagadnienia te będą przedmiotem rozdziału 3.5.3.
Patrz rozdziały 3.4.1 i 3.7.2.
aktualnej strony i konkretnych propozycji poprawy sytuacji, które zostaną
wymienione poniej.
Problem z nieczytelnością planu zajęć dotyczy pracowników w równie duym,
jeśli nie większym stopniu co studentów. Jeśli sekretariat odpowiedniej
katedry wykae się inicjatywą i operatywnością, wówczas pracownik
otrzyma listę swoich zajęć, jeeli nie – wówczas musi on skorzystać z tego
samego planu, co studenci. O ile jednak ci muszą odszukać wszystkie swoje
zajęcia na jednej tylko stronie, pracownicy muszą przejrzeć w s z y s t k i e
lata w s z y s t k i c h kierunków studiów, aby sprawdzić, z którymi grupami
i w jakie dni mają zajęcia. Podobnie kłopotliwe bywa take uzyskanie listy
osób, z którymi są prowadzone zajęcia – często taką listę trzeba uzyskać... od
samych studentów.
Rozdzielenie materiałów na zajęcia wśród studentów równie moe
nastręczać problemów:
„Materiały na zajęcia przygotowywane przez prowadzących: wiadomo, e
istnieją ograniczenia dotyczące kserowania i jest nierealne, aby prowadzący
mógł zrobić tyle odbitek, ilu ma studentów (tak, aby kady miał swoją kopię
przed nosem kiedy temat jest omawiany a o zabraniu kopii do domu mowy
być nie moe, bo wtedy nie starczy dla następnych grup!).
Co więcej, najczęściej jest moliwość zrobienia kilkunastu odbitek, które
mają wystarczyć na kilka grup. Albo co gorsza w ogóle nie mona skserować
materiału i studenci biegną w trakcie zajęć na ksero aby przynajmniej jedna
kopia została w grupie do dalszego duplikowania – paranoja! Mój pomysł:
moliwość zamieszczania materiałów na stronie internetowej i przy uyciu
Adobe Acrobat Readera mogłyby trafić do studentów przed zajęciami.”
Zasugerowano take wprowadzenie na stronie wyszukiwarki dokumentów
naukowo-technicznych, która przydałaby się w pracy naukowej, i do której
mona byłoby niekiedy odesłać studenta w razie pytań. Podobną rolę mogłyby
spełniać prace naukowe umieszczane bezpośrednio przy stronach katedr lub
odpowiednich przedmiotów.
Kolejnym pomysłem był dostęp do swojego konta uczelnianego z poziomu
przeglądarki, z moliwością ściągania i dodawania plików poprzez protokół
HTTP (HTTPS) – przydatny w wypadku konieczności dostania się do swojego
konta z zewnętrznego komputera z małą ilością oprogramowania, np. podczas
podróy słubowej.
2.4.4.
Zagroenia przy tworzeniu i eksploatacji serwisu
informacyjnego
Zastanawiając się nad wprowadzeniem serwisu informacyjnego naley wziąć
pod uwagę take i wszystkie ewentualne zagroenia dla jego prawidłowego
funkcjonowania.
Przede wszystkim konieczne jest upewnienie się, i serwis jest tworzony
zgodnie z oczekiwaniami osób, które będą potem z niego korzystały,
a wszystkie funkcje są proste i moliwie jak najbardziej intuicyjne. Jeśli
jakakolwiek z opcji będzie skomplikowana, nieczytelna, niepotrzebna
bądź niezgodna z rzeczywistością, uytkownicy nie będą po prostu z niej
korzystać. Jeśli taki będzie cały serwis, równie i on stanie odłogiem,
a serwis z którego nikt nie korzysta wkrótce przestanie być komukolwiek
przydatny. Stąd konieczne jest zbadanie oczekiwań i wysłuchanie wniosków
oraz propozycji przyszłych uytkowników tego serwisu, gdy ich zdanie
jest tutaj bezwzględnie najwaniejsze. W niniejszej pracy taką rolę spełniła
ankieta dla studentów (omówiona w rozdziale 2.4.1.1) oraz indywidualne
zapytania pracowników Wydziału Informatyki (vide rozdział 2.4.3). Sam
serwis powinien być równie wyposaony w system pomocy, który moliwie
dokładnie wyjaśniałby wszelkie nieścisłości i ewentualnie zapytania.
Kolejnym elementem, na który naley zwrócić uwagę, jest dostęp studentów
i pracowników do serwisu, czyli w praktyce dostęp do komputerów.
Nietrudno domyślić się, e system, do którego nie ma „dojścia” nie będzie
systemem uytecznym. Naley więc zadbać o to, aby wszyscy zainteresowani
mieli swobodny i nieprzerwany dostęp do serwisu – czy to poprzez
upewnienie się, e ilość dostępnych komputerów podłączonych do lokalnej
sieci jest adekwatnie dua, czy poprzez udostępnienie odpowiedniej ilości
komputerów75 przeznaczonych tylko do korzystania z serwisu76.
W Wydziale Informatyki w przypadku pracowników sytuacja jest dość prosta
– kady z nich ma własny słubowy komputer w swoim pokoju, tak więc
moe z serwisu korzystać na bieąco. Studenci mogą mieć w tym względzie
nieco większe problemy – wprawdzie jest co najmniej kilkanaście sal
laboratoryjnych z odpowiednio wyposaonymi komputerami, jednak dostęp
do nich jest uwarunkowany ilością odbywających się w danym momencie
zajęć77. Nie naley jednak zapominać o tym, i studenci w znakomitej
większości mają swoje własne domowe komputery z dostępem do Internetu
(por. rozdział 2.4.1.1), a w przyszłości będą dysponowali take coraz większą
ilością urządzeń przenośnych (notebooki, palmtopy, telefony komórkowe
nowej generacji).
75
76
77
Lub alternatywnych urządzeń, takich jak kioski internetowe – będzie o tym mowa
w rozdziale 3.6.2.
Podobnie, jak często np. w bibliotekach widzi się komputery przeznaczone tylko
do oglądania wewnętrznego katalogu.
A w związku z niedawnym otwarciem nowych kierunków tych zajęć jest coraz więcej.
Kolejnym wanym elementem mogącym wpływać na działanie systemu –
szczególnie w początkowej fazie – jest konieczność przystosowania i swoistego
„oswojenia się” z nim zainteresowanych osób, zwłaszcza tych mających
bezpośredni wpływ na dane pojawiające się w systemie (np. pracowników
dziekanatu). W przeciwnym wypadku bowiem system, nie uzupełniany
o nowe informacje, szybko stanie się nieaktualny i bezuyteczny.
Parę osób odpowiadających za podobne systemy w innych uczelniach
przysłało konkretne przykłady takiego typu zagroeń, jak chociaby:
„Dziekanat moe wprowadzać treści ogłoszeń (choć cięko to od nich
wydobyć).”
czy:
„Jak na razie są z tym problemy tzn. mało ludzi chce z niego korzystać,
w większości ludzie są przyzwyczajeni do tradycyjnych metod pozyskiwania
informacji.”
Niewątpliwie niezbędne wydają się więc serie odpowiednich szkoleń dla
pracowników uczelni (por. rozdział 3.7.3), wraz z odpowiednią motywacją,
oraz przygotowanie informacji o systemie dla studentów (chociaby
w postaci elektronicznej) zwracających uwagę na korzyści płynące
z pełnego wykorzystywania serwisu. Z własnych obserwacji autora przy
wprowadzaniu i rozwijaniu serwisu intranetowego w Akademickim Centrum
Informatyki wynika, i przydaje się take opór i konsekwencja, pomagająca
w przełamywaniu zastanych konwencji czy barier wynikających z nie mających
uzasadnienia obaw uytkowników.
Kolejnym niebezpieczeństwem, w naturalny sposób wynikającym
z przeniesienia wielu danych do otwartego środowiska komputerowego,
są zagroenia podejrzenia informacji (bądź, co gorsza, ich modyfikacji)
przez osoby niepowołane. Im większa rozległość systemu, tym potencjalne
zagroenia są powaniejsze i nietrudno sobie wyobrazić ogrom konsekwencji
nieautoryzowanej zmiany ocen bądź stanu płatności studentów. Naley więc
zwrócić duą uwagę na kwestie zabezpieczenia systemu przed dostępem
intruzów i ustawienia odpowiednich uprawnień dla wszystkich korzystających
z niego osób.
2.4.5.
Wnioski
Oczywiście mona i naleałoby polemizować z tym przedstawionym obok tak
euforystycznym
okrzykiem
jednego
z wypełniających ankietę studentów, jednak
nie mona zaprzeczyć powszechnej niechęci
studentów do obcowania z dziekanatem
„Gdyby udało wam się
spełnić wszystkie
z powyszych, to cholerny
dziekanat nie byłby nam
wcale potrzebny i ave!!!”
i innymi przejawami uczelnianej biurokracji, szczególnie jeśli jest to
biurokracja mało uzasadniona.
Z samej ilości przysłanych ankiet mona wywnioskować, i studentom zaley
na tym, aby strona WWW – z której obecnie są raczej niezadowoleni –
umoliwiała im dostęp do większej ilości danych i materiałów oraz zastępowała
część istniejących na uczelni od dawna mechanizmów przepływu informacji.
Chocia mało polskich uczelni posiada naprawdę lepsze, dynamiczne
witryny – nawet dostęp do poczty elektronicznej przez WWW czy katalogów
bibliotecznych bywa rzadkością – po spojrzeniu na strony zachodnich uczelni
widać, i przyszłość witryn ley właśnie w dostępnych z Internetu serwisach
informacyjnych.
Dobrze zaprojektowany serwis informacyjny, biorący pod uwagę
zapotrzebowania studentów i pracowników oraz uwzględniający ju przy
projektowaniu wszystkie te czynniki, które mogą wpływać negatywnie
na jego funkcjonowanie, mógłby znacznie przyspieszyć, uprościć
i zautomatyzować niektóre czynności, odciąyć dziekanat i inne komórki
uczelniane oraz przyczynić się do lepszego i szybszego obiegu informacji
w uczelni. Po odpowiednim okresie przejściowym oraz przyzwyczajeniu się
ludzi do swoistego novum, i studenci, i pracownicy powinni tylko zyskać na
jego wprowadzeniu. O tym, jak powinien być tworzony taki system będzie
mowa w kolejnych rozdziałach pracy.
3.
Projekt serwisu
informacyjnego
W poprzednich rozdziałach opisano podstawowe technologie spotykane
w sieci WWW, elementy serwisu informacyjnego, na które naley zwracać
uwagę, a take oczekiwania wszystkich zainteresowanych stron co do
działania takowego serwisu, kolej więc na fazę projektowania serwisu,
w której oczywiście zostaną uwzględnione wszystkie opisane wcześniej
informacje.
Projekt serwisu informacyjnego 57
3.1.
Załoenia
Na początku przydatne moe być wypisanie wszystkich najwaniejszych cech
serwisu informacyjnego:
Ułatwianie pracy studentom i pracownikom – to podstawowe zadanie
serwisu. Kady, nawet najmniejszy jego element ma ułatwiać zarządzanie
i przekazywanie informacji w obrębie uczelni. Wszystkie składniki mają
składać się na system, z którego uytkownicy chcą korzystać, a nie na system,
z którego korzystać m u s z ą .
Bogactwo, rzetelność i aktualność informacji – naley starać się
szczególnie, aby zaimplementować w systemie mechanizmy wyświetlania
i obróbki najbardziej poądanych przez uytkowników informacji (planu zajęć,
informacji o zaliczeniach i ich wynikach, danych wykładowców i studentów
– por. rozdziały 2.4.1 i 2.4.3), i aby informacje te były odpowiednio często
aktualizowane. Idealny system powinien zawierać take mniej na pierwszy
rzut oka przydatne dane, jeśli tylko istnieje podejrzenie, e mogą one kiedyś
być dla kogoś pomocne.
„Strony powinny zawierać
wszystko, nawet to co
nieprzydatne, ale najwaniejsze
jest to, aby uytkownik
w sposób łatwy i intuicyjny dotarł
do tej zawartości; niech sobie
będzie nawet rozkład obiadów
na stołówce – jeśli jest chocia
jedna osoba, która będzie
Hierarchizacja informacji – przy
zakładanym bogactwie informacji
naley te uwzględnić to, i stopień
ich widoczności powinien być
proporcjonalny do waności. Naley
unikać sytuacji, w której wszystkie
moliwe informacje są podane ciągiem
jedna obok drugiej, gdy system
straci na czytelności – najbardziej
istotne dane powinny być dostępne
na pierwszy rzut oka tak, aby
uytkownicy nie tracili cennego czasu
na ich odnalezienie.
chciała go znać to powinien
Prostota i wygoda obsługi – które
muszą iść w parze z przedstawianymi
być... ale w odpowiednim
informacjami, inaczej system będzie
miejscu!”
dla
uytkowników
nieczytelny
(szczególnie jeśli weźmiemy pod
uwagę, i część z nich nie miała do tej pory styczności z tego typu systemami).
Trzeba w tym celu zwrócić uwagę na wiele rzeczy, począwszy więc od
prostego do zapamiętania adresu serwisu, poprzez wygodny i intuicyjny
interfejs z jak najmniejszą ilością technicznego argonu, a skończywszy na
łatwo dostępnym oraz wyczerpującym systemie pomocy.
Jednorodność i spójność – nawet, jeśli system powstaje jako powiązanie paru
szczątkowych systemów ju obecnych na uczelni, naley zadbać o to, aby
prezentował się jako jedna, spójna całość. Niedozwolona jest dla przykładu
sytuacja, w której jakiekolwiek dane są przechowywane w systemie dwu- lub
kilkukrotnie, poniewa grozi to powstaniem rónic między tymi danymi.
Równie w obrębie nawigacji i interfejsu powinna obowiązywać spójność,
nawet jeśli konieczne będzie stworzenie w tym celu dodatkowych „bramek”
których jedynym zadaniem będzie ujednolicenie wyglądu stron.
Profilowanie – oczywistym jest, i z systemu będą korzystały róne osoby –
studenci, dydaktycy, dziekanat – i e kada z tych grup będzie zainteresowana
innymi informacjami. Dla przykładu, studentów będzie interesować jedynie
wycinek planu dotyczący ich grupy, dydaktyków tylko zajęcia które sami
przeprowadzają, natomiast dziekanat plan zajęć jako całość. Naley więc
postarać się, aby dopasować serwis do kadej z tych grup oddzielnie.
Personalizacja – stanowiąca swoiste rozszerzenie powyszej cechy. Wiadomo,
i nawet w obrębie danej grupy kada osoba ma własne upodobania i system
powinien to uwzględniać, pozwalając na indywidualne dopasowanie części
funkcji do ądań uytkownika. Funkcji tych nie powinno być ani za mało
(uytkownik chce mieć kontrolę), ani za duo (gdy przyczyni się to jedynie
do jego zagubienia).
Prosty, ciągły dostęp – na który składają się: uycie jak najbardziej popularnej
i intuicyjnej formy dostępu do informacji (WWW); upewnienie się, i istnieje
odpowiednio dua liczba komputerów, na których mona korzystać z serwisu;
umoliwienie korzystania z serwisu take z komputerów spoza kampusu78;
proste, nie wymagające wiele wysiłku uwierzytelnianie.
Dua szybkość działania – czyli mieszcząca się w rozsądnych granicach
wielkość stron WWW serwisu i odpowiednio szybki serwer udostępniający te
strony (te dwa czynniki powinny umoliwiać wygodne oglądanie stron nawet
na komputerach podłączonych do Internetu za pomocą modemu, co jest
istotne w świetle wyników badań z rozdziałów 2.4.1.1 i 2.4.1.4)79. Oprócz
tego naley uwzględnić potencjalne korzystanie z serwisu przez wiele osób
równocześnie.
Zachowanie prywatności – czyli upewnienie się, i dane uytkownika
prywatne (takie jak jego adres e-mail czy numer telefonu komórkowego)
i poufne (np. stan płatności i oceny) nie będą mogły być udostępniane na
zewnątrz bez wyraźnego zalecenia zainteresowanej osoby.
Zachowanie bezpieczeństwa – powiązane z powyszym, uniemoliwiające
osobom postronnym celowy bądź nieumyślny dostęp do informacji w serwisie
(jak równie modyfikację czy usunięcie ich), zablokowanie czy utrudnienie
jego działania oraz podszycie się pod innego uytkownika.
Otwartość – cały system powinien być projektowany z myślą o jego dalszym
rozwoju. Nawet jeśli takie podejście moe oznaczać większy nakład pracy przy
realizacji serwisu, z pewnością przyniesie korzyści podczas jego późniejszej
rozbudowy. Konieczne jest tutaj więc unikanie wszelkiego rodzaju „skrótów”
78
79
Tak, aby uzyskać dostęp 24/7 – całą dobę, siedem dni w tygodniu.
Jakob Nielsen, Response times: the three important limits, 1994, serwis useit.com
(http://www.useit.com/papers/responsetime.html).
i prowizorycznych rozwiązań, a take dokładne opisywanie wszelkich
elementów serwisu (i jako komentarzy w kodzie źródłowym, i zewnętrznych
plików z dokumentacją).
Powiązanie ze stroną WWW Wydziału – mimo i system jest przeznaczony
jako uzupełnienie, a nie zastępnik witryny Wydziału (http://www.wi.ps.pl),
naley wziąć pod uwagę wszystkie załoenia opisane w rozdziale 1.3.4.1,
a take z czasem dąyć do tego, aby obie witryny uzupełniały się nawzajem
– od interfejsu poczynając, na wspólnych danych kończąc.
Zwracanie uwagi na detale – naley unikać myślenia „ta rzecz jest niewana”
czy „tę funkcję będzie mona na porządnie dokończyć później”. Kady
element serwisu, nawet te potencjalnie rzadko wykorzystywane, powinny
być przemyślane od początku do końca i na równi z innymi składnikami.
3.2.
Przykład wykorzystania
Zanim poszczególne elementy serwisu zostaną przebadane i dokładnie
opisane, przydatnym eksperymentem moe być wyobraenie sobie i opisanie
typowej sesji z serwisem zarówno studenta, jak i dydaktyka.
3.2.1.
Sesja studenta
Student siada przy jednym z ogólnodostępnych stanowisk w salach
laboratoryjnych Wydziału Informatyki. Włącza komputer, ładuje system
operacyjny, uruchamia przeglądarkę i wpisuje adres witryny intranetowej.
Poniewa jest to komputer dostępny dla wszystkich, student musi najpierw
podać systemowi własną tosamość. W tym celu na stronie wejściowej podaje
swój login oraz hasło (takie samo, jak dla wykorzystywanego przez niego
konta pocztowego).
Po zidentyfikowaniu się system wita go stroną wejściową. Na tej stronie
student szybko sprawdza swój plan na dzień dzisiejszy oraz jutrzejszy. Jedno
z zajęć jest oznaczone jako „odwołane”, co mile zaskakuje studenta, poniewa
a) będzie mógł wyjść z uczelni w piątek dwie godziny wcześniej, b) zdąył ju
o fakcie odwołania zajęć zapomnieć. Student sprawdza tylko, w jakiej sali ma
kolejne zajęcia i przenosi wzrok do ramki, gdzie czeka na niego informacja
o najnowszych wiadomościach, które otrzymał.
Widzi, i jedna z nich jest zaznaczona jako wana i zatytułowana „Wyniki
zaliczenia”. Klika więc na niej i dowiaduje się, i nie zaliczył ostatniego
kolokwium z jednego z przedmiotów. Po chwili refleksji klika na nazwie
przedmiotu i ma dostęp do wszystkich dostępnych online materiałów
dotyczących tego przedmiotu. Wybiera te, które będą mu potrzebne do
nauki i w tle ściąga je na własne konto. Widzi te listę zalecanych przez
wykładowców ksiąek.
Poniewa jednak lista jest dość długa, student przechodzi z powrotem do
systemu wiadomości, tworzy nową wiadomość, jako adresata wybiera całą
swoją grupę i pisze krótki list z prośbą o polecenie mu jednej z tych ksiąek
i wskazanie miejsca, w którym mona byłoby ją w miarę szybko i w miarę
tanio dostać.
Po wysłaniu listu student sprawdza jeszcze szybko pocztę e-mail oraz zagląda
na forum dyskusyjne swojej grupy aby sprawdzić, czy nie pojawiły się jakieś
nowe informacje. Poniewa w międzyczasie ściągnęły się ju materiały,
student przegrywa je na dyskietkę, po czym wylogowuje się z systemu
i wyłącza komputer.
3.2.2.
Sesja dydaktyka
Dydaktyk siada w swoim pokoju przed komputerem i uruchamia
przeglądarkę. Serwis informacyjny jest wpisany jako strona początkowa,
a dzięki wybraniu wcześniej odpowiednich opcji w systemie autoryzacji nie
będzie konieczne logowanie się, tak więc strona wejściowa systemu pojawia
się automatycznie.
Jego uwagę przykuwają nowe ogłoszenia z jego katedry o gościnnym
wykładzie profesora z innej uczelni, który ma się odbyć za dwa tygodnie.
Dydaktyk kae systemowi zapisać tę informację do jego kalendarza, po czym
w tyme kalendarzu sprawdza, jakie ma tego dnia zajęcia.
Widzi, i o tej godzinie ma laboratoria z jedną z grup. Klika więc na nazwę
grupy, po czym kae systemowi wysłać do wszystkich z tej grupy wiadomość
o tym, i zajęcia są odwołane.
Następnie wraca na stronę główną. Patrzy, i czeka na niego wiadomość
od jednego ze studentów. Klika na nią – jest to prośba o udostępnienie
materiałów do przedmiotu. Dydaktyk kolejnym kliknięciem sprawdza,
z której grupy jest student i jakie ma z nim zajęcia. Kilka na nazwę
przedmiotu, po czym za pomocą przeglądarki umieszcza na stronie WWW
plik z materiałami bezpośrednio ze swojego dysku. Następnie cofa się
i odpowiada na wiadomość.
Podobnie jak student sprawdza swoje zajęcia na dzień dzisiejszy i jutrzejszy,
a take wydarzenia z kalendarza na te dni. Po tym zamyka przeglądarkę
i wychodzi z pokoju, mijając grupkę zadowolonych studentów, którzy właśnie
dostali SMS-em wiadomość o odwołaniu zajęć...
3.3.
Wymagania dotyczące interfejsu
Interfejs witryny powinien być tworzony na samym końcu, ju po dokładnym
przemyśleniu jej zawartości i funkcji. Identyczna kolejność obowiązywała
w przypadku projektowania tego serwisu, jednak z uwagi na strukturę pracy
(kolejne rozdziały będą zawierały konkretne przykłady ekranów obrazujących
opisywane w tekście funkcje witryny) projekt interfejsu zostanie opisany ju
w tej części.
Opis rozpocznie się od załoeń ogólnych, a skończy na szczegółach
technicznych i dotyczących implementacji.
3.3.1.
Wytyczne
Interfejs serwisu informacyjnego powinien być przede wszystkim skromny,
dyskretny i czytelny. Celem serwisu nie jest zdobycie nowych klientów,
czy oszołomienie odwiedzających nowinkami technicznymi, a webmaster
nie musi udowadniać nikomu, e zna najnowsze technologie WWW. Duo
większe ni w przypadku innych witryn znaczenie będzie tu miał dostęp do
informacji, a interfejs nie powinien stać odwiedzającemu na przeszkodzie
w zdobywaniu tych informacji ani odwracać jego uwagi od treści80.
Kolejnym podstawowym załoeniem przy projektowaniu interfejsu powinna
być jego intuicyjność. Tak, jak w przykładach podanych w rozdziale 3.2,
uytkownik powinien skupiać się jedynie na tym, c o robić, a nie na tym
j a k to robić. Naley pamiętać, i większości uytkowników serwisu nie
interesują jego wewnętrzne mechanizmy – chcą jedynie korzystać z niego
w sposób tak skuteczny, jak to tylko moliwe81. Aczkolwiek od osób z Wydziału
Informatyki mona oczekiwać dość duego „obycia” z komputerami i WWW
w szczególności, nie naley ich jednak niepotrzebnie obarczać koniecznością
znajomości np. języka HTML czy innych rzeczy nie związanych w aden
sposób z informacjami zawartymi w serwisie.
W intuicyjności naley posuwać się tak daleko, jak to moliwe. Jeśli np.
w serwisie pojawi się okienko do wpisania daty, nie powinno się narzucać
uytkownikowi jednego konkretnego formatu daty, poniewa jeśli jest to
format, do jakiego nie jest on przyzwyczajony, wówczas po pierwsze spędzi
on niepotrzebnie duo czasu nad przerobieniem daty w myślach, a po drugie
zwiększy się wtedy ryzyko popełnienia błędu przy „konwersji”. Oczywiście,
w serwisie powinna obowiązywać spójność jeśli chodzi o przedstawianie dat,
jednak w przypadku podawania jej przez uytkownika system powinien być
bardziej liberalny i zezwalać na wprowadzanie daty w rónych formatach.
Z intuicyjności wypływa te przyjazność dla uytkownika. Ewentualne
komunikaty o błędach powinny być przeznaczone dla człowieka, a nie
jedynie informatyka – czyli być zwięzłe, napisane naturalnym językiem,
uprzejme, precyzyjne oraz powinny nieść ze sobą porady co do dalszego
postępowania82. Konieczność ingerencji uytkownika w wypadku wystąpienia
80
81
82
Jakob Nielsen, The 10 best intranet designs of 2001, listopad 2001, serwis useit.com
(http://www.useit.com/alertbox/20011125.html).
Bruce Tognazzini, First principles, 2001, serwis Nielsen Norman Group
(http://www.asktog.com/basics/firstPrinciples.html).
Jakob Nielsen, Error message guidelines, czerwiec 2001, serwis useit.com
błędu powinna być ograniczona do minimum – nie naley np. oczekiwać od
niego, i ponownie wypełni od początku formularz. Wykonanie potencjalnie
groźnej w skutkach operacji powinno być poprzedzone odpowiednim
zapytaniem dokładnie wyjaśniającym jej działanie i upewniającym się, i
uytkownik na pewno miał to na myśli. Wszelkie odnośniki powinny być
opatrzone etykietkami wyjaśniającymi co się stanie po ich uyciu. Dłusze
tabele (np. wyniki przeszukiwania) powinny mieć moliwość sortowania
po dowolnej kolumnie i w dowolnym kierunku, naley take rozwayć
(przynajmniej początkowo) przełamywanie ich i dzielenie na strony
w przypadku nadmiernej długości.
Niezbędny
wreszcie
będzie system pomocy,
najlepiej
kontekstowy
(tj. dostosowujący wyświetlane
informacje
do sytuacji, w jakiej
znajduje się uytkownik),
wyjaśniający
moliwości
dostępne
na
poszczególnych
stronach serwisu oraz odpowiadający na najczęściej
zadawane pytania83. Dostępny powinien być take
widoczny adres e-mail
webmastera, do którego
będzie mona zgłosić pytania bądź uwagi dotyczące funkcjonowania serwisu, lub poprosić o pomoc
jeśli wszystkie inne środki zawiodą84.
Rysunek 21
Menu nawigacyjne
czterech
sekcji serwisu
STARTREK.COM
Kolejnym słowem kluczowym powinna być powtarzalność. Naley zdawać
sobie sprawę, i kade odchylenie od ustalonych wytycznych to potencjalnie
więcej czasu zmarnowanego przez uytkownika serwisu na zastanawianie się,
czy jest ono celowe (a jeeli tak, to czemu słuy), czy przypadkowe. Kada
strona naszej witryny powinna być kolorystycznie spójna, wykorzystywać
identyczne czcionki i być opatrzona identycznymi nagłówkami i stopkami;
wszystkie elementy interfejsu powinny prezentować ten sam styl; kliknięcie
na podobnym odnośniku czy ikonce powinno dawać podobne rezultaty;
wszystkie tabelki i daty wyglądać jednakowo... Przykłady mona mnoyć85.
Nie oznacza to jednak, e strona musi od początku do końca wyglądać
identycznie. Dopuszczalne są odchylenia, jeśli tylko słuą one
83
84
85
O systemie pomocy będzie mowa w rozdziale 3.4.12.
Na niektórych stronach zamiast adresu e-mail mona spotkać formularz pozwalający na
wysłanie uwagi z poziomu WWW, jednak to rozwiązanie jest zazwyczaj mało wygodne
i wprowadza wiele ograniczeń (np. niemoność przesłania załącznika ze zrzutem ekranu).
Eric Tilton, Composing good HTML, op. cit.
konkretnemu celowi, np. wizualnemu wydzieleniu szczególnej części
serwisu. Dobrym przykładem moe być tutaj witryna STARTREK.COM
(http://www.startrek.com), gdzie specjalne sekcje witryny wyróniają się
odmienną kolorystyką i nieco zmienioną grafiką, zachowując jednak styl
i funkcjonalność całego serwisu (patrz rysunek 21).
3.3.2.
Nawigacja
Znaczenia nawigacji, o czym była ju mowa w rozdziale 1.3.4, nie da
się przecenić. Kada podstrona powinna być precyzyjnie umiejscowiona
w hierarchii ser wisu, a uytkownik powinien sobie zdawać z tej hierarchii
sprawę – większość odwiedzających witrynę nie potrafi zbudować sobie
w myślach mapy serwisu i jeśli jest do tego zmuszona, czuje się zagubiona
bądź zmęczona86.
Dlatego te na kadej podstronie serwisu powinny być umieszczone
wskazówki nawigacyjne pozwalające uytkownikowi zorientować się,
w którym dokładnie miejscu serwisu się znajduje. Te wskazówki nawigacyjne
to: hierarchiczne menu, aktualny kontekst (zaznaczony kolorystycznie
w menu), logo, mapa serwisu oraz tytuł strony.
W przypadku menu zdecydowano się na dwupoziomowe hierarchiczne menu,
gdy taka ilość poziomów powinna wystarczyć na potrzeby serwisu (naley
równie pamiętać o „zasadzie trzech kliknięć”, omówionej w rozdziale
1.3.4). Pierwszy poziom menu składa się z następujących pozycji:
(główna strona z informacjami zbiorczymi),
INFORMACJE
ZAJĘCIA
WIADOMOŚCI
FORUM
(fora dyskusyjne dla studentów),
POCZTA
(dostęp do konta pocztowego e-mail przez WWW),
KALENDARZ
WYKŁADOWCY
STUDENCI
MATERIAŁY
(informacje o planie zajęć, terminach zjazdów, materiałach),
(wysyłanie i odbieranie wewnętrznych wiadomości systemu),
(informacje o wydarzeniach),
(informacje o wykładowcach i katedrach),
(informacje o studentach),
(materiały do zajęć, informacje, poradniki, adresy stron WWW).
Podana wyej kolejność jest podyktowana przede wszystkim wynikami
przeprowadzonej ankiety – zgodnie z naturą języka polskiego najbardziej
znaczące opcje powinny być umieszczone po lewej stronie ekranu.
Oczywiście kolejność tę będzie mona potem dopasować do faktycznej
popularności kolejnych opcji, aczkolwiek naley wziąć wtedy pod uwagę inny
czynnik – przyzwyczajenie człowieka.
86
Bruce Tognazzini, First principles, op. cit.
Pierwszy poziom menu będzie widoczny na ekranie cały czas, pozwalając
uytkownikowi na natychmiastowe przeniesienie się do wybranej sekcji
serwisu. Dodatkowo aktualnie wybrana sekcja będzie w pewien sposób
(kolorystycznie) odznaczona tak, aby uytkownik wiedział, w jakim aktualnie
kontekście się znajduje.
Większość wymienionych wyej pozycji menu ma swój drugi poziom,
który będzie dokładniej omówiony ju w kolejnych rozdziałach, jednak
tutaj nadmienić naley, i on te będzie widoczny na ekranie i podobnie
jak w przypadku menu głównego wybrana sekcja zostanie odpowiednio
zaznaczona.
Oprócz dwupoziomowego menu głównego w projekcie przewidziane są dwa
menu poboczne – jedno uywane częściej, drugie rzadziej. W pierwszym
znajdą się trzy przyciski:
– słuące do wylogowania się uytkownika z serwisu. Wprawdzie
zamknięcie okna przeglądarki będzie równoznaczne z wylogowaniem się,
jednak uytkownicy czują się bardziej bezpiecznie, mogąc w kadej chwili
jawnie przerwać swoją sesję z systemem87,
WYLOGUJ
PROFIL
POMOC
– po kliknięciu którego uytkownik będzie mógł zmienić swoje
ustawienia dotyczące systemu,
– kontekstowy system pomocy, opisujący szczegółowo tę część
serwisu, w której uytkownik aktualnie się znajduje.
Pomocnicze menu poboczne składa się z czterech przycisków:
KONTAKT – umoliwiający wysłanie e-maila z uwagami bądź pytaniami osobie
opiekującej się serwisem (najlepiej, aby był to po prostu adres e-mail),
– przenoszący do podstrony z informacjami o serwisie, autorach
serwisu i technologiach uytych przy jego tworzeniu (te informacje mogą
zainteresować studentów),
O SERWISIE
PRZESZUKAJ SERWIS
MAPA SERWISU
– pozwalający uytkownikowi na przeszukanie zawartości
całego serwisu pod kątem wybranych słów kluczowych. Naley zauwayć,
i szukanie będzie dostępne take w bardziej przystępnej formie – np.
pola tekstowego na głównej stronie czy niektórych stronach pobocznych,
jednak uytkownik powinien mieć dostęp do szukania z kadej strony
serwisu88.
– wyświetlający dokładną hierarchiczną mapę serwisu
zawierającą informacje i odnośniki do wszystkich podstron, rzecz
niezbędną w przypadku tak rozbudowanego serwisu.
Oprócz tych czterech opcji czasami będzie się pojawiać take przycisk WERSJA
DO DRUKU, umoliwiający obejrzenie aktualnej strony w wersji przeznaczonej
87
88
Jakob Nielsen, Security & human factors, listopad 2000, serwis useit.com
Jakob Nielsen, Search and you may find, lipiec 1997, serwis useit.com
(http://www.useit.com/alertbox/9707b.html).
do wydruku (np. z uboszą grafiką, inaczej dobranymi czcionkami,
odpowiednimi marginesami).
Ze względu na przyzwyczajenia uytkowników i konwencje wykorzystywane
w innych serwisach pierwsze menu poboczne powinno być umieszczone
w okolicach góry ekranu, natomiast drugie – na dole.
Komplementarny w stosunku do menu powinien być tytuł strony, zazwyczaj
widoczny w pasku okienka przeglądarki. Oprócz nazwy serwisu powinien
zawierać take tytuł aktualnie odwiedzanej strony w serwisie – pozwoli to
z jednej strony na szybsze zorientowanie się, w którym miejscu serwisu
znajduje się uytkownik, a z drugiej strony na duo bardziej efektywne
wykorzystywanie zakładek (ang. bookmarks) lub systemu nawigacji
w przeglądarce89.
Kolejnym elementem nawigacji powinno być logo, umieszczone zawsze
w tym samym miejscu, i tradycyjnie przenoszące uytkownika do głównej
strony serwisu90. Po prawej stronie logo natomiast, w pobliu przycisku
WYLOGUJ znajdować się powinno imię i nazwisko oraz funkcja aktualnie
zalogowanej osoby, z jednej strony aby wykluczyć wszelkie pomyłki, z drugiej
natomiast upewniając uytkownika, e serwis wcią dostosowuje się do jego
ustawień i wymagań.
3.3.3.
Nazwa i adres serwisu
Wybrana nazwa serwisu powinna być prosta i łatwa do zapamiętania,
podobnie jak adres WWW, pod którym jest ona dostępna. Naley pamiętać,
i uytkownicy będą musieli wpisać go w oknie przeglądarki i jeśli w tym
momencie będą musieli zastanawiać się i przypominać sobie, jak on brzmi,
wówczas znacznie zmniejszy się wygoda korzystania z serwisu.
W miarę moliwości naleałoby umieścić serwis jako stronę startową
w przeglądarkach ogólnodostępnych na wydziale komputerów (lub jako
stronę startową wybrać stronę Wydziału Informatyki, a tam w wyraźnym
miejscu umieścić odnośnik do serwisu informacyjnego). Ponadto korzystając
z mechanizmów zawartych w systemach operacyjnych mona ustalić
domyślną domenę, tak, aby uytkownicy mogli wpisać jedynie nazwę systemu
(bez przyrostka .wi.ps.pl), aby dostać się do serwisu91.
Dodatkowo warte uwagi jest takie skonfigurowanie serwera WWW, aby
większość podstron była dostępna bezpośrednio po wpisaniu intuicyjnego
adresu http://adreswitryny/menu lub http://adreswitryny/menu/
89
90
91
Jakob Nielsen, Microcontent: headlines and subject lines, wrzesień 1998, serwis useit.com
Jakob Nielsen, Ten good deeds in web design, październik 1999, serwis useit.com (http:
//www.useit.com/alertbox/991003.html).
Stworzony przez autora serwis intranetowy w Akademickim Centrum Informatyki nazywa
się po prostu... Intra, a dostać się do niego mona wpisując w oknie przeglądarki pięć liter
– intra właśnie.
podmenu.
Przygotowanie takiej konfiguracji nie powinno zająć duo czasu92,
natomiast znakomicie ułatwi uytkownikom korzystanie z serwisu.
3.3.4.
Wersje serwisu
Aczkolwiek większość aktualnie wykorzystywanych przeglądarek
internetowych93 wyświetla strony WWW w zbliony sposób, nie mona
zapomnieć o badaniach z rozdziału 2.4.1, które wykazały, i na komputerach
Wydziału Informatyki wcią korzysta się ze starszych bądź uboszych
przeglądarek, takich jak Netscape Navigator 3.x czy Lynx.
Konieczne więc będzie stworzenie trzech wersji interfejsu serwisu:
dla przeglądarek najnowszej generacji (Internet Explorer 5.0 i lepsze,
Mozilla 5.0, Netscape 6.x i 7.x),
dla uboszych przeglądarek lub wolniejszych łącz,
dla przeglądarek tekstowych.
Oczywiście nie wymaga się przygotowania trzech zupełnie oddzielnych
wersji serwisu – umiejętnie zaprogramowane skrypty CGI powinny wykryć
wykorzystywaną przeglądarkę i automatycznie dostosować wygląd serwisu do
uzyskanych danych, aczkolwiek nie naley pozbawić uytkownika moliwości
ręcznego wyboru wersji (np. w przypadku słabego łącza moe on optować za
wersją drugą, nawet jeśli ma nowoczesną przeglądarkę).
Ze strony osób przygotowujących serwis konieczne będzie zwrócenie uwagi
na dokładne opisywanie za pomocą tekstu elementów graficznych (tagi title
i alt w HTML) oraz regularne sprawdzanie wyglądu strony we wszystkich
trzech konfiguracjach.
Oprócz tych trzech wersji czasami będą obecne take inne:
wersja do druku – aktualna strona sformatowana tak, aby mona ją było
bez problemu wydrukować (w grę będzie tu wchodziło zmniejszenie ilości
grafiki na stronie i wybranie czcionki lepiej wyglądającej w druku),
wersja „eksportowa” – czyli aktualnie wybrane dane (np. plan zajęć) przekonwertowane do formatu umoliwiającego bezpośrednie wykorzystanie
tych danych przez oprogramowanie uytkownika – moe to być format
tekstowy lub XML.
3.3.5.
Wygląd serwisu
Ze względu na wykorzystywaną na Wydziale Informatyki bazę sprzętową,
konieczne będzie upewnienie się, i witryna wygląda poprawnie w roz-
92
93
URL howto, serwis PHP.net (http://www.php.net/urlhowto.php).
Zeitgeist, serwis Google (http://www.google.com/press/zeitgeist.html).
dzielczości 640x480, chociaby dla jej bardziej „ubogiej” wersji. Podobnie
powinna być ona czytelna nawet dla konfiguracji z szesnastoma kolorami.
Wersja dla nowoczesnych przeglądarek nie będzie miała takich ograniczeń
– minimalna rozdzielczość to tutaj co najmniej 800x600, a liczba kolorów to
zazwyczaj 16 milionów (ang. true color), jednak oczywiście nie naley tutaj
ślepo wykorzystywać tych moliwości tylko dlatego, i są one dostępne. Naley
w zamian pamiętać o sprawdzeniu wyglądu strony w rónych warunkach, np.
przy powiększonych czcionkach czy wyłączonych obrazkach.
Przy projektowaniu interfejsu powinno się zrezygnować z ramek (ang.
frames). Ramki przy wszystkich swoich zaletach wprowadzają dość duo
problemów (takich jak utrudniona nawigacja, kłopotliwe tworzenie
zakładek, niezgodność z przeglądarkami tekstowymi), a ich funkcjonalność
mona aktualnie bez problemu zastąpić zagniedzonymi w razie potrzeby
tabelami94.
Wykorzystanie grafiki na stronie powinno być w miarę moliwości skromne
– naley pamiętać, i jest to przede wszystkim serwis i n f o r m a c y j n y ,
tak więc jakiekolwiek elementy nie niosące ze sobą informacji powinny
być wyeliminowane. Dopuszcza się stosowanie ikon czy piktogramów, jeśli
będą one przekazywały informacje w sposób bardziej przyswajalny ni
odpowiadający im tekst. Szczególnie naley uwaać na jakiekolwiek elementy
animowane, które skupiają na sobie większą część uwagi uytkownika
i z tego powodu ich wykorzystanie powinno być bardzo uzasadnione95.
Grafika powinna być równie oszczędna ze względu na jej wielkość,
przekładającą się bezpośrednio na czas ładowania strony. Witryna powinna
być skonstruowana w taki sposób, aby czas wczytywania się kadej z podstron
zajmował optymalnie ok. sekundy, z górną granicą wynoszącą 10 sekund
(badania wykazują, i w przypadku przekroczenia tego limitu uytkownik
przestaje skupiać się na okienku przeglądarki96).
3.3.6.
Kolorystyka
Dobranie odpowiednich kolorów ma ogromne znaczenie dla czytelności
serwisu i prezentowanych w nim informacji, jednak nawet profesjonalne
badania nie dadzą nam „złotego przepisu” na najodpowiedniejszą kolorystykę
witryny97. Bez wątpienia naley jednak zastosować zestaw kolorów moliwie
estetycznie przyjemny i nie męczący oczu, a take zdecydować się na ciemny
94
95
96
97
Jakob Nielsen, Frames suck (most of the time), grudzień 1996, serwis useit.com
Jakob Nielsen, Top ten mistakes revisited three years later, maj 1999, serwis useit.com
Jakob Nielsen, Response times: the three important limits, op. cit.
Alyson L. Hill, Readibility of websites with various foreground/background color
combinations, font types and word styles, Department of Psychology, Stephen F. Austin
State University, 1997 (http://hubel.sfasu.edu/research/AHNCUR.html).
tekst na jasnym tle (odwrotna kombinacja jest mniej czytelna, szczególnie na
słabszych monitorach).
Naley te stosować jednolite kolory w obrębie całego interfejsu – jeśli, dla
przykładu, odnośniki są przedstawiane w kolorze niebieskim, powinny być
pokolorowane w taki sposób w całym serwisie tak, aby uytkownik szybko
powiązał kolor niebieski z moliwością klikania.
Pamiętać trzeba równie o tym, i kolor nie powinien być jedynym nośnikiem
informacji – badania wykazują, i ponad 10% osób siadających przed
monitorami ma pewne zaburzenia postrzegania kolorów i w trosce o nich
naley informacje wyróniać take innymi metodami98.
Umiejętne wykorzystywanie kolorów moe take zwiększyć produktywność
– np. przyciemnianie co drugiego wiersza w tabelce pozwala na optyczne
odizolowanie poszczególnych linijek i w rezultacie szybsze przetworzenie
informacji.
W projekcie interfejsu na potrzeby tej pracy zdecydowano się na czarny tekst
na białym tle, a elementy interfejsu przedstawiono w odcieniach szarości
bądź brudnej zieleni. Przewiduje się jednak moliwość wyboru jednego
spośród kilku preferowanych kolorów interfejsu dla kadego uytkownika
serwisu indywidualnie.
Czcionki
3.3.7.
Wygląd czcionki, którą prezentowane są informacje, jest równie wany co
kolory tekstu. Naley jednak pamiętać, i niektóre tradycyjne wytyczne
typograficzne mogą być tutaj chybione, gdy ekran komputera róni się
znacznie od kartki papieru (od orientacji począwszy na rozdzielczości
skończywszy). Dla przykładu, przy małych rozmiarach nie są polecane czcionki
szeryfowe (takie jak np. Times New Roman), gdy szeryfy99 zmniejszają tylko
czytelność100.
Naley take pamiętać o problemie dostępności czcionki na komputerach
wyświetlających witrynę. Niestety, istniejące mechanizmy dołączania
czcionek do stron WWW101 pozostawiają wiele do yczenia, tak więc wybór
zawęa się do kilku (kilkunastu) czcionek obecnych domyślnie w tych
systemach operacyjnych, z których korzystają odwiedzający witrynę.
Dla serwisu informacyjnego wybrano bezszeryfową czcionkę Arial
o wielkości 9 punktów. Czcionka ta obecna jest domyślnie w systemie
Windows począwszy od Windows 3.0, a take moliwa do ściągnięcia
98
99
100
101
Bruce Tognazzini, First principles, op. cit.
W poligrafii: krótkie ukośne lub poprzeczne zakończenia kresek tworzących litery.
Joe Gillespie, Font comparison, maj 2002, serwis Web page design for designers:
typography (http://www.wpdfd.com/wpdfonts2.htm).
Font embedding on the Web, kwiecień 2002, serwer Microsoft
(http://www.microsoft.com/typography/web/embedding).
z witryny Microsoft Typography102. W wypadku nieobecności czcionki Arial
zastosowana zostanie popularna bezszeryfowa czcionka Helvetica (obecna
na komputerach typu Macintosh). Zdecydowano się take na zwiększenie
interlinii (odstępów między wierszami) do 140%, aby zwiększyć czytelność
większych bloków tekstu.
Do tekstów pobocznych i mniejszych przycisków zastosowana została czcionka
ekranowa Verdana (obecna standardowo w Windows 98 i późniejszych
wersjach), natomiast dla graficznych przycisków zastosowano wygładzoną
czcionkę Futura Medium Condensed.
3.3.8.
Technologie
W serwisie nie zostanie wykorzystana wszechobecna technologia Macromedia
Flash, poniewa jej zastosowanie nie byłoby w aden sposób uzasadnione,
a ponadto wprowadziłoby to wiele trudnych do uniknięcia problemów103.
Wykorzystanie JavaScript do manipulacji HTML jest dozwolone, jednak pod
warunkiem i zostanie dokładnie przetestowane na okoliczność działania
w rónych przeglądarkach i nie będzie konieczne do korzystania z serwisu
(innymi słowy z serwisu będzie mona korzystać w optymalny sposób take
po wyłączeniu JavaScript). Nie naley równie „zasłaniać” się technologią
JavaScript
np.
przy
weryfikacji
danych
wprowadzanych do formularzy, gdy mimo i
jest to duo prostsze, to
w tym wypadku naley to
do obowiązków skryptu
umieszczonego na serwerze104.
Rysunek 22
Projekt interfejsu
serwisu
informacyjnego
W przypadku samego
języka HTML naley
zwrócić uwagę na to, aby był on interpretowany jednakowo (a przynajmniej
podobnie) na wszystkich wykorzystywanych przez uytkowników
przeglądarkach, począwszy od tekstowego programu Lynx, a skończywszy na
najnowszej wersji Internet Explorer czy Mozilli.
3.3.9.
Projekt interfejsu
Na rysunku 22 przedstawiono przykład interfejsu, w którym starano się
zawrzeć wszystkie wymienione powyej załoenia.
102
http://www.microsoft.com/typography.
103
Jakob Nielsen, Flash: 99% Bad, październik 2000, serwis useit.com
Wszystkie kolejne prezentowane w tej pracy przykłady stron będą
prezentowane w oparciu o ten interfejs. Oczywiście naley go traktować
bardziej jako wstępny szkic ni ostateczną wersję interfejsu – dla przykładu
mona sobie wyobrazić większą liczbę piktogramów, naleałoby take
przetestować interfejs w 16 kolorach a take przygotować jego bardziej
„ubogie” wersje.
3.4.
Projekt poszczególnych
elementów serwisu
W kolejnych podrozdziałach przedstawiony będzie opis i przykłady interfejsu
poszczególnych elementów serwisu. Kolejność i szczegółowość opisu tych
elementów została wybrana ze względu na wyniki ankiety przeprowadzonej
wśród studentów Wydziału Informatyki.
3.4.1.
Uwierzytelnianie i autoryzacja
W przypadku bezpiecznych systemów uwierzytelnianie i autoryzacja
są dwoma etapami koniecznymi do tego, aby uytkownicy mogli z nich
w pełni korzystać. Uwierzytelnianie to identyfikacja uytkownika, z reguły
wymagająca podania identyfikatora (tzw. loginu) oraz nieznanego nikomu
oprócz uytkownika hasła105. Jeeli uytkownik poda poprawny identyfikator
i hasło, system zakłada e jest on osobą, której odpowiada identyfikator
i przechodzi do autoryzacji, czyli ustalenia przysługujących mu uprawnień
do oglądania lub modyfikacji obiektów w systemie106.
Uwierzytelnianie jest w serwisie informacyjnym konieczne z przynajmniej
kilku względów. Przede wszystkim umoliwia korzystanie z takich usług
jak przesyłanie wiadomości, poczta e-mail, for dyskusyjnych – tam, gdzie
konieczna jest stuprocentowa pewność, e jedynie dana osoba ma dostęp
do przeznaczonych dla niej wiadomości i odwrotnie, e wysyłane przez nią
wiadomości są na pewno jej autorstwa. Po drugie, umoliwia personalizację,
czyli dostosowanie wyświetlanych wiadomości do danych lub yczeń
uytkownika (np. wyświetlanie tylko tych zajęć, w których musi brać udział,
lub jedynie tych elementów witryny, które chce oglądać). Po trzecie, pozwala
uytkownikowi na podanie systemowi poufnych danych (takich jak np. numer
telefonu komórkowego, na który będą wysyłane informacje o odwołanych
104
105
106
Stephanos Piperoglou, How not to build a Web application, kwiecień 2002, serwis
WebReference (http://www.webreference.com/html/watch/standards), str. 3.
Frequently asked questions about today’s cryptography, praca zbiorowa, RSA Laboratories
2000, str. 45.
Authorization, kwiecień 2002, serwis Webopedia.com
(http://www.webopedia.com/TERM/a/authorization.html).
zajęciach za pomocą usługi SMS107) bez obaw, i będą je mogły obejrzeć inne
osoby. W przypadku ewentualnego rozbudowania systemu o przechowywanie
ocen taki wymóg jest wręcz koniecznością.
Autoryzacja natomiast wymagana jest dlatego, i kada osoba znajdująca
się w systemie ma jedynie pewien konkretny, określony zestaw uprawnień.
Dla przykładu, pracownicy dziekanatu będą ich mieli naturalnie więcej ni
wykładowcy, natomiast ci z kolei więcej ni studenci.
Chocia istnieją równie inne metody uwierzytelniania (takie jak np.
biometria czy karty chipowe), ze względu na ich małą popularność konieczne
będzie skorzystanie z tradycyjnego duetu login
login/hasło. Ze względu na
wygodę uytkowników i obecność w sieci Wydziału Informatyki systemu
kont opartego o usługi katalogowe, najkorzystniejsze będzie zintegrowanie
serwisu informacyjnego z tym systemem, tak aby spełnić postulat single signon (do korzystania przez uytkownika ze wszystkich usług systemu konieczne
jest pojedyncze uwierzytelnienie za pomocą jednej pary login/hasło108).
Chocia moliwe byłoby stworzenie osobnego systemu kont przeznaczonego
tylko dla serwisu informacyjnego, jest to niepoądane z kilku powodów:
kady dodatkowy identyfikator poza tym, z którego uytkownicy korzystają
praktycznie na codzień (np. numer albumu lub numer pracownika) będzie
trudniejszy do zapamiętania, a co za tym idzie duo mniej wygodny,
chocia wydawałoby się, i większa ilość kont i haseł zwiększa
bezpieczeństwo systemu, paradoksalnie sytuacja jest odwrotna, jeśli
wziąć pod uwagę czynnik ludzki i skłonność do jawnego zapisywania
przez uytkowników w czasem widocznych miejscach haseł, których nie
potrafią zapamiętać109,
stworzenie ok. 3000 (na dzień dzisiejszy) kont i późniejsza ich
synchronizacja z kontami usług katalogowych przysporzyłaby wiele pracy
i potencjalnie otworzyłaby furtkę z wieloma błędami.
Oczywiście konieczne będzie dodanie kilku dodatkowych kont, np. dla
administratora systemu, gościa lub osób z zewnątrz mogących dodawać
zewnętrzne informacje (np. newsy). Jeśli chodzi o konto gościa (ang. guest
account) naley zwrócić uwagę i – w przeciwieństwie do np. portali – serwis
nie daje moliwości obejścia systemu uwierzytelniania/autoryzacji, jednak
konto umoliwiające dowolnej osobie wejście do systemu i ograniczone
obejrzenie jego działania jest jak najbardziej poądane, po to chociaby, aby
zachęcić abiturientów do rekrutacji.
Przykładowa strona autoryzacji jest przedstawiona na rysunku 23.
107
108
109
Ang. Short Message Service, usługa pozwalająca na przesłanie krótkich wiadomości
tekstowych osobom posiadającym telefony komórkowe.
Jakob Nielsen, Security & human factors, listopad 2000, serwis useit.com
Tame.
Widać tutaj obok spodziewanych dwu pól na wpisanie identyfikatora oraz
hasła take trzy przyciski. POMOC słuy do przywołania ekranu pomocy,
wyjaśniającego pokrótce działanie procesu uwierzytelniania (głównie jaki
identyfikator i hasło naley wpisać), dzięki KONTAKTOWI natomiast moliwe jest
bezpośrednie wysłanie e-maila do osoby opiekującej się serwisem w razie
jakichkolwiek problemów czy pytań ju na tym etapie.
Kolejny przycisk, ZAPAMIĘTAJ MNIE,
wymaga
dłuszego
objaśnienia.
Oczywiste jest, i pojawiające się
przy kadym wywołaniu serwisu
uwierzytelnianie moe być w niektórych
przypadkach
męczące
i właściwie zbędne. Takie przypadki
to np. logowanie się do systemu z prywatnych komputerów studentów
(bądź słubowych wykładowców). Poprzez zaznaczenie pola ZAPAMIĘTAJ MNIE
zgadzają się oni na załoenie przez serwis, i kade następne wejście będzie
dokonywała ta sama osoba i pominięcie etapu uwierzytelniania. Naturalnie
opcja ta powinna być wyłączona na ogólnodostępnych komputerach (np.
w salach laboratoryjnych), gdy pojawi się moliwość, i kolejna siadająca
przy komputerze osoba będzie zidentyfikowana jako poprzednia i zaistnieje
niebezpieczeństwo podszycia się pod nią.
Rysunek 23
Strona autoryzacji
Oprócz powyszej istnieje jeszcze kilka metod zwiększenia bezpieczeństwa
systemu. Często spotykane jest ograniczenie działania serwisu tylko do
komputerów z wewnętrznej sieci uczelni, jednak byłoby to rozwiązanie
stojące w sprzeczności z załooną wcześniej dostępnością. Mona jednak
przypisać niektóre newralgiczne funkcje systemu (np. wpisywanie godzin
rektorskich czy wszystkie uprawnienia administratora) nie tylko do
konkretnych osób, ale take i do konkretnych komputerów110. Dzięki temu
nawet w momencie przechwycenia loginu i hasła, podszywająca się osoba nie
będzie mogła wprowadzić zmian do systemu.
Serwis powinien umoliwiać take obsługę poprzez szyfrowane połączenie
SSL111 (protokół HTTPS), nieco wolniejsze, jednak praktycznie do zera
zmniejszające moliwość przechwycenia przez niepowołane osoby danych
przesyłanych między dwoma komputerami (np. hasła).
Na kadej z kolejnych stron powinien być obecny w widocznym miejscu
przycisk umoliwiający wylogowanie się bieącego uytkownika, nawet jeśli
wcześniej wybrał on opcję ZAPAMIĘTAJ MNIE.
3.4.2.
Strona główna
Oczywistym jest, e główna strona serwisu jest jego najczęściej
odwiedzanym miejscem, chociaby z tego powodu, i to od niej zaczyna się
110
Zastosować tutaj mona weryfikację adresu IP komputera.
zazwyczaj wędrówkę po
serwisie – w najbardziej
korzystnym przypadku
uytkownik będzie musiał jedynie uruchomić
przeglądarkę, aby znaleźć
się na głównej stronie
serwisu. Wykres 16
prezentuje częstotliwość
o d w i e d z a n i a
poszczególnych
sekcji
serwisu intranetowego
stworzonego przez autora
pracy.
Wykres 16
Popularność
poszczególnych
stron serwisu
intranetowego
Z wykresu wynika, i ponad 60% odwiedzin w całym serwisie przypada na
stronę główną. Z tego więc powodu naley zadbać o to, aby strona ta była
zaprojektowana w sposób gwarantujący jak największą przydatność, zarówno
jeśli chodzi o przedstawiane informacje, jak i moliwość dotarcia do kolejnych stron serwisu.
Na rysunku 24 obecny
jest przykładowy wygląd
strony głównej. Strona
została zaprojektowana
zgodnie z zasadą progressive disclosure, czyli
wyświetlaniu najpotrzebniejszych
informacji,
a przeniesieniu tych
rzadziej wykorzystywanych na kolejne podstrony112. Dzięki takiemu
rozwiązaniu w wielu przypadkach uytkownik nie
będzie musiał w ogóle
przechodzić do kolejnych
stron, gdy najwaniejsze
informacje znajdzie zebrane w jednym miejscu.
Oprócz przycisków nawigacyjnych omówionych
ju w rozdziale 3.3.2,
na ekranie znajdziemy
Rysunek 24
Strona główna
serwisu
informacyjnego
111
112
Frequently asked questions about today’s cryptography, op. cit., str. 154.
Jakob Nielsen, WebTV usability review, luty 1997, serwis useit.com
(http://www.useit.com/alertbox/9702a.html).
parę wydzielonych sekcji, odpowiadających poszczególnym aspektom
uczelnianego ycia113.
Na samej górze strony zawarte są
informacje o aktualnej dacie, okresie
roku akademickiego (semestr zimowy,
semestr letni, sesja zimowa, sesja
letnia, sesja jesienna, wakacje) oraz
– w przypadku semestru – o rodzaju
tygodnia (parzysty/nieparzysty). Ta
ostatnia informacja jest oznaczana
take charakterystycznym trójkątem
po prawej stronie.
„Chciałbym zauwayć, i na
stronie nie ma informacji o tym,
jaki aktualnie jest tydzień (N/P).
Najlepiej byłoby, gdyby istniała
lista podziału tygodni do końca
roku akademickiego – ja np.
nigdy nie wiem, jaki tydzień
Następnie pojawia się informacja
jest po jakiejkolwiek dłuszej
o tym, w jakich godzinach
w dzisiejszym dniu przewidziane
przerwie (święta, sesja, itd).”
są zajęcia dla osoby odwiedzającej
witrynę. Zgodnie z postulatami
zawartymi w rozdziale 1.3.4.2 jest to zdanie zbudowane w jak najbardziej
czytelny sposób, uwzględniające przerwy w zajęciach, godziny dziekańskie
i rektorskie oraz informacje o zaliczeniach. Dla przykładu, moe to być
informacja „Masz zajęcia od 8:15 do 18:00 z przerwą w godz. 12:00-16:15”.
Dzięki takiemu podaniu informacji wystarczy rzut oka aby zorientować się,
jak rozkłada się czasowo pobyt na uczelni w danym dniu.
Kolejną sekcją jest plan zajęć na kolejne dwa dni. W przypadku studentów
studiów dziennych będzie to zazwyczaj plan na dzień dzisiejszy i jutrzejszy
(lub, w przypadku weekendu, poniedziałkowy i wtorkowy), w przypadku
studentów studiów zaocznych – plan na kolejny zjazd. Oczywiście
informacja o tym, których dni dotyczy plan, musi być obecna i odpowiednio
dokładna114.
W przypadku zajęć podawane są kolejno: typ zajęć (np. ćwiczenia, wykłady,
laboratoria; kodowany kolorystycznie), nazwa zajęć, godziny trwania oraz
numer sali (plus ew. budynek, jeśli nie jest to budynek oznaczony jako
główny). Pozostałe dane (jak np. nazwisko prowadzącego) są w tym momencie
niepotrzebne i jedynie zaciemniałyby obraz, jednak oczywiście mona się do
nich dostać po kliknięciu na nazwę przedmiotu. W podobny sposób kliknięcie
na numerze sali przenosi do informacji o jej zajętości oraz umiejscowieniu,
natomiast kliknięcie na nazwie budynku – do podstawowych informacji
o nim oraz sposobie dotarcia na miejsce.
Wyświetlane zajęcia powinny dotyczyć jedynie osoby, która aktualnie korzysta
z systemu. W razie konieczności powinny być one równie uzupełnione
113
114
Lub te, w zaleności od punktu widzenia, rónym bazom danych zawartym na serwerze.
W przypadku np. dni odległych o więcej ni tydzień naleałoby ju podać konkretną datę,
wcześniej wystarczą jedynie określenia typu „dzisiaj”, „jutro”, „pojutrze”; obowiązkowy
powinien być z kolei dzień tygodnia.
o informacje o zaliczeniach lub egzaminach odbywających się w danym
dniu. Jeeli w danym momencie (np. z powodu wakacji) niemoliwe jest
wyświetlenie planu zajęć, powinien informować o tym stosowny komunikat.
Umieszczoną niej sekcją są wiadomości otrzymane w obrębie serwisu.
Powinny być tutaj wyświetlane jedynie najnowsze, nie przeczytane
wiadomości, w następującej postaci:
piktogram określający wysoką waność informacji (wykrzyknik),
tytuł wiadomości,
autor wiadomości,
adresat wiadomości (jeśli nie jest to jedynie aktualnie zalogowany
uytkownik systemu),
godzina i ewentualnie data przesłania wiadomości.
Kliknięcie na tytule pozwala uytkownikowi na przeczytanie całej treści listu,
natomiast na autorze – dotarcie do informacji o nim.
W podobny sposób co wiadomości przedstawiane są oficjalne ogłoszenia,
aczkolwiek brakuje w nich informacji o adresacie (są kierowane z reguły do
wszystkich, do pracowników bądź do studentów), w zamian za to moe być
wyświetlana komórka, do której naley autor listu (np. dziekanat).
Ostatnią pozycją w lewej części strony głównej są odnośniki do przydatnych
stron – domyślnie mogą to być np. witryny Wydziału Informatyki,
Politechniki Szczecińskiej czy popularnego wśród studentów Infoludka
(http://www.infoludek.pl), jednak z moliwością ich zmiany oraz dopisania
własnych odnośników.
Po prawej stronie ekranu, w węszej kolumnie znajdują się równie cztery
sekcje. Pierwsza z nich to informacja o nowych, nieodebranych jeszcze
listach e-mail (poniewa do uwierzytelniania jest wykorzystywany ten sam
identyfikator oraz hasło, serwis moe bezpośrednio spytać serwer pocztowy
o te dane). Kliknięcie na odnośnik przenosi uytkownika bezpośrednio do
skrzynki pocztowej dostępnej z poziomu WWW.
Kolejną pozycją jest fragment kalendarza przedstawiający aktualny miesiąc
oraz zapisane wcześniej osobiste wydarzenia na bieący i kolejny dzień.
Dni w kalendarzu są oznaczone odpowiednimi kolorami w zaleności od
wydarzeń w danym dniu, wane wydarzenia są oznaczone dodatkowo
odpowiednią ikonką, natomiast kliknięcie na danym dniu czy wydarzeniu
przenosi uytkownika bezpośrednio do kalendarza.
Następną sekcją jest panel szukania, pozwalający na odnalezienie stron,
przedmiotów, ogłoszeń czy osób odpowiadających wpisanym słowom. Naley
zauwayć, i jest to jedyne pole tekstowe na całej głównej stronie, przez
co uytkownicy automatycznie kojarzą je z polem szukania, co pozwala im
zaoszczędzić sporo czasu, gdy starają się dotrzeć do poądanej informacji115.
Ostatnim polem na stronie są odnośniki do popularnych wśród studentów
bramek SMS – kliknięcie na jednym z trzech symboli odpowiadającym
obecnym w Polsce sieciom komórkowym przenosi uytkownika bezpośrednio
do strony WWW pozwalającej przesłać SMS za pomocą Internetu.
Praktycznie kada z obecnych sekcji jest wyposaona w kwadratowy przycisk
ze strzałką w prawo, przenoszący odwiedzającego do odpowiedniej podstrony
serwisu dedykowanej wyłącznie wybranej sekcji, gdzie znajdzie więcej
interesujących go danych (poszczególne sekcje będą omówione w kolejnych
rozdziałach).
Naley take zauwayć, i kady przycisk czy odnośnik na stronie jest
wyposaony w etykietkę, dzięki której uytkownik wie dokładnie, gdzie
przeniesie się po wciśnięciu przycisku (dla przykładu, najedając na „Sprzęgi
informacyjne” pojawi się etykietka z napisem „Informacje o przedmiocie”).
Kady uytkownik moe take w swoim profilu zaznaczyć, które
z przedstawionych powyej sekcji go nie interesują i w związku z tym nie
powinny być wyświetlane na głównej stronie podczas jego sesji z serwisem.
Mona sobie wyobrazić take inne sekcje, jak np. „moja grupa” czy „moja
katedra”, prezentujące listę osób, z którymi się pracuje bądź odbywa
zajęcia.
Podczas pierwszej sesji uytkownika z serwisem przed stroną tytułową
powinna pojawić się strona startowa, przedstawiająca podstawowe informacje
dotyczące korzystania z serwisu. Pozwoli to nowym uytkownikom na lepsze
i szybsze poznanie serwisu, a take poprawi nieco ich samopoczucie na
nieznanym bądź co bądź terenie. Podobny mechanizm wprowadzających stron
startowych będzie obecny take w przypadku kolejnych sekcji serwisu.
3.4.3.
Plan zajęć
Plan zajęć, jako – co wynika
z przeprowadzonej ankiety i obecnych
był w postaci jakiejś bazy
obok komentarzy – zdecydowanie
najwaniejszy zbiór informacji dla
– sortowanie i przeszukiwanie
studentów, powinien być przygobardzo by pomogło.”
towany ze szczególną rozwagą. Proponuje się wprowadzenie następujących
sekcji (dostępnych jako menu drugiego poziomu pojawiające się po kliknięciu
na przycisku ZAJĘCIA w menu głównym):
„Dobrze by było, gdyby plan
strona startowa (oznaczana strzałką) – wprowadzenie do sekcji,
115
NAJBLISZE
LISTA
– plan zajęć na najblisze kilka dni,
– lista zajęć na cały tydzień, tylko dla studentów studiów dziennych
lub wieczorowych lub dydaktyków mających zajęcia ze studentami takich
studiów,
Jakob Nielsen, Search: visible and simple, maj 2001, serwis useit.com
– jak wyej, jedynie w formie
graficznej,
SIATKA
ZJAZDY
PRZEDMIOTY
– terminy zjazdów dla studentów studiów zaocznych,
– informacje o przedmiotach z planu zajęć,
ZALICZENIA – informacje o egzaminach
„Plan powinien być
przedstawiony w innej formie,
np. takiej, jaką mona dostać
na ksero. Ten obecny jest
nieczytelny!”
i zaliczeniach z przedmiotów.
Część z tych opcji moe być niedostępna dla określonych grup podczas
pewnych okresów czasu (np. sesja).
3.4.3.1.
Strona startowa
Po kliknięciu na przycisku
Rysunek 25
Zajęcia – strona
startowa
3.4.3.2.
ZAJĘCIA
powinna pojawić się strona startowa,
wprowadzająca
uytkownika w opcje
znajdujące się w sekcji
(vide rysunek 25).
Znaleźć na niej mona
opcje dostępne z pobocznego menu na górze
strony z dodatkowymi
opisami, a take funkcje
pomocnicze, takie jak
np. odwoływanie zajęć
w przypadku dydaktyków
czy dziekanatu. Podobnie
jak w przypadku strony
głównej dostępny jest
przycisk umoliwiający
wyłączenie tej strony
i przechodzenie bezpośrednio do planu zajęć na najblisze dni (oczywiście
uytkownik moe jawnie wywołać stronę startową klikając na strzałce
w menu).
Najblisze zajęcia
Po wybraniu opcji NAJBLISZE powinna pokazać się strona zbliona do tej
przedstawionej na rysunku 26. Znajdują się na niej zajęcia wypisane w sposób
podobny do tego na stronie głównej, jednak z rozszerzonymi informacjami.
Są to:
oznaczenie grupy, która ma dane zajęcia (po kliknięciu na nim przechodzi
się do strony z informacjami o składzie grupy i mona np. wysłać do niej
wiadomość),
nazwisko prowadzącego zajęcia (po kliknięciu na nim uytkownik jest
przenoszony do strony z informacjami o prowadzącym, m.in. pokoju,
w którym mona go znaleźć lub godzinach konsultacji dla studentów),
informacje o odwołanych zajęciach, oznaczanych w inny sposób (szarym
kolorem oraz przekreśleniem), z moliwością kliknięcia na adnotacji
„odwołane” i przeczytania informacji od prowadzącego,
informacje o zaliczeniach czy egzaminach, oznaczanych odpowiednią
ikonką i pogrubioną czcionką, z moliwością kliknięcia na adnotacji
„zaliczenie” („egzamin”, „kolokwium”, „wejściówka” itd.) i przeczytania
informacji o formie i zakresie zaliczenia,
informacje o konsultacjach, jeeli osoba zalogowana do systemu takie konsultacje prowadzi.
Dodatkowo w planie powinny być obecne take ewentualne zaliczenia
czy
egzaminy
poza
normalnymi godzinami
zajęć (szczególnie podczas sesji).
Na dole strony znajduje
się legenda tłumacząca
znaczenie poszczególnych
ikonek
(które
same
w sobie są opisane za
pomocą
etykietek).
Domyślnie
proponuje
się wyświetlanie planu
na
najblisze
pięć
lub sześć dni, jednak
istnieje
moliwość
wyświetlenia
dalszej
porcji zajęć poprzez
kliknięcie na przycisku
KOLEJNE DNI. Dwukrotne
wciśnięcie tego przycisku
na
kolejnych
stronach powinno być
równoznaczne z poleceniem
„poka
mi
Rysunek 26
wszystkie zajęcia do końca semestru/sesji”.
Naley zwrócić uwagę na odpowiednie oprogramowanie planu tak, aby
pokazywał on tylko te informacje, które są potrzebne. Dla przykładu, na
powyszym ekranie znajdują się tylko nazwy grup, bez podania lat czy
kierunku studiów. Jednak jeeli miałby być to plan dla prowadzącego zajęcia,
naley umieścić tyle informacji, ile jest koniecznych dla zorientowania się,
o które grupy chodzi. Podobnie jeśli wykładowca jedynie prowadzi zajęcia,
a sam nie uczestniczy w adnych, mona przy wyświetlaniu pominąć kolumnę
„prowadzący”. W przeciwnym przypadku powinno się w jakiś sposób
rozrónić zajęcia, które prowadzi uytkownik, np. poprzez odpowiednią
ikonkę w typie zajęć. Nawet w legendzie powinny pojawiać się jedynie
wykorzystane w planie ikonki.
Przy zajęciach, w których prowadzącym jest uytkownik, powinny
take
pojawić
się
przyciski
DODAJ ZALICZENIE i ODWOŁAJ ZAJĘCIA,
pozwalające
prowadzącemu
na
wpisanie/modyfikację danych zaliczenia dotyczącego tych zajęć, lub ich
odwołanie bądź przeniesienie.
„Obrana kolorystyka sprawia,
e informacje są nieczytelne,
o formacie informacji (data!)
nie wspomnę.”
W przypadku tej strony powinna pojawić się opcja WERSJA DO DRUKU pozwalająca
uytkownikowi na obejrzenie (i docelowo wydrukowanie) tych samych
danych w bardziej odpowiedniej dla drukarki wersji.
3.4.3.3.
Lista zajęć
Kolejna sekcja przedstawia uytkownikowi tygodniowy rozkład jego zajęć
(tak więc z oczywistych względów jest niedostępna dla studentów studiów
zaocznych lub pracowników mających zajęcia jedynie z takimi studentami).
Przykładowy rozkład mógłby wyglądać tak, jak na rysunku 27.
Widać, i w porównaniu z poprzednią sekcją pojawiła się nowa kolumna,
określająca graficznie rodzaj tygodnia, w którym odbywają się zajęcia (tydzień
parzysty, nieparzysty lub kady).
Dodatkowo po kliknięciu na pierwszych pięciu nagłówkach mona posortować
listę według danych z odpowiadających im kolumn (na powyszym ekranie
widać strzałkę oznaczającą
posortowanie
tabeli
podług dnia tygodnia).
Ponowne kliknięcie oznaczać będzie posortowanie
danych w odwrotnym
kierunku.
Rysunek 27
Lista zajęć
Po wciśnięciu przycisku
ZAAWANSOWANE uytkownik
moe
skorzystać
ze
strony
umoliwiającej
mu wyszukanie interesujących go zajęć innych
grup. Panel wyszukiwania
moe wyglądać tak, jak to
przedstawia rysunek 28
na kolejnej stronie.
Przy wyszukiwaniu zajęć moemy zdefiniować następujące parametry:
nazwa
przedmiotu
– serwis wyświetli
tylko te przedmioty,
których nazwa będzie
odpowiadała
tej podanej przez
uytkownika (lub zawierała ciąg znaków
podanych przez uytkownika),
Rysunek 28
Wyszukiwanie zajęć
typ przedmiotu – mona tutaj zawęzić wybór do ćwiczeń, laboratoriów,
wykładów, projektów bądź te innych zajęć,
budynek (i ew. sala), w której odbywają się zajęcia,
które zajęcia wyświetlać – powinien istnieć tu wybór pomiędzy zajęciami
własnymi (jako prowadzącego i/lub jako uczestnika), zajęciami własnego
roku (jeśli chodzi o studenta) oraz zajęciami wybranych lat z wszystkich
kierunków studiów,
prowadzącego lub komórkę, której zajęcia naley wyświetlić
(w przypadku komórki, np. katedry, bierze się pod uwagę wszystkie osoby
w niej zawarte)116,
dzień oraz tydzień – czy naley pokazywać zajęcia z tygodni parzystych,
nieparzystych, czy wszystkich, oraz z jakich dni,
po której kolumnie sortować dane – takie same moliwości, jak
w przypadku klikania na nagłówkach tabeli.
Po wciśnięciu przycisku WYŚWIETL serwis powinien pokazać wszystkie zajęcia
odpowiadające podanym kryteriom wyszukiwania. W przypadku braku takich
zajęć, powinien być wyświetlony odpowiedni komunikat sugerujący zmianę
kryteriów szukania na mniej ścisłe. W obu wymienionych wyej sytuacjach
na ekranie wcią powinien być dostępny panel wyszukiwania z wybranymi
ostatnio przez uytkownika danymi.
Dzięki temu panelowi moliwe będzie wydawanie skomplikowanych zapytań,
np. „poka wszystkie zajęcia prowadzone w Wydziale Informatyki przez
osoby z Katedry Grafiki, Przetwarzania i Rozpoznawania Obrazów” lub
„poka wszystkie laboratoria prowadzone w sali 315 w nieparzyste tygodnie”,
których wyniki mogą być bardzo przydatne np. w dziekanacie uczelni.
Podobnie jak w sekcji przedstawiającej najblisze zajęcia, take i tutaj powinno
ograniczyć się wyświetlanie do tylko tych kolumn, które są niezbędne (dla
przykładu, w przypadku wyświetlania tylko tygodni parzystych, kolumna
116
Z powodu potencjalnie duej ilości opcji w tym i poprzednich dwóch menu powinno się
przedstawić je w sposób moliwie wyraźnie oddający hierarchiczny podział, tj.
z wykorzystaniem wcięć i linii oddzielającej róne opcje.
z rodzajem tygodnia będzie niepotrzebna). Ta strona równie powinna być
wyposaona w przycisk WERSJA DO DRUKU.
3.4.3.4.
Siatka
Sekcja „siatka” jest odpowiednikiem powyszej sekcji, lecz zajęcia będą
przedstawione w formie graficznej, w postaci trójkątów odpowiadającym
rodzajowi tygodnia, na poziomej osi czasu reprezentującej cały tydzień
i poszczególne godziny. Trójkąty
powinny
być
pokolorowane
„Plan zajęć powinien być
w sposób odpowiadający rodzajowi
podany równie w formie
zajęć (niebieski – wykłady, czerwony
– ćwiczenia, itd.). Po skierowaniu ułatwiającej jego wydrukowanie
kursora myszki na dany trójkąt
i sciągnięcie. Czarne tło, ółte
powinny pojawiać się informacje na
temat przedmiotu, prowadzącego
i róowe napisy... Rozmiary
oraz sali (mona tutaj wykorzystać
tabeli... Trzeba się napracować,
JavaScript, jednak te same dane
eby doprowadzić go do stanu
powinny być zawarte w etykietce
obrazka).
uywalności.”
Tutaj
równie
dostępny
jest
zaawansowany
panel
szukania.
W przypadku wybrania więcej ni jednej grupy poszczególne grupy są
wyświetlane jedna pod drugą. Z uwagi na wygląd planu nie da się sortować
zajęć inaczej, ni podług dnia i godzin, tak więc opcje sortowania mona
pominąć.
3.4.3.5.
Rysunek 29
Zajęcia – zjazdy
Zjazdy
W tej opcji – dostępnej
tylko dla wykładowców
i studentów studiów
zaocznych – mona
zobaczyć
terminy
i numery kolejnych weekendowych
zjazdów,
z zaznaczonym najbliszym z nich. Kliknięcie
na wybranym dniu przenosi uytkownika do
kalendarza. Dodatkowo
serwis powinien wykrywać, czy w danym
dniu odbywają się zajęcia – jeśli np. wszystkie zostały odwołane, cały zjazd
powinien być zaznaczony odpowiednim kolorem.
3.4.3.6.
Przedmioty
Po wybraniu z drugiego menu opcji PRZEDMIOTY uytkownik serwisu uzyskuje
dostęp do odpowiedniej listy (pokazanej na rysunku 30) – domyślnie są
to przedmioty, w których student w danym semestrze uczestniczy bądź
przedmioty, które dydaktyk w danym semestrze prowadzi.
W przypadku oglądania zajęć, w których się uczestniczy, pojawia się
kolumna „prowadzący”, w której zawarte są nazwiska w s z y s t k i c h osób
prowadzących dany przedmiot. Dodatkowo na liście obecna jest liczba godzin
w semestrze, odpowiadającym danemu przedmiotowi, oraz rodzaj zaliczenia
końcowego.
Lista przedmiotów jest domyślnie posortowana podług nazwy przedmiotu,
a kady z przedmiotów jest przedstawiony jako odrębna sekcja. Dzięki
takiemu rozwiązaniu uytkownik moe postrzegać przedmiot jako jedną
całość, w której skład wchodzą laboratoria, wykłady i ćwiczenia. Oczywiście
istnieje te moliwość posortowania listy podług kadej z pozostałych kolumn
(oprócz typu zaliczenia).
Naley zauwayć, i na liście powinny być take obecne „jednorazowe”
przedmioty takie jak szkolenie biblioteczne czy BHP.
Podobnie jak w przypadku
listy
przedmiotów
powinna być obecna
opcja
ZAAWANSOWANE,
pozwalająca na wyświetlanie przedmiotów
take
innych
osób,
przefiltrowanych podług
zadanych
kryteriów.
I w tym wypadku powinny
pojawiać się piktogramy
oznaczające
zajęcia,
w których uczestniczy
uytkownik,
bądź
te, które uytkownik
prowadzi.
Rysunek 30
Zajęcia – przedmioty
Kliknięcie
na
typie
przedmiotu,
podobnie
jak kliknięcie na nazwie przedmiotu we
wszystkich poprzednio
opisanych sekcjach przenosi uytkownika do strony z informacjami o tym konkretnym przedmiocie
(rysunek 31).
Na tej stronie uytkownik moe zobaczyć wszystkie informacje dotyczącego
danego przedmiotu, takie, jak:
podstawowe
dane
o liczbie godzin, typie
zaliczenia itp.,
listę
prowadzących
ten przedmiot,
listę odbywających się
zajęć,
zagadnienia poruszane
na tym przedmiocie,
literaturę
miotu,
Rysunek 31
Informacje
o konkretnym
przedmiocie
z
przed-
listę
obecnych
w serwisie materiałów
dotyczących
tego
przedmiotu (jak na
przykład artykuły, opracowania, czy oprogramowanie).
Na górze ekranu obecne są przyciski umoliwiające szybkie przełączanie się
pomiędzy rónymi postaciami tego samego przedmiotu (jak np. ćwiczenia,
wykłady i laboratoria).
W przypadku studenta wyświetlane są informacje o jego zajęciach,
w przypadku innych osób – o wszystkich zajęciach, które mają róne grupy
studentów. Jeśli zalogowana osoba jest jedną z prowadzących dany przedmiot,
wówczas pojawiają się odpowiednie przyciski umoliwiające jej modyfikację
np. zagadnień lub literatury.
Dodatkowo moliwe jest dodanie własnego, osobistego komentarza do danego
przedmiotu, który będzie widoczny tylko przez danego uytkownika.
3.4.3.7.
Inne
Oprócz wymienionych stron powinna istnieć take moliwość dopisywania
przez prowadzącego nowego i edycji poprzednich zaliczeń, odwoływania zajęć
(take „grupowego”, w wypadku np. choroby bądź wyjazdu prowadzącego),
zmiany prowadzącego w przypadku konkretnych zajęć, zmiany terminu
konkretnych zajęć, itp. itd. Mimo i te opcje nie będą wykorzystywane
często, są kluczowe dla poprawnego działania serwisu.
Inną opcją powinna być strona przedstawiająca sposób wypełnienia indeksu
i kart egzaminacyjnych przed kadą z sesji – taka moliwość byłaby bardzo
mile widziana przez studentów, w świetle wyników przeprowadzonej
ankiety.
Opcje
3.4.3.8.
Na tej stronie uytkownik serwisu moe wybrać interesujące go opcje
dotyczące zajęć. Podstawową z nich będzie sposób informowania go
o odwołanych bądź przełoonych zajęciach. Domyślnie serwis powinien
wysyłać wtedy wiadomość do wszystkich zainteresowanych osób (przede
wszystkim studentów), jednak uytkownik powinien mieć moliwość
powiadamiania go take za pomocą e-maila bądź usługi SMS.
3.4.3.9.
Uwagi
Nie zwrócono do tej pory uwagi na sam fakt układania planu, wychodząc
z załoenia, i będzie on przygotowywany za pomocą zewnętrznej aplikacji,
a następnie dzięki odpowiednim filtrom importowany do bazy danych
serwisu informacyjnego. Istnieje jednak moliwość wbudowania modułu
układającego plan zajęć podług zadanych kryteriów w sam serwis, aczkolwiek
wykracza to poza zakres tej pracy117.
3.4.4.
Wiadomości
Czy istnieje sens tworzenia odrębnego systemu przesyłania wiadomości
poprzez WWW w serwisie informacyjnym, jeeli mona do tego celu
wykorzystać pocztę e-mail, która w wersji WWW i tak przewidziana jest jako
część serwisu? Mona znaleźć ku temu kilka powodów:
brak konieczności konfiguracji programu pocztowego na komputerze,
z którego się korzysta, co moe mieć due znaczenie w świetle ograniczeń
ogólnodostępnych terminali na uczelni,
duo większa integracja z serwisem – np. moliwość uzyskania
informacji o osobie wysyłającej wiadomość poprzez proste kliknięcie na
jej nazwisku, moliwość wysyłania informacji do określonych grup osób
(np. studenci, IV rok informatyki, grupa 441 itd.), silniejsze powiązanie
z usługami takimi jak fora dyskusyjne, moliwość stworzenia szablonów
dla podstawowych typów wiadomości,
działanie w czasie rzeczywistym (brak niepoądanych opóźnień
towarzyszących czasami przekazywaniu e-maili między serwerami
pocztowymi),
natychmiastowe sprawdzanie poprawności adresów wybranych
odbiorców oraz moliwość ich wyboru z listy (zamiast ręcznego
wpisywania),
oddzielenie wiadomości z systemu od zwykłej poczty e-mail (aczkolwiek
moe to być postrzegane jako wada),
117
Do tego problemu nawiązuje jeszcze jednak rozdział 3.6.4.
moliwość dołączania i wstawiania grafiki i załączników do przesyłanych
wiadomości (takie coś umoliwia take poczta e-mail w formacie HTML,
która jednak kryje w sobie wiele niebezpieczeństw i niedogodności),
uwzględnianie popularnych graficznych ikonek (smileyów
(smileyów).
Z obserwacji wynika, i systemy prywatnych wiadomości118 zintegrowane
z forum na WWW są bardzo popularne jako szybka, skuteczna i niekłopotliwa
metoda dotarcia do poądanej osoby, której zalety rekompensują podstawową
wadę, którą jest pozostawienie wszystkich informacji po stronie serwera
(i w rezultacie bycia uzalenionym od jego niezawodności).
Menu WIADOMOŚCI powinny towarzyszyć następujące pozycje podmenu:
strona startowa – podobnie jak w poprzednim przypadku wprowadzająca
uytkownika do sekcji,
3.4.4.1.
– czyli inaczej skrzynka odbiorcza, w której przechowywane są
otrzymane wiadomości,
WIADOMOŚCI
WYSŁANE
AUTOMATYCZNE
OPCJE
– katalog, w którym przechowywane są ju wysłane wiadomości,
– wiadomości wysyłane automatycznie w zadanych
odstępach czasu,
– pozwalająca na skonfigurowanie niektórych osobistych opcji
dotyczących wysyłania wiadomości.
Wiadomości
Ekran główny wiadomości, przedstawiony na rysunku 32, wygląda podobnie
jak skrzynka odbiorcza w kadym programie do obsługi poczty e-mail lub
serwisie do odczytywania poczty przez WWW.
Przedstawione są na
nim w postaci listy
kolejne wiadomości, domyślnie
posortowane
podług czasu otrzymania
(aczkolwiek kolejność sortowania mona zmienić
w opisany ju sposób).
W przypadku wiadomości
nie adresowanych jedynie
do uytkownika w kolumnie „do” powinien pojawić się adresat (np. IV rok
informatyki). Dodatkowo mogą być obecne ikonki oznaczające duą waność
wiadomości (wykrzyknik) oraz załączniki (spinacz). Pogrubiona czcionka,
zgodnie z popularną konwencją, oznacza wiadomości, które nie zostały
jeszcze przeczytane.
Rysunek 32
Wiadomości
118
Zwane w skrócie PM od angielskiego Private Messages.
Naley w tym miejscu119 nadmienić, i serwis nie będzie przechowywał
wiadomości a do momentu jawnego skasowania ich przez uytkownika.
Jest to wręcz nie zalecane, w świetle wcześniej wymienionych zastosowań
przekazywania wiadomości (szybki kontakt). Serwis powinien więc
automatycznie kasować p r z e c z y t a n e ju wiadomości po określonym
z góry upływie czasu (np. miesiąc). Jeśli uytkownik zayczy sobie zachować
kopię listu, będzie mógł przesłać ją sobie e-mailem za pomocą jednej
z wymienionych dalej opcji.
Po kliknięciu na autora bądź adresata wiadomości uytkownik powinien
zostać przeniesiony do odpowiedniego ekranu informacji, natomiast
kliknięcie na tytuł wiadomości otwiera ekran z treścią wiadomości, gdzie
powinny być widoczne tradycyjne informacje o wiadomości, jej treść, oraz
parę przycisków:
i POPRZEDNIA, pozwalające przenieść się bezpośrednio do innych
wiadomości bez wracania do ich spisu,
NASTĘPNA
ODPOWIEDZ
ODPOWIEDZ WSZYSTKIM
KASUJ
WYŚLIJ JAKO E-MAIL – umoliwiająca przesłanie kopii wiadomości pocztą e-mail
– umoliwiająca wysłanie odpowiedzi do autora wiadomości,
– jak wyej, jednak wysyłająca odpowiedź take do
adresata (opcja przydatna np. do kontynuowania dyskusji),
– nakazująca usunięcie wiadomości,
w celu jej archiwizacji (domyślnym adresatem powinien być uytkownik).
Tworzenie nowej wiadomości
3.4.4.2.
Po kliknięciu na jednym z dwóch przycisków ODPOWIEDZ, bądź te na przycisku
NOWA WIADOMOŚĆ znajdującym się na poprzednim ekranie, uytkownik
zostaje przekierowany do strony, gdzie moe napisać nową wiadomość bądź
odpowiedzieć na wskazaną.
Ponownie, większość z podanych tutaj opcji będzie pokrewna z programami
pocztowymi, jednak niektóre z nich będą wymagały szerszego omówienia.
Począwszy od góry, na ekranie powinny znaleźć się:
adresat (adresaci) – pole tekstowe, w którym uytkownik moe wpisać
imię i nazwisko osoby lub nazwę jednostki, do której kierowana jest
wiadomość. Obok widnieje take przycisk, umoliwiający wybranie
adresata z listy (ta opcja zostanie omówiona w dalszej części rozdziału),
temat wiadomości,
typ wiadomości – istnieje tutaj wybór pomiędzy wiadomością prywatną
(opcja zaznaczona domyślnie), wiadomością publiczną (jeśli wiadomość
tego typu skierujemy do pewnej jednostki, wówczas otrzymają ją take
osoby „zainteresowane” tą jednostką) oraz ogłoszenie (ta opcja jest
119
Oraz z pewnością w systemie pomocy serwisu.
dostępna tylko dla wybranych osób – jak np. pracowników dziekanatu –
i podana w ten sposób wiadomość jest wyświetlana na stronie głównej),
wysoka waność – oznaczone w ten sposób wiadomości będą wyróniane
w specjalny sposób jako bardziej znaczące,
treść – w tym polu uytkownik moe wpisać treść wiadomości. Dostępny
jest tutaj zestaw pomocniczych przycisków, które zostaną opisane
w dalszej części rozdziału,
załącznik – dzięki temu polu mona do wiadomości dołączyć plik (lub
pliki) znajdujące się na komputerze uytkownika.
Uytkownik moe wpisać ręcznie adresata w odpowiednie pole (w przypadku
więcej ni jednego adresata poszczególne wpisy mogą być oddzielane
przecinkami bądź średnikami) bądź skorzystać z opcji pozwalającej na
wybranie adresata (adresatów) z listy. Oczywiście w przypadku odpowiedzi
na wiadomość to pole będzie ju wypełnione.
Lista adresatów powinna ukazać się w nowym oknie, bądź – w przypadku
niemoności skorzystania z takiego rozwiązania120 – zastąpić aktualny ekran
pozwalając jednak do niego wrócić. Poniewa lista wszystkich adresatów
(a w to wliczone są oprócz osób fizycznych take wszystkie jednostki,
jak np. katedry) byłaby za długa, konieczne jest podzielenie jej na wiele
hierarchicznie powiązanych list. W przypadku kadej z nich moliwe będzie
dodanie wszystkich osób do listy adresatów, bądź wyświetlenie listy tych
osób po to, aby wybrać tylko niektóre z nich.
W pierwszym oknie mogłyby się pojawić następujące opcje:
„ostatni adresaci” – po jej wciśnięciu pojawiłaby się druga lista
z nazwiskami kilkunastu osób, do których wysyłano ostatnio listy,
„grupa 411”, „grupa 7 lab.”, „IV rok informatyki” – i inne grupy
(jednostki), których uytkownik jest członkiem; wybranie jakiejkolwiek
z nich spowoduje wyświetlenie nazwisk wszystkich członków (oprócz
uytkownika) w kolejnym oknie,
„studenci” – po wybraniu tej opcji w drugim oknie powinna pojawić
się lista grup studenckich, poczynając od opcji „wszyscy studenci”,
poprzez poszczególne kierunki, lata oraz grupy (informacje powinny być
prezentowane w sposób hierarchiczny),
„dydaktycy” – jak wyej, jednak z uwzględnieniem wszystkich katedr,
zakładów i innych jednostek, takich jak dziekanat,
„inne” – tutaj mona pomyśleć o wpisaniu innych grup, takich jak np.
„wszyscy starości lat”, „wszyscy starości grup”, „wszystkie osoby, z którymi
masz zajęcia”, „wszystkie osoby starsze ni 26 lat” i innych, szybki dostęp
do których moe być z jakichkolwiek powodów przydatny.
120
Np. przy przeglądarkach nie obsługujących JavaScript.
Uytkownik moe wybrać indywidualne nazwiska bądź grupy z dowolnej
listy klikając na nich121 i dodając do listy adresatów w oknie tworzenia
wiadomości.
W przypadku tworzenia treści wiadomości równie przewidziano kilka
ułatwień. Przede wszystkim moliwe jest skorzystanie z szablonów, tj. ju
przygotowanych wiadomości z lukami, które uytkownik powinien wypełnić.
Wśród szablonów mogą się znajdować np. wezwanie studenta do dziekanatu,
wnioski o zaliczenia warunkowe oraz informacje o konieczności złoenia
zaległych opłat. Takie rozwiązanie moe znacznie uprościć działalność
dziekanatu z jednej strony, oraz ycie studenta z drugiej. Lista szablonów,
podobnie jak adresatów, powinna wyświetlać się w dodatkowym oknie i być
dostosowana do uprawnień osoby, która tworzy wiadomość.
Przy samym tworzeniu treści moliwe jest korzystanie z kodu UBB122,
uproszczonego wariantu HTML, umoliwiającego podstawowe formatowanie
treści. Oprócz znaczników takich jak [b]...[/b], [i]...[/i] czy [u]...[/u]
(odpowiadających za pogrubienie, pochylenie i podkreślenie części tekstu)
uytkownik moe take za pomocą odpowiednich znaczników umieścić
w swojej wiadomości take odnośnik do zewnętrznej strony, adres e-mail,
numerowaną listę lub plik z grafiką. Wszystkie te opcje są dostępne take jako
przyciski przy polu z treścią. Takie rozwiązanie jest coraz bardziej powszechne
we wszelakich forach dyskusyjnych na WWW oraz np. księgach gości, tak
więc osobom obytym z tego typu witrynami w Internecie korzystanie z kodu
UBB nie powinno sprawiać adnych trudności.
Po wciśnięciu przycisku WYŚLIJ serwis powinien sprawdzić, czy wszystkie
pola zostały prawidłowo wypełnione. W szczególności konieczne jest
zweryfikowanie nazwisk wszystkich adresatów i w przypadku tych
wpisanych błędnie przez uytkownika zasugerować zmianę (lub, optymalnie,
wybór z listy osób czy jednostek o podobnie brzmiących nazwiskach bądź
nazwach). Następnie wiadomość moe ju zostać dostarczona do odbiorcy
(odbiorców).
Wiadomości wysłane
3.4.4.3.
Na tym ekranie będą wyświetlane wysłane ostatnio wiadomości, w podobny
sposób co wiadomości niedawno otrzymane, z odpowiednimi poprawkami
(np. nie będzie konieczne wyświetlanie autora, gdy zawsze będzie nim
uytkownik). Równie w analogiczny sposób wiadomości wysłane powinny
być kasowane po zadanym upływie czasu (np. trzech miesiącach) lub
w przypadku przekroczenia arbitralnej liczby wiadomości.
121
122
W przypadku grup poądanym dodatkiem byłaby umieszczona w nawiasach liczba osób
w danej grupie tak, aby nadawca miał pewne pojęcie, do ilu osób kieruje swoją wiadomość.
Nazwanego tak, gdy po raz pierwszy został wprowadzony w Universal Bulletin Board firmy
Infopop, por. http://www.infopop.com/products/ubbclassic.
3.4.4.4.
Wiadomości automatyczne
Na tej stronie, dostępnej tylko dla określonej grupy uytkowników (głównie
pracowników dziekanatu), mona zdefiniować listy rozsyłane automatycznie
w zadanych okresach czasu. Mogą to być informacje o:
powtarzających się co roku w tym samym okresie godzinach rektorskich,
rozpoczęciu sesji lub ferii,
konieczności złoenia indeksów do dziekanatu,
przyznaniu bądź wpłynięciu na konto stypendium,
konieczności przedłuenia legitymacji.
Uytkownik powinien mieć moliwość wyboru kiedy chce wysłać daną
wiadomość (opcje powinny być dość bogate, umoliwiając sformułowanie
nawet takich dat, jak np. „5 dni przed końcem semestru” czy te „kadego 7.
dnia miesiąca”), do kogo, oraz mieć wpływ na treść tej wiadomości. Powinna
istnieć take moliwość zatwierdzania wiadomości, tj. zamiast do docelowej
grupy osób wiadomość powinna w określonym dniu najpierw zostać wysłana
do autora celem weryfikacji i ewentualnej zmiany treści; oraz wstrzymywania
wysyłania danej wiadomości.
3.4.4.5.
Opcje
Na tej stronie uytkownik powinien mieć moliwość wybrania kilku opcji
dotyczących systemu wiadomości, jak np.:
dołączanie wybranej sygnaturki pod kadą wiadomością,
włączenie/wyłączenie automatycznego cytowania treści listu, na który
uytkownik odpowiada,
informacje e-mailem lub SMS-em w przypadku otrzymania wiadomości
oznaczonej jako wana,
korzystanie z kodu UBB przy tworzeniu listów,
przechowywanie wysłanych wiadomości bądź automatyczne kasowanie
ich.
3.4.5.
Konto
Kady z pracowników oraz studentów Wydziału Informatyki Politechniki
Szczecińskiej dostaje do swojej dyspozycji konto na jednym z serwerów,
będące jednocześnie kontem pocztowym, jak i miejscem do przechowywania
materiałów widocznych przede wszystkim z poziomu lokalnej sieci Wydziału.
Aczkolwiek obie części składowe konta są dostępne take z Internetu
(poczta dzięki protokołom POP3/IMAP, dane dzięki protokołowi FTP), jednak
idealnym rozwiązaniem byłoby udostępnienie tych zasobów take z poziomu
serwisu informacyjnego, co w niektórych przypadkach (np. korzystania
z obcego komputera podczas wyjazdu, vide rozdział 2.4.3) oszczędziłoby
zbędnej konfiguracji czy wręcz umoliwiłoby dostęp do konta.
Dostęp do poczty
3.4.5.1.
Poczta e-mail dostępna z poziomu przeglądarki WWW jest jedną z bardziej
popularnych usług, umoliwiając korzystanie z poczty nawet jeśli nie jest
moliwe bądź opłacalne zainstalowanie czy skonfigurowanie odpowiedniego
oprogramowania.
Ju w chwili pisania tej pracy studenci i dydaktycy mają dostęp do
poczty poprzez WWW, po wpisaniu w przeglądarce adresu https://
webmail.wi.ps.pl. Niestety, jest to typowa instalacja oprogramowania
IMP123, natomiast w przypadku wykorzystania poczty internetowej w serwisie
informacyjnym naleałoby stworzyć tę część od nowa bądź zaadaptować tak,
aby dopasować interfejs, a take lepiej zintegrować funkcjonalność tego
elementu z resztą serwisu.
Przede wszystkim naleałoby zadbać o to, aby obsługa poczty e-mail była jak
najbardziej podobna do podsystemu wiadomości, jednak z drugiej strony
upewnić się124, aby uytkownicy nie mogli pomylić obu części serwisu
i wiedzieli dokładnie, do czego słuy kada z nich125.
Dodatkowo na stronie głównej, o czym wspomniano ju w rozdziale
3.4.2, powinna pojawiać się informacja o nowych wiadomościach od
czasu ostatniego logowania się uytkownika. Mona take pokusić się
o dalszą integrację poczty e-mail z serwisem informacyjnym – w przypadku
otrzymania poczty od osoby posługującej się kontem Wydziału Informatyki
serwis mógłby umoliwiać uzyskanie informacji o tej osobie podobnie jak
w przypadku systemu wiadomości.
W przypadku implementacji systemu katalogów (folderów), ksiąki adresowej
oraz najpopularniejszych opcji konfiguracyjnych system poczty mógłby się
stać właściwie zastępnikiem oprogramowania pocztowego instalowanego na
poszczególnych stanowiskach. Równie wane wydaje się być jednak take
obudowanie systemu bardziej „niewidocznymi” funkcjami, jak chociaby
oprogramowaniem antywirusowym i filtrami chroniącymi uytkowników
przez pocztą reklamową126.
123
124
125
126
Więcej informacji o IMP mona znaleźć na stronie IMP Webmail Client
(http://horde.org/imp).
Dzięki systemowi pomocy, stronom wejściowym, odpowiednim szkoleniom, a take
zrónicowaniu interfejsu, chociaby poprzez zastosowanie rónych tytułów albo ikon.
Wane w tym przypadku będzie konsekwetne stosowanie oddzielnej terminologii dla
systemu wiadomości i systemu poczty e-mail.
Ang. spam.
3.4.5.2.
Dostęp do plików
W środowiskach, w których utrudniony lub niemoliwy jest dostęp do
programu pocztowego, równie kłopotliwy moe być dostęp do programu –
klienta FTP, pozwalającego na dotarcie do zgromadzonych na koncie danych.
Drugą opcją w menu KONTO powinna więc być moliwość dostępu do danych
z poziomu serwisu informacyjnego, bezpośrednio z przeglądarki WWW.
Wprawdzie wszystkie nowoczesne przeglądarki WWW obsługują take
protokół FTP, jednak umoliwiają jedynie ściąganie (ang. downloading),
tak więc nie będą wystarczające w tym przypadku, gdy konieczna jest tu
take moliwość umieszczania na koncie nowych plików (ang. uploading).
Naleałoby więc stworzyć swoistą bramkę, dającą moliwość zarówno
ściągania, jak i dodawania plików. Moe ona wyglądać podobnie, jak typowa
reprezentacja FTP na stronie WWW, mona te pokusić się o wygląd bardziej
zbliony do popularnych systemów operacyjnych, jak np. Windows.
3.4.5.3.
Inne
Oprócz tych dwu najwaniejszych opcji naley te przewidzieć inne
moliwości, wśród których znajdować będą się:
moliwość zmiany hasła dostępu do poczty e-mail oraz konta, i w rezultacie
do serwisu informacyjnego (oczywiście obwarowana odpowiednimi
komentarzami i zabezpieczeniami),
moliwość sprawdzenia zajętości konta FTP oraz konta pocztowego (take
w postaci procentowej),
ustawienie ewentualnego forwardu (automatycznego lub warunkowego
przekierowywania poczty na inne konto e-mail),
umoliwienie dostępu do baz danych (począwszy od października 2002
roku kady student ma mieć własne konto w systemie wydziałowej bazy
danych).
3.4.6.
Fora dyskusyjne
Oprócz opisanego wcześniej systemu przekazywania wiadomości niezmiernie
przydatny będzie system wielu for dyskusyjnych, umoliwiających wymianę
uwag i informacji między grupami zainteresowanych daną tematyką osób
(konkretną grupą laboratoryjną, osobami zatrudnionymi w danej katedrze,
osobami zainteresowanym programowaniem, itp. itd.)
Naley zauwayć, i chocia teoretycznie wystarczyłby do tego celu system
przekazywania wiadomości umoliwiający dostarczanie ich do więcej ni
jednego adresata jednocześnie127, jednak byłby duo bardziej kłopotliwy
w obsłudze ni osobne forum dyskusyjne.
3.4.6.1.
Wybór rodzaju forum dyskusyjnego
W Internecie zyskały ogromną popularność przede wszystkim trzy
mechanizmy grupowej dyskusji:
listy e-mailowe – oparte o pocztę
elektroniczną; e-mail wysyłany pod
adres listy trafia do wszystkich
zapisanych uytkowników,
„Powinno istnieć równie forum
na WWW lub jakakolwiek inna
grupy Usenetowe (zwane popularnie „newsami”) – oparte o protokół NNTP, zblione w obsłudze
do poczty elektronicznej128,
forma komunikacji pomiędzy
wszystkimi ludźmi na Wydziale
– eby jedni drugim mogli
forum WWW – oparte o protokół
HTTP, umoliwiające czytanie
i odpisywanie na wiadomości
z poziomu przeglądarki WWW.
pomagać lub ewentualnie coś
ogłosić.”
Analizując przedstawione w rozdziale 2.4.1.1 wyniki przeprowadzonej
wśród studentów ankiety widać wyraźnie, i kada z ww. metod dyskusji
ma w przyblieniu tyle samo zwolenników. Konieczne więc będzie dokładne
przeanalizowanie zalet i wad kadej z nich w celu wybrania najbardziej
odpowiedniej dla przedstawianego serwisu informacyjnego. Wady i zalety
przedstawione są w tabeli 3:
Tabela 3
Porównanie
najpopularniejszych
w Internecie metod
dyskusji
127
128
Listy e-mailowe
Grupy
Usenetowe
Fora na WWW
Wygoda obsługi
mała
średnia
średnia/dua
Dostępność
mała/średnia
mała
dua
Opcje
mała
bardzo mała
dua
Formatowanie
tekstu
z reguły nie
nie
tak
Załączniki
z reguły nie
z reguły nie
z reguły tak
Wymagania
dotyczące łącza
internetowego
małe
małe
due
Znajomość
wśród
internautów
bardzo dua
średnia
średnia
Tym bardziej, i w systemie przewidziana jest moliwość indywidualnego tworzenia grup
osób.
Chip Salzenberg, What is Usenet?, styczeń 1998, serwis Internet FAQ Consortium
(http://www.faqs.org/faqs/usenet/what-is/part1).
Wygoda obsługi – w przypadku list dyskusyjnych rozsyłanych poprzez e-mail
istnieją z reguły dwie moliwości: kada wiadomość trafia do uytkownika
w postaci zwykłego listu, bądź te po uzbieraniu się kilkunastu (kilkudziesięciu)
takich wiadomości są one wysyłane w postaci zbiorczej w jednym liście129.
O ile wykorzystując mechanizmy filtracji dostępne w kadym nowoczesnym
programie pocztowym moliwe jest ju skierowanie e-maili z listy dyskusyjnej
do odrębnego katalogu (dzięki czemu nie będą wymieszane z innymi
wiadomościami), jednak wcią śledzenie np. wybranego wątku wymaga
ręcznego przeglądania kadej wiadomości bądź te sortowania ich po tytule,
co zresztą nie zawsze daje oczekiwane rezultaty.
W podstawowe mechanizmy zarządzania wątkami wyposaone są grupy
Usenetowe, oprócz przyporządkowania wiadomości do odpowiedniego wątku
umoliwiając zazwyczaj na poziomie aplikacji z jednej strony ignorowanie
mało wanych tematów dyskusji, a z drugiej specjalne odznaczenie tych
interesujących.
Zdecydowanie najlepiej prezentuje się tutaj forum na WWW, oprócz bogatego
zarządzania wątkami (subskrypcja, edycja własnych wątków, kasowanie
wątków, ankiety) dające moliwość rozszerzenia forum o praktycznie
wszystkie wymarzone opcje.
Dostępność – listy e-mailowe wymagają dostępu do programu pocztowego
(który musi być odpowiednio skonfigurowany), ponadto konieczne jest
zapisanie się na daną listę z danego konta e-mail. Oczywiście większości
z tych kłopotów mona uniknąć stosując bramkę umoliwiającą dostęp
do poczty poprzez WWW, jednak technicznie takie rozwiązanie stoi ju
pomiędzy tradycyjną listą e-mailową a forum na WWW.
Grupy Usenetowe równie wymagają dostępu do odpowiedniego
oprogramowania (większość popularnych programów pocztowych130
umoliwia dostęp do grup dyskusyjnych) i znajomości adresu odpowiedniego
serwera NNTP.
Forum na WWW wydaje się tutaj najbardziej dostępne, gdy wymaga jedynie
tradycyjnej przeglądarki WWW.
Opcje – tutaj na najgorszej pozycji stoją zdecydowanie grupy Usenetowe
– wszystkie wiadomości trafiają do wszystkich czytelników w takiej samej
postaci i oprócz wspomnianych mechanizmów filtrowania grup/wątków
nie dają uytkownikom zbyt duego wyboru jeśli chodzi o kontrolę nad
zdobywanymi informacjami.
W przypadku list e-mailowych spotyka się często dodatkową moliwość
wyboru formatu przesyłanych listów (zwykły tekst lub WWW) oraz
wspomniane wyej generowanie listów zbiorczych zamiast pojedynczych
wiadomości.
129
130
Ang. digest.
Takich jak np. Outlook Express czy Mozilla Mail & News.
Forum na WWW daje tu zdecydowanie najwięcej moliwości, szczególnie
jeśli uwzględnić moliwości praktycznie nieograniczonej rozbudowy
z jednej strony i moliwości zintegrowania z innymi elementami serwisu
informacyjnego z drugiej. Połączonych jest tu wiele cech obu poprzednich
rozwiązań i parę dodatkowych funkcji, częściowo wynikających z samego
zastosowania WWW.
Formatowanie tekstu – w przypadku grup Usenetowych przyjęło się
stosowanie czystego tekstu131 bez jakichkolwiek ozdobników. Taka sama
reguła obowiązuje w przypadku większości list e-mailowych, aczkolwiek
w przypadku niektórych z nich umoliwia się korzystanie z e-maili pisanych
przy uyciu HTML, co moe być wykorzystywane dla lepszego formatowania
listu, jednak równie często bywa po prostu naduywane.
Dobrze przygotowane forum na WWW pozwala na wypośrodkowanie
tych dwu przedstawionych wyej skrajności, poprzez udostępnienie tylko
niektórych moliwości (pogrubienie, kursywa, graficzne smileye, dołączenie
obrazka), z reguły dzięki kodowi UBB.
Załączniki – chocia zarówno e-maile, jak i posty na grupach dyskusyjnych
umoliwiają dołączanie do wiadomości załączników w postaci plików,
zazwyczaj ta moliwość jest wyłączana w obawie przed naduyciami (wielu
subskrybentów wydaje się nie mieć świadomości, i np. czterystukilobajtowy
załącznik dołączony do własnej wiadomości będą musieli odebrać wszyscy
czytający daną listę/grupę).
Na forum korzystającym z WWW moliwe jest przedstawienie wszystkich
załączników jako odnośników przy danej wiadomości – uytkownik zgra je na
swój komputer i obejrzy dopiero na własne yczenie.
Wymagania dotyczące łącza internetowego – tutaj objawia się dua
przewaga grup dyskusyjnych i (przede wszystkim) list e-mailowych. Oba te
rozwiązania pozwalają na ściągnięcie wiadomości i następnie przeglądanie
ich w trybie offline. W przypadku forum na WWW jest to wprawdzie równie
moliwe, jednak bardzo utrudnione – poza tym samo „obudowanie” tekstu
kodem HTML i grafiką oznacza, i dla tego rozwiązania bardzo wskazane jest
posiadanie stałego połączenia z Internetem.
Znajomość wśród internautów – zarówno poczta elektroniczna jak i grupy
Usenetowe powstały jeszcze przed Internetem, tak więc są ju – szczególnie
e-mail – bardzo popularne i większość osób posługuje się nimi wręcz
intuicyjnie. Fora na WWW upowszechniły się stosunkowo niedawno i wiele
osób jeszcze nie miało z nimi styczności.
Patrząc na plusy i minusy trzech przedstawionych rozwiązań mona dojść
do wniosku, i rozwiązaniem najlepszym i najbardziej obiecującym jest
forum na WWW. Jego największa wada – konieczność posiadania stałego
łącza internetowego – przestaje mieć większe znaczenie w świetle
wyników ankiety przeprowadzonej wśród studentów (oraz samych załoeń
131
Ang. plain text.
serwisu), duo waniejsza wydaje się natomiast moliwość duej integracji
z pozostałymi elementami serwisu oraz zapamiętywania ustawień i preferencji
uytkownika niezalenie od środowiska (komputera), z którego korzysta do
przeglądania forum.
Wytyczne przy tworzeniu forum dyskusyjnego
opartego o WWW
3.4.6.2.
W przypadku forum tego typu przyjętą regułą jest hierarchiczny podział na
– kolejno – fora, wątki i posty132.
Forami dyskusyjnymi mogą być np.:
zamknięte fora dla poszczególnych kierunków studiów, lat, grup itp.
zamknięte fora dla poszczególnych jednostek – katedr, instytutów itp.,
otwarte fora tematyczne (muzyka, filmy, ycie uczelni),
zamknięte fora „prywatne” dla wybranych grup, zakładane przez
uytkowników,
otwarte fora „ogłoszeniowe” (kupię/sprzedam, zgubiono/znaleziono),
otwarte fora „techniczne” dotyczące samego działania serwisu.
Mona nawet pomyśleć o forach otwartych dla gości z zewnątrz, traktujących
np. o Szczecinie, wydarzeniach kulturalnych, itp. itd.
Kady uytkownik systemu jest domyślnie zapisany do for dyskusyjnych
dotyczących grup do których przynaley, i moe się zapisać do kadego
z innych otwartych for. W takim wypadku dostaje on informacje o nowych
wiadomościach w kadym z nich, a take moe brać udział w dyskusji
(oczywiście moliwe jest równie swobodne przeglądanie innych otwartych
for bez zapisywania się).
W kadym forum pojawiają się tematyczne wątki, a w kadym wątku obecne
są posty – czyli wiadomości – od zainteresowanych uytkowników. Kady
wątek ma swoją osobną stronę WWW, tak więc odwiedzający czyta tylko te
wiadomości, które go interesują.
Wszystkie funkcje (m.in. przeglądanie, dopisywanie, odpowiadanie i edycja
postów oraz rozpoczynanie nowych wątków) powinny odbywać się za
pomocą WWW, w sposób moliwie intuicyjny i zgodny z innymi elementami
serwisu (przede wszystkim przedstawionymi ju systemem wiadomości
oraz kontem pocztowym) oraz ze standardami de facto wytyczonymi przez
najpopularniejsze oprogramowanie tego typu (np. przedstawiony ju
Universal Bulletin Board133 czy vBulletin134).
132
Spolszczenie angielskiego post.
133
http://www.infopop.com/products/ubbclassic.
134
http://www.vbulletin.com.
Zintegrowanie systemu for dyskusyjnych z pozostałymi elementami serwisu
będzie dotyczyło m.in.:
przejścia do informacji o danej osobie (wykładowcy bądź studencie) po
kliknięciu na jej nazwisku,
przesyłania informacji o nowych postach w stworzonym przez uytkownika
wątku dzięki systemowi wiadomości (oczywiście na wyraźne yczenie
uytkownika),
automatycznego tworzenia for dyskusyjnych dla wszystkich obecnych
w systemie grup,
moliwości wysyłania postu na dane forum z poziomu systemu wiadomości
(w przypadku braku dostępu uytkownika do danego forum).
Dość wanym elementem do dokładnego przeanalizowania będzie dostęp
indywidualnych osób do poszczególnych for – niektóre z nich powinny
być zamknięte bez moliwości oglądania przez osoby niepowołane – oraz
informowanie uytkowników o tym, i zostali zapisani do nowych for, np.
tych powstających z początkiem kolejnego roku akademickiego z powodu
przetasowań w obrębie grup.
Ostatnim wanym elementem jest
„Studenci mogą nie mieć
kwestia zaufania do systemu, którą
zaufania do list dyskusyjnych
zgrabnie podsumowuje przedstawiony
obsługiwanych przez serwery
obok cytat jednego z ankietowanych.
Przy projektowaniu systemu naley
uczelniane i tym samym nie
wziąć pod uwagę równie i tę kwestię
korzystać z tych list.”
– przede wszystkim zapewniając, i
fora dyskusyjne nie są pod adnym
względem moderowane (cenzurowane) ani e nie mają do nich dostępu
osoby niepowołane (nawet administrator systemu).
3.4.7.
Informacje o wykładowcach
„Uwaam, e przydatne byłyby
wszelkie informacje dotyczące
wykładowców (plany zajęć, terminy
konsultacji – niektóre takie
informacje są, ale nie wszystkie).”
3.4.7.1.
Informacje dotyczące wykładowców
są jednymi z najwaniejszych
poszukiwanych przez studentów
danych, naley więc zadbać o to,
eby w projektowanym serwisie
było ich jak najwięcej i podane były
w jak najprzystępniejszej formie.
Informacje o wykładowcy
Kliknięcie na nazwisku wykładowcy w jakimkolwiek miejscu systemu (np. na
planie zajęć, w wiadomościach, w forach dyskusyjnych) powinno przenieść
uytkownika do strony z informacjami o wykładowcy, która moe wyglądać
podobnie, jak na rysunku 33. Informacje te powinny zawierać:
imię, nazwisko i stopień naukowy wykładowcy,
zdjęcie (jeśli jest to moliwe),
jednostki
(katedra,
instytut,
zakład), w których zatrudniony jest
wykładowca,
numer pokoju oraz telefon słubowy,
„Wiadomo, e rzadko
odwiedza się prowadzących na
konsultacjach – moe powodem
jest te pewne skrępowanie – to
e-mail oraz adres ewentualnej
prywatnej strony WWW,
godziny przyjęć dla studentów
(konsultacji),
z
ewentualnym
wyszczególnieniem tematyki konsultacji,
mogłoby oywić studiowanie
take pomiędzy sesjami
zaliczeniowymi.”
listę prowadzonych zajęć,
listę prac naukowych, ich abstraktów oraz opcjonalnie treści,
listę magistrantów, którymi opiekuje/opiekował się dany wykładowca
(oraz wszystkie pokrewne informacje).
Powinna te istnieć
moliwość wysłania wiadomości do wykładowcy
poprzez proste wciśnięcie obecnego na
stronie przycisku, a take
wysłanie mu wiadomości
za
pomocą
usługi
SMS (bez ujawniania
postronnej osobie numeru prywatnego telefonu
komórkowego).
Rysunek 33
Informacje
o wykładowcy
Nie naley take zapomnieć o wbudowaniu w serwis opcji szukania danego wykładowcy. Konieczne
jest równie wzięcie pod uwagę wytycznych omawianych w rozdziale 1.3.4.2,
i suche fakty uzupełnić informacjami w postaci „W tym semestrze nie masz
zajęć z tym wykładowcą” lub „W tym semestrze masz z tym wykładowcą
zajęcia: programowanie równoległe i rozproszone”.
rozproszone
Oczywiście sam wykładowca (plus ew. osoba wyznaczona jako odpowiedzialna)
powinien mieć moliwość modyfikacji części z dotyczących siebie danych.
3.4.7.2.
Informacje o jednostce naukowej
Dostępna powinna być take strona dotycząca kadej jednostki naukowej
(takiej jak np. katedra, ale równie i dziekanat), z pozycjami takimi, jak:
kontakt (telefoniczny oraz elektroniczny),
lista pracowników z odpowiadającymi im słubowymi telefonami oraz
pokojami,
wysłanie wiadomości do wszystkich osób z jednostki (moliwe tylko
w przypadku uprawnionych do tego osób),
oficjalne ogłoszenia i wydarzenia,
zajęcia wszystkich zatrudnionych osób,
ogólne osiągnięcia naukowe i publikacje.
Takie rozwiązanie pozwoli zunifikować wszystkie serwisy poszczególnych
jednostek (obecnie, jak wspomniano w rozdziale 2.1.3, dość odmienne,
a nawet częściowo nieobecne) oraz poprzez zintegrowanie z serwisem
pozwoli na odciąenie odpowiedzialnych za stronę osób135. Nie naley
jednak zapomnieć o przeprowadzeniu odpowiedniej ankiety wśród osób
odpowiedzialnych za strony WWW katedr w celu zorientowania się, czy nie
yczą sobie one jeszcze innych funkcji na ich witrynach.
W przypadku zalogowania się do systemu wykładowcy powinien mieć on
domyślnie widoczną w menu opcję MOJA KATEDRA, dzięki której w szybki
sposób będzie mógł on dotrzeć do informacji o swoich najbliszych
współpracownikach. Z kolei student powinien mieć w menu przycisk
MOI WYKŁADOWCY, po kliknięciu którego pojawi się lista osób, z którymi ma
w danym semestrze zajęcia.
3.4.8.
Informacje o studentach
Informacje o studentach i grupach studenckich będą w pewien sposób kopią
informacji o wykładowcach i ich jednostkach. Ponownie będą tu obecne:
szukanie studenta podług rónych kryteriów,
przynaleność studenta do rónych grup,
informacje o statusie studenta (zwykły student, wolny słuchacz...),
numer albumu studenta,
informacje o zajęciach studenta,
wybrane przez studenta kierunek i specjalizacja,
informacje o wszystkich osobach w danej grupie,
wyświetlanie zajęć danej grupy,
opcje w menu postaci „moja grupa” lub „moi studenci”,
informacje o funkcjach studenta (starosta grupy czy roku, przewodniczący
samorządu itp.),
informacje postaci „masz zajęcia z tym studentem”, „jesteś promotorem
tego studenta”, itp. itd.
Oczywiście naley tutaj wziąć pod uwagę rónice w dostępie: student –
w przeciwieństwie do wykładowcy – nie powinien mieć moliwości oglądania
informacji o studentach z innych ni swój kierunków.
3.4.9.
Materiały dydaktyczne/naukowe
Częścią serwisu powinno być centralne
„Umieszczajcie trochę plików
repozytorium do przechowywania
rónorakich materiałów dydaktycznych pomocy do zajęć dydaktycznych
– wykładów (w formacie tekstowym,
z WI lub chocia linki.”
Worda czy PDF), prezentacji, prac
naukowych oraz oprogramowania.
Materiały te powinny być przyporządkowane do przedmiotów, grup
studenckich oraz jednostek naukowych.
Powinien zostać zastosowany mechanizm umoliwiający nie tylko ściąganie
materiałów z WWW, ale take umieszczanie ich na serwerze za pomocą tej
samej metody (zainteresowana osoba powinna wybrać tylko plik ze swojego
dysku i nie martwić się adnymi szczegółami technicznymi).
Oczywiście naley posłuyć się odpowiednio dobranymi kryteriami
dostępu. Materiały dotyczące przedmiotu umieszczone przez jednego
z
dydaktyków
powinny
być
widoczne dla wszystkich; materiały
„Zamieszczone na stronie
umieszczone
przez
studentów
powinny być teoretyczne
– tylko dla nich. Skasować dany
materiał lub zastąpić go nowym moe
informacje przydatne
jedynie autor bądź, w szczególnych
w zaliczeniu danych
przypadkach, administrator systemu.
przedmiotów; tzn. np. sieci
Jako ciekawostkę mona zastosować
prosty mechanizm zliczający, ile razy
komputerowe – opis protokołu
dany plik został pobrany – moe to
TCP, opis routingu itp.;
być swoistym wyznacznikiem jakości
programowanie obiektowe – opis danego materiału.
Oprócz tego, jako jeden z elementów
omówionej w rozdziale 1.3.4.1
przygotowaniem tych informacji
organizational identity
identity, w widocznym
mogliby się zająć na przykład
miejscu powinny być umieszczone
szablony dla przygotowywania dokuasystenci lub profesorowie.”
mentów, prezentacji, wykresów itp.
Dzięki nim z jednej strony uzyska
się pewność, i wszystkie dokumenty dotyczące Wydziału Informatyki
będą wyglądały jak najlepiej i w poądany sposób, z drugiej – odciąy się
autora od myślenia nad oprawą oraz pozwoli mu lepiej skupić się nad treścią
tworzonych materiałów dydaktycznych i naukowych.
klas, funkcji wirtualnych, itd.;
135
Nie będzie ju np. konieczne ręczne sporządzanie listy pracowników czy planu zajęć.
Poza omówionymi uprzednio materiałami w serwisie powinno się znaleźć
miejsce take na materiały innego rodzaju: ogólne informacje, poradniki, oraz
odnośniki do wanych stron.
Wśród ogólnych informacji mona pomyśleć m.in. o:
godzinach otwarcia dziekanatu, bufetu, czytelni, punktu kserograficznego
itp.,
najwaniejszych telefonach (dziekanat, przychodnia itp. itd.)
procedurze ubiegania się o stypendium,
procedurze zdawania pracy magisterskiej i ustalania terminu obrony.
Poradniki
dotyczyłyby
głównie
sieci wydziałowej i mogłyby zostać
zintegrowane z systemem pomocy,
udzielając odpowiedzi na takie
pytania, jak:
„Zbyt mało informacji o sieci
WI. Większość zamieszczonych
informacji ogólnikowa - np.
w jaki sposób mona korzystać
ze swoich kont poza terenem
wydziału,
w jaki sposób mona umieścić
własną stronę WWW na serwerze
wydziału,
nigdzie nie ma wzmianki
o moliwości lub braku
umieszczania skryptów CGI na
stronach domowych studentów.”
w jaki sposób mona uruchomić
serwer X-Windows, itp. itd.
Naley zauwayć, i część z tych informacji jest ju obecna w Internecie136,
jednak przydałoby się zebranie ich w jednym wyraźnym miejscu i w jednolitej
formie.
Wśród odnośników do zewnętrznych stron powinny się znaleźć:
odnośniki do rónych witryn Politechniki Szczecińskiej,
odnośniki do najpopularniejszych portali,
odnośniki do wyszukiwarek,
odnośniki do stron dotyczących Szczecina,
odnośniki do witryn z materiałami interesującymi studentów,
odnośniki do informacji o netykiecie137.
Poprzez stworzenie odpowiedniego skryptu zliczającego kliknięcia
administrator systemu mógłby badać, które strony są najczęściej, a które
najrzadziej odwiedzane, i odpowiednio modyfikować odnośniki.
136
137
Na przykład wydziałowa sieć opisana jest na stronie http://www.wi.ps.pl/wips.
Której znajomość, nota bene, powinna być wg. autora obowiązkowa wśród wszystkich
studentów informatyki.
3.4.10.
Profil
Ta pozycja w menu pozwoli uytkownikowi na skonfigurowanie serwisu
i poprzez szereg opcji dostosowanie go jak najpełniej do swoich upodobań.
W menu drugiego rzędu powinno się tu zdublować wszystkie konfiguracyjne
pozycje z poprzednio omówionych sekcji (takich jak wiadomości czy fora
dyskusyjne). Oprócz tego obecne będą tutaj inne opcje, takie jak:
moliwość wpisania alternatywnego „prywatnego” adresu e-mail, z opcją
pozwalającą na określenie, czy jest „waniejszy” od adresu uczelnianego
(jeśli tak, cała korespondencja z serwisu powinna być kierowana na adres
prywatny) oraz czy powinien być widoczny dla innych osób przeglądających
informacje o uytkowniku,
moliwość wpisania numeru telefonu komórkowego i określenia, jakie
informacje powinny być wysyłane za pomocą usługi SMS pod ten
numer, oraz czy numer telefonu powinien być widoczny dla innych osób
przeglądających informacje o uytkowniku,
moliwość wpisania adresów własnych stron WWW,
moliwość wpisania ulubionych stron WWW (odnośniki do nich będą się
pojawiały na stronie głównej),
moliwość wpisania danych, za pomocą których inni mogliby znaleźć
uytkownika w popularnych komunikatorach, takich jak ICQ czy GaduGadu138,
moliwość wpisania numeru pokoju w akademiku, pod którym mona
studenta zastać,
moliwość zamieszczenia swojego zdjęcia i ewentualnie rysunku
symbolizującego naszą osobę na forach dyskusyjnych139,
moliwość wpisania danych osobowych – telefonu domowego, adresu
domowego, numeru konta – tylko do wiadomości np. kwestury
i dziekanatu (oczywiście musi być to wyraźnie zaznaczone).
Uytkownik powinien mieć tutaj take kilka bardziej technicznych
moliwości, jak:
zmianę hasła, za pomocą którego wchodzi do serwisu,
wypisanie stanu zajętości poszczególnych kont,
wypisanie innych przydatnych informacji (np. kontekst w sieci Novell).
Oprócz ww. elementów powinny znaleźć się tutaj take opcje pozwalające na
dopasowanie interfejsu i wyglądu witryny do upodobań uytkownika:
138
139
Mona pomyśleć take o innych komunikatorach, takich jak np. Onet Komunikator, jednak
najpierw naleałoby przeprowadzić badania pozwalajace na ustalenie ich rzeczywistej
popularności.
Nazywana po angielsku avatar, ta moliwość jest bardzo popularna w takich forach.
wybór rodzaju witryny (zgodnie z ustaleniami z rozdziału 3.3.4 powinny
istnieć przynajmniej dwie wersje: uproszczona i normalna), albo jednego
z wielu alternatywnych wyglądów witryny (jeśli takowe będą istniały),
wybór kolorystyki strony (jeśli są do wyboru róne warianty),
ustalenie, jakie elementy powinny się pojawiać na stronie głównej, wraz
z dodatkowymi opcjami (np. ile maksymalnie nowych wiadomości powinno
być wyświetlanych).
Do tego powinny pojawić się opcje śledzące ostatnie poczynania uytkownika
(swego rodzaju „historia”) i pozwalające mu np. na sprawdzenie, ile
komentarzy zostawił, w jakich forach dyskusyjnych ostatnio się udzielał itp.
itd. Mona pomyśleć take o paru drobnych, jednak poytecznych funkcjach,
jak chociaby przestawienie strony domowej na główną stronę serwisu.
3.4.11.
System pomocy
Rzeczą, o której łatwo zapomnieć i uznać ją za niewaną, jest system
pomocy. Jego częścią są omówione ju ekrany startowe, oraz linki do stron
z informacjami i poradnikami, jednak pomoc powinna być duo bardziej
rozbudowana.
Przede wszystkim kady element serwisu i kada widoczna strona powinna
być dokładnie opisana (w miarę moliwości z ilustracjami bądź nawet
animacjami). Co więcej, pomoc powinna być kontekstowa – osoba klikająca
na przycisku POMOC powinna dostać precyzyjne informacje dotyczące tego
ekranu, z którego właśnie korzysta. Mona nawet pokusić się o jeszcze
większy poziom kontekstowości, wykrywając element interfejsu aktualnie
wybrany przez uytkownika i wyświetlając pomoc dotyczącą jedynie jego.
Kolejnym elementem systemu pomocy będzie zbiór najczęściej zadawanych
pytań i odpowiedzi, oznaczany zwyczajowo akronimem FAQ140. Przy
tworzeniu serwisu mona wymyślić potencjalnie „najpopularniejsze” pytania,
jednak naley pamiętać take o późniejszym ich uaktualnianiu i dodawaniu,
bazując na listach czy telefonach od uytkowników systemu.
Cały system pomocy powinien zostać obudowany przyjaznym interfejsem,
z moliwie duą ilością intuicyjnych odnośników, hierarchicznym menu
i moliwością wyszukania informacji. Ideałem byłoby take dodanie systemu
eksperckiego, który umoliwiałby np. zadanie przez uytkownika pytania
w języku naturalnym.
3.4.12.
Inne
Oprócz opisanych głównych elementów serwisu, naley mieć na uwadze
równie wane sekcje poboczne, które będą omówione w tym podrozdziale.
140
Ang. Frequently Asked Questions.
3.4.12.1.
Informacje o salach/budynkach
Zarówno w planie zajęć, jak i informacjach o pracownikach Wydziału
pojawiały się numery sal oraz nazwy budynków. Kliknięcie na tych polach
powinno przenosić uytkownika do odpowiednich stron z dalszymi danymi.
Strona z informacjami o sali powinna zawierać dane o zajętości sali
w poszczególnych dniach (podobnie, jak aktualnie informują o tym wywieszki
na drzwiach sal w budynku Wydziału Informatyki). Dodatkowym przyjaznym
elementem mógłby być take plan piętra budynku z zaznaczeniem, w którym
miejscu znajduje się dana sala.
Na stronie powinno się take zamieścić informacje o zasobach sali
(komputery, rzutniki itp. itd.), a w przyszłości właśnie w tym miejscu
powinno się implementować mechanizmy rezerwowania sal na zajęcia.
Z kolei strona z informacjami o budynku powinna zawierać:
podstawowe dane – nazwa, adres, telefon, nawet zdjęcie budynku,
listę sal (oczywiście z moliwością kliknięcia na danej sali),
wycinek mapki miasta z zaznaczonym dojazdem,
listę najbliszych przystanków komunikacji miejskiej wraz z rozkładem
jazdy.
Przy tej okazji mona pomyśleć o interaktywnej mapie całego kampusu, oprócz
budynków wydziałów i instytutów wyświetlając take budynki akademików,
przychodni itp. itd. Mona tu wzorować się np. na mapie przedstawionej na
witrynie University of Washington141.
3.4.12.2.
Usługa SMS
Wykorzystanie usługi SMS dostępnej w przypadku telefonów komórkowych,
powinno być wbudowane w system, chociaby w celu informowania
studentów o odwołanych zajęciach, jeśli sobie tego yczą. Biorąc pod uwagę
ogromną popularność tej usługi – szczególnie wśród ludzi młodych142
– naleałoby jednak jeszcze bardziej rozbudować jej obecność w serwisie.
Przede wszystkim bardzo przydatna byłaby funkcja przesyłania SMS-em
informacji do osoby z Wydziału (studenta bądź dydaktyka), jeśli tylko ta osoba
wpisała w swoim profilu numer telefonu komórkowego. Oczywiście numer
ten nie będzie ujawniony osobie chcącej wysłać wiadomość, która będzie
musiała tylko wpisać ją w odpowiednie pole – resztą zajmie się sam system.
Oprócz tego mona pokusić się o zrealizowanie funkcji wysyłania SMSów pod wybrany przez uytkownika dowolny numer telefonu. Najprostszą
141
http://www.washington.edu/home/maps.
142
Piotr Rabiej, Rekord popularności, Twoja Komórka 2/2002
(http://www.twoja-komorka.com.pl/a2002_021.htm).
metodą byłoby po prostu umieszczenie w widocznym miejscu odnośników
do odpowiednich stron WWW wszystkich trzech polskich sieci telefonii
komórkowej (jak to zaproponowano w rozdziale 3.4.2), aczkolwiek bardziej
profesjonalne rozwiązanie to bez wątpienia umieszczenie pól do wpisania
numeru telefonu i wiadomości bezpośrednio na stronie głównej – i w ten
sposób „zrzucenie” części pracy z barków uytkownika na sam serwis.
Ankiety
3.4.12.3.
Kolejnym elementem, o rozszerzenie którym strony głównej mona by się
pokusić, jest zmieniająca się co jakiś czas ankieta (sonda). Popularna i obecna
w wielu amatorskich serwisach143 ankieta traktowana jest jednak głównie
jako element zabawowy, podczas gdy tutaj moe słuyć czemuś więcej
– umiejętnie zastosowana moe słuyć władzom uczelni jako mało kłopotliwy
i bardzo skuteczny (w porównaniu do bardziej tradycyjnych metod) sposób
pytania studentów o planowane zmiany czy przewidywane nowości.
Jak kady element interaktywny stron WWW ankieta powinna być bardzo
popularna – pod warunkiem, i będzie dobrze widoczna (najlepiej umieścić
ją na głównej stronie, gdzie nie zajmie zbyt wiele miejsca) i maksymalnie
uproszczona w obsłudze (wybranie jednej z kilku dostępnej opcji
i e w e n t u a l n e kliknięcie na „zagłosuj”), a take ciekawa. Odpowiednio
dobrany czas (tydzień lub dwa tygodnie) zapewni udział w ankiecie jak
największej liczby zainteresowanych z jednej strony i odpowiednio częstą
rotację pytań z drugiej, natomiast sam system autoryzacji będzie dbał
o miarodajność wyników. Naley pamiętać, aby wyniki ankiety były dostępne
dla głosujących zaraz po jej zakończeniu, a najlepiej od razu po oddaniu głosu
– ankietowani muszą czuć swój bezpośredni wpływ na jej rezultaty, w innym
przypadku mogą dość szybko się do niej zniechęcić.
Ciekawostki
3.4.12.4.
Innym ciekawym elementem strony głównej moe być małe pole
z ciekawostkami. Mona je zatytułować „czy wiesz, e...” i co tydzień
przedstawiać krótki fakt z ycia uczelni (np. jej historii) bądź samego serwisu.
Dzięki takiemu rozwiązaniu144 mona niejako „przemycić” niektóre fakty
uytkownikom systemu bądź zainteresować ich niektórymi zagadnieniami
(nic nie stoi na przeszkodzie, eby krótka informacja opatrzona była
odnośnikiem do strony, gdzie mona będzie dowiedzieć się o danym fakcie
więcej). Dla przykładu:
„Czy wiesz, e Politechnika Szczecińska istnieje ju 57 lat?”
lat
143
144
Dzięki wielu darmowym usługom tego typu, wśród których prym wydaje się wieść sonda.pl
(http://www.sonda.pl).
W nieco odmienionej formie istniejącemu nawet w programach komputerowych, pod
nazwą „porada dnia”.
lub
„Czy wiesz, e klikając na numerze sali moesz zobaczyć jej dokładne
umiejscowienie w budynku?”
Jeśli ciekawostki będą zwięzłe i umieszczone w odpowiednim miejscu na
stronie, nie powinny w aden sposób przeszkadzać osobom, których nie
interesują.
Przeszukiwanie serwisu
3.4.12.5.
Serwis informacyjny, jak kada profesjonalnie wykonana strona, powinien
mieć moliwość szukania wybranego ciągu znaków wśród swojej zawartości.
Uytkownicy nie zawsze chcą podporządkować się hierarchicznej strukturze
serwisu, a ponadto opcja wyszukiwania słuy im pomocą, kiedy po prostu nie
potrafią odnaleźć się w serwisie145.
W przypadku serwisu generowanego w tak dynamiczny sposób jak
prezentowany serwis informacyjny, niemoliwe jest proste skatalogowanie
i zindeksowanie wszystkich stron serwisu. Rozwiązaniem jest podzielenie
informacji zawartych w serwisie na poszczególne domeny i umoliwienie
wyszukiwania informacji w poszczególnych z nich. Te domeny to:
zajęcia (nazwy zajęć),
dydaktycy (nazwiska),
studenci (nazwiska),
materiały (tytuły i treść prac),
wiadomości (tytuły i treść),
ogłoszenia (tytuły i treść),
fora dyskusyjne.
Opcja szukania w skróconej postaci powinna być obecna na głównej stronie,
a take na odpowiednich podstronach (informacje o studentach, informacje
o dydaktykach, materiały). Dodatkowo naley zaimplementować rozszerzony
panel szukania zaawansowanego, bardziej skomplikowanego w obsłudze,
jednak dającego uytkownikowi więcej moliwości146.
Innym aspektem szukania, na który koniecznie naley zwrócić uwagę, jest
obsługa polskich liter. W niektórych środowiskach (np. przeglądarkach
tekstowych) niemoliwe jest uzyskanie polskich znaków diakrytycznych,
z drugiej strony czasami nie będą one obecne take w materiałach147. Z tych
powodów konieczne będzie zaprojektowanie rozwiązania uwzględniającego
te niedogodności (np. przezroczysta konwersja zadanego pytania oraz
145
146
147
Jakob Nielsen, Search: visible and simple, op. cit.
Jakob Nielsen, Search and you may find, op. cit.
Chocia naley to tępić z pełną surowością.
przeszukiwanych materiałów na format, w którym polskie znaki są
zastępowane przez ich łacińskie odpowiedniki148).
3.4.12.6.
Mapa serwisu
Kolejnym niezbędnym elementem serwisu jest jego mapa, przedstawiająca
wszystkie podstrony w sposób uporządkowany hierarchicznie i z rozszerzonymi komentarzami149. Mapa taka, łącznie z opisanym powyej
wyszukiwaniem, daje uytkownikowi mile widziane alternatywne moliwości
dotarcia do informacji oprócz głównego menu nawigacyjnego150.
Informacje o serwisie
3.4.12.7.
Naley te pomyśleć o stronie
przedstawiającej informacje o serwisie, takie jak:
nazwę i aktualną wersję serwisu,
listę osób odpowiedzialnych za
poszczególne elementy serwisu
wraz z ich adresami e-mail
i ewentualnie innymi sposobami
kontaktu,
„Niekiedy cięko znaleźć
poszukiwane informacje.
Przydałaby się szczegółowa
mapa serwisu, zrealizowana
jako zwykły tekst (bez obrazków
i Flasha), by do odnajdywania
działów mona było uywać
funkcji wyszukiwania dostępnej
listę technologii uytych przy
tworzeniu serwisu, wraz z odnośw przeglądarce.”
nikami do ich stron domowych
(moe to w pewien sposób pomóc
studentom i zachęcić do samodzielnego zdobywania informacji).
3.4.13.
Administracja
W serwisie powinno istnieć specjalne konto dla administratora (webmastera),
mającego pełną kontrolę nad danymi. Oczywiście zawsze będzie istniała
moliwość edycji danych na niskim poziomie wykorzystywanych narzędzi
(pliki skryptowe, zapytania SQL w bazach danych itp. itd.), jednak
administrator powinien mieć moliwość edycji wszystkich moliwych danych
z poziomu WWW – w sposób podobny do tego, z jaki korzystają z niego
inni uytkownicy, jednak oczywiście z większymi (nieograniczonymi wręcz)
uprawnieniami.
148
149
150
Takie rozwiązanie zostało zastosowane przez autora pracy z powodzeniem w serwisie USS
Solaris.
Jakob Nielsen, Site map usability, styczeń 1997, serwis useit.com
Eric Tilton, Composing good HTML, op. cit.
Konto webmastera powinno być kontem funkcyjnym, nie związanym
z konkretną osobą – administrator, jak kada inna fizyczna osoba powinna mieć
swoje własne konto z typowymi ograniczeniami, a korzystać ze specjalnego
konta jedynie w razie nagłych przypadków. Pozwoli to na zmniejszenie ryzyka
przypadkowych błędów, a ponadto pozwoli na zajmowanie się serwisem
więcej ni jednej osobie. Nie pojawią się te problemy w przypadku zmiany
osoby opiekującej się serwisem.
Administrator powinien mieć dodatkowe opcje przy praktycznie kadej
podstronie serwisu, umoliwiające mu ingerencję w zawarte tam dane,
a take dodatkowe podstrony, zawierające np. listę aktualnych sesji, logi,
konfigurację serwisu, opcje sprawdzania spójności baz danych itp. itd.
Oczywiście na stanowisku administratora naley umieścić osobę z jednej
strony odpowiedzialną, a z drugiej oddaną tak, aby zajmowała się serwisem
tak dobrze, jak jest to moliwe. Niezbędne będzie te uczulenie tej osoby
na waność wszystkich bez wyjątku uwag zgłaszanych przez uytkowników
i konieczności odpowiadania oraz reagowania na nie.
3.5.
Integracja z innymi usługami
Mimo załoeń, i serwis informacyjny będzie zawierał w sobie jak najwięcej
przydatnych opcji, nie naley oczekiwać, e zastąpi on wszystkie usługi
dostępne dla uytkowników w całej sieci wydziału. W przypadku tego
typu „zewnętrznych” usług jak najbardziej poądane powinno być jednak
zintegrowanie ich z serwisem informacyjnym tak ściśle, jak to tylko moliwe
(oczywiście biorąc pod uwagę bezpieczeństwo i sposób ich działania).
Szczególnie istotne będzie tu wyeliminowanie konieczności wielokrotnego
logowania się – zakładamy, i uytkownik potwierdził swoją tosamość ju
w momencie wejścia do serwisu, tak więc w większości przypadków powtórna
autoryzacja przy wejściu do nowej usługi będzie tylko zbędną stratą czasu.
3.5.1.
Dostępność serwisu w systemach pozbawionych
przeglądarek WWW
Wykonanie serwisu informacyjnego w technologii WWW gwarantuje dostęp
do niego z poziomu większości systemów, nie naley jednak zapominać, i
na Wydziale Informatyki przynajmniej dwa z nich nie dają bezpośredniego
dostępu do graficznej przeglądarki WWW. Są to: system MS-DOS z sieciową
otoczką w postaci oprogramowania Novell Netware, oraz serwer linuksowy
dający konsolowy dostęp z kadego stanowiska w salach laboratoryjnych. Oba
te systemy to środowiska tekstowe, a uruchomienie z ich poziomu graficznej
przeglądarki WWW moe być czasochłonne i kłopotliwe.
W tej sytuacji mona rozpatrzyć stworzenie specjalnego oprogramowania
pod oba te systemy151, które po zalogowaniu się uytkownika łączyłoby
się z serwerem przechowującym dane i wyświetlało na ekranie (w formie
tekstowej) najwaniejsze informacje. Przykładowy wynik działania takiego
programu mógłby wyglądać następująco.
[ Marcin Wichary ]
Liczba nowych wiadomości: 5
3 nowe wiadomości (w tym jedna wana).
Brak nowej poczty e-mail.
Wpisz „conf”, aby skonfigurować działanie programu.
Po wpisaniu „conf” uytkownik uzyskałby listę poleceń i mógłby za ich pomocą
w ograniczonym zakresie sterować tym, co ma być wyświetlane na ekranie
po zalogowaniu się. W ten sposób byłby on na bieąco z najbardziej pilnymi
wydarzeniami, wiadomościami i informacjami z serwisu informacyjnego
nawet pod nieobecność przeglądarki WWW.
Stworzenie serwisu w wersji WAP
3.5.2.
Podobnym do powyszego i wymagającym zblionych poczynań mogło by być
stworzenie okrojonej edycji serwisu w wersji WAP, moliwej do oglądania
w telefonach komórkowych. Pomimo wielu zalet takiego rozwiązania, wady
wydają się jednak duo większe – WML jest językiem raczej ograniczonym
i niewygodnym (nie wspominając o tym, i jest przez wielu uwaany za
rozwiązanie bez przyszłości152), liczba osób korzystających z technologii WAP
jest dość mała z powodu jej wysokiej ceny (czyli z oczywistych względów
wśród studentów będzie tym mniejsza), a wygodę wynikającą z zastosowania
przenośnych telefonów komórkowych serwis wykorzystuje ju rozsyłając do
uytkowników wiadomości SMS.
Eksportowanie danych z serwisu
3.5.3.
Innym rodzajem integracji będzie udostępnianie danych z serwisu
informacyjnego do wykorzystania przez inne systemy, z wykorzystaniem
specjalnie do tego celu stworzonego oprogramowania spełniającego rolę
swoistej bramki-konwertera.
Przykładem mogłoby być wykorzystanie istniejących w serwisie danych
do wyświetlania planu zajęć czy pracowników poszczególnych katedr na
ich własnych podstronach dostępnych w serwisie Wydziału Informatyki
151
152
Przy zachowaniu odpowiedniej dyscypliny programowania moliwe byłoby stworzenie
jednego tylko programu (np. w C++), który dałby się kompilować pod obiema platformami
(MS-DOS i Linux).
Jakob Nielsen, WAP Backlash, lipiec 2000, serwis useit.com
(oczywiście do momentu, w którym nie zostaną one „zasymilowane” przez
serwis). Dzięki takiemu rozwiązaniu nie byłoby konieczne wykonywanie
dodatkowej pracy za kadym razem, gdy plan lub personalia osób są
zmieniane, a take uniknięto by moliwości powstania nieścisłości pomiędzy
zdublowanymi danymi.
Technicznie taką bramkę mona byłoby stworzyć jako skrypt w języku PHP,
który byłby umieszczany na witrynie katedry i w momencie wywołania
strony pobierał dane z serwisu informacyjnego i następnie przedstawiał je
w odpowiedniej formie. Naley tu zwrócić uwagę na to, i skrypt powinien
mieć moliwość konfiguracji wyglądu generowanych danych153 tak, aby
pasował on do całego designu strony.
3.5.4.
Importowanie danych z innych serwisów
Kolejnym pomysłem mogłoby być importowanie aktualnych wiadomości
dotyczących studenckiego ycia z innych serwisów WWW i wyświetlaniu ich
na stronie głównej serwisu, oczywiście po wcześniejszym porozumieniu z ich
twórcami. Takimi serwisami mogą być np. Infoludek lub witryny lokalnych
szczecińskich gazet. Naleałoby jednak upewnić się (na przykład za pomocą
opisanej w rozdziale 3.4.12 ankiety), i korzystający z serwisu informacyjnego
są rzeczywiście zainteresowani takimi wiadomościami, inaczej staną się
one elementem niepotrzebnie zapełniającym serwis i obniającym jego
czytelność, a co za tym idzie uyteczność.
3.6.
Moliwości rozwoju
Przedstawiany serwis nie powinien być serwisem zamkniętym i praktycznie
nigdy nie będzie mona powiedzieć o zakończeniu prac nad nim, poniewa
lista rzeczy które mona do niego dodawać jest bardzo długa. W tym
rozdziale przedstawione zostanie kilkanaście kierunków rozwoju serwisu,
jednak oczywiście mona ich wymyślić o wiele więcej, a i naley przygotować
się na to, i sami uytkownicy będą sugerowali konieczność zmian, ulepszeń
i rozszerzeń serwisu (jeden z ankietowanych webmasterów napisał wprost,
i jednym z głównych problemów jest fakt, e „nowe pomysły na rozwój
rodzą się szybciej ni mona je realizować”).
3.6.1.
Oceny/płatności
Kolejne dwa rozszerzenia będą wymagać ogromnego wysiłku w celu
zbudowania jak najlepszych i najbardziej wyrafinowanych zabezpieczeń (m.in.
153
Chociaby dzięki wykorzystaniu stylów CSS.
stworzenie lokalnej infrastruktury klucza publicznego154), poniewa wszelkie
próby włamań i fałszowania danych byłyby dla systemu katastrofalne.
Pierwszym rozszerzeniem mogłoby być zbudowanie duo lepszego systemu
przechowywania ocen studentów. Aktualnie wykładowcy mogą wprawdzie
dzięki systemowi wiadomości wysyłać do grup studentów listy z ocenami
– co jest znacznym krokiem naprzód w stosunku do aktualnego stanu rzeczy
– jednak kolejnym etapem powinno być zbudowanie osobnego systemu
zapamiętywania i przetwarzania ocen.
Wykładowcy nie musieliby przechowywać ocen cząstkowych studentów za
pomocą innych środków – wystarczyłoby wpisanie ich do serwisu, natomiast
oceny ostateczne byłyby równowane z kartą zaliczeń. Widać, jak ogromną
wagę naleałoby tu przyłoyć do odpowiedniego zabezpieczenia tych danych
oraz tworzenia ich kopii zapasowych.
Serwis mógłby zostać te rozbudowany o system regulowania płatności
– kady pracownik i student miałby swoje osobiste „konto”, na którym
zapamiętywane byłyby jego wszystkie opłaty (np. za wpis warunkowy)
i wynagrodzenia (np. stypendium). Uytkownik miałby pełną kontrolę
i wiedziałby, ile jeszcze winny jest uczelni lub ile uczelnia jest jemu winna
oraz kiedy moe spodziewać się nalenych mu pieniędzy (oczywiście
konieczna byłaby tutaj współpraca z kwesturą). Naturalnym rozwinięciem
tego toku myślenia mogłaby być obsługa kart kredytowych i płatniczych
z poziomu serwisu, pozwalająca na regulowanie naleności w formie
całkowicie elektronicznej.
Połączenie obu podsystemów pozwalałoby na praktycznie automatyczne
rozwiązywanie takich kwestii jak obliczanie średnich, przyznawanie
stypendiów, naliczanie opłat za wpisy warunkowe itp. itd.
3.6.2.
Rozszerzenie dostępu
W bieącym momencie na terenie Wydziału pracownicy mieliby dostęp do
serwisu z własnych komputerów słubowych, natomiast studenci jedynie
z ogólnodostępnych komputerów w salach laboratoryjnych. Niestety,
z komputerów tych mona korzystać jedynie wtedy, jeśli w salach nie
są prowadzone zajęcia, co pozwala przypuszczać, i mogą pojawiać się
przypadki, w których studenci nie będą mogli dostać się do serwisu.
Aby temu zapobiec, proponuje się zainstalowanie w widocznym miejscu
kiosków (terminali) z ekranami dotykowymi. Ich liczba powinna być
uzaleniona od przewidywanego wykorzystywania tak, aby w danym momencie
zawsze przynajmniej jeden kiosk był wolny. Kioski słuyłyby jedynie do obsługi
serwisu (i to – z uwagi na ekran dotykowy – w ograniczonym zakresie) tak,
aby studenci nie zajmowali ich do innych zadań.
154
Więcej informacji o tym temacie mona znaleźć w opracowaniu Frequently asked questions
about today’s cryptography, op. cit., str. 123.
Praktycznie niezbędne byłoby tutaj take wyposaenie terminali w czytniki
kart chipowych (ang. smartcards) i studentów w takowe karty, które
pozwalałyby znacząco uprościć proces uwierzytelnienia. Kolejnym krokiem
byłoby wyposaenie w wymienione czytniki take wszystkich komputerów
w salach laboratoryjnych.
Niewykorzystywane w danej chwili terminale mogłyby wyświetlać przydatne
dane, jak np. aktualny czas, kursy komunikacji miejskiej, najnowsze ogłoszenia
czy informacje kulturalne. Oprócz kiosków mona by take pomyśleć
o zainstalowaniu jednego lub więcej duych paneli (np. ciekłokrystalicznych),
które take prezentowałyby ww. informacje.
Mona take, kontynuując rozwaania z rozdziału 3.5.2, myśleć powoli
o stworzeniu okrojonej wersji serwisu dla urządzeń przenośnych, takich jak
palmtopy czy telefony wyposaone w następcę technologii WAP
WAP.
3.6.3.
Prace przejściowe/magisterskie
Kolejnym rozszerzeniem serwisu mogło by być stworzenie systemu
obsługi zadań, który wykorzystywany byłby przede wszystkim przy pracach
przejściowych oraz magisterskich. Wszystkie dane dotyczące takich
prac – zakres i tezy projektowe, dane promotora i recenzenta, poziom
zaawansowania, terminy, seminaria, konieczne czynności biurokratyczne
– byłyby przechowywane w systemie i zarówno opiekun jak i student mieliby
do nich ciągły dostęp.
3.6.4.
Plan zajęć
Jak zwrócono uwagę w rozdziale 3.4.3.9, aktualny projekt przewiduje jedynie
importowanie planu zajęć z zewnętrznego źródła. Duo bardziej przyjaznym
rozwiązaniem byłoby jednak dobudowanie do serwisu kolejnego modułu,
który miałby za zadanie utworzenie planu zajęć, który zostawałby wpisany
bezpośrednio w serwis, w oparciu o przedstawione mu wytyczne.
Innym rozszerzeniem systemu, o wiele prostszym, jest uzupełnienie
go o pełną obsługę przedmiotów obieralnych (aktualnie mało jeszcze
rozpowszechnionych na Wydziale Informatyki), włącznie z tworzeniem
list osób, wyznaczaniem kryteriów i podawaniem przez uytkowników
alternatywnych przedmiotów, jeśli nie będą mogli dostać się na te pierwotnie
wybrane.
3.6.5.
Uytkownicy
W przedstawionym projekcie zarządzanie uytkownikami, a przynajmniej
ich podstawowymi danymi dotyczącymi uwierzytelnienia, odbywa się poza
serwisem – dane te przechowywane są korzystając z mechanizmu usług
katalogowych i odbierane za pomocą protokołu LDAP155.
Mona się jednak pokusić o rozszerzenie zarządzania uytkownikami
i wbudowanie go w sam serwis, łącznie z np. sprawdzaniem zajętości
kont. Pozwoliłoby to na zlikwidowanie potencjalnych nieścisłości podczas
synchronizacji obu baz danych (danych katalogowych oraz wewnętrznej
bazy danych serwisu łącznie z profilem uytkownika) oraz uczyniłoby serwis
bardziej funkcjonalnym.
3.6.6.
Obsługa biblioteki
Kolejnym elementem, który mona zintegrować z systemem, jest system
obsługi biblioteki (wydziałowej w pierwszej kolejności, uczelnianej
w drugiej).
Pozwoliłoby to na:
przeglądanie katalogów bibliotecznych z wykorzystaniem znanego ju
interfejsu,
rezerwację ksiąek i informowanie uytkownika kiedy zostaną zwolnione,
informowanie uytkownika o terminach oddania ksiąek i ewentualnie
dziekanatu o zaległościach,
bezpośredni kontakt z uytkownikiem ze strony biblioteki,
informowanie o nowościach wydawniczych w bibliotece za pomocą
systemu wiadomości/ogłoszeń serwisu.
Docelowo studencka karta chipowa mogłaby te zastępować kartę
biblioteczną.
3.6.7.
Strona WWW Wydziału Informatyki
Nawet po powstaniu przedstawionego
serwisu nadal pozostanie kwestia
nieuaktualnianej i nie cieszącej się
duym powodzeniem strony WWW
Wydziału
Informatyki.
Zgodnie
z rozdziałem 1.3.4.1 naleałoby
stworzyć od nowa wizerunek tej
strony tak, aby obie witryny wyglądały
jak większa część jednej całości,
jednak z drugiej strony róniły się od
siebie w wyraźny sposób. Z integracją
interfejsu powinna iść take w parze
integracja treści (por. rozdział 3.5.3).
155
Lightweight Directory Access Protocol.
„Mała propozycja: jeśli jest to
moliwe, to przydałaby się nowa
szata graficzna, poniewa ta nie
jest zbyt przyciągająca
i w przypadku odwiedzin osób
spoza wydziału moe być źle
przyjęta. Taki wydział stać na
więcej, dlatego proszę o tym
pomyśleć.”
3.6.8.
Zdalne nauczanie
Nauczanie na odległość (osoby uczestniczące w wykładach i zdające
egzaminy zdalnie, poprzez Internet) to kolejny element, który mona
bezproblemowo włączyć do serwisu, jeśli zostanie on przygotowany zgodnie
z przedstawionymi załoeniami, jako serwis modularny i otwarty.
3.6.9.
Implementacja na innych wydziałach/uczelniach
Po udanym wdroeniu i dokładnym przetestowaniu serwisu mona pomyśleć
o zastosowaniu go na innych wydziałach Politechniki Szczecińskiej i –
w dalszej kolejności – innych uczelniach. Jakkolwiek odległa nie była by ta
wizja, naley mieć ją na uwadze ju podczas projektowania serwisu, poniewa
wymusza ona otwartość i stosowanie duo mniej sztywnych załoeń na
kadym etapie pracy.
3.7.
Wskazówki dotyczące
implementacji
W ostatnim rozdziale tej pracy przedstawione zostanie kilka wskazówek
i wytycznych, które mogą być przydatne w procesie tworzenia serwisu.
3.7.1.
Załoenia i projekt struktur baz danych
Pierwszym krokiem przy projektowaniu bazy danych powinna być analiza
danych przeznaczonych do przechowywania i obrabiania w tej bazie
oraz ustalenie zaleności między tymi danymi156. Dzięki temu powinna
powstać struktura jak najdokładniej odwzorowująca świat rzeczywisty bez
niepotrzebnego skomplikowania i nadmiarowości.
Przy projektowaniu baz danych naley zwracać uwagę na cztery zasady157:
dokładność – i pola w tabelach, i same tabele, i powiązania między
nimi powinny jak najbardziej precyzyjnie oddawać zaleności istniejące
w świecie rzeczywistym, a kady element dołączony do projektu musi
mieć swój odpowiednik w realnym modelu,
unikanie redundancji – czyli niepotrzebnych powtórzeń, wprowadzających ryzyko pojawienia się niespójności między identycznymi z załoenia
danymi,
156
157
Jeffrey D. Ullman, Jennifer Widom, Podstawowy wykład z systemów baz danych,
Wydawnictwa Naukowo-Techniczne Warszawa 2000, str. 46.
Tame, str. 74-76.
prostotę – sprowadzającą się do tego, aby nie wprowadzać do projektu
niepotrzebnych elementów, które zaciemnią tylko jego wygląd i utrudnią
operacje na danych,
dobór właściwych elementów – czy to typów pól, czy rodzaju powiązań
między tabelami, czy wreszcie (a moe przede wszystkim) odpowiedni
wybór pomiędzy polami a odrębnymi, odpowiednio powiązanymi
tabelami.
W wyniku takiej dogłębnej analizy, proponuje się projekt przedstawiony na
rysunku 34 na kolejnej stronie. Oczywiście jest to jedynie bardzo wstępny
projekt, który niewątpliwie będzie znacznie zmodyfikowany, jednak ju teraz
pozwala na zorientowanie się co do poziomu skomplikowania i ogromu pracy
potrzebnej do jego stworzenia i zweryfikowania.
Naley zauwayć, i zgodnie z załoeniami z rozdziału 3.6.9 przedstawiona
struktura bierze pod uwagę nie tylko załoenia prawdziwe na Wydziale
Informatyki czy wręcz Politechnice Szczecińskiej, ale take na innych
uczelniach. Dołoono w tym celu starań158, aby powiązania były jak najbardziej
elastyczne, często poprzez wprowadzenie dodatkowych, na pierwszy rzut
oka wydawałoby się niepotrzebnych tabel.
Powiązania w kolorze zielonym oznaczają powiązania opcjonalne, natomiast
tabele w kolorze zielonym przedstawione za pomocą przerywanych linii to
tabele słownikowe.
3.7.2.
Bezpieczeństwo
W przypadku zawarcia w serwisie opartym o WWW tak wielu poufnych
informacji, zadbanie o jego pełne bezpieczeństwo jest sprawą bardzo duej
wagi. Istnieją trzy podstawowe rodzaje zagroeń159:
wykorzystanie luk w serwerze WWW bądź skryptach CGI do całkowitego
bądź częściowego przejęcia kontroli nad komputerem serwera przez osoby
postronne (włamywaczy),
zdobycie poufnych informacji z serwera WWW przez osoby postronne,
podsłuchanie informacji przesyłanych między serwerem WWW
a komputerem uytkownika przez osoby postronne.
Pierwszego zagroenia mona uniknąć dokładnie testując wykorzystywany
serwer WWW, a przede wszystkim tworzone skrypty CGI. Naley je
sprawdzać przede wszystkim pod kątem najpopularniejszych błędów,
takich jak np. buffer overflow160 czy błędów związanych z przetwarzaniem
parametrów podanych w URL.
158
159
M.in. poprzez wywiady z byłymi studentami innych szkół wyszych.
Simson Garfinkel, Gene Spafford, Bezpieczeństwo w Unixie i Internecie, O’Reilly &
Associates, Inc. Wydawnictwo RM, Warszawa 1997, str. 520.
Rysunek 34
Projekt struktury bazy
danych
Drugie zagroenie moe zostać zniwelowane przez poprawnie działający
system autoryzacji, dający danemu uytkownikowi dostęp do tych i jedynie
do tych danych, do których ma on uprawnienia. Remedium na trzecie
zagroenie natomiast będzie odpowiednie szyfrowanie danych przesyłanych
między serwerem a komputerem uytkownika, chociaby z wykorzystaniem
SSL161.
Oprócz tego niezbędne będzie tworzenie backupu, czyli kopii zapasowych
danych, przydatnych w przypadku ich utraty bądź nieprzewidzianej
modyfikacji. Kopie zapasowe powinny być przechowywane na innym
serwerze i wykonywane co najmniej raz dziennie.
System powinien umoliwiać take prowadzenie auditingu, czyli zapisywania
w archiwum przeprowadzanych przez uytkowników operacji. Oczywiście
pełny auditing jest bardzo trudny do przeprowadzenia za względu na
wymagania co do pamięci masowych, jednak częściowe jego prowadzenie
– szczególnie w początkowej fazie działania serwisu – powinno pozwolić na
łatwiejsze uporanie się z problemami.
Zapewnienie bezpieczeństwa serwisu będzie niestety duo bardziej
skomplikowane, ni przedstawione powyej zarysy – naley tutaj skonsultować
się ze specjalistami z odpowiednich katedr w celu wypracowania jak
najlepszych mechanizmów ochronnych.
3.7.3.
Wdroenie
Poprawne i całościowe wdroenie serwisu informacyjnego do uytku moe
być zadaniem równie trudnym, jak jego zaprojektowanie i stworzenie.
Największym zagroeniem nie będą tutaj problemy techniczne, lecz
przekonanie wszystkich zainteresowanych osób, i korzystanie z serwisu
moe przynieść korzyści i im, i innym osobom.
W związku z tym zaleca się przygotowanie odpowiednich okólników
przedstawiających zasady i zalety korzystania z serwisu. Konieczne moe być
take przygotowanie serii szkoleń, podczas których osoby tworzące serwis
bądź znające go najlepiej przedstawiałyby zasady jego działania.
Oczywiście nie naley stosować przymusu, ani nawet jego pozorów – wręcz
przeciwnie, naley wyraźnie wysłuchać opinii wszystkich zainteresowanych
osób i, jeśli ich uwagi byłyby konstruktywne, skorzystać z nich przy ulepszaniu
serwisu. Take i przed etapem wdroenia naleałoby przeprowadzić fazę
testów wśród wybranych studentów i pracowników, których uwagi co do
funkcjonowania serwisu mogą być wręcz bezcenne.
Ju na etapie projektowania i tworzenia naleałoby tworzyć dokumentację,
z jednej strony opisującą wewnętrzne składniki serwisu, z drugiej strony
160
161
Błąd polegający na podaniu na wejściu programu większej ilości danych, ni potrafi
przechować jego bufor, co w rezultacie doprowadza do awaryjnego zakończenia programu.
Tame, str. 537.
– sposób jego wykorzystania. Naley mieć na uwadze, i w bliszym lub
dalszym okresie czasu administrować systemem mogą inne osoby, ni te,
które je tworzyły, a przy przyszłym wdroeniu systemu w wydziałach innych
ni Wydział Informatyki dokumentacja jest wręcz niezbędna.
Bardzo potrzebny będzie te harmonogram tworzenia poszczególnych
elementów serwisu, gdy z oczywistych względów niektóre są bardziej
wane ni inne, a stworzenie wszystkich składników moe być pracoi czasochłonne. Przy kadym elemencie powinny równie znaleźć się
dokładne wytyczne dotyczące wyglądu i bezpieczeństwa tak, aby osoby je
tworzące wiedziały dokładnie, w jakich granicach mogą się poruszać.
3.7.4.
Obsługa
W dalszym uytkowaniu systemu nadrzędną zasadą działania powinno być
„serwis myśli o administratorze, nie administrator o serwisie”. W przypadku
serwisu tak złoonego i obszernego jak przedstawiany serwis informacyjny,
niemoliwe jest wymaganie od jednej być moe osoby czuwania nad
wszystkimi aspektami jego działania. W witrynę powinien być więc
wbudowany mechanizm przypominania administratorowi o najwaniejszych
wydarzeniach dotyczących samego serwisu, jak np.
sprawdzaniu logów co określony czas,
przeglądaniu statystyk przeglądanych stron i wykorzystywanych funkcji,
koniecznych zmianach w bazach danych na początku kadego semestru,
koniecznych zmianach w bazach danych na początku kadego roku
akademickiego (dopisanie nowych osób, przydział do grup itp. itd.).
Z oczywistych względów administrator sam powinien mieć moliwość
dopisywania nowych wydarzeń do tej listy.
Jednym z elementów serwisu powinna być take regularna autodiagnostyka,
czyli sprawdzanie przez sam serwis swojej spójności. W regularnych odstępach
powinna być kontrolowana zawartość baz danych i jakiekolwiek niezgodności
natychmiast zgłaszane do administratora (np. brak wyboru przez studenta
specjalizacji, zgodność dat zajęć z datami zjazdów dla studiów zaocznych,
obecność starostów we wszystkich grupach itp. itd.). W tym wypadku due
znaczenie ma częste i regularne wykonywanie kopii zapasowych tak, aby
w razie niemoliwej do naprawienia awarii odzyskane dane były jak najbardziej
aktualne. Na tej samej zasadzie co jakiś czas powinno być przeprowadzanie
czyszczenie serwisu, np. usuwanie dawnych wiadomości.
W dalszym uytkowaniu przydatne moe być spisanie – a take zaimplementowanie w samym serwisie w postaci kreatorów162 – procedur działania
w najwaniejszych przypadkach, szczególnie przy rozpoczynaniu się
semestrów.
162
Ang. wizards.
Podsumowanie
Wyniki ankiety – szczególnie bogate komentarze (część z których
jedynie znalazła się w tej pracy) – a take pozostałe omówione w drugim
rozdziale badania pokazują, i zarówno dydaktycy, jak i studenci wykazują
zainteresowanie przeznaczonym dla nich serwisem informacyjnym.
Przedstawiony na poprzednich stronach projekt takiego serwisu moe
stanowić podwaliny bogatego i przydatnego systemu, na uytkowaniu
którego skorzystać powinni wszyscy zainteresowani. Nie tylko będzie
on ułatwiał i ulepszał ich codzienne ycie na uczelni (i potencjalnie
take poza nią). Tworzenie i rozbudowywanie serwisu moe być
znakomitym polem do popisu dla studentów Wydziału, a take źródłem
praktycznych tematów prac przejściowych czy nawet magisterskich.
Co więcej, będzie to równie wyśmienity poligon dla rónorakich
badań nad zachowaniem uytkowników serwisu i ogólną uytecznością
WWW oraz pokrewnych technologii, eby nie wspomnieć o prestiu
z posiadania tego typu kompleksowego rozwiązania.
Oczywiście praca ta to dopiero początek. Dokładne, bardziej techniczne
opracowanie elementów serwisu, a następnie ich implementacja oraz
wdroenie to tytaniczne zadanie, wymagające pracy i współpracy wielu
zaangaowanych osób. Od Internetu jednak uciec się nie da, podobnie jak na
dłuszą metę ignorować jego istnienia. Wręcz przeciwnie – naley poczynić
wszelkie moliwe starania, aby w pełni wykorzystać potencjał Sieci. A jeeli
nie uczyni tego Wydział Informatyki, to kto inny?
Aneks Adresy witryn WWW
wyszych uczelni w Polsce
Akademia Ekonomiczna w Katowicach
http://www.ae.katowice.pl
Akademia Ekonomiczna w Krakowie
http://www.ae.krakow.pl
Akademia Ekonomiczna w Poznaniu
http://www.ae.poznan.pl
Akademia Ekonomiczna we Wrocławiu
http://www.ae.wroc.pl
Akademia Górniczo-Hutnicza
http://www.uci.agh.edu.pl
Akademia Marynarki Wojennej
http://www.amw.gdynia.pl
Akademia Medyczna w Białymstoku
http://amb.ac.bialystok.pl
Akademia Medyczna w Bydgoszczy
http://www.amb.bydgoszcz.pl
Akademia Medyczna w Gdańsku
http://www.amg.gda.pl
Akademia Medyczna w Lublinie
http://www.am.lublin.pl
Akademia Medyczna w Łodzi
http://www.am.lodz.pl
Akademia Medyczna w Poznaniu
http://www.usoms.poznan.pl
Akademia Medyczna w Warszawie
http://www.amwaw.edu.pl
Akademia Medyczna we Wrocławiu
http://www.am.wroc.pl
Akademia Morska w Gdyni
http://www.wsm.gdynia.pl
Aneks 120
Akademia Muzyczna im. Fryderyka Chopina
http://www.chopin.edu.pl
Akademia Muzyczna w Gdańsku
http://www.amuz.gda.pl
Akademia Muzyczna w Katowicach
http://www.polbox.com/a/amkce
Akademia Muzyczna w Poznaniu
http://www.paderewski-am.poznan.pl
Akademia Pedagogiczna w Krakowie
http://www.wsp.krakow.pl
Akademia Podlaska
http://www.ap.siedlce.pl
Akademia Polonijna w Częstochowie
http://www.wsjoe.czest.pl
Akademia Rolnicza w Krakowie
http://www.ar.krakow.pl
Akademia Rolnicza w Lublinie
http://swallow.ar.lublin.pl
Akademia Rolnicza w Szczecinie
http://www.ar.szczecin.pl
Akademia Rolnicza w Szczecinie
Wydział Ekonomiki i Organizacji Gospodarki ywnościowej
http://www.e-ar.pl
Akademia Rolnicza we Wrocławiu
http://www.ar.wroc.pl
Akademia Sztuk Pięknych im. Jana Matejki w Krakowie
http://www.asp.krakow.pl
Akademia Sztuk Pięknych w Gdańsku
http://www.asp.gda.pl
Akademia Sztuk Pięknych w Łodzi
http://www.asp.lodz.pl
Akademia Sztuk Pięknych w Poznaniu
http://www.asp.poznan.pl
Akademia Świętokrzyska
http://www.pu.kielce.pl
Aneks 121
Akademia Techniczno-Rolnicza w Bydgoszczy
http://www.atr.bydgoszcz.pl
Akademia Wychowania Fizycznego we Wrocławiu
http://www.awf.wroc.pl
Bałtycka Wysza Szkoła Humanistyczna
http://ns.bwsh.edu.pl
Biblijne Seminarium Teologiczne
http://www.bst.edu.pl
Bielska Wysza Szkoła Biznesu i Informatyki
http://www.tyszkiewicz.edu.pl
Collegium Civitas
http://www.collegium.edu.pl
Filia Uniwerystetu Śląskiego w Cieszynie
http://www.filus.edu.pl
Fundacja Sądecko-Podhalańskie Centrum Szkolenia
http://www.wsb-nlu.edu.pl/FSPCS
Gdańskie Seminarium Duchowne
http://www.gsd.gda.pl
Górnośląska Wysza Szkoła Pedagogiczna
http://www.wsew.edu.pl
Katedra Archeologii UMCS w Lublinie
http://archeo.umcs.lublin.pl
Katedra Teorii Literatury, Teatru i Filmu Uniwersytetu Łódzkiego
http://free.art.pl/ktltf
Katolicki Uniwersytet Lubelski
http://www.kul.lublin.pl
Nauczycielskie Kolegium Językow Obcych
Uniwersytet w Białymstoku
http://ettc.uwb.edu.pl
Olsztyńska Wysza Szkoła Zarządzania
http://www.owsz.edu.pl
Państwowa Wysza Szkoła Filmowa, Telewizyjna i Teatralna
http://www.filmschool.lodz.pl
Państwowa Wysza Szkoła Zawodowa w Tarnowie
http://www.wsz.tarnow.pl
Aneks 122
Papieski Fakultet Teologiczny we Wrocławiu
http://www.pft.wroc.pl
Politechnika Białostocka
http://www.pb.bialystok.pl
Politechnika Białostocka
Wydział Informatyki
http://www.bialystok.pl/ii
Politechnika Częstochowska
http://www.pcz.czest.pl
Politechnika Częstochowska
Wydział Inynierii Mechanicznej i Informatyki
http://ktmiap.pcz.czest.pl
Politechnika Gdańska
http://www.pg.gda.pl
Politechnika Gdańska
Wydział Elektroniki, Telekomunikacji i Informatyki
http://www.eti.pg.gda.pl
Politechnika Koszalińska
http://www.tu.koszalin.pl
Politechnika Krakowska
http://www.pk.edu.pl
Politechnika Lubelska
http://www.pol.lublin.pl
Politechnika Łódzka
http://www.p.lodz.pl
Instytut Informatyki
http://ics.p.lodz.pl
Wydział Organizacji i Zarządzania
http://oizet.p.lodz.pl/oiz
Politechnika Poznańska
http://www.put.poznan.pl
Politechnika Poznańska
http://www.cs.put.poznan.pl
Aneks 123
Politechnika Rzeszowska
http://www.prz.rzeszow.pl
Politechnika Śląska
http://www.polsl.gliwice.pl
Politechnika Śląska
Wydział Automatyki, Elektroniki i Informatyki
http://www.polsl.gliwice.pl/rau
Politechnika Świętokrzyska
http://www.tu.kielce.pl
Politechnika Warszawska
http://www.pw.edu.pl
http://www.ii.pw.edu.pl
Wydział Elektroniki i Technik Informacyjnych
http://www.elka.pw.edu.pl
Wydział Matematyki i Nauk Informacyjnych
http://www.mini.pw.edu.pl/pol/index.html
Politechnika Wrocławska
Wydział Mechaniczny
Indywidualny Tok Studiów
http://www.immt.pwr.wroc.pl/~its
Politechnika Zielonogórska
http://www.pz.zgora.pl
Politechnika Zielonogórska
Instytut Informatyki i Elektroniki
http://www.iie.pz.zgora.pl
Polska Akademia Nauk
Instytut Podstaw Informatyki
http://www.ipipan.waw.pl
Polsko-Japońska Wysza Szkoła Technik Komputerowych
http://www.pjwstk.waw.pl
Pomorska Akademia Medyczna w Szczecinie
http://www.pam.szczecin.pl
Pomorska Akademia Pedagogiczna
http://www.wsp.slupsk.pl
Aneks 124
Profesjonalna Szkoła Biznesu w Krakowie
http://psb.edu.pl
Prywatna Wysza Szkoła Biznesu i Administracji
http://www.pwsbia.edu.pl
Prywatna Wysza Szkoła Zawodowa w Giycku
http://www.karolex.com.pl
Szkoła Główna Gospodarstwa Wiejskiego
http://www.sggw.waw.pl
Szkoła Główna Handlowa
http://www.sgh.waw.pl
Szkoła Główna Słuby Poarniczej
http://www.sgsp.edu.pl
Szkoła Medyczna dla Obcokrajowców
http://www.medschool.cm-uj.krakow.pl
Szkoła Nauk Humanistycznych i Społecznych Uniwersytetu
Zielonogórskiego
http://www.wsp.zgora.pl
Szkoła Nauk Ścisłych w Warszawie
http://snsinfo.ifpan.edu.pl
Szkoła Wysza im. P. Włodkowica w Płocku
http://www.wlodkowic.edu.pl
Szkoła Wysza Psychologii Społecznej
http://www.swps.edu.pl
Szkoła Wysza Warszawska
http://www.sww.edu.pl
Śląska Akademia Medyczna w Katowicach
http://www.slam.katowice.pl
Toruńska Szkoła Zarządzania
http://www.tsz.torun.pl
Uniwersytet w Białymstoku
http://www.uwb.edu.pl
Uniwersytet Gdański
http://www.univ.gda.pl
Uniwersytet Gdański
Międzyuczelniany Wydział Biotechnologii
http://www.biotech.univ.gda.pl
Aneks 125
Uniwersytet im. Adama Mickiewicza w Poznaniu
http://www.amu.edu.pl
Wydział Matematyki i Informatyki
http://www.wmid.amu.edu.pl
Instytut Akustyki
http://www.ia.amu.edu.pl
Uniwersytet Jagielloński
http://www.uj.edu.pl
Uniwersytet Jagielloński
http://www.ii.uj.edu.pl
Uniwersytet Kardynała Stefana Wyszyńskiego w Warszawie
http://www.atk.edu.pl
Uniwersytet Łódzki
http://www.uni.lodz.pl
Uniwersytet Marii Curie-Skłodowskiej w Lublinie
http://www.umcs.lublin.pl
Uniwersytet Marii Curie-Sklodowskiej w Lublinie
Wydział Matematyki, Fizyki i Informatyki
http://mfi.umcs.lublin.pl
Uniwersytet Mikołaja Kopernika w Toruniu
http://www.uni.torun.pl
Uniwersytet Mikołaja Kopernika w Toruniu
Wydział Matematyki i Informatyki
http://www.mat.uni.torun.pl
Uniwersytet Opolski
http://www.uni.opole.pl
Uniwersytet Szczeciński
http://www.univ.szczecin.pl
Uniwersytet Śląski
http://www.us.edu.pl
Uniwersytet Śląski
Wydział Techniki
http://www.tech.us.edu.pl
Aneks 126
Uniwersytet Warmińsko-Mazurski w Olsztynie
http://www.art.olsztyn.pl
Uniwersytet Warszawski
http://www.uw.edu.pl
Uniwersytet Warszawski
Wydział Matematyki, Informatyki i Mechaniki
http://www.mimuw.edu.pl
Uniwersytet Wrocławski
http://www.uni.wroc.pl
Uniwersytet Wrocławski
http://www.ii.uni.wroc.pl
Uniwersytet Zielonogórski
http://www.uz.zgora.pl
Uniwersytet Zielonogórski
Instytut Informatyki i Zarządzania
http://www.iiz.pz.zgora.pl
Warszawska Szkoła Zarządzania
http://www.wsz-sw.edu.pl
Warszawska Wysza Szkoła Ekonomiczna
http://www.wwse.waw.ids.pl
Wojskowa Akademia Medyczna
http://www.wam.lodz.pl
Wojskowa Akademia Techniczna
http://www.wat.waw.pl
Wysza Szkoła Admininstracji i Biznesu w Gdyni
http://www.wsaib-gdy.edu.pl
Wysza Szkoła Administracji Publicznej w Szczecinie
http://www.wsap.szczecin.pl
Wysza Szkoła Administracji Publicznej w Łodzi
http://www.wsap.lodz.pl
Wysza Szkoła Bankowa w Gdańsku
http://www.wsb.gda.pl
Wysza Szkoła Bankowa w Poznaniu
http://www.wsb.poznan.pl
Wysza Szkoła Bankowa w Toruniu
http://www.wsb.torun.pl
Aneks 127
Wysza Szkoła Bankowa we Wrocławiu
http://www.wsb.wroclaw.pl
Wysza Szkoła Bankowości i Finansów w Bielsku-Białej
http://www.wsbif.edu.pl
Wysza Szkoła Bankowości i Finansów w Katowicach
http://www.wsbif-katowice.edu.pl
Wysza Szkoła Biznesu - National-Louis University
http://www.wsb-nlu.nowy-sacz.pl
Wysza Szkoła Biznesu w Dąbrowie Górniczej
http://www.wsb.edu.pl
Wysza Szkoła Biznesu w Tarnowie
http://www.wsb.tarnow.pl
Wysza Szkoła Dziennikarska
http://www.wsd.net.chelm.pl
Wysza Szkoła Dziennikarska w Warszawie Instytut w Kielcach
http://www.wsd-kielce.com.pl
Wysza Szkoła Ekonomii Stosowanej i Handlu Zagranicznego
http://www.ekonomia.edu.pl
Wysza Szkoła Ekonomiczno-Humanistyczna
http://wsehsk.home.pl
Wysza Szkoła Ekonomiczno-Humanistyczna w Bielsku-Białej
http://www.wseh.pl
Wysza Szkoła Handlowa w Kielcach
http://www.wsh-kielce.edu.pl
Wysza Szkoła Handlu i Finansów Międzynarodowych
http://www.wshifm.edu.pl
Wysza Szkoła Handlu i Prawa
http://www.wship.edu.pl
Wysza Szkoła Humanistyczna Pułtusk-Ciechanów
http://www.wsh.edu.pl
Wysza Szkoła Humanistyczno-Ekonomiczna
http://www.wszh-e.edu.pl
Wysza Szkoła Humanistyczno-Przyrodnicza
http://www.wshp.home.pl
Wysza Szkoła Informatyki
http://info.wsinf.edu.pl/index1.htm
Aneks 128
Wysza Szkoła Informatyki i Ekonomii
http://www.wsiie.olsztyn.pl
Wysza Szkoła Informatyki i Zarządzania w Bielsku-Białej
http://www.wsi.edu.pl
Wysza Szkoła Informatyki i Zarządzania
http://www.wsiz.rzeszow.pl
Wysza Szkoła Informatyki Stosowanej i Zarządzania
http://www.wsisiz.edu.pl
Wysza Szkoła Integracji Europejskiej
http://www.wsie.pl
Wysza Szkoła Komunikacji i Zarządzania
http://www.wskiz.poznan.pl
Wysza Szkoła Lingwistyczna w Częstochowie
http://www.wsl.edu.pl
Wysza Szkoła Marketingu i Biznesu w Łodzi
http://www.wsmib.edu.pl
Wysza Szkoła Morska w Szczecinie
http://www.wsm.szczecin.pl
Wysza Szkoła Oficerska im. gen. J. Bema w Toruniu
http://zi.osa.torun.pl
Wysza Szkoła Oficerska w Poznaniu
http://www.wsowp.poznan.pl
Wysza Szkoła Przedsiębiorczości i Administracji w Lublinie
http://www.wspa.lublin.pl
Wysza Szkoła Przedsiębiorczości i Zarządzania
http://www.wspiz.edu.pl
Wysza Szkoła Społeczno-Gospodarcza w Tyczynie
http://www.wssg.rzeszow.pl
Wysza Szkoła Ubezpieczeń i Bankowości
http://www.wsub.waw.pl
Wysza Szkoła Ubezpieczeń w Kielcach
http://ii.wsu.kielce.pl
Wysza Szkoła Umiejętności Społecznych
http://www.wsus.poznan.pl
Wysza Szkoła Zarządzania w Częstochowie
http://www.wsz.edu.pl
Aneks 129
Wysza Szkoła Zarządzania
http://www.wsz.pl
Wysza Szkoła Zarządzania-The Polish Open University
http://www.wsz-pou.edu.pl
Wysza Szkoła Zarządzania i Administracji w Zamościu
http://www.wszia.edu.pl
Wysza Szkoła Zarządzania i Bankowości w Poznaniu
http://www.wszib.poznan.pl
Wysza Szkoła Zarządzania i Bankowości w Poznaniu (oddział we Wrocławiu)
http://www.wszib.wroc.pl
Wysza Szkoła Zarządzania i Bankowości w Krakowie
http://www.wszib.krakow.pl
Wysza Szkoła Zarządzania i Nauk Społecznych
http://www.wszins.tychy.pl
Wysza Szkoła Zarządzania i Przedsiębiorczości im. Bogdana Jańskiego
w Warszawie
http://www.janski.edu.pl
Wysza Szkoła Zawodowa Handlu i Rachunkowości w Poznaniu
http://www.wszhir.poznan.pl
Wysze Seminarium Duchowne w Poznaniu
http://www.wsdsc.poznan.pl
Zachodniopomorska Szkoła Biznesu
http://www.zpsb.szczecin.pl
Bibliografia
1.
Apple Garamond, maj 2002, serwis MacParc
(http://www.macparc.ch/nostalgia/applegaramond).
2.
Authorization, kwiecień 2002, serwis Webopedia.com
(http://www.webopedia.com/TERM/a/authorization.html).
3.
George E. Breen, Albert B. Blankenship, Badania marketingowe
w twojej firmie, PWE, Warszawa 1995.
4.
E. Duliniec, Badania marketingowe w zarządzaniu przedsiębiorstwem,
PWN, Warszawa 1999.
5.
Simson Garfinkel, Gene Spafford, Bezpieczeństwo w Unixie
i Internecie, O’Reilly & Associates, Inc. Wydawnictwo RM, Warszawa
1997.
6.
Rafał Piecuch, Biometria – Technika identyfikacji człowieka, marzec
2002, serwer republika.pl (http://biometria.republika.pl).
7.
CGI environment variables, luty 2002, serwis National Center
for Supercomputing Applications
(http://hoohoo.ncsa.uiuc.edu/cgi/env.html).
8.
Eric Tilton, Composing good HTML, lipiec 1998, serwis ology.org
(http://www.ology.org/tilt/cgh).
9.
Jakob Nielsen, The difference between intranet and Internet design,
wrzesień 1997, serwis useit.com
10.
Stephanie Autrey i Scott Harper, Discovering organizational identity,
2001, serwis link&learn (http://www.linkageinc.com/newsletter/
archives/od/reliant_1.shtml).
11.
Jakob Nielsen, Error message guidelines, czerwiec 2001, serwis
useit.com (http://www.useit.com/alertbox/20010624.html).
12.
Evaluating the size of the Internet, kwiecień 2002, serwis Telcordia
Technologies (http://www.netsizer.com).
13.
Extranet, kwiecień 2002, serwis Webopedia.com
(http://www.pcwebopaedia.com/TERM/e/extranet.html).
14.
Bruce Tognazzini, First principles, 2001, serwis Nielsen Norman
Group (http://www.asktog.com/basics/firstPrinciples.html).
15.
Jakob Nielsen, Flash: 99% Bad, październik 2000, serwis useit.com
16.
Joe Gillespie, Font comparison, maj 2002, serwis Web page design for
designers: typography (http://www.wpdfd.com/wpdfonts2.htm).
Bibliografia 131
17.
Font embedding on the Web, kwiecień 2002, serwer Microsoft (http:
//www.microsoft.com/typography/web/embedding).
18.
Jakob Nielsen, Frames suck (most of the time), grudzień 1996, serwis
19.
Frequently asked questions about today’s cryptography, praca
zbiorowa, RSA Laboratories 2000.
20.
Stephanos Piperoglou, How not to build a Web application, kwiecień
2002, serwis WebReference (http://www.webreference.com/html/
watch/standards).
21.
Internets and intranets, luty 2002, serwis Consumer Protection Board
(http://www.consumer.state.ny.us/clahm/internet.htm).
22.
Harry M. Kriz, Internet services, maj 2000, serwis VirginiaTech
(http://learning.lib.vt.edu/wintcpip/services.html).
23.
Interface, maj 1996, serwis The Free On-line Dictionary of
Computing (http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?quer
y=interface).
24.
Java vs. JavaScript, 2002, serwis First Step Communications
(http://www.firststep.com.au/education/solid_ground/
javadiff.html).
25.
Justin Howes, Johnston’s underground type, Capital Transport
Publishing, Londyn 2000.
26.
David Lawrence, A logo for London, Capital Transport Publishing,
Londyn 2000.
27.
Klemens P. Białecki, Marketing, WPE Infor, Warszawa 1998.
28.
Jakob Nielsen, Microcontent: headlines and subject lines, wrzesień
1998, serwis useit.com (http://www.useit.com/alertbox/
980906.html).
29.
Microsoft .NET, kwiecień 2002, serwis Microsoft
(http://www.microsoft.com/net).
30.
Eric S. Raymond, The New Hacker’s Dictionary (3rd Edition),
MIT Press, Massachusetts 1996.
31.
Elaine Ashton, Perl timeline, kwiecień 2002, serwis Perl Mongers
(http://history.perl.org/PerlTimeline.html).
32.
PHP usage stats, marzec 2002, serwis PHP.net
(http://www.php.net/usage.php).
33.
Jeffrey D. Ullman, Jennifer Widom, Podstawowy wykład z systemów
baz danych, Wydawnictwa Naukowo-Techniczne Warszawa 2000.
Bibliografia 132
34.
Alyson L. Hill , Readibility of websites with various foreground/
background color combinations, font types and word styles,
Department of Psychology, Stephen F. Austin State University, 1997
(http://hubel.sfasu.edu/research/AHNCUR.html).
35.
Piotr Rabiej, Rekord popularności, Twoja Komórka 2/2002
(http://www.twoja-komorka.com.pl/a2002_021.htm).
36.
Jakob Nielsen, Response times: the three important limits,
1994, serwis useit.com (http://www.useit.com/papers/
responsetime.html).
37.
Jakob Nielsen, Search and you may find, lipiec 1997, serwis useit.com
38.
Jakob Nielsen, Search: visible and simple, maj 2001, serwis useit.com
39.
Jakob Nielsen, Security & human factors, listopad 2000, serwis
40.
Semantic Web, maj 2002, serwis W3C
(http://www.w3.org/2001/sw).
41.
Jakob Nielsen, Security & human factors, listopad 2000, serwis
42.
Jakob Nielsen, Site map usability, styczeń 1997, serwis useit.com
43.
The size of the World Wide Web, październik 2001, serwis Pandia
(http://www.pandia.com/sw-2001/57-websize.html).
44.
Stephanos Piperoglou, Take a stand and understand the standard
standard,
sierpień 1999, serwis WebReference (http://webreference.com/
html/watch/standards), wstęp.
45.
Jeffrey Zeldman, Taking your talent to the Web, kwiecień 2002, serwis
WebReference (http://www.webreference.com/authoring/design/
talent/chap3/2).
46.
Jakob Nielsen, The 10 best intranet designs of 2001, listopad 2001,
serwis useit.com (http://www.useit.com/alertbox/20011125.html).
47.
Jakob Nielsen, Ten good deeds in web design, październik 1999,
48.
Bryan Pfaffenberger, The elements of Hypertext Style, AP Professional,
Londyn 1997.
49.
Tim Berners-Lee, Tim Berners-Lee – frequently asked questions, 2000,
serwis W3C (http://www.w3c.org/People/Berners-Lee/FAQ.html).
50.
Jakob Nielsen, Top ten mistakes revisited three years later, maj 1999,
Bibliografia 133
51.
David Whalen, The unofficial cookie FAQ, maj 1999, serwis
Cookiecentral.com (http://www.cookiecentral.com/faq).
52.
URL howto, serwis PHP.net (http://www.php.net/urlhowto.php).
53.
Jakob Nielsen, WAP Backlash, lipiec 2000, serwis useit.com
54.
Matthew Gray, Web growth summary, 1996, serwis Massachusetts
Institute of Technology (http://www.mit.edu/people/mkgray/net/
printable/web-growth-summary.html).
55.
Thea Partridge, What is an interface?, 2001, serwis Techbabes (http:
//www.techbabes.com/WebTech/Interface/whatis.html).
56.
Chip Salzenberg, What is Usenet?, styczeń 1998,
serwis Internet FAQ Consortium
(http://www.faqs.org/faqs/usenet/what-is/part1).
57.
Jeffrey Zeldman, Where am I? Navigation and interface, kwiecień
2002, serwis WebReference (http://www.webreference.com/
authoring/design/talent/chap3/1).
58.
Why PHP?, marzec 2002, serwis Zend
(http://www.zend.com/why-php.php).
59.
Simon St. Laurent, Why XML?, kwiecień 2002, serwis Simon
St. Laurent (http://www.simonstl.com/articles/whyxml.htm).
60.
Zeitgeist, serwis Google
(http://www.google.com/press/zeitgeist.html).
Spis rysunków
1.
Witryna firmy Apple
19
2.
Witryna Transport for London
19
3.
Elektroniczna tablica informacyjna na Wydziale Informatyki
25
4.
Plan zajęć dla studentów
26
5.
Witryna Wydziału Informatyki Politechniki Szczecińskiej
27
6.
Wirtualna Szkoła Wyszej Szkoły Biznesu w Nowym Sączu
30
7.
System SUSZI Wyszej Szkoły Zarządzania i Bankowości w Krakowie
31
8.
Student Info – witryna WETiI Politechniki Gdańskiej
31
9.
Serwer studencki PJWSTK
32
10.
System Szkoła Wyszej Szkoły Informatyki Stosowanej i Zarządzania
32
11.
Wirtualna Uczelnia Wyszej Szkoły Informatyki i Zarządzania
33
12.
MyUW – witryna dla studentów i pracowników University
of Washington
34
13.
MyUCLA Portal – witryna dla studentów i pracowników University
of California
34
14.
Portal my.harvard dla studentów i pracowników University of Harvard
34
15.
MyStanford – witryna Uniwersytetu w Stanford
35
16.
Portal dla studentów i pracowników Caltech
36
17.
Witryna my.utoronto.ca Uniwersytetu w Toronto
37
18.
Elita Exclusive Club
37
19.
Studencki System Wymiany Informacji – serwis II roku informatyki 38
20.
Strona II roku Informatyki Politechniki Poznańskiej
39
21.
Menu nawigacyjne czterech sekcji serwisu STARTREK.COM
62
22.
Projekt interfejsu serwisu informacyjnego
69
23.
Strona autoryzacji
72
24.
Strona główna serwisu informacyjnego
73
25.
Zajęcia – strona główna
77
26.
78
27.
Lista zajęć
79
Spis rzeczy 135
28.
Wyszukiwanie zajęć
80
29.
Zajęcia – zjazdy
81
30.
Zajęcia – przedmioty
82
31.
Informacje o konkretnym przedmiocie
83
32.
Wiadomości
85
33.
Informacje o wykładowcy
97
34.
Projekt struktury bazy danych
115
Spis tabel
1.
Syndrom „kliknij tutaj”
18
2.
Zapis mechaniczny a zapis naturalny
21
3.
Porównanie najpopularniejszych w Internecie metod dyskusji
92
Spis wykresów
1.
Obecność serwisów informacyjnych na wyszych uczelniach w Polsce
29
2.
Dostęp studentów do Internetu
3.
Posiadanie własnego, niezalenego od uczelnianego konta pocztowego
43
4.
Przeglądarki wykorzystywane przez ankietowanych
43
5.
Liczba wykorzystywanych przez badanych przeglądarek
43
6.
Preferowana forma dyskusji w Internecie
44
7.
Przydatność aktualnej strony WWW Wydziału Informatyki
45
8.
Przydatność usług oferowanych przez system informacyjny
45
9.
Systemy operacyjne komputerów spoza Wydziału Informatyki
46
10.
Systemy operacyjne komputerów na Wydziale Informatyki
47
11.
Przeglądarki na komputerach spoza Wydziału Informatyki
47
12.
Przeglądarki dostępne w Wydziale Informatyki
48
13.
Rodzaje połączenia z Internetem
48
14.
Preferowany sposób dostępu do portalu MIT
49
15.
Przydatność usług oferowanych przez portal MIT
50
16.
Popularność poszczególnych stron serwisu intranetowego
73
42
Indeks
.NET 12
auditing 116
autodiagnostyka 117
backup 116
buffer overflow 114
CGI 11, 45, 66, 114
chat 50
cookies 12
CSS 109
DHTML 11
e-mail 9, 15, 25, 27, 43, 62, 63,
70, 75, 84, 90, 92, 101
login 27, 29, 59, 70, 71, 72
Lynx 43
Mac OS 46
MS-DOS 107
Netscape 9, 43, 66
offline 94
organizational identity 18, 99
PDF 99
Perl 11
PHP 11
progressive disclosure 73
SDI 48
ekstranet 13
Semantic Web 12
etykietki 18
single sign-on 71, 107
FAQ 102
smartcard 111, 112
Flash 12, 69
SMS 60, 71, 75, 103, 108
FTP 9, 89
spam 90
Gopher 9
SSL 51, 72, 116
HTML 9, 61, 69, 85
UBB 88, 94
HTTP 9, 12, 52
upload 91, 99
HTTPS 52, 72
URI 9
Internet Explorer 9, 43, 66
Usenet 9, 44, 92
intranet 13
WAP 111
JavaScript 10, 69, 87
Windows 46
LDAP 111
WWW 9, 14, 58
Linux 46
XML 12, 66

wydział informatyki katedra organizacji i zarządzania

Transkrypt

Podobne dokumenty

Strategia dla lokalo.pl

Rzeszowski serwis imprezowy-Agendo