Third Iteration

After gathering feedback from our client regarding our second iteration, we spent time implementing the changes that he requested. The third iteration was the first major style change our web app had undergone, and was now in better shape for use by the client. The third iteration fulfils the following requirements:

  • RQ1: The application must be a data dictionary editor
  • RQ2: The application must be able to create a data dictionary (logical and physical) for the required system e.g. for a customer system or for a payroll system
  • RQ4: The application should ensure that the data dictionaries can handle the versioning of systems
  • RQ10: The application must have a screen for loading data dictionaries
  • RQ12: The application must have a screen for loading data
  • RQ14: The application must accept systems and data dictionaries as its data (content for the application)
  • RQ15: The application must define a data model for our data dictionary
  • RQ16: The data dictionary should have have the ability to be augmented (can grow in size)
During the third development cycle, we spent time on styling and making sure the system was intuitive to use as this was one of the main points that came out of our last client meeting. We added colour and some JavaScript in order to give a more professional feel to the application.

We added some styling to our home page, adding padding and curved edges to our jumbotron.

We carried the styling through to our other pages to keep our application consistent.

We added icons as asked for by our client to complete tasks such as deleting systems as well as using a hover enabled table to add to a better user experience.

The version name was now a link as the client requested, as well as using icons as we did for systems above.

The list of "tables" as it was called in our previous iteration was renamed data points as requested by our client in order to make the pages function more clear.

In line editing was now added so that the data points could be changed by clicking on the data point the user wants to edit. This was achievable using a ruby gem and some JavaScript.

The table of data points would update when a value was edited.

We added a form so that more than one data point can be edited at once as discussed in our last feedback meeting with the client.

Client Feedback

Once we were satisfied with our second iteration, we had another meeting with our client in order to get his feedback and note any changes he would like. The results of the meeting were the following:

  1. The pop up form to add data points to the data points table should be displayed in column format rather than one row.
  2. Create an active status attribute for versions and data points which are independent of each other
  3. Icons such as the bin for deleting should have text appearing on hover saying "delete" in order to add extra accessibility to the user interface
  4. Add a search bar so that systems and versions can be searched for
  5. Replace current input method to use radio buttons
  6. The mapping section should be implemented. We discussed this in detail and came up with the following structure:

Go to iteration 4

References used for research in iteration 3

1) A RESTful unobtrusive jQuery Inplace-Editor and a helper as a Rails Gem-GitHub [Library]: https://github.com/bernat/best_in_place

2) #302 In-Place Editing-Railcasts [Video Tutorials]: http://railscasts.com/episodes/302-in-place-editing

3) Table Bootstrap designs: https://blackrockdigital.github.io/startbootstrap-sb-admin-2/pages/tables.html

4) #217 Multistep Forms-Railcasts [Vido Tutorials]- http://railscasts.com/episodes/217-multistep-forms?view=asciicast