This marks the start of my efforts to improve the results view. If you have any comments or suggestions please write to me or instead use getsatisfaction.com to share ideas and raise issues.

If anyone has any suggestions then please feel free to contact me at kumo@kumo.it with any ideas. Also I am looking for translations for my Roman Numerals application (external link to itunes) so if anyone would like to help out I would be most grateful. I have Italian, Korean, and Chinese (Traditional and Simplified) so far.

This plugin treats a datetime attribute and an integer attribute as a boolean. This boolean can then be used as normal attribute in a check box (or in any part of the program) and when it is checked, the datetime records the moment and the integer records the id of the current user.

It is assumed that there is a Users table and that the current user can be found at User.current_user. If the current user cannot be accessed then 1 is used as the id.

h3. Installation

$ cd vendor/plugins
$ git checkout git://github.com/kumo/acts_as_confirmable/tree

h3. Usage

* On models where you want to be able to confirm X add a X_confirmed_at datetime and X_confirmed_by integer.
* In the model put acts_as_confirmed :X
* In the views add check boxes (check_box :X)

h3. Example

h4. create a new rails app

$ rails confirm
$ cd confirm

h4. create users table and items table with 3 confirmable fields

$ script/generate scaffold user name:string
$ script/generate scaffold item name:string \
      started_confirmed_by:integer started_confirmed_at:datetime \
      finished_confirmed_by:integer finished_confirmed_at:datetime \
      ready_confirmed_by:integer ready_confirmed_at:datetime

h4. add the plugin to the model

class Item < ActiveRecord::Base
  acts_as_confirmable :started, :finished, :ready
end

h4. add 3 check boxes in items/new.html.erb and items/edit.html.erb

  <%= f.label :started %>
  <%= f.check_box :started %>



  <%= f.label :finished %>
  <%= f.check_box :finished %>



  <%= f.label :ready %>
  <%= f.check_box :ready %>

h4. show the confirmation info in items/list.html.erb

  <%=h item.started? %>
  <%=h item.finished_confirmer.name if @item.finished? -%>

h4. example of assigning a user to current_user

class User < ActiveRecord::Base
  cattr_accessor :current_user
end

class ItemsController < ApplicationController
  before_filter :load_user

  def load_user
    User.current_user = User.find(:first)
  end
end

h3. Available fields

If a model has the attributes fields started_confirmed_at and started_confirmed_by, then the plugin provides:

*

started?

-- true if it has been confirmed by someone on a specific date
*

started

-- same as above but is normally used by a check box tag
*

started=

-- the assignment method that is used by the check box when posting
*

started_confirmer

-- the user that confirmed it
*

started_at

-- when it was confirmed

I tend to prefer to use development tools that simplify the tasks that I have come to find routine, but perhaps more importantly provide me with a fresh and powerful way of looking at new problems that I need to solve. The latest tool to find me is “user stories”:http://rspec.info/documentation/stories.html with “RSpec”:http://rspec.info. Now, I must say that I was already using RSpec to ‘test’ other Ruby on Rails applications and I think that everyone should try and play around with it for a bit, but user stories — in particular the plain-text flavour of them — are what currently occupy my notebook scribbles.

Let me show a somewhat simplistic and incomplete example of a user story:

Story: starting a quiz
  As a visitor
  I want to start a quiz
  So that I can hopefully learn something

  Scenario: quiz doesn't exist
    Given a quiz named hiragana
    When I start another quiz
    Then I should see the 404 error page
    And I should see a link to the list of quizes

  Scenario: quiz does exist
    Given a quiz named hiragana
    When I start the quiz
    Then I should see the quiz
    And I should see a question

We have a story with two scenarios: when the quiz exists and when the quiz doesn’t exist. It is not very interesting, but at least we know that the user should see an error page if they try and start a quiz that doesn’t exist, and that they should also see a list of quizes that are available instead. If the quiz does exist then they should see a question.

This might be useful if we want to ensure that the 404 page is shown when the requested quiz doesn’t exist, but it is not very satisfactory to write down and seems a bit pointless. It also doesn’t help us understand what happens when a user starts a quiz.

One of the main thing that I like about plain text user stories is that I can easily scribble them down on a piece of paper. I can focus on describing my goals without worrying about the implementation details and afterwards even use this “pseudotestcode” directly. The plain text user story also is nicely separated from the implementation code that is needed to make it work and because of this, it is easy to fit an understandable and detailed story in a manageable page or two.

I think I will use the following story in my quiz redevelopment and next time I will discuss other stories, and also how to test these stories.

Story: starting a quiz
  As a visitor
  I want to start a quiz
  So that I can hopefully learn something

  Scenario: quiz doesn't exist
    Given a quiz named hiragana
    And a quiz named katakana
    When I start another quiz
    Then I should see the 404 error page
    And I should see a list of quizes
    And the list of quizes should have 2 items

  Scenario: default configuration
    Given a quiz named hiragana
    When I start the quiz
    Then I should see the quiz
    And I should see a question
    And I should see the text "Question 1 of 5"
    And there should be 3 textboxes

  Scenario: 10 questions
    Given a quiz named hiragana
    And the quiz has been configured for 10 questions
    When I start the quiz
    Then I should see the quiz
    And I should see "Question 1 of 10"

  Scenario: 5 hiragana per question
    Given a quiz named hiragana
    And the quiz has been configured for 5 hiragana
    When I start the quiz
    Then I should see the quiz
    And there should be 5 textboxes

  Scenario: areas have different types
    As an administrator
    I want to assign different types to the areas
    So that I can structure the home page

    Scenario: footer shows page links
      Given an area
      And area has 5 pages
      And area is of type footer
      When I view the home page
      Then I should see the home page
      And I should see the footer section
      And the list section should contain 0 areas
      And the footer section should contain 5 links

Of course, if I actually bothered to read it properly then I would have seen that the first line should have read:

  Story: areas have different types

Moral of the story: even if the code that you have to write is small, always assume that you are capable of making silly mistakes!

The comments that I received were as follows:

• …should show results at end of quiz…
• …ask real words…
• …optional real words…
• …keyboard shortcuts…
• …show correct answers at end of quiz…

Some notes from the graph and comments:

• more than half of you requested that you be tested with real words;
• repetitive questions appears to be a problem;
• an equal number of you wanted to be able to check your progress and also have the questions adapting automatically to your progress.

Real words I believe have been requested by people that have already learnt quite a bit of the hiragana or katakana and now want to be tested on words that are actually useful. When I try to learn things I tend to focus on one group at a time so I think it would be difficult to find a list of words that only contain ka, ki, ku, ke, ko for example.

Repetitive questions could either be the result of selecting too few character groups so that the questions are always formed from the same 10 characters, or instead the same characters are shown regardless of how many character groups are selected.

Progress tracking and automatically adapting questions can allow the software to automatically suggest which groups/characters need testing and when. However, if the on-screen results are not clear then there is the risk that the users are not aware of their progress and perhaps even the mistakes they have made and need to concentrate on.

I will post on this again later, but if people do have any more comments or want to open up a discussion then please use the comment form below.