A.    The Current Paper-Based Memo Processing

The conventional paper-based memo system is modelled into the proposed system to preserve the originality of the manual system in the new electronic system.  Figure 2 shows the conventional flow of sending memos in any typical organization. The memo is first written by an assigned officer or a staff. It consists subject, date and time, references of higher officers (widely known as “Throughs”), copies(widely known as Cc),  body of the message and the signature of the sender. If this memo has one or more “Throughs” in it, the memo will have to pass through the named officers who will make comment, approve or disapprove and append signatures and date on the memo. Memos are written and signed in ascending order of the mentioned officers’ hierarchy (or cadre). Memos with one or more “Ccs” will have to be delivered to the mentioned persons for record purposes. After all necessary approvals have been accrued from all through which the memo was written, the memo is then ready for a dispatch after having been recorded in the incoming mail file. Figure 3 shows the conventional process flow for incoming mails. A written and duly signed memo is received by the recipient’s department’s office. The memo is stamped and registered and finally delivered to and receipt of the memo acknowledged by the intended recipient(s). Not all memos demand a reply; hence Figure 3 may not be necessary in some cases. This paper-based system as elicited above is known to compromise speed, confidentiality and security as well as pose some challenges regarding the ease of storage and retrieval, unrequired redundancy and delimited access. These challenges necessitated the need for the designed system.

 

 Figure 2.      Process flow for generating paper memo

 

 

Figure 3.      Process flow for incoming papermemo

B.    Conceptual Framework of the Proposed eMemo

Memo entails generation of memo, signing of memo by superiors, delivery and actions as required by intended recipient(s). Signing and documentation are required at each stage of the memo lifecycle. This section discusses the user categories and their conceptual relationships and roles, the system architecture, data models and transactions of the proposed eMemo system.

  i.      User Categories and Relationships

The proposed electronic memo system is typically meant to replicate the workings of a manual memo. The users are typically categorized as follows:

·          The Generator / Sender: This includes any staff of an organization seeking to pass or request an information, demand actions from personnel, convey deadlines to specific personnel, to all personnel in a specific category (e.g., all Directors, all Managers, all Deans etc.) or to every member of staff in the organization. The request will contain a specific system-generated reference number and timestamp, sender’s information at the time of memo generation, and, basically, recipient(s), subject and body of memo.

·         Recipient(s) / Group of Recipients: This is a list of those registered and authorized to receive the generated memo. This may be an individual and may also be one or more groups of personnel as may be required. The recipients may take actions such as acknowledge, append a public or private note, or reply the sender.

·         Through(s): These are users who must see and approve a generated memo before getting to the intended recipients. A memo written to the Vice Chancellor of a University may have to pass through the approval of the Head of Department and Dean of Faculty of the memo generator. At each hierarchical layer, an action triggers another layer until it is finally signed off by all “throughs” before being delivered to the recipients. A copy is however kept with these users after taking an action.

·         Cc(s): A memo may copy individual or group(s) of individuals. This is visible to them once this email is generated and undergoing its lifecycle. Those copied in a memo are only allowed to append private notes to the memo.

·         Administrator and ICT Department: The ICT department sits on top of the operations of the proposed system. The (super)admin possesses to root privileges of the system but not without an adequate audit trail. Other users in this category are basically responsible for providing solutions to complaints and requests. They hold the information required to solve issues. They can see all requests and respond to them accordingly. They also see to the one-time biometric enrollment of members of the organization.

Figure 4 shows the scenarios of usage of a typical user of the system while the relationships existing between these user categories are simply illustrated by the organogram in Figure 5. The super administrator monitors and coordinates all the processes of the eMemo platform and supervises the ICT users who in turn provide services for the intended users of the system. There is a bottom-up reporting hierarchy as depicted in Figure 5. The ICT users serve as the middlemen in the chain, providing services to the major users and are moderated by the super-admin on top of the chain.

Figure 4.     Scenarios of Usages of a User

 

Figure 5.      Relationship Diagram of the eMemo system

 

  i.      System Architecture for eMemo

