Forum .LRN Q&A: Re: Forums Review by the UAB

Collapse
Posted by Matthias Melcher on
Thank you Lars for the thoughtful reply.

<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.