GR6: User Testing

Implementation

Our implementation choices were driven largely by previous experience among members of our team, although none of us had compelling full-stack experience (which cause issues during the implementation phase). To that end, we chose to HTML and CSS for presentation, Javascript (specifically JQuery) for dynamic interaction, PHP for dynamic page construction, and MySQL for the database that supported the whole site.

Front End UI

We chose HTML and CSS to create the UI, as one member of our group had a good amount of experience with the technology, and the other members had been exposed through the class. We also wanted to emphasize cross-platform compatibility, and perhaps even lay the groundwork for a future mobile offering, so choose a standards-compliant, cross-platform UI technology fit our design goals. Implementation wise, this did not effect the user-interface too much, as the combination of HTML, CSS, and JQuery allowed us to create a very dynamic user interface. However, as only one member of the team had significant HTML and CSS experience, we were somewhat hindered by the bottleneck of having only one member experienced enough to construct the DOM, and the interactions thereof. This meant PHP and JS development had to wait until the initial static site was completed, and we ran in a good degree of trouble in creating a dynamic version of the static sites from the database.

Dynamic Interaction

For the dynamic portions of the user interface, we relied largely on javascript, especially the JQuery framework and Jeditable plugin. These two technologies allowed us to create compelling, dynamic user experiences with the technological limitations of a fairly traditional web application. Using Jeditable was a great improvement over our initial technological plans of implementing a similar static-to-dynamic DOM translation engine ourselves. Jeditable allowed us to dynamically modify static page content to become editable input dialogs in a seamless fashion. Unfortunately, we introduced this new framework late in the implementation process, and struggled a bit on the JS to database integration.

User-Customized Site Behavior

The major implementation hurdle for our group was in dynamic creation of the pages from the database. Although the save functionality worked flawlessly, we were unable to successfully implement entirely dynamic page creation for GR5. However, we did lay the framework for an enjoyable user interaction in this arena. By introducing such new design aspects as checkboxes to enable or disable sections, attachment buttons to trigger the add media dialog, and seamlessly editable plain-text, we allowed our users to interact with the page similarly to how they might approach a traditional résumé, while enabling easy and intuitive access to the advanced features that make Resumazing shine. It is unfortunate that we ran into such a major design hurdle so late in implementation, as both our backend and frontend implementations were sound, and we only came across major difficulty in integrating the two. This was exacerbated by the fact that only one member of the team had a strong working knowledge of PHP, adding another bottleneck to the unfortunate landscape of overspecialized team members.

Database Schema

We employed MySQL for our databse, as one of our group members had extensive experience working with PHP and MySQL, and felt most comfortable developing in those domains. We employed a profusion of many-to-many relationships to create the type of dynamic page structure called for by our application. The database architecture was sound, as was the saving functionality. Unfortunately, the major hurdle was in retrieving saved information from the database and dynamically creating the requested pages. Additionally, as only one team member was experience with MySQL development, this created another bottleneck in the development process that ended up resulting in unavoidable implementation delays.

Implementation Problems

Our major implementation issues resulted from the problem of connecting a working frontend with a completely implemented backend. Although each part of the site worked satisfactorily in and of itself, using the backend to dynamically create a working frontend, and saving changes in the frontend to the backend data model both caused significant issues in implementation. Ultimately, we had issues with each part of this, although the view worked properly, and the model accurately reflected changes in the view. The main cause of these problems was a bottleneck across a few different technologies. Only one group member truly understood the HTML and CSS to the point where he was comfortable making quick changes to the DOM. Likewise, only one group member was comfortable enough with PHP and MySQL to adequately tie the two technologies together and properly construct a working UI dynamically. Finally, only one group member had enough JS and JQuery experience to construct all the AJAX calls necessary for live, real-time updating. As each of these competencies relied on the successful implementations of the others, we ran into much trouble integrating the different technologies at the end.

Evaluation

User 1:

• Found some bugs in the way the page was populated
• The buttons to move bullet points up and down were nice, but direct manipulation such as dragging and dropping would have been better
• Still some bugs in persisting information once it has been entered
• Like how some input is controlled for certain fields, such as dropdown for address type and only allowing numbers in the phone number
• Logo could be better
• Spacing of top bar (with logo, public link, logout) is kind of weird

User 2:

• Was confused about whether she could add multiple supplemental items for a single bullet point
• Thought the logo was somewhat unprofessional, although workable in spirit
• Thought the supplemental content format icons were clickable to edit supplemental content
• Was concerned that sharing functionality only incorporated a public link, instead of a post to social networks or email this résumé functionality

User 3:

• Appreciated the feedback via icons presented in account creation
• Maybe would have been good to verify the email before allowing resume creation.
• Checkboxes next to the section can be confusing. What if I want to add another section?
• Wanted more options for sharing.
• "Your Face Here" sounded immature.
• Appreciated the inline editing.

Design

Reflection

Throughout the course of this project, we learned a substantial amount about the challenges in iterative design and also in software project management. This was the first time that any of us participated a project of this type – with a fast iteration cycle and a variety of media. If we were to do this project again, we may spend more time initially brainstorming and "verbally" prototyping ideas. This would allow us to really think through an idea before getting into design; additionally, our project could have benefitted from a clearer vision from the start.

We worked very well together as a team, which made the process go very smoothly. Having worked together for 6.005, we knew what the relative strengths of each teammember were. However, what we didn't know is how much the gap between our skills would factor in to our success. Ultimately, the hardest part of the project implementation was not in the complexity of the backend or the details of the frontend, but in putting the two together. We would have greatly benefitted if all of the members would have been better more well versed in all the technologies we used (PHP, HTML, CSS and JavaScript), as a better understanding would have enabled us to be more successful at bridging the gap between the different components. And as always, we could have used more time (and started earlier).

When deciding which features to prototype, we looked at the core tasks that a user might perform. The two obvious ones were creating a resume and viewing one. From there, we thought the two most interesting challenges were how to make it obvious to the user that they are inputting text and how to make a simple interface for attaching the files to a resume. We had to encourage users to speak up about their thoughts when testing the system in order to get useful feedback.