Group Wikis: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(removed About Me section) |
||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
This is a Google Summer of Code 2008 proposal, any and all feedback is greatly appreciated! |
|||
==About== |
==About== |
||
I would like to implement a feature which would allow groups to be able to quickly and easily create wiki-style pages for the facilitation of collaborative work. A group, in this sense, could be: an entire class, several students working on a project, teachers planning the curriculum, friends collaborating outside the classroom, etc. |
I would like to implement a feature which would allow groups to be able to quickly and easily create wiki-style pages for the facilitation of collaborative work. A group, in this sense, could be: an entire class, several students working on a project, teachers planning the curriculum, friends collaborating outside the classroom, etc.This idea is in a way very similar to the [[OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Bulletin_Boards | Bulletin Board]], the difference is that users of a '''Group Wiki''' interact through wiki pages (most likely via [[MikMik]]) rather than a contextual chatting interface. I should note that Group Wikis are not intended to be a replacement for the Bulletin Board idea, there are appropriate times for both. |
||
This idea is in a way very similar to the [[OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Bulletin_Boards | Bulletin Board]] the only real difference is that users of a '''Group Wiki''' interact through wiki pages (most likely via [[MikMik]]) rather than a contextual chatting interface. I should note that Group Wikis are not intended to be a replacement for the Bulletin Board idea, there are appropriate times for both. |
|||
==Use Case== |
==Use Case== |
||
| Line 12: | Line 12: | ||
:There are a few things wrong with using forums for collaboration. For one, forums are organized temporally, so to get a good idea of what's being discussed you have to read every post from the start of the thread to the end. Also, collaboration is not just discussion, students will want to do things like draw up lists of goals which can be modified over time This is trivial with a wiki, but really doesn't work with forums. |
:There are a few things wrong with using forums for collaboration. For one, forums are organized temporally, so to get a good idea of what's being discussed you have to read every post from the start of the thread to the end. Also, collaboration is not just discussion, students will want to do things like draw up lists of goals which can be modified over time This is trivial with a wiki, but really doesn't work with forums. |
||
====Why not a contextual chatting interface?==== |
====Why not a contextual chatting interface like the [[OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Bulletin_Boards|Bulletin Board]]?==== |
||
:Contextual chatting is very nice for quick notes, and for working in real time with others, but they're very limited in a number of ways. |
:Contextual chatting is very nice for quick notes, and for working in real time with others, but they're very limited in a number of ways. For example, it's not obvious how one should display more information than can fit on a single screen, this could be a problem for long projects with complex goals which need to be described at length. Also, they lack the versatility of wikis for dealing with changing content (such as, again, a list of goals). Lastly, because wikis are capable of doing version control, they're much better suited for dealing with individuals who have sporadic connectivity. |
||
While wikis are less intuitive than the other options, they provide of level of control and scalability which is far superior to both. Plus, there are a number of wiki applications already available, such as MikMik, and |
While wikis are less intuitive than the other options, they provide of level of control and scalability which is far superior to both. Plus, there are a number of wiki applications already available, such as [[MikMik]] and MediaWiki. Given this, as well as the fact that wikis are becoming more and more common on the internet, we can likely assume that students and teachers will familiarize themselves with the wiki format and that the comparatively steep learning curve of wikis will be counteracted by their prevalence. |
||
==Implementation== |
==Implementation== |
||
<div class="messagebox"> |
|||
====The Wikis==== |
|||
An earlier version of this proposal discussed integrating the wiki feature into the group view screen, those |
|||
:The wiki pages will be generated, viewed, and edited through [[MikMik]]. When a user pushes the Wiki button on the group view screen, MikMik will attempt to open the groups wiki page. If the page does not yet exist a new page will be created for the group. This means that each group will need a unique identifier, so that the program will know where to look for the group's page if it already exists. The simplest way to do this would be to have the wiki page's name be the same as the unique identifier, but this isn't very user friendly. So, say the unique identifier was “abc123” one thing that could be done is a page named “abc123” could be generated, and the user could be prompted to give a more suitable name for it, and then “abc123” could be made into a redirect to that new name. |
|||
sections have been moved to the [[Talk:Group_Wikis|discussion page]]. |
|||
</div> |
|||
:Potential challenges: |
|||
Ideally this feature would be integrated directly into the [[OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Zoom_Metaphor#Groups|group view screen]], unfortunately this is not possible as Groups have not yet been implemented and may not be for some time. However, there are several other ways in which this could be implemented. The most viable, I believe, is to extend [[MikMik]] to include a simple, yet intuitive, group management system. If the MikMik developers do not want this functionality, a separate activity could be built with the sole purpose of managing groups. |
|||
| ⚫ | |||
| ⚫ | |||
:A “Groups” namespace could be created where all of the Group pages are held. To start a group you simply create a page within that namespace -- tools should be created to make this process as simple as possible. |
|||
| ⚫ | |||
====Group Membership==== |
|||
[[Image:GroupWikiInvite.png | right | Group Invite Mock-up]] |
|||
:The creator of a group should be added to it automatically. Other users should be able to join a group in one of two ways |
|||
:Based on: [[OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Zoom_Metaphor#Groups | Zoom Metaphor#Groups]], I believe this is something which is planned, but has not yet been implemented. Users should be able to select peers in their neighborhood view and invite them to join a group. The user should also have some means of visualizing the groups s/he belongs to through the Group View screen, and a way of selecting a group to “zoom in” on it. As of yet, I do not believe the ability to belong to multiple groups has been implemented. It appears that the group view screen currently functions more like a friends list than like what was defined in the Human Interface Guidelines. Working on this by myself would almost certainly take the entirety of my Summer of Code time, so I'm hoping that there is either work already being done on Groups or that other people would be interested in working on it. If not, I would be willing to revise my proposal to work on Groups instead. |
|||
::'''Case 1''': When a user browses to a page in the group namespace they should be presented with the option of joining that group. A button in the activity's toolbar would be appropriate. This button should always be present, but should be disabled when a users is not on a page in the Groups namespace. |
|||
::'''Case 2''': Users should be able to join a group by invitation. Ideally this would be done with notifications, but the creator of a group could also just share her/his activity and invite others to it through the neighborhood screen. |
|||
====Managing Groups==== |
|||
:There should be a screen, very similar in appearance to the Journal, which lists the groups one belongs to and has options for viewing group pages, removing yourself from a group, marking a group as a favorite, and inviting new members to the group. |
|||
====Misc. Challenges / Implementation questions==== |
|||
| ⚫ | |||
:*Should there be a way to make groups invite only? Might this be detrimental to the read-write culture which wikis inspire? |
|||
==Schedule== |
==Schedule== |
||
{| border=1 |
{| border="1" cellspacing="0" |
||
! Date !! Goal |
! Date !! Goal |
||
|- |
|- |
||
|April |
|April 21 - May 26 || Get better acquainted with the community and the software. During this period I'll familiarize myself with the code base, and determine exactly how to go about implementing Group Wikis. Towards the end of this period I will draft up a comprehensive time line for the remainder of the project. |
||
|- |
|- |
||
|May 26 || Programming begins |
|May 26 || Programming begins, Time line posted here. |
||
|- |
|- |
||
|Mid-Late June || |
|Mid-Late June || The namespace for groups should be created and the MikMik toolbar should have a "Join this Group" button which is aware of the page the user is on. Work on the groups list begins |
||
|- |
|- |
||
|Mid July || Groups list should be nearing completion |
|||
|Mid July || A rudimentary UI should be in place by this point. Autogeneration of wiki pages should be complete, and I should be able to create a group, by some means, within sugar even if it's not pretty. |
|||
|- |
|- |
||
|August 6 || All features that will be present in the final version should be in place by this point. |
|August 6 || All features that will be present in the final version should be in place by this point. |
||
| Line 45: | Line 52: | ||
|} |
|} |
||
[[Category:GSoC_proposals]] |
|||
==About Me== |
|||
I'm a student at Hampshire College where I am studying cognitive science in relation to computer science. Students at Hampshire have a tremendous degree of freedom not just in what they study, but how they study it, and for me that primarily means working on self directed projects. I design and implement software (and recently hardware) projects on a regular basis and I'm very comfortable doing so. Some of my recent projects include a wiimote controlled MIDI synthesizer, and an EEG signal classifier which utilized genetic programming techniques. I've worked on open source projects before (though none nearly as large as Sugar), including a few which I initiated (such as, http://sourceforge.net/projects/pygame-console/), so I'm comfortable with the tools involved. |
|||
====Why OLPC==== |
|||
:I truly love open source; there are very few things I believe in more than the vision of free culture as a liberating, empowering force. I had, of course, heard of OLPC before Mako Hill came to Hampshire (his alma mater as well) a few weeks ago to talk about it, but at the time I still thought that it was just a laptop project. I didn't know anything about the project's commitments to education, freedom, and open source -- hearing about those things really impressed me. I'm inspired by what the OLPC project is trying to do, and I would love to be a part of it. |
|||
====Misc==== |
|||
I would be able to travel to Boston at some point during the summer. |
|||
Latest revision as of 07:11, 2 June 2008
This is a Google Summer of Code 2008 proposal, any and all feedback is greatly appreciated!
About
I would like to implement a feature which would allow groups to be able to quickly and easily create wiki-style pages for the facilitation of collaborative work. A group, in this sense, could be: an entire class, several students working on a project, teachers planning the curriculum, friends collaborating outside the classroom, etc.This idea is in a way very similar to the Bulletin Board, the difference is that users of a Group Wiki interact through wiki pages (most likely via MikMik) rather than a contextual chatting interface. I should note that Group Wikis are not intended to be a replacement for the Bulletin Board idea, there are appropriate times for both.
Use Case
Four students, Ally, Bill, Chris, and Dana, are working on their science fair project about ocean waves. Ally starts the group and invites the other students, she also types up a short description of the project and a time line showing when things need to be finished. Bill gets on the wiki and notices that Ally forgot to mention that a draft of their paper is due next Wednesday, so he adds it to the time line and also posts a link to a great website he found. Over the next few days the students share their notes and resources through the wiki and discuss what information should go into the paper. Chris and Dana, who have agreed to create the poster, add pictures of waves which everyone comments on to decide which should be used. Ally and Bill, who wrote a draft of the paper in a shared write activity, add it to the wiki for the others to see. They're able to fix mistakes and add new information right on the wiki page, if they decide they don't like a change that was made they can revert to an earlier version using the wiki's history.
Why Wikis
One might imagine that the functionality I'm describing could be implemented with traditional bulletin boards, or with something like contextual chatting interfaces, so why bother with the overhead of wikis?
Why not traditional forum-style threads?
- There are a few things wrong with using forums for collaboration. For one, forums are organized temporally, so to get a good idea of what's being discussed you have to read every post from the start of the thread to the end. Also, collaboration is not just discussion, students will want to do things like draw up lists of goals which can be modified over time This is trivial with a wiki, but really doesn't work with forums.
Why not a contextual chatting interface like the Bulletin Board?
- Contextual chatting is very nice for quick notes, and for working in real time with others, but they're very limited in a number of ways. For example, it's not obvious how one should display more information than can fit on a single screen, this could be a problem for long projects with complex goals which need to be described at length. Also, they lack the versatility of wikis for dealing with changing content (such as, again, a list of goals). Lastly, because wikis are capable of doing version control, they're much better suited for dealing with individuals who have sporadic connectivity.
While wikis are less intuitive than the other options, they provide of level of control and scalability which is far superior to both. Plus, there are a number of wiki applications already available, such as MikMik and MediaWiki. Given this, as well as the fact that wikis are becoming more and more common on the internet, we can likely assume that students and teachers will familiarize themselves with the wiki format and that the comparatively steep learning curve of wikis will be counteracted by their prevalence.
Implementation
Ideally this feature would be integrated directly into the group view screen, unfortunately this is not possible as Groups have not yet been implemented and may not be for some time. However, there are several other ways in which this could be implemented. The most viable, I believe, is to extend MikMik to include a simple, yet intuitive, group management system. If the MikMik developers do not want this functionality, a separate activity could be built with the sole purpose of managing groups.
Creating a Group
- A “Groups” namespace could be created where all of the Group pages are held. To start a group you simply create a page within that namespace -- tools should be created to make this process as simple as possible.
Group Membership
- The creator of a group should be added to it automatically. Other users should be able to join a group in one of two ways
- Case 1: When a user browses to a page in the group namespace they should be presented with the option of joining that group. A button in the activity's toolbar would be appropriate. This button should always be present, but should be disabled when a users is not on a page in the Groups namespace.
- Case 2: Users should be able to join a group by invitation. Ideally this would be done with notifications, but the creator of a group could also just share her/his activity and invite others to it through the neighborhood screen.
Managing Groups
- There should be a screen, very similar in appearance to the Journal, which lists the groups one belongs to and has options for viewing group pages, removing yourself from a group, marking a group as a favorite, and inviting new members to the group.
Misc. Challenges / Implementation questions
- We'll want to delete unused group pages after a while so as to prevent bloat and namespace crowding, how do we determine when to delete a page? Should a group be deleted if it has no members?
- Should there be a way to make groups invite only? Might this be detrimental to the read-write culture which wikis inspire?
Schedule
| Date | Goal |
|---|---|
| April 21 - May 26 | Get better acquainted with the community and the software. During this period I'll familiarize myself with the code base, and determine exactly how to go about implementing Group Wikis. Towards the end of this period I will draft up a comprehensive time line for the remainder of the project. |
| May 26 | Programming begins, Time line posted here. |
| Mid-Late June | The namespace for groups should be created and the MikMik toolbar should have a "Join this Group" button which is aware of the page the user is on. Work on the groups list begins |
| Mid July | Groups list should be nearing completion |
| August 6 | All features that will be present in the final version should be in place by this point. |
| Aug. 6 - 18 | Testing and bug fixing. |