Website Development - Philosophy and Themes
From Digital Lyceum Wiki
Contents |
Over-arching flows
new event: user logs in > user is brought back to index > user presses event create button > user enters in required event information > event is created, has static link.
new user: user clicks new user link > brought to registration page > fills out required information > confirms registration via email > user ends on page they started on
user enters event: user clicks link to event > enters as not authenticated > user tries to interact, gets prompted to login or stay anon (or should we at least ask for email address that remains anon?).
starting event: presenter authenticates to site > navs to event site > presses big red button to start the show > server processes request and starts jobs.
ending event: presenter presses big red end button > server responds and closes live feeds, switches views.
Summary Notes
I don't think we'll have all this functionality by NMC, but i think we can have most of the active event stuff working fairly well, the user create stuff and archive features would have to come later, but we've already discussed this.
As far as a language to start writing this in, it still to me could go either way. Really i think we need to start considering whether we actually can use flex. Since the flash player isn't open source, can we consider something we write that requires the flash player open source? i suppose it doesn't matter as long as our source is open. and the tools to use that source could be whatever.....
anyway, i don't really have a feeling either way as to language. personally i know php + js etc. really well, but i'm clueless right now with flex (though i'm sure i could learn quickly enough). i think that flex has a lot more potential/ability to deal with a lot of the video complexity that we want to work with, and because cyle and john have a lot more experience working with it, it could be a better choice, but i'd rather leave that choice to them.
Feedback
Question Tool reflections (from MR Symp)
- Only vote up, not down
- Integrated collapsible chat (so user can save space). The chat in the QT is anticipated to be very focused on the question to which the chat is responding, as opposed to the SL chat, which will likely follow diverging discussion threads.
- A way to designate a question as “answered.” As a follow-up… instead of disappearing from the board, preference is to have the question move, change color, and use other signifiers to communicate that it has been answered. The chat should continue to be open, however, so that the audience can communicate their opinions on whether or not the question was truly answered, etc.
- The function of the QT will be the starting point for the overall design of the DL Event pages, as opposed to being ‘embedded’ which leads to many problems.
