Educoder present and future (educoder@googlegroups.com)

[Turadg Aleahmad (Google Docs)]

I've shared Educoder present and future

Click to open:

• Educoder present and future

Understanding Educoder

Differences from related communities

1. Most mainstream software development (some of these are similar to startups)

1. Requirements constantly changing
2. Runtime configurability for hypothesis testing
3. Used by messiest users, children
4. Small development teams
5. Very specific context (really diff?)
6. Low hierarchy (really diff?)
7. Devs wear many hats

2. Almost all mainstream software development

1. Disposable software (prototypes made fast, cast aside)
2. Gratifying sense of social and/or scientific impact
3. User is not the customer (teachers make the choice for students)
4. Slow evaluation cycle (learning takes time, can’t just ask if learned)
5. Boss (researcher) will screw users to answer a question

3. Other research fields

1. Software must work in treacherous classroom setting
2. Design must be clearly communicated
3. Many iterations of designs (prototypes)
4. Wish your prototype could scale to be used by many
5. Highly collaborative/interdependent (across disciplines, timezones)
6. Availability of cheap/free students

Stakeholders

1. software developer working on edtech

1. UX, frontend, backend
2. driven by social impact
3. prefers Edtech but wants to develop general skills

2. PI

1. needs efficient effective development for research

3. theory-driven PhD student

1. depends on a particular implementation to run their study
2. hard to

4. tech-driven PhD student

1. hybrid who implements some or all

5. Societies like ISLS

1. Want to promote relevant ed tech design and research

6. Corporations

1. Want to promote their brand, be associated with altruism
2. Recruit good talent
3. Mine good ideas
4. Have non-proprietary dependencies managed responsibly

---

SWOT analysis

Strengths

1. brand within the community
2. strong participation in person
3. bond-based community
4. at meetings, exposed to new technologies and approaches

Weaknesses

1. low participation online
2. no future funding
3. no shared goals of community members
4. poor historical knowledge, repeating same mistakes

Opportunities

1. define a mission
2. invite similar groups to participate: NetLogo, Phet, Kahn, TERC, Umich, EDC
3. make participating in Educoder a part of project budget and dev responsibility to project
4. support novice programmers (e.g. interns, undergrads)
5. post-mortem on projects to articulate lessons learned (e.g. SAIL)

1. lots of design documentation internally already

1. Official connection to larger organization

1. annual SIG meeting at ICLS, CSCL?

2. Use brand to promote projects and people

1. “vimeo channel” of products
2. Job postings

1. discuss breaking news
2. why Educoder?  Share resources

1. suggest code management systems, design tools, online communities
2. promote certain code libraries or paradigms
3. publish our own code solutions Leilah: related: we may wish to catalogue our own “best practices / design patterns” suggestions, perhaps organized by problem type - so not just a matter of publishing the code, but also the “if condition” that leads to the code “If you need a system that does X, try Y, and here’s some sample code”

1. where and why? Publish and discuss design methods
2. need more concrete  Discuss technology purchases and platform decisions
3. what does this mean? Support collaborations (e.g., WISE 4, S3, Netlogo, ?)

Threats

1. if trips stop, devs stop participating
2. growing the group could displace key participants
3. officialness could make it less fun

Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations.