GeriLife is a comprehensive toolkit designed to empower caregivers in elder-care communities, promoting wellness and ensuring equitable engagement in life-enriching activities. This project, rooted in real-world insights and collaborative innovation, aims to transform elder care by making quality-of-life activities visible and coordinated.
License: European Union Public License 1.2
![allcontributors[bot] avatar](https://avatars.githubusercontent.com/in/23186?v=4 "allcontributors[bot]")
We want to show some statistical overview on the Homes List page, so there is actionable information at that level of aggregation. Add a statistical chart for each home showing the proportion of work carried out for each role in the home, e.g. what percentage of work was performed by each role. That way, the homes can be compared in some meaningful way and further details can be seen when clicking on the link to the Home Detail view.
Now that we have a Plotly Express multi-series plot showing proportional caregiver work by role and type, we can remove the less-informative calendar heatmap (created with ECharts). We may decide to add it again, but for now let's clean up the code.
Add the Activities app with Activity model.
Activity
Add activity form
Recent activities table
Our Finnish translations are currently somewhat unnatural, and lack context. Go through the Finnish translations and update them so they sound more natural.
In the development phase, testing different views, queries, and functionalities requires working with realistic data. To facilitate this, there is a need for a reliable method to create data fixtures or generate project data.
factory_boy and Faker.factory_boy and Faker in the context of the project's data requirements.Resident - at least plan to include data generator for residentsResidency - if possible, also include Residency generator, which would depend on Resident and Home generators (so is optional)factory_boy and Faker to generate realistic data for the residents app.This task is crucial for ensuring that the development team can test and refine the application with realistic data scenarios, ultimately leading to a more robust and reliable final product.
Introduction
table structure and Bootstrap 5 classes
Detailed Description
Use Case
Technical Considerations
Alternatives Considered
Additional Context
The Add Work form has two time-related fields:
Only duration minutes or duration hours would be required.
Duplicate time fields which can lead to inconsistencies.
Remove one of the fields and derive it from the remaining field.
No response
N/A
N/A
No response
Add a mock data generator for activities, aiming to create a realistic data set for development and testing purposes.
Detailed Description
duration_m: Randomly set to 15, 30, 45, or 60 minutes.caregiver_role: Randomly selected from the predefined caregiver roles.activity_type: Randomly chosen from the available activity types.Use Case
Technical Considerations
numpy, scipy, or statsmodels which are already included in the project.Additional Context
Users need to see application text in their native language. To this end, we will add internationalization to all default texts. Once the texts are internationalized, we will have a localization process to translate the texts into supported languages.
The Home List page currently shows a bar chart for each home:
Task
Introduction
Detailed Description
Use Case
Technical Considerations
Alternatives Considered
Additional Context
This issue is intended to clearly define the requirements for the new Groups feature, ensuring a user-friendly interface that aligns with the current design system used throughout the project. The provided screenshot will serve as a visual guide for the expected outcome.
Overview: Implement a make_fake_data management command in Django that generates 30 days of complete, interconnected fake data for development and demonstration purposes.
Background/Context:
Goals/Objectives:
make_fake_data command without errors.Our current Activity data model, while robust, presents challenges in generating charts and reports due to its complex relationships, particularly the ManyToMany relationship between Residents and Activities. To streamline data aggregation and improve performance, we propose creating a new Django application, metrics, featuring a more efficient data model.
resident: ForeignKey(Resident)activity: ForeignKey(Activity)residency: ForeignKey(Residency) - Linking Resident and Home at the activity timehome: ForeignKey(Home) - Derived from residencyactivity_type: stringactivity_minutes: intcaregiver_role: strEnsuring data consistency between the Activity and ResidentActivity models is critical. We are considering two approaches:
Custom Django Model Manager:
Django Signals:
metrics App: Develop the new Django application within our project.Once the metrics application and ResidentActivity model are established, we will focus on defining specific metrics and developing visualizations to support caregiving in elder care communities.
This initiative aims to enhance our data handling capabilities, making it easier to generate meaningful insights and reports. The success of this implementation will lay the groundwork for advanced analytics in our caregiving project.
The Work Report and Home Detail view contain a significant amount of duplicated code. However, the code contains subtle changes, due to filtering the work reports on the Home Detail view.
metricsWe want to experiment with displaying the percent of work done by each role for particular types of work. E.g. "nurses spend X% of time doing Y activity"
This will help to ensure that workers are doing work that is appropriate for their expertise and can inform staff hiring.
We want technology to make ”Indirect work” visible. Basically I just want to find out how many minutes staff (different roles) is doing the work
Ensure we have the following MVP reports:
Add the Django debug toolbar and ensure it is only enabled in debug mode.
We want to debug and audit our Django views for things like query slowness and other possible optimizations.
Install and configure Django debug toolbar.
We want to raise awareness about caregiving duties. To that end, we need a streamlined way for users to record duties.
The Duty model might contain the following fields:
is_caregiver attribute, useful for filtering and distinguishing between types of users (staff, administrator, etc.)user that created the Duty instanceIf the above Duty model is fairly easy to achieve, consider extending the Duty model as part of this task to include the following fields. Otherwise, the relationships can be continued in a subsequent task.
duty typeRemove the username field from the user model and use the email address as username.
We don't have a use case for usernames.
Integrate IBM's Carbon Design System into our project as a complement or replacement for Bootstrap. This transition aims to enhance the professional appearance, usability, and modernity of our web application's UI, especially focusing on forms, data tables, and bespoke dashboards. Carbon's enterprise-oriented design language aligns perfectly with the goal of appealing to enterprise customers while supporting our users effectively in their daily tasks.
Our current use of Bootstrap, while effective, lacks the specific focus and advanced features needed for enterprise-grade applications. By experimenting with the Carbon Design System, we can leverage its professional design language, adherence to web standards, and modern UI conventions. This aligns with our goal to offer an application that not only meets but exceeds the expectations of enterprise clients, particularly in areas where our application is most utilized – forms, data tables, and custom dashboards.
Continuing with Bootstrap, while feasible, may not fully meet the evolving demands of our enterprise clients. Other design systems were considered, but Carbon's alignment with enterprise needs and its comprehensive design and component offerings make it the most suitable choice.
This proposal to experiment with and potentially adopt the IBM Carbon Design System reflects our commitment to staying at the forefront of modern web application design, prioritizing both user experience and client appeal.
These resources will provide a comprehensive understanding of the Carbon Design System, its components, design philosophy, and how it can be implemented and utilized in our project.
Add the ability to assign users to specific homes, which will form the basis of basic access control within the application.
Detailed Description
Use Case
Technical Considerations
Alternatives Considered
Additional Context
Certainly, here is the UI/UX section for the GitHub issue regarding user assignment to homes:
UI/UX Considerations
We will want to locate model instances by a short URL slug, which is non-sequential.
shortuuid package to the projectShortUuidField to each model that we would retrieve via URL slugShortUuidField as the primary key or just a url_uuid fieldPort existing views and database operations in the project to utilize Python/Django's asynchronous features. This enhancement involves refactoring current synchronous views and database interactions to asynchronous ones using the latest async capabilities provided by Django. The objective is to improve the overall performance and scalability of the application by enabling non-blocking database operations and handling concurrent requests more efficiently.
As the application grows in complexity and user base, performance and scalability become increasingly important. Traditional synchronous processing can lead to inefficiencies, especially under heavy load. By adopting Django's async features, we can handle more requests simultaneously, reduce response times, and improve user experience, particularly in data-intensive operations. This shift is also in line with modern web development practices, ensuring our application remains robust and future-proof.
The primary alternative to implementing Django's async features is to continue using synchronous views and database operations. This approach relies on the existing, well-understood synchronous programming model, ensuring stability and maintaining the current performance benchmarks. While it lacks the potential performance improvements of async processing, it avoids the complexities and potential challenges involved in refactoring to asynchronous code. This approach would be more about optimizing within the current synchronous framework, focusing on database query optimizations, efficient view logic, and potentially leveraging caching strategies to improve performance.
This transition to asynchronous processing is part of a strategic move towards adopting modern web development practices. It requires careful planning and testing to ensure seamless integration with the existing synchronous parts of the application. The latest version of Django's improved async support makes it a suitable time for this upgrade.
For adding Django async support, the official Django documentation provides a comprehensive guide on implementing asynchronous support. Key aspects include:
async for on all QuerySets.asave and acreate, which can be used for database operations.sync_to_async() for calling sync functions from an async context.async_to_sync() and sync_to_async() from the asgiref.sync module to adapt calling styles between sync and async code.asyncio.CancelledError might be raised if a client disconnects before the view returns a response.The Django documentation covers these topics and more in-depth and is an essential resource for implementing async in Django. You can read more about asynchronous support in Django on the official documentation.
Additionally, the DEV Community provides an article discussing the comparison between WSGI and ASGI in the context of Django, highlighting the benefits of ASGI for async support, including scalability, concurrency, and real-time functionality. It also covers why ASGI is needed for async support in Django and provides a comparison of Uvicorn and Daphne, two popular ASGI server implementations. You can read more about this on the DEV Community article.
Continued from #57
Add a horizontal bar chart for resident activity levels beside each home listed on the Groups page.
Detailed Description
activity_level method from the Resident model to determine activity statuses.get_percent_residents_by_activity_level as the main aggregation function.Use Case
Technical Considerations
Alternatives Considered
Additional Context
We aim to enhance the Home profile template by adding a multi-line chart to display activity level trends of residents over the past seven days. This visualization will provide insights into the daily activity patterns of residents, categorized into four levels: inactive, low, good, and high.
To visualize the trend of activity levels of residents in a specific home, helping staff and caregivers to monitor and understand changes in resident activity patterns.
WEEKLY_ACTIVITY_RANGES constant.The core of this chart lies in the aggregation of resident activity data to accurately represent activity levels over the past seven days. This involves several key steps:
move_in and move_out dates for each residency.WEEKLY_ACTIVITY_RANGES.
Create as much of the resident page from the previous GeriLife Wellbeing application as is possible. Open a follow-up ticket for any remaining items.
There is a bug in the function resident_counts_by_activity_level where the calculated percentages for
each activity level (inactive, low active, good active, high active) do not sum up to 100%.
The sum of the percentages for all activity levels should be exactly 100%.
The current implementation results in a sum that can be slightly lower or higher than 100%.
resident_counts_by_activity_level method on a Home instance.A rounding strategy needs to be implemented to adjust the individual percentages so that they sum up to 100%,
while still reflecting the accurate proportions as closely as possible.
Integrate HTMX into the Resident page to enable asynchronous loading of chart data. The goal is to have the page load immediately with placeholders where charts will be displayed. HTMX will then send a GET request to a backend view for each chart. This view returns the chart's HTML, which is processed asynchronously and loaded into the page as soon as it's ready. This approach will enhance the user experience by providing immediate page feedback and gradually loading complex data.
The current Resident page load time is slow due to the synchronous loading of complex chart data. This leads to a suboptimal user experience. By integrating HTMX, we aim to improve page load times, provide immediate feedback to users, and enhance the overall user interface responsiveness. Asynchronous loading of charts will ensure that users are not kept waiting and that they can interact with other page elements while data is being processed.
Implement HTMX on the Resident page by adding hx-get attributes to placeholder elements where charts will be displayed. Create dedicated Django views for processing each chart's data. These views will return HTML snippets containing the rendered charts. Use Django channels or background tasks for asynchronous data processing. Ensure that the frontend gracefully handles the asynchronous insertion of these charts into the DOM.
Alternatives such as Ajax calls and client-side JavaScript frameworks were considered. However, HTMX provides a simpler implementation with less JavaScript, aligning well with the current project's technology stack and coding practices.
This feature is part of an ongoing effort to improve the application's performance and user experience. It aligns with our goals to make the application more efficient and user-friendly.
While developing, we would like to have some fake Work data to preview and test the app.
The fake data would help us demo and develop the app.
Generate a significant amount of work data sufficient to demonstrate all Work-related charts, such as 30 or 365 days (depending on the chart contents.) Include the Work-data generation code when calling the make_fake_data command.
Manually creating the data but this is a bit tedious and doesn't help with demonstrating the software quickly.
We currently have a modal dialogue for submitting work reports. However, the user is redirected to the Home page when submitting a work report. It may be more natural to redirect the user to the page they were viewing when they submitted the modal dialogue.
Deprecate the Activity model and transition all functionalities to the ResidentActivity model.
Background/Context:
Activity for building application views and ResidentActivity for efficient metric aggregations.ResidentActivity model is capable of fulfilling application requirements, ranging from page building to analytics.Goals/Objectives:
Activity model.ResidentActivity model.ResidentActivity model to include an activity_group field for enhanced analytics.Activity model from the codebase.ResidentActivity model.Activity to ResidentActivity.activity_group field in the ResidentActivity model, if required.Activity model.ResidentActivity.Activity model.Introduction
On the Home profile page, implement a new bar chart report that groups activity minutes or hours by month and caregiver role.
This is a grouped bar chart where the data are grouped by month and subgrouped by activity type with an aggregated sum of activity minutes (or hours.)
Detailed Description
Use Case
Technical Considerations
Alternatives Considered
Additional Context
Now that Bootstrap 5.3 supports dark and light mode and we have set the dark mode on our base html element, we can allow users to toggle their preferred mode.
Our project aims to appeal to decision-makers in large institutional care networks. To achieve this, we propose adopting the Nordhealth Design System for our UI components. Nordhealth's design system offers a professional, sleek aesthetic and includes numerous usability and accessibility features that would significantly enhance the user experience of our project.
The decision to integrate the Nordhealth Design System is motivated by several key factors:
Professional Aesthetics: A polished and professional user interface is crucial for making a strong impression on decision-makers in large care networks. Nordhealth's design system offers a contemporary, clean look that aligns with this goal.
Usability and Accessibility Improvements: Nordhealth's design system is built with accessibility and usability at its core. Implementing it would ensure our application is more user-friendly and accessible to a wider audience, including those with disabilities.
Ease of Design Scalability: As our project grows, the need for a scalable design system becomes more apparent. Nordhealth provides a robust framework for scaling our UI design efficiently.
Figma Integration: For future UI design enhancements, the availability of Figma components within the Nordhealth design system is highly beneficial. This would streamline our design process, especially if we onboard professional UI designers.
The implementation would involve a phased approach:
Evaluation Phase: Assess the compatibility of Nordhealth design system with our current UI and backend framework.
Planning Phase: Develop a detailed plan for the integration, including timelines and resources needed.
Implementation Phase: Gradual replacement of current UI components with those from the Nordhealth design system, ensuring minimal disruption to existing users.
Testing and Feedback Phase: Rigorous testing for usability and accessibility, followed by gathering feedback from a select user group.
Roll-out Phase: Full implementation of the design system across the platform, accompanied by user education initiatives as needed.
We have considered maintaining our current design or adopting other design systems. However, the specific benefits of Nordhealth in terms of professional aesthetics and its focus on healthcare contexts make it a more compelling choice.
Further information about the Nordhealth Design System can be found at Nordhealth Design. The design system's focus on healthcare interfaces aligns well with the needs of our project, making it an ideal candidate for our UI overhaul.
To introduce a stacked bar chart on the Home profile template that displays activity counts grouped by resident and activity type. This visualization aims to provide a clear overview of each resident's participation in different activities, enhancing the understanding of individual engagement patterns.
This chart requires a multi-level aggregation approach:
We've almost transitioned completely from ECharts to Plotly.py. However, the calendar chart is still rendered with ECharts.
Either replace the ECharts calendar histogram with a similar solution from Plotly or consider removing the chart.
Introduction
On the Home profile page, implement a new bar chart report that groups activity minutes or hours by month and activity type.
This is a grouped bar chart where the data are grouped by month and subgrouped by activity type with an aggregated sum of activity minutes (or hours.)
Detailed Description
Use Case
Technical Considerations
Alternatives Considered
Additional Context
Ensure the "add work activity" form has these minimal viable features:
And then ”Submit”
This ”Add acitivity” -form is really easy and quick to use.
Determine how we want to group homes, such as the allowed hierarchy level. After doing so, use the previous Homes display as inspiration to design new data visualizations for the new homes list display.
HomeGroup model
name field to HomeGroup modelgroup field to Home model as a ForeignKey to HomeGroupgroup field to HomeForm so homes can be assigned to groupsHomes view that lists homes
Note: you don't need to build the following data visualizations. This screen is only a visual reference to show the homes nested within home groups.
Introduction
Add an "Add Activity" feature on the Home profile page, to be implemented as a modal dialogue with a form.
Detailed Description
resident: Multi-select for residents with active residencies (use Select2 for enhanced UI).activity_type: Single-select dropdown, options from ActivityTypeChoices.activity_date: Datetime field with a calendar widget.duration_minutes: Positive integer field for activity duration in minutes.caregiver_role: Select widget, options from CaregiverRoleChoices.Use Case
Technical Considerations
Alternatives Considered
Additional Context
Our work reports currently display the amount of work in minutes. However, employers may be more oriented towards planning staff needs in hours.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.