Group Project

You have flexibility on how to design and develop the App as long as you cover the compulsory and minimum requirements, and your solution is sensitive to the user profile and the context in the case description. You will have to prioritize which two of the optional requirements to implement, and you can choose to develop one 'surprise us' feature. You need to justify your decisions regarding design, application workflow, and implementation in the final (graded) group presentation. You also need to be able to reflect on and discuss your project experience of development in a platform ecosystem and relate this experience to the course curriculum and lectures. 

You must use React, the DHIS2 app development platform, the DHIS2 UI library and style guide, and the UiO git for development and coordination. Your group must set up its own git repository. The final app should be deployable to run as an internal app in DHIS2, but you do not need to actually deploy it. 

Throughout the group work, you will be able to discuss ideas for design, functionality, and how to implement this with the group seminar teachers. You can get help with the technical aspects of your project (e.g., APIs, DHIS2 app platform, UI library) during the seminar groups. 

You only have about seven weeks for the project work. Start as soon as possible by organizing your group collaboration and development process. We encourage you to work through several iterations. In the first iteration, the focus should be on designing and developing a minimum viable product that addresses the most fundamental aspects of the application. Consider dividing the work among group members to work efficiently while making sure that everyone is aware of and participates in all major decisions. Try to have frequent meetings and do larger ideation activities together as a group.

You will need to strike a balance between 'ideal' features and what is possible given technical limitations and the limited time you have for the project. Make sure you meet the minimum requirements before you move into 'nice to have' features and designs, including the 'surprise us' feature.

Week 41 ¨C 43, and presentation 1

The first part of the project work is to elicit and define requirements for your minimum viable product based on the information provided in the case description, and get started on the application development! You will present your preliminary ideas and designs in the first group presentation in week 43. This is an opportunity to get feedback on your prototype, clear up misunderstandings, and ask any questions you might have. Please make sure to check beforehand that the laptop you want to present from is compatible with the audiovisual equipment in the seminar room, as we have limited time for presentations and feedback. Your presentation (max 6 minutes per group) should include:

• Outline the functionality and design of your minimum viable product
• Very brief demo of any implemented functionality and UIs (or prototype sketches)
• Any concerns with DHIS2, its APIs, or the app platform resources
• Timeline and plan for coordinating the remaining work between group members 

Remember that you will need to reflect on your solution and the development process in the final graded presentation. When you start exploring the DHIS2 API and other DHIS2 resources, you might discover that you need to adapt to the possibilities and constraints of the platform. We encourage you to take note of how this shapes your experience of development in a platform ecosystem, so that you are prepared to discuss those experiences with us. 

Week 44-47

Make sure you have a working version of your minimum viable product before embarking on additional features. It is also wise to merge different parts of the application to a shared repository regularly, rather than to do one comprehensive merge right before the project deadline. 

Final "push" and submission in Devilry - 25th of November

After the 25th of November (23:59), your group should not make changes to your solution on git. Before your presentation in week 49, we will have a look at your code.

To submit your project, you have to:

• Invite all group teachers and David to your git repository
• In your git repository, you should include a short readme file outlining:
  • Your app's functionality
  • How this is implemented (just a brief explanation)
  • Any missing functionality (as per the minimum requirements), and things that do not work as you intended
• Submit a link to your git repository in Devilry before the 25th of November 23.59. This is a compulsory group submission in the course. 
  • Upload a video of about four minutes to Devilry where you review and explain the code structure of your application. This video is not intended to demonstrate the user experience or features of the application, as you will do that in the final graded presentation. Rather, the video complements the readme file and demonstrates your understanding and ownership of the submitted code.  
  • The submission must be made as a 'group delivery' in Devilry. Make sure to include all group members.

Week 49: Final presentation

The final presentations will be held in week 49. All group members must be present. Your presentation should be no longer than 10 minutes (we will stop you if you use more time). We will then ask you some questions and discuss your app development experience with you, in light of the course syllabus. 

The presentation and your performance in the oral exam will be graded (one shared grade per group). The grade counts 85% towards your final individual grade in the course.  

Checklist of what you must cover in your presentation (10 minutes):

• Live demo of the app, covering the compulsory requirements, two additional requirements, and potentially an optional 'surprise us' feature. Use the demo to highlight your adherence to UX principles (Don Norman's principles) and the DHIS2 UI recommendations. 

• Briefly explain the utility of the features you have decided to include and why you chose to implement these. How do these features complement each other in your application?

• Reflect on the design and development process (e.g., prototyping, usability testing, coordination). 

• Reflect on how development in a platform ecosystem, including your engagement with platform boundary resources, shaped your decisions regarding ideation, design, user experience, and the overall development process.

• Reflect on the partitioning between the DHIS2 platform and your application in terms of presentation logic, application logic, data access logic, and data storage. Is there anything with the partitioning that you would have done differently if you were to start over with the project?