Meta-POD meeting area, using POD 0.0.1/0.0.2/0.1, 8/4-12/7/2003:
(Click here for documents)
| subj | author | msgtext | in_reply_to | when_posted | num_replies | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| New Document: "orig glossary" | brendan | This is the original copy of a terminology glossary that Todd wrote a little bit back | 0 | 2003-08-04 19:43:26 | 10 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Note on stability | brendan | This meta-pod discussion/collaboration forum is separated from the development code, so it'll be somewhat more stable. There should *never* be problems because I'm working on the code -- if you find any, post in here or email me immediately! (brendano@stanford.edu)
| 0 | 2003-08-04 19:46:11 | 1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 1 disco | brendan | There should be one discussion per meeting area, but many documents per meeting area. By this I mean, all of the meeting area's discussion should appear as one long message list in the discussion viewer pane, but can go over many different documents. | 0 | 2003-08-04 20:19:08 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| heading of preface | todd | I think we should replace "Creator Remarks" with the title of the document as the header of the preface. | 1 | 2003-08-04 21:53:47 | 8 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Numbers and brackets | todd | I think the numbers should appear in headings and the document header outside of the title brackets, with a space separating them e.g.:
"1 [orig glossary]" and "2.3.2 [John's revision]". Todd | 1 | 2003-08-04 21:57:23 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| no brackets or numbers in messages without refs | todd | For threads like this one that do not refer to a document, I think the brackets should not appear (nor numbers, obviously, since they would refer to documents).
Todd | 2 | 2003-08-04 21:59:37 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| index in date view | todd | When viewing by date, I think it's best to show the document reference for each message, in linear (non-indented) format | 0 | 2003-08-04 22:03:59 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| notices in document index | todd | When in the document index, if you click on "Insert a comment" it currently does nothing. It should either do the same thing as "Compose New Message" in the message index frame (that's what I would recommend), or give a notice to select a document first (as done for "Revise" in this view).
Todd | 0 | 2003-08-04 22:07:44 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Where are the dots | todd | I miss the Craigslist dots ("..") that formerly indented headers in the message index. Can we have them back? :)
Todd | 4 | 2003-08-04 22:09:53 | 6 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| on second thought | todd | Instead of getting rid of "Creator remarks" altogether, how about if we put that next to the title, e.g. "1 [orig glossary] creator remarks" (with "creator remarks" in a smaller, distinct font).
Todd | 4 | 2003-08-04 22:12:55 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Ah, now I see them! | todd | Hmmm, they disappeared in subject view. I thought that was what we were going to call what is now labeled "threaded". (?) I'd prefer to get rid of the current "subject" view, replace "threaded" with "subject" (but with the format of "threaded"), and add "location" view.
Todd | 9 | 2003-08-04 22:15:35 | 5 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| also | todd | I think the compose box needs a "cancel" button for when you think better of it midway through writing.
Todd | 11 | 2003-08-04 22:21:56 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Digest ideas | brendan | So we're getting way too many email notifications as it stands right now. What sort of message digest options can we implement? Right now I'm thinking of daily summaries such as "3 new messages in ___ meeting area, 1 new message in ___ meeting area". This could be extended for monthly or whatever intervals. | 0 | 2003-08-04 22:23:26 | 5 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| idea about email integration | todd | As an option, maybe we could offer users the choice of getting notified whenever new activity occurs in the meeting area for which they choose email notification, but just say something like "At least one new message has been posted today to Todd 0 | 2003-08-04 22:26:13 | 6
| sounds good. | brendan | Sounds fine. Would the Location setting preserve threaded-ness in the display? I think it makes sense to do so. The date and author settings would destroy the threaded structure, so I'd imagine they might be tricky to use... do we have any way to solve this? | 11 | 2003-08-04 22:26:41 | 1
| program header | todd | I think that instead of just "Meeting Area" the page title should be something like "POD: version 0.01 - Meeting Area". Definitely the release number should be visible somewhere.
| Todd 0 | 2003-08-04 22:29:58 | 0
| no subject | todd | maybe a hybrid of this idea and mine (see "idea about email integration" message).
| Todd 13 | 2003-08-04 22:36:07 | 4
| "Re: no subject" | todd | If a user doesn't type a subject in a message, but it responds to another message, I think the subject should default to "Re: | Todd 17 | 2003-08-04 22:37:29 | 3
| see my earlier message | todd | Brendan, we had an exchange about this on July 4. I'll try to pull together those more contentful messages into a document tomorrow so we can refer to them. Not promising that will address your question, but I'd like to go back and look at that before responding.
| Todd 15 | 2003-08-04 22:41:03 | 0
| automatic reload of page on posting | todd | Brendan, you may already be doing this, but I think it would be useful if the Java script simply reloads the meeting area page automatically for a user who posts a message, at the moment they hit "post this message", thus reflecting both their own message in the discussion viewer and also any activity in the meantime.
| 0 | 2003-08-04 22:43:51 | 1
| sign-offs | todd | One nice feature of chat rooms is the "Beth has signed off" notification. I think that would be good to implement in the realtime activity window we talked about today. | 0 | 2003-08-04 22:47:59 | 0
| missing unseen highlights | todd | I'm noticing that it's more difficult to follow the discussion when there is no unseen/unread or "new" indicator. This was addressed at length in our earlier exchange. I'm waiting to repost so I can do it from Evolution which will make it easier to copy over. | 0 | 2003-08-04 22:50:23 | 0
| losing selected message on reload | todd | Right now when you reload, it loses the message you had selected. This shouldn't happen, and if it's reloading due to a new message posting (see my earlier message) the new message the user has just posted should be selected and displayed in the message display frame. | 0 | 2003-08-04 22:52:33 | 1
| it's happening | brendan | it also selects your message that you just posted. | 20 | 2003-08-04 23:19:59 | 0
| defaults kill creativity | brendan | On the other hand, by having a blank subject line, the user is forced to think of a short, snappy summary for their post. | 18 | 2003-08-04 23:21:02 | 2
| good point, but... | todd | my feeling is that leaving the subject line blank in the compose window is enough to encourage people to fill it in. "Re:" can be a useful thing.
| Todd 25 | 2003-08-04 23:27:16 | 0
| cut/paste in compose box | todd | I was going to test whether I could paste in a link to another message as a way of connecting threads, but I see I can't paste into this compose window. How hard would that be?
| 14 | 2003-08-04 23:38:34 | 5
| working for me | brendan | It's working for me. Is it a bug with your email/browser setup? If you're using mozilla, it can sometimes do screwy things with cut/paste... | 27 | 2003-08-04 23:48:36 | 4
| I'm using Netscape 7.1 | todd | The compose window has no edit menu associated with it in this browser.
| In clicking in from email to view this message, I get the message okay but it doesn't show its header in context in the message index window. Todd 28 | 2003-08-05 00:14:13 | 3
| forgot to say | todd | I'm in Win '98, on my old home machine.
| In shame, Todd 29 | 2003-08-05 00:16:38 | 0
| long discussions | todd | It's becoming clear to me that for long discussions we're going to have to do something like show the message index with page breaks. | 0 | 2003-08-05 00:19:30 | 4
| preserving thread view on reload | todd | When you reload manually right now the thread view changes to "threaded" automatically insteading of maintaining whatever view (e.g. "date") was in use before. This needs to be changed. I've only tried it with "date".
| Todd 0 | 2003-08-05 00:24:11 | 9
| cookies and passwds | guest | this is pretty cool
| seems cookies should expire when one logs out. i'm logged as guest, but cookie info from an old 'mic' login is in array below: [PHPSESSID] => 3622c1bd3ac77c2108fb7c5993cf9031 also, how would one go about getting their passwd, should they have forgotten it? mic 32 | 2003-08-05 00:56:41 | 8
| cookies/auth fix | brendan | I think I fixed the authentication bug here on pod/meta [thus the 0.0.1-post version now]. The session id cookie is staying for now; it's just the php server side $_SESSION that is modified, with 'auth' deregistered. | 33 | 2003-08-05 01:32:53 | 0
| password options | brendan | For missing passwords, we could implement the following..
| (1) Option to email you your password (2) Those silly "what's your favorite pet" schemes I think #1 is the best bet... which, btw, requires passwords to be stored in cleartext in the DB, which is what's happening right now. This has the disadvantage of me (or the admin) being able to see everyone's passwords. It is possible to instead store a one-way cryptographic hash of the passwords [md5], so it's impossible to see what they are, but it is possible to check if a given string matches a particular hash. This is implemented now, with php's implementation of md5(). I just have the cleartext password entry in the DB for convenience. Tell me when/if the privacy interest should impel me to switch it around. 33 | 2003-08-05 01:37:02 | 6
| oh, it's POD's problem | brendan | yes, that's right, the menubar is totally gone on a new popup. There's a way to fix that somehow.
| Hot keys (ctrl+c,v) still work, I'm just too used to using them I guess :) 29 | 2003-08-05 01:41:56 | 1
| on preserving state | brendan | Right, that should change. A related bug is that right now if you navigate to a message with a copy-and-pasted URL from your email message, "Reload" goes back to that same message because it's just reloading what's in the Location bar of the browser. It's the one-url-per-page assumption of html & webbrowsers, once again.
| I'll check to see if javascript can overload the "reload" button to finagle in our own custom "bring up the marea and go to this message" URL [the sort of URL that's sent in those notification emails] 23 | 2003-08-05 01:52:07 | 0
| passwd encrypt | guest | like you suggested, it seems best to use function to encrypt passwords, the only disadvantage being that you can't decrypt them (to send them out to people who have lost their passwords)
| to which it seems the main solution is to send a confirmed email a new password. which would have to be clear text. so, it could be that all users initially are sent clear text passwords (which may or maynot be stored encrypted on database), and then user can set own encrypted password at their will. i'm guessing this is how it is most usually done. 35 | 2003-08-05 01:57:15 | 5
| half-sync idea | brendan | On the topic of making the system more synchronous when multiple people are on at the same time... What about, when you're logged in, you automatically get per-post notifications? So people with periodic digest notification get all the it's-almost-like-synchronous-communication benefits of per-post email notification while they're logged on: while I was using the system just now, I noticed in my email that mic had posted again.
| This scheme is limited by how frequently your email updates or gets checked, but I figure it's better than nothing. The disadvantage would be if you're accidentally logged in for hours and get way too many notifications you don't want. ANd if you're using something clunky like webmail, rechecking your inbox is damn annoying, makes email less synchronous in general. 0 | 2003-08-05 02:04:46 | 19
| outta synch | mic | yeah, i guess this becomes a major issue when you got multiple folks editing the same file. i haven't checked out the source yet to see if this occurs. nor would i know what to do about it.
| the idea of constantly making new files, with some clever file naming pattern (as opposed to resaving old files) seems like a good one. 39 | 2003-08-05 02:23:04 | 1
| each file is a copy | brendan | Well, right now we're just dodging the issue by assigning each revision to be a separate copy, as opposed to one master copy that everyone collectively edits. So unlike a wiki, this system is confugred right now to support only weighty or large-scale changes -- which is what you want, if you're doing something like making progressively advanced drafts of a document, or if you want to select several drafts to choose from and vote on.
| The locking-a-shared-edited-document problem seems quite annoying to me; some wikis i've looked at seem to have solved it, but it would be not-trivial to implement I think.. look in the files/ directory for the naming scheme; it just uses the mareaowner_id and doc_id of the document in question, to create a unique name in the filesystem. 40 | 2003-08-05 02:58:41 | 0
| I favor encryption asap | todd | I'd say passwords should not be stored in clear text or decryptable - we all reuse passwords and I wouldn't want us to be more vulnerable to breakins etc.
| For forgotten passwords I think the favorite pet scheme may be the most scalable. Another option might be to have an email address that people can send to which will reply automatically with a new password if the email address is registered on the site. The favorite pet thing seems easier, so maybe that should be implemented first. Todd 38 | 2003-08-05 10:00:25 | 4
| Ah, thanks! | todd | I learn something new every day. :) | 36 | 2003-08-05 10:07:28 | 0
| teaching creativity | todd | Another way we can encourage people to fill in subject line is with the sample board in our introduction. Training with examlples works pretty well. | 25 | 2003-08-05 10:16:00 | 0
| email notifications idea | todd | Actually, I think per-post notification would be quite usable if the header showed who sent the message and trimmed POD-specific verbiage to a minumum, with the "Reply-to" field set as the poster's email address. Something like:
| Aug 5 todd@pod.org 4.3K [MArea1]Good point! I suggest this assuming that we can't make the email come directly from the poster's email account, although I'm not sure about that. Then people could choose per-post, periodic, or no notification as options. I don't think this obviates the need for as much synchrony as possible within the html limits. Todd 39 | 2003-08-05 10:25:09 | 16
| clarification | todd | As part of this more email-like per-post notification, I think that option should duplicate the message text in the notification, so people can follow along just by reading email (with a link to the context in the meeting area, of course).
| Also "todd@pod.org" would be a send-only account name. Reply-to would be my regular email address, with the whole board as an option if explicitly chosen by the respondent. Todd 45 | 2003-08-05 10:31:11 | 6
| Already a big improvement | todd | Brendan, I see you added in the username in the subject line for notifications. That helps a lot. | 45 | 2003-08-05 10:43:53 | 6
| heh | brendan | Actually, it was there before... but at the end of the subject line. If you're like me and using a silly old email client like pine in a tiny window, it makes quite a difference :)\t | 47 | 2003-08-05 10:49:57 | 5
| remember, it's damn annoying | brendan | There's a lot of convenience lost with moving to a encrypted-stored scheme. I've always found it quite annoying to enter in those weird random passwords like "aAH6". The maillist manager Mailman [like majordomo but better], on default settings, will email you your passwd in cleartext every month -- which I think is perfect for a world where we all have to memorize dozens of different login/passwords.
| If you really think people want to use it in these security-paranoid situations, I'll go ahead and remove the cleartext field & put in some simple password-resetting schemes... I just considered convenience more important at this stage of development. 42 | 2003-08-05 11:01:48 | 3
| email is the devil incarnate | brendan | Message text should NOT be duplicated in the email notifications. Once we do that, we start degenerating into just-another-mailing-list.
| (1) Email is a bad form of group communication. You lose the expressive power of subject lines since you need to use "Re: " format to indicate threads, but then you lost all decent threading anyways because all mailclients flat-date-sort because email is a stupid hodgepodge of poorly implemented pseudostandards, and then people don't even read it because they don't have time and most people don't filter making it all a mess. (2) POD solves these problems by increasing structure. Dividing messages up by meeting area, tying them to doc structure [which we're not doing in this discussion], etc. etc. If people start following through email, automatically people's style will creep towards non-usefulness: you have to change your subjectlines to be readable without the discussion thread context ("no" is a useful subjectline in threaded mtg area context; it is useless in emails) -- your messages ahve to be longer, have more tedious explanation and summary in them. We talked about this earlier... I read this back in spring, and it's old, but it's really good: http://www.oreilly.com/catalog/pracintgr/chapter/ch03_02.html rightfully bashes email and convinced me to avoid depending on it. Email is a medium that ain't changing; discussion forums can look like whatever we imagine... 46 | 2003-08-05 11:11:43 | 5
| yep! (nm) | todd | I guess I have to type something here. | 48 | 2003-08-05 11:22:11 | 4
| should allow blank messages | todd | Right now it won't let you post a blank. | 51 | 2003-08-05 11:22:41 | 0
| craigslist's solution | brendan | look at their forums for example http://forums.craigslist.org/?forumID=49 a little section symbol is appended to the subject line for a (nm) post.\t | 51 | 2003-08-05 11:27:30 | 2
| I agree, but... | todd | First, I'm not getting the O'Reilly page for some reason. Can you check it and repost?
| I very much agree on the deficiencies of email. But my general philosophy is that we need to be as responsive as possible to how people actually function. To me this means creating a system that integrates with email as much as possible, since that's how most of our userbase relates to the Internet. Used correctly, email can be tremendously useful. I still manage to get by with it most of the time. And I don't think it would destroy what we are doing at all to give people the option to follow things by email when they want to. I myself would appreciate that option. In general, my approach is not to be paternalistic about this. I think we'll brind more people along and accomplish more by letting people be lazy if they want to. We can get on our high horses in the trainings and demos. :) Todd 50 | 2003-08-05 11:35:16 | 4
| I like the appending idea, but... | todd | I think we should avoid symbols that people have to learn. Better to just insert the words "(no text)" imo.
| Todd 53 | 2003-08-05 11:38:55 | 1
| let's talk about this tomorrow | todd | nm | 49 | 2003-08-05 11:43:27 | 2
| "display" -> "sort by" | todd | Instead of "display:" in the discussion index toolbar, I think we should say "sort by:".
| Todd 0 | 2003-08-05 11:51:45 | 0
| an object lesson | todd | In the early shakeout of group sites, the winner was Egroups, which is why Yahoo bought it. I believe that the key to Egroups' success was that, unlike Ecircles and a bunch of other sites, which either tried to get people off of email or were pure listservs, Egroups gave people a lot of options and let them use both. It was crucial in setting up a listserv to be able to tell people "you can read it on the web only", and it was also important for people who didn't "do" message boards that they get email messages.
| Ideally I'd like to be able to use email to quickly read messages as they appear (email being my window on the world for much of the day), and then be able to go to the meeting area and see all the messages nicely structured and archived with doc pointers etc. when I'm ready to focus on it. This would also suit situations like users on the road who want to follow what's going on and have limited time, etc. Todd 54 | 2003-08-05 12:14:30 | 1
| toolbar buttons for message display window | todd | Some ideas:
| back (go back to message previously read) forward previous (go to previous message in index) next 0 | 2003-08-05 12:26:41 | 1
| the link works | brendan | make sure you're copy-and-pasting the whole thing through the ".html" -- it may be wider than the msgviewer pane.
| That's another item on the TODO list... clickable links... 54 | 2003-08-05 13:10:10 | 1
| allowing blank messages. | brendan | 55 | 2003-08-05 13:15:34 | 0
| email is infinitely malleable | brendan | I suggest this assuming that we can't make the email come directly from the poster's email account
| Actually, email protocols have almost no authentication mechanism -- you can make an email say "From: god@god.com" as much as you want, using any smtp server you want, so it appears as if they sent the email. This is what mailing lists do, as well as spammers. There really is no such thing as an email coming directly from someone's account -- the only difference is whether you personally sent the message, or a machine sent it for you. So, yes, it can be done. 45 | 2003-08-05 13:22:54 | 1
| compromise with the devil | brendan | you should get this message via email. | 58 | 2003-08-05 13:27:51 | 0
| once upon a time... | todd | I used to like this "feature" of email addresses. In early versions of Netscape you could type in any email address at all in an email window and it would appear to be coming from that person. I thought things were tighter now, but I guess it's only clients that have tightened up on what they'll allow.
| Todd 62 | 2003-08-05 13:42:52 | 0
| thanks - very useful | todd | I probably left off the "l" at the end. | 60 | 2003-08-05 13:45:53 | 0
| especially for long complex threads | todd | Having "previous" or "message in reply to" or both in the toolbar of message display is crucial, since otherwise it's very hard to find the mesage being replied to. | 59 | 2003-08-05 13:47:34 | 0
| Yogi Bera's dictum | todd | Here's a guiding principle, though obviously it has its limits: (quoting from Yogi the sage)
| When you get to the fork in the road, take it! :) Todd 0 | 2003-08-05 14:05:42 | 0
| New Document: "Design notes" | todd | This was cobbled together from email/POD discussion, notebook scribbles, and face-to-face meetings between Todd Davies and Brendan O' Connor, 8/6/03 | 0 | 2003-08-06 17:42:34 | 4
| New Document: "test doc" | brendan | Here's the new document, everyone | 0 | 2003-08-06 18:00:28 | 0
| New Document: "test2" | brendan | Here's the new document, everyone | 0 | 2003-08-06 18:01:24 | 0
| New Document: "test3" | brendan | Here's the new document, everyone | 0 | 2003-08-06 18:01:48 | 0
| New Document: "Message digests" | brendan | On what message digests & summaries should look like. | 0 | 2003-08-07 02:51:39 | 6
| meta: shorter documents | brendan | So I posted this as a small design idea. It's more of a wiki-style thing to elevate something like that to the status of a Document, but I thought I'd try it and see how it feels in the system... that as message text would be better, I feel. | 73 | 2003-08-07 02:53:22 | 4
| test msg | brendan | message text | 0 | 2003-08-07 03:23:35 | 0
| thanks for straightening this out (nm) | todd | message text | 69 | 2003-08-07 09:01:48 | 0
| I like this | todd | Yeah, let's go with this as the digest option. I'd favor including the time of day as well, and I like the more verbose version. Originator of a meeting area should be included for those, I believe. Also, I would href the subjects so the message doesn't include a bunch of clear text URLs.
| Todd 73 | 2003-08-07 09:12:01 | 0
| doc pointer? | todd | Brendan, I don't understand what this is referring to.
| 74 | 2003-08-07 09:14:06 | 3
| page-ing docs | todd | Even on my DSL line at home this document (10 pages) takes a while to load, so I think it makes sense to break these up into pages for loading. Otherwise it's hard to move back and forth between documents. | 69 | 2003-08-07 09:21:06 | 1
| integrating read/unread with email | todd | Can the "message read" send-back from a user's email client be passed to POD so it is equivalent to them having clicked on the message in the MA?
| 31 | 2003-08-07 09:35:22 | 2
| on second thought | todd | Once a document is loaded it *is* nice to be able to scroll all the way through it. So maybe the default should be to load one page only, but have a button below the preface for "View full document" so the user can select this when a document is going to be looked at extensively.
| 80 | 2003-08-07 10:44:49 | 1
| new proposeddiscussion index toolbar | todd | How about this?
| Post comment Sort by: subject date doc-loc (collapse) "Doc-loc" is a term we will need to define, but should be intuitive. It sorts by document and location within documents. The doc-loc for a comment is the place where it is inserted within or globally attached to a document. I'm liking the term "comment" as opposed to "message" and think we should standardize on that, emphasizing the deliberative and group aspects of this. I'll propose language specifics in a revised glossary hopefully soon. I don't think we need sort by author in the toolbar. One forum I saw had a feature when you click on the user's profile which gave a link to all the comments by that person. You could see the list, select one and then it would display in context. Todd 69 | 2003-08-07 11:31:58 | 0
| oops - posted in wrong place | todd | I should have posted this below under the design notes. I'll copy it.
| Todd 81 | 2003-08-07 11:33:49 | 0
| on second thought | todd | Once a document is loaded it *is* nice to be able to scroll all the way through it. So maybe the default should be to load one page only, but have a button below the preface for "View full document" so the user can select this when a document is going to be looked at extensively. | 79 | 2003-08-07 11:34:33 | 0
| proposed dis index toolbar (repost) | todd | I should have added this at the relevant place. Here goes:
| How about this? Post comment Sort by: subject date doc-loc (collapse) "Doc-loc" is a term we will need to define, but should be intuitive. It sorts by document and location within documents. The doc-loc for a comment is the place where it is inserted within or globally attached to a document. I'm liking the term "comment" as opposed to "message" and think we should standardize on that, emphasizing the deliberative and group aspects of this. I'll propose language specifics in a revised glossary hopefully soon. I don't think we need sort by author in the toolbar. One forum I saw had a feature when you click on the user's profile which gave a link to all the comments by that person. You could see the list, select one and then it would display in context. Todd 0 | 2003-08-07 11:37:03 | 6
| not quite working yet | todd | I see comment display in the doc is not working at the moment.
| Also, there were no insertion spaces available at the ends of lines and at the ends of paragraphs - that should be corrected. Todd 85 | 2003-08-07 11:39:31 | 3
| New Document: "new document" | brendan | Here's the new document, everyone | 0 | 2003-08-07 12:50:15 | 0
| after 1st asdf | brendan | message text | 0 | 2003-08-07 13:00:30 | 0
| half fixed | brendan | Comment display is fixed.
| Enabling newlines instead of just spaces to be commentable, however, is *very* tricky with how the internal format is designed right now. This is because it's not just a matter of flagging an area in the html to be editable -- in that flag, you also have to embed information as to where in the internal document the docref will appear -- then you have to be able to insert it correctly. [i'm talking about th text one sees from "see raw docrefd text"] Absolute positioning in the file fails, as well, because the embedded docrefs in the docrefd format take up space. So right now it's implemented with tokenizing the docrefd text, inserting html docrefs, then putting in the magic clickable spaces inbetween each token. The problem with enabling clickable newlines is that you have to remember which delimiter was used to break up a particular pair ot tokens, because you have to output the appropriate html clickable spot depending on whether it was a newline or a space that broke them up. I'm trying to figure out how to make the parser remember which was used.. I'll try to work it out soon... otherwise, there's lots of other things to fix at the moment. 86 | 2003-08-07 13:09:02 | 2
| making a comment on the medium | brendan | I was unsure whether to post this sample message summary format as a message or as a document. So I tried doing it as a document, but I'm thinking that something small like this should be more like a message, perhaps. | 78 | 2003-08-07 13:10:30 | 2
| autoscrolling | brendan | I implented autoscrolling, so that the discussion index should zoom to the correct message, when one is selected from the document viewer or otherwise. Same goes for the document viewer. Tell me if you notice anything. | 0 | 2003-08-07 13:30:45 | 1
| ah, I see | todd | I agree in this case, though if it were part of a larger document it might make more sense to put it in the doxbox. | 90 | 2003-08-07 13:57:31 | 0
| okay, I see | todd | I didn't realize the difficulties.
| I like the term "magic spaces" a lot. :) Todd 89 | 2003-08-07 14:02:49 | 0
| cool! | todd | 91 | 2003-08-07 14:04:28 | 0
| unread messages | brendan | They seem to be working now working here in the meta area -- boldfaced subject lines indicate it's unread.
| Should the date on the message index header also be bolded? Should the entire header be colorized? 0 | 2003-08-07 17:10:01 | 5
| looks good | todd | I would bold/unbold all the fields in read/unread comments.
| Todd 95 | 2003-08-07 17:45:41 | 3
| on second thought | todd | I see that my own message gets unbolded as I post it, which makes sense, but in that case I think it's okay to bold just the subject or just the subject and date, whatever you prefer.
| Todd 96 | 2003-08-07 17:48:25 | 0
| an additional suggestion | todd | I'd recommend boldfacing an unseen document reference as well, since someone might read the comment via email or by clicking on the subject in the discussion index without looking at the comment in its doc-loc. | 96 | 2003-08-07 18:10:08 | 0
| clarification | todd | >>I would bold/unbold all the fields in read/unread comments.
| "read/unread" should be "unread/read" in the above sentence. 96 | 2003-08-07 18:11:35 | 0
| more stuff for compose window | todd | There obviously needs to be more header info provided in the compose window (and also in the comment display window), including:
| document reference that will appear (e.g. this message, since I hit "Compose new message" to post it with "Design notes" in the doc viewer, should have above it something like Commenting on: 2. [Design notes] (general comment) where "general comment" might be replaced with "inserted comment" if I were using magic spaces. also in the header should be In reply to: if the message is a reply. Todd 0 | 2003-08-07 18:21:49 | 0
| colors for highlighting | todd | Do you have strong thoughts on this, Brendan?
| I prefer green for doc-refs and magic spaces yellow for subject lines pink for warnings and special instructions and would like to see us switch to that scheme for now, but am open to being overruled by user testing or surveys. Todd 0 | 2003-08-07 18:32:51 | 3
| as I play with this more | todd | I see that the discussion index gets loaded a lot less frequently than the comment display or document frames do, so I'd say it's okay to keep the dis index un-paged. | 31 | 2003-08-07 18:36:26 | 0
| here it is | brendan | message text | 101 | 2003-08-07 20:53:05 | 0
| here it is (repost) | brendan | Here it is with your suggested colors. I'm ambivalent as to which scheme I like better. One negative aspect of this scheme is that the green of a highlghted in-doc docref is a little confusing with the green of highlighted magic spaces. | 101 | 2003-08-07 20:56:14 | 1
| green versus green | todd | Yeah, I thought of that too. It seems okay to me to view each space as provisionally green when in edit mode, though. Do you think some other color would be better? It wouldn't need to be a highlight color.
| Todd 104 | 2003-08-08 00:07:04 | 0
| following-up | todd | message text | 56 | 2003-08-08 00:35:41 | 1
| follow-up to following up | todd | Well, first, I just hit return at the end of the subject line and found that that posted my message. Probably shouldn't do that, but rather I think return at that point should put the cursor in the compose text box.
| Anyway, I'm just recording for this MA the fact that Brendan and I discussed encryption and decided to implement encrypted passwords, with the procedure for forgotten passwords beging that the user clicks to have a URL for changing the password sent to their email account. The password itself should not be changed until the account holder completes the process, since anyone can request such a message even if they are not the account holder. 106 | 2003-08-08 00:39:47 | 0
| toolbars/banners should be in fixed frames | todd | I think that, as with the document viewer, the discussion viewer's toolbar banners should also be constantly visible above the variable-sized content frames; i.e. the discussion index toolbar should be in a fixed frame above the index itself, and the comment display banner (including comment header info and buttons for previous, next, backward, forward, reply to all, and reply to poster) should be in a fixed frame above the comment text. These should be vertically short, part of the expandable window in each case, and lightly marked off with color backgrounds or somthing rather than a horizontal frame bar.
| Todd 85 | 2003-08-08 12:46:17 | 0
| doc-loc for general comments | todd | I'd say that general comments referring to a document should attach to the title bar in the preface of the document, rather than a space at the end, so that the document displays at its beginning when a comment referring to the whole document has its doc-ref clicked. | 85 | 2003-08-08 12:51:27 | 0
| New Document: "the TODO" | brendan | A structured TODO list, in wiki form | 0 | 2003-08-08 16:11:38 | 3
| looked at it | todd | Brendan, thanks for posting. FWIW, it's often useful to visually mark items as critical path (C) or side projects (S). A wiki-like document type would be a side project, for example, whereas actions in the actions menu are critical. C items, which need to happen before the first release, are obviously much higher priority. | 110 | 2003-08-08 16:38:01 | 2
| another suggestion | todd | Brendan,
| It might be useful, if only for your private view of the task list, to annotate each task with a time estimate, then keep track of how well calibrated these are by, e.g., recording the actual times spent on the tasks and comparing it to your estimates. That would help both with planning and with learning how to plan more realistically. Todd 111 | 2003-08-08 16:49:45 | 1
| read/unread color change suggestion | todd | I'm finding with the blue background it's hard to see the difference between bold and unbolded comment headers. So I'd suggest maybe changing the color as well as switching between bold and unbold, to make the distinction between read and unread more apparent. Maybe purple for unread and blue for read, in addition to bold/unbold respectively.
| 95 | 2003-08-08 21:01:29 | 0
| changes noted | todd | Brendan, I see the changes you've made (C versus S marking, time estimates). I hope this is helpful for you!
| It can be useful sometimes to see these as limiting too, meaning they check the tendency to try to perfect things. As I see it, we are aiming at version 0.1! Todd 112 | 2003-08-08 21:11:49 | 0
| Yet Another forum system | brendan | This one looks pretty nice: it's got simple functionality, and as a bonus does email subscriptions correctly, with reply-by-email as well. It does teh simple interface thing right, though the flat-date view is probably ultimately limiting... finallly, there seems to be a document commenting system, that allows comments per paragraph. I still like ours better :)
| www.quicktopic.com 0 | 2003-08-10 23:14:36 | 4
| interesting... | todd | It's nice, but a bit cumbersome. We should look closely at whatever features they have that would be good to include. One clear deficiency on Quick Topic is the lack of in-line comment visibility. Also it doesn't look like you can submit edits or revisions. I still prefer having every space available to insert comments.
| We should cite this and Purple Numbers as antecedents of our system. Although I was unaware of both before we started, it's validating to see some similar ideas out there. 115 | 2003-08-11 12:06:38 | 3
| remember another site | todd | Also there was that european decision tool which wraps comments around text - I'll look up the name.
| Todd 116 | 2003-08-11 12:08:25 | 2
| d3e? | brendan | Is this the one? Not sure about the wrapping around text part.
| http://d3e.sourceforge.net/ 117 | 2003-08-11 12:12:50 | 1
| yes, that's it | todd | They really have a lot of architectural features in common with us (see screenshots at http://d3e.sourceforge.net/d3e-screens.html). This one also I didn't see until after our spring design meetings, but if you put this together with the other sites we've talked about it seems there is a general convergence going on, which indicates to me that the problems we are trying to solve have something like natural best solutions to them and there is some evidence that we are finding those solutions.
| Time and user experience will be the real test, though. Todd 118 | 2003-08-11 16:25:54 | 0
| runaway lines need to be cropped | todd | On my browser (Moz 1.2.1) the above URL extends outside the boundary, with the side effect of creating lots of white space next to the window that results in a horizontal scroll bar being added at the bottom of the document window. It would be nice to avoid this by having URLs wrap automatically to the next line instead of extending outside. | 0 | 2003-08-12 14:27:24 | 5
| autoscroll location | todd | Also, right now the document text that gets loaded when I click on a doc-ref begins with the doc-loc for the doc-ref'd comment at the top of the document window. I think it would be better for it to display near the middle of the page, so you could see the surrounding context both above and below. In this case, I was commenting on a URL above the doc-loc, and it would be good to see the URL. | 120 | 2003-08-12 14:30:38 | 2
| email notification for inserted comments | todd | The email message version of inserted comments should display the context surrounding the insertion - I'd say three lines above and below, with a note that the comment was inserted and also giving the doc-ref I think. | 120 | 2003-08-12 14:58:27 | 1
| autoscroll context | brendan | I agree. However, it's an HTML limitation that you can't easily autoscroll a certain position to the center of the page -- I'm not sure how to fix it easily. | 121 | 2003-08-12 16:23:56 | 1
| HTML sucks sometimes :( | todd | 123 | 2003-08-12 17:34:09 | 0
| speaking as a guest, the format is not clear and it is not at all obvious how to use this.... this project has a ways to go in making things more transparent for the average computer user | guest | message text | 122 | 2003-08-13 11:33:00 | 0
| New Document: "article on picking online discussions" | todd | Interesting article from today's SF Chronicle. | 0 | 2003-08-19 11:11:09 | 0
| after 2nd asdf | bshanks | well well then | 0 | 2003-09-05 09:40:48 | 0
| New Document: "Revision of 'test doc'" | bshanks | Here's a new revision | 0 | 2003-09-05 09:41:18 | 0
| views | bshanks | is subject/date/location view implemented yet? b/c if so, i can't find it.
| 11 | 2003-09-05 09:51:44 | 1
| nevermind | bshanks | i found them | 129 | 2003-09-05 10:02:57 | 0
| like it this way | bshanks | i like it this way (as a doc, not a msg)-- this way we could, if we chose, collaboratively edit the proposed daily message summary.
| 90 | 2003-09-05 12:30:47 | 0
| relevant standards | bshanks | i don't quite understand what you mean, but i thought I'd mention some words I've heard; standards which may have to do with this: Xpointer, XPath, Xlink. I believe these are standards for specifying a particular position in a document. Presumably there's some open source software available for doing stuff in these frameworks.
| 89 | 2003-09-05 12:37:02 | 0
| New Document: "general" | bshanks | This is just to attach general comments to.
| 0 | 2003-09-05 13:13:57 | 13
| first thoughts | bshanks | The system's neat and looks like a good way to have document-centered discussions, along with polls and votes. I am especially impressed with the magic spaces; what a great way to insert annotations into a document; and it must have taken some work to program. I like how simple it is to create a new poll or document; somehow although there are other discussion boards with polls, I can't remember seeing one where it is so easy for a normal user to create one.
| As for document-discussion software, I haven't seen so many of those around, but as Todd said, I think a lot have recently been created/are being created. So that whole feature is impressive. As I was browsing through, I tried to think of suggestions; I got quite a few little ones and a few major ones. I guess I'll post them in separate messages. 133 | 2003-09-05 13:39:00 | 0
| general UI | bshanks | I think the UI might still be too complicated for someone not familiar with the web (or with computers at all). I think the Homepage is very concise and easy-looking, and that sort of feel is what you should aim for for the meeting area page. The homepage doesn't have very much on it, and all the things the user can do (the links) are in those awesome colored boxes. So it doesn't feel like there's lots of confusing controls; it feels like there are only two items on the page to think about.
| In the meeting area, however, everything looks rather technical. There are quite a few things to think about: panels, links, scrollers, emboldened words, and pull-down menus. I think this screen needs to be simplified. More specific suggestions to follow. 133 | 2003-09-05 13:46:31 | 3
| thanks | todd | Thanks, Bayle. I'll be interested to see your specific suggestions. Meanwhile, some thoughts:
| Details of the look and feel shouldn't be taken too seriously. There are many things we've discussed that aren't done yet, which should add to the user friendliness in the meeting area (like redundant buttons, clearer directions, etc.). We're mostly focused on functionality and the large-scale look (i.e. split screen with expand options, which I still think is the way to go). Another thing to consider is that we are producing something newer and more complicated than people are used to, and that is, I think necessarily, going to be a little challenging for computer novices especially when we first roll this out. Think about how difficult people found computers, windows, mouses, etc. when they first came out. I think we're aiming to simplify as much as possible and not simpler. Finally, much as I appreciate your design comments and look forward to more, questions about ease of UI for novices can, in my opinion, best be answered through user testing, and I'd rather start out assuming people can do a fair amount and then scale back - I think we'll find the right level more easily that way. I'm amazed that the average person can deal with desktops, e-commerce sites, Yahoo-groups, etc., and there may be a tendency to underestimate what people can do with just a little bit of exposure. All these things were quite difficult for new users, but progress required building them. We may be in a similar situation in our little sphere. Having said this, there are some real challenges in simplifying things here and any specific suggestions you have would be most welcome. Thanks again! Todd 135 | 2003-09-05 14:20:58 | 0
| titles | bshanks | Titles make things feel less technical, I think. One of the good things about the homepage is the big title at the top, with some whitespace below it. I think the meeting area could have a similarly friendly title. The text ""Design discussion" meeting area" could be in some sort of title font, and there could be a little bit of whitespace below it. I realize that this cuts into valuable real estate, so don't make it too much bigger, I guess.
| Also, I think the 3 panes (frames?) should have their own titles. I.e. the document pane could have the document title (it already says the document name in the pull-down box, but that's not title-sized), the message index pane could have a "message index" title, and the message pane could be titled "message display" (for that one i think just having the subject heading might not be enough). I think it might be cool if the pane titles had a different background color (I mean, the same color for the title of all three panes), like the boxes on the homepage. Not sure until I see that, though. I feel like having a few titles would reduce the "what is all this stuff?" feeling. Also, it would be great if the three panes had dotted line borders, like the cool boxes on the front page. 135 | 2003-09-05 14:27:47 | 1
| New Document: "new document" | bshanks | (Potential) Bugs | 0 | 2003-09-05 14:30:38 | 0
| New Document: "(Potential) Bugs" | bshanks | 0 | 2003-09-05 14:31:26 | 9
| subject heading and return | bshanks | If I type in a subject in the Compose box (in the Subject: field), and then hit enter, the subject that i just typed in just disappears.
| 133 | 2003-09-05 14:33:52 | 2
| New Document: "feature requests" | bshanks | 0 | 2003-09-05 14:34:39 | 19
| document-less discussion? | bshanks | The only way I could find to start a new subject area (or even a new thread) that isn't under any of the existing documents is to create an empty document for that purpose. Groups will probably often have comments that don't belong under any specific document.
| One idea is to talk about "topics" rather than "documents" -- i.e. "All documents in this meeting area" becomes "All topics in this meeting area", and you can "create a new topic" as well as "compose a new document". 133 | 2003-09-05 14:38:27 | 2
| Actually, you can hit "compose new message" | todd | the name for which will probably change, in the comments index toolbar.
| Todd 142 | 2003-09-05 14:43:36 | 0
| topic idea is in process | todd | Although it's not in the design doc, we're planning a "create discussion item" action for the purposes you've outlined.
| Todd 142 | 2003-09-05 14:45:00 | 0
| I agree | todd | with most of what you've said here, though I'm not sure each pane needs a title. Clearer titles and demarcaters are very good in general, though. These are among the niceties that should make the meeting area UI much easier to follow. | 137 | 2003-09-05 14:48:36 | 0
| which browser? | brendan | Which browser version are you using? Sounds like a javascript inconsistency to me.. Normally the | It seems to be working on IE 6 and Moz 1.0+ 140 | 2003-09-05 17:38:46 | 1
| re: subject heading and return | bshanks | hmm. I'm using Mozilla 1.0.0. I wonder what it is.
| The subject heading that i type (which disappears) does appear in the debugging info at the bottom after i press enter. (but then if i type something else in the subject line and press enter, that appears instead in the debugging info -- it's not as if it's capturing multiple lines. 146 | 2003-09-05 20:49:22 | 0
| reply to email | bshanks | i am in favor of allowing users to reply to email notifications.
| it's true that giving users some ability to interact with the discussion mainly through email will transplant some email mores and norms into this environment. But I think it's worth it. Otherwise, the software might not "take" for many groups, because there will be some people who would rather just use their email and who won't be enthusiastic about POD. Also, philosophically, I prefer to empower the users as much as possible -- rarely will I agree that some feature should not be implemented for social reasons (although I do think some features should be buried in some way to discourage use). 141 | 2003-09-05 21:01:26 | 6
| link to subdocuments | bshanks | it would be nice for there to be direct link(s) to any subdocuments when you are viewing a document (I mean, in the document pane; I guess this already exists in the message index pane).
| 141 | 2003-09-05 21:04:46 | 0
| search | bshanks | feature req: full-text search of a meeting area
| 141 | 2003-09-05 21:06:47 | 2
| links in sbj index | bshanks | i feel like i just wrote this, but i can't find that message now so maybe i imagined it.
| It would be nice if you could copy a link from the message index, and that link, if pasted into a new browser, would take you to POD with that message in the message viewer. I.e. if the links in the message index could be sent in an email or something like that. 141 | 2003-09-05 21:15:21 | 0
| option not to get own msgs | bshanks | feature request: an option (turned off by default) that would filter out messages that I post from being emailed to me as notifications.
| (the reason I want it turned off by default is so people don't get confused as they test out the notification system by posting something and seeing what happens) 141 | 2003-09-05 21:18:12 | 0
| Yeah! I agree completely! | todd | 148 | 2003-09-06 00:16:51 | 0
| too many messages | bshanks | the message index fills up with tons of messages quickly -- just look at how many there are now.
| Besides being slightly cumbersome, I think all that scrolling might intimidate novices. I don't know exactly how to solve this. Maybe split it up so that you can only see the messages for the current document (with a "show all topics" button or something in case you want to see all of them)? And/or, maybe a way for some admin type person to say something like "all messages before such and such a date" should be moved to (somewhere else -- "archives for the month of june"? I dunno). I'm not sure that's the best solution, though... hmmm 141 | 2003-09-06 00:41:58 | 0
| browser's Back arrow | bshanks | I experienced some strange behavior with "back" arrow -- i.e. I selected a document, clicked "revise", then hit "back" and for the first few times nothing seems to happen; eventually I went back to the "All documents in this meeting area" section (i.e. it skipped the intermediate pages that I had gone through on the way forward, such as the meeting area, viewing the document but not revising it yet).
| 139 | 2003-09-06 01:02:47 | 3
| agreed | brendan | The more systems it can interact with, the better...
| One challenge is that it might be harder to deploy email-replyability on new sites. For example, I can't do it at the moment without figuring a bit about how stanford's mail system works... 148 | 2003-09-06 01:04:21 | 4
| hierarchial documents? | bshanks | I feel that hierarchial documents (revisions as subdocuments within documents) might be very confusing to people. As computer people we have lots of exposure to hierarchies, and compared to the other data structures out there we think of them as simple. But the idea of documents "within" other documents may be pretty alien to most people.
| 133 | 2003-09-06 01:06:33 | 1
| yeah, back button is crazy | brendan | The back button is simply bizarre for the meeting area system. mixing both frames and javascript is just a recipe for back-button disaster... | 155 | 2003-09-06 01:08:13 | 2
| portability of email | bshanks | that's true, I tried to send email to a program a few months ago, and while I found an easy way to do it, it was system-dependent.
| On unix, the "fetching the email from the server using POP3 or IMAP" is it's own step and there are separate programs like fetchmail to do it. Then your client need only concern itself with reading the email file. Is it similar on windows? or does your program have to implement POP and IMAP in order to receive mail? 156 | 2003-09-06 01:13:18 | 3
| re: back button | bshanks | he he
| 158 | 2003-09-06 01:14:35 | 0
| SQL | bshanks | just out of curiosity, are the messages stored in an SQL database (seemed like that judging from the debugging info when posting a msg)?
| 0 | 2003-09-06 01:15:52 | 1
| receiving email challenges | brendan | The major problem is, you really need control over your own mail server. POD would need something like "discussion-id-03a4@piece.stanford.edu" to be the Reply-To address. If you want to assign your own email addresses, you need to be running a mail server, like sendmail or postfix. POP and IMAP wouldn't work because there needs to be a server with that discussion-id@ address registered.
| However, setting up a mail server to receive email from the big outside world raises a whole host of ugly email issues. The Stanford firewall probably won't allow it for starters [for good reason since badly configured mail servers get exploited for viruses & spam] and then there's some system Stanford runs to get email sent to a @piece.stanford.edu address, and this system would either conflict or interact weirdly with ours... And finally, there's all these annoyances with email [which is a system that's very old and historically haphazardly developed]: For example, there's zero authentication once you're on email. The "From: brendano@stanford.edu" line can be forged like crazy quite easily; we'd just have to trust that an email appearing to be from me was actually from me. Another possible problem is, if there was a discussion open only to certain participants, only the web interface could enforce that; if the "discussion-id-04ab@..." address got loose, then anyone could post to the meeting area. There could be moderate enforcement by inspecting the "From:" header but that again is vulnerable to a somewhat determined intruder. 159 | 2003-09-06 01:50:20 | 2
| yes, the'yre in SQL | brendan | messages are al lstored in a MySQL db.
| Documents, however, are on the filesystem [the text of them, at least]. 161 | 2003-09-06 01:53:49 | 0
| re: email challenges | bshanks | > The major problem is, you really need control over your own mail server. POD
| > would need something like "discussion-id-03a4@piece.stanford.edu" to be the > Reply-To address. I agree that this would be the best thing. However, if you wanted more portability (which you do, for the reasons you described), you could put such information into the message itself. You know, just have a -------------------------- PLEASE INCLUDE THE NEXT LINE IN YOUR REPLY, AND DO NOT ALTER OR DELETE IT; THIS INFORMATION IS USED BY POD TO POST YOUR REPLY Reply-ID: 2346762 at the top of the message or something. It might be even easier to put it in the subject header and just say "PLEASE DO NOT CHANGE THE SUBJECT HEADER WHEN YOU REPLY". I'm not sure. As for security, I think that would rarely be a problem. Once again, you could eventually put some sort of passcode into the message if you were worried about it. But I don't think you need to include those security features in the 1.0 edition or 0.1 edition or whatever you are testing first. 162 | 2003-09-06 10:50:29 | 1
| in support of novice/advanced | bshanks | >First, in a democratic forum, I'd rather not introduce distinctions
| >between levels of competence in users, since the point of this is to put >everyone on the same level as much as possible. Second, creating such a >distinction sends a signal that the system is hard to learn to use, and I >don't really want it to be or to send that signal, especially since we >don't have much evidence that we need to. My main feeling about levels is >that it is very difficult to guess what people will find hard or easy a >priori, without user testing. i think a "novice/advanced" option is a great way to do things, actually. HyperCard used this, and it seemed to work great there, at least for me. I feel that this feature relieves the tension between making software easy to use for beginners and making it powerful for advanced users, with almost no cost. >First, in a democratic forum, I'd rather not introduce distinctions >between levels of competence in users, since the point of this is to put >everyone on the same level as much as possible. I can see how you'd want to avoid it if you have philosophical issues with different levels (even if the participants are free to move between levels). >Second, creating such a >distinction sends a signal that the system is hard to learn to use, and I >don't really want it to be or to send that signal, especially since we >don't have much evidence that we need to. However, if the system has a lot of options or details on the screen, that sends an even stronger signal that it is hard to use. 0 | 2003-09-06 12:44:36 | 6
| word wrap sbj headers | bshanks | If you word wrapped the message index box, you could conceivably eliminate the horizontal scrollbar there
| 141 | 2003-09-06 12:46:31 | 1
| separate windows options | bshanks | (i think that if you do this at all, it should be a non-default option for advanced users): maybe allow the user to choose to have three separate windows, instead of separate panes.
| 141 | 2003-09-06 12:48:16 | 1
| expand/collapse threads | bshanks | here's another "advanced" feature that I think should be off by default but which may be useful; expand/collapse threads in the msg index window.
| you might be able to get the relevant code off some other open source discussion board or newsgroup archive software. anyhow, this feature would take awhile to implement, I guess, so it may not be worth it for awhile. 141 | 2003-09-06 13:18:24 | 0
| small note on my schedule | bshanks | i gotta go to this "boot camp" thing for my grad program for the next two weeks, so don't be surprised if i suddenly disappear after flooding you with messages for the last two days
| 0 | 2003-09-06 13:23:02 | 0
| expand/collapse mode - reply to Bayle's comment | todd | Here's some discussion of expand/collapse from the design notes - see later discussion in this document too (click on docref).
| This brings up that it would be nice to be able to combine comment insertion in a document with replying to a comment in a thread. Right now inserted comments always initiate a new thread. Todd 0 | 2003-09-06 16:16:53 | 1
| a meta comment | todd | Bayle,
| Thanks for all these suggestions and thoughts. A lot of what you are raising are points we have been working on, so it's good to see some of our intuitions validated. As for what is easy or hard for novices, I'm pushing a wait-and-see philosophy, not wanting to dumb things down before we see what people can handle. I'm wary of those of us who are experienced users or programmers speculating on what newbies can handle. At the moment, we're under some time pressure to get a first version done, so the emphasis has to be on building functionality. We learned over the summer that focusing too much too early on UI details can get in the way of that. So while I'm really happy to have your input and we'll take note of these suggestions, you may find it's a while before they are addressed. There are a lot of things in the Design notes that haven't been implemented yet. You might want to read through them and Brendan's todo list, since they are a better indication of what's coming than the current system is. Todd 165 | 2003-09-06 16:26:56 | 5
| hmmm, looks like... | todd | Copy Link Location applied to a document brings up the whole document index page. I'm not sure how to get the unique URL for each document. | 171 | 2003-09-06 16:29:26 | 2
| true, but then you lose indentation information... | todd | unless you do something like insert vertical space between headers. We'll have to see what the best solution is. | 166 | 2003-09-06 16:33:13 | 0
| disabling "Back" might be best | todd | Brendan raised this suggestion at one point, and it might make the most sense in the meeting area. | 158 | 2003-09-06 16:36:08 | 0
| this is a good discussion | todd | In the long run I'd want to aim for email/meeting area interoperability that is comparable to Yahoo Groups. | 164 | 2003-09-06 16:38:17 | 0
| check out Forte Free Agent | todd | A wonderful newsreader that many people find easy to learn. That's my model for expandable panes.
| 167 | 2003-09-06 16:40:17 | 0
| or, better, for the whole site | todd | That will be an important feature to add - hopefully we can get an open source search tool. | 150 | 2003-09-06 16:43:22 | 1
| maybe, maybe not | todd | I don't think hierarchies are a difficult concept - they are ubiquitous (hierarchical organization charts, etc.). We'll see - it may take some UI friendliness to make it more intuitive, but I wouldn't want us not to implement something this useful because we are afraid that some users *might* not initially understand it. I'd like to find out by implementing and testing it. | 157 | 2003-09-06 16:48:49 | 0
| deep linking IMPLEMENTED | brendan | You're right, "Copy Link Location" fails.
| In the /dev branch I implemented a "Link to this document/message" feature so you can get a URL to copy-and-paste. Some UI tweaks are hard.. but this one was easy! Hurrah. 172 | 2003-09-07 00:39:44 | 1
| loop happened again | bshanks | I was viewing message ID: 164, "re: email challenges - bshanks", and I told my browser to go to http://piece.stanford.edu/pod/meta/marea/?marea_id=1&msg_id=176
| and it got into a loop. btw, when i hit "stop" the loop stops and then if i do something else, or even the same thing, the loop doesn't happen. 139 | 2003-09-07 11:21:21 | 0
| loop again | bshanks | was viewing ID: 177; "or, better, for the whole site - todd". Pasted in http://piece.stanford.edu/pod/meta/marea/?marea_id=1&msg_id=179
| 139 | 2003-09-07 11:25:32 | 3
| loop | bshanks | you know, i think that now it just happens everytime i paste in a message's URL from the notification email.
| 181 | 2003-09-07 11:27:58 | 2
| re: a meta comment | bshanks | that's great; Brendan just asked if I had any comments so I tried to write down anything I thought of as I was using the site. Obviously, as the designers you can pick and choose which ones you want to use or not or when you want to think about certain areas of the program. | 171 | 2003-09-07 11:39:14 | 0
| i see | bshanks | sorry, i had skimmed this and thought the expand/collapse you were suggesting was for showing a whole thread in the message viewer (as opposed to expand/collapse in the msg index)
| 170 | 2003-09-07 11:41:54 | 0
| and they are much appreciated! | todd | Your comments are all very thoughtful and have caused me to think about things, like how to make things clearer for novices. I just don't want Brendan to get overwhelmed with design issues right now, since he has limited programming time available before classes start and we need to prioritize. There's a lot to be added functionally before we put finishing touches on the UI.
| Todd 171 | 2003-09-07 13:00:48 | 0
| great! | todd | good work. | 179 | 2003-09-07 13:03:05 | 0
| New Document: "Revision of 'Design notes'" | todd | Here's a new revision - adding a search link per Bayle's suggestion on the group home page | 0 | 2003-09-07 13:08:29 | 0
| maybe loop = slowness? | brendan | Is the loop just the system being slow? Sometimes when I click on a link [on pod, or else any website] nothing happens for a few seconds, so I just click again and then it works. | 182 | 2003-09-07 13:08:38 | 1
| it's doable | brendan | there's a number of projects out there that should work.
| For example, for message searching, MySQL has a full text indexer built in. I'd have to look in to other options for full-site searches. 177 | 2003-09-07 13:09:49 | 0
| loop != slowness | bshanks | i don't think so. The browser status bar flips between "sending request to" and "transferring data" indefinitely. For normal web pages it only flips between these two states a few times, like once or 10 times. If it was just slow, I think it would stick in either one of these states or the other.
| 188 | 2003-09-07 14:02:27 | 0
| New polling features! | brendan | http://piece.stanford.edu/pod/dev/ has all new polling features!
| 1) Poll creator control: the poll creator now can close the poll early, and leave an informational message when doing so. There's always an informational message when the poll closes, even if automatically. Creator control over poll closing would be more useful for more informal polls without a specified end date [currently all polls must have an end date. this should change] I implemented it actualyl because it makes debugging the informational messages vastly easier. 2) Poll comments -- arbitrary freetext comments with your vote, as we discussed before. Your comment appears both (a) within the poll result view, and (b) as a new message in the forum. I'm not so certain that (b) is a good idea, because that would justify having every single vote generate a message in the forum -- but one of the weaknesses of a deliberative space without polls is that one-message-per-vote clutters everything up! It's also messy if you change your vote multiple times; currently pod just generates yet another new message each time. [the inconsistent subjectlines there are just an anomaly] This poll illustrates the freetext voting: http://piece.stanford.edu/pod/dev/marea/?marea_id=1&obj_id=15&obj_type=poll 0 | 2003-09-08 04:42:06 | 1
| looks good | todd | But I'd vote in favor of each poll needing an end date, allowing changes only through the site owner (rather than the poll creator, for now, until groups can do this through some process), and not having each vote annotation show up as a separate comment in the discussion. If the results are reported continuously this shouldn't be a problem.
| Todd 191 | 2003-09-08 14:12:34 | 0
| New Document: "Polling Method & Decision Rule constraints" | brendan | Here's the first draft of the relationships between which d-rules are allowed for which polling methods for which number of propositions.
| Has to be very precisely specified. 0 | 2003-09-12 03:16:46 | 0
| decision-vote creation mockup | brendan | A kinda-functional mockup for creating a decision vote (a "d-vote"?) is now up!
| http://piece.stanford.edu/pod/dev/marea/newpoll2.php?marea_id=1 it does NOT implement method/d-rule constraints, and the add/remove GUI has to be improved somewhat. 0 | 2003-09-12 03:31:26 | 1
| New Document: "Revision of 'Polling Method & Decision Rule constraints'" | todd | Here's a new revision by Todd | 0 | 2003-09-12 15:57:44 | 6
| good start | todd | The interface for entering propositions and actions is confusing, though - we need to work on that. "Add button" should appear after the proposition, for example, and each action should be able to be separately specified.
| Todd 194 | 2003-09-12 16:00:51 | 0
| Mic and I met | todd | Mic and I met this evening to talk about the OSI proposal. We worked out a basic budget and timeline and I'm going to try to produce a draft by the 22nd, so we have a week or more to revise. I'll post it here.
| Todd 0 | 2003-09-13 00:00:56 | 0
| New Document: "Revision of 'Revision of 'Polling Method & Decision Rule constraints''" | todd | Here's a new revision, correcting the reporting for results when ranking is the method of polling by erasing the "(must win outright...)". Results can simply be presented as the rules dictate, with ties indicated if that''s what happens. | 0 | 2003-09-13 17:26:18 | 0
| 100? | brendan | Should the number of points to allocate be variable? Or is fixed-at-100 good enough? | 0 | 2003-09-15 12:32:27 | 1
| I think we can start with a flat 100 for point allocation, but... | todd | it might be good to make the rating scale variable for "Rate individually". That could also allow the user to choose labels for each number on the rating scale, e.g. "1=strongly agree, 2=mostly agree,..".
| Todd 199 | 2003-09-15 13:54:17 | 0
| d-rule results | brendan | We also need a formalized, coded system of possible decisionmkaing results -- that is, if you apply a d-rule to a given set of votes and propositions, what result do you get? I can envision three:
| 1) WinResult -- one proposition is the unequivocal winner of the vote. 2) TieResult -- two or more propositions are all declared winners. For example, on a chooseone-plurality d-rule, if two propositions are tied for the most number of votes. * Note: we may have to distinguish situations where it is acceptable to have multiple winning propositions, versus times when the people demand only one prop to be the winner. 3) NowinResult -- zero propositions have been accepted. For example, on a chooseone-majority d-rule, if no proposition manages to get a majority. Some decision rules may yield only WinResults (that is, ban undecidability), or some might yield the other outcomes as well. #2 and #3 I'm thinking would lead to some sort of re-vote or else no actions are taken. Only #1 would lead to the actions being executed. Finally: would it be desirable to only support decision schemes that yield one unambiguous result? It becomes quite unclear what to do in these ambiguous situations... 0 | 2003-09-15 17:12:49 | 3
| our way or the highway | todd | For now I think we should only support one winning criterion for each rule, but it doesn't always have to be the same one. For example, in the "average above threshold" rule for rating and point allocation, all above the threshold should be approved. For the rank rules I think winning should require no ties, but you can report all the results (full list).
| Todd 201 | 2003-09-15 17:18:16 | 2
| translating rule results | brendan | by "one winning criterion" you mean, one winning proposition?
| What happens when there is no winning proposition? -- in your example, if there's a tie for a rank rule? or if noone gets a majority? I propose: 1) no actions of any proposition should be taken 2) redo the vote Maybe (2) could be upgraded later on to introduce runoffs or other schemes. Finally: if all props above the threshold are approved, does that mean all of their actions are executed? What if the actins are contradictory? Is it the users' responsibility to pick a rule that will result in only one prop being selected, if they're creating mutually exclusive options? 202 | 2003-09-15 17:51:42 | 1
| constraints: gui Implemented! | brendan | http://piece.stanford.edu/pod/dev/marea/newpoll2.php?marea_id=1
| has the method/d-rule constraints implemented in the GUI !!! There's also the beginnings of a modular framework to actually *implement* all these decision procedures. See any problems off the bat? For the curious, the declarative structure outlining all the methods and d-rules is at the top of dev/lib/Decisions.php . 195 | 2003-09-15 23:08:33 | 5
| clarifying | todd | "One winning criterion" just means the user doesn't have an option to specify whether one option has to win outright, or can tie with others, and still be approved. This can all be tweaked later I assume, though I know it's not trivial. If there is no winner, the result should be reported as such. Let's leave it to the users to redo it if they want. Later we can add instructions that suggest changing the polling or decision method. I would say if a group are approved, their actions should be executed, and let's let the users worry about contradictions.
| 203 | 2003-09-16 00:40:25 | 0
| good, but one suggestion | todd | This is good. I like the way the "Add another proposition" button appears below the proposition box.The "action" box is quite confusing, though, still. Rather than having a pulldown menu for actions, I think in this case there should just be separate boxes for each one. Also, let's call them "outcomes" instead of "actions", to distinguish them from actions withiin the agenda (which *should* be in a pulldown menu in the doxbox toolbar. Adopt and implement can each be restricted to one specified document/statement, respectively. For delete, you can have a "delete another document" button under the browse box. I wouldn't bother allowing people to remove things after they are added. For now, let's just show them everything once after they hit create, give them a chance to accept or reject, and make them create another poll/decision if they want to replace it. I would plan to add an "edit" function between create and accept when you have time, but that can wait I think. Date selection for the deadline could be friendlier (I recommend pulldowns for date, year, time).
| Todd 204 | 2003-09-16 11:33:51 | 0
| Declarative structure | todd | I'm not seeing anything in dev/lib/Decisions.php - it comes up blank.
| 204 | 2003-09-16 11:37:16 | 2
| php source | brendan | Sorry, that's php source so it's *not* viewable from the browser. [the only stuff visible from the browser is html & javascript outputted by the php processor -- and lib/Decisions.php emits nothing.] You have to login to piece.stanford then goto the /var/www/html/pod/dev/lib directory and look at Decisions.php. | 207 | 2003-09-16 12:41:22 | 1
| Ah - I see it now | todd | Very nice. I'm not used to seeing code in color, which adds a lot to readability. | 208 | 2003-09-16 15:08:52 | 0
| note on reporting results | todd | Brendan,
| We may want to report multi-round rules like IRV by round, i.e. list the numbers of first-ranks for each proposition after each round. I say this just so you can anticipate it, and don't get locked into a schema that assumes reporting can always be summarized as a single vector. Todd 204 | 2003-09-17 18:06:33 | 0
| New Document: "New glossary" | todd | Here's a substantially revised glossary, still very incomplete. My goal is to name as many features as possible, with the idea that the names may change. | 0 | 2003-09-17 20:09:53 | 1
| new vocabulary here | todd | Note - lots of new terminology here. "doxbox" -> "folio", "item" as the general term for the things in a folio, distinctions between frames, panes, and viewers. More to be added later. | 211 | 2003-09-17 20:12:02 | 0
| New Document: "Revision of 'New glossary'" | todd | Here's a new revision - more terms and some corrections | 0 | 2003-09-17 20:56:03 | 0
| toolbar buttons? | brendan | Is it still possible to implement this as toolbar buttons, instead of a pulldown menu? I think it's more intuitive to see a few buttons [with graphical icons!] "Comment" "Edit/Revise" "Attach". Then only the buttons relevant to the current view would be shown.
| The "breadcrumbs" frame could have two rows of stuff: Row 1 would be how it currently is: just navigation items. Back to Index ... [item selector] ("item" in the sense of the glossary) Row 2 would have the action buttons. For example, when viewing a document, it would look like: [Comment] [Edit/Revise] [Attach] 0 | 2003-09-17 21:46:47 | 1
| "agenda" | brendan | To me, "agenda" seems to imply a list of things to be addressed during one meeting -- "agenda item". However, for meeting areas that are more indefinite and open ended -- advice, general discussion, q&a, a standing committee with old budgets & drafts -- I think a more generic term like "index page" might make sense.
| I guess this is a confusion between real-world meaning of "agenda" which, since it's in real-time, are discussed immediately. For an asynchronous meeting. I suppose "agenda" is more specific to the meeting sense, than the term "meeting area index" or "item index" which is essentially being used now. 0 | 2003-09-17 23:09:16 | 1
| I'm willing to try this... | todd | ...with the warning that we may expand the number of actions to the point where it is no longer feasible in the future. The idea of having two rows just might work. An alternative would be to keep the pulldown format in the folio control panel, but include the most important buttons in a row under the preface or other item info within the item display frame.
| Todd 214 | 2003-09-17 23:55:19 | 0
| not HTML frame | brendan | I think the comment reader header *should* be part of the page that the comment text is on -- that is, they should scroll together. This is how it currently is implemented.
| an HTML frame, [my default understanding of the term "frame"] I think, is different than what you mean by "fixed frame" and "variable frame" -- could you explain? 0 | 2003-09-17 23:57:41 | 5
| I still like agenda... | todd | ...for a number of reasons. Lexically, it fits with meetings and items. Also, I think it encourages people to put items in the folio that are relevant, and not to let it get out of hand - to start a new meeting area with a new agenda when that happens. With one discussion, the meeting area is basically one continuous asynchronous meeting, so I think it's okay to use the term "agenda" to refer to the list of items. As you'll see in our AF meetings, Brendan, we pretty much have one agenda for the whole year - it just keeps getting revised, so maybe I tend to think this way naturally anyway. Finally, I think the order of items does matter, and it should help people have better meetings if they actually think of the index as an agenda, putting some items before others.
| Todd 215 | 2003-09-18 00:04:43 | 0
| I'm open on this | todd | I think my meaning of frame is the same as an HTML frame, but I'm not sure. It's the family that scrolls together and stays together, basically. As for whether the comment reader header, I can see it either way. A good argument for your position is that you can see the header in most cases in the discussion index. Although I didn't say it in the glossary, I had been thinking the header would also have reply buttons, which might be nice to have constantly visible as you scroll or page through a comment. | 217 | 2003-09-18 00:09:02 | 4
| unattached? | brendan | This posts a new comment that is *not* referenced to any item -- right? | 0 | 2003-09-18 00:16:49 | 5
| make sense | brendan | Yeah, your meaning of frame *is* the same as an html frame.
| It saves lots of space if a header is part of the scrollable page; my thinking is, once you see the comment header, you can scroll it away while reading hte text of the message. For a long message, it may be acceptable to have the "reply" et al. buttons at the button where you see them once you're *done* reading the comment/. 219 | 2003-09-18 00:21:35 | 1
| let's see how it works | todd | we can try it your way and assess - it may be that inexperienced users need a constantly visible reply button or they will freak out and either not know how to reply or else start a new thread or insert a comment in the document. | 221 | 2003-09-18 00:29:39 | 0
| Right | todd | 220 | 2003-09-18 00:30:32 | 0
| note on referent./referrred terminology | brendan | Just so we don't get confused... here's the grammar i'm using in the code right now and that i'll tend to use when discussing:
| An item reference consists of two parts. * referrer -- the message * referred -- the document being referred to. it's a silly subject/object distinction in this case, but i get confused if i don't define them. 220 | 2003-09-18 00:33:37 | 0
| another point on this | todd | Note that currently the itemref only appears in the discussion index as part of the header for the first message in a thread under subject view. In the comment reader header, the itemref will appear directly, so you can click on it if you have selected the message subject without the itemref. I can imagine scrolling through a message and wanting to bring up the associated document, and finding it difficult if it's not immediately visible in either the discussion index or the comment reader. | 219 | 2003-09-18 00:38:33 | 1
| and news! | brendan | News items & general announcements that everyone should see, should also get to go in the center column, at least in a default template.
| With a templating system, layout details can be abstracted away from the content-prodcuing functions (so each group could have a different layout -- some might want a 2-column layout for example). That's a more long-term goal I guess. 0 | 2003-09-18 00:39:49 | 7
| "folio item"? | brendan | Since all items appear in a folio (or, alternatively viewed, they are the stuff of which folios are made) -- Could we call this a "folio item" as a more complete name, especially when just "item" is ambiguous? | 0 | 2003-09-18 00:45:29 | 1
| question about autoscrolling | todd | Is it possible to put the inserted comment location at the bottom of the visible part of the item display frame within a browser, instead of at the top? Since comments usually refer to text above them, this might make more sense. The ideal would be scrolling to the middle of the browswer view, but I understand that's tough in PHP.
| 220 | 2003-09-18 00:45:44 | 2
| sure | todd | 227 | 2003-09-18 00:46:53 | 0
| definitely... | todd | good point | 226 | 2003-09-18 00:47:29 | 0
| point about editing | todd | Seeing this comment here makes me think how useful it would be to have the inserted comments visible in a document as it is being edited/revised, and even to be able to click on them to bring up the full comment in the discussion viewer. That would make editing that takes into account everyone's comments much easier, and create an incentive to insert comments in the most appropriate places. | 226 | 2003-09-18 00:51:39 | 5
| not easily. | brendan | It's quite easy to make the item display frame scroll to a position where the inserted comment is at the top of the frame, because there happens to be this one little feature of HTML that does it well. Putting it at a middle or bottom position or anywhere else is a complete mess -- it's either highly visually unappealing or else would require nasty non-cross-browser javascript hacks.
| Oh well. 228 | 2003-09-18 00:52:34 | 1
| and another | todd | The comment reader header should also have a link to any comment to which the comment being read is a reply. Another reason to have that information visible as I read the message. | 225 | 2003-09-18 00:54:38 | 0
| darn it all, eh? | todd | 232 | 2003-09-18 00:56:38 | 0
| popup? | brendan | Would having the drafting-new-revision window be a popup [like comment composition right now] be a good enough quickfix? You can just flip back and forth, then -- the main disadvantage is you have to keep track of scrolling two separate places. | 231 | 2003-09-18 00:59:30 | 1
| yeah, I think that would work for now | todd | 235 | 2003-09-18 01:01:57 | 0
| more html deficiencies | brendan | It may be quite difficult to make items inside the textarea box to be clickable. The TEXTAREA html item just doesn't do that.
| In the future, with a conversion to a richer editing widget (like ones that support WYSIWYG rich text editing) it may be possible to add support for something like this. 231 | 2003-09-18 01:03:29 | 0
| and how do comments go away? | brendan | we'd also need a behavior for the inserted comments going away in the new draft. We've already established that you can't carry over comments from an earlier draft (due to textual change etc.) -- so would the editor have to manually delete them? Or should they automatically be deleted? | 231 | 2003-09-18 01:06:08 | 1
| I think they should be automatically deleted | todd | The idea would be that comments don't carry over to a revision, just that you can see them as you edit the previous one. If the full (verbose) view could be seen, that would be useful during editing even if it wasn't clickable.
| Todd 238 | 2003-09-18 13:31:10 | 0
| Alan Cooper and interaction design | todd | I'm trying to get caught up on theories of HCI, and have learned of Alan Cooper's work from a student. I think my views correspond with his in a number of ways, which is validating, although it's not clear how scientifically based this is. Anyway, here's one link: http://www.uidesign.net/2000/interviews/cooper1.html | 0 | 2003-09-18 13:38:00 | 0
| d-rules & interfaces | brendan | As the new vote-system is being implemented, some issues of modularization have come up.
| Every polling method so far, has associated with it, code to display the current status of votes, as well as display a ballot for a user to make their selection. This is because each polling method needs a different interface. chooseone requires mutually exclusive radio buttons per proposition; allocatepts requires little number boxes by each one that must add up to 100. Now, the other modular unit besides polling methods, is decision rules. Each combincation of method/d-rule requires its own evaluation code, that takes as input the polling data, and determines the winner(s). here's the question: Is it right that there's one interface per polling method? Could it somehow be the case that, rather, there's one einterface per method/d-rule combination? -- that is, if you have one polling method, do you need different interfaces depending which decision rule is being used for the overall vote? 0 | 2003-09-21 18:16:57 | 1
| they should mostly be independent | todd | A polling method's voting interface should not depend on the decision rule, except that the user should be told what the decision rule is and (eventually) given a link to a description of it. You should be able to do this as a parameter passed, probably in the URL, or possibly in a form to the interface code for the user. The code for the report will depend on both the polling method and the d-rule. I can help you to modularize this as much as possible if you're not sure how. | 241 | 2003-09-21 20:12:00 | 0
| group homepage design is cool! | todd | Very nice, spare aesthetic. | 0 | 2003-10-01 20:35:15 | 1
| implementation note | brendan | great mic! Keep in mind that changes are gonna have to be migrated to the dev/ branch eventually. There's no harm in testing look-and-feel stuff on the meta/ branch however; but there *are* some differences in the css setup for things inside meta/marea vs. dev/marea. | 243 | 2003-10-01 20:44:11 | 0
| Banner over meeting area | brendan | I can't seem to find anything in the glossary, or otherwise, on exactly what info still needs to be in the banner for a meeting area. Should anything more be added? | 0 | 2003-10-12 01:38:42 | 1
| meeting area control panel | todd | I neglected to add this into the glossary. I think it's pretty good with the info it has: it should have the name of the meeting area (center), navigation back to group home page (with name of group), login/logout and member name. Anything else can be added later I assume.
| Todd 245 | 2003-10-12 04:03:29 | 0
| Meeting area creation | todd | I think that when a new meeting area is created, the originator should be able to write a description that appears on the index page of the m-area, explaining what it is about. I'd make the box relatively small to encourage brief descriptions.
| Todd 0 | 2003-10-13 14:24:33 | 0
| rich comment reader headers | todd | Brendan,
| Per our conversation today, I think I can make a case for a richer comment reader header on the grounds that with the expansion pop-up option implemented for each pane, the comment reader pane (consisting of the comment reader header and the comment text display frames) can easily be viewed by the user in a larger window, so crowding out the text in the default display is not so much of a problem. This is a great advantage of expandable panes, that it buys us a bit of real estate, admittedly at the expense of a more crowded view in the default display of a meeting area. My feeling is that the default display is still not overly crowded. Working tools that people will be using over a long period can afford to be a bit more crammed. Todd 0 | 2003-10-30 15:01:12 | 0
| Accessibility and usability | todd | Here's a good page on accessibility, including links for making a design accessible to disabled users: Usability page. | 0 | 2003-10-31 16:39:38 | 0
| PHPBB | todd | Brendan, did you ever look at this tool? (Note the topic of the forum using it!)
| http://www.freestateofsf.org/forum/index.php 0 | 2003-10-31 17:14:23 | 2
| Yes I have | brendan | I've looked at it quite a bit, even gone through its source & read its developers' lists a bit (back in the research phase in June). http://www.phpbb.com/ is the page for the tool itself.
| It's an example of a one-group-per-installation system (that I assumed we were going to model until today) -- every website has its own phpBB installation, roughly. It's quite popular, actually, and very effective. 250 | 2003-10-31 20:02:08 | 1
| effective but still quite limited | todd | doesn't have the document collaboration aspects. | 251 | 2003-10-31 20:08:13 | 0
| New Document: "item view format" | todd | Here's what I propose for the item view in the discussion index.
| 0 | 2003-10-31 20:17:46 | 3
| Wired's OSS issue | todd | I picked up the November issue of Wired. Brendan, is this the article about Torvalds you were mentioning to me? The article about general open source got me to thinking that we need to figure out how best to plug into a network. We'll need some process for vetting ideas, code changes, etc., and I'd like to refer to this in the release notes for 0.1. I'll poke around, but if you know good sites I should look at on this, let me know.
| Todd 0 | 2003-10-31 20:26:56 | 2
| some notes | brendan | * In the general comments section, should comments (or rather, comment references) be 1 per line?
| * Are comments for each specific item supposed to appear in the agenda? That's the impression I get from reading this. I think that could clutter up the agenda page a bit... 253 | 2003-10-31 20:31:31 | 1
| yes, and OSS management | brendan | Yeah, that's the Torvalds article.
| There's a number of conventional practices out there for code changes. In my opinion it's something that has to grow organically rather than imposing a system in place. I really don't think it's something you can write down in a planning document -- that's just ineffectual bureaucratization of self-organizing action. But that said, here's some very standard infrastructure & techniques: * There needs to be a developer discussion list. This MetaPOD will do for that. * THere's a standard format for sending proposed patches around. The standard prototcol is for interested folks to send their patches to the main developers, or project maintainers. That can be done through email and to a lesser extent the discussion area to discuss the proposed changes and such. * The CVS version management system is the standard way to store code that multiple people can work on at once; you can checkout code from CVS, update to get new changes, and if you hvae write access, commit the changes you make back to the repository. I haven't put POD on CVS yet; there are a number of considerations to handle, before doing so. It isn't too hard by any standard, really. CVS access is limited to the main developers on the project; if you don't have CVS access but think you have a good patch, you submit it to someone who does have CVS access. there's one CVS overview at least, off of http://cs108.stanford.edu * THere are good places to go in open-source world to publicize POD -- website that collect interesting projects and such. freshmeat.net is important; and then maybe the mailing lists of various open-soruce groupware/discussion software out there -- basically, all the ones listed on that Online Delib Links page I made (including phpBB and others) Then there's always slashdot for the brave... * We may as well take out a sourceforge site, they have nice things like patch managers and a cvs repository with huge bandwidth, to use if we need to. We also would get a http://pod.sourceforge.net to redirect to http://piece/pod. Don't think the sourceforge thing is strictly necessary though. 254 | 2003-10-31 20:41:19 | 1
| responses | todd | * In the general comments section, should comments (or rather, comment references) be 1 per line?
| Yes, I'd say at most one per line (with replies in parens in the short view). * Are comments for each specific item supposed to appear in the agenda? That's the impression I get from reading this. I think that could clutter up the agenda page a bit. No, I didn't intend that. They just appear in the discussion viewer when the agenda is the item displayed in the folio viewer. 255 | 2003-10-31 20:54:10 | 0
| all sounds good | todd | We should talk about the specifics next week when we meet. | 256 | 2003-10-31 20:58:00 | 0
| just to clarify | todd | the format I'm proposing is just for the discussion index pane, not for the folio viewer.
| Todd 253 | 2003-10-31 21:00:48 | 0
| straw polls | brendan | I don't have written what we decided -- should straw polls be date-less, never closing?
| Or should they have closing times and closing announcements, just like decision votes? 0 | 2003-11-01 13:31:04 | 1
| d-vote announcements fixed | brendan | after many debugging emails, the multiple-send on a vote closing bug, is now fiexed | 0 | 2003-11-01 13:33:59 | 1
| deadlines | todd | I think for both decisions and nonbinding/straw polls (not sure best term), the creator should be able to specify a deadline. Maybe there should be an option of no deadline for both too. I would say that 1 week should be the default in both cases.
| Todd 260 | 2003-11-01 20:50:38 | 0
| great! | todd | 261 | 2003-11-01 20:51:31 | 0
| vocabulary thoughts | todd | A couple of ideas:
| How about using "response" to refer to after-comments sent to the discussion, and "reply" to refer to messages sent to the poster's email address? Also, how about "overall comments" instead of "general comments"? We could even have an icon that is a picture of overalls. :) 0 | 2003-11-02 15:58:11 | 0
| New Document: "changes from todd" | brendan | copy and pasted from email | 0 | 2003-12-07 17:43:27 | 0
| problem with numbering scheme | brendan | here's a potential problem with the entire location-letter scheme.
| what about commetns on non-documents? Currently only documents have those little tags like "1.1" However, all non-documents currently CANNOT have inline comments, just general comments. Doe sthis resovle the issue? 0 | 2003-12-07 17:46:23 | 1
| cannot fix | brendan | this is a limitation of the HTML frames system, as we've gone over before for similar issues. the overall URL only sets up the frames with a default for each internal frame. The refresh button pulls up the URL again.
| there's a tiny change that a wacky javascript hack could work around the problem, but there are more important things to do. 0 | 2003-12-07 17:47:55 | 3
| non-trivial | brendan | this requires fairly large architecture changes to implement in the general case; i may want to put this one off, since I think it's fairly non-essential | 0 | 2003-12-07 18:03:34 | 1
| not for 0.1 | brendan | again, very non-trivial | 0 | 2003-12-07 18:04:53 | 0
| race condition | brendan | Keep in mind this cannot always be accurate.
| Say we have document 2.3. If person A does a revision, the composing window will say "your new revision will be 2.4." If person B does a revision *before* A has finished theirs, they'll be working off 2.3. So their window will say "your new revision will be 2.4." Whoever finishes first will get the 2.4. tag number, whoever finishes second will get 2.5. There's no way to solve this except unless the composer keeps constant updates. This can't be done in an HTTP system, except for simulated push via a pull every few minutes or so, which strikes me as difficult to implement (but may be possible, if messy and going against the grain of what HTTP is supposed to do) 0 | 2003-12-07 18:08:33 | 1
| location letters | todd | I don't think this is a problem. If the comment is an overall comment, the notification can inform the user of that. I think that all items should be numbered according to the same scheme. E.g. item 1 could be a document, item 2 could be a vote, and in the future this will facilitate revisions to votes etc. Obviously not necessary for 0.1, but let's hang onto it. | 266 | 2003-12-07 22:51:15 | 0
| okay | todd | I'll await the best technical solution. | 267 | 2003-12-07 22:54:17 | 0
| okay | todd | I agree it's not essential for 0.1. In a task list, I would code this (and the other changes/bugs in this list) as problems, with suggested solutions (including mine and then yours), so we don't lose sight of the fact that the problem exists. Does that make sense?
| 268 | 2003-12-07 22:57:47 | 0
| one question | todd | When I post a comment in view-by-date responding to one of these most recent comments, the new comment shows up at the bottom in an autorefreshed version of the discussion index. Is it just autoscrolling to the posted comment, or keeping track of where it was somehow?
| 267 | 2003-12-07 23:00:28 | 1
| actually, I guess it's obvious.. | todd | that it is autoscrolling to the new comment, which is also now highlighted. Perhaps this could be a basis for solving the problem of scrolling to the appropriate place when frames are refreshed? | 274 | 2003-12-07 23:02:08 | 0
| it's fine to amend | todd | That's okay - like with Wikis, we can just let the user know another revision has occurred and theirs will now be 2.4 instead of 2.3, or whatever. | 270 | 2003-12-07 23:04:36 | 0
| |