infopact partner portal
Post on 15-Apr-2022
6 Views
Preview:
TRANSCRIPT
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.
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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'
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact 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.
Bachelor Project – Infopact Portal
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).
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
Page 30
11 APPENDICES
11.1 Database design
Bachelor Project – Infopact Portal
Page 31
11.2 Project document
Bachelor Project – Infopact Portal
Page 32
Bachelor Project – Infopact Portal
Page 33
Bachelor Project – Infopact Portal
Page 34
Bachelor Project – Infopact Portal
Page 35
Bachelor Project – Infopact Portal
Page 36
Bachelor Project – Infopact Portal
Page 37
Bachelor Project – Infopact Portal
Page 38
11.3 Graphic design
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Het importeren zal op gezette tijden gebeuren voor alle partners.
Deze facturen worden vervolgens in een tabel getoond, standaard gesorteerd op meest recente
datum eerst.
Deze tabel biedt de mogelijkheid tot zoeken, sortering en paginering.
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.
Deze tabel biedt de mogelijkheid tot zoeken, sortering en paginering.
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.
Bachelor Project – Infopact Portal
Page 41
De beschikbare downloads worden in een tabel getoond met hun relevante informatie (referentie,
grootte, etc.)
Deze tabel biedt de mogelijkheid tot zoeken, sortering en paginering.
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.
Deze tabel biedt de mogelijkheid tot zoeken, sortering en paginering.
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Bachelor Project – Infopact Portal
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.
Het importeren zal op gezette tijden gebeuren voor alle partners.
Deze storingen worden vervolgens in een tabel getoond, standaard gesorteerd op meest recente
datum eerst.
Deze tabel biedt de mogelijkheid tot zoeken, sortering en paginering.
Bachelor Project – Infopact Portal
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.
Het importeren zal op gezette tijden gebeuren voor alle partners.
Deze support tickets worden vervolgens in een tabel getoond, standaard gesorteerd op meest
recente datum eerst.
Deze tabel biedt de mogelijkheid tot zoeken, sortering en paginering.
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.
Bachelor Project – Infopact Portal
Page 46
11.5 User journey
Bachelor Project – Infopact Portal
Page 47
Bachelor Project – Infopact Portal
Page 48
Bachelor Project – Infopact Portal
Page 49
Bachelor Project – Infopact Portal
Page 50
Bachelor Project – Infopact Portal
Page 51
Bachelor Project – Infopact Portal
Page 52
Bachelor Project – Infopact Portal
Page 53
Bachelor Project – Infopact Portal
Page 54
Bachelor Project – Infopact Portal
Page 55
Bachelor Project – Infopact Portal
Page 56
Bachelor Project – Infopact Portal
Page 57
Bachelor Project – Infopact Portal
Page 58
Bachelor Project – Infopact Portal
Page 59
Bachelor Project – Infopact Portal
Page 60
Bachelor Project – Infopact Portal
Page 61
Bachelor Project – Infopact Portal
Page 62
Bachelor Project – Infopact Portal
Page 63
Bachelor Project – Infopact Portal
Page 64
Bachelor Project – Infopact Portal
Page 65
Bachelor Project – Infopact Portal
Page 66
Bachelor Project – Infopact Portal
Page 67
Bachelor Project – Infopact Portal
Page 68
Bachelor Project – Infopact Portal
Page 69
Bachelor Project – Infopact Portal
Page 70
Bachelor Project – Infopact Portal
Page 71
Bachelor Project – Infopact Portal
Page 72
Bachelor Project – Infopact Portal
Page 73
Bachelor Project – Infopact Portal
Page 74
Bachelor Project – Infopact Portal
Page 75
Bachelor Project – Infopact Portal
Page 76
Bachelor Project – Infopact Portal
Page 77
Bachelor Project – Infopact Portal
Page 78
Bachelor Project – Infopact Portal
Page 79
Bachelor Project – Infopact Portal
Page 80
Bachelor Project – Infopact Portal
Page 81
top related