The designed e-memo system as shown in Figure 6 was designed on a three-tier Model-View-Controller (MVC) software architectural design pattern. The MVC model is a compartmentalized framework of well-defined but interconnected components with a well-structured, secure and highly scalable characteristics. The model handles all data-related logic of the system, all entities and relationships and all user roles and restrictions at the data level. The view is used to handle the display of data and all user interactions and personalization. The controller is the brainbox of all processed logic which interfaces between the model and the view components. It is responsible for the business logic of the system including processing of incoming requests, data manipulations and rendering of vital subcomponents to the View component. The HyperText Transfer Protocol (HTTP) handles all the request-response mechanisms and Application Program Interface (API) calls.

 

Figure 6.      System Architecture of Proposed eMemo

The controller component in the system architecture handles some functions which include but are not limited to:

·         Generate Memo Module

The function “compose_memo” presents the user (the memo originator) with a standard form to generate a new memo. Upon triggering the generate() function, the user is then able to select the recipient’s name in the Recipient’s section. The “Through” section allows the memo originator to add as many users as possible. The system automatically arranges the selected users in descending order of hierarchy as exists in the organization. The memo originator then types in the subject and body sections of the interface. The attachment section allows uploading files in allowed media formats alongside the generated memo. The last section is the “Cc” section in which the user is allowed to select as many users or/and groups of users as possible or send copy by category. The signature is automatically appended as it has been captured upon registration by the admin. The user clicks the Submit button to finalize after having previewed the memo.

·         Memo Response Module

The “treat_through()” subprogram allows memos written through the user to be approved or disapproved as well as commented on. After commenting, the timestamp in which each user treats this memo is appended alongside the signature. If a particular memo is written through two or more users, the memo is intelligently sent to each user one after another from the lowest to the highest cadre. When all “Throughs” have been completed, then the “treat_memo()” subprogram which finally makes this memo available to the intended recipients for treating is activated.

·         View/Search Module

One of the major benefits of an e-record system is its indexing, sorting and searching efficiency. This module is concerned with making memos available to users in all categories depending on their respective user roles. Search terms using sender, body of memo, subject of memo are given top search priority.

·         Notification Module

This module is active in order to trigger an instant notification via SMS or/and email depending on the user’s profile settings so that each user is aware real-time that a memo is waiting attention. The notification subprogram also takes care of escalations – a situation where a memo that requires action is left unattended to for a certain number of working days.

·         Report/Audit Module

The “report_audit()” method enables the administrator to generate reports on memos generated in a given period of time and helps in the audit trail functions.

  i.      Workflow for the Proposed eMemo

The designed e-Memo System has two options for a given organization; the local server option and the Cloud Server option. Table 1 shows compares these options in terms of the system’s capabilities. Choosing between these two options depend on the context of usage.

Table 1. Comparative analysis of the two options provided by the proposed system.

Criteria	Locally-hosted Server	Cloud Server
Wider accessibility	No	Yes
User’s convenience	No	Yes
Instant notification system (SMS and Email)	No	Yes
Speed of access	Yes	No
Need for internet by each office	No	Yes
Accessibility on mobile devices	Yes but confined to the local premises	Yes
Reliability	Reliable	More reliable
Backup	Yes	Yes
Security	Depending on the administrator	Cloud security is more recommended

 

Figure 7 shows the dataflow operations of the eMemo system. The sender is the originator of the memo. There are two categories of third-party users, those through which the memo is written and those who were copied in the memo. Memo is received immediately when it is composed and sent if it is not written through another user or kept in “waiting to be delivered” if written through one or more users (i.e., signees) until it is treated accordingly.

Figure 7.      Dataflow Operations of eMemo

 

ii.      Data Model of eMemo

The relational data model is adopted in the Model component of the system. A relational data model $R = \{D_n | n \in \mathbb{N}\}$ is a set of n-tuples $\{A_i \times d_i | i \in \mathbb{N}\}$ where  $A_i$ are attributes with the domain $D_i$ having tuples $d_i$.   If $P_i$ are a set of schema relations, then $\{P_i | i \in \mathbb{N}\}$ are different relations with specific attributes over a given domain  [33][34][35].

The database of the proposed eMemo is a pool of semantically related objects given as:

 

eMEMO = {USER_CATEGORIES, USER_ROLES, USERS, MEMO_CATEGORIES, MEMOS, MEMO_ATTACHMENTS, MEMO_ESCALATIONS}

 

The schema of the identified relations as shown in Figure 8 which are well structured but interrelated in a way that allows data independence.

Figure 8.     Relational schema of the eMemo System

