Meta-POD meeting area, using POD 0.0.1/0.0.2/0.1, 8/4-12/7/2003:
(Click here for documents)

-------------- select subj, author, msgtext, in_reply_to, when_posted, num_replies from msgs --------------
subjauthormsgtextin_reply_towhen_postednum_replies
New Document: "orig glossary"brendanThis is the original copy of a terminology glossary that Todd wrote a little bit back02003-08-04 19:43:2610
Note on stabilitybrendanThis 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)

02003-08-04 19:46:111
1 discobrendanThere 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.02003-08-04 20:19:080
heading of prefacetoddI think we should replace "Creator Remarks" with the title of the document as the header of the preface. 12003-08-04 21:53:478
Numbers and bracketstoddI 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
12003-08-04 21:57:230
no brackets or numbers in messages without refstoddFor 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
22003-08-04 21:59:370
index in date viewtoddWhen viewing by date, I think it's best to show the document reference for each message, in linear (non-indented) format02003-08-04 22:03:590
notices in document indextoddWhen 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
02003-08-04 22:07:440
Where are the dotstoddI miss the Craigslist dots ("..") that formerly indented headers in the message index. Can we have them back? :)

Todd
42003-08-04 22:09:536
on second thoughttoddInstead 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
42003-08-04 22:12:550
Ah, now I see them!toddHmmm, 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
92003-08-04 22:15:355
alsotoddI think the compose box needs a "cancel" button for when you think better of it midway through writing.

Todd
112003-08-04 22:21:560
Digest ideasbrendanSo 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.02003-08-04 22:23:265
idea about email integrationtoddAs 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 " and limit this to one notification per day.

Todd
02003-08-04 22:26:136
sounds good.brendanSounds 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?112003-08-04 22:26:411
program headertoddI 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
02003-08-04 22:29:580
no subjecttoddmaybe a hybrid of this idea and mine (see "idea about email integration" message).

Todd
132003-08-04 22:36:074
"Re: no subject"toddIf 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
172003-08-04 22:37:293
see my earlier messagetoddBrendan, 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
152003-08-04 22:41:030
automatic reload of page on postingtoddBrendan, 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.

02003-08-04 22:43:511
sign-offstoddOne 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. 02003-08-04 22:47:590
missing unseen highlightstoddI'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.02003-08-04 22:50:230
losing selected message on reloadtoddRight 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. 02003-08-04 22:52:331
it's happeningbrendanit also selects your message that you just posted.202003-08-04 23:19:590
defaults kill creativitybrendanOn the other hand, by having a blank subject line, the user is forced to think of a short, snappy summary for their post.182003-08-04 23:21:022
good point, but...toddmy 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
252003-08-04 23:27:160
cut/paste in compose boxtoddI 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?

142003-08-04 23:38:345
working for mebrendanIt'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...272003-08-04 23:48:364
I'm using Netscape 7.1toddThe 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
282003-08-05 00:14:133
forgot to saytoddI'm in Win '98, on my old home machine.

In shame,
Todd
292003-08-05 00:16:380
long discussionstoddIt'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.02003-08-05 00:19:304
preserving thread view on reloadtoddWhen 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
02003-08-05 00:24:119
cookies and passwdsguestthis 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
322003-08-05 00:56:418
cookies/auth fixbrendanI 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.332003-08-05 01:32:530
password optionsbrendanFor 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.
332003-08-05 01:37:026
oh, it's POD's problembrendanyes, 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 :)
292003-08-05 01:41:561
on preserving statebrendanRight, 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]
232003-08-05 01:52:070
passwd encryptguestlike 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.

352003-08-05 01:57:155
half-sync ideabrendanOn 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.
02003-08-05 02:04:4619
outta synchmicyeah, 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.

