|
|
CXP-Powered I-MINDS Capabilities 2.0 |
We have
significantly revised our QuestionAnswering and BuddyGroup capabilities.
Here is a synopsis of our changes:
|
|
QuestionAnswering |
Data Adapters One significant change we made in this
version is how the database is accessed by our source code. In v1 most of our source code in Question
Answering used C# DataAdapters to access the
database. In brief, DataAdapters
select all the records in a table and populate a C# DataTable
with the results. This can be very
convenient because once the DataTable is populated
you can manipulate the data (add, remove, update records) without querying the
database. However, we encountered some
concurrency problems with the implementation.
While these were not as bad as those encountered by Buddy Group, the
decision was made to remove all the DataAdapters and
replace them with SQL queries.
Adding Keywords In v1, there was no way to add additional
keywords to the database without writing the queries yourself. This was an oversight on our part, in the old I-MINDS client we had a form for adding new
keywords and weights. When we made the
decision to use the CXP Client, this was a feature that somehow got left
out. In v2, this feature is back. The teacher can at any time select the Add Keyword
item from the Options menu. This brings
up a form containing a DataGrid with all the keywords
and weights stored in the database. The
user can delete existing keywords by clicking on the row and pressing
delete. New keywords can be added by
clicking on the star row at the bottom.
Existing keywords can be updated by selecting their entries and typing
in a new weight. To save the changes
simply press the Update button. See
figure 5.1 for more information.
Virtual Classroom The Virtual Classroom form is very useful
for teachers. It displays information
about each student, message, and topic from a classroom. Students are represented by small pie charts,
with each chart split into five pieces.
Each piece corresponds to a different statistics category. The pieces are colored blue if the student is
at or above the thresholds for those statistics (as set by the teacher) and
colored red if the student falls below the set thresholds. These thresholds are stored in the database
so the teachers can just “set it and forget it”, rather than worry about their
levels. The statistics are computed for
the last number of sessions specified at the bottom left corner of the
screen. The Virtual Classroom form is
accessible from the Options menu, in the teacher version.
Statistics Charts The Statistics Charts form is used to
display statistics information about students in graphical form. A teacher can choose to display all the
statistics of any individual student or the ratings of each student for an individual
statistic, both in bar chart form. Once
again, statistics that fall at or above the thresholds set by teachers are
shown in a blue color and those that fall below thresholds are shown as a red
color. The thresholds are the same ones
recorded in the database by the Virtual Classroom form, and any change to the
thresholds is propagated in both forms.
There is also the option of displaying a legend for the statistics by
clicking on the Legend button. Once
again, the stats are computed for the number of sessions specified in the
bottom left corner of the screen, which is also tied to the corresponding
option in Virtual Classroom. The Student
Charts form is accessible from the Options menu, in the teacher version.
|
|
BuddyGroup |
Data Adapters One significant change we made in this
version is how the database is accessed by our source code. In v1 most of our source code other than the
statistics class used C# DataAdapters to access the
database. In brief, DataAdapters
select all the records in a table and populate a C# DataTable
with the results. This can be very
convenient because once the DataTable is populated
you can manipulate the data (add, remove, update records) without querying the
database. However, we encountered
horrible concurrency issues with this implementation. Because of the way capabilities work, it was
very difficult to synchronize all the DataAdapters. This led to all sorts of bizarre errors
relating to database concurrency. The
decision was made to remove all the DataAdapters and
replace them with SQL queries throughout the BuddyGroup
codebase. This
eliminated the concurrency errors because all the students were dealing
directly with the database.
MAX(Session_ID) In
v1, the Session ID was determined by simply taking the MAX(Session_ID)
from the database. This worked well
until we started using Question Answering at the same time. A scenario occurred where Buddy Group was
started and students joined and queried for their Session ID. A Question Answering capability was then
started incrementing the Session ID. If
additional students join the Buddy Group they will no longer receive the
correct Session ID.
In v2, the
Session ID is determined once when the capability is created. It is then broadcast to each participant when
they join the capability. In affect, the
Session ID is “buffered” for all participants.
Because of this, when the participant who started the capability leaves
the Session ID is not lost. This also
solves the problem where a student accidentally starts up another Buddy Group
capability. Now Buddy Group and Question
Answering can coexist peacefully without corrupting the database.
Students_In_Buddy_Group and Students_In_Session In
v1, both these tables were N:M linking tables
connecting two other tables. The
limitation on N:M linking talbes
is that each pair of values is a unique primary key. The database will not allow us to have the
same student in the same buddy group twice, for example. In affect, we knew which students were in
which Buddy Group or Sessions, but that is all we knew. We wanted to be able to track which students where
in a buddy group during an interval of sessions and when students joined and
left a session. This required more than
just N:M linking tables. Both the above tables were
replaced with triply-linked tables.
Load
Messages In v1, each message was broadcast to each
student immediately after it was added to the database. This worked fine in practice, but happens if
one of your buddies arrives late? We
decided it would be nice to have the option to ask the database for the
messages sent to your buddies for this session.
We added the “Load Messages” menu item to the Options menu. Pressing it queries the database for the
messages sent during this session. This
list is filtered by who your buddies are.
It will not return messages for students who are not currently your
buddies. These messages are identically
formatted to those received in real time.
MessageTree The MessageTree class was modified so
that it has the ability to generate a full message tree for any message
regardless of its position in the tree.
This is done by first determining the root for message tree (the message
ID which started the topic) and then generating the full subtree
from this message. This reduces the
complexity of some of the queries in the Statistics class considerably. The MessageTree
class can be configured to only generate the subtree
for the given message ID.
Statistics It was determined through testing that
several of the statistics queries in v1 where not returning exactly the results
we wanted. A minor change to the way we
stored messages in the database considerably reduced the complexity of some of
the queries while increasing the validity of their results. This was done by storing whether or not the
message was a topic-starter or response in the Message table. The Recipient column now contains the value
“BUDDIES-TOPIC” or “BUDDIES-RESPONSE” where appropriate.
The queries in
v1 for Dialog Involvement only looked at the responses and their parents. Thus they only worked only for message trees
of max height 2. In v2, we can query for
all the messages that are “BUDDIES-TOPIC” and use the full message tree feature
described above in MessageTree to compute the
statistics for message trees of any height.
We were also able to clean up some of the statistics queries in v2 such
as those for ComputeAverageResponseTime. All queries now check the same session
interval. In v1, ComputeSessionMessages
and ComputeSessionMessageToTeacher (along with their
averages) did not use this session interval determined by the Calculate
menu. This has been fixed in v2.
Database Search The Database Search form can be used by both
students and teachers to look up both messages and users in the database. Messages are searchable based on the message
itself, the sender, the group they were sent to, by score, by session, and also
by time and date the messages were received, answered, or discarded. Any combination of these properties can be
used at once thanks to intelligent querying.
Students are searchable by name and identifier. The Database Search form is accessible from
the Options menu.