Forum .LRN Q&A: Re: Nominclature Cleanup
here is a sample of messages currently used in the dotLRN UI relevant to this discussion:
- <msg key="dotlrn_main_portlet_pretty_name">Groups</msg> (Group occurs in a few other messages such as "Join a Group" etc.).
- <msg key="clubs_pretty_name">Community</msg>
- <msg key="class_instances_pretty_name">Class</msg>
- <msg key="classes_pretty_name">Subject</msg>
Here is my take on the terminology as it currently stands. There are two types of communities in dotlrn - clubs (called Community in UI, i.e. student organizations etc.) and classes (called Subjects in the UI, the word subject doesn't even exist in the source code). As far as "Group" goes it seems to be used in the UI as a synonym for community (both clubs and classes). This means the structure we are dealing with is really quite simple, we just have to make sure our terminology is consistent (and avoid synonyms).
I always found the term subject in the UI quite misleading and I think it should really be class. The question then of course is what to call class instances and I don't really have a good answer to that. Maybe we can get away with not having a term for class instances though. A class instance is simply the community for a class given during a certain term.
<msg key="dotlrn_main_portlet_pretty_name">Groups</msg>
(Group occurs in a few other messages such as "Join a Group" etc.)
My suggestion:
<msg key="dotlrn_main_portlet_pretty_name">Communities</msg>
(this would be one of the few places Communities would show up, because it is one of the few places where "classes" and "clubs" are listed in the same place. The " Join/Drop a Class or Community Group" link that can be found in this portlet would then read "Join/Drop a Class or Group"
Peter's Example:
<msg key="clubs_pretty_name">Community</msg>
My Suggestion:
<msg key="clubs_pretty_name">Group</msg>
This <msg key="class_instances_pretty_name">Class</msg> would not change.
Subject doesn't really belong in this discussion, because it is just a a way of grouping classes. The confusion in the UI comes from there being no way to add a class using the "Classes" link on the admin page (please feel free to try it here: http://dotlrn10-pg-test.dotlrn.collaboraid.net/dotlrn/admin/ ). In order to add a class we have to use the "Subjects" link.
I am not really sure why we should even limit Groups (or clubs if you will) from being associated with subjects or terms. Why shouldn't we be able to associate the "Group" Ancient History Club with the "Subject" Ancient History and the History "Department"? Why wouldn't we want to be able to limit the existence of a group (e.g. Students Against War in Iraq) to one term? What happens when we add Research Communities? They are usually associated with departments and subjects as well.
I do not want to unnecessarily complicate things here (sorry for going off on a tangent). One thing after another.
Sloan has a naming solution that works for their users and because there is a way to define "pretty_names" they do not need to change their way of naming groups, clubs, or communities. Openforce stuck to their guns with the "anything that is not a class is a club" concept, which makes naming them something else in the standard dotLRN install pretty simple.
In the long term we want to keep things simple. We need to think about what kind of communities we are going to be adding to dotLRN in the future and how we can keep confusion to a minimum in the process.
I am not interested in turning everything on its head, but I am very interested in consistency in the standard install before 1.0 goes out the door. We need to decide which way we want to go on this: replacing "Subgroups" within "Communities" with "Sub-communities" or replacing references to "Communities" with "Groups" (and vice versa). The longer we wait on this the more the confusion an inconsistency trickles into the translations that we all have been working on for the last couple of weeks.