392003-08-05 02:23:041
each file is a copybrendanWell, 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.
402003-08-05 02:58:410
I favor encryption asaptoddI'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
382003-08-05 10:00:254
Ah, thanks!toddI learn something new every day. :)362003-08-05 10:07:280
teaching creativitytoddAnother way we can encourage people to fill in subject line is with the sample board in our introduction. Training with examlples works pretty well.252003-08-05 10:16:000
email notifications ideatoddActually, 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
392003-08-05 10:25:0916
clarificationtoddAs 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
452003-08-05 10:31:116
Already a big improvementtoddBrendan, I see you added in the username in the subject line for notifications. That helps a lot. 452003-08-05 10:43:536
hehbrendanActually, 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 472003-08-05 10:49:575
remember, it's damn annoyingbrendanThere'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.
422003-08-05 11:01:483
email is the devil incarnatebrendanMessage 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...
462003-08-05 11:11:435
yep! (nm)toddI guess I have to type something here. 482003-08-05 11:22:114
should allow blank messagestoddRight now it won't let you post a blank.512003-08-05 11:22:410
craigslist's solutionbrendanlook 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 512003-08-05 11:27:302
I agree, but...toddFirst, 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
502003-08-05 11:35:164
I like the appending idea, but...toddI think we should avoid symbols that people have to learn. Better to just insert the words "(no text)" imo.

Todd
532003-08-05 11:38:551
let's talk about this tomorrowtoddnm492003-08-05 11:43:272
"display" -> "sort by"toddInstead of "display:" in the discussion index toolbar, I think we should say "sort by:".

Todd
02003-08-05 11:51:450
an object lessontoddIn 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
542003-08-05 12:14:301
toolbar buttons for message display windowtoddSome ideas:

back (go back to message previously read)
forward
previous (go to previous message in index)
next
02003-08-05 12:26:411
the link worksbrendanmake 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...
542003-08-05 13:10:101
allowing blank messages.brendan552003-08-05 13:15:340
email is infinitely malleablebrendanI 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.
452003-08-05 13:22:541
compromise with the devilbrendanyou should get this message via email.582003-08-05 13:27:510
once upon a time...toddI 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
622003-08-05 13:42:520
thanks - very usefultoddI probably left off the "l" at the end.602003-08-05 13:45:530
especially for long complex threadstoddHaving "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.592003-08-05 13:47:340
Yogi Bera's dictumtoddHere'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
02003-08-05 14:05:420
New Document: "Design notes"toddThis was cobbled together from email/POD discussion, notebook scribbles, and face-to-face meetings between Todd Davies and Brendan O' Connor, 8/6/0302003-08-06 17:42:344
New Document: "test doc"brendanHere's the new document, everyone02003-08-06 18:00:280
New Document: "test2"brendanHere's the new document, everyone02003-08-06 18:01:240
New Document: "test3"brendanHere's the new document, everyone02003-08-06 18:01:480
New Document: "Message digests"brendanOn what message digests & summaries should look like.02003-08-07 02:51:396
meta: shorter documentsbrendanSo 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.732003-08-07 02:53:224
test msgbrendanmessage text02003-08-07 03:23:350
thanks for straightening this out (nm)toddmessage text692003-08-07 09:01:480
I like thistoddYeah, 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
732003-08-07 09:12:010
doc pointer?toddBrendan, I don't understand what this is referring to.

742003-08-07 09:14:063
page-ing docstoddEven 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.692003-08-07 09:21:061
integrating read/unread with emailtoddCan 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?
312003-08-07 09:35:222
on second thoughttoddOnce 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.
802003-08-07 10:44:491
new proposeddiscussion index toolbartoddHow 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

692003-08-07 11:31:580
oops - posted in wrong placetoddI should have posted this below under the design notes. I'll copy it.

Todd
812003-08-07 11:33:490
on second thoughttoddOnce 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.792003-08-07 11:34:330
proposed dis index toolbar (repost)toddI 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
02003-08-07 11:37:036
not quite working yettoddI 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
852003-08-07 11:39:313
New Document: "new document"brendanHere's the new document, everyone02003-08-07 12:50:150
after 1st asdfbrendanmessage text02003-08-07 13:00:300
half fixedbrendanComment 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.
862003-08-07 13:09:022
making a comment on the mediumbrendanI 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.782003-08-07 13:10:302
autoscrollingbrendanI 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.02003-08-07 13:30:451
ah, I seetoddI agree in this case, though if it were part of a larger document it might make more sense to put it in the doxbox. 902003-08-07 13:57:310
okay, I seetoddI didn't realize the difficulties.

