INFOPACT PARTNER PORTAL

Delft University of Technology

Computer Science

Faculty of Electrical Engineering, Mathematics and Computer Science

INFOPACT PARTNER PORTAL

F I N A L R E P O R T I N 3 4 0 5

B A C H E L O R P R O J E C T

Jeroen van Delft – 1014927

July, 2013

Bachelor Project – Infopact Portal

Page 1

SUMMARY

Infopact [1] is a reseller of DSL lines, expanding rapidly. To accommodate their

customers, Infopact wished to replace their own existing order platform with a new

online portal. This portal should allow the creation of new orders, give an overview of

existing orders and provide up to date information on any related events. Quince, a

marketing communication agency based in Amsterdam, took on this assignment and

designed and developed a fully functional portal.

This portal would replicate all existing functionality of the old portal, and expand upon

this with new functionality, designed to promote interaction through the portal instead

of the old channels of e-mail and phone, thus reducing the need for, and pressure on,

customer service at Infopact.

Our development team at Quince designed the interface and implemented the portal

using PHP [2], leveraging the FuelPHP [3] framework. Communication with the backend

at Infopact was achieved using a RESTful API.

Testing was done by minor unit testing, an in-house QA team and external QA

advisors, with additional acceptance testing by a pilot team of Infopact's resellers. Both

phase one (replicating the functionality of the original portal) and phase two

(expanding the portal with new functionality) were completed and delivered on

schedule, and the new portal was presented to Infopact's customers. The response was

positive and Infopact continues to use the new portal with satisfaction by both staff

and partners.


Page 2

PREFACE

This report is the final report on the development of phase one and two of the Infopact

Partner Portal. Although not originally intended as such, I have used this project as the

basis for my contribution to the IN3405 Bachelor Project. This project ran during the

final quarter of 2012, with a final release in early January 2013.

This report will provide information on the problems we faced, the design we created

and the eventual implementation of this design. Also included is information on the

feedback we gathered and the methodology used to accomplish this.

I would like to thank the following persons in particular:

Remco Schoos, for initial leadership of the project and valuable mentoring

during the later stages.

Wilco Dona and Nick van Manen, for coordinating the project at Infopact and

providing a calm and stable point of contact.

Rene van Bakel, for joint leadership of the project and filling in where my skills

were lacking.

Gerd Gross, for coordinating the Bachelor Project course and assistance in my

exceptional case.

Jeroen van Delft

Rijnsburg, The Netherlands, July 2013


Page 3

Contents

PREFACE .................................................................................................... 2

1 INTRODUCTION .................................................................................... 5

1.1 About Infopact.................................................................................... 5

1.2 Outline ............................................................................................... 5

2 PROBLEM ANALYSIS .............................................................................. 7

2.1 Old situation....................................................................................... 7

2.2 Requirements ..................................................................................... 8

3 METHODOLOGY ................................................................................... 9

3.1 Planning ............................................................................................. 9

3.2 Sprints ................................................................................................ 9

4 PROJECT TEAM ................................................................................... 11

5 WORKING ENVIRONMENT .................................................................... 14

5.1 Tools ................................................................................................ 14

5.2 Servers ............................................................................................. 14

6 DESIGN .............................................................................................. 16

6.1 Functional design ............................................................................. 16

6.2 Technical design ............................................................................... 16

6.2.1 Framework ................................................................................... 17

6.2.2 API ................................................................................................ 19

6.2.3 Frontend ....................................................................................... 20

6.2.4 Database design ........................................................................... 21

6.2.5 Graphic design ............................................................................. 22

7 QUALITY ASSURANCE ......................................................................... 24

7.1 Automated testing ............................................................................ 24

7.2 Field testing ..................................................................................... 24

7.3 Verification and review ..................................................................... 25

8 REPORTING ........................................................................................ 26

8.1 To Infopact ....................................................................................... 26

8.2 To management ............................................................................... 27


Page 4

8.3 Issue tracking ................................................................................... 27

9 CONCLUSION ..................................................................................... 28

10 BIBLIOGRAPHY .................................................................................... 29

11 APPENDICES ....................................................................................... 30

11.1 Database design ............................................................................. 30

11.2 Project document ........................................................................... 31

11.3 Graphic design ............................................................................... 38

11.4 Interface specification .................................................................... 39

11.5 User journey .................................................................................. 53


Page 5

1 INTRODUCTION

1.1 About Infopact

Infopact is a company specialising in reselling customised Digital Subscriber Line (DSL)

packages, either directly to consumers or through a large network of resellers - their

so-called partners. They purchase DSLs from two suppliers: KPN and BBNed, and

combine these into packages containing additional components such as an

appropriate DSL modem and an optional SLA (Service Level Agreement; this contains

guarantees such as a minimal uptime). Originally Infopact focused purely on selling

standalone DSL packages without any additional services, but in recent years the

“Alles-in-een” (All-in-one) market has seen a steady rise in popularity, prompting

Infopact to offer a fully customisable range of package combinations.

Various channels were used by Infopact to sell these packages, amongst which an

online portal developed several years ago. This portal is used by their partners to

create and configure orders, and to enter them into Infopact's backend. Employees at

Infopact then use this backend to further process the order. This portal was developed

in-house, and was lacking in maintenance. Product descriptions and combinations

were out of date, and a hassle to update. Partners were very limited in their choices

when creating an order through the portal, and received virtually no status updates

after an order was placed.

Infopact wished for a new sales platform, especially since the Internet was used more

and more by salesmen to place an order or update it. And seeing as how they

themselves were on the forefront of Internet connectivity, spreading connections

across the Netherlands, they believed they should have a top-of-the-line portal and

integrate as many features their partners would think of use.

1.2 Outline

In chapter 2, a detailed analysis of the problem as it was presented to Quince will be

given. This includes a description of the system Infopact was using at the time, and

the limitations they were running into. The requirements we distilled from this

problem will be briefly summarized in paragraph 2.2, while the methodology which we

used to execute this project is outlined in chapter 3. Chapter 0 introduces the team

working for the project at Quince and their respective responsibilities, while chapter 5


Page 6

focuses on the working environment used during the project. After that, chapter 6

continues with a description of both the functional and technical designs created

during the project and important decisions made regarding elements such as the

framework and database structure used. We continue with a short summary of the

quality assurance used during the project in chapter 7, and chapter 8 contains a

description of the reporting methods used. Finally this report is concluded in chapter

9. Appendices at the end of the report contain the original database design, the

graphic design theme used, the project document and the user journey.


Page 7

2 PROBLEM ANALYSIS

2.1 Old situation

Infopact was using an older site, developed in-house by their developers. There had

been some transition in these developers, so that the original team was no longer

available for any modifications. Any available packages and possible combinations

were hardcoded into the site, with separate pages for each viable combination.

Maintenance was an issue, and changing the company style or any such global

sweeping changes would require a large amount of work. Moreover, with the amount

of packages and their combinations increasing more rapidly due to increased

competition on the DSL market, Infopact could no longer afford to make continued

changes in these hardcoded pages.

Furthermore, the old portal offered little to no insight into the status of orders. Other

than sending an order to the relevant Infopact personnel and changes made to the site

by developers, there was hardly any interaction between the portal and the rest of

Infopact. Order status would not be displayed on the site, and the order overview was

minimal. Partners depended on contact by phone and email to maintain a current view

on orders and their statuses. For things such as network status partners were

dependant on external sites, such as those of the actual DSL suppliers (KPN and

BBNed).

When an order was created in the old system, the system generated a mail which was

sent to the sales staff at Infopact. The salesperson responsible for this partner then

processed the order into the backend system, and initiated all requests related to this

order. This includes requesting the actual line with the appropriate supplier, ordering

the required modem (if any) and requesting a mechanic for installation of the physical

endpoint of the line. The salesperson used e-mail to update the partner on any status

changes of the order, and phone contact for any questions that might arise. Should the

partner require information on the status of his order, or change (or cancel) any part

of the order, he needed to resort to e-mail and phone contact as well.


Page 8

2.2 Requirements

First of all, the new portal would need to have all the functionality of the old one, so

that meant that the package selection and order process would need to be

implemented: A partner should be able to select the packages he requires for an order,

enter the address information for the order, and have it sent to Infopact. Any other

new functionality was split into modules, and planned accordingly.

The portal should have a proper order overview, allowing a partner access to

any orders that have already been placed, and allowing him to view any status

information relevant to an order. He should also be able to change or cancel an

order, for instance by adding or removing packages, or changing the installation

address.

The portal should have a dedicated section for news messages, to allow Infopact

to advertise new products, inform partners of any upcoming maintenance or

changes and provide general news.

Partners should have a way of contacting Infopact personnel (their own sales

representative, and support staff) via the site. This lessens the need for external

e-mail and phone contacts, and provides a convenient way of tracking

conversations and requests.

We used the MoSCoW model to arrange all requirements, both functional and non-

functional, and discussed this prioritisation with Infopact. During development, some

modules had their priority shifted, mostly due to feedback by either the pilot partners

simultaneously testing the portal, or stakeholders at Infopact reassessing their own

priorities and the expected usage of that particular module.


Page 9

3 METHODOLOGY

3.1 Planning

The partner portal project was divided into two main phases. Phase one entailed the

replication of the functionality of the current portal, in the new style. This included an

authentication and registration system (with registered users unable to login pending

approval by the administrators), a configuration page for orders and the ability to add

orders to the system. We added to this a simple dashboard page and order overview

functionality. Development time for phase one was estimated at 8 weeks, containing

four two-week sprints. The release for this phase would coincide with the start of

dedicated testing by the pilot partners. Two employees (Rene and myself) would be

working on this project fulltime, assisted by support staff varying between sprints; a

graphic designer during the first sprint and dedicated usability testers during the last

two sprints, for instance. The only exception was Theodoros, who came on as a

fulltime developer for the project halfway through the first phase, to make up for

Rene’s absence.

Phase two expanded upon the first phase by adding additional, new functionality.

Some of this functionality performed tasks that were up until then either run by

external systems or performed manually by either the partners or Infopact personnel,

while other functionality was brand new and either desired by Infopact or requested by

their partners. Once again, staff working on the project varied from sprint to sprint,

with Theodoros, Rene (once returned from paternity leave) and myself as the steady

factors.

3.2 Sprints

An interesting aspect of the project was the differing sprint lengths between Quince

and Infopact. While Infopact used monthly sprints with a focus on reporting to

management, Quince uses biweekly sprints. This meant that every two weeks Quince

would have a deliverable in place for Infopact to test, but proper feedback from

management possibly wouldn't reach Quince until two more weeks had passed. And

even more problematic: high-priority requests from Quince to the development team

at Infopact might be detailed for an additional two weeks due to their developers'


Page 10

limited resources being filled completely for their current sprint. Luckily enough the

lead developer at Infopact at the time was very cooperative, having already suggested

switching to bi-weekly sprints to his own management. As a compromise, the

development team at Infopact switched their sprints to a bi-weekly schedule, while

Quince agreed to try to reserve major functionality changes and milestones for the

sprints that coincided with the timetable used by the management at Infopact.


Page 11

4 PROJECT TEAM

The development team at Quince was led by both Rene van Bakel and me. Both Rene

and I have extensive experience in working on both backend solutions written in PHP

and frontend implementations of HTML/CSS designs augmented by JavaScript.

Whereas Rene's expertise tends more towards converting a design into HTML/CSS, I

personally prefer the frontend programmability of JavaScript. This was reflected by our

respective focus during the project: While Rene used his knowledge of the Bootstrap

[4] framework to convert the graphic design and mockup into proper HTML/CSS, I

focussed on the extensive JavaScript functionality of the order process; especially the

order creation and configuration module, the heart of the application. Both Rene and I

shared project leadership as well, one of the focal points at Quince is personal

responsibility: Instead of having dedicated project leaders with little to no 'hard skills'

relating to the project, projects at Quince are led by the actual developers, designers

and other people 'in the field', so to speak. This promotes a better awareness of

projects and increases the ease and expertise with which a project leader can discuss

implementation details with a customer, for example.

This meant that Rene and I took on different mantles as the project progressed. When

the initial design was completed, Rene took on both conversion of the design into

HTML/CSS using Bootstrap, and stayed in contact with Infopact to provide regular

updates on the status of the project. Whereas I focussed on implementing both the

backend in PHP (using FuelPHP) and the order creation frontend code in JavaScript,

while acting as an internal coordinator. In essence, this meant that Rene concentrated

on most external parts of the project and I coordinated internally.

As I was involved with the entire main part of the project, my responsibilities varied as

the project progressed. I have tried to highlight my main areas of involvement during

the run time of the project (spanning the entire Q4 of 2012 and January of 2013):

Communication with the client on both the initial design and redesigns

according to feedback from both Infopact and partners.

Creating a budget and project plan for both phases in consultation with

developers, designers and planners at Quince, and management and developers

at Infopact.


Page 12

Setting up use cases and the user journey used by both parties during the

project, and refining this along the way.

The order module, consisting of both the frontend code for filtering and

displaying order package combinations and the backend communication with

the Infopact API for retrieving package combinations and storing the orders.

The users module, responsible for access checks throughout the application and

modifying the set of users for a partner.

Further API communication for services such as interruptions, invoices and

support tickets.

Minor pages and functionality such as downloads, contacts, FAQs and support

tickets.

Setting up testing and verification, and communicating with pilot partners

during their testing.

Other roles in the project team at Quince were filled by:

Marijn Bouma, another HTML/CSS expert at Quince. Marijn was responsible for

converting part of the design into HTML/CSS, and took on a large part of this

role when Rene went on paternity leave halfway during phase one. When the

basic structure and styling of most pages was completed, he was relegated to a

support role.

Theodoros Papadopoulos, a PHP developer. Theodoros was initially supposed to

provide minor support in backend development, and pick up any small issues.

His role grew expansively however during Rene's absence, and he eventually

became lead developer during the latter phases of the project, during which

time I was no longer involved in it

Olaf Weijers, a dedicated QA tester at Quince who performed most of the

usability and regression testing on Quince's side during and after development.

Guido Porten, graphic designer. Guido created the initial graphic design for the

Infopact portal, and thus set out the style to be used throughout the site. Guido

based his design

As mentioned before, unfortunately (but fortunately for him though) Rene went on

paternity halfway during the project. This was supposed to happen during the

transition from phase one to phase two, but unfortunately due to some complications


Page 13

this had to be advanced. This meant that my responsibilities as project leader

increased, and I would be responsible for all contact with Infopact as well (instead of

merely with the development team on their side). Remco Schoos assisted me in this,

and I was able to rely on Theodoros for additional backend coding.

During the initial stages of contact with the customer, the project was led by Remco

Schoos. Remco made contact with Infopact, and explained how we could be of service.

As Quince has a large amount of experience in business-to-business communication,

we considered ourselves an ideal party to create the new partner portal.


Page 14

5 WORKING ENVIRONMENT

5.1 Tools

Quince does not enforce a standard IDE or operating procedure on its employees, so

tools tend to vary from employee to employee. Sublime Text 2 was used as editor of

choice, since it has a rich plugin integration API allowing for extensions such as source

control and code completion.

Source code versioning was used of course, with Subversion [5] being the tool of

choice at Quince. Although Quince normally uses an svn server accessibly only by

developers, this project featured a server with extended access, to allow the

development team at Infopact to monitor the state of the code, and offer their own

changes should time permit. The repository also contained related data, such as the

database design and testing data, and any other versioned project documentation

such as the description of the API and the interface user journey.

5.2 Servers

A variety of servers were used during the project. Every developer ran a local version

of the portal on his working machine, including a copy of the testing database. To

simulate communication with the backend, Infopact had a testing server available

which contained an older copy of their actual backend data. No other backend process

at Infopact was attached to this testing data of course, to prevent accidental injection

of testing data into the live environment. We also used stubs to simulate backend

communication whenever proper data or API calls weren't yet available, or when the

required data was of such simple nature that creating a stub was more efficient for the

time being.

An actual testing server was also installed at Quince, accessible by Infopact and their

partners. This server was used as a demonstration server for any deliverables, and at

the bare minimum updated after every sprint at Quince. The pilot partners used this

server to run their own tests and to gauge the acceptance of the new portal.

Communication with the backend at Infopact was done using the same testing server

available at Infopact.


Page 15

For the final version of the portal at the end of every phase, Infopact provided two

servers located at their datacentre. One of these functioned as the application

platform, while the other was a database server. These servers are maintained by

Infopact, with Quince having responsibility over the code located on them. These

servers differ from those used during testing / demonstrations in that they link to the

live API instead of the testing copy, and they silently log and email errors instead of

displaying them to users (and thus potentially displaying exploitable information).


Page 16

6 DESIGN

6.1 Functional design

During initial discussions with Infopact, it became clear that the new portal should, at

a minimum, recreate all functionality of their current portal. This included a limited

configurability of DSL packages and an order process. Both of these modules were

surrounded by a login system.

The core of the partner portal is, in essence, an online store. The main goal of the site

is simply to allow partners to order package combinations from Infopact, and any

other information and services offered are secondary in nature. For this reason, the

site was designed around the concept of an order. Or more specifically, around the

creation of an order from start to finish. Two ways of creating an order are present in

the current system, to accommodate two types of users. Existing users already had

experience with the old portal, and with the old order system.

The functional design for the new system was mostly worked out through a series of

use cases, culminating in a full graphic user journey. This user journey illustrated the

various components of the site, with accompanying text on how they should be used.

This storytelling method was used to discuss and refine the intended functionality of

the portal in cooperation with the pilot partners selected by Infopact. This way, all

parties had a clear view of what the eventual portal would be capable of, and whether

or not this fulfilled the expectations of both Infopact and their partners. As an added

bonus, the user journey would serve as a guide for new users, and was the basis for

the site manual eventual created by Mr Buchter.

This design was of course refined during both phases, mostly because of feedback by

any of the testers.

6.2 Technical design

Several decisions made during the project were out of our hands due to imposed

restrictions by Infopact, but fortunately enough we were given largely free reign over

the technical details of the frontend. As this project was intended partly as a learning

experience for those involved, several new technologies and techniques were used.

Using PHP as an implementation language was a given, considering our experience


Page 17

and the rapid development nature of the language. After discussion and analysing the

in-house experience with several frameworks, decisions were made regarding the PHP

framework to be used, the API for interaction with Infopact’s backend and the

framework (so to speak) for the frontend. Concurrent with this, the database structure

was crystallized and the graphic design was further fleshed out, according to the initial

style impression created by Guido and the user journey.

6.2.1 Framework

Early on during the technical design, the decision to use an MVC framework was made

by the development team. As there are a large number of frameworks available for PHP

projects, selecting one wasn't an easy process. In the end the team opted for FuelPHP,

a framework developed since August 2011. The main advantages of FuelPHP for

Quince are:

FuelPHP uses an expanded MVC model, adding an additional ViewModel layer.

ViewModels are a layer between Controllers and Views, acting as a store for

logic (which has no place in a View) that is View-specific (so has no place in a

Controller). This provides a clearer distinction between the actual graphic user

interface and the business logic used by the portal. This further simplifies the

process of converting the UI sketches into an actual proper interface, allowing

any business logic to be added later in the process. This also allows designers

with little to no development experience to collaborate on the site, without

being burdened by development decisions and implementations. While at

Quince all front end work, other than providing the graphic design and imagery,

is done by developers (so knowledge about developing the front end is a given)

the ViewModel layer still facilitates more comfortable work, allowing the

developer to focus on a single aspect of the site.

In-house experience with FuelPHP was readily available; FuelPHP has been used

extensively in several projects by Quince, and developers for those projects

were standing by for support during development. This support was mostly

used during the initial stages of phase one, where misconceptions on the basic

structure of the framework happened on occasion.


Page 18

FuelPHP is in active development. This meant that any support requests to the

team would have a chance of actually being heard, which can be something of a

hit-and-miss with open source frameworks. Furthermore, development was

actually active, with releases every couple of months. The community

surrounding FuelPHP was active as well, which combined with our internal

support meant that any requests for help were promptly answered. This help

was well-appreciated, since all three developers from Quince working on the

Infopact portal had quite limited experience in working with FuelPHP.

As said, the actual team working on the portal had limited experience with the

framework. While this is partially a disadvantage of course, one of the

cornerstones of Quince is self-realisation and the increasing of employee

responsibility. Thus, embracing new technologies and helping them spread

through the company, and spreading awareness and mastery of new techniques

amongst the employees is always promoted. Having a new framework and

mastering it with a new team was a welcome challenge.

Development was started, and the respective model classes for most of the domain

objects were created. Even the more straightforward controllers with basic CRUD

actions for the models were created. Then, however, Infopact made a decision which

severely altered our timetable and invalidated a lot of the work we had done so far.

While it was originally agreed that the portal would store all information that was

relevant for the portal (anything from partners, users and orders to news items) in its

own database, higher management at Infopact decided that they wanted to maintain a

tighter leash on their information, and only data that was unique to the portal should

be stored in its database. Any other information, including the cornerstone of the

application (the order) would be stored in Infopact's backend instead. Several solutions

to this complication were considered. First of all, a mirror of the Infopact backend

could be maintained and synchronised periodically. This would lessen the need for

constant interaction via an API, and would allow the portal to use its own database for

all relevant storage.

One of the larger disadvantages of 'losing' a large part of the data structure was that

integrity constraints in the database could no longer be satisfied in a sensible way.

Originally the database model encompassed most of the object diagram, and the


Page 19

FuelPHP framework and actual constraints between tables took care of data validity.

The backend at Infopact maintained very little constraints, but this was a moot point

regardless since any interaction went through the RESTful API instead of any direct

database manipulation.

To make up for this loss of automated integrity checking, the portal needed to

maintain its own checks, which added a lot of computational complexity when storing

and retrieving information. This decision was unfortunate with respect to development

time and complexity, but understandable in the larger picture, especially with Infopact

further modularizing their backend and allowing other external services access via the

standardised API.

6.2.2 API

One vital part of the new portal is the interaction with Infopact's backend system.

Although part of the data used by the portal is stored in its own local database, any

information that has an impact on Infopact's workflow is stored in their backend. To

handle communication with this database, a proper interface was needed. Infopact had

already been developing an API for their backend, for multiple reasons. Chief amongst

these was the desire to properly compartmentalize their backend into distinct systems

with clear responsibilities, instead of the somewhat chaotic setup they were running

now. They were also planning on opening up their backend for external parties, so

that for instance their support department could be run remotely and still have access

to any and all information about orders they might need.

Infopact decided on using a RESTful API. REST, or Representational State Transfer, is a

style of communication for a client and a server with several benefits. First and

foremost: the communication is stateless, which means the server does not need to

maintain a state for the client; everything needed from a client to service a request is

contained in that very request. To accommodate the four basic actions contained in a

request (Create, Retrieve, Update and Delete) REST implementations often reuse the

HTTP vocabulary and methods: POST, GET, PUT and DELETE respectively.

The interface used by the portal was created using the FRAPI framework, a framework

intended purely to allow rapid development of RESTful APIs. This framework was put


Page 20

into place by Infopact, who created CRUD actions for the most basic of elements.

These actions were then expanded upon in a joint effort by both Quince and Infopact,

to create a fully-fledged API for any requests the frontend might make. Most extensive

of these requests was the ‘create order’ request, which had a large responsibility.

Several tables would need to be filled with (properly validated) information, and several

backend processes needed to be set in motion when an order was created or updated.

Other important API calls were the login call for instance; as user logins for the portal

were used for tracking other information throughout the backend as well, these could

not be stored in the frontend either. So to facilitate logins, a secure call was sent

whenever someone attempted to log in to the portal, containing their credentials and

receiving a list of functions (if successful) the user had access to. This was then used

by the frontend, to create a proper interface.

The Infopact team was responsible for the API. Originally, this meant that all work on

the API was done by its members. As the project continued, however, the Infopact

team had less and less time to work on the API, which of course expanded greatly

when the decision was made to keep all essential data in their own backend. This

meant that the Quince team expanded their work on the API, while Infopact ran any

relevant regression tests. Thankfully, FRAPI uses PHP (and leverages the Zend

framework) so no additional expertise was needed on Quince's end to create and

modify API actions.

6.2.3 Frontend

6.2.3.1 JAVASCRIPT

Various modules within the frontend make extensive use of JavaScript to enable their

functionality. The largest of these modules is the order configuration tool. This

complex module contains the rules and logic to enable a user to create and configure

an order for a customer, with any and all options that are allowed. The starting point

for this process is either the order configuration page itself, or the zip code entry on

the dashboard (which then leads to the order configuration page). As the set of

packages available to a customer is limited by the available services at that particular

zip code, entering a zip code is the preferred way of starting the process. This zip

code is then transmitted to the Infopact backend via the API, and a set of available

packages is returned. These are then used to render the configuration interface, which


Page 21

is in essence a form with groups of radio buttons and checkboxes, to select for

instance the desired DSL speed and to enable various extra options such as an alarm

central or SLA. Another request is sent out via the API, to determine the possible

combinations allowed for the available packages. This list of combinations is what

dominates the configuration module of the frontend, enabling and disabling options to

prevent the user from selecting an invalid combination, and displaying a total price to

the user. The selected options also determine the amount of extra information the

user is requested to enter during the order process, such as requiring a phone number

when call forwarding is requested.

6.2.3.2 BOOTSTRAP

As a frontend framework, Bootstrap was used. In its essence, Bootstrap is not a proper

framework but more a set of modular tools assisting in implementing a consistent

frontend. Bootstrap promotes the use of a column-based responsive design with a

grid system and a stylable set of tools. Using Bootstrap greatly simplified the creation

of pages such as the dashboard, which has a complicated set of rows and grouped

controls, including items like a list of active orders.

As mentioned, Bootstrap promotes the creation of a responsive design. Although the

current portal is not entirely suitable for mobile or tablet use, Infopact did express

interest in eventual development for these types of devices. For instance, mechanics

en route to an installation point for a customer should have access to the portal on

their mobile to see the route, or the precise location of an installation point. And sales

representatives or support personnel should have easy access to the details of a

customer or one of their orders on their tablet. This was one of the reasons we opted

for Bootstrap. Preparations were put into place to make sure that an eventual proper

responsive site would not require a total rewrite of the frontend, regardless of whether

Quince or another party would develop this new functionality.

6.2.4 Database design

This subsection largely focuses on the database design as it was originally intended,

during the part of the project where the portal would be completely supported by its

own database, instead of relying on the Infopact API to store and retrieve data. The

design of the database used by the backend at Infopact was unfortunately out of our

hands since a large number of backend systems depended on it, and was thus largely


Page 22

out of scope for this project. However, due to the close resemblance and relation of

object diagram and database design, I believe it useful enough to explain the original

intended structure.

Early on in development, the decision was made to implement the database for the

FuelPHP framework using MySQL [6] 5.5. Experience with this server was in ample

supply at Quince, and the referential integrity constraints of the InnoDB storage engine

were well-suited to maintain the strict relations we intended to impose. The database

design closely mimics the object diagram, which was to be expected. The largest

difficulty was in mapping the various packages, their combinations and the

customisable options they offered onto a relational structure. This was eventually

solved by adding the 'options' table, with a categoryId to specify the type of option,

which could be anything ranging from the alarm central to used, to the throughput of

the connection required. This table was linked to the 'orders' table via 'orderOptions'.

The order itself contained a link to the actual packageCombination selected, while the

packageCombination table was linked to the actual packages contained in that specific

combination. This way, an order has a mandatory link to a packageCombination, since

that is the essence of an order. Any options, customisations or selections made during

the order process for whatever category are then linked to that order. Packages and

their combinations were never intended to be stored in the portal database; these were

retrieved through the API as these are changed rapidly and by various external

systems, it was infeasible to create a synchronisation system for these elements within

the scope of the portal project.

As expected, orders are the core of the database design as well. Most tables are linked

to the orders table in one way or another; be it a support ticket (imported from a

TopDesk API), the history of statuses an order has gone through or the kickbacks a

partner receives for establishing and maintaining the order. An order is made on

behalf of a customer, and a customer is 'owned' by a partner, thus creating a link

between the three largest tables in the database and covering the core of the

functionality of the site, 'partners creating orders for customers'.

6.2.5 Graphic design

To provide Infopact with extensive insight into the final portal, a comprehensive

mockup in Balsamiq was created. This mockup contained pages for every screen in the


Page 23

portal, including popups and tabbed interfaces. This mockup was used extensively as

a user journey; providing both Infopact management and testers with a clear view of

what the application should do, and look like in a broad sense. This user journey was

also discussed with the pilot testers at Infopact, to gauge their reactions.

An example of the visual style we intended the site to have was then created by Guido

Porten, combining elements from Infopact’s own distinct house style with a more fresh

appearance. Infopact and their partners found the old portal style dated and

inconsistent, so Quince went with a lighter, more streamlined portal while reusing

Infopact’s colour scheme.


Page 24

7 QUALITY ASSURANCE

As the portal is a critical application in the workflow at Infopact, proper testing and

validation were a large concern. To this end, and to allow accurate and detailed

reporting during meetings, we employed a strict testing regiment during the

development phases. While Quince focused primarily on unit tests, both Quince and

Infopact performed usability tests. Infopact took responsibility for any regression test

with regards to the API used, and coordinated acceptance tests with their partners.

7.1 Automated testing

Automated testing was done predominantly by unit tests, using PHPUnit. PHPUnit is

largely integrated into the FuelPHP framework, and creating dedicated classes to test

models, controllers and views was sufficiently simple and clear. Unfortunately, due to

the decreased reliance on FuelPHP we were unable to use the full range of testing

available, and Infopact were unable or unwilling to share their testing process on their

own backend. Infopact was also responsible for testing the API; the FRAPI tool used

has integrated testing facilities to simulate requests and their output, and these were

automated and verified by Infopact.

7.2 Field testing

During planning of the first phases of the project, it was decided that several 'pilot

partners' would be selected from Infopact's client pool, and these partners would

perform field testing of the portal. Three partners were selected, from distinct

categories; Infopact has several types of partner, with individual pricing schemes and

available products and options. These partners were involved during the development

of the portal as well, as their input was gathered on several occasions. When field

testing began, the partners were instructed by Infopact (with help from the manual

created by Mr Buchter, amongst others) and they started using the portal in the same

manner as they had been using the old one. Feedback from field was highly valued

during the project, and the pilot partners were excited to be part of this testing.


Page 25

7.3 Verification and review

Formal acceptance testing and verification of the new portal was done by external

parties, being Paul Buchter of Systhema B.V. and Rachid Ben-Laouane of EsperantoXL.

These parties were engaged by Infopact, and provided predominantly acceptance

testing. Testing was done according to the set of requirements and use cases set up at

the start of the project, and any newly discovered issues were weighed according to

the established MoSCoW ranking. The testers were instructed by Infopact, and

reported directly to Quince using the JIRA [7] issue system. Depending on the criticality

of these issues, a fix might be delayed until a later phase. Mr Buchter had an

additional task during his testing: He created a small, formal manual to be used by

partners during the early stages of portal adoptation; while the pilot partners had been

instructed by Infopact, the layout of the portal was deemed easily understandable

enough by both testers and pilot partners to deem personal guidance unnecessary.


Page 26

8 REPORTING

8.1 To Infopact

Infopact was kept up to date through formal appointments: every week there would be

either a Skype call or a face-to-face meeting, alternating at Amsterdam (Quince) and

Rotterdam (Infopact). During these meetings, all relevant stakeholders at Infopact and

the project leaders at Quince were present. The current project manager at Infopact

(either Wilco or Nick) led these meetings, and a strict agenda was used. Any relevant

outstanding issues were discussed, and any fixed issues were confirmed verified by

their respective stakeholder. After that, the planning for the coming week or iteration

was discussed, and deadlines were set for any items that were due. For any of those

items, the responsibly party was noted, for due diligence during the next meeting.

These meetings were quite pleasant for the most part, largely due to the firm control

both Wilco and Nick took of the other Infopact people present. Meetings were smooth

and structured, and any new issues were immediately recorded and assigned.

While our initial contact at Infopact was Wilco Dona, it became clear early on in the

project that Wilco would be leaving Infopact at the end of phase one. Wilco was purely

an interim manager, who led Infopact through a series of large changes, from a

relatively obscure DSL reseller to a prominent factor in the current market. Starting

from phase two, we would be dealing with Nick Schagen. This was an interesting

switch as both have a very different managing style, and Nick was quite new in his role

at Infopact. During this transition, contact with the development team at Infopact

intensified. This had both advantages and disadvantages: while communication lines

were shorter and requests could be fulfilled in less time (by both parties), there was no

longer a clear record of communication. Decisions made were no longer properly

documented, which lead to double work and lack of clarity. Together with Nick, Quince

intervened partly through phase two, and clear guidelines for communication were

once again established, with Nick regaining a firm grasp on stakeholders and

developers on his end, and Quince no longer accepting communication through

informal channels. This eliminated the aforementioned problems and ensured a

smoother workflow.


Page 27

8.2 To management

Reporting to management at Quince was mostly done through two official channels:

the weekly standup for the entire development department, and reports generated by

the internal hours registration system. During the standup, a brief summary was

provided of the work that was completed during the previous week, any problems that

might have arisen and the global planning for the coming week including the capacity

that would be required. Quince uses an internally developed hours registration system

with advanced reporting functionality, enabling managers to quickly gain a bird's eye

view on a project and the hours and resources being spent on it. This, combined with

the planning created at the start of the project provides sufficient information for

managers to make decisions. Of course, informal communication is important as well;

Quince uses a mostly horizontal organisation so informal communication with

managers and staff happens all the time, and anyone interested is kept in the loop on

