Forum OpenACS Q&A: Bboard for OpenACS non-techies?

While I'm delighted to be introducing people to the wonders of
OpenACS, many of these folks are feeling lost and a bit overwhelmed by
the amount of technical information they need to learn in order to
create ADPs.  No longer is it enough to tell them, "Ignore the stuff
between <%= and %> tags"; now they need to know about masters, default
masters, parameters, <if> tags, @variables@, and the like.

Is there any interest in starting a bboard for non-techie OpenACS
users, such as graphic designers.  The designer I'm working with most
closely right now would very much like to be in touch with her peers.

I'll gladly be in charge of the forum, if such supervision is really
necessary.

Yeah, I was basically thinking along the lines of, "OpenACS graphic designers' forum," or perhaps, "ADP users' forum."  I'm not sure which is really more precise.

We could also call it the "Please don't make me learn Tcl" forum...

Yes I would be interested in a new forum.

However, I would not restrict the forum to designers only. I think the central idea of a new forum should be, to cover OpenACS as a 'PROGRAM out of the box'. 

Why? Most 'guru-people' seem to be working with an adapted version (built upon other systems and/or OpenACS 3.x and older). I'm afraid that is the reason that basic UI's (ef group admin) are not optimal functioning. To be honest, I think I didn't meet anybody at the OpenACS social we had recently (It was fun to be there! Thanks Greenpeace!).who had a complete OpenACS 4.5 site up-and-running (probably my mistake). This made me wonder whether OpenACS is a solution as a 'program' or a development environment; especially when I see practical questions (Out-of-the-box, or new package?) being deferred to dotLRN. 

So yes, let's have a forum that is UI oriented. This would help designers and programmers that use the UI as an interface to understand OpenACS as a 'program'. Probably the community could grow faster. Furthermore, an UI oriented forum would be an alternative way to write practical documentation (!). Let us struggle together with the basic pages/UI that are provided by the standard OpenACS 4 tarball (including adp, tcl, xql, html, vuh files etc) and let's exchange examples. 

My proposal would be to have forum questions TAGGED with OpenACS version-number and UI-names. This approach might help to find 'basic' and 'fundamental'questions at the UI-LEVEL (and the code that is underneath). It will also be easier to find out which features are there and which are not. If we would have a real installation of the latest OpenACS release (hub.org?), with a Bboard widget included on every page, that would even be better. Each widget should be a part of the central bboard, but with UI specific information. Is this realistic ?

I'm not just talking about pretty pictures, but also addressing the glaring usability issues that crop up with OpenACS on an everyday basis. Allowing graphic designers to get together and speak with OUR jargon can only help the project as a whole.

As far as graphics designers contributing to UI discussions ... usability issues for the toolkit at large really belong in our 4.x design forum.  I welcome input from everyone on usability (the fact that there are issues in this area is no secret) but such discussion needs to be in a place where people, both techie and others, will expect it and a "templating for designers" forum won't be where those who will actually implement usability improvements will expect it.

One thing that we're missing from OpenACS.org that seemed to work at least passably well on web/db is the ability to assign different categories to threads in the same bboard. That way people could look in one unified place for recent activity but could also narrow their searches for existing threads to those that are likely to be relevant. if the new 4.5-based site will restore this capability, then perhaps we want to wait and consider which topics need their own boards and which ones simply need their own categories within a larger bboard.

Here's the explanation

Categorization
After a Q&A forum has collected a few thousand messages, it becomes tough for users to find archived threads, even when the software is running on a server with a full-text search engine. Categorization lets you support browsing as well as searching. As the administrator, you are always able to recategorize messages and define new categories. If you want less work and don't mind a little chaos, then you can allow users to categorize their own questions (they get a select menu when they post a new question). If you don't mind a lot of chaos, you can allow users to define new categories.

Present Categorized?  Yes  No

Ask User to Categorize?  Yes  No

Allow Users to Add New Categories?  Yes  No

- OpenACS forum: all OpenACS questions, some categorization

- OpenACS 4 Design forum: OpenACS 4 experienced developer
forum

- OpenACS 4 Testing: for testers

- OpenACS CMS: for CMS (not really all that used right now)

- dotLRN: for all dotLRN issues right now

I agree with Michael that we want cross-pollination. We can also
learn from the OpenACS CMS forum that a forum topic that is too
specific will not work.

Here are the needs we're trying to address:

- forum for newbies

- forum for graphic designers

- forum for OpenACS users/administrators (not programmers).

How can these be grouped? Can we use existing forums and
better categorization to make some of this work? Some initial
ideas on my end:

