Final Project

All that we ask is that you build something of interest to you, that you solve an actual problem, that you impact education, or that you change the world. Strive to create something that outlives this course. — from Harvard's CS50 Final Project (modified to reference education)

We see a lot of solutions without problems — anonymous Venture Capitalist about reviewing Startup proposals

Your task is to create an app (web, mobile, or desktop) focused on helping people to learn something better that includes some way of assessing that learning occurred.

It can be an original idea, an innovative solution to a problem, a improved version of an existing resource, or an existing app modified towards an educational issue. Your working prototype may be supported by non-running wireframes that clearly describe how additional features may work that you do not have the expertise, computing resources, or data to develop. Your app's exact programming language and user interface are up to you.

Make what you are planning on doing ambitious to the point of impossible, since you can use Al. Does it involve a website? You should commit to creating a prototype working site, with all-original images and text. I won't penalize you for failing if you are too ambitious. Any plan benefits from feedback, even if it just gives you permission to discuss what might go wrong. Ask the Al to give you 10 ways your project could fail and a vision of success. And, to make it interesting, ask three famous figures to criticize your plan. You can invoke entrepreneurs (Steve Jobs, Tory Burch, Jack Ma, Rhianna), leaders (Elizabeth I, Julius Caesar), artists, philosophers, or any other people you think would be useful to critique your strategy in their voice. Figure out a prompt that gives you good results, give me the results, and tell me what, if anything you learned from it. From an assignment discussed on Ethan Mollick's Blog (a vocal proponent of incorporating AI creatively in education).

To succeed, it is vital to focus on a Minimum Viable Product (MVP): building your app incrementally, in small manageable steps, that keep things simple, and allow you to learn about the impact of your ideas. Letting users interact directly with the unique, interesting, or challenging features of your app early and often (while some changes can still be made) is also a vital part of the iterative process.

You may work by yourself or in a group. Group projects will have greater expectations since more people will be working collaboratively. If you are unsure of your idea, feel free to discuss it with me first.

Your final grade will be determined subjectively based on how consistently you work on the project, how well you justify its value to improve an aspect of education, and how useful it is viewed by your identified stakeholders.

Resources

Possible Sources of Ideas

• EduLearn Conference and past conference meetings
• SXSW EDU and past conference schedules
• Intelligent Textbooks workshops

Giving Demos

• Slides with DOs and DONTs advice from a previous project course
• 7 Tips for Pulling Off a Great Demo Presentation from Lifesize
• 20 Outstanding Examples of Software Demos with explanations and tips (at the bottom)

Deliverables

Fork the assignment repository to make your own personal area to work in and use GIT to push your agent to it. You must push your progress each week and for at least the following deliverables:

Proposal

Describe your idea in a Markdown file named Proposal.md, that includes at least the following:

• Name(s). Everyone's name who plans to contribute to the project (note, I reserve the right to combine similar projects)
• Goals. Describe the app you want to build and what problem(s) it solves
  • what specifically from the project's area or domain can be leveraged in your solution
• Target Users. Describe what kind of learner you are targeting
  • conduct at least one empathy stakeholder interview with at least three people to get other perspectives on the problem you are addressing
  • develop at least three personas to represent potential users
  • justify how your personas inclusively capture important traits of your target users (this worksheet may be helpful)
• Value. Describe how your project will help people learn something better:
  • the pain points in the current processes used
  • what will be improved or changed by this project
  • what makes it useful and different from what already exists
• Impacts. Describe your project's possible impacts, referring to your personas for justification and including:
  • positive and negative impacts
  • inclusive and exclusionary impacts
  • any possible ethical considerations
• Data Needs. Justify the user data you think your project will require (follow Lean Data practices to minimize your data needs)
• Scope. List the features your project will need to implement to be successful, categorized into
  • simple: required features to minimally convey your project's core novelty
  • lovable: expected features to give your project common conventional value, make it user friendly, or provide more robust functionality
  • complete: stretch goals that you might be able to implement for a truly successful project

Wireframe

Letting potential users interact directly with your app early and often, while changes can still be made, is a vital part of the iterative process and should be welcome. Thus, create Wireframe(s) of your project's key elements that make it distinctive or interesting in a way that can be shared, commented on, and easily updated (using tools such as Wordpress, Squarespace, Wix, Figma, PowerPoint, or ExcaliDraw). For example,

• if you are trying to gamify something, focus on the game mechanics so others can validate that it will be fun and motivating
• if you are trying to make a lesson interactive, focus on how the interaction improves the learning experience so others can validate your choices
• if you are trying to make learning social, focus on what will bring learners together to collaborate so others can validate they would want to participate