project progress.

8.3 Issue tracking

While meetings were a key part of our reporting to Infopact, issue management was

also used to provide feedback and keep Infopact up to date on progress. Quince has

historically used JIRA; an issue tracking system developed by Atlassian, and deployed

this for use during the partner portal project as well. Key stakeholders and developers

at Infopact were given access to this system, and a basic explanation on how to create

issues and provide feedback. Wilco (and Nick later on) received administrative access

and the ability to generate reports, giving them the ability to stay up to date on all

progress on current outstanding issues. These issues included bugs discovered by

both developers and the testing teams, but also contained a roadmap for feature

development for both planned phases. JIRA was used extensively by the development

team of course, with outstanding bugs and assignments covered during the daily

standup. With JIRA being updated as often as possible, Infopact was able to keep a

close eye on development progress and adjust their expectations on releases and the

resolution of obstacles accordingly.


Page 28

9 CONCLUSION

The Infopact portal was an interesting project in various ways. First of all, the

experience gained by the project team in using techniques such as FuelPHP and

Bootstrap is invaluable and has already been of immense help in other projects. To

promote the spreading of knowledge within Quince, we have been giving

demonstrations on these subjects to other developers and designers. Not just hard

skills were honed during this project, however. The experience in leading a relatively

large and longer-term project was highly appreciated by both Rene and myself, and

although the increase in responsibility was a challenge we believe we performed well

as a team.

Goals set at the onset of the project were reached, with the new portal taking over all

functionality of the old portal and further integrating additional features, while

maintaining a clear modular nature and segregation from the backend.

The one missed chance would have to be the fact that the FuelPHP framework was

never used to its full extent, due to Infopact's requirement that the data remain in

their backend as much as possible. This was a blow to the project team, and a slight

loss of time due to development work already finished. We however believe that the

final solution we implemented worked admirably, with order creation being a smooth

and seamless experience for the users despite the large amount of communication

and calculation happening.

Infopact has been pleased with their new portal, with orders swiftly returning to their

original volume and increasing further shortly after the release of phase two.

Evaluation after the release of phase two led to two additional phases, with one phase

expanding upon the new functionality and processing feedback from all partners, and

the fourth phase concentrating on maintenance and cleanup, culminating in Infopact

taking full control of the portal. Quince is currently in talks with Infopact about

additional modules and a fully responsive version of the site, but the current iteration

is considered a success.


Page 29

10 BIBLIOGRAPHY

[1] "Infopact," [Online]. Available: http://infopact.nl/.

[2] "PHP," [Online]. Available: http://php.net/.

[3] "FuelPHP," [Online]. Available: http://fuelphp.com/.

[4] "Twitter Bootstrap," [Online]. Available: http://getbootstrap.com/.

[5] "Subversion," [Online]. Available: http://subversion.tigris.org/.

[6] "MySQL," [Online]. Available: http://www.mysql.com/.

[7] "Jira - Atlassian," [Online]. Available: https://www.atlassian.com/software/jira.


Page 30

11 APPENDICES

11.1 Database design


Page 31

11.2 Project document


Page 32


Page 33


Page 34


Page 35


Page 36


Page 37


Page 38

11.3 Graphic design


Page 39

11.4 Interface specification

The following appendix was created together with the User Journey, and combined

they form a detailed description of the interface and use cases of the portal.

De nummering van de schermen in dit document volgt de nummering linksboven weergegeven op de

pagina's van de Infopact User Journey.

Login (1)

Dit scherm biedt de gebruiker de mogelijkheid tot inloggen op het systeem.

Na het indrukken van de 'Login' knop wordt geverifieerd of een actieve gebruiker met het

bijbehorende e-mail adres en wachtwoord bestaat.

Zo ja, dan wordt de gebruiker doorgestuurd naar het dashboard (2).

Zo nee, dan krijgt de gebruiker hier een melding van.

Na het indrukken van de 'Wachtwoord vergeten' knop wordt de gebruiker doorgestuurd naar het

'Wachtwoord vergeten' scherm (3).

Account - Actie (46)

Op dit scherm wordt een lopende 'Barcelona'-type actie getoond.

Hier wordt de beschrijving en een eventueel sfeerbeeld van de actie weergegeven.

De 'actie status' wordt weergegeven als een voortgangsbalk.

Bij een 'plaats <x> orders' criterium wordt het aantal orders binnen de grenzen van de actie

opgehaald en afhankelijk daarvan en van het doel aantal van de actie wordt de voortgangsbalk

gevuld.

Eventuele andere criteria zorgen voor een andere invulling van de balk.

Account - Vergoedingen (44)

Dit scherm toont de ontvangen en openstaande vergoedingen van een partner.

Het systeem zal via een API een lijst met vergoedingen en hun bijbehorende data (order #, status,

etc.) ophalen.

Het importeren zal op gezette tijden gebeuren voor alle partners.

Deze vergoedingen worden vervolgens in een tabel getoond, standaard gesorteerd op meest

recente datum eerst.

Deze tabel biedt de mogelijkheid tot zoeken, sortering en paginering.

Account - Facturen (45)

Dit scherm toont de betaalde en openstaande facturen van een partner.

