ROCZNIKI GEOMATYKI 2016 m TOM XIV m ZESZYT 5(75): 597–608
Projektowanie zorientowane na u¿ytkownika
oraz metody zwinnego programowania
w procesie tworzenia geoportalu wspieraj¹cego
partycypacjê spo³eczn¹ w planowaniu przestrzennym
*User-centered design and agile programming methods
in the process of creating a geoportal supporting
public participation in urban planning
Marek M³odkowski1, Dariusz Walczak2, Piotr Jankowski1,3
1Uniwersytet im. Adama Mickiewicza w Poznaniu, Wydzia³ Nauk Geograficznych i Geologicznych 2Uniwersytet Ekonomiczny w Poznaniu, Wydzia³ Informatyki i Gospodarki Elektronicznej
3San Diego State University, Department of Geography
S³owa kluczowe: projektowanie zorientowane na u¿ytkownika, partycypacyjny GIS, zwinne programowanie, planowanie przestrzenne, interakcja cz³owiek-komputer
Keywords: user-centered design, public participation GIS, agile programming, urban planning, human-computer interaction
Wprowadzenie
Tradycyjnie systemy informacji geograficznej (ang. Geographic Information Systems, GIS) s¹ wykorzystywane g³ównie przez wysoko wykwalifikowanych specjalistów, w ta-kich dziedzinach jak: zarz¹dzanie sieciami transportowymi i energetycznymi, katastrem oraz zasobami naturalnymi. Jednak¿e od pewnego czasu, zakres wykorzystania systemów infor-macji geograficznej znacznie siê powiêkszy³, przede wszystkim dziêki dynamicznemu roz-wojowi technologii oraz aplikacji internetowych. Obecnie szerokie grono u¿ytkowników bez formalnej wiedzy na temat GIS z powodzeniem wykorzystuje w codziennym ¿yciu interne-towe aplikacje mapowe. Jednym z obecnych kierunków rozwoju GIS jest zastosowanie ich jako narzêdzia umo¿liwiaj¹cego udzia³ spo³eczeñstwa w podejmowaniu decyzji (Andrzejew-ska i in., 2007; Hanzl, 2009; Jankowski, 2011; Kingston, 2011; Nyerges i in., 2011). Obsza-rem sfery publicznej, w której tego typu rozwi¹zania mog¹ znaleŸæ zastosowanie jest plano-wanie przestrzenne. Podczas tworzenia miejscowych planów zagospodarowania przestrzen-* Badania, w ramach których powsta³ geoportal, sfinansowano ze œrodków Narodowego Centrum Nauki, numer grantu 2012/05/B/HS4/03850.
nego istotne jest uwzglêdnienie podstawowych potrzeb mieszkañców, ich obaw, preferencji i opinii na temat proponowanych rozwi¹zañ. Proces planowania przestrzennego regulowany jest w Polsce przez ustawê z dnia 27 marca 2003 roku o planowaniu i zagospodarowaniu przestrzennym (Ustawa, 2003). Ustawa okreœla minimalny poziom partycypacji spo³ecznej w planowaniu: obywatele maj¹ prawo do zg³aszania pisemnych wniosków na pocz¹tku oraz na koñcu procesu przyst¹pienia do sporz¹dzenia dokumentów, a tak¿e do wziêcia udzia³u w wys³uchaniach publicznych. W Poznaniu, na wniosek Rady Miasta Poznania, wprowadzo-no w 2010 roku regularne pozaustawowe konsultacje dotycz¹ce dokumentów planistycz-nych przygotowywaplanistycz-nych przez Miejsk¹ Pracowniê Urbanistyczn¹. Rozwi¹zaniem wycho-dz¹cym naprzeciw tej idei wsparcia demokracji bezpoœredniej s¹ internetowe partycypacyjne systemy informacji geograficznej (ang. Public Participation GIS, PPGIS) (Kingston, 2011; Jankowski, 2011), dziêki którym mieszkañcy mog¹ za pomoc¹ mapowych aplikacji interne-towych wyraziæ swoje opinie co do zagospodarowania przestrzeni oraz wymieniæ siê infor-macjami ze specjalistami w dziedzinie planowania przestrzennego.
Istnieje wiele przyk³adów wykorzystania PPGIS w planowaniu przestrzennym (m.in. Andrzejewska i in., 2007; Jankowski, 2011). Jednak¿e Ganapati (2010) wskazuje, ¿e w wiêkszoœci by³y to projekty badawczo-rozwojowe, które rzadko by³y wdra¿ane w prakty-ce. Powa¿n¹ barier¹ dla praktycznego wykorzystania PPGIS mog¹ byæ Ÿle zaprojektowane funkcje, ma³o czytelny interfejs graficzny lub zbyt wygórowane wymagania co do umiejêt-noœci u¿ytkowników w pos³ugiwaniu siê aplikacjami mapowymi (Elwood, 2002). Innym powodem, dla którego wykorzystanie PPGIS mo¿e przynieœæ negatywne skutki jest to, i¿ proces projektowania i wytwarzania internetowego PPGIS odbywa³ siê bez bezpoœredniego zaanga¿owania przedstawicieli grup spo³ecznych, które w przysz³oœci maj¹ z niego korzy-staæ (Uran, Jassen, 2003). Czepkiewicz i Snabb (2013) wskazuj¹ jeszcze jeden istotny po-wód, którym jest zbyt du¿e skupienie siê na rozwi¹zaniach technologicznych z pomiêciem odpowiednich analiz faktycznych potrzeb u¿ytkowników. Jednym ze sposobów na polep-szenie sytuacji jest zastosowanie iteracyjnego procesu wytwarzania oprogramowania, filo-zofii projektowania zorientowanego na potrzeby u¿ytkownika oraz metod badania interakcji cz³owieka z komputerem (Haklay, 2010).
W artykule przedstawiono wyniki badañ u¿ytecznoœciowych przeprowadzonych pod-czas budowy geoportalu, którego g³ównym zadaniem jest umo¿liwienie uczestnictwa w kon-sultacjach spo³ecznych na temat miejscowych planów zagospodarowania przestrzennego w Poznaniu za poœrednictwem Internetu.
Metodyka
Projektowanie zorientowane na u¿ytkownika
Filozofia projektowania zorientowanego na u¿ytkownika (ang. user centred design, UCD) sk³ada siê z piêciu etapów (Haklay, 2010) (rys. 1): (1) zebranie informacji o planowanym produkcie, jego u¿ytkownikach i ich celach, (2) analiza wymagañ u¿ytkowników, (3) pro-jektowanie rozwi¹zania, (4) ewaluacja oraz (5) stworzenie finalnego projektu funkcjonalno-œci. Jest to proces iteracyjny. Na etapie ewaluacji robionej za pomoc¹ testów u¿ytecznoœcio-wych podejmuje siê decyzjê b¹dŸ zaprojektowane rozwi¹zanie jest gotowe do wdro¿enia. Negatywny wynik testu skutkuje powrotem do fazy projektowania (Haklay, 2010).
Filozofia UCD by³a ju¿ kilkukrotnie przedmiotem badañ zwi¹zanych z wykorzystaniem jej przy projektowaniu aplikacji GIS. Haklay i Tabon (2003) wskazuj¹, i¿ podczas projekto-wania PPGIS powinno siê koncentrowaæ na potrzebach i umiejêtnoœciach u¿ytkowników, poniewa¿ najczêœciej nie posiadaj¹ oni fachowej wiedzy z zakresu GIS. Robinson i in. (2005) rekomenduje zastosowanie UCD w aplikacjach, w których k³adziony jest nacisk na wizuali-zacjê danych przestrzennych. Nival i in. (2008) zalecaj¹ stosowanie UCD we wszelkiego rodzaju aplikacjach mapowych, a szczególnie w tych, które bêd¹ udostêpnione poprzez Internet.
Testowanie u¿ytecznoœci
Nielsen (1993) jako u¿ytecznoœæ okreœla to czy dany produkt dzia³a w sposób, który spe³nia potrzeby u¿ytkownika. Badaniami nad u¿ytecznoœci¹ produktów zajmuje siê dziedzi-na dziedzi-nauki zwadziedzi-na Interakcja cz³owiek-komputer (ang. human computer interaction, HCI). W literaturze istnieje wiele przyk³adów badañ nad u¿ytecznoœci¹ ju¿ funkcjonuj¹cych: inter-netowych aplikacji mapowych (Skarlatiodu, Haklay, 2006; Nivala i in., 2008), desktopo-wych aplikacji GIS (Haklay, Zafiri, 2008), internetodesktopo-wych PPGIS (Haklay, Tobon, 2003, Meng, Malczewski, 2010) oraz systematów wspomagania decyzji przestrzennych (Andrien-ko i in., 2002). Zhao i Coleman (2007) oraz Sildlar i Rinner (2007) przygotowali zbiór metod badania u¿ytecznoœci PPGIS. Wyniki i rekomendacje, miêdzy innymi z tych badañ oraz wspó³praca z potencjalnymi u¿ytkownikami PPGIS da³y autorom podstawê do doboru od-powiednich funkcji wykorzystanych podczas budowy geoportalu. W badaniach autorzy wy-korzystywali trzy miary u¿ytecznoœci:
1) skutecznoœæ – mierzon¹ iloœci¹ czasu potrzebnego na wykonanie zadania, 2) liczbê b³êdów podczas wykonania zadania,
3) poziom trudnoœci (Nilsen, 1993).
Metodyki zwinnego programowania
Metodyki zwinnego programowania (Agile manifesto, 2001) skupiaj¹ siê na jak najszyb-szym dostarczeniu odbiorcy gotowych do przetestowania funkcji. Takie podejœcie ma zmini-malizowaæ ryzyko zwi¹zane z dostarczeniem produktu, który nie bêdzie spe³nia³ wymagañ u¿ytkowników. Jedn¹ z najbardziej popularnych implementacji manifestu Agile jest metodyka Scrum (Deemer i in., 2009). Dzieli ona projekt na iteracje – trwaj¹ce zazwyczaj od 1 do 4 tygodni, podczas których wybrane funkcje przechodz¹ przez pe³en proces wytwarzania oprogramowania, od projektowania przez implementacjê do wielopoziomowego testowania. Wszystko to dzieje siê przy œcis³ej wspó³pracy zespo³u tworz¹cego oprogramowanie z po-tencjalnymi u¿ytkownikami.
Identyfikacja u¿ytkowników geoportalu
Podstawowym za³o¿eniem UCD jest skoncentrowanie siê na potrzebach potencjalnych u¿ytkowników produktu. Dlatego pierwszym etapem prac by³a identyfikacja interesariuszy procesu planowania przestrzennego w Poznaniu. Spoœród wszystkich grup interesariuszy skupiono siê na tych, którzy interesuj¹ siê sprawami zwi¹zanymi z zagospodarowaniem przestrzeni miejskiej i chêtnie wyra¿aj¹ swoje uwagi na temat preferencji zagospodarowania przestrzennego, a mniejsz¹ uwagê poœwiêcaj¹ tym, którzy s¹ odbiorcami tych uwag. Prze-prowadzono 61 wywiadów, na podstawie których, pos³uguj¹c siê metod¹ Personas (Nyer-ges, Ramsey, Wilson, 2006), stworzono 5 profili potencjalnych u¿ytkowników geoportalu: Aktywista miejski; Mieszkaniec – osoba przyjezdna; Mieszkaniec – osoba mieszkaj¹ca w Poznaniu od urodzenia; Przedsiêbiorca/Inwestor lokalny; Specjalista – planiœci/pracowni-cy urzêdu/radni. Ka¿dy z tych profili zawiera³ dane socjodemograficzne, opis umiejêtnoœci technicznych oraz informacje silnie zale¿ne od kontekstu projektu, takie jak doœwiadczenia oraz cele w obszarze zwi¹zanym z geoportalem. G³ównym zadaniem profili by³o dostarcze-nie zagregowanych informacji o celach, potrzebach informacyjnych i umiejêtnoœciach po-tencjalnych grup u¿ytkowników geoportalu.
Proces budowy geoportalu trwa³ 6 miesiêcy i by³ poprzedzony analiz¹ literatury dotycz¹-cej badañ u¿ytecznoœci funkcji dostêpnych w istniej¹cych narzêdziach PPGIS. Prace rozpo-czê³y siê w paŸdzierniku 2013 roku. Sk³ada³y siê z czterech g³ównych iteracji, podczas których wykonywano: prace projektowe, prace programistyczne oraz testy u¿ytecznoœcio-we z udzia³em osób zainteresowanych tematyk¹ planowania przestrzennego. Prace progra-mistyczne prowadzono przy u¿yciu metodyki Scrum. Wspó³praca z uczestnikami badania obywa³a siê na zasadzie indywidualnych spotkañ. Na pierwszym spotkaniu omówiono cel wynikaj¹cy z projektu budowanego geoportalu oraz potrzeby funkcjonalne i motywacje uczest-ników. W dalszej kolejnoœci omawiane by³y szczegó³owe funkcjonalnoœci, które zdaniem uczestników badania pozwol¹ na zrealizowanie ich celów oraz ogólne wytyczne, co do u³o-¿enia elementów interfejsu graficznego. Nielsen (2012) wskazuje, i¿ wykonanie badañ u¿y-tecznoœciowych na grupie 5 osób pozwala na wykrycie praktycznie wszystkich problemów zwi¹zanych z u¿ytecznoœci¹.
W ka¿dej iteracji wziê³o udzia³ ³¹cznie 8 osób, których profile odpowiada³y wczeœniej przygotowanym „personom”, w tym 6 sta³ych u¿ytkowników, którzy uczestniczyli w bada-niach w ka¿dej iteracji. Na tê grupê sk³ada³o siê 3 mê¿czyzn w zró¿nicowanym wieku:
m 45 lat (przedsiêbiorca zajmuj¹cy siê projektowaniem miejscowych planów zagospo-darowania przestrzennego),
m 52 lata (aktywista miejski) oraz trzy kobiety:
m 30 lat (prowadzi w³asne przedsiêbiorstwo, bra³a udzia³ dwukrotnie w konsultacjach spo³ecznych na temat planów miejscowych),
m 58 lat (nauczycielka na emeryturze udzielaj¹ca siê w organizacjach pozarz¹dowych), m 28 lat (udziela siê w Towarzystwie Przyjació³ So³acza).
Pozosta³e osoby rekrutowane by³y do ka¿dej iteracji osobno. Byli to studenci (za ka¿dym razem kobieta i mê¿czyzna) z Wydzia³u Nauk Geograficznych i Geologicznych Uniwersytetu im. Adama Mickiewicza w Poznaniu.
Projektowanie i testy u¿ytecznoœciowe
Zgodnie z za³o¿eniami UCD, jeszcze przed rozpoczêciem implementacji funkcji odby³y siê pierwsze testy u¿ytecznoœciowe zwi¹zane z obs³ug¹ map. Mo¿na by³o je przeprowadziæ dziêki dostêpnym przyk³adom w bibliotekach programistycznych Open Layers (http:// openlayers.org/two/) oraz Leafleat (http://leafletjs.com/). Uczestnicy testów mieli do wyko-nania zadania ujête w tabeli 1. Podczas testów mierzono czas potrzebny na wykonanie zada-nia, liczbê b³êdów oraz poziom trudnoœci. W tym ostatnim przypadku do pomiaru przyjêto 5-stopniow¹ skalê, w której wartoœæ 1 odpowiada³a interpretacja „bardzo ³atwe”, zaœ war-toœæ 5 oznacza³a zadanie „bardzo trudne”. Ka¿dy z testów na etapie implementacji polega³ na realizacji przez uczestnika badania wyznaczonego zadania, które by³o rejestrowane za po-Tabela 1. Funkcje zwi¹zane z obs³ug¹ mapy poddane testom u¿ytecznoœciowym i wyniki tych testów
e i n a d a Z Czaswykonania ] s [ a i n a d a z a b z c i L w ó d ê ³ b i c œ o n d u r t m o i z o P ) 5 -1 a l a k s ( a i n d e r œ mediana œrednia mediana œrednia mediana u k o d i w e i n e ¿ i l b y z r p e n l a m y s k a M " -" i " + " y n o k i ¹ c o m o p a z y p a m 9 , 2 1 11,0 0,0 0,0 1,0 1,0 e i p a m a n a c s j e i m e i n a w o d j a n d O i j c k n u f m e i n a t s y z r o k y w z e i s e r d a o p a i n a k u z s 8 , 9 2 17,5 1,1 1,0 2,0 2,0 u n o g i l o p e i n a w o s y R o g e i k c y ¿ e J u k n y R y r u t n o k 8 , 6 2 10,5 1,0 0,5 2,0 1,5 e i p a m a n u t k n u p e i n a z c z s e i m U 5,5 5,0 0,0 0,0 1,0 1,0 j e n a l t e i w œ y w a n a i m Z j e w o d a ³ k d o p y p a m 4 , 4 1 9,5 1,0 0,5 2,1 2,0 w t s r a w i c œ o n j e l o k a n a i m Z 28,1 13,0 0,9 1,0 2,4 2,0 w t s r a w æ œ o t s y z c o r z e z r P 28,0 17,0 0,3 0,0 1,8 1,5 i c œ o ³ g e l d o r a i m o P 7,3 6,5 0,0 0,0 1,1 1,0 i n h c z r e i w o p r a i m o P 20,3 14,5 0,3 0,0 2,1 2,0 i j c a m r o f n i e i n a w y t y z c d O w ó t k e i b o h c a r t e m a r a p o h c y w o p a m 6 , 2 1 8,0 0,6 0,5 2,4 2,5
moc¹ aplikacji „Jing” nagrywaj¹cej obraz z monitora. Dodatkowo, po ka¿dym z testów u¿ytkownicy byli proszeni o komentarze, które pos³u¿y³y do wprowadzenia odpowiednich modyfikacji w kolejnych iteracjach i oceny trudnoœci zadania. Jako g³ówn¹ miarê kwalifiku-j¹c¹ dan¹ funkcjê do modyfikacji przyjêto liczbê b³êdów pope³nionych podczas pierwszego u¿ycia. Je¿eli dwie lub wiêcej osób pope³ni³o przynajmniej dwa b³êdy funkcja by³a zmieniana i poddawana kolejnym testom. Wyniki badañ przedstawiono w tabeli 1.
Za niezrozumia³e i trudne w obs³udze zosta³y wskazane przez u¿ytkowników funkcje daj¹ce mo¿liwoœæ zmiany kolejnoœci warstw mapy oraz ustawienia przezroczystoœci warstw mapy. Z tego powodu nie przekazano ich do fazy implementacyjnej. Funkcje, takie jak ryso-wanie poligonu oraz odczytyryso-wanie informacji o obiektach geograficznych równie¿ sprawi³y uczestnikom badania du¿o trudnoœci. Jednak¿e, ich implementacja by³a konieczna ze wzglê-du na to, ¿e ich brak w znacznym stopniu ogranicza³by mo¿liwoœci wprowadzania treœci oraz analizowania zapisów planu. W przypadku rysowania poligonu, najwiêcej problemów sprawi³ sposób zakoñczenia rysowania, który w testowanym przyk³adzie polega³ na klikniê-ciu w pocz¹tkowy punkt poligonu. Czterech uczestników badania poda³o dwie bardzo po-dobne uwagi dotycz¹ce tej funkcji. Pierwsza uwaga – zakoñczenie rysowania powinno od-byæ siê po podwójnym klikniêciu myszk¹, któremu powinno towarzyszyæ wyœwietlanie in-strukcji postêpowania w postaci tekstu przy wskaŸniku myszy. Druga uwaga dotyczy³a równie¿ pozosta³ych narzêdzi, które pozwalaj¹ dokonywaæ operacji na mapie. Dodatkowo 4 osoby niemaj¹ce doœwiadczenia z GIS wskaza³y nazwê „poligon” jako niezrozumia³¹, któr¹ nale¿y zast¹piæ inn¹, na przyk³ad „obszar”. Szeœæ krytycznych uwag zosta³o zg³oszonych do funkcji odpowiedzialnej za zmianê wyœwietlania map podk³adowych. W testowanym przy-k³adzie ta funkcja by³a dostêpna z poziomu rozwijanego menu. Nawet osoby maj¹ce do-œwiadczenie w wykorzystaniu GIS wskaza³y, i¿ menu odpowiedzialne za zamianê warstw powinno byæ zawsze widoczne. Wszyscy uczestnicy badania wskazali, i¿ funkcja odpowie-dzialna za wyszukiwanie adresu dzia³a niepoprawnie. Sugerowano, i¿ powinna dzia³aæ tak jak w mapach firmy Google, gdzie wystarczy wpisaæ jedynie nazwê ulicy i numer bez koniecz-noœci wpisywania miasta.
W kolejnych iteracjach po³o¿ono nacisk na zaprojektowanie i przetestowanie funkcji i mechanizmów geoportalu odpowiedzialnych za prowadzenie dyskusji w postaci forum po³¹czonego z map¹. Wyniki testów zaprezentowano w tabeli 2.
Uczestnicy badania nie mieli ¿adnych problemów z okreœleniem swych potrzeb i wyarty-ku³owaniem tego jak powinny dzia³aæ funkcje zwi¹zane z prowadzeniem dyskusji. Podczas zbierania wymagañ najczêœciej sugerowane by³y rozwi¹zania znane z forów internetowych i mediów spo³ecznoœciowych (Facebook). Wykonane testy u¿ytecznoœciowe potwierdzi³y to, ¿e uczestnicy badania nie maj¹ problemów z wprowadzaniem wypowiedzi, komentowa-niem, ocen¹ (“za” lub “przeciw”) wypowiedzi innych uczestników lub te¿ sortowaniem i wyszukiwaniem testów. Tylko dwie funkcje z modu³u dyskusji musia³y ulec modyfikacji po etapie implementacji: (1) lokalizowanie dyskusji na mapie, (2) odœwie¿anie. W przypadku lokalizowania w¹tku dyskusyjnego na mapie pocz¹tkowo zastosowano ikonê obrazuj¹c¹ punkt na mapie. By³o to na tyle myl¹ce, ¿e œrednia liczba b³êdów wynios³a 3, a œredni poziom trudnoœci zosta³ okreœlony na 4. Zastosowano modyfikacjê polegaj¹c¹ na zmianie ikony w przycisk z opisem „poka¿ na mapie” oraz animacjê polegaj¹c¹ na pulsowaniu wybranego obiektu na mapie. Problem z funkcj¹ odœwie¿ania polega³ na zbyt ma³o wyraŸniej ikonie prezentuj¹cej symbol odœwie¿ania, przez co 3 uczestników badania nie ukoñczy³o tego zada-nia. W tym przypadku równie¿ zastosowano przycisk z opisem zamiast ikony. Po dokonaniu modyfikacji, b³êdy zwi¹zane z ich funkcjonowaniem nie powtórzy³y siê.
Podczas 4 iteracji wykonano 39 prototypów funkcji. Po dokonaniu wstêpnej ewaluacji przy udziale potencjalnych u¿ytkowników geoportalu, 20 funkcji przekazano do zaimple-mentowania – w tym 5 funkcji zwi¹zanych z obs³ug¹ mapy by³o modyfikowanych w kolej-nej iteracji po wykonaniu testów u¿ytecznoœciowych, a 2 z nich kolejny raz przekazano do modyfikacji. W przypadku funkcji zwi¹zanych z modu³em dyskusji liczba zmian by³a znacz-nie mznacz-niejsza. Jedyznacz-nie 2 funkcje po wykonanych testach u¿ytecznoœciowych przekazano do modyfikacji – po dokonaniu rekomendowanych zmian, zosta³y przetestowane, a nastêpnie zaakceptowane.
Geodyskusja – aplikacja wspieraj¹ca partycypacjê
w planowaniu przestrzennym
Architektura systemu by³a inspirowana wzorcem projektowym MVC (ang. model-view-controler) (Leff, Rayfield, 2001), który zaleca rozdzielenie aplikacji na 3 warstwy (rys. 2): (1) modelu danych, (2) kontrolera realizuj¹cego podstawowe funkcje aplikacji oraz (3) wi-doku, warstwy odpowiedzialnej za prezentacjê informacji. Ostatnia z nich jest kluczowa, gdy¿ wygoda u¿ytkownika mo¿e mieæ decyduj¹cy wp³yw na sukces lub pora¿kê geoportalu. Poniewa¿ wiêkszoœæ interakcji z u¿ytkownikiem odbywa siê na jednej stronie zdecydowano siê wykorzystaæ bibliotekê AngularJS. U³atwia ona tworzenie aplikacji typu „single-page”,
Tabela 2. Funkcje zwi¹zane z obs³ug¹ modu³u dyskusji poddane testom u¿ytecznoœciowym i wyniki tych testów
e i n a d a Z Czaswykonania ] s [ a i n a d a z a b z c i L w ó d ê ³ b i c œ o n d u r t m o i z o P ) 5 -1 a l a k s ( a i n d e r œ mediana œrednia mediana œrednia mediana i j s u k s y d u k t ¹ w o g e w o n e i n a d o D u t k n u p e i n e z c a n z o z e z r p o p e i p a m a n 0 , 0 3 11,0 0,1 0 1,0 1,0 i j s u k s y d u k t ¹ w o g e w o n e i n a d o D u r a z s b o e i n e z c a n z o z e z r p o p e i p a m a n 1 , 1 4 14,4 0,0 0 1,0 1,0 a z r a t n e m o k e i n a d o D i j s u k s y d u k t ¹ w o g e c ¹ j e i n t s i o d 0 , 6 1 4,9 0,1 0 1,0 1,0 w i c e z r p b u l a z a n e c O 2,5 1,0 0,0 0 1,0 1,0 i j s u k s y d w ó k t ¹ w e i n a w o t r o S e i c a d o p 3 , 0 1 2,3 0,1 0 1,0 1,0 i j s u k s y d w ó k t ¹ w e i n a w o t r o S y z r a t n e m o k e i b z c i l o p 0 , 0 1 3,1 0,0 0 1,0 1,0 e w o t s k e t e i n a w i k u z s y W 23,3 7,0 0,0 0 1,0 1,0 i j s u k s y d u k t ¹ w a j c p y r k s b u S 7,0 3,5 0,0 0 1,0 1,0 i j s u k s y d u k t ¹ w a j c a z i l a k o L e i p a m a n 0 , 9 3 15,2 2,5 2 2,9 2,1 i c œ e r t e i n e ¿ e i w œ d O i j s u k s y d u l e n a p w 3 , 2 2 24,3 4,1 5 4,3 2,4
dziêki której u¿ytkownik wczytuje wszyst-kie niezbêdne pliki (HTML, CSS, Java-script) tylko raz, a dalsza interakcja z ser-werem odbywa siê z u¿yciem technologii AJAX bez prze³adowywania strony. Angu-larJS wymusza na programistach zacho-wanie przejrzystoœci i podzia³u kodu Java-script, co ma pozytywny wp³yw na utrzy-manie i rozszerzanie aplikacji. Do wizuali-zacji danych na mapie skorzystano z bi-blioteki Leaflet, która pozwala w ³atwy i szybki sposób zrealizowaæ zaznaczanie, rysowanie i wyœwietlanie obszarów na mapie. Biblioteka doskonale wspó³pracuje z AngularJS oraz wieloma Ÿród³ami danych wykorzystywanymi w geoportalu: WMS, Tilecache, GeoJSON. Zakres jej funkcji odpowiada³ potrzebom autorów, a prostota u¿ycia przes¹dzi³a o jej wykorzystaniu.
Warstwa widoku w omawianym przypadku istnieje tylko w przegl¹darce u¿ytkownika, a dane z niej trafiaj¹ na serwer poprzez interfejs programistyczny (ang. Application Pro-gramming Interface, API) przy u¿yciu formatu JSON i GeoJSON. Czêœæ serwerowa zreali-zowana zosta³a w jêzyku Python z wykorzystaniem biblioteki Django, która podobnie jak AngularJS przyspiesza wytwarzanie aplikacji internetowych, jednoczeœnie zachowuj¹c przej-rzyst¹ strukturê kodu. Po³¹czenie Pythona z Django pozwala na interakcjê z przestrzennymi bazami danych, w omawianym przypadku PostgreSQL z dodatkiem PostGIS. Biblioteka pozwala na komunikacjê z baz¹ poprzez interfejs mapowania obiektowo-relacyjnego (ang. Object-Relational Mapping, ORM) który mapuje obiekty aplikacji na tabelê i wiersze w bazie danych. Dziêki temu programista nie musi tworzyæ kodu odpowiedzialnego za trans-akcje oraz komunikacjê z silnikiem bazy danych.
Opis funkcji portalu Geodyskusji
W efekcie prac zosta³y zaimplementowane w geoportalu funkcje, które podczas testów u¿ytecznoœciowych w najefektywniejszy sposób pozwoli³y u¿ytkownikom osi¹gn¹æ wyzna-czone cele. Portal geodyskusji sk³ada siê z dwóch g³ównych czêœci (rys. 3): modu³u mapy i modu³u dyskusji.
Funkcje geoportalu pozwalaj¹ce na udzia³ w dyskusji s¹ nastêpuj¹ce: 1) dodawanie wy-powiedzi dotycz¹cych fragmentów projektu planu przez nanoszenie na mapê obiektów geo-graficznych (linii, punktów lub obszarów); 2) dodawanie wypowiedzi dotycz¹cych ca³ego projektu planu; 3) komentowanie wypowiedzi; 4) subskrybowanie wypowiedzi; 5) ocenê wypowiedzi na „za” lub „przeciw”; 6) dodawanie za³¹czników do wypowiedzi; 7) lokalizo-wanie istniej¹cych wypowiedzi na mapie; 8) filtrolokalizo-wanie wypowiedzi po dacie i tekœcie oraz 9) sortowanie wypowiedzi po dacie i liczbie komentarzy.
Modu³ mapy umo¿liwia szczegó³owe zapoznanie siê z projektem rysunku planu i zapisami uchwa³y, dokonywanie pomiarów odleg³oœci i powierzchni, wyszukiwanie po adresie, prze-³¹czanie map podk³adowych, wyœwietlanie treœci uchwa³y przypisanych do poszczególnych obszarów planu oraz filtrowanie wypowiedzi dotycz¹cych zaznaczonego obszaru na mapie.
Rysunek 2. Schemat architektury zastosowanej w portalu Geodyskusji
605 OW ANIE ZORIENT OW ANE NA U¯YTKOWNIKA ORAZ MET ODY ZWINNEGO PROGRAMOW ANIA ...
Rysunek 3. Portal Geodyskusji – z lewej strony widok na przyk³adowy rysunek planu zagospodarowania przestrzennego z naniesionymi przez u¿ytkowników obiektami punktowymi, liniowymi i powierzchniowymi; z prawej strony widoczny jest modu³ dyskusji
Podsumowanie
W artykule przedstawiono doœwiadczenia zwi¹zane z projektowaniem, testowaniem u¿y-tecznoœci oraz implementacj¹ poszczególnych funkcji, w wyniku których autorzy zbudowali portal Geodyskusji. Z tych doœwiadczeñ wynika, ¿e nawet pocz¹tkowo trudne w u¿yciu dla przeciêtego u¿ytkownika Internetu funkcje do obs³ugi map, po odpowiednim przetestowaniu i niezbêdnych modyfikacjach, mog¹ okazaæ siê ³atwe w u¿yciu dla szerokiego grona odbiorców. Projektowanie aplikacji PPGIS to du¿e wyzwanie, a sukces jest uzale¿niony od subiek-tywnej oceny wielu osób. Z tego wzglêdu, w opinii autorów, projektowanie zorientowane na u¿ytkownika jest niezbêdnym elementem procesu projektowania i wytwarzania oprogramo-wania. Zastosowanie iteracyjnego podejœcia pozwala szybko reagowaæ na zmiany i zapotrze-bowania u¿ytkowników, a tym samym zredukowaæ ryzyko dostarczenia rozwi¹zania, które nie bêdzie spe³niaæ podstawowych celów, dla których zosta³o stworzone.
Du¿ym wyzwaniem pozostaje decyzja o uwzglêdnianiu lub odrzucaniu niektórych wy-magañ i opinii potencjalnych u¿ytkowników. Zdaniem autorów, projektuj¹c aplikacjê PPGIS konieczna jest konfrontacja wymagañ u¿ytkowników nieposiadaj¹cych wiedzy z zakresu GIS z wiedz¹ eksperck¹. U¿ytkownicy, którzy nie mieli wczeœnie do czynienia z GIS, na etapie projektowania funkcjonalnoœci czêsto potrzebowali wyjaœnieñ dotycz¹cych dzia³ania internetowych map lub zg³aszali propozycje, które by³y niemo¿liwe do zrealizowania. Zasto-sowanie internetowych aplikacji PPGIS w procedurach zwi¹zanych z planowaniem prze-strzennym jest innowacyjnym podejœciem. Dlatego potencjalnym u¿ytkownikom takich apli-kacji jest stosunkowo trudno sformu³owaæ potrzeby co do oferowanych w nich funkcji, a dla osób nieznaj¹cych GIS jest to wrêcz zadanie abstrakcyjne.
Literatura
Agile Manifesto, 2001: Principles behind the Agile Manifesto. http://agilemanifesto.org/
Andrienko N., Andrienko G., Voss H., Bernardo F., Hipolito J., Kretchmer U., 2002: Testing the usability of interactive maps in Common GIS. Cartography and Geographic Information Science 29(4): 325-342. Andrzejewska M., Baranowski M., Fiedziukiewicz K., Kowalska A., Matuszkiewicz J.M., Rusztecka M.,
Roo-Zieliñska E., Solon J., 2007: O partycypacji spo³ecznej w planowaniu przestrzennym. Zastosowa-nia geowizualizacji w celu wzmocnieZastosowa-nia udzia³u spo³ecznego w planowaniu przestrzennym. Ostatni dostêp: 14.03.2012 r. http://pspe.gridw.pl/movies/O%20partycypacji_spolecznej.pdf
Czepkiewicz M., Snabb K., 2013: ,Lean,Public Participation GIS: Towards a sustainable tool for participato-ry urban planning. Proceedings of GIS Ostrava 2013: Geoinformatics for City Transformations, 21-23 January 2013:33-48
Deemer P., Benefield G., Larman C., Vodde B., 2009: The Scrum Primer. A Lightweight Guide to the Theory and Practice of Scrum, Version 2.0. http://scrumprimer.org/
Elwood S., 2002: GIS Use in Community Planning: A Multidimensional Analysis of Empowerment. Environ-mental and Planning A, 34(5): 905-922.
Ganapati S., 2010: Using Geographic Information Systems to Increase Citizen Engagement. IBM Center for the Business of Government.
Haklay M., Tobón, C., 2003: Usability evaluation and PPGIS: towards a usercentered design approach. International Journal of Geographical Information Science 17(6): 577-592.
Haklay M., Zafiri A., 2008: Usability Engineering for GIS: Learning from a Screenshot. The Cartographic Journal 45(2): 87-97.
Haklay M., (ed.) 2010: Interacting with Geospatial Technologies. John Wiley & Sons. ISBN 978-0-4709-9824-3.
Jankowski P., 2011: Designing Participatory Geographic Information Systems. [In:] Nyerges T.L., Couclelis H., McMaster R. (eds.), The SAGE Handbook of GIS and Society. London, SAGE Publications: 347-360. Kingston R., 2011: On-line Public Participation GIS for Spatial Planning. [In:] Nyerges T., Couclelis H., McMaster, R. (eds.), The SAGE Handbook of GIS and Society. London, SAGE Publications: 361-380. Leff J., Rayfield T., 2001: Web-application development using the model/view/controller design pattern.
Proceedings of the Fifth IEEE International Enterprise Distributed Object Computing Conference. Meng Y., Malczewski J., 2010: Web-PPGIS Usability and Public Engagement: A Case Study in Canmore,
Alberta, Canada. URISA Journal 22(1): 55-64.
Nielsen J., 2012: How Many Test Users in a Usability Study. http://www.nngroup.com/articles/how-many-test-users
Nielsen J., 1993: Usability Engineering. Amsterdam: Morgan Kaufmann.
Nivala A-M., Brewster S., Sarjakoski L.T., 2008: Usability Evaluation of Web Mapping Sites. The Cartogra-phic Journal 45(2): 129-138.
Nyerges T.L., Aguirre R., 2011: Public participation in analytic-deliberative decision making: Evaluating a large-group online field experiment. Annals of the Association of American Geographers 101(3): 561-586.
Nyerges T., Ramsey K.S, Wilson M.W., 2006: Design considerations for an Internet portal to support public participation in transportation improvement decision making. [In:] Balram S., Dragicevic S. (eds.) Collabo-rative Geographic Information Systems. Idea Group, Hershey: 208-236.
Sidlar C.L., Rinner C., 2007: Analyzing the usability of an argumentation map as a participatory spatial decision support tool. URISA Journal 19(1): 47-55.
Uran O., Janssen R., 2003: Why are spatial decision support systems not used? Some experiences from the Netherlands. Computers, Environment and Urban Systems 27 (5): 511-526.
Ustawa z dnia 27 marca 2003 r. o planowaniu i zagospodarowaniu przestrzennym. Dz.U. 2003 nr 80 poz. 717.
Zhao J., Coleman D.J., 2007: An Empirical Assessment of a Web-based PPGIS Prototype. [In:] Submitted to the 2007 Annual Conference of the Urban and Regional Information Systems Association.
Streszczenie
Dynamiczny rozwój technologii i aplikacji internetowych, takich jak: Google Maps, Big Maps, Open Street Maps oraz ³atwy dostêp do szerokopasmowego Internetu spowodowa³y, i¿ znaczna czêœæ spo-³eczeñstwa zaczê³a wykorzystywaæ aplikacje mapowe w codziennym ¿yciu. Równoczeœnie, coraz wiê-cej us³ug œwiadczonych przez podmioty komercyjne oraz jednostki administracji publicznej wykorzy-stuj¹ rozwi¹zania oparte o interaktywne mapy udostêpnione przez portale internetowe (geoportale). Oznacza to, ¿e funkcje niegdyœ dostêpne tylko dla specjalistów z dziedziny Systemów Informacji Geograficznej (ang. geographic information system, GIS) zosta³y udostêpnione praktycznie ka¿demu u¿ytkownikowi komputerów i urz¹dzeñ mobilnych. Koncentruj¹c siê na ró¿norodnoœci posiadanych umiejêtnoœci u¿ytkowników Internetu autorzy zaprojektowali geoportal wspieraj¹cy partycypacjê (ang. public participation geographic information system, PPGIS) w procesie planowania przestrzennego w oparciu o filozofiê projektowania zorientowanego na u¿ytkownika (ang. user centred design, UCD). W trakcie wytwarzania oprogramowania autorzy zastosowali metodyki zwinnego programowania (Agile Manifesto), które dziêki iteracyjnemu podejœciu w szybki sposób pozwoli³y na wprowadzenia zmian wynikaj¹cych z potrzeb u¿ytkowników. W wyniku 4 iteracji z wykorzystaniem metod badania interakcji pomiêdzy cz³owiekiem a komputerem (ang. human computer iteraction, HCI) powsta³ geoportal z funkcjami pozwalaj¹cymi spe³niæ zapotrzebowanie potencjalnych u¿ytkowników w kon-tekœcie prowadzenia dyskusji z wykorzystaniem interaktywnych map. Badania, w ramach których powsta³ geoportal, zosta³y sfinansowane ze œrodków Narodowego Centrum Nauki, numer grantu 2012/05/B/HS4/03850.
Abstract
A dynamic development of technologies and applications such as Google Maps, Big Maps, Open Street Maps as well as an easy access to broadband Internet have led to the proliferation of map applications and their wide-spread use. Concurrently, a growing number of services provided by commercial entities and public administration use solutions based on interactive maps available through geopor-tals. This means that capabilities once available only to Geographic Information Systems (GIS) specialists have become available to virtually every computer or mobile device user. Taking into account the diversity of Internet user skills we designed a geoportal enabling public participation in the land use development planning process, based on the methodology of user-centred design (UCD). In the development of the software we followed Agile set of principles (Agile Manifesto) which, thanks to an interactive approach, made it possible to quickly adjust the software functionalities in accordance with the user’s emerging needs. As a result of four usability tests, which have been conducted in accordance with the human-computer interaction research methods, a new, user-friendly geoportal was developed. The system provides functionalities that meet the needs of potential users in the context of online discussions with the use of interactive maps. The geoportal research reported herein was supported by a research project funded by the National Science Centre 2012/05/B/HS4/03850.
mgr Marek M³odkowski marekmlodkowski@gmail.com mgr Dariusz Walczak walczak.darek@gmail.com prof. dr Piotr Jankowski pjankowski@mail.sdsu.edu
