- Home
- Pattern Languages
- Liberating Voices (English)
- Liberating Voices (other languages)
- Liberating Voices (Arabic)
- Liberating Voices (Chinese)
- Liberating Voices (French)
- Liberating Voices (German)
- Liberating Voices (Greek)
- Liberating Voices (Hebrew)
- Liberating Voices (Italian)
- Liberating Voices (Korean)
- Liberating Voices (Portuguese)
- Liberating Voices (Russian)
- Liberating Voices (Serbian)
- Liberating Voices (Spanish)
- Liberating Voices (Swahili)
- LIBERATING VOICES (VIETNAMESE)
- Civic Ignorance / Anti-Patterns (English)
- Other
- Projects
- Community
- Digital Resources
- News
- About
- Contact
Wednesday Nov 27
Submitted by elemunjeli on Thu, 2012-11-29 21:04
Still working on the program logic; trying to make an algorithm out of RROO. I'm looking at this point how to merge the existing motion data table into the concept of a motion state in my own design. Three things need to happen this week: put the buttons in for the actual motions available to members (in the demos, I've had that messed up with several options attributed to the chair- in reality the chair has only three states); begin a rewrite of the polling code which is having network collisions with more than four users logged in at a time; write the code to grant and forfeit the floor.
One thing I decided this week was that the buttons would be visible only if they're available, not dimmed to say unavailable- unavailable buttons will be completely invisible. This is a UI choice to keep people from complaining about wanting to use subsidiary motions that are not available in RROO and also to maintain cardinality to decision making: if there are too many options visible people will get confused. I don't want users to have to scan an irregular list with some options on and others off.