![](bg3.png)
categories are speed and understanding. A threshold
regulates how many votes are needed in a given pe-
riod of time to notify the lecturer. The teacher will be
notified on a small screen about the current situation.
The third functional requirement, called Chatwall
(CW), is feedback in form of asking particular ques-
tions, rating and answering them. For lecturers it is
hard to give a presentation and read questions from
the audience at the same time. Therefore an unfiltered
forwarding of audience questions will not be conve-
nient. The system gives the audience the possibility
to ask questions on a Chatwall-like platform. At the
beginning questions are proposed and displayed only
on students’ devices. After questions have been pro-
posed others can vote for these. This can result in high
rated questions concerned by many others. A thresh-
old decides which question will be presented to the
lecturer. A log of the Chatwall can also be used by
the lecturer afterwards to evaluate his presentation.
3.2 Non-functional Requirements
Besides the functional features as described above,
Tweedback has many other requirements which aim
best possible user experience. First of all, interac-
tion with the system has to be fast and responsive.
Waiting while interacting with the application is de-
creasing acceptance of users. A second requirement
with direct impact on acceptance rate is an intuitive
and minimalistic user interface, that even fits on very
small mobile devices. Tweedback will be used by
many laypersons. According to (N)ONLINER Atlas
2012 (Initiative D21 e.V., 2012), which represents the
situation in Germany, 96.9% of young people (20–29
years) have Internet experience. So we can assume
that they are able to use even complicated websites.
According to the lecturer’s view, it is assumed that
teachers have less experience with the Internet (e.g.
60–69 years, 60.4%). We do not know what people
will use our system in the future, how old they are or
what preferences they have. So we cannot suppose
that teachers are familiar with complex websites and
their navigation features. According to the students’
side it can be assumed that there is more experience
in dealing with complex websites due to the age of
students.
Students use their mobile devices to access
Tweedback. It is not possible to control which de-
vice will be used. This is a design decision. The ad-
vantage is that users maintain their own devices. The
disadvantage is that the interface of a live feedback
system needs to be as flexible as possible on students’
devices.
With a growing number of users the system needs
to be scalable. This is especially a matter of concern
when many surveys start at the same time. In these
cases many students take part at a survey simultane-
ously. This causes an access peak. Situations with
thousands of connections need to be handled.
For users we want to make the first step of partici-
pation in Tweedback as easy as possible, which leads
to an anonymous access for students. We do not want
users to pass an initial account creation procedure. We
believe in success of open systems.
To generate additional value compared to ”offline“
feedback, users can not be blamed for wrong answers.
It is a common phenomenon that people do not partic-
ipate in surveys because they are afraid to say wrong
answers in the front of others. But these people are
able to participate in a feedback system when users
are anonymous. This is the second reason why anony-
mous access is preferred.
Finally the system has to be modular to easily im-
plement new forms of audience interaction in the fu-
ture.
4 ARCHITECTURE OF
TWEEDBACK
In order to provide an application for many mobile de-
vices, it is sensible to build a web application that sim-
ply serves HTML. Because most mobile devices are
able to render HTML5, Javascript and CSS, there is
no need to develop a native app for all the mobile op-
erating systems (namely the most common used: An-
droid, iOS and Windows Phone) (Kamboj and Gupta,
2012). By using just one browser-related client inter-
face, we do not have to manage and maintain multiple
different platform variants. Even if there are frame-
works that promise to handle these issues, there would
always be multiple different code repositories. This
would unnecessarily increase the development effort
and support.
Furthermore the user interface shipped by the
web application should not only fit on most kinds
of screens (for example on a mobile device and/or a
notebook), but it should be easy to use, too. While the
first can be assumed by using a well-known frame-
work for web user interfaces, the last is hard to
achieve. Our approach is to use the bootstrap frame-
work from twitter. It provides a set of common user
interface elements, such as a header bar or a button,
and organizes the way it is visually structured. Addi-
tionally we want to subdivide the user interface into
different views, in such a way that each feature has its
own view. Offering the lecturer a choice of features,
students are able to see which feature is enabled by
CSEDU2013-5thInternationalConferenceonComputerSupportedEducation
196