4.7 Forslag til forbedringer

Følgende ting blev enten nedprioriteret under implementationen eller er ideer der er kommet for sent, og nåede derfor ikke at komme med i det endelige system.

• Tilmelding til aktiviteter - Denne funktion var planlagt, men det var ikke muligt at finde oplysninger i databasen om hvilke der ville være relevant at tilmelde en kunde, og det samlede antal af forskellige aktiviteter er meget stort.
• Smart søge-funktion - Denne er beskrevet i mockups'ene i analysen, men blev nedprioriteret, da den kun er en alternativ løsning til noget der virker. Der er dog stadig stort potentiale i denne funktion, da den afhjælper et af de store problemer på en WAP-telefon, nemlig den besværlige indtastning af fritekst. Ideen med funktionen er at alle kunder er sorteret efter deres navne, og man kan så snævre sig ind på den ønskede i en form for træ-struktur.
• Vise antal fundne ved fritekst-søgning - Når man kun skriver en del af navnet, er det rart et vide hvormange kunder/medarbejdere der opfylder søge-kriterierne, så man kan beslutte om man vil skrive en lidt længere søgestreng eller bare bladre de fundne igennem. Hvis der eksempelvis er søgt på "Peter" og der er fundet 100 der hedder Peter, vil man gerne skrive lidt mere af navnet. Antal fundne vises ikke, da vi ikke kunne finde noget sted det skulle så på det lille display, uden at være i vejen. Det burde dog være nemt at tilføje.
• Korrekt overførsel af æ, ø og å - På en WAP-emulator var der problemer med at overføre æ, ø og å i en søgestreng. Det blev forsøgt løst, men virkede ikke. Det er dog kun med den WAP-emulator der er problemer, så det er værd at undersøge hvor udbredt problemet er. WAP-emulatoren udskiftede de danske tegn med koder, som MAOV så kan konvertere tilbage, men det viste sig at de koder ikke blev overført ordentligt, så præcist hvor problemet er, er endnu lidt uvidst. Problemet er teoretisk løst, men det virkede ikke i praksis. Læs mere om vores forsøg i afsnit XXX "Design-test" side XXX.
• Overblik over kundeoplysninger - Når man vælger en kunde, kan man vælge licenser, aktiviteter, TAR'er og kontaktpersoner. Nogle af dem kan dog være tomme, og det er derfor lidt irriterende at have klikket sig ind på dem bare for at få at vide at de er tomme. Det ville være smartere hvis man i menuen kunne se hvilke punkter der er tomme. Det kunne være markeret med en lille stjerne, eller at man bare ikke kunne vælge de punkter der er tomme. Se mere om denne feature i "Hvordan ændres systemet" side XXX.
• Oprydning i Recent-tabellerne - Der vises kun de 10 senest søgte kunder/medarbejdere. Dem der er ældre gemmes dog stadig i databasen til ingen nytte. Der burde blive ryddet op i de tabeller med jævne mellemrum, for at spare plads.
• Understøttelse af flere sprog - Alle ord i systemet er på dansk, og de er skrevet direkte ind i koden. Systemet er dog kun tiltænkt til brug i danmark, men det ville alligevel være pænere, designmæssigt, at adskille teksten fra koden. Det kunne gøres ved at lave et sprog-objekt som indeholder en masse Strings med alle ordene i, som resten af koden så henter tekst fra når den skal bruges. Hvis sproget senere skulle ændres, ville det kun være det objekt der skulle ændres. Tænker man videre, kunne sprogobjektet hente alle sine ord fra en database under oprettelse. På den måde behøver man ikke recompile noget, for at ændre sproget, og man kunne have flere sprog i databasen samtidig, som kan vælges ved opstart, individuelt for hver enkelt bruger.
• Håndtering af SQLExceptions - Når der hentes data med JDBC, kan der blive kastet nogen Exceptions. Når en sådanne bliver fanget, bliver der ikke gjort noget ved det. Det resulterer i NullPointerExceptions, eftersom de værdier der skal sættes ud fra databasen ikke bliver sat. Den NullPointerException bliver fanget og skrevet ud til slut-brugeren. Det er ikke nogen pæn løsning. I stedet burde systemet fortælle brugeren på en pæn måde at der er sket en fejl, under tilgangen til databasen. Det kan gøres ved at skrive fejl-meddelelsen i de variabler der alligevel skrives ud til brugeren, eller kalde en generel metode der genererer en pæn og sigende fejl-meddelelse, der sendes til brugeren.
• Tilbage-menupunkter på samtlige sider - En WAP-telefon har en back-knap, så man kan altid komme tilbage til hvor man var. Man kan dog ikke garantere at en sådanne back-knap findes på alle enheder. Der burde derfor være menu-punkter der kan lede brugeren tilbage til forrige sider. Det vil også gøre brugen mere intuitivt forståelig, da brugeren så udelukkende skal vælge menu-punkter, og ikke til at bruge alle mulige andre knapper.
• Hvilke personer der er tilmeldt aktiviteter - Som det er kan man kun se at et firma er tilmeldt en aktivitet, og ikke hvilke personer det drejer sig om. Et link direkte til firmaets kontaktpersoner kunne give direkte adgang til telefonnumre på dem der er tilmeldt aktiviteter.
• Opsætning gemmes i DB-tabeller - Der vises 10 punkter på hver side der er for stor til en WAP-telefon. Hvis tallet 10 skal ændres skal systemet re-compiles. Det ville være smartere hvis sådanne opsætningsværdier var gemt i en tabel i databasen. På den måde kunne hver enkelt bruger også have sine individuelle instillinger.
• DB-links direkte til tabeller - Når der hentes data fra databasen sker det med DB-links. De links er dog til hele databaser, og ikke til tabeller. Hvis en tabel blev flyttet til en anden database, skal koden ændres. Det ville være smartere hvis der var oprettet synonymer i MAOV's egen database til de forskellige DB-links. Hvis tabellerne en dag blev flyttet, ville det være nok at ændre i de synonymer.
• Undgå kode-gentagelse - Der er flere steder i koden, hvor store mængder kode er gentaget med kun få ændringer. Det gør sig eksempelvis gældende i alle entitetsobjekterne der flytter data fra ResultSet til Vector og videre til array's. Det ville være smart at lave en generel hjælpemetode, der kan bruges alle stederne. Det gør sig også gældende for den kode der deler siderne op, så der kun vises 10 linier ad gangen. Det er besværligt at vedligeholde et system med meget kopieret kode.
• Søg kontakperson udfra navn, ikke firma - Man kan kun søge kontaktpersoner ud fra hvilket firma de er tilknyttet, i den overbevisning at man ikke er i tvivl om hvilket firma en person kommer fra, som man vil i kontakt med. Det kan dog i visse tilfælde være en fordel at søge mellem samtlige kontaktpersoner, uden først at skulle vælge firmaet.
• CC-email til sig selv, når action-points sendes - Dette var faktisk et ønske fra brugerne, men blev ikke implementeret. Der sendes kun en e-mail til modtageren af action-pointet, og ikke til afsenderen.

Ud over disse forslag til forbedringer, er der forslag til eksterne funktioner i bilag XXX side XXX.