- a forum for beginners is a good idea to help people become
part of the community

- a forum for non-developer but techno-savvy folks is useful, too
(graphic designers, business analysts, etc...)

- a forum for advanced developers is important. It's probably time
to stop differentiating between 3.x and 4.x at the forum level...

First, self-categorization by each poster within each forum (as Talli suggests), is important for increasing the value of targeting searching.

Second, given that OpenACS docs are notorious for needing improvement, a forum or communication structure needs to be developed that:

1. indicates when documentation fails,

2. helps create new documentation.

3. verifies improved documentation (by showing a lack of "new-history" to use the forum for a previously documented item).

The forums are a perfect resource for documentation development -Think of treating documentation in the same process as any other project: observe, plan, implement (write), verify.

Context of notes are important when creating docs. Does a specific note belong in the beginner doc or the admin doc etc? Right now, I'm sitting with over 400 notes (linked to the various developer-oriented forum discussions) that need to be tracked to documentation somewhere, and if not found, then added. Also, it's not clear to me if certain issues are admin, developer or beginner issues because the context of jargon is unknown --is CM customer management, content management etc.

I have a strong urge to post a question to each noted discussion, asking 1. "has X been added to documentation", and 2. "where?"  But 400+ emails would be obnoxious spamming even if it were to benefit the docs. Who would read and respond to them? So, I'm left with having to assume that most are not documented (likely), and posting to the documentation project --hoping its not redundant.

If the communication about documentation is not directly addressed in the structure of forums, then extra communication is burdened to the community and specificly document writers. Asking similar questions to different noted discussions gets old fast for everyone.

We need:

1. One forum for beginners (definition: if you don't know what classification you are in, use "beginner" [end-users]).

2. One forum for admins (those managing OpenACS [such as html, graphics designers, installers, sysadmins etc],

3. One or more forums for developers. Why not keep the current developer-centric forums for developers?

This structure solves many problems. Including a self-categorizing topic for each poster, as Talli and others recommend, would add to the value of this arrangement.

The thoughts in your post seem to reflect some of the current developer-centric forums (code-maker, code-comparer), and putting everyone else in a beginner's forum. There is nothing wrong with those thoughts for starters, but it is incomplete. The forums need to reflect the documentation for optimization purposes. If marketing documentation will be separate from beginner docs, then there should likely be a forum (or at least a categorization) for marketing as well.

Personally, I subscribe to all the bboards even though I don't understand the highly technical posts. The reason is that its important to pay attention to all of the discussions to at least be peripherally aware of the important projects.

If we had various bboards, we might end up saying a lot of "this is the wrong place for that question, try it over there." The problem is that even the most hardcore of developers could learn something important about improving the system from the most softcore of artists.

That's why I would propose a single bboard with categories. That can be messy, so I'm open to separating them. But I think even Reuven's graphic artists could post to the most technical of bboards and get a good answer.

talli

You ask, "isn't OpenACS.org all about code development?" Partly code development, more specifically (from the homepage):

"OpenACS (Open Architecture Community System) is an advanced toolkit for building scalable, community-oriented web applications. If you're thinking of building an enterprise-level web application, OpenACS is a solid, proven foundation that will give you a 3-6 month headstart."

To me, OpenACS.org is an example [hopefully flagship] site using the OpenACS technology. As an example site, OpenACS.org has an opportunity (and I believe a requirement) to use the tools it creates. If an organization doesn't use the tools it promotes (when appropriate), how effective can the tools be?  This is a primary question that most any decision-maker would ask before considering investing in a system like OpenACS.

Marketing is about identifying the strengths and weaknesses of the system for others to "compare" or analyze according to the opportunities and "threats" [competing strengths] posed by other systems.  A given situation is analyzed in order to find the best solution(s). The comparison of strengths, weaknesses, opportunities and threats helps to identify when OpenACS is an appropriate technology to use.  Creating documentation about the strengths and weaknesses of OpenACS helps lower the barrier of including OpenACS in pool of technologies under consideration --for example when an MBA has limited time and resources to apply to the decision. Or, when someone likes the system and needs a few words to competently state "why".

Now to address the one forum for all scenario:

Like, Talli, I also subscribe to all the boards, though I do not [yet] understand everything. In addition to Talli's reasons for subscribing to all, I am training to develop the system. I swear that half of my problem is based in deciphering the jargon --so many acronyms have multiple meanings --I have difficulty realizing the context. For example, which acronyms are system specific (or have OpenACS specific implications), and which are general to the technology.  Assuming forum categories were detailed enough, I might be able gain more understanding of context from them. So, I fully agree that the forum(s) should support categories.

However, categories have their own problem: sometimes (frequently?) a discussion or message includes multiple categories. Marking checkboxes (instead of a drop-down menu) would alleviate this concern.

Would users be able to choose notification of board messages based on selected categories?

Even though Talli and I like all the messages in the mailbox, I'm certain that many others will prefer to be notified of messages relating to only some categories.

Reuven's point about having to create a forum that cater's to the less initiated is important for three reasons. 1. OpenACS needs to get as much feedback from externals as possible, to further it's individual-community serving goals for the technology. A separate forum with a link from the homepage (or an introduction page) may help to this end. 2. The feedback needs to be appropriate and useful. 3. The feedback and recorded dialog become great first drafts for improving documentation.

Each website using OpenACS probably should have their own end-user feedback forum of sorts to help end-users adjust to the system. Yet, think of how much effort addressing these issues would have to be duplicated from site to site. An OpenACS forum dedicated to end-users and their problems with the system would help create documentation, verify the documentation is working, and identify weakpoints in the user interface and end-user expectations for developers. Developers will know where to go to find the feedback without having to depend on secondary accounts and administration-centric analysis.

In the current forums, Reading The Fine Manual (TRTFM) is expected [which it should be for developers and admins], but end-users should have their questions answered regardless. They shouldn't have to read a manual or do much more than browse a list or table of contents... and then post a question if their answer is not found within a minute or so.  Right now, I know lots of people who are curiously interested in Openacs.org, but their eyes gloss over when get to openacs.org because it does not have a place oriented to people who might not understand or be aware of the open-source culture, the technology used by OpenACS etc. Yet, these are the target end-users who will promote the technology when they eventually use it and come to like how it works. As Reuven states, they "will go a long way toward helping spread the OpenACS gospel." We need to support them in it.

Is Ben's suggestion ('a user bulletinboard, where people could refer to the functionality they see') an option for user-forums (end-user, designers, admins)?

I reviewed the link and service you setup.  It does not show what I described, but that is my fault for not describing well. My last message was created when I was in a meditative state... Trying to understand it may be hazardous while operating heavy machinery --could make readers drowsy! =)

I'll restate:

Using the board system, a user can choose to be notified of any activity in a forum or message thread.

What if the person only wants to view messages most directly relevant to their current user-type tasks (end-user, admin, developer)?

Case1: If there is only one forum (and multiple categories), then...

there is no easy way to limit message threads to those most directly relevant to the user. For example, if an admin only wants to track admin related discussions, the person must subscribe to all forum discussions and then turn-off alerts relating to discussions of no interest, or using the search function, regularly find admin-related discussions and set alerts "to be notified of new messages on this thread". This case is burdonsome for anyone who wants to limit message notification to the most relevant (directly connected) to their situation.

Case2: If one forum for each user-type: end-user, admin, developer, then..

A person sets alerts (subscribes) to the forum of their user-type. By setting the alerts at the forum level, they will be notified of all ongoing discussion (and new threads) within the forum automatically. No additional work needs to be done by the user. An admin will be alerted when admin-related issues develop in the forum. An end-user will be alerted when other end-users have problems (and can help describe how to solve problem in language other end-users understand [few jargon]. A developer can focus on developer-related issues when immersed in coding a package without distractions from other discussions.

Anyone can always subscribe to all forums. In case 2, the ones who want to have only directly relevant messages will be catered to also. There is no burden on users to limit messages to the most relevant ones.

Let me know if this is unclear.

Again, 3 forums, with multiple categories per message/discussion thread, should cater to most everyone's needs.

One of the goals of the APLAWS project seems to have been to allow such categorisation of content based on a single meta-data standard for ALL local authorities in the UK. Sharing a single metadata standard allows for easier sharing of information.

More important than sharing a single metadata standard, is the ability to categorise all the information on a site. One of the bad thing about most organisations' websites is that they reflect more the internal structure of the organisation, instead of providing information in the way that users would look for it.

I see similarities on this board. We are looking to seperate users by skill ... advanced/intermediate/beginner, or by job description ... developer/designer/analyst. Whichever way we seperate the boards will be inadequate for a "site-virgin" looking for information because a thread started in one board will invariably interest an audience in another. Additionally, information exists in other areas as well, from wimpy points, to uploaded files. I know you can crosspost, but can we rely on someone doing this regularly?

Rather, I propose being able to implement categorise information based on one metadata set for the entire site. In this way, information (be it articles, news items, entire forums, individual bboard posts) can be tagged by target audience (designers, analysts), their competency (advanced, beginners) and the category (page design, advocacy, kernel hacking).

Information tagged in this way means users are able to search for it in a way that makes sense to them, which may or may not be the way this group sees things. As an example, I might search for all beginner level information relating to hacking the openACS kernel. Alternatively, I might search for advanced templating information.

There is already a plan to add this feature with a site-wide category tree that can be mapped to package specific category trees.

See this thread:
https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0003xq&topic_id=12&topic=OpenACS%204%2e0%20Design

Someone just needs to finish the data model anad work on a interface so packages can take advantage of the service.

You are right. I just spend the last 5 hours filling my FAQ module with issues based on recurring questions on the BBoards, categorized per subject. I assume it will take me another 2 days to have categorized all serious questions. That will give me a reasonable insight in where problems are encountred,a nd how hackers have managed so solve them. I am nontechie, but after using OpenACS for 14 months, have a pretty good idea what people are asking. Many of the problems have been my nightmare too.

From what I can tell now, manny problems have allready been solved in new releases, ie. the current bboards could do with a cleanup. I gusee all it takes is activate the archive fucntion in admin section, because that will allow to set a time for display of active subjects based on date. (so old topics are still available).

Once the onetime cleanup is done, maintaining the bboard and follow up on important issues is not realy that difficult to monitor. atleast using the datefuction in admin will be a great help.

Effectively all it takes is one volonteer to keep track of issues. I guess that's the basic problem we are running into with the current bboard.

As much as I like the ideas that have been tossed around regarding how to make life easier for newbies, we've strayed far from my original suggestion.

I'm asking for a place where people who have no interest in programming can learn to use OpenACS templates (and applications, I guess). These people are new to OpenACS, but they're not new to the Web or to computers.

Lumping these people together with newcomers to OpenACS is inaccurate: Newbies want to learn the data model, the user-defined functions, the Tcl API, and so forth. Designers don't know and don't care about such things. They just want to get their designs up and running as quickly and intelligently as possible.

Aldert's suggestion about a "code users" forum, separated into categories as necessary, sounds like the closest to what I was originally talking about.

Again: I'm totally in favor of making OpenACS more accessible to new hackers. But if we want OpenACS to move forward, we've got to provide support, and preferably community support, for people who hear the phrase "data model" and imagine a well-dressed computer on a fashion runway in Paris.

I'm part to blame for the confusion between using "newbie" and "non-techie". To clarify, for my usage, "newbie" refers to anyone who is a non-techie, including those graphics designers who want to create content for an OpenACS system. Newbie does not necessarily (but can) refer to someone who has little internet experience.

I also mentioned how a "newbie" (new-person to OpenACS) with appropriate developer expertise (or OpenACS admin related expertise) could start directly in the technically advanced forums.

Graphics designers who also have interests in UI may want to participate in an admin forum as well as (or instead of) the "newbie" forum.

The choice is individual, but the options need to be there for everyone to get the more effective use of the OpenACS community --the the OpenACS community the most affective use of them.

If developers are concerned about unanswered or inadequately answered questions, they are free to participate in the forums for nontechies and admins also. These are not exclusive forums. As a developer-in-training, I would subscribe to all of the forums. The forums become a direct resource for helping to track inadequate documentation --and updating it, as well as the obvious service to nontechies and admins.

With regard to the newbie forum, think of it this way: if you're a newbie, and you really want to get a question answered, would you ask in the newbie section, or in the experienced developer section? I'd go for the experienced developer section any day.

I also don't like the division it creates in the developers. I think we need to see the cross-fertilization going on.

That said, I do see a need for something better than what we have now.

I put together a mockup of how my ideal version of the bboards and the documenation. It's in this thread: https://openacs.org/bboard/q-and- a-fetch-msg.tcl?msg_id=0004wL&topic_id=OpenACS&topic= 11 Make sure you click on the "navigation" link at some point, and follow the * to see the valid links.

What I liked about this particular way of viewing the bboards is that you could set up email alerts for only the types of messages you were interested in (make sure you see the "navigation" page.

I think we should focus on creating better documentation for new users, and focus on making it as easy as possible for them to be expert users. I would rather see some very easy intro guides for users than a separate forum.

The reason this doesn't seem like such a great idea to me, though, is that is reminds me of the problem set forums of old. Those forums were maybe helpful for a few people, but it seems like the real questions had to be asked on web/db to get an answer.