I like the term "magic spaces" a lot. :)

Todd
892003-08-07 14:02:490
cool!todd912003-08-07 14:04:280
unread messagesbrendanThey 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?

02003-08-07 17:10:015
looks goodtoddI would bold/unbold all the fields in read/unread comments.

Todd
952003-08-07 17:45:413
on second thoughttoddI 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
962003-08-07 17:48:250
an additional suggestiontoddI'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.962003-08-07 18:10:080
clarificationtodd>>I would bold/unbold all the fields in read/unread comments.

"read/unread" should be "unread/read" in the above sentence.
962003-08-07 18:11:350
more stuff for compose windowtoddThere 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
02003-08-07 18:21:490
colors for highlightingtoddDo 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
02003-08-07 18:32:513
as I play with this moretoddI 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.312003-08-07 18:36:260
here it isbrendanmessage text1012003-08-07 20:53:050
here it is (repost)brendanHere 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.1012003-08-07 20:56:141
green versus greentoddYeah, 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
1042003-08-08 00:07:040
following-uptoddmessage text562003-08-08 00:35:411
follow-up to following uptoddWell, 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.
1062003-08-08 00:39:470
toolbars/banners should be in fixed framestoddI 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
852003-08-08 12:46:170
doc-loc for general commentstoddI'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.852003-08-08 12:51:270
New Document: "the TODO"brendanA structured TODO list, in wiki form02003-08-08 16:11:383
looked at ittoddBrendan, 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.1102003-08-08 16:38:012
another suggestiontoddBrendan,

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
1112003-08-08 16:49:451
read/unread color change suggestiontoddI'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.

952003-08-08 21:01:290
changes notedtoddBrendan, 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
1122003-08-08 21:11:490
Yet Another forum systembrendanThis 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

02003-08-10 23:14:364
interesting...toddIt'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.
1152003-08-11 12:06:383
remember another sitetoddAlso there was that european decision tool which wraps comments around text - I'll look up the name.

Todd
1162003-08-11 12:08:252
d3e?brendanIs this the one? Not sure about the wrapping around text part.

http://d3e.sourceforge.net/
1172003-08-11 12:12:501
yes, that's ittoddThey 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
1182003-08-11 16:25:540
runaway lines need to be croppedtoddOn 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. 02003-08-12 14:27:245
autoscroll locationtoddAlso, 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.1202003-08-12 14:30:382
email notification for inserted commentstoddThe 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.1202003-08-12 14:58:271
autoscroll contextbrendanI 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.1212003-08-12 16:23:561
HTML sucks sometimes :(todd1232003-08-12 17:34:090
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 userguestmessage text1222003-08-13 11:33:000
New Document: "article on picking online discussions"toddInteresting article from today's SF Chronicle.02003-08-19 11:11:090
after 2nd asdfbshankswell well then02003-09-05 09:40:480
New Document: "Revision of 'test doc'"bshanksHere's a new revision02003-09-05 09:41:180
viewsbshanksis subject/date/location view implemented yet? b/c if so, i can't find it.

112003-09-05 09:51:441
nevermindbshanksi found them1292003-09-05 10:02:570
like it this waybshanksi like it this way (as a doc, not a msg)-- this way we could, if we chose, collaboratively edit the proposed daily message summary.
902003-09-05 12:30:470
relevant standardsbshanksi 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.
892003-09-05 12:37:020
New Document: "general"bshanksThis is just to attach general comments to.
02003-09-05 13:13:5713
first thoughtsbshanksThe 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.
1332003-09-05 13:39:000
general UIbshanksI 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.
1332003-09-05 13:46:313
thankstoddThanks, 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
1352003-09-05 14:20:580
titlesbshanksTitles 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.
1352003-09-05 14:27:471
New Document: "new document"bshanks(Potential) Bugs02003-09-05 14:30:380
New Document: "(Potential) Bugs"bshanks02003-09-05 14:31:269
subject heading and returnbshanksIf 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.
1332003-09-05 14:33:522
New Document: "feature requests"bshanks02003-09-05 14:34:3919
document-less discussion?bshanksThe 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".
1332003-09-05 14:38:272
Actually, you can hit "compose new message"toddthe name for which will probably change, in the comments index toolbar.

Todd
1422003-09-05 14:43:360
topic idea is in processtoddAlthough it's not in the design doc, we're planning a "create discussion item" action for the purposes you've outlined.

Todd
1422003-09-05 14:45:000
I agreetoddwith 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.1372003-09-05 14:48:360
which browser?brendanWhich browser version are you using? Sounds like a javascript inconsistency to me.. Normally the key inside the Subject text field would send off the message; I used javascript to disable that, but javascript is just so inconsistent on different browsers.

It seems to be working on IE 6 and Moz 1.0+
1402003-09-05 17:38:461
re: subject heading and returnbshankshmm. 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.



1462003-09-05 20:49:220
reply to emailbshanksi 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).

