SCoPE

 

Focusgroups

Page history last edited by Sylvia Currie 2 yrs ago

Summary of Focus Sessions

 

Group 1: Activities

1) The community needs to be real and familiar to the users.

For example:

  • Much of the information should come from the community members themselves and/or should reflect their experiences.
  • Integrate actual case studies.
  • Faculty need to be seen as leaders of community.
  • The technology used should be familiar to the community members.

 

2) We can encourage membership and participation by ensuring the community is quick to access and use.

For example:

  • Use technology that community members are familiar with and are most likely using already.
  • Eliminate/minimize the use of technology requiring any set-up, plug-in etc.
  • Provide a variety of access points to the community.
  • Implement good search tools and good metadata tagging.

 

3) The community should be useful.

 For example,

  • Content should be brief, concise, and easy to find.
  • As mentioned above, include actual case studies / knowledge sharing that reflect community members' experience.

 

My commentary and interpretation for community design

 

The emphasis on the site being practical and efficient combined with the suggestion that content should be contributed by members, really highlights the shortcomings of existing community tools. Often excellent ideas and stories are generated through a discussion, but it becomes quite the task to later wade through the content to find the specific pieces of information.  

For example, take the case study idea. If an instructor posts a story about why and how he developed a new grading system, then that post could be tagged with some categories (case, tool, reference, myshelf, etc) and transformed into a valuable resource. Another instructor arrives at the site much later looking for assessment idea, finds the grading tool, uses it, contacts the original developer of the grading tool with some questions about the tool, then contributes a refined tool back to the site. The original resource was generated through a forum discussion, but becomes a reusable resource that can be searched, changed and annotated.

This model leaves the context in which the resource was generated intact, and also makes it available in a new context.

 

Group 2: Community Environment

1) Design to cater to different levels of engagement

For example:

  • experienced designer vs text-based user  
  • keeners vs apathetic vs hostile
  • newsletter  
  • international flavour (different languages?)  
  • design for online/offline participation (email, conferencing threads)  

 

2) Metaphors to improve engagement in community

For example:

  • cannot be too cutesey  
  • must have meaning, make sense  
  • not too culturally oriented - sensitive  
  • university campus?

 

3) Make community welcoming

For example:

  • email discussions  
  • meme (shared ideas)  
  • rich resources, not just links to sites  
  • resource contributions?  
  • seed discussions to try to bring people in  

 

4)  Validate acceptance of community environment

For example:

  •  levels of participation  
  • foster keeners - bring in antagonists/sceptics into discussion  
  • catch users on first hook  
  • don't promote on broad scale unless there is demonstrable momentum (phased release)  

 

My commentary and interpretation for community design

 

This focus group highlights that we are designing for a broad group in terms of skills, cultural backgrounds, philosophical beliefs, and attitudes. Given that, we need to consider different elements that will ensure the community environment is inclusive yet appealing to everyone. The use of site metaphor appears risky. However, metaphors to convey spaces within the community could be helpful, particularly if they are selected by members. The issue of what to name the community remains!  

 

Group 3: Sustaining the Community

1) Community convener and maintenance person needs to be remunerated.

 

2) Sustaining and project/event funding is required

For example:

  • Sustaining sponsor(s) such as SFU, other universities, Telus, VanCity
  • Project/event sponsor(s) such as BCCampus project funds, course fees

3)  Community must encourage and be responsive to member ideas and suggestions.

 

My commentary and interpretation for community design

 

Each point addresses sustaining the community on a unique level. The community convener has a very visible role – organizing and facilitating events, etc., as well as a less visible role in keeping the community healthy. That role is too complex to easily share with someone else. The maintenance person also obviously has an essential role.

The second point brings to mind the question of timing. Sponsorship dollars are necessary to establish the community as being worthy of sponsorship dollars! We need to develop a “what’s in it for you” list to present to potential sponsors. What are some things this list could include? The third point, “encourage and be responsive to member ideas and suggestions” is a big one, and we’re in an ideal situation. With so much in-house expertise at eLINC we can be responsive. We need to dream up some ways to encourage ongoing feedback from members. Ideally members should be able to offer these ideas as they come to mind.

 

Group 4: Research

This group looked at research from two perspectives.

1) Research that must be done before the community is launched.

For example:

  • Begin with a needs analysis.
  • What role or need is out there that this community will fill?
  • An examination of how the technology affects the community.  

 

2) Research once the community is launched and active.

For example:

  • Study the structures and processes relating to 'power' within the community.
  • What is required of an individual wanting to gain entrance to the 'community'?
  • Once in the community how does that individual gain influence, status and power?

 

My commentary and interpretation for community design

 

The 2 perspectives presented by the research group are important and broad. The first description ties in with comments raised during the full group session -- that we need to be using the latest technologies, and be responsive to the changing needs. This “needs” research could (should) also be ongoing research.

The interesting part of community work is that new needs emerge through participation, and sometimes these new needs are identified rather informally. The most useful information can be gathered through participatory and also unobtrusive research methods. For the community environment design, we need to keep in mind the value of having access to the participation data (perhaps ways of tagging messages that are related to design and support needs) and some of the behind-the-scenes activities and patterns of use.

The second perspective, the structures and processes relating to 'power' within the community, is a fascinating topic. One way to look at this is the evolution of roles in the community, from newcomer to gradually taking on new responsibilities, to giving back to the community and becoming involved in sustaining and advancing the community. There are so many factors at play – comfort level, acknowledgement, recognition, identity, power, etc. Gradually members come to understand the culture and become comfortable with the environment (certain actions become internalized).

In planning for research for the SCoPE community there are many questions to be addressed. For example, should we ask members to specify from the beginning their willingness to participate in community research? How can we anticipate and plan for future needs for research in the community?

 

Session 2: Technical and Design Team

The afternoon session was with the eLINC Technical and Design Team. We discussed community design process, options for tools to support the community, and lessons learned. This session was an extension of the morning discussions. The following agenda was distributed to guide the discussion:

1) Overview of morning session

2) Discussion of immediate needs to prepare for pilot

3) Discussion: Open Source or Proprietary or both

4) Exploration of software choices

5) Elements of community life which technology can affect

a) Presence and Visibility

b) Participation

c) Knowledge management

d) Membership and Identity

e) Evolution

6) Next steps in design

Much of the discussion during this session focused on available tools, the pros and cons of building from the ground up, or of customizing existing tools to respond to immediate and emergent community needs.

Several advanced features were identified as necessary to present our community as unique, appealing, and scalable. Also, a recurring theme for the community environment design was to understand needs for newcomers, and that these needs will evolve over time. The group was mindful that members need to be involved in the process and that our design efforts should be focused on the pilot and community launch, with the idea that the community environment will evolve based on participation research and feedback from community members.

It was decided during this session that the community environment would be designed in house, rather than build on existing open source and proprietary software. However, the environment could hook in to existing tools, and the design specifications will reflect recommendations from the research phase.

Comments (0)

You don't have permission to comment on this page.