Forum .LRN Q&A: Re: Forums Review by the UAB
specification for forums improvements. To enable
timely participation in the discussion, we put
up a very early draft here
http://www.rzuser.uni-heidelberg.de/~x28/fspec/
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
<blockquote> - 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?
</blockquote>
I think, the former (per thread).
What we thought of when writing the quoted first
version was simply that the user should be allowed
to change the expand/collapse display, overriding
system or class level or forum's level pre-setting.
We did not yet think if this should be a single
setting for all forums /threads. I think the best
way to set the display is to have the class admin
make some recommended pre-setting. It the user wants
to override it for some reason s/he can do this for
each lower level again. If this is too much bother
s/he should talk to the class admin to discuss whether
the pre-settings are really the best for the given
context, and then perhaps a solution is found on a
content level, e. g., splitting forums according to
different usage patterns. So, user-specific settings
should be sufficient on a per-thread basis.
<blockquote>
- Re 9, text input:
[...]
</blockquote>
Not sure how to reach the htmlArea editor on the
test servers / which test server.
Guessing from your judgement of "Difficult", we
think you have understood the desired optimal
functionality right. We will try to further elaborate
on the use cases, but as a quick answer,
the "copy & paste safeness" goal is the most important,
and there is also a "easy" subset possible: the simple
radical solution to the take the pasted input, put html
"<PRE>" tags around it, and let the horizontal
scroll bar do the rest.
<blockquote>
- 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.
</blockquote>
Yes, sorting by favorites is in fact part of the
# 2) "Rating" star system on the wishlist, with Bruce's
answer
https://openacs.org/forums/message-view?message_id=184018
to Jeff's question. We have not yet decided among
priorites however, that might be relevant for
sorting in general vs. this additional sort field.
<blockquote>
- Re 11, improved alerts: We do not
understand what you mean by "breadcrumb
tagging".
</blockquote>
Sorry for this unpolished part of the advanced wishes.
Microsoft SharePoint notifications contain an indication
where the document lives whose change is being reported.
If you have several changes in the same neigborhood at
the same notification interval, this will probably look
like this
Subject A > Topic A3 > Subtopic A31 > Team paper: changed
Subject A > Topic A3 > Subtopic A31 > Wrap up paper: updated
Subject A > Topic A3 > Overview: added
Subject A > Topic A3 > Subtopic A37 > Introducton: revised
Subject B > Topic B1 > Subtopic B14 > Content Part 5: moved
Subject B > Topic B1 > Subtopic B14 > Summary: deleted
This sort of bulk notifications could be optimized by
sorting, omitting repeating crumbs, indenting, and
sophisticatedly offering deep-linking "handles" right
into the subsection being most approriate for the
personal workflow, as sketched in the newer specs.
<blockquote>
- 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?
</blockquote>
Sorry for that little misunderstanding among ourselves.
<blockquote>
- 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.
</blockquote>
Ok.
