Vaak is het verstandig om verouderde software gewoon opnieuw te maken. Maar wat doe je als de businesslogica nog niet aan vervanging toe is, terwijl de gebruikersinterface dringend behoefte heeft aan een make-over? En hoe transformeer je dan een systeem dat gemaakt is voor techneuten door techneuten naar een moderne, bruikbare en eigentijdse variant, zonder alles opnieuw te ontwikkelen? Nedap over de totstandkoming van Aeos 3.0.

Bij Nedap Security Management hebben we vanaf het jaar 2000 geïnvesteerd in de ontwikkeling van het Aeos-platform. Dit toegangscontrolesysteem bestaat uit hardware en software voor de beveiliging van gebouwen en terreinen. Een belangrijk onderdeel is de interface voor gebruikers.

Ondanks dat we bij de start van het project hadden gekozen voor een moderne webarchitectuur, was het resultaat een typische oplossing voor techneuten door techneuten. Door samen met ervaren grootgebruikers allerlei handige foefjes in te bouwen, waren bestaande klanten over het algemeen tevreden. Nieuwe gebruikers hadden echter vooral moeite met de navigatie door de grote hoeveelheid functies in het menu. De belangrijkste onvrede over de bruikbaarheid en uitstraling van het product kwam vreemd genoeg van onze eigen salesmensen.

We stonden voor de keuze om een aantal cosmetische verfraaiingen aan te brengen of de gebruikersinterface grondig te herontwerpen. We besloten zelf te investeren in het opbouwen van de, voor ons nieuwe, discipline van interaction design. Het resultaat mag er zijn, vinden we zelf: een zeer eenvoudige en bruikbare interface met een frisse, sexy uitstraling voor de bediening van een gedistribueerd en technisch complex product. Dit artikel bespreekt de transformatie van een ouderwetse HTML-interface, rechtstreeks afgeleid van de onderliggende databasestructuur, naar een moderne, taakgerichte rich internet application waarin de gebruiker vooropstaat.

Gelaagde informatie

Al snel na het begin van het make-overproject ontstond er een nieuwe dynamiek in onze ontwikkelgroep. We gingen scrummen, issues werden user stories en de persona’s als voorbeelden van typische gebruikers kwamen tot leven. De overdracht van de domeinkennis naar de interactiedesigners was een tijdrovende klus, maar achteraf gezien een belangrijke en noodzakelijke succesfactor. Zonder goed begrip van het domein, de gebruikers, de technologie en de markt hadden we nooit tot de huidige interface kunnen komen.

De belangrijkste projectdoelstelling: de gebruikersvriendelijkheid vergroten. Tijdens interviewsessies met bestaande gebruikers bleek een duidelijke behoefte aan reductie van het aantal verschillende schermen, betere navigatie, taakgerichte widgets en ondersteuning van multitasking per gebruiker. Op basis van dit onderzoek kwamen we tot een focusmodel van vier persona’s: receptioniste, bewaker, administrator en security officer.

De uitgangspunten voor de nieuwe gebruikersinterface waren betere ondersteuning bij het uitvoeren van de processen en taken, snel en overal toegang tot de meest frequente taken (quick launch), contextgerelateerde acties (task panel) en een persoonlijk dashboard. Belangrijk was verder het gelaagd aanbieden van informatie: noodzakelijke informatie moet direct zichtbaar en bewerkbaar zijn, gedetailleerde informatie is beschikbaar in ‘inspectors’ en complexe taken worden uitgevoerd in ‘editors’.

Het Aeos-systeem kenmerkt zich door meerdere gebruikers die het systeem tegelijk kunnen gebruiken, ondersteuning van meer dan twintig talen met spiegeling, een fijnmazig model voor gebruikerspermissies, het tonen van alarmen en streaming video van bewakingscamera’s. Dit heeft zich vertaald naar een oplossing op basis van een ‘stateful’ client met directe validatie van invoer waarin het mogelijk is zonder onderbreking te wisselen tussen gebruikerstaken. De beschikbare gebruikersacties zijn afhankelijk van gebruikerspermissies en de context. Systeemfuncties zijn vervangen door gebruikerstaken en het aantal bedienschermen voor de receptionist is teruggebracht van 248 in de oude HTML-interface naar slechts vier in de nieuwe interface.

Opensourceproject

Om tot een goede technologiekeuze te komen, hebben we ons in eerste instantie gericht op de belangrijkste uitgangspunten voor de nieuwe gebruikersinterface. Het kunnen multitasken en switchen tussen gebruikerstaken, navigatie en afhandeling van alarmen typeert de interface als een ‘stateful’ applicatie. Het systeem heeft eigenschappen van een echte desktoptoepassing met ondersteuning van meerdere platforms, skinning, internationalisatie en integratie van streaming video. Bezien vanuit de bestaande serverarchitectuur moest de technologie goede integratiefaciliteiten bieden met Java EE. Ook moest er een asynchroon model zijn voor notificaties en alarmen.