Het systeem zal via een API een lijst met facturen en hun bijbehorende data (order #, status, etc.)

ophalen.


Page 40

Dit gebeurt, afhankelijk van de beschikbaarheid, als xml/json data of als pdf.

Mocht het importeren als pdf gebeuren dan wordt deze geparsed en de geextraheerde data

opgeslagen.


Deze facturen worden vervolgens in een tabel getoond, standaard gesorteerd op meest recente

datum eerst.


Per factuur wordt de mogelijkheid geboden om een pdf van de factuur te downloaden.

Account - Targets (43)

Dit scherm wordt gebruikt om de verschillende targets die een klant heeft te beheren en in te

zien.

De targets worden in een tabel getoond met een regel per maand, aanvangend met de maand

waarin de partner aangemaakt werd.


Elke regel bevat informatie over de betreffende maand en jaar, de targets en actuals voor die

maand betreffende orders en omzet.

Na het klikken op een regel worden de wijzigbare gegevens (target orders en omzet) van de

betreffende maand in de invoervelden onder de tabel getoond.

Na het klikken op de 'Gegevens opslaan' knop worden de targets van de betreffende aangeklikte

maand opgeslagen en wordt een melding hiervan getoond.

Afhankelijk van de certificering van de partner wordt tevens een 'Rebate target' balk getoond.

Deze balk wordt opgevuld naarmate de partner dichter bij het door Infopact gestelde doel komt.

Contact (39)

Dit scherm wordt gebruikt door partners om contact op te nemen met een van de aan hen

gekoppelde contactpersonen van Infopact.

Het scherm bestaat uit een aantal tabbladen, een per categorie van contactpersoon (Account

Manager, Sales Support, Helpdesk, Finance).

Mocht voor de betreffende partner geen contactpersoon voor die categorie toegewezen zijn, dan

is het tabblad niet zichtbaar.

Elk tabblad bevat informatie over de gekoppelde contactpersoon: Naam, beschrijving, e-mail

adres en telefoonnummer.

Tevens bevat elk tabblad een invoerveld om een bericht aan een contactpersoon te sturen.

Na het klikken op de 'Stuur <x> een bericht' knop wordt het ingevulde bericht in een e-mail naar

de betreffende contactpersoon gestuurd.

Downloads (38)

Op dit scherm worden de beschikbare downloads getoond, en wordt de mogelijkheid geboden

om deze bestanden te downloaden.


Page 41

De beschikbare downloads worden in een tabel getoond met hun relevante informatie (referentie,

grootte, etc.)


Elke regel van de tabel bevat tevens een 'Download' knop. Het klikken hierop start de download

van het betreffende bestand.

FAQ - Detail (37)

Dit scherm toont een specifieke FAQ en het bijbehorende antwoord.

Onder elkaar worden de titel (vraag), datum van aanmaak en text (antwoord) van een FAQ

getoond.

Het scherm biedt drie mogelijkheden tot het exporteren van de vraag (enkel de vraag, dus bv.

zonder menu): printen, opslaan als pdf en versturen als attachment

Na het klikken op de 'FAQ printen' knop wordt de FAQ geprint.

Na het klikken op de 'FAQ als PDF opslaan' knop wordt de FAQ als pdf bestand ter download

aangeboden aan de gebruiker.

Na het klikken op de 'FAQ als PDF attachment...' knop wordt een mail verstuurd vanuit het

systeem naar de gebruiker, met de betreffende FAQ in pdf vorm als attachment.

FAQ (36)

Op dit scherm wordt een lijst van FAQs weergegeven met de mogelijkheid om de details hiervan

te zien.

In een tabel worden de verschillende FAQs per regel weergegeven, met referentienummer, vraag

en een 'details' knop.


Na het klikken op de 'details' knop van een regel worden de details van die specifieke FAQ

weergegeven (37).

Home (2)

Dit scherm omvat het dashboard van de portal en biedt een partner korte overzichten van de

verschillende onderdelen van de portal, en snel toegang tot de meest gebruikte functionaliteit.

Het blok 'Order opzoeken' kan gebruikt worden om direct naar een reeds bestaande order te

gaan, op basis van het ordernummer.

Na het invoeren van een ordernummer en het klikken op de 'Order opzoeken' knop wordt de

gebruiker doorgestuurd naar de detailpagina van een reeds aangemaakte order (13).

Mocht het ingevoerde ordernummer niet bestaan, dan wordt dit gemeld en blijft de gebruiker op

het dashboard.

Na het klikken op de 'Nieuwe bestelling' knop komt de gebruiker op de eerste stap in het

bestelproces, waarbij een aansluitlokatie gekozen kan worden (6).

Na het klikken op de 'Product samenstellen' krijgt de gebruiker de mogelijkheid om snel een

productcombinatie samen te stellen de prijs hiervan te zien (5).

Het blok 'Open orders' bevat een tabel met nog openstaande orders.


Page 42

Per openstaande order bevat de tabel een regel met relevante order informatie, en een statusbalk

met daarin grafisch weergegeven de status voortgang van de order.

Deze tabel biedt de mogelijkheid tot sortering en paginering.

Na het klikken op de statusbalk van een order wordt men naar de detailpagina van de

betreffende order gestuurd (13).

Ook bevat het blok een 'bekijk alle orders' knop, welke de gebruiker doorstuurt naar het

orderoverzicht scherm (12).

Het 'Actuele storingen' blok is gevuld met een lijst van storingen welke op dit moment actueel

zijn en betreffing hebben op orders van de partner.

Per regel wordt een storing weergegeven met de relevante informatie en actuele status.

Mocht een storing niet meer actueel zijn, dan blijft deze nog 1 dag zichtbaar.

Na het klikken op de status van een storing wordt de gebruiker doorgestuurd naar de

detailpagina van deze storing (33).

Ook bevat het blok een 'Bekijk alle storingen' link waarna de gebruiker doorgestuurd wordt naar

de complete lijst van storingen (32).

Het 'Open Support Tickets' blok is gevuld met een lijst van tickets van de partner welke nog open

staan.

Per regel wordt een ticket weergegeven met de relevante informatie en actuele status.

Na het klikken op de status van een ticket wordt de gebruiker doorgestuurd naar de detailpagina

van dit ticket (48).

Ook bevat het blok een 'Bekijk alle tickets' link waarna de gebruiker doorgestuurd wordt naar de

complete lijst van tickets (47).

Tevens worden op deze pagina de twee meest recente nieuwsberichten getoond.

Elk bericht bevat een 'lees verder' link welke de gebruiker doorstuurt naar de detailpagina van het

betreffende bericht (35).

Instellingen - Gebruikers (41)

Dit scherm toont de gebruikers behorende bij een partner en biedt de mogelijkheid om deze toe

te voegen, te verwijderen en te wijzigen.

Het systeem toont een tabel met gebruikers van de partner, met de mogelijkheid tot zoeken,

sortering en paginering.

Deze tabel bevat ook een regel met 'Nieuwe gebruiker', welke gebruikt kan worden om een

gebruiker aan het systeem toe te voegen.

Een regel uit de tabel kan geselecteerd worden, waarna de relevante informatie van de gebruiker

getoond wordt in de invoervelden.

Bij een gebruiker kan ook een 'rol' geselecteerd worden. Deze rol bepaalt de mogelijkheden die

een gebruiker binnen het systeem heeft.

Een 'Alleen lezen' gebruiker kan enkel informatie uit het systeem halen. Alles is inzichtelijk

(orders, storingen, etc.) maar niks kan gewijzigd / toegevoegd / verwijderd worden.

Een 'Lezen en bewerken' gebruiker heeft verder de mogelijkheid tot het toevoegen en wijzigen

van orders.


Page 43

Een hoofdgebruiker heeft daarnaast de mogelijkheid tot het toevoegen en verwijderen van

gebruikers en het toewijzen van rollen.

Na het indrukken van de 'Gebruiker verwijderen' knop wordt om bevestiging gevraagd. Hierna

wordt de gebruiker op inactief gezet, uit de lijst verwijderd en wordt een melding hiervan

getoond.

Na het indrukken van de 'Wachtwoord reset' knop wordt een mail naar het e-mail adres van de

betreffende gebruiker verstuurd.

Deze mail bevat een link inclusief unieke hash naar het 'Wachtwoord reset' scherm (4).

Na het indrukken van de 'Gegevens opslaan' knop worden de gegevens van de gebruiker

opgeslagen. Indien 'Nieuwe gebruiker' is geselecteerd in de lijst zal een nieuwe gebruiker aan het

systeem worden toegevoegd. De nieuwe gebruiker wordt onmiddelijk aan de lijst toegevoegd en

vervolgens geselecteerd, en een melding van succes wordt getoond.

Instellingen - Algemeen (40)

Op dit scherm wordt de algemene informatie van een partner getoond en kan deze aangepast

worden.

Het klantnummer en certificering van de klant zijn niet wijzigbaar door de partner en worden

enkel ter informatie getoond.

Het 'Bezorgadres modem' deel is enkel wijzigbaar als de 'Zelfde als factuuradres' checkbox

uitgevinkt staat. Zo niet, dan zal dit deel dezelfde adresinformatie als het factuuradres tonen.

Na het klikken op een van beide 'Zoek straatnaam..' knoppen wordt aan de hand van de

ingevulde postcode en huisnummer de bijbehorende straat- en plaatsnaam opgehaald en

getoond. Deze laatste velden zijn niet wijzigbaar en kunnen dus enkel aan de hand van postcode

en huisnummer gevuld worden.

Na het klikken op de 'Gegevens aanpassen' knop worden de gegevens van de partner gewijzigd

en wordt een melding hiervan getoond.

Instellingen - Notificaties (42)

Dit scherm toont de verschillende hoofdstatussen die een order door kan gaan en overige

eventueel belangrijke gebeurtenissen en biedt de mogelijkheid tot het selecteren van gebruikers

die op de hoogte gesteld moeten van deze gebeurtenissen.

De verschillende statussen en gebeurtenissen (storingen, support updates, etc.) worden in een

tabel getoond.

Per gebruiker van de partner wordt een kolom toegevoegd met een checkbox per regel. De stand

van deze checkbox bepaalt of de gebruiker op de hoogte gesteld dient te worden van deze

gebeurtenis.

Wijzigingen in de stand van checkboxes worden automatisch verwerkt, hier is geen bevestiging

voor nodig.

Een extra kolom gemarkeerd met '<EXTRA>' wordt toegevoegd aan de tabel met een checkbox

per regel. Mits deze aangevinkt is dan wordt het verderop vermelde e-mail adres ook ook de

hoogte gesteld.


Page 44

Het scherm bevat een invoermogelijkheid voor een 'extra e-mail adres'. Dit wordt gebruikt om

een eventueel adres toe te voegen waar notificaties naartoe verstuurd dienen te worden, maar

waar geen gebruiker van het systeem aan gekoppeld is.

Dit e-mail adres kan e-mails zowel als html-formatted text (standaard) of als ongeformatteerde

text ontvangen.

Dit wordt bepaald door de radio buttons onder het invoerveld voor het extra e-mail adres.

Wijzigingen in het 'extra e-mail adres' en de radiobuttons ten behoeve van de formatting worden

automatisch verwerkt.

Klantinformatie - NAW (26)

Op dit scherm kunnen de algemene gegevens van een klant aangepast worden.

Na het klikken op de 'Zoek straatnaam..' knop wordt aan de hand van de ingevulde postcode en

huisnummer de bijbehorende straat- en plaatsnaam opgehaald en getoond. Deze laatste velden

zijn niet wijzigbaar en kunnen dus enkel aan de hand van postcode en huisnummer gevuld

worden.

Na het klikken op de 'Klantgegevens opslaan' knop worden de gegevens van de partner gewijzigd

en wordt een melding hiervan getoond.

Klantinformatie - Orders (28)

Op dit scherm worden de orders van de geselecteerde klant getoond.

Het systeem toont een tabel met orders van de klant, met de mogelijkheid tot zoeken, sortering

en paginering.

Per order bevat de tabel een regel met relevante order informatie, en een statusbalk met daarin

grafisch weergegeven de status voortgang van de order.

Na het klikken op de 'details' knop van een order regel wordt de gebruiker doorgestuurd naar de

detailpagina van de betreffende order (13).

Een vinkbox 'Alleen open orders...' geeft de gebruiker de mogelijkheid om de lijst te filteren

enkel onafgeronde orders te tonen.

Storing detail (33)

Dit scherm toont de gebruiker alle beschikbare details van een storing.

Het systeem zal via een API alle beschikbare details ophalen.

Storingen (32)

Dit scherm toont alle storingen.

Het systeem zal via een API een lijst met storingen ophalen.


Deze storingen worden vervolgens in een tabel getoond, standaard gesorteerd op meest recente

datum eerst.



Page 45

Support tickets (47)

Dit scherm toont alle support tickets van een partner.

Het systeem zal via een API een lijst met support tickets ophalen.


Deze support tickets worden vervolgens in een tabel getoond, standaard gesorteerd op meest

recente datum eerst.


Ticket aanmaken (49)

Dit scherm biedt de gebruiker de mogelijkheid op een ticket aan te maken.

Alle nodige, reeds beschikbare data zal automatisch ingevuld worden en is niet aanpasbaar.

Tevens bevat het scherm een tweetal invoervelden om de ticket compleet te maken, te weten:

Titel

Omschrijving

Na het klikken op de 'Nieuwe ticket aanmaken' knop wordt de ticket via de API naar TopDesk

gestuurd.

Ticket details (48)

Dit scherm toont de gebruiker alle beschikbare details van een ticket.

Het systeem zal via een API alle beschikbare details ophalen vanuit TopDesk.

Wachtwoord reset (4)

Dit scherm biedt de gebruiker de mogelijkheid het wachtwoord te veranderen.

Na het indrukken van de 'Opslaan en inloggen' knop worden de twee ingevulde wachtwoorden

met elkaar vergeleken.

Als ze niet overeenkomen, dan krijgt de gebruiker hier een melding van.

Als ze wel overeenkomen, dan wordt het nieuwe wachtwoord weggeschreven in de database en

zal de gebruiker automatisch ingelogd zijn en naar het dashboard (p15) gestuurd worden.

Wachtwoord vergeten (3)

Dit scherm biedt de gebruiker de mogelijkheid het wachtwoord te laten reseten.

Na het indrukken van de 'Reset wachtwoord' knop wordt het ingevulde e-mail adres geverifieerd

of het bestaat.

Zo ja, dan wordt er een e-mail naar de gebruiker gestuurd waarin de gebruiker het wachtwoord

kan reseten. Dit is in de vorm van een link. Zodra er op deze link gedrukt wordt, komt de

gebruiker uit op het 'Wachtwoord reset' scherm (p52).

Zo nee, dan krijgt de gebruiker hier een melding van.


Page 46

11.5 User journey


Page 47


Page 48


Page 49


Page 50


Page 51


Page 52


Page 53


Page 54


Page 55


Page 56


Page 57


Page 58


Page 59


Page 60


Page 61


Page 62


Page 63


Page 64


Page 65


Page 66


Page 67


Page 68


Page 69


Page 70


Page 71


Page 72


Page 73


Page 74


Page 75


Page 76


Page 77


Page 78


Page 79


Page 80


Page 81

Documents

INFOPACT PARTNER PORTAL