CO600 Group Project Magnus Bogucki, Christos Fragiadakis

Transcription

1 Department of Computer Science CO600 Group Project E-Pinion An Online Questionnaire Management System Magnus Bogucki BSc (Hons) Computer Science and Business Administraion with a year in Industry, University of Kent Canterbury CT2 7UY pmb4@kent.ac.uk Christos Fragiadakis BSc (Hons) Computer Science and Business Administraion with a year in Industry, University of Kent Canterbury CT2 7UY gcf1@kent.ac.uk Page 1 of 7

2 Abstract In the ever-changing world of e-business, web applications continue to replace paper processes. Reduced costs, improved efficiencies and opportunities for in-depth analysis are some of the benefits that online processes offer. Combining this with the competitive need for continuous feedback from customers in case of the University, its students we set out to create an Online Questionnaire Management System, which would enable University Lecturers to create and deploy online surveys in order to gather feedback from students on course content, structure, teaching aids, delivery and coursework. We demonstrate the use of Java in this domain by implementing the Survey Management System in Java Server Pages (JSP), using a MySQL Database to store the information in the Back-End. 1. Introduction Project E-Pinion is our implementation of Dr. J.Bovey s proposal of a web-based Questionnaire Management System. Having worked with online survey tools during our placement years at Sun Microsystems Inc., we were both familiar with the concept and decided to split the task between the two of us although the Management System was originally proposed for a group of four to five students. In the following paper, we will further discuss the background to our project, the aims and objectives we set out to achieve, what approaches we considered and experimental work we conducted. We will then focus in depth on some of the technical aspects of the Project, such as the Database, Architecture, User and Admin Views, Control and Modules. Finally we will present some of the challenges we faced and how we overcame them, a summary of User Evaluations, leading to our conclusion. 2. Background Online Surveys are becoming more and more popular as a way of collecting and analyzing customer feedback. There are two major waves in this trend: Some users prefer to give their questions/surveys to 3d party Software Vendor, who will create the Online Survey for them; However, the majority of Software Vendors focus on giving users the freedom to create their own surveys/questions, by providing them with a toolkit to do so. Benefits of the second approach against the first are more control for the user, maximum customization, reduced time of communication and thus faster cycle times. The only drawback is the complexity of using the particular toolkit, as the users will have to learn how to build questions, pair them with answer options, change the order of questions /answers or even the overall layout of a Survey. Thus, our greatest challenge was to combine a highperformance, maximum feature system, which would cater for many requests by advanced or experienced users, with the ease of use a novice would require. Looking at existing work in the field, we focused our research on four Surveytools: Cogix ( ), the tool used internally by Sun Microsystems, Ultimate Survey Advanced ( ey/demo.asp ), Netreflector ( )and Zoomerang.( ). 3. Aims of the Project According to our Requirements Gathering and Functional Specification, our aim was to create a web-based system to construct, modify and publish online feedback questionnaires interactively on the web and gather, analyse and present the results online. We decided to aim high and set the ambitious goal of producing a management system rather than a plain system of creating and viewing surveys - which was supposed to be undertaken by five students, instead of our team of two. Because of this - and the limited time in hand - we opted for an evolutionary life cycle model, consisting of a first phase to construct a core working system and consequent phases of adding more functionality through extensions and added features. In particular, our aim for the core system was a secure toolkit allowing for the creation of new questionnaires, retrieval and modification of existing questionnaires, and presentation of results. We prioritized extensions as follows, in decreasing level of importance: 1. A structured Question Library providing users with standard questions which they can import and subsequently edit in their Surveys 2. Adjustable Layout and Look& Feel of the Surveys in the form of Templates 3. Start and Expiry Dates for Surveys 4. Result Statistics (as a first form of analysis) Page 2 of 7