Twee jaar geleden stonden we voor de keuze: HTML5 of Flex van Adobe. HTML5 zagen we als mogelijke toekomstige standaard, maar stond nog erg in de kinderschoenen. De technologie was zeker niet volwassen genoeg voor een enterpriseapplicatie zoals Aeos. Daarnaast was er onvoldoende tooling beschikbaar om snel met ontwikkelen te kunnen starten. Flex was al een beproefde technologie met gedegen integratiemogelijkheden voor enterprisearchitecturen en ondersteuning van meerdere platforms. Bovendien biedt het goede handvatten voor het stroomlijnen van de samenwerking tussen interactiedesigners en software-engineers.

Adobe heeft onlangs besloten de Flex-SDK te opensourcen en de Flash-player op mobiele devices te vervangen door de Air-runtime. Deze recente ontwikkelingen hebben niet geleid tot een herziening van onze keuze. Air biedt de mogelijkheid om in de toekomst widgets uit de nieuwe gebruikersinterface te gebruiken als native applicaties op IOS en Android. Daarnaast zien we het onderbrengen van Flex als opensourceproject bij Apache als een positieve ontwikkeling.

Java-code leidend

De huidige Aeos-architectuur is het resultaat van tien jaar ontwikkeling. In de basis is het een typische Java EE-architectuur, waarbij de domein- en presentatielagen in de jaren zijn meegegroeid met nieuwe functionaliteiten. Op meerdere punten zijn domein- en presentatiegedrag vermengd geraakt. Vanwege de complexiteit en de hoeveelheid code van het huidige systeem zagen we behoorlijk op tegen een grootschalige ombouw. Binnen onze organisatie konden we drastische wijzigingen in de serverarchitectuur niet verantwoorden. De keuze voor een goed integratieframework was dan ook van groot belang. We zochten daarom naar een lichtgewicht integratie tussen client en serverarchitectuur, zonder de noodzaak om de bestaande Java-code grotendeels te herschrijven en aan de serverkant te veel afhankelijkheid met Flex te creëren.

Uiteindelijk hebben we gekozen we voor het GraniteDS-framework (www.graniteds.org), een tegenhanger van Adobe Livecycle DS (LCDS). Doorslaggevend in de voorkeur voor GraniteDS boven LCDS was dat het Adobe-product uitgaat van een beperktere client-serverarchitectuur. Het koppelt een zware Flex-clientapplicatie aan een server die bijna is gereduceerd tot de database. Daarnaast bieden LCDS en de opensource variant BlazeDS ons niet voldoende mogelijkheden op het gebied van datamanagement, zoals het kunnen opvragen van delen van grote datasets en het op aanvraag (lazy) kunnen laden van entiteitrelaties. Dergelijke mechanismes zijn zeer bepalend voor het realiseren van een goede applicatieperformance.

Bij GraniteDS staat de huidige Java-code centraal. Het gaat uit van een bestaande Java EE-architectuur en kan integreren met frameworks als EJB, Seam en Spring. Door goed gebruik te maken van de mogelijkheden die GraniteDS biedt en ‘de server’ te isoleren in een integratielaag, hebben we de koppeling met zeer beperkte wijzigingen in de server kunnen realiseren. Belangrijk om te noemen is dat we bij de integratie van Java en Flex handmatige ontwikkeltaken veelal hebben kunnen automatiseren. Hiervoor hebben we de Actionscript-codegeneratiefuncties van het framework ingezet, met het bestaande entiteitenmodel in Java als uitgangspunt. Constraints in het model, aangegeven met standaard annotaties, worden zo gebruikt dat invoervalidatieregels in de Flex-code zijn te genereren. Op deze wijze blijft de bestaande Java-code leidend en wijzigt de Flex-code indien nodig mee.

Zeer positief

Vanzelfsprekend is niet alles meteen volgens plan verlopen. De introductie van nieuwe technologie gaat altijd gepaard met onverwachte situaties die zich moeilijk laten plannen. We zijn geconfronteerd met de nodige bugs in het framework waar we oplossingen of work-arounds voor hebben moeten bedenken. De werking en optimalisatie van complexere mechanismes als paging van data en het pushen van dataverandering naar de clients hebben ons de nodige hoofdbrekens bezorgd. Ook was het niet altijd eenvoudig om met performanceproblemen in de bestaande architectuur om te gaan. Desalniettemin zijn we erg enthousiast over de mogelijkheden van Flex. We zijn met name te spreken over de objectgeoriënteerde Actionscript-taal en de ondersteuning voor meerdere IDE’s met goede debugfaciliteiten, waaronder Eclipse.

Dit voorjaar hebben we de eerste officiële release van de nieuwe gebruikersinterface opgeleverd. De reacties zijn zeer positief. Bedrijven staan te trappelen om ermee van start te gaan, bestaande klanten maken plannen om te migreren en sales heeft de oplossing gekregen waar het om vroeg. Daarnaast hebben we met de nieuwe uitstraling een aantal van onze grootste concurrenten de loef afgestoken.

Albert Dercksen, Tim Garthoff, Wouter Kersteman en Eric van der Maarel werken bij Nedap Security Management. Richard van der Laan is daar gedetacheerd vanuit Luminis. De ‘making of’ Aeos is te zien op www.vimeo.com/34364577