1412003-09-05 21:01:266
link to subdocumentsbshanksit 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).
1412003-09-05 21:04:460
searchbshanksfeature req: full-text search of a meeting area
1412003-09-05 21:06:472
links in sbj indexbshanksi 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.

1412003-09-05 21:15:210
option not to get own msgsbshanksfeature 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)
1412003-09-05 21:18:120
Yeah! I agree completely!todd1482003-09-06 00:16:510
too many messagesbshanksthe 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

1412003-09-06 00:41:580
browser's Back arrowbshanksI 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).

1392003-09-06 01:02:473
agreedbrendanThe 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...
1482003-09-06 01:04:214
hierarchial documents?bshanksI 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.
1332003-09-06 01:06:331
yeah, back button is crazybrendanThe back button is simply bizarre for the meeting area system. mixing both frames and javascript is just a recipe for back-button disaster...1552003-09-06 01:08:132
portability of emailbshanksthat'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?
1562003-09-06 01:13:183
re: back buttonbshankshe he
1582003-09-06 01:14:350
SQLbshanksjust out of curiosity, are the messages stored in an SQL database (seemed like that judging from the debugging info when posting a msg)?
02003-09-06 01:15:521
receiving email challengesbrendanThe 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.
1592003-09-06 01:50:202
yes, the'yre in SQLbrendanmessages are al lstored in a MySQL db.
Documents, however, are on the filesystem [the text of them, at least].
1612003-09-06 01:53:490
re: email challengesbshanks> 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.

1622003-09-06 10:50:291
in support of novice/advancedbshanks>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.
02003-09-06 12:44:366
word wrap sbj headersbshanksIf you word wrapped the message index box, you could conceivably eliminate the horizontal scrollbar there
1412003-09-06 12:46:311
separate windows optionsbshanks(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.
1412003-09-06 12:48:161
expand/collapse threadsbshankshere'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.
1412003-09-06 13:18:240
small note on my schedulebshanksi 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


02003-09-06 13:23:020
expand/collapse mode - reply to Bayle's commenttoddHere'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
02003-09-06 16:16:531
a meta commenttoddBayle,

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
1652003-09-06 16:26:565
hmmm, looks like...toddCopy 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.1712003-09-06 16:29:262
true, but then you lose indentation information...toddunless you do something like insert vertical space between headers. We'll have to see what the best solution is. 1662003-09-06 16:33:130
disabling "Back" might be besttoddBrendan raised this suggestion at one point, and it might make the most sense in the meeting area.1582003-09-06 16:36:080
this is a good discussiontoddIn the long run I'd want to aim for email/meeting area interoperability that is comparable to Yahoo Groups.1642003-09-06 16:38:170
check out Forte Free AgenttoddA wonderful newsreader that many people find easy to learn. That's my model for expandable panes.

1672003-09-06 16:40:170
or, better, for the whole sitetoddThat will be an important feature to add - hopefully we can get an open source search tool.1502003-09-06 16:43:221
maybe, maybe nottoddI 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.1572003-09-06 16:48:490
deep linking IMPLEMENTEDbrendanYou'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.
1722003-09-07 00:39:441
loop happened againbshanksI 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.
1392003-09-07 11:21:210
loop againbshankswas 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

1392003-09-07 11:25:323
loopbshanksyou know, i think that now it just happens everytime i paste in a message's URL from the notification email.

1812003-09-07 11:27:582
re: a meta commentbshanksthat'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. 1712003-09-07 11:39:140
i seebshankssorry, 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)
1702003-09-07 11:41:540
and they are much appreciated!toddYour 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
1712003-09-07 13:00:480
great!toddgood work.1792003-09-07 13:03:050
New Document: "Revision of 'Design notes'"toddHere's a new revision - adding a search link per Bayle's suggestion on the group home page02003-09-07 13:08:290
maybe loop = slowness?brendanIs 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. 1822003-09-07 13:08:381
it's doablebrendanthere'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.
1772003-09-07 13:09:490
loop != slownessbshanksi 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.