3 5. Multi-Page Surveys 6. Cross-Tabulation Capabilities and Download of Results in MS Excel 7. Dynamic Surveys ( Our system would also have to fulfill the following requirements: - Robustness - Functionality - Efficiency - Security - Scalability - ISO Compliance (Process) - Ease of use and User friendliness - Browser Independence (newer versions of Netscape, Mozilla, IE) - Ease of Maintenance - Full Documentation for Users and Administrators Keeping in mind that this is an academic and not a commercial project, other aims could be seen in learning and mastering new technologies such as JSP, Javascript, MySQL and learning more about project planning, design, implementation, documentation processes as well as developing soft skills such as time management, teamwork and organisation. Summarizing the objective of our Group Project, our main aim has been to deliver a working, scalable and well-documented prototype system. 4. Approaches Considered The most fundamental requirements for the E- Pinion System were that it had to be web-based and connected to a Database for data archiving and modification. There is a range of options to write web-based applications that connect to a Database. The ones we considered were the Common Gateway Interface (CGI), PHP, Active Server Pages (ASP) and Java Server Pages (JSP). A CGI script is an external content-generating program run by the web server to access a database and create dynamic output for presentation on a web client. It may be written in a number of languages, such as C, VB or Perl and is compiled against Data Access Libraries in order to connect to the Database. We decided against CGI because firstly we were not as familiar with the C, VB or Perl scripting languages as we were with Java, and secondly because CGI poses many limitations, in Security, maintaining State and Session connections and Performance (a new thread has to be generated for each CGI script). Although PHP, as a platform-independent server-side scripting option, is easy to learn and deploy, we decided against it because of its lack of scalability and security features. Looking at ASP, we discarded it almost immediately because it is proprietary to Microsoft and we wanted our Application to run on an Apache Web Server, which was available to us from the University. We finally decided to use Java Server Pages, because of our familiarity with Java, and the performance, security and scalability JSP offers. The Database we used for development of the application is MySQL, although it can be also be plugged it into a Postgres or other relational Database. Lastly, we decided to use Session Variables as a way of carrying information about Users and Surveys from one Screen to another, as supposed to using a Java Servlet for the sake of simplicity and due to time and resource constraints on the Project. 5. Experimental Work Before we started to do any implementation we decided to do some experimental work in order to get a feel of what technology would be best to use and how we would need to approach our project in terms of planning, design and implementation. The mini-prototype we created consisted of JSP files and a connection to a database containing a checkbox table and question table. We inserted dummy data into the database tables. From there we created a front-end page which dynamically retrieved the data from the database tables and produced a survey. From this prototype we realised that the database structure plays a major role in terms of implementation and therefore we decided to spend extra time on the database design. We also contacted the owner of surveyworld.org and his advice to us was to focus a lot on the database design. Furthermore, we also learnt that we needed to mix quite a bit of HTML, JavaScript and Java. Therefore we found JSP to be more useful than Servlets with JSP we can grab values and insert them straight into our html code rather than having to do out.println statements all over the page. Page 3 of 7

4 6. The Database The Database of the Project is comprised of 15 tables. A script to create them is provided. They can be grouped into four functional entities (see Table 1 on the right). An overview of the relationships between tables, fields and primary keys is provided in the Database Design Documents. 7. Architectural Overview The following (Table 2) is a a high level overview of the E-Pinion System, following a hierarchy from left to right, where AllSurveyCollection is implemented as Departments.jsp, SurveyCollection as Owners.jsp, Manage as mysurveys.jsp etc. Departments, Owners, Surveys AllSurveyCollection (Departments) SurveyCollection (Owners) Survey Questiontypes Checkbox Dropdown Radiobutton TextSingle TextMulti Questiontype - Table 1 - Survey Questions, Answers, Style Prefix_Questions Prefix_Results Ty Template Question Library Questionbank Questionanswers - Table 2 - Page 4 of 7

5 8. User and Admin View The System offers two views one for normal Users and one for Administrators. Below is an overview of the files comprising each of the two and how they are connected (Table 3) User View Admin View 9. Control The application uses JavaScript validation functions and JSP session variables in order to control the users. As the user logs in three session variables are set. The variables which are set are department id, survey collection id and username. By knowing the department id we can customize the users view to one specific department. This is also useful for any future expansion of the application. The survey collection id allows us to make the application more secure because by knowing the survey collection id we only display the surveys which the user owns. When the user clicks logout then all the session variables are killed. However, if the user just closes the window then the session variables will die after 15minutes. The JavaScript that E-Pinion uses validates for any illegal characters and checks if the user has filled in the required fields. The errors that are - Table 3 - produced by the JavaScript are relative descriptive. This is done in order to help the user to see his/her mistake. 10. Modules The nature of the application involves a lot of adding/deleting/modifying and therefore we modularized those specific tasks. For example, when a user adds a question they are presented with different forms, such as checkbox/radio button/dropdown forms, but when they submit the data then it is all directed to one single file which processes the submitted data and updates the relevant tables in the database and then forwards on the user to the right place. The same goes for deleting/modifying questions, answers and surveys. The advantages of having a few files to process the data from loads of different forms are control of application, easy maintenance and scalability. Page 5 of 7

6 11. Challenges and Work-Arounds The first challenge we encountered had to do with setting the default values for Answer Options. We wanted users to be able to specify which answers should appear checked/marked as default when someone would take their Survey. We achieved this by creating an Array called defaults[] in the mofify.jsp file to hold the Default Values and iterating through it with the help of a for loop. Another problem was how to edit the title of a survey. This was as much a design as a coding decision we decided to have it as a pop-up window instead of a separate screen, and achieved this by using Javascript to replace the Title in the Database with the input of the user in the pop-up. Another feature we wanted to implement was enabling users to change the order of questions within a survey and answers within a question in a simple manner. Again, Javascript was used and a function created called which enables users to change the order of questions with a click of a mouse and without changing screens. The use of Javascript brought with it some more problems, since we wanted our application to work in a variety of low-end browsers (as specified in the Business Requirements), such as Netscape 4. This meant hours of extensive testing using different browser versions. As a result, all Javascript features work in most browsers. Moreover, another challenge we encountered was how to enable users to dynamically change the layout and look and feel of a survey they create. We overcame this by using Cascading Style Sheets (CSS) in the preview and survey files and adding a Style table to our Database. Finally, one of the last challenges we faced was how to validate the data users input, in order to prevent error-prone characters such as / which put the integrity of the Database at risk. Apostrophes especially caused us quite a bit of problem when we dealt with queries to the database and JavaScript. The reason for this is that apostrophes usually indicate the end of a statement and therefore the database queries broke or only part of the data was uploaded. We worked around this problem by creating a java method which replaces the apostrophe with two apostrophes. A database query with two apostrophes after each other will not break. In some cases, like entering a value for a question name, we chose to throw an alert statement to the user stating that they should not be using apostrophes. 12. User Evaluations For our Usability Study we divided testers into 3 groups: Novice Students, Advanced Students and Staff. We managed to collect results from 4 Novice, 4 Advanced Students and 4 members of staff. Users were asked to perform a simple walkthrough the system, logging in, creating a survey, adding, modifying and deleting questions, using the Question Library, previewing and pusblishing the Survey and viewing its results. They subsequently had to comment on the level of difficulty (1 to 3) for each task and propose any changes they would like to see. In general, we scored a medium of 1.46 for ease of use (with 1.0 being easy and 3.0 difficult). Users seemed to encounter most problems in editing the title of the Survey and changing its start and end date. We acknowledged these and other suggestions and have embraced them in our Future Improvements Document. 13. Comparison to Existing Tools Benchmarking our system against other (commercial) Surveytools, the difference in resource allocation and time of development becomes apparent. However, we are proud to observe some advantages that E-Pinion has over these tools, and acknowledge areas where other systems give directions for further development of our System. Taking Cogix, the first apparent difference is in the User Interface: E-Pinion is designed with ease of use as a priority, in order to cater for novice users Cogix seems to have a complex User Interface, with a heavy load of options and jargon, not visually appealing. Furthermore, when adding answer options to a question or changing the order of questions or answers, the whole page is reloaded E-Pinion avoids this by using Javascript for these functions, speeding the entire process up. On the other hand, Cogix offers many features (such as Multi-Page Surveys, Detailed Results Analysis and Downloading Capabilities) that we didn t have time to implement in E-Pinion. Comparing E-Pinion to Prezzatech s Ultimate Survey Advanced tool (written in ASP), a lot of the functionality is similar Javascript is used to change order, however when adding answer options to a question the page has to be reloaded. From a Usability point of view, it is arguable that both tools are equally easy to use. In order to Page 6 of 7

7 change the Look and Feel of a Survey, a new template has to be created in UltSurvAdv., where this is done dynamically in E-Pinion. Other tools such as Netreflector or Zoomerang offer interesting features such as cross-tabulation, invitations, a survey creation wizard etc. However, we believe E-Pinion has a more appealing design and is easier to use that s the reason we performed a Design Usability Study and put a lot of effort in creating several design versions to choose from. we finally found is that users perceptions differ from individual to individual, and it would be impossible to build a system to cater for everyone s requests but we tried hard to cater for the majority of users. 14. Conclusions In summary, our project is a working prototype of a robust, functional and scalable Survey Management System. We tried hard to combine a user-friendly interface with many advanced features, resulting in a great tool for experts and novices. Choosing JSP and Session Variables proved a good choice for the scope of the project however using a Servlet could have improved the scalability, modularity and performance of the system. We solved a lot of functionality problems with the use of Javascript, which makes the application more responsive, since pages don t have to be re-loaded every time a minor change to a Question or Answer is undertaken. Comparing E-Pinion to existing Survey tools, it is much easier to use, appealing in its design and still provides satisfactory levels of functionality. Of course, to compete with commercial products a lot of work still needs to be done, in form of extra features, such as download, cross-tabulation and analysis of results, multi-page or dynamic survey capabilities etc. However, given the time and human resource constraints, we can be as satisfied as the system users will be. According to their comments in our Usability Study, they are generally confident in using it and like many of its features. Some of the most important criticisms we received on our design decisions were the Edit Title function, which is hard to spot and should probably be in the Menu, the URL of the live Survey (hard to find) and the Start/End Date function for Surveys, which many users expected on the MySurveys Manage Page. Responding to users suggestions, we changed some of the names used to be more descriptive (i.e. Fulltext and Value to Answers Displayed and AnswerID in Question) and would continue improving the systrem s usability. What REFERENCES : Cogix, Ultimate Survey Advanced, Netreflector, Zoomerang, JSp vs ASP Servlets vs ASP vs PHP (Performance benchmarking) JSP vs PHP vs ASP PHP, Perl, Java Servlets ibm.com/developerworks/web/library/wasssl.html Performance Comparison of Web-Based Database Access Page 7 of 7