ducklet/quiz
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
quiz/public/buzzer.html

157 lines
4.7 KiB
HTML
Raw Normal View History

init with crummy buzzer & docker setup so much boilerplate :O
2021-01-29 01:20:17 +01:00
<meta charset="utf-8" />
<link rel="stylesheet" type="text/css" href="buzzer.css" />
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
<body class="player">
add user session reclaiming In its current state the implementation should allow a user to resume their session if the websocket connection is reset, for whatever reason. This could be expanded to allow session sharing (multiple agents logging in to the same client), or manual session resume via some sort of password (encode uid & key to some pass-phrase kinda thing, or QR code).
2021-01-31 00:19:35 +01:00
<div id="error">
Error:
<code></code>
</div>
replace user buzzer with big red button
2021-03-02 20:02:54 +01:00
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
<div id="points-admin" class="admin-only">
<h2>Admin</h2>
lint
2021-03-02 20:06:03 +01:00
<div>
<a href="monitor.html" onclick="this.href='monitor.html'+location.hash"
>Monitor</a
>
</div>
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
<div>
<label>points: <input type="number" name="points" value="0" /></label>
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
<button data-onclick="named.points.valueAsNumber += 100">+ 100</button>
<button data-onclick="named.points.valueAsNumber -= 100">- 100</button>
<button data-onclick="named.points.valueAsNumber *= -1">+/-</button>
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
</div>
<div>
<label>tokens: <input type="number" name="tokens" value="0" /></label>
</div>
control via admin what players to show in monitor
2021-02-04 00:04:03 +01:00
<div>
lint
2021-03-02 20:06:03 +01:00
<label
>monitored:
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
<input type="text" name="monitored1" value="" />
<input type="text" name="monitored2" value="" />
<input type="text" name="monitored3" value="" />
</label>
lint
2021-03-02 20:06:03 +01:00
<button
data-onclick="conn.send('control', {targets: [
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
named.monitored1.value,
named.monitored2.value,
named.monitored3.value,
lint
2021-03-02 20:06:03 +01:00
], action: 'monitor'})"
>
resubmit
</button>
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
</div>
<div>
lint
2021-03-02 20:06:03 +01:00
<label
>text overlay:
<textarea
name="textbox"
data-onselect="
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
const text = target.value.substring(
target.selectionStart,
target.selectionEnd
) || ''
conn.send('control', {action: 'text', text})
lint
2021-03-02 20:06:03 +01:00
"
data-onchange="
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
if (!target.value.length) {
conn.send('control', {action: 'text', text: ''})
}
lint
2021-03-02 20:06:03 +01:00
"
></textarea>
</label>
</div>
add admin ability to double card values
2021-03-02 20:08:28 +01:00
<div>
<label
>double:
<button data-onclick="conn.send('control', {action: 'double'})">double</button>
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
</label>
control via admin what players to show in monitor
2021-02-04 00:04:03 +01:00
</div>
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
</div>
replace user buzzer with big red button
2021-03-02 20:02:54 +01:00
<div id="userinfo" class="player-only">
<label
init with crummy buzzer & docker setup so much boilerplate :O
2021-01-29 01:20:17 +01:00
>You:
<input
type="text"
name="username"
id="username"
placeholder="Please put your name here ..."
replace user buzzer with big red button
2021-03-02 20:02:54 +01:00
data-onchange="q('#set-name').disabled = false"
lint
2021-03-02 20:06:03 +01:00
/><button
id="set-name"
data-onclick="
replace user buzzer with big red button
2021-03-02 20:02:54 +01:00
set_name(named.username.value)
target.disabled = true
lint
2021-03-02 20:06:03 +01:00
"
>
set name
</button>
replace user buzzer with big red button
2021-03-02 20:02:54 +01:00
</label>
</div>
<div id="info" class="admin-only">
init with crummy buzzer & docker setup so much boilerplate :O
2021-01-29 01:20:17 +01:00
<h2>All Players</h2>
show in the UI if a player is disconnected
2021-01-31 00:56:30 +01:00
<ul class="players">
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
<!-- players (see template#player) will be inserted here -->
add user session reclaiming In its current state the implementation should allow a user to resume their session if the websocket connection is reset, for whatever reason. This could be expanded to allow session sharing (multiple agents logging in to the same client), or manual session resume via some sort of password (encode uid & key to some pass-phrase kinda thing, or QR code).
2021-01-31 00:19:35 +01:00
</ul>
init with crummy buzzer & docker setup so much boilerplate :O
2021-01-29 01:20:17 +01:00
</div>
replace user buzzer with big red button
2021-03-02 20:02:54 +01:00
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
<div id="buzzbox" class="player-only">
replace user buzzer with big red button
2021-03-02 20:02:54 +01:00
<button id="buzzbutton">
<div class="ready">Press the big red button</div>
<div class="active">BZZZZZ!</div>
</button>
<p>or press <strong id="bkey">{key.name}</strong> to activate buzzer.</p>
<p class="inactive">Please focus the window to allow the buzzer to work.</p>
init with crummy buzzer & docker setup so much boilerplate :O
2021-01-29 01:20:17 +01:00
</div>
</body>
add user session reclaiming In its current state the implementation should allow a user to resume their session if the websocket connection is reset, for whatever reason. This could be expanded to allow session sharing (multiple agents logging in to the same client), or manual session resume via some sort of password (encode uid & key to some pass-phrase kinda thing, or QR code).
2021-01-31 00:19:35 +01:00
<template id="player">
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
<li class="player" data-cid="client ID">
<span class="name">player name</span>
<div class="admin-only">
add original version of old crummy monitor
2021-02-02 00:42:02 +01:00
(<span class="points">points</span> pts) (<span class="tokens">tokens</span> tks)
lint
2021-03-02 20:06:03 +01:00
<button
data-onclick="(!named.monitored1.value.length ? named.monitored1 :
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
(!named.monitored2.value.length ? named.monitored2 :
named.monitored3)).value = client.id;
let monitored = [
named.monitored1.value,
named.monitored2.value,
named.monitored3.value,
];
lint
2021-03-02 20:06:03 +01:00
conn.send('control', {targets: monitored, action: 'monitor'})"
>
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
monitor
</button>
<button
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
data-onclick="client.points += named.points.valueAsNumber;
fix broadcasting added points
2021-02-02 21:41:22 +01:00
conn.send('points', {id: client.id, points: client.points})"
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
>
add points
</button>
<button
admin: split monitor list in 3, add sending text selection to monitor
2021-02-24 23:52:33 +01:00
data-onclick="client.tokens += named.tokens.valueAsNumber;
fix broadcasting added points
2021-02-02 21:41:22 +01:00
conn.send('tokens', {id: client.id, tokens: client.tokens})"
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
>
add tokens
</button>
lint
2021-03-02 20:06:03 +01:00
<select
name="sound"
data-onchange="
add buzz sounds
2021-02-25 22:54:56 +01:00
conn.send('control', {action: 'sound', client_id: client.id, sound: target.value})
lint
2021-03-02 20:06:03 +01:00
"
>
add buzz sounds
2021-02-25 22:54:56 +01:00
<option value="">-</option>
<option value="bark">bark</option>
<option value="chirp">chirp</option>
<option value="meow">meow</option>
<option value="moo">moo</option>
<option value="quack">quack</option>
<option value="ribbit">ribbit</option>
</select>
add support for setting points, tokens, and broadcasting control msgs Control messages are messages that are broadcast to all clients and have no clearly defined content. The idea is that this can be used to control a monitor without having to keep adding support for specific commands on the protocol layer. This also changes some of the existing messages and adds another ridiculous convenience layer to our HTML/JS templating: data-eval. We should probably just bite the bullet and use some reactive framework.
2021-02-01 23:07:49 +01:00
</div>
</li>
add user session reclaiming In its current state the implementation should allow a user to resume their session if the websocket connection is reset, for whatever reason. This could be expanded to allow session sharing (multiple agents logging in to the same client), or manual session resume via some sort of password (encode uid & key to some pass-phrase kinda thing, or QR code).
2021-01-31 00:19:35 +01:00
</template>
init with crummy buzzer & docker setup so much boilerplate :O
2021-01-29 01:20:17 +01:00
<script type="module" src="./buzzer.js"></script>
Reference in a new issue Copy permalink