Coweb Triage Design Discussion
This page is intended to track our design discussions around a cooperative daily scrum meeting app.
- Scrum master (SM)
- Current speaker (CS)
- Other attendees
All users have the app loaded in the web browser. All users are in touch with audio and/or video in addition to using the app.
The SM determines the meeting length in minutes. The SM shares the unique meeting link representing this configuration with the other team members.
Any user may see the attendance list at any time. The list is always visible to the SM for ease of selecting users.
The SM starts the meeting by triggering the overall meeting countdown clock. This countdown starts at the preconfigured time. It continues down to zero and then warns the time for the meeting has expired. It continues past zero to show how much extra time the meeting has taken.
The SM selects an attendee to give status, the current speaker. A speaker clock starts counting down the time allotted for that user's status, initialized as (total time remaining / number of users left to speak). It continues down to zero and then warns the time for the meeting has expired. It continues past zero to show how much extra time the speaker has taken.
The SM may grant the speaker extra time in minute intervals. When invoked, the speaker clock adds 1 minute to the speaker's remaining time. If the remaining time is negative, it resets to exactly 1 minute. The speaker clock continues running through the reset.
The SM may appoint another attendee as the current speaker at any time. When this occurs, the app notes the current time remaining (positive or negative) for the current speaker in mm:ss and shows it alongside the user's name. Then the speaker clock resets to the time allotted to the new speaker, computed in the same manner as the first.
The SM stops the overall meeting clock. The meeting clock stops at its current value, but does not reset. The speaker clock clears and the time taken by that speaker is noted next near his/her name as if the SM selected a new speaker. The rest of the UI remains as it was before so no info is lost.
Any user may take notes in a shared real-time notepad during the meeting. The SM is likely to be the primary editor.
The SM takes notes on a non-cooperative wiki during the meeting. The wiki page appears in an iframe in the app. The SM configures the wiki page URL via the same mechanism as the meeting duration.
- Firefox, Safari, and Chrome support
- Attendee list - who is in the application, coweb-enabled
- Clock - total time and current speaker's time, coweb-enabled
- Controls - timer start, timer restart, next speaker, etc, coweb-enabled
- Notification - remind or indicate when current speaker's time is up, coweb-enabled
- iFrame - pointing to a url-parameter-specified page, not coweb-enabled
- Use dojox.mobile for both desktop and mobile, with footprint-based UIs
Get to these over time:
- iOS, Android table form-factor support
- IE support
- Replace iFrame stand-in with coweb-enabled Rich Text Editor (reusable widget, see this discussion)
- Persistence of notes in rich text editor
- Hotkeys for functions
- Access controls. It doesn't matter if other users can perform the same actions as the scrum master. (We're all consenting adults.)
- Minimal new server pre-reqs
- Minimal framework changes
- Minimal new requirements for apps (e.g., avoid extra API calls)
- Minimal new requirements for users (e.g., avoid save button)
- Isolated widgets (e.g. attendee list) to be reused in other future apps
- Attendee List: attendance API
- Clock: Local incrementation via timeout
- Conrols: Simple coweb-enabled UI elements
- Notification: We can do some clean-looking UI magic with dojo.fx or dojo.animate to flash the clock div, sync when this happens.
- iFrame: use JS, parse url parameter, direct iFrame accordingly. All local.
- Dojox.mobile: use it for everything
- Use Coweb attendance API
- Write our own widget with reusability in mind
- Initiate control via sync
- Then, increment locally based on a timeout
- Because of timeout discrepancies between browsers, check against Date object to mandate correct timing.
- Dojo.animate (or similar) a div, probably the clock container, when a speaker's time is up
- Should we notify only the speaker in this manner? All other attendees will still see the clock run out, do they need a big flashing div as well?
- Build entire app off Dojo 1.7's dojox.mobile
- How do we include cross-domain before Dojo cuts a 1.7 release?
The scrum master may use a url parameter, defaulted to a specific value, to control the meeting length in minutes.
http://someurl.com/coscrum/index.html?length=10The scrum master starts the meeting by triggering the overall meeting countdown clock by clicking the START button next to total time clock. This clock begins, but no speaker clock starts because no speaker has been chosen.
PJP: The Start button should probably say Stop after this step.
The scrum master selects a new speaker by clicking or tapping on any name in the attendee list. That name will then be a) formatted differently than other list elements and b) fill in the header text above right view. Note that the speaker clock has begun, and the speaker time next to "Dan Gisolfi's" name begins counting.
PJP: The clock next to the speaker doesn't have to count up if that's difficult. It can update to show the total time taken when a new speaker is selected instead if that's easier.
As the current speaker's clock approaches 0:00, the scrum master adds one minute to his allotted time, causing two events to occur: 1) the current speaker's clock is incremented by one minute and 2) a notification is overlaid over the "+1:00" button to indicate how many minutes have been added thus far to this speaker.
PJP: I like the minutes added warning. Doesn't have to be a fancy overlay though if it's tough.
The scrum master does nothing more than click on a new name to instantly select a new speaker. The speaker's clock resets.
PJP: Missing?
###Timing
The current algorithm to divide the remaining meeting time by the number of users is confusing and doesn't work from a UI standpoint. Instead, see this gist for the actual timing implementation used. Note that it's in Python that we ported to raw JS.
###Invite List
Not all users will be present in the meeting via a computer. For example, sometimes a user may only call in, but their presence still needs to be calculated in the timing calculations. Thus, a new system has been implemented using an optional url parameter pointing to a server-side JSON invite list, that populates the AttendeeList with disabled, expected users, enabling these as users join. Further, to solve the problem of phone-only users, a moderator may double click on any user to activate them, regardless of whether they actually join the session via a browser.
###Layout
The aforementioned proposed layouts introduced some design conflicts in terms of usability and visual presentation. Thus far, we've settled on the following revisions in terms of UI:
- User clock only at the top of the center View, the total clock down below the AttendeeList
- Highlight the local user
- Sync the selection of a user in the AttendeeList
- No Start/Stop button, simply click on a user to start, then a STOP button will appear.
The following screenshot captures the current application design state as of June 7, 2011: