HSC2011/Software/Frontend: Unterschied zwischen den Versionen
aus Metalab Wiki, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Zur Navigation springenZur Suche springen (Die Seite wurde neu angelegt: „===Teacher Frontend=== HTML/JS webapp running on the teacher's laptop. UX Design Wireframes: Datei:EduBuzzer_InteractionDesign_Version0.1.pdf List of possi…“) |
|||
Zeile 8: | Zeile 8: | ||
List of possible applications: | List of possible applications: | ||
− | ==''' | + | ==Application '''"RAISE YOUR HANDS"'''== |
− | *question | + | |
− | * | + | * I. Application start: |
− | * random | + | ** Teacher poses question to the class |
− | * | + | ** Presses the "start" button in the frontend |
+ | ** Buzzers change status (e.g. pulsing LEDs) as a sign that users can press button to raise their hands | ||
+ | |||
+ | * II. During the timeout period: | ||
+ | ** as soon as a user presses a button on his or her buzzer | ||
+ | ** the buzzer changes status (different LED signal) | ||
+ | ** the frontend displays each buzzer status change | ||
+ | |||
+ | * III. Timeout end | ||
+ | ** either automatic or teacher hits the "stop" button in the frontend | ||
+ | ** buzzers change their status to show that time is over | ||
+ | ** computer changes random buzzer | ||
+ | ** selected buzzer changes status (e.g. plays sound, yellow LED flashes) | ||
+ | ** user with selected buzzer answers the teacher's question | ||
+ | |||
+ | IV. Evaluate answer | ||
+ | ** The teacher presses one of the following buttons in the frontend: | ||
+ | *** correct answer | ||
+ | **** buzzer changes status to reflect "correct answer" | ||
+ | **** app returns to start screen | ||
+ | *** incorrect answer, start new timeout | ||
+ | **** buzzer changes status to reflect "wrong answer" | ||
+ | **** app returns to start screen | ||
+ | *** incorrect answer, select new random buzzer (this option is disabled if there aren't any buzzers left that have pressed a button) | ||
+ | **** buzzer changes status to reflect "wrong answer" | ||
+ | **** new selected buzzer changes status to "answer please" | ||
=='''VOTES/SURVEYS'''== | =='''VOTES/SURVEYS'''== |
Version vom 13. April 2011, 14:10 Uhr
Teacher Frontend
HTML/JS webapp running on the teacher's laptop.
UX Design Wireframes: Datei:EduBuzzer InteractionDesign Version0.1.pdf
List of possible applications:
Application "RAISE YOUR HANDS"
- I. Application start:
- Teacher poses question to the class
- Presses the "start" button in the frontend
- Buzzers change status (e.g. pulsing LEDs) as a sign that users can press button to raise their hands
- II. During the timeout period:
- as soon as a user presses a button on his or her buzzer
- the buzzer changes status (different LED signal)
- the frontend displays each buzzer status change
- III. Timeout end
- either automatic or teacher hits the "stop" button in the frontend
- buzzers change their status to show that time is over
- computer changes random buzzer
- selected buzzer changes status (e.g. plays sound, yellow LED flashes)
- user with selected buzzer answers the teacher's question
IV. Evaluate answer
- The teacher presses one of the following buttons in the frontend:
- correct answer
- buzzer changes status to reflect "correct answer"
- app returns to start screen
- incorrect answer, start new timeout
- buzzer changes status to reflect "wrong answer"
- app returns to start screen
- incorrect answer, select new random buzzer (this option is disabled if there aren't any buzzers left that have pressed a button)
- buzzer changes status to reflect "wrong answer"
- new selected buzzer changes status to "answer please"
- correct answer
- The teacher presses one of the following buttons in the frontend:
VOTES/SURVEYS
- enable to vote on a topic without raising your hand in front of the class which ultimately leads to a more honest voting behaviour
- enables vote mechanisms that are hard to do with paper like multiple choices and ratings on preferred solutions as in "I'd like option A but if we don't get enough votes for that, option B would be my second favourite."
GROUPWORK / GROUPGAMES
- teams of pupils can be chosen by a random generator this would take the social stress off the teacher as in "i dont want to be in a group with this guy.." "..the computer has chosen ist fair"
- games would be possible where groups compete and if a group performs better it has to let a member go into another group
- also the opposite is possible where the best performing group gets new members..
WHO WANTS TO BE A MILLIONAIRE MODE
- if a pupil doesnt know the answer he could "ask the audience" and the kids could press what they think is the right answer..
MULTIPLE CHOICE TESTS
- this will probably not be in version 0.1 as it needs a lot of work that is unrealistic to be implemented with the very short deadline of 2 months
- teacher should be able to have a live on-stage test where the kids can answer questions with multiple choice pushbutton modes
- multiple choice tests are not very common in europe so we need to spend research on this subject
GAMES
- maybe something like the werewolf game
- the remote choses who is the wolf and the others have to find out who it is by talking to each other on a round based system
SCHNITZELJAGD
- multiple stations are layed out around the classroom
- students go from station to station, plug in their ibutton, push a button to put in their solution to the quest presented at this station, go to next station