Skip to content
This repository has been archived by the owner on Apr 5, 2019. It is now read-only.

The term "Limbo" is not widely understood #206

Open
JonTheNiceGuy opened this issue Oct 20, 2013 · 4 comments
Open

The term "Limbo" is not widely understood #206

JonTheNiceGuy opened this issue Oct 20, 2013 · 4 comments
Labels

Comments

@JonTheNiceGuy
Copy link
Member

...

@NotBobTheBuilder
Copy link
Member

Perhaps we should refer to talks as 'proposed' or 'scheduled'

@jgbreezer
Copy link

I happen to think that "Limbo" is quite a good word for what it is,
actually, as a short snappy way of describing it; but I can understand that
it might be ambiguous what aspects of limbo it implies for a talk (how much
"in no-mans land" between life and death is it), and some folk (especially
non-English first language) folk might not be so aware of what the word
means.

Unallocated, unfixed are the first words that spring to mind to replace
"limbo" but I'm not sure they're the best (if displayed in the same
position for those talks as the room/time are for others that are known,
which would help users identify what its talking about). Maybe a big fat
question mark in each place would be clear that its unclear (what
location/time its at)?

Or a timer? Just thought it could say "HH hrs MM mins to vote" (HH:MM
could be confused with mins/secs or hrs/mins unless includes seconds).

On a related note: do we show the "lock" period (or time-til) on the UI
anywhere (ie. usually like 15mins, before a talk is due to start).

On 20 October 2013 13:13, Jack Wearden [email protected] wrote:

Perhaps we should refer to talks as 'proposed' or 'scheduled'


Reply to this email directly or view it on GitHubhttps://github.com//issues/206#issuecomment-26671870
.

@JonTheNiceGuy
Copy link
Member Author

I think maybe we should shade the talks to show when they've been fixed in the UI? I also like the idea of having a timer, but I don't know how scalable that would be. I guess it only needs to be on the slot which is due to be scheduled? I don't know where the system would get that count down from though...

@jgbreezer
Copy link

Well a static timer goes out of date fairly fast, but if we javascript it
(so that its not broken for non-js of course) then that could work for a
while; or specify the time instead of countdown, which never goes out of
date. Are you worried about the db requests to fetch the time each event
gets fixed, I presume you weren't thinking each page would refresh itself
every minute to update the timer on all events shown. Maybe I'm not
thinking about the same sort of timer (relative outsider to CFM again
nowadays, though I've been more involved successively with each release -
by 2020 I'll own the project :) ).

On 21 October 2013 10:49, JonTheNiceGuy [email protected] wrote:

I think maybe we should shade the talks to show when they've been fixed in
the UI? I also like the idea of having a timer, but I don't know how
scalable that would be. I guess it only needs to be on the slot which is
due to be scheduled? I don't know where the system would get that count
down from though...


Reply to this email directly or view it on GitHubhttps://github.com//issues/206#issuecomment-26704382
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants