Dear Matthias, Dorothea, and UAB
Thank you very much for the detailed specification.
We on our end had a meeting on Tuesday night to gather all the information for working on a forums specification. That gave rise to a number of questions and clarifications, which I'd much appreciate if you could respond to before Sunday, when our next work session on this will be.
I've read the above specification, and only posted questions that weren't already answered by that one.
Here we go ... apologies if any of them are stupid.
- Re 3, expand/collapse: Your oroginal "Recommendations" doc says "the user could customize the display". Does this simply mean that the user can click expand/collapse posts/subthreads, or can the user chose some other configuration settings that would apply to all threads? Would they apply to all forums as well, or be a per-forum option? What would those customizations be?
- Re 9, text input: Have you looked at the htmlArea WYSIWYG editor already in OpenACS 5.1? Text input is a tricky problem, as you are essentially providing a means for translating plaintext into HTML, since the rendered version will always be in HTML. I cannot completely follow the specification on this.
What I would suggest is that, if possible, you point to an existing system that does text input and conversion to HTML correctly the way you would want it. And whether or not that's possible, you provide a set of examples, test cases if you will, of text input and corresponding rendered HTML, so that we can properly understand all the implications, and have test cases that we can use to verify the implementation when done.
Another use case to consider is when users reply to a posting via email. Most email clients will automatically break lines at some fixed width, which currently gets posted as hard line breaks where what is really intended is a running paragraph. When this is rendered into HTML, what you see is either lines that are shorter than those in the other postings, or when the display area is more narrow than the line width used in the email, you get the zig-zagged line breaks. A couple of examples to illustrate:
This is an email
where the line
width is shorter
than the display
pane.
This would be an
email
where the display
pane
is more narrow than
the
line width used in
the
email.
Even more troublesome is the situation where the email contains quotes using the ">" symbol. I'm not saying we need to deal with this, that would be your judgment call as the UAB, but it's something to keep in mind.
To me, this is issue ought to be classified in the "Difficult" category on the matrix, not in "Easy".
- Re 5, "Sohpisticated sorting": The original "Recommendations" doc says "a way of making one's favorites and sorting accordingly". We (as well as Jeff above) are not sure what those favorites are. Is it favorite authors? Favorite threads? Posts? Then sort so threads where your favorite authors have posted are on top? Or does it refer to a favorite sort order, so the system will remember how you last sorted this list?
Another possibility to consider: Google's new Gmail service has a mechanism where you can tag emails/conversations with a "star", which makes that email/conversation show up in a special, automatic "Starred" folder. This would be a very efficient and convenient way to save a thread for later, e.g. I could have this thread starred while I'm working on the project. Google's implementation is very slick as well, since setting/removing the 'star' flag is handled transparently in the background, so you don't need to wait for a round-trip to the server, and you don't loose your position on the page.
- Re 11, improved alerts: We do not understand what you mean by "breadcrumb tagging".
- Re 2, ratings: I don't see how Bruce's post relates. That said, in the original "Recommendations" document, this item was placed under the "for admins" header. Why not allow all users to rate postings, the typical collaborative filtering approach?
- Re 6 & 7, protocol and meta-commentary: We don't fully understand how these would work, and fear that the required user interface elements will clutter and confuse users more than they will help. They're still interesting and definitely worth pursuing, though, so we propose that these are postponed to a version 2 of this work.
The next step we on our end intend to do is to develop some page layout sketches that we will then post for review and can base further discussions on. Our next work session is Sunday, so expect to see these early next week.
/Lars