A.    Implementation

This section deals basically with the implementation of the eMemo system vis-à-vis the software and hardware requirements as well as the front-end and back-end development procedures. The frontend was developed using HTML, Twitter Bootstrap, JavaScript and JQuery. The server-side of the request processing of the system is written in PHP and AJAX. The choice of database is MySQL. Table 2 contains the tools used in the development phase of this study.  

 

Table 2: Development phase requirements for the eMemo system.

SOFTWARE	RECOMMENDATIONS
Operating system	Windows 10 64-bit
Front-end programming (UI/UX)	HyperText Markup Language (HTML), Cascading StyleSheet (CSS) and BootStrap
Client-Side scripting	JavaScript
Server-side scripting	HyperText Pre-Processor (PHP), Asynchronous JavaScript and XML (AJAX)
Text-editor IDE	Sublime Text 3
Server + Database	Apache and MySQL Server using the phpMyAdmin interface
API	SMS service via Representational State Transfer (REST) API, Google CAPTCHA authentication

 

eMemo was implemented to improve the working face of memorandum processing in an organization. Its flexibility allows the user institution to select between the local-hosting and the web-hosting options. It was designed with a mobile-first strategy (using fluid layout) because the potential users are smartphone owners. Feedbacks from users are integrated into the system and features are extended for an improved User-Interface/User-Experience (UI/UX).

B.    Testing

The eMemo system was tested in the alpha-beta-gamma test phases. The alpha testing was by the developers and other team members and feedbacks were collected. The beta testing was conducted by randomly selected members of staff in the Faculty of Science of Lagos State University and feedbacks were also collected. The gamma testing was conducted in a University-wide setting after the full deployment of the system. Feedbacks were collected and integrated using the agile principles.

C.    Results

42 academic staff members were in attendance during the beta testing. Registration was done and accounts were activated via email. Administrators assigned roles obtainable in a university setting to registered users. Memos were generated, treated and signed off by the designated superiors. Completely treated memos were sent to and immediately treated by the intended recipients. The prototype of the development has been temporarily hosted at https://lasucomputerscience.com/memo.

Figure 9 shows the system’s homepage which includes a brief description of the designed system including the Login page. Staff signs in with their Staff ID and password. Only staff members who have been pre-registered can login to this platform.  Figure 10 shows the landing page of an authenticated user. Figure 11 shows the core function of the designed system; that is, the “Compose Memo” menu where a new memo is being generated. User selects the faculty of the intended recipients, then the department, and a list of registered users in the selected department will drop down for the memo originator to choose from.  User can, in addition to a conventional paper-based memo, attach media of supported formats alongside their memos. User submits the form and a new memo is successfully created and reformatted in the institution-wide accepted format. Figure 12 shows the list of messages written through the logged-in user with their corresponding status of treatment. The eMemo lifecycle has an average turnaround time of 4 minutes 32 seconds on the average of 42 experimental testing.

D.   Threats to Validity
In judging the quality of a research study it is very important to consider threats to the validity of the study and the results. For quality assurance purposes, we evaluated the performance and stability of our system vis-a-vis threats to validity using  the Validity Test (VT) criteria. The selected  VT checks are presented in Table 3. 

Table 3: Validity Threats of the Study

Validity Threats	Questions and Answers (Q & A)
Internal Validity	Q: Does the software we introduced cause the effect on the way memos are treated?
	A: Yes. Memos are now treated as fast, safe and effective as possible.
External Validity	Q: Can we generalize our results? Do the results apply in other contexts?
	A: Yes, we can generalize our result because the system can be ported to any organization as long as they use official memo to communicate some internal affairs.
Construct Validity	Q: Does the outcome correspond to the effect we are interested in?
	A: Yes, because the original intent of the researchers was to minimize processing time, improve memo standard, improve response time, security and so on. Results gotten from the usage of eMemo shows huge potential in making life easier and better for staff in the organization
Conclusion Validity	Q: Does the change we introduced have a statistically significant effect on the outcome we measure?
	A: The average processing time of a memorandum on eMemo shows that our system also shows a statistically significant effect on the performance indicators of the eMemo.

 

 

Figure 9.     The Homepage Design + Login

 

 

Figure 10.     User Personalized Page

 

 

Figure 11.     The Memo Generation Page

 

Figure 12.     List of messages to be treated.