Do not spend time mocking up typical parts of an app, such as logging on, searching a list of topics, generic chat features, etc. For this deliverable, you do not need to implement working software, so try to be as creative as possible!

Include text at the start of each Wireframe that:

• summarizes its purpose
• explains what makes it distinctive
• describes how you expect it to help with learning

Within a Wireframe, include additional descriptions where appropriate to help us better understand the motivations behind your choices and the learning results you want, such as about necessary context and data or expected interactions and transitions.

Test your Wireframe with three people, ensuring they understand its purpose, context, and what kind of feedback would be helpful. Summarize the results in a Markdown file named Wireframe_Feedback.md, that includes the following:

• Direct feedback. This should be each user's direct feedback as much as possible (either their written summary or quotes) rather than your interpretation of their feedback.
• Positive notes. Summarize the top good things that users felt were important to be kept in the app. Ideally, these would be similar comments made by multiple users.
• Improvement notes. Summarize the top things that users commented critically about, regardless of whether or not you agree or they seem to contradictory. If any of these comments are made by multiple users, make sure to note that as well.

Record two videos, as long as needed, of

• one User Test — the user does not need to appear in the video, it can just show the interaction with their voice over
• going through your Wireframe(s) — include voiceover explaining the goals and expected interactions as well as why you think it represents something distinctive or interesting

You can use Zoom, your phone, or there are many free screen capture tools available or free trials of some pretty powerful tools as well.

Weekly Progress Report

Each week push new app features (implemented or Wireframed) to your GIT repository and a written Markdown progress report, named Progress_WeekN.md (where N is either 1, 2, or 3), that includes:

• Updates. describe all updates completed or started
• Plan. prioritized features you are planning to work on next week
• Pivot. justify changes, if any, to your project's Goals, Target Users, Values, Impacts, Data Needs, or Scope
• Personas. describe how your Updates, Plan, and Pivots impact or provide value for each of your project's Personas
• Retrospective. describe something that worked well, something that did not, and any issues/blockers that complicated your progress (and how you are planning to handle them)
• Feedback. impressions and quotes from at least two people and how you plan to address their feedback to better inform the value and outcomes of your app

Record a video, as long as needed, describing its progress from the previous week. You can use Zoom or there are many free screen capture tools available or free trials of some pretty powerful tools as well.

You should also endeavor to make what work you do as visible as possible (i.e., follow the Open-Source Coding Community's maxim: “Keep a history: if it isn't public, it didn't happen”).

For example,

• if you work on a tutorial, include:
  • a link to it
  • a short description of it
  • something you learned from it
• if you implement something, include:
  • a short description of it
  • a ZIP file of the code files
  • a video of it running (in case I can't get it working)

Thus, the Updates section summarizes your efforts and the supporting artifacts (links, ZIP files, videos, etc.) provide evidence of that work.

Additionally, you should be prepared to demo your project during any class meeting.

Final Submission

Capture as much of your idea as possible using "dummy" data and specific situations to demonstrate how the key features work in Software Artifact(s) you feel is most appropriate, such as:

• functional software (using tools such as Flowbite's Svelte Components or React Suite Components)
• functional LLM (using tools such as the Soffos platform, PrivateGPT, or the ChatGPT API)
• visual slideshows with written explanations between each (using tools such as Figma, PowerPoint, or ExcaliDraw (a Markdown-oriented drawing tool!))
• interactive wireframes (using tools such as Wordpress, SquareSpace, or Wix)

Note, at least one part of your project must be submitted as functional software.

They may be developed and demoed separately for this initial prototype, even if your ultimate plan is a combined single app or experience.

In addition to Software Artifact(s), submit the following materials:

1. README file that describes the project's overall vision, attributions, and how to access different parts of the Software Artifact
2. summaries of any data, research studies, or other materials that informed your work
3. justification of your design and feature choices based on principles covered during this course
4. privacy policy and justification for data your project keeps by linking it to project features
5. plan for how you would verify your project's effectiveness if it were deployed
6. all stakeholder, and AI, feedback and discussion of your responses (i.e., how comments were incorporated into the final version or might be in a future version)
7. retrospective of how the project has evolved since the initial proposal, including what influenced the changes (new ideas, user, peer, or staff feedback, etc.)
8. any presentation materials and a video, approximately 5 minutes long, going through your Software Artifact(s)

During our final class meeting, you will demo your Software Artifact(s), highlighting:

• the best case or ultimate value of your project
• differentiate it from existing EdTech tools or current teaching practices
• justify its value based on at least one data, research study, learning theory, or other principle discussed this semester
• an experiment or survey you could do to validate your project's approach and purpose
• how iteration and feedback improved your project