1882003-09-07 14:02:270
New polling features!brendanhttp://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
02003-09-08 04:42:061
looks goodtoddBut 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
1912003-09-08 14:12:340
New Document: "Polling Method & Decision Rule constraints"brendanHere'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.
02003-09-12 03:16:460
decision-vote creation mockupbrendanA 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.

02003-09-12 03:31:261
New Document: "Revision of 'Polling Method & Decision Rule constraints'"toddHere's a new revision by Todd02003-09-12 15:57:446
good starttoddThe 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
1942003-09-12 16:00:510
Mic and I mettoddMic 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
02003-09-13 00:00:560
New Document: "Revision of 'Revision of 'Polling Method & Decision Rule constraints''"toddHere'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.02003-09-13 17:26:180
100?brendanShould the number of points to allocate be variable? Or is fixed-at-100 good enough?02003-09-15 12:32:271
I think we can start with a flat 100 for point allocation, but...toddit 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
1992003-09-15 13:54:170
d-rule resultsbrendanWe 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...
02003-09-15 17:12:493
our way or the highwaytoddFor 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
2012003-09-15 17:18:162
translating rule resultsbrendanby "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?
2022003-09-15 17:51:421
constraints: gui Implemented!brendanhttp://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 .
1952003-09-15 23:08:335
clarifyingtodd"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.

2032003-09-16 00:40:250
good, but one suggestiontoddThis 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
2042003-09-16 11:33:510
Declarative structuretoddI'm not seeing anything in dev/lib/Decisions.php - it comes up blank.

2042003-09-16 11:37:162
php sourcebrendanSorry, 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.2072003-09-16 12:41:221
Ah - I see it nowtoddVery nice. I'm not used to seeing code in color, which adds a lot to readability.2082003-09-16 15:08:520
note on reporting resultstoddBrendan,

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
2042003-09-17 18:06:330
New Document: "New glossary"toddHere'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.02003-09-17 20:09:531
new vocabulary heretoddNote - 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. 2112003-09-17 20:12:020
New Document: "Revision of 'New glossary'"toddHere's a new revision - more terms and some corrections02003-09-17 20:56:030
toolbar buttons?brendanIs 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]
02003-09-17 21:46:471
"agenda"brendanTo 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.
02003-09-17 23:09:161
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
2142003-09-17 23:55:190
not HTML framebrendanI 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?
02003-09-17 23:57:415
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
2152003-09-18 00:04:430
I'm open on thistoddI 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. 2172003-09-18 00:09:024
unattached?brendanThis posts a new comment that is *not* referenced to any item -- right?02003-09-18 00:16:495
make sensebrendanYeah, 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/.
2192003-09-18 00:21:351
let's see how it workstoddwe 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. 2212003-09-18 00:29:390
Righttodd2202003-09-18 00:30:320
note on referent./referrred terminologybrendanJust 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.
2202003-09-18 00:33:370
another point on thistoddNote 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.2192003-09-18 00:38:331
and news!brendanNews 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.
02003-09-18 00:39:497
"folio item"?brendanSince 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?02003-09-18 00:45:291
question about autoscrollingtoddIs 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.
2202003-09-18 00:45:442
suretodd2272003-09-18 00:46:530
definitely...toddgood point2262003-09-18 00:47:290
point about editingtoddSeeing 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.2262003-09-18 00:51:395
not easily.brendanIt'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.
2282003-09-18 00:52:341
and anothertoddThe 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.2252003-09-18 00:54:380
darn it all, eh?todd2322003-09-18 00:56:380
popup?brendanWould 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.2312003-09-18 00:59:301
yeah, I think that would work for nowtodd2352003-09-18 01:01:570
more html deficienciesbrendanIt 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.
2312003-09-18 01:03:290
and how do comments go away?brendanwe'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?2312003-09-18 01:06:081
I think they should be automatically deletedtoddThe 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
2382003-09-18 13:31:100
Alan Cooper and interaction designtoddI'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.html02003-09-18 13:38:000
d-rules & interfacesbrendanAs 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?
02003-09-21 18:16:571
they should mostly be independenttoddA 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.2412003-09-21 20:12:000
group homepage design is cool!toddVery nice, spare aesthetic.02003-10-01 20:35:151
implementation notebrendangreat 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.2432003-10-01 20:44:110
Banner over meeting areabrendanI 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?02003-10-12 01:38:421
meeting area control paneltoddI 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
2452003-10-12 04:03:290
Meeting area creationtoddI 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
02003-10-13 14:24:330
rich comment reader headerstoddBrendan,

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
02003-10-30 15:01:120
Accessibility and usabilitytoddHere's a good page on accessibility, including links for making a design accessible to disabled users: Usability page.02003-10-31 16:39:380
PHPBBtoddBrendan, did you ever look at this tool? (Note the topic of the forum using it!)

http://www.freestateofsf.org/forum/index.php
02003-10-31 17:14:232
Yes I havebrendanI'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.
2502003-10-31 20:02:081
effective but still quite limitedtodddoesn't have the document collaboration aspects.2512003-10-31 20:08:130
New Document: "item view format"toddHere's what I propose for the item view in the discussion index.
02003-10-31 20:17:463
Wired's OSS issuetoddI 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
02003-10-31 20:26:562
some notesbrendan* 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...
2532003-10-31 20:31:311
yes, and OSS managementbrendanYeah, 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.
2542003-10-31 20:41:191
responsestodd* 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.
2552003-10-31 20:54:100
all sounds goodtoddWe should talk about the specifics next week when we meet.2562003-10-31 20:58:000
just to clarifytoddthe format I'm proposing is just for the discussion index pane, not for the folio viewer.

Todd
2532003-10-31 21:00:480
straw pollsbrendanI 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?
02003-11-01 13:31:041
d-vote announcements fixedbrendanafter many debugging emails, the multiple-send on a vote closing bug, is now fiexed02003-11-01 13:33:591
deadlinestoddI 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
2602003-11-01 20:50:380
great!todd2612003-11-01 20:51:310
vocabulary thoughtstoddA 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. :)
02003-11-02 15:58:110
New Document: "changes from todd"brendancopy and pasted from email02003-12-07 17:43:270
problem with numbering schemebrendanhere'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?
02003-12-07 17:46:231
cannot fixbrendanthis 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.
02003-12-07 17:47:553
non-trivialbrendanthis 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-essential02003-12-07 18:03:341
not for 0.1brendanagain, very non-trivial02003-12-07 18:04:530
race conditionbrendanKeep 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)
02003-12-07 18:08:331
location letterstoddI 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.2662003-12-07 22:51:150
okaytoddI'll await the best technical solution. 2672003-12-07 22:54:170
okaytoddI 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?
2682003-12-07 22:57:470
one questiontoddWhen 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?

2672003-12-07 23:00:281
actually, I guess it's obvious..toddthat 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?2742003-12-07 23:02:080
it's fine to amendtoddThat'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.2702003-12-07 23:04:360