The Value Added axis allows everyone else to see where we feel we will get the biggest "bang for the buck" for users.
As another qualifying note, the UAB is well aware that these are rudimentary documents; that if and when any of this work is to be done, there will be a need to flesh out the required specifications; and that when that time comes, each UAB member is prepared to work with the developers to elaborate and clarify on each item.
UAB Forums Enhancements Recommendations April 2004
1) MOVE functionality (Martins)
2) Ratings: a star system so that one could rate a thread as helpful or not and sort accordingly.
For All Users:
3) Threading layout/Display choices: expand/collapse sub-headers and bodies on demand
Ex: On SSV1, admin had three display options:4) Clean Print feature: small type printing without indentations, a simple header for each contributor and none of the navigation links
1) expand tree in summarized form;
2) expand and show message bodies and
3) expand one level. Additionally, the user could customize the display.
Now asking a hacker to post the document in another format is cool, but asking users to do that is not, IMO. My guess is that common users don't know about formats. "Text only" could mean a Word tekstdocument.
Criticism of the UAB on the Forums package is clear, so I suggest we don't complain about MS Office formats anymore?
When I work with clients, I also waste breathe telling developers to convert their docs from OpenOffice to PDF because an average user should not be expected to download OpenOffice when that is their normal application.
In this community, the default application is certainly not Word, and I would say it's not even OpenOffice. There are many formats out there that offer plenty of cross platform functionality as well as being very readable and useable.
So there is irony to a "User Advisory Board" that is insensitive to the open source developer community they are trying to communicate with. Not terribly surprising and not a horrible crime, but certainly not something that should be left alone.
The feature potential in a switch to convert any doc to PDF, say, is a very strong, though.
I am sorry to offend you or anyone else in the community and I resent your implication that the UAB is insensitive, but I'm sure you didn't intend to be hurtful with your comments. We are working very hard to integrate ourselves into this community in useful and constructive ways. We are absolutely, positively not interested in causing any divisions within the community over small things like what wordprocessing software people use to get through their workdays. Certainly this public flogging is a lesson for us all. From now on, I and the UAB will be sure to 1) post things in PDF or 2) post the entire text of all docs within a posting (thank you, Carl). The UAB was eager to get our "report" out there in time for Heidelberg and I sent Tracy the documents in Microsoft formats - without thinking, of course. Whether I like it or not, Microsoft Office is the MIT/Sloan supported software, so that is what I use. Interestingly enough, as a member of this community, I have never seen a posting of rules and requirements that states that I cannot use Microsoft products; I guess it's one of those unspoken rules no one told me about.
Mea culpa, but today is a new day.
Be nice to the UAB.
It was actually me that posted the document without converting it first.
It might not be so hard to do it server side, but even easier to do it client side.
Thanks, I fully agree, and for users who are paying attention this is what they do. But not all of my users pay attention, for those who are technologically-challenged this is asking a bit much, and we have others who, as soon as you would give them instruction, say "we shouldn't have to do this". I look forward to the day, Talli, when I can buy you a drink so we might evaluate the moral psychology of our users in colorful terms. Until then, I treat every obstacle as "good poopoo" and an opportunity to explore a fix. I leave it up to the developers to decide if, when, and where they might put these fixes into effect. So let's move the question forward: if it is feasible, which is what I'm hoping to find out in this forum, I'll write up a bug report and so toss it into the hopper. Now what does this sound like?
I set up automatic word->html conversion for a client, and I am working on a way to make a more general conversion utility for other formats as well.
Is 6 to facilitate structured converstions (like Winograd's "Conversations for Action" model) or simply a navigational aid?
It would be nice if there were some peoples names attached to the specific things which probably need some iterations to get right (esp 3,6,7, and 10).
I think in what I have been working on for communities of practice I will at least touch on 2,4,5, and 11; and it would be useful to be able to get some feedback if what I have done suitably addresses some of those issues.
thank you very much for starting with concrete details. Although I don't know yet how this discussion may be done best, I don't want to waste time and tell you want I think important about #3 and #10 (not speaking for the UAB here).
For #3, I would be happy to have SOME way to expand and collapse individual postings and subtrees, perhaps with a "+" and "-" toggle similar to windows explorer (sorry, or in Mozilla preferences menu). The most important reason is that, for instance, within the use case of humanities discussions, threads simply become too long to keep orientation within the thread.
For #10, the idea is to allow users to read much text in a narrow pane without being forced to adjust the window width each time they leave a page with wider content (e. g. navigation) and enter a text intensive page. (Narrow reading panes might irritate programmers but are important for text-intensive work, and newspaper columns are therefore narrow since many decades). At the same time, the saved space could be used for breadcrumb navigation in a left-hand side pane instad of wasting space in the top for the breadcrumbs.
Regarding #2, #6, #7, I do think they touch your communities of practice work and I would like to learn more about it.
A short comment on the text width issue. Couldn't this be solved by adding a parameter setting to the module? I mean, weblogger offers a choice to select the number of characters to be displayed and than breaks up the default topic with hyperlink to the full story. That function could be used define the width of the text by changing the definition. (so not CSS related);
"set collum width" or number of characters that identify the text width. from an enduser perspective. It would be a great advantage if users would have access to that function from their "workspace panel".
Hope this is clear.
Here are some examples of framed browsers for long threads: google and gmane. Gmane is nice since it tracks what you have read, and has a collection of well chosen key shortcuts, but it does not let you collapse threads at all.
I think we could take a google style sidebar nav (which is pretty easy to implement) and use Morten's tree menu to construct a collapsable tree menu (the code is BSD licensed so could be included in OpenACS).
And phpBB One thread and One forum The support forum for phpBB has something like 100,000 threads and 500k posts which gives you an idea of how many users of phpBB there are. Sticky threads stay at the top of the front page and announcements are present on all thread pages. The user profile pages are good and presenting post count is useful I think. Another thing to take away from phpBB is how nice some of the themes are.
And in the make your head explode category: ezboard. ezboard has a tremendous number of forums with giant numbers of posts, and there are some useful ideas there, although obviously it's not really intended to support serious persistent threaded discussions.
One of the best things to look at is kuro5hin (sort of slashdot.org but with generally higher quality discussions). posts are rated, can be presented threaded or flat, they distinguish editorial versus topical posts (although to be honest people mostly don't classify them properly).
If you set Display: "dynamic, threaded", you can see the expandable and collapsable threads. I think this might be the closest to what you are talking about for #3.
All the best,
You asked me "Are any of the discussions from Dorothea's course online somewhere that I could look at to get a feel for how deep the nesting is and how long the posts are typically?"
I put an anonymized thread up her http://www.rzuser.uni-heidelberg.de/~x28/911/ .
I'm wondering if you might now review the use cases we've developed for the various features we've assembled on our matic, maybe with reference to the features found on the sites Jeff has kindly offered us, and so evaluate which combinations might best suit our use cases?
A: Very basic functionality, for people who were comfortable with the communication provided by simple listserv lists for the last two decades, and who are ready to take advantage of forums software to take this business out of the (overcrowded) inbox.
D: use for intensive, long, structured discussions, for instance, in the humanities (Dorothea's, see link above). Subcases might be Bruce's ones above, Exploratory or Debating (Problem solving, IMO, is rather "A" obove or "X" below.)
X: Usage where users are trying to extend forum functionality into a direction that might be better accomodated by other types of communcation channels but (for some reason) they don't want to (or may not) adopt these. Examples/subcases include
- users who like to retain their inbox workflow as they did in listserv times
- users who think of more advanced social networking features / communities of practice but do not have blogs, wikis, and the like available yet. (The next use case where all these communication channels coexist and forums plays a very distinct optimized role, is IMO not yet realistic). See #2, #6, #7.
I think we should not waste too much time with trying to conduct serious use case analyses for the forums, because we are not (yet) at the stage of fine-tuning and adjusting to sophisticated special audiences but rather try to accomodate basic usability requirements.
Targeting to single audiences, here, will mainly involve the pre-setting of reasonable defaults. For instance, the default value for expand and collapse could perhaps be "collapsed" for use case D while beng "expanded" for others.
Regarding use cases, it is necessary to be *aware* of multiple uses for the design of the software, but they do not have to be fully fleshed out.
Last but not least. Do not reinvent the wheel over and over again. Jeff posted links to the state of the art. Mimic it. This should take care of the usability that concerns most of the users.
If you want to get serious about Forums, then take a look at the forum developed for the StudIP plattform.
The forum package (on it's own) has been the topic of a PhD thesis from a sociologist and has a ton of features that make the forum useful even in a very complex discussion. I'd change some of the things, but if you want to extend forums beyond a basic approach, seriously take a look at it.
Summary of key extensions (which I found really neat):
- Collapsable Rating and Poster information
- In posting quotes (the quote appears in a seperate box within the posting).
- Relevance calculation (based on views, rating, links)
- Indicator in the front of each posting (esp. in collapsed view), for immediate color coded scanning of relevance, rating or new postings.
1, 3, 5, 8, 9 and 7(perhaps)
The rest of the points I would consider secondary to those above and they could be put on hold until the points above have been implemented.
The PhpBB has always been a favorite for me since there are so many things you can choose to do with it. It seems clean, well-structured and very user friendly.
I have no idea where this gets us, but this is this users opinion.
The two sections have dealt with the forum very differently. I had given both sections clear instructions to post ALL their contributions under the Week 1 header. One section complied very well, which lead to a VERY long thread of contributions. The other section has many individual headers: either they can't read and follow instructions or they instinctively tried to create a personal section structure. The result is very confusing since there is no way to relate contributions for one thread to another and there is no way for me as a teacher to move things to try to do some didactic "housekeeping."
Your contribution showed me how very complex our forum structure is (after only 3 days!) and why I feel the need so strongly for a better tool. Thanks for visualizing this for all of us.
The longer this thread becomes, the more problematical this will become. Matthias can do a wonderful visualization of our own UAB forum structure that will be just as destructive to rational discussion as the present .lrn forum.
Does that mean marking people as favorites and sorting by threads in which they have participated or marking threads as favorites?
Dorothea, are you aware of a phpBB site which does some of the different threading views (#3) that I could look at?
The start of a thread:
There are little drop downs that allow the users to sort as they wish.
Pick "dynamic threaded" or "dynamic minimal".
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
This would be an
where the display
is more narrow than
line width used in
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.
> - 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?
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.
> - Re 9, text input:
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.
> - 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.
Yes, sorting by favorites is in fact part of the
# 2) "Rating" star system on the wishlist, with Bruce's
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.
> - Re 11, improved alerts: We do not
> understand what you mean by "breadcrumb
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
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.
> - 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?
Sorry for that little misunderstanding among ourselves.
> - 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.