sglavoie.com – Tag: BSc

Building a task planner with React Native: an academic journey

Sébastien Lavoie — Sun, 30 Jul 2023 18:44:00 -0600

Preamble

For my last assignment in a BSc in Computer Science at the University of London, I decided to get involved in the world of task management to tackle one of the most common challenges usually offered to programmers, but with a twist based on scientific evidence. The result ended up being a cross-platform mobile application built with React Native, named ProductiviDo. Due to intellectual property concerns, I will not be able to share the source code of the application, but I hope you will nonetheless find joy in reading about the process of building it through the lens of the report I submitted for the assignment. For a complete list of references and appendices in context, please refer to the original report.

1 Introduction

The world needs a new kind of task manager, just like ProductiviDo, which comes to life through the “task manager mobile app” template provided for the Mobile Development module taught at Goldsmiths, University of London.

1.1 Inspiration: the main contenders

Inspiration.

There are a few wonderful products that deliver a good experience. Desirable features range from filters, labels and reminders to custom views and breadcrumbs. With Todoist, tasks can be quickly captured and will be added to an “Inbox” section. Once categorized, tasks are organized into projects, sections and sub-tasks.

Although Todoist recently added a board view, ClickUp takes it to the next level by labelling columns. In ClickUp, tasks are organized into multiple levels of hierarchies, down to task dependency, where sub-tasks depend on parent tasks.

ClickUp overview.

Trello takes an entirely different approach, where planning happens by moving cards onto different columns horizontally and re-ordering them vertically. Even though it has a concept of workspaces which is a group of boards, all the organization of a project usually takes place within a single board which contains multiple columns, each containing multiple cards.

Planning in Airtable is much more freestyle with a spreadsheet-like system. There is a Gantt view in the paid plan to visualize tasks over time. Using Airtable feels like interacting directly with a SQL database with its heavily grid-focused appearance.

Airtable project.

Finally, Asana shines mostly within a team setting and mainly works with the core concept of projects, which themselves can contain tasks, sub-tasks and even sub-projects.

Asana calendar.

1.2 Drawbacks of existing solutions

Drawbacks.

There are usability issues across all these mobile apps (and others) for different reasons. Most popular task managers have a limited search functionality, making it hard to find what one needs quickly unless a good organizational system has been consciously put in place beforehand. Crucially, such applications do not address the fact that unimportant tasks accumulate over time and provide no system to focus on what matters to avoid the fate of having “41% of to-do items […] never completed”.

A second point worth mentioning is that a calendar integration is not a core feature deeply integrated into these apps. For instance, Todoist offers a 2-way sync with Google Calendar, but tags, labels, priorities and areas of responsibilities are not shown nor taken into account in the calendar. Some task managers will provide their own built-in set of calendar features that partially solve the problem of being able to navigate a complete schedule in a breeze. However, none of these applications really allow efficient scheduling within the calendar. Some allow the user to add or modify events in the calendar, but this remains a slow process working with reduced functionality.

With regards to organization, all these applications are well-suited to manage tasks but when it comes to “time boxing” or “time blocking”, they will show every single task in the calendar view. This is impractical at scale as it quickly becomes overwhelming with dense information, a setup encouraging fragmented work and multitasking. Fragmented work caused by context switching has been shown to have a negative impact on productivity and on output quality while multitasking will lead to “experiencing more stress, higher frustration, time pressure and effort”.

1.3 Market overview

ProductiviDo will target in its first iteration Google Calendar because this product can be consumed from a plethora of desktop and mobile applications and there are about 4.3 billion Google users. Once data is integrated into Google Calendar, it can be consumed by different applications such as Apple Calendar, Zoom, Slack or other Google products, including Google Docs.

The number of smartphone users will increase by almost 23% over the next 5 years, forecasting more than a doubling over a 10-year period (2016–2026). Task management software is going upwards of USD$5 billion in market size, the CAGR —compound annual growth rate— is hovering around 14% and continuously growing. Combining supply and demand, we can see that both are expected to increase drastically over the coming years and that task managers fall into a category of growth market, which is desirable as it clearly indicates there is room for new rivals in the field: this is distinctly the case given that the task management world is still dominated by a few big players, many products have retired over the years (which unsaturates the market) and considering that ProductiviDo solves a real problem —that of staying on top of a growing list of commitments— with an innovative solution not yet implemented elsewhere.

1.4 Motivation

One reason why ProductiviDo will shine is because calendars are still under-appreciated in existing task managers, yet all major task manager applications integrate them in one way or another. It has been shown through many studies that calendars save time, improve productivity, reduce stress and make it simpler to batch similar activities. Plus, they can be consumed in a myriad of ways with their Application Programming Interfaces (APIs). The problem with using only a calendar without a task manager is that they are inconvenient when dealing with many events or tasks. On the other hand, relying only on task managers makes it difficult to appreciate how useful calendars are when it comes to visualizing one’s schedule from different perspectives such as a weekly or monthly view. Regarding ProductiviDo as a task manager and not only a calendar integration, it will distinguish itself by allowing users to quickly and efficiently record their routine activities. This is because it has been shown that these occupy a good amount of time even for productive people and there is currently no application that really implements a direct solution to this.

Intelligent prioritization is essential, yet difficult to achieve with existing products. Beyond capturing tasks and categorizing them, this application will feature a prioritization system that will help users focus on their most high-leverage activities with the help of custom sorting algorithms as advocated by Edmond Lau in his book The Effective Engineer. These will take into consideration aspects such as urgency and importance — in the spirit of the Eisenhower Matrix — as well as deadlines to calculate the impact that completing a task will have. Importantly, the priority matrix is adapted to account for other needed facets, such as when other people are involved in the task dependency chain (delegatees), an adaptation of the “fit” variable from the Sung Diagram, which is an extension of the Eisenhower Matrix.

The application will benefit users by providing a built-in planning system that will make it easier to follow a successful schedule. This goes hand in hand with findings illustrating how, in the absence of a mindful review process, users will want to focus on small or unimportant tasks to release dopamine even though they know what would bring them the best outcomes, a real productivity threat leading to a decrease in output and an increase in completion time. Therefore, by offering a system that will encourage users to take better decisions and visualize evidently their highest-leverage tasks in a familiar and useful fashion, ProductiviDo will carve its place in the market by solving unmet needs.

2 Literature review

2.1 Previous work

As alluded to in section 1.1, the current work found inspiration in well-established task management software. There are numerous alternatives available on the market: only the most well-known and relevant ones for this project will be covered. Evaluating such products in depth goes beyond the scope of this report: key points will be highlighted to justify the need for a new solution.

2.1.1 Todoist

Todoist is one of the most popular task management software, with over 20 million users. It is a web-based application that allows users to create tasks, organize them into projects, and assign them to specific dates. It also features a priority system that allows users to sort tasks by importance, and a reminder system that will notify users of upcoming tasks. While Todoist is a very popular solution, it has some shortcomings. Its design is arguably polished, yet its dark theme lacks contrast, recurring tasks don’t show immediately on which schedule they recur and tasks with comments or attachments are difficult to locate. Other functional deficiencies include the fact that the “Upcoming” view shows all tasks from all projects as a large, single list of items without allowing filtering or that the app has a concept of “due date” with no “start date” such that duration is not taken into account nor can be visually represented meaningfully in a calendar. Equally relevant when comparing to what ProductiviDo will offer is the fact that there is no way to apply “time boxing” as there is no calendar view and only a functionally limited Google Calendar integration, task filtering is not intuitive due to the custom query language syntax used by the app and there is no easy way to find recurring or routine tasks without setting up a custom labelling system on one’s own.

Todoist upcoming view.

2.1.2 Trello

Trello lies on the other end of the feature creep spectrum when compared to ClickUp and can be seen as possessing an even more basic set of capabilities than Todoist. With its simple and uncluttered drag & drop interface, Trello is much more intuitive than a more sophisticated and flexible option such as Todo.txt which can be technically extended at will and can be operated from the command-line on a desktop computer or from a multitude of third-party applications on mobile devices. Trello’s simplicity comes at a cost, however: it is not uncommon to lose track of “cards” because one must swipe horizontally in order to navigate the UI; and very little information fits on the screen at once, where only a fraction of a “board” with up to a few “cards” is shown. There is a copious amount of calendar integrations available for Trello, yet the core of the issue that ProductiviDo aims to address remains unsolved: the app’s metadata is not accessible from Google Calendar (e.g., priority, area of work, task status, etc.) and the app does not provide a way to visualize the user’s tasks in a convenient calendar view as it only “displays all cards with due dates by month” and only when using one of its paid feature, called “Power Ups”.

Trello boards.

2.2 Contributions from the literature and gaps being filled

2.2.1 Initial design justifications

Amongst a panoply of scientific papers on the subject of task management, the quintessential work of Bellotti et al. serves as an excellent entrypoint listing a set of design requirements to be expected in an efficiently conceived task manager. Of particular relevance to the creation of ProductiviDo are the needs for the app to be “instantly on” with the option to have “no formal task description” and a “mechanism for handling stale to-dos of low importance”. The authors highlight that the main issue is “making sure that the important tasks get done”, which led to further research being exposed on the topic of prioritization matrices. The authors also advocate for task states, location, social relations, notes and time constraints to be captured, all of which are taken into account in the design. In a more recent study looking at the importance of prioritizing tasks, further evidence suggested that a prioritization model should be adopted (e.g., HI/LO, CARVER or Carpenter) in a task management system, pointing at the Eisenhower Matrix as a useful framework to use for this very purpose. Other less formal alternatives such as the RICE or ICE frameworks have also been reported to be used with success and could be adapted to this project with their scoring model.

Another aspect which served to inform the overall direction to take is the well-known fact that humans do not work optimally when multi-tasking as this leads to a high cognitive load in keeping track of different areas of focus or projects. Fragmentation of information in one’s work —which occurs when multitasking— is a problem because people won’t remember where to find the information. Applying this idea of fragmentation to the digital world, it only makes sense that offering too many ways to store and retrieve data (such as with ClickUp) is counterproductive. Furthermore, the ability to customize the UI is a double-edged sword because “users make mistakes and create building blocks with unintended consequences”. Indeed, if the user interface is cluttered or offers too many bells and whistles, managing the global context of one’s tasks becomes difficult and one inevitably encounters obstacles when trying to juggle with multiple actions at once, because “prospective memory is fallible”. Hence, simplicity is key to a good task manager (which certainly helps to explain Todoist’s wild success). While simplification is part of the gamified model —Habitica being one example of a product incorporating many elements of gamification— this model suffers from the “undifferentiated use of rewards”, leads to “punishments for productivity”, to “feeling of not being taken seriously” and cause “negative anticipation”. Moreover, “people found their standard task manager simpler to use” and the integration of extrinsic motivational factors such as a reward system “would not excite them to continue being immersed in a gamification application”. While this form of motivation does not appear to be effective in goal attainment, the literature concludes that “valuing extrinsic goals […] does not seem to increase our happiness, but attaining those goals does”, adding that giving weight to intrinsic goals (such as personal growth, loving relationships and physical health) and achieving them is a better way to increase happiness. As long as a task manager nourishes intrinsic motivation, it is likely to be effective in helping people to achieve their goals while maintaining optimal psychological health.

Other approaches were considered, notably the “Binary Priority List” due to its simplicity when it comes to comparing two elements (such as tasks). However, it lacks flexibility and becomes inefficient as more and more tasks are added because —unlike the famous binary search algorithm— this algorithm requires human intervention to classify tasks, which becomes burdensome faster than O(log n). The literature on gamification also linked to sources that revealed solutions to solving procrastination, a self-regulation failure that gamified systems sought to minimize to no avail, which led to identifying a desirable core component of the application: implementation intentions. These can be integrated into the “mental flexibility” facet of “planfulness” —through a technique known as “mental contrasting with implementation intentions” (MCII)— along with temporal orientation and cognitive strategies, all of which improve goal outcomes.

2.2.2 Implementation intentions

Implementation intentions have shown their effectiveness in helping people to achieve their goals, the real purpose behind using task managers in the first place. The idea is to create a plan of action for a specific goal, which is then followed by a specific time and place. The plan must be broken down into a series of steps, which are written down in a way that is easy to remember using so-called “if–then plans”. The specific formulation of such plans “produce much more favorable and reliable outcomes than broad intentions to pursue a goal”. Findings from Bieleke et al. show that implementation intentions are also useful when planning one’s work because they help “evaluate information from a certain perspective” —which can be verbally recommended to users so they adopt a “certain processing style (e.g., deliberative thought) or perspective (e.g., neutral observer)”. Their research also highlight the high potential of implementation intentions in reviewing tasks because “participants can strategically adopt a reflective mode of information processing that helps them make more sophisticated decisions when facing uncertainty”. Other studies show that such “plans to deliberate can be used to increase the likelihood of deliberation and thereby the effective processing of newly available information”, which further supports the benefits of implementation intentions with regards to planning. To make the planning stage more effective, research also “indicates that having plans that focus on overcoming obstacles are important for maintaining progress and staying on track with one’s goals”, so this aspect will also be featured when creating tasks in the “Inscribe” step described in section 2.3.1. Once planning has been done, implementation intentions will also prove useful to take action towards accomplishing one’s goals because they lead to “automatic action initiation without further conscious intent” —surprisingly and encouragingly, even in participants suffering from mild to moderate depression. While this is obviously beneficial during the initial stages of a project or task to overcome procrastination, it is equally important to re-evaluate one’s course of action because sticking to a plan stubbornly “can hinder overall goal performance by causing one to overlook alternative opportunities for achievement”, amongst other negative consequences. This explains why ProductiviDo encompasses a “Review” step which deals with this particular problem and more, described in section 2.3.4.

While this self-regulation technique can be applied successfully in the context of a task manager, it bears mentioning that it is not a panacea as it suffers from some limitations, one of which being that “formulating multiple implementation intentions is ineffective when changing unwanted behavior […] due to interference in the enacting phase of the planning process”. In other words, multiple implementation intentions can compete for attention, which makes one lose focus. To drastically mitigate this issue, ProductiviDo dedicates an entire step to “Focus”, which is described in more detail in section 2.3.3. The “Review” step will help with reducing the number of tasks one has to juggle with while there will be a “Prioritize” step (described in section 2.3.2) to help users decide which tasks to focus on before they get conveniently extracted in the “Focus” step.

2.2.3 Calendars, planning & scheduling

Section 1.4 introduced some of the core benefits of using calendars for planning and scheduling, yet scientific examination supplies a treasure trove of additional findings justifying their use alongside a task manager. A study exploring the use of a personal calendar discovered that most interviewees prefer a weekly view to aid with “opportunistic rehearsal”, a fact that sits well with the need for a reviewing system such as the one proposed in section 2.3.4 as well as the realization that a simple list or Kanban presentation is helpful but not sufficient to get a clear overview of one’s schedule at a glance. The same study made it clear that most users rely on their calendar to store efficiently certain types of information such as the date (97%), time (96%), location (93%) and purpose (69%). Quite convincingly, participants also used their calendar for “tentative event scheduling”, revealing the need to empty their mind to stay on top of their duties, a need addressed with the “Inscribe” step referred to earlier. This study also emphasized the fact that calendars can be viewed on the web from most devices or even printed for offline reference. Finally, this paper also found that a majority of users (63%) reported using reminders and alarms with the help of their calendar.

Even though almost two thirds of working professional consider using a calendar application to be very important in their workflow, it was also found in another study that “it is inconvenient to schedule on calendar apps”, which supports the use of task managers for that specific necessity since they can alter tasks brilliantly and speedily. Calendars are not necessarily the best tactic when it comes to scheduling all kinds of activities either. Indeed, “when consumers schedule their leisure, they may inadvertently reduce their utility for the activity”. With this type of activity, the authors divulge that “roughly scheduling (i.e., without pre-specified times)” constitutes a practical alternative. This results in effective scheduling when tasks are entered via a task manager and synced with Google Calendar since blocks of activities can still be displayed in the calendar view without the added burden of specifying a strict duration for each event.

There are some use cases that simply are not well suited for task managers, such as synchronizing events from Gmail (i.e., capturing tasks from different sources), setting reminders on appointments scheduled by third parties (where the primary source of truth must remain the calendar itself) or sharing a schedule with groups across the G suite applications with the help of smart suggestions coming from Google users’ data which is not entirely available to external applications.

2.3 The four pillars forming a new approach: evaluating their effectiveness

2.3.1 Inscribe

Inscribe screen.

ProductiviDo features four core components to help tackle one’s work skillfully, the first of which being all about jotting down tasks, a demonstration of the “generation effect” which assists with remembering information better. At this stage of the process, the idea is to record any potential future action that is required while being fully aware of the impact that such action will have on one’s life, benefitting at once from reducing one’s cognitive load by storing or discarding thoughts that do not require immediate response. “Inscribing” in this application is an intentional step demanding a certain level of mindfulness and acts as a precursor to the use of implementation intentions as it similarly “serves an important self-regulatory function” according to a study on mindfulness done at the University of Rochester. A 2020 study from Bieleke and Keller found that “opportunity-focused plans are especially important for initial progress towards the goal”, therefore this step ensures —through questioning the user’s aspirations— that the task is indeed a priority and that it is not just a distraction by evaluating its “leverage”, a notion introduced in section 1.4.

2.3.2 Prioritize

Prioritize screen.

There is substantial evidence to establish that the concept of a “master list” has been popularized and has found multiple concrete applications (e.g., as a list of relevant jobs held by an applicant, as an Excel spreadsheet keeping track of crucial information at a high-level, in some jurisdictions in the legal world, etc.), including as a way to manage tasks, an idea also sprouting from Edmond Lau’s work. In the context of task management systems, a master list manifests itself as a centralized location where all tasks are accessible once they have been “inscribed”. With ProductiviDo, “prioritizing” is a transient state: it is about handling a database of data to be referenced later when progress must be undertaken on specific tasks. It is a digital space separate from the current areas of focus (presented in the following step in section 2.3.3) used to find the next priorities to work on, where filters are available to that end (see section 3 for the technical details). As defended by Bellotti’s research as a set of desirable features, the “Prioritize” step offers the “ability to sort by importance and deadlines” as well as a “smart prioritization” of tasks by default, where the most important ones will flow to the top of the list, ready to be acted upon. Because tasks listed in the “Prioritize” step are forcibly distinct from those listed in the “Focus” step as they are mutually exclusive, this intermediate step helps to reduce the number of tasks shown in the schedule, improving one’s perceived control of time, busyness and stress.

2.3.3 Focus

Focus screen.

Once there are prioritized tasks in the application defined in terms of implementation intentions, science dictates that there is a need to “support the viewing of entire task vistas, but also allow different perspectives for different kinds of planning” and for “top priority items to be made apparent”. It is also known that setting clear goals eliminates intrusive thoughts and that “commitment to a later behavior was linked to reduced rather increased strain on mental resources”. For these reasons, the “Focus” step is a crucial component of the application. This component has the additional benefit of mitigating the problem uncovered in section 2.2.2 about the lesser efficacy of having multiple implementation intentions at once because it helps to recall all the high-leverage tasks in a filtered version of the master list (i.e., the current working list), leading to the observation of the Zeigarnik Effect which states that “an activity that has been interrupted may be more readily recalled”. In addition, seeing a list of promises to oneself in the form of MCIIs “seems to facilitate behavior change even when there is an initial reluctance to engage in the targeted behavior”. Even more benefits from MCIIs include “sustained task value and higher persistence”, two aspects that contribute to goal achievement and, consequently, to turning a task manager into an efficacious product.

2.3.4 Review

Review screen.

At this point, a working list of tasks exists to “Focus” and a backlog of work remains to “Prioritize”, yet not all labor should be brought to fruition as initially planned. Life circumstances change and “plans to deliberate can be used to increase the likelihood of deliberation and thereby the effective processing of newly available information”, which can help eliminate or update tasks that are no longer considered important or relevant enough given an ever-changing environmental context. A paper on making informed scheduling decisions also noted that “self-monitoring and self-reflection often affect behavior, and this change typically goes in the desired direction of improvement”. These findings can be applied practically by creating plans focusing on overcoming obstacles to make sustained progress, allowing one to ponder every major decision during the journey. A 2021 study on task management tools proposed to break complex tasks into smaller chunks (using a sophisticated approach with dependency graphs), an idea that can auspiciously be employed in a simpler way by breaking down a larger unit of work into smaller ones, which can be done during the information-gathering phase (i.e. the “Inscribe” step) as well as during the reviewing phase with existing units of work, which is known as “compartmentalization”. This self-reflection process can also contribute to one’s well-being by providing written cues to recollect positive images from past accomplishments. Looking towards the future, cueing the users to imagine positive outcomes and encouraging them to restructure their priorities can equally evoke optimism and improve life satisfaction while inspiring them to live according to their personal values. After all, a “person who sets up life and its routines to avoid inner conflict between goals is better off in the sense that he or she ends up feeling fewer bad emotional states and is generally happier”.

Review screen, showing a filter being applied.

3 Design

3.1 Domain and target audience

ProductiviDo is a task management system staying clear of project management and time management, geared towards being a capture and review tool leaving notifications and scheduling to external systems, primarily to Google Calendar in these first product iterations. As such, the target audience is represented by conscientious people desiring to optimize their productivity with a tool discouraging multitasking, who don’t mind hand holding to achieve their goals — willing to trade off flexibility in exchange for a more rigid system backed by science —, expecting a simple set of essential features for a distraction-free environment to get things done and wanting to manage their own set of personal tasks (as this product is not designed with teams or businesses in mind).

Explicitly supported users include people who want to follow a useful system without having to build it from scratch (e.g., setting up projects, tags, custom priorities, etc.) as well as those who need to keep track of tasks involving others with basic functionality (via Google Calendar and filters in the application). The application will not cater to those who want to rely mainly on desktop applications (because the core of the application is mobile only), nor to those who want to use a calendar other than Google Calendar (which is the only calendar undeniably supported in this version) or those who are looking for a solution integrating into other applications, since there will be no publicly accessible API at first to make this possible.

3.2 Design decisions and principles

Designing and wireframing in Figma.

Section 2 abstractly laid out the foundation for the core ideas being implemented in the application meeting the needs of the target audience. Concretely, a few design principles listed in “The Pocket Universal Principles of Design” inform how the application has been thought out, markedly:

The 80/20 rule: “80 percent of a product’s usage involves 20 percent of its features”, which is true with ProductiviDo where users will spend most of their time focusing on the work they have to accomplish;
Chunking: “Chunk information when people are required to recall and retain information”, where each task will display the most important information to contextualize work;
Constraint: “Limiting the actions that can be performed to simplify use and prevent error”, where each screen will have a single function with a premedidated lack of customization;
Five Hat Racks: the five ways in which information can be organized (i.e., category, time, location, alphabet, and continuum), all of which are supported by ProductiviDo;
Form follows function: “Aesthetic considerations should be secondary to functional considerations”, where the application maximizes the functionality available on each screen while taking into consideration the primary interactions needed at each step, regardless of the visual impact these decisions have;
Garbage in, garbage out: “Make it impossible to store bad data types”, where the application will not accept invalid inputs on any field that could jeopardize the integrity of the data;
Nudges: “smart defaults, clear feedback, aligned incentives, structured choices, and visible goals”, where the app makes the purpose of each interaction crystal clear;
Progressive disclosure: “A method of managing complexity, in which only necessary or requested information is displayed”, where filters are selectively shown to match the intent of each screen and where optional fields are hidden away by default until they are needed.

It is noteworthy that calendar integration will be optional and that the application will remain fully functional without relying on external calendars for maximum convenience, especially while users are offline. Even though this work underlined the usefulness of calendars when used as companions for task managers, one of the primary goals of a task manager is to be available at all times regardless of internet connectivity so that users can access their list of priorities and get work done: requiring an active connection and access to a calendar via sign-on before being able to do any work would break the principle of least astonishment in this type of application.

Some of the original wireframes for the Prioritize screen.

3.3 Structure of the application

The application is structured in such a way that each screen has a single function and that the user is guided through the process of adding, editing, and reviewing tasks4. The application is designed to be as simple as possible, with a minimalistic interface and a limited number of interactions to keep the user focused on the task at hand. Technically, it is arranged according to a pyramid schematic architecture, where the “hub” is the hamburger menu which links to all other pages and where all the sub-pages can go back to the “hub”. In this architecture, the tab navigation at the bottom of the screen lists the core sub-pages which are always accessible and can lead back to the hub as needed so that the user does not need to remember how to get from one screen to another, since they are all identified with both a recognizable icon and text label.

The application is structured in a way that makes it easy to add, edit, and review tasks, with the following screens:

Inscribe: Looking at the tab bar (bottom part of the wireframes) from left to right, this is the first screen meant to be easily accessible and also the first step that is part of the process of managing tasks by carefully adding them to the system;
Prioritize: this is the screen responsible for displaying the list of tasks that have been added to ProductiviDo in the first step (Inscribe) but still require planning (i.e., they represent the tasks to prioritize);
Focus: Once the tasks have been prioritized from the previous screen (Prioritize), they are ready to be scheduled and worked on, which is the purpose of this screen — it displays the current working list of tasks in a digestible format;
Review: Periodically (daily, weekly, etc.), the application will ask the user to review the tasks that remain to be completed to ensure that they are still relevant and that they are still a priority.

Edit task screen.

These core screens are accessible at all times from the tab bar to allow for easy navigation between them. The application will also have a few other screens that are not part of the core workflow but that are still important for the user experience:

About: This screen will display information about the application, such as the purpose behind each aspect as well as the version number;
Help: There will be a help system embedded in this screen to help users understand how to use the application and how to get the most out of it, which will be fully searchable;
Recycle bin: Sometimes, tasks will be added to ProductiviDo by mistake or they will be completed before they are scheduled. This screen will allow the user to review and restore these tasks if they are still relevant;
Accomplishments: This screen will display a list of tasks that have been completed and will allow the user to review them and reflect on their accomplishments;
Settings: This screen will allow the user to customize the application to their liking, such as changing the theme, determining default values on new tasks, etc.

About screen.

These secondary screens are accessible from each core screen in the top-right corner to toggle the presence of a “drawer” menu. The menu can also be revealed by swiping from right to left on the screen. The menu will be hidden by default to keep the interface as clean as possible and to avoid cluttering it with unnecessary information. The menu will be revealed by default on the first launch of the application to help users discover the features available to them.

Menu screen.

3.4 Libraries and services

At a high level, the application will be built using React Native to support both Android and iOS platforms. In terms of software user-facing dependencies, the application will use the following libraries:

react-native-async-storage/async-storage: The application will use this library to store data locally on the device;
react-native-community/datetimepicker: This library will be used to display the date and time pickers;
React Navigation: This library will be used to implement the navigation system;
Redux: This library will be used to manage the state of the application;
NativeBase: it will be used to implement the user interface;
redux-persist: This library will be used to persist the state of the application locally on the device;
redux-thunk: This library will be used to implement asynchronous actions in the application;
react-native-collapsible: This library will be used to implement all the collapsible sections to provide progressive disclosure;
react-native-extended-stylesheet: This library will be used to implement the theming system;
nandorojo/anchor: This library will be used to implement the anchor system so that users can jump from one section to another in the help system.

The application will also use the following libraries to support the development process:

Eslint: This library will be used to enforce a consistent coding style;
Babel: This library will be used to transpile the code to support older versions of JavaScript;
Jest: This library will be used to implement unit tests;
react-native-testing-library: This library will be used to implement integration tests;
react-native-dotenv: This library will be used to manage environment variables;
react-test-renderer: This library will be used to implement snapshot tests;
TypeScript: It will ensure type checking is available app-wide and reduce the number of bugs.

On the backend side, the application will make use mainly of the following services:

Firebase: This service will be used to implement the authentication system needed to deal with Google accounts as an optional add-on;
Google Calendar: This service will be used to implement the calendar system;
SQLite: It will be used to implement the database system locally and will be backed up to the cloud.

Showing the database design behind ProductiviDo.

3.5 Plan of work

In a nutshell, the plan of work will be followed as shown below:

3.6 Testing and evaluation

The project will be tested primarily using the following methods:

Unit tests: Unit tests will be implemented to ensure that each component of the application works as expected. These tests will be implemented using Jest and react-test-renderer.
Integration tests: Integration tests will be implemented to ensure that the application works as expected when all the components are combined. These tests will be implemented using the apt react-native-testing-library.
User and usability testing: User testing will be implemented to ensure that the application is easy to use and that it meets the needs of the users. These tests will be implemented using a combination of user interviews and surveys.
Performance, load and stress testing: Performance testing will be implemented to ensure that the application is fast and responsive. These tests will be performed by simulating the presence of a large number of tasks and events.
Security testing: Security testing will be implemented to ensure that the application is secure, most definitely when it comes to protecting user’s data in the cloud to avoid data breaches.
Regression testing: Regression testing will be implemented to ensure that the application does not break when new features are added, using a mixture of automated git bisect scripts to locate anomalies and by automatically running test suites with Git pre-commit hooks.
Compatibility testing: Compatibility testing will be implemented to ensure that the application works on all the supported platforms.
Accessibility testing: Accessibility testing will be implemented to ensure that the application is accessible to all users.

4 Implementation

4.1 Overview

At its core, ProductiviDo aims to provide a system that facilitates “getting things done” in the manner of the famously successful productivity system GTD, created and shared with millions of people by David Allen. The system is based on the following principles, worth expanding on as it bears strong resemblance with the final design of the application:

Capture: All tasks and events should be captured in a single place, so that they can be easily accessed and managed. This is achieved with the “Inscribe” screen, the first step in the ProductiviDo system.
Clarify: All tasks and events should be clarified, so that they can be easily understood and prioritized. This is achieved in the “Inscribe” screen, where the user can add a description to the task or event along with necessary metadata to help classify and prioritize the data being added.
Organize: All tasks and events should be organized, so that they can be easily accessed and managed. While this GTD step does not map directly to a step in ProductiviDo, the “Focus” screen serves a similar purpose in that it allows the user to organize tasks and events into a list of immediately actionable items that are easy to reference.
Reflect: All tasks and events should be reflected upon, so that they can be easily understood and prioritized. With ProductiviDo, this is done in the “Review” screen, which invites users to review tasks logically according to their deadline, priority, and other metadata.
Engage: All tasks and events should be engaged with, so that they can be easily accessed and managed. ProductiviDo deals with this GTD step in a simpler way via the “Prioritize” screen and the “Focus” screen, which allow users to prioritize tasks and events and then focus on the most important ones.

4.2 Features implemented: a visual tour

Quick actions.

The application has the following features:

Add a task: The user can add tasks by navigating to the “Inscribe” screen and filling in the required fields. The user can also add a deadline date and time, a duration, a location, a priority to the task and so on. By choosing the type of task as “Calendar” and filling in the required fields, the task will be added to the user’s Google Calendar. This screen hides any navbar and tab bar to maximize the screen real estate.
Prioritize a task: The user can prioritize tasks by navigating to the “Prioritize”, where filtering options are available to help the user find the task to prioritize. The main task action that can be performed on this screen is to “focus” a task, effectively moving it to the “Focus” screen.
Focus on a task: The user can focus on a task by navigating to the “Focus” screen, where the user can see a list of tasks that are immediately actionable. The user can also filter the tasks to focus on. The main action that can be performed on this screen is to “complete” a task, effectively moving it to the “Accomplishments” screen.
Review tasks: The user can review tasks by navigating to the “Review” screen, where the user can see a list of tasks that are overdue, due soon (e.g., today, tomorrow, this week), due later (e.g., next week, next month, next year) as well as tasks that are “old” (i.e., tasks that have been added to the system more than a month ago relative to today’s date but have not been worked on yet). This screen features “quick actions” that are relevant to the tasks being reviewed. These actions provide the ability to reschedule a task, update its current state (i.e., move it from and to the Prioritize and Focus screens) and to delete a task without having to open the task details screen to edit it.
Filter tasks to review: The user can filter tasks to review by navigating to the “Review” screen and selecting the filter options. The user can filter tasks by one of the categories “Overdue”, “Soon”, “Later”, “Old” and by all of these at once when no filters are applied.
Edit task details: Once a task has been added to the system, it can be edited from any of the main screens (i.e., “Prioritize”, “Focus”, “Review”). The user can edit all the same properties as when adding a task as well as add new ones not present when the task was added. When a task is of type “Calendar”, its related details will also be updated on the user’s Google Calendar.
About screen: while the About screen does not provide any functionality related to tasks, it allows users to learn more about the application. The screen includes a link to the application’s website, a link to a dynamic feedback form to help ProductiviDo become a better fit for its users, an email address to contact the developers (which opens the default email client on the user’s device) and other less frequently accessed information, including a link to the GitHub repository of the project and a list of open source libraries used to create the product.
Help screen: the application has been designed to avoid relying on documentation in order to be used. However, the Help screen is a useful resource for users who want to learn more about the concepts involved in the application. It describes possible workflows and guides users through the application’s main screens so they will be able to use it even more effectively.
Recycle bin screen: ProductiviDo makes it very easy to access and manage tasks that have been deleted by the user. The Recycle bin screen allows users to restore deleted tasks (which are sent back to the Prioritize screen for the next round of prioritization) or to permanently delete them by emptying the recycle bin.
Accomplishments screen: While the Recycle bin holds all deleted tasks, the Accomplishments screen holds all tasks that have been completed by the user from the Focus screen. The Accomplishments screen is a great way to keep track of the user’s progress and to celebrate the user’s accomplishments, yet it also allows removing completed tasks from the system if the user wishes to do so.
Settings screen: The Settings provided by ProductiviDo allow users to customize the application to their needs in a basic way — and all settings are persisted across reboots of the application or device. There is a dark mode available to protect the users’ eyes from screen brightness. Other settings include the ability to set default behaviours on new tasks, set the increment in minutes to be shown in the time picker, set a different locale to represent dates and times and some more options to toggle the display of certain elements in the application.
Filters: What ProductiviDo lacks in customizations, it makes up for in filters. The application allows users to filter tasks by type, status, priority, deadline date, deadline time, duration, location and more. The filters are applied in real-time, so the user can see the results of the filters as they are being applied. The filters can be applied to any of the main screens (i.e., “Prioritize”, “Focus”, “Review”) and can be combined to create more precise filters.
Google Calendar: One of the key tenets of ProductiviDo is to make it easy for users to manage their tasks and to have a visual window into their schedule, which is achieved by integrating with the user’s primary calendar on Google Calendar. The application allows users to connect their Google Calendar account to ProductiviDo and to create calendar events from new or existing tasks. At the same time, this functionality remains entirely optional: users can choose to never opt in to the Google Calendar integration and can disconnect their Google account at any time, which will prevent any synchronization from happening between ProductiviDo and Google Calendar.

Settings screen.

Dark mode.

4.3 Techniques and methods

Help screen.

Beyond the libraries mentioned in section 3.4, the actual implementation of the application happened in the following way:

React Native bare workflow: The application was developed using the React Native bare workflow, which allows for the use of native code in the application. This was necessary to implement the Google Calendar integration, which was not possible using the Expo workflow.
State management: The application was architected in such a way that React Context was used to avoid “props drilling” and to provide a global state to the application, using data coming from the SQLite database loaded at launch. All context that does not require persistence is managed by React Context, while the rest of the state (e.g., settings) is managed by Redux Toolkit.
TypeScript: The app was developed using TypeScript, a typed superset of JavaScript that compiles to plain JavaScript. TypeScript was used to ensure type safety and to provide a better developer experience with autocomplete and other features that help developers write code with fewer errors.
React Navigation: The navigation between screens uses a combination of stack and tab navigation, with the main screens being accessible through the tab navigation and the rest of the screens being accessible through the stack navigation. Additionally, a drawer navigation is used to provide access to all secondary screens via the traditional “hamburger” menu.
NativeBase: This library was used to provide a consistent look and feel to the application and get access to components that are not available in React Native. Many of its components were put to use in the application, including Actionsheet, AlertDialog, Badge, FlatList, Modal, Switch and Transitions to name a few.
Google Calendar API: The application uses the Google Calendar API to allow users to connect their Google Calendar account to ProductiviDo and to create calendar events from new or existing tasks. The API is used to create new events, to update existing events and to delete events. The API is also used to retrieve the user’s primary calendar and to retrieve the list of calendars available to the user.
SQLite: The application uses SQLite to store all data locally on the device. The application uses the expo-sqlite library to interact with the SQLite database. The database is initialized at launch and is updated whenever the user makes changes to the data.
Form validation: The application uses the yup library to validate forms and to provide error messages to the user. Coupled with formik, the library provides a great way to validate forms and to provide a consistent experience to the user.
Custom hooks and functional components: This project explicitly embraces new React features such as custom hooks and functional components. The application uses custom hooks to encapsulate logic for all the main screens. The application also uses functional components to avoid the use of class components, which are considered legacy in React.

5 Evaluation: results and discussion

5.1 Successes

5.1.1 Planning and execution

Extensive research and preparation went into the project before writing a single line of production code. A multitude of potential implementations and concepts were explored in great details and the idea of the final product was refined from a very early stage, leading to a more focused development of the todo application. Because there existed a tangible vision of the desired outcome, it made it much simpler to define the database schema and the React context needed throughout the application to pass adequate data structures around. On a related note, doing all this work upfront helped to avoid wasting time learning libraries that would not entirely meet the needs of the application and to stop contemplating features that would not fit within the constraints of the chosen concept.

Another decision that proved to be quite useful was to postpone dealing with complicated services till much later during development. For instance, storing mock data as simple JSON allowed for quick iterations during development without having to manually add tasks one by one by using the application itself to do so. Once it came time to integrate database functionality, data was first stored as a temporary in-memory database for fast read/write speeds (because the task view, filtering and sorting was not optimized yet) and it was later persisted to disk. Likewise, external services (e.g., Firebase and Google Calendar) were only integrated until the internal application design was set in stone. Performance optimizations were favorably delayed until most of the logic was implemented, which gave ample time to test and refine the design, productively steering clear of premature optimization due to the changing nature of the application still being validated and tested by beta users.

5.1.2 Functionality achieved

One concept that served the final design well was a direct application of Fitt’s law, which states that “the time required to touch a target is a function of the target size and the distance to the target”, meaning that it is important to keep controls close and large when speed or accuracy matters. As a concrete demonstration of this law, tasks can be added with the touch of a single button in the “Inscribe” button located in the tab bar, making it frictionless for users to add tasks and events to the application. This meets the need of being “always on”, especially since all data is accessible locally without the need for an internet connection, allowing users to quickly get their priorities out of their mind and onto a digital device to allow for proper referencing later on. Other critical interactions such as focusing tasks and completing them can be done by tapping on a large icon next to each task.

The application allows visualizing all tasks at once in the “Prioritize” screen, which contains all necessary filters in order to make filtering and sorting through a growing list of incoming data not only feasible but also simple and practical. Indeed, the lack of hierarchical organization in the information architecture is absolutely intentional. This design decision allows flexibility with the use of filters without incurring a cognitive cost to understand how information is organized. As long as users are diligent with the metadata they input in the application (as they should if they wish to accomplish their goals), they will be able to easily find the information they need in the “Prioritize” screen. Excluding the hierarchical access to information, all other aspects of information architecture (location, alphabet, time, category) are available as filters to the users.

The “Focus” screen intuitively lets users know which tasks are most important to work on at any given time, sorting them by deadline, priority and other metadata, making the data “always actionable”. Since focused tasks are isolated from the rest of the data, users are able to focus on the task at hand without being distracted by other tasks. On this screen, users are able to complete tasks, which effectively disappear from the task list and are kept in the “Accomplishments” screen for later retrieval. This is a way to keep track of tasks that have been completed, which is a feature that is not available in the Google Calendar application and which complements its functionality very well. Additionally, this screen allows users to “restore” tasks, which performs the opposite action. Notably, it will prevent mistakes by letting users undo their actions; it will also allow users to review tasks and events that have been deleted and to permanently delete them as needed. This feature is not available in the Google Calendar application and contributes to making ProductiviDo a useful ally in this case so that events can be restored to the calendar view. The final active step required to use ProductiviDo effectively, found in the “Review” screen, provides complimentary functionality to that found in most modern calendar applications. While a calendar is useful to get a sense of upcoming events, a review system is needed to stay on top of one’s priorities to make sure that time-insensitive yet important events do not slip through the cracks. The “Review” screen is a way to make sure that users are not only aware of the tasks and events they have scheduled, but also of the tasks and events that they have not scheduled but are important to them. Furthermore, reviewing one’s work periodically in an automatic way allows for better planning and will make sure that longstanding tasks are either updated, prioritized, delegated or removed.

5.2 Failures and limitations

The following points of failures are discussed in more details in section 6.2, where solutions for brighter times ahead are pictured.

5.2.1 Google Calendar integration

ProductiviDo solves real-world issues related to task management and scheduling in a robust manner, yet it does so partially. One major caveat to the current implementation is that it supports only Google Calendar, which severely limits the potential market the application can tap into. Because only Google Calendar was taken into account during this project, it is highly likely that the application will not be able to support other calendar applications without a major overhaul of the codebase. The application was thought to be a companion to Google Calendar from the ground up, which means that while it integrates seamlessly with it, it creates tight coupling between the two applications. There are in fact more issues to delve into when it comes to Google Calendar. In particular, full synchronization of tasks and events is not supported in a scalable way. For one, Google Calendar API’s daily and monthly rates are limited: instead of calling that API on every little detail being updated in a task, the application should really try its best to batch requests so that heavy users will not be penalized if they happen to trigger many updates in their calendar or if Google decides to lower the number of requests that can be processed in a given amount of time. Another pitfall is that the application does not support recurring tasks as originally intended due to lack of human resources, which is a feature that is available in the Google Calendar application. While it is technically possible to implement this feature, more context would need to be stored in the application to avoid duplication of tasks in the database and to allow recurring tasks to be reset to their original state or updated as desired, all of which would need to communicate with the Google Calendar API in an efficient way. There is, at the moment, no task tracking facility: a completed task is simply removed from the list of tasks by updating its status in the database. This is a considerable limitation, since it prevents users from creating tasks that are recurring, such as weekly meetings or monthly bills.

5.2.2 Unit testing

One clear oversight in the development process was the lack of unit testing. While the application was profusely tested in a manual way, it would have been much more efficient to have had a suite of unit tests that would have allowed for a more sturdy and scalable application. ProductiviDo comprises a few essential unit tests regarding the Google Calendar integration, but it is nowhere near the level of testing that would be required to ensure that the application is robust and that it will not break in the future. Amongst some of the types of tests that should have been implemented are unit tests for the database, unit tests for the application’s business logic, snapshot testing and testing of asynchronous API calls through mocking. In hindsight, the reason more tests did not make it into the final application is that the development process was not agile enough to allow for the time required to write unit tests and there have been too many side experiments that have taken priority over the core functionality of the application. Of equal relevance is the fact that unanticipated issues have arisen during the development process, which have required more time and effort to be spent on fixing them rather than on writing unit tests. It is also important to keep in mind that unit testing is not a one-time activity: it should be done continuously throughout the development process, more akin to the test-driven development (TDD) workflow. Failing in that department was a major setback for the application, since it will make it harder to maintain and to scale in the future and it likely contributed to the fact that more time was spent on debugging than was necessary.

5.2.3 Advanced features powered by AI

Besides the issues already raised in this section, there are a few other features that would have optimized the user experience, but which were not implemented due to lack of time as otherwise the scope of the project would have fallen appreciably out of reasonable proportions. For instance, the application does not support batch editing of tasks, which is a feature that is available in many other task managers in one form or another. It also does not support location-based notifications, which would have been useful to send reminders to users based on their location. The application does not make use of advancements in machine learning: learning users’ preferences over time to provide helpful shortcuts when creating new tasks could have been a fantastic time saver. ProductiviDo could have stored task templates such that creating recurring tasks would be faster and more intuitive by providing logical default values based on what the algorithm thinks is going to be needed next. Similarly, the app could add locations, people, and other properties to tasks once it figures out that certain actions only happen in given locations or with the same people repeatedly. Yet another feature that would have proven handy would be to provide time-based notifications based on predictions from past data derived from tracking user movements and time taken to complete specific types of tasks. For instance, if a user has a task that is due at 9:00 AM, the app could send a notification to the user’s phone at 8:45 AM if the user is at home, but at 8:30 AM if the user is at work once the travel time could reliably be estimated from prior activities.

6 Conclusion

6.1 Salient takeaways

ProductiviDo set out to fathom the needs of the modern-day, demanding user and to provide a novel solution to the problem of task management and scheduling. The application was designed from the start to work alongside Google Calendar, which is a popular calendar application that is used by many millions of people around the world. The application was designed to be a simple and intuitive task manager that would allow users to create tasks and events, to schedule them, and to track their progress. While there is room for improvement, ProductiviDo goes far beyond a proof of concept or “Goldilocks Quality” and shows how it can be used by anyone who wants to manage their tasks and schedule more efficiently, as it relies on strong scientific foundations that were dispersed throughout this work as convincing evidence backing up such a claim.

One of the key takeaways from this work is that despite a crowded task management digital market, innovation can take place by taking inspiration from different fields and by applying them to the problem at hand. In the case of ProductiviDo, the needs of business users and productivity seekers alike were distilled into an almost mechanical process, where the application flow is extremely simple and strives to put forward in a visually sensible manner all the required functionality to get work done without friction: this meant taking a few assumptions about users for granted, knowingly reducing the user base to better serve those who will resonate with the offering.

There are a few dominant players in the industry, albeit niches are still well underserved. Almost every software application out there in this space endeavors to serve customers in a very generic way, but it could be flourishingly argued that a task manager could be designed to serve a specific industry. For instance, a task manager for a construction company could be designed to be more intuitive for construction workers, who are not necessarily computer savvy, and could be designed to be more efficient for project managers, who are likely to be more tech-savvy. The same could be said for a task manager for a law firm, a task manager for a restaurant, or a task manager for a school. The possibilities are endless, and the key is to understand the needs of the users and to design the application to be as intuitive as possible. Even though “task templates” can, up to a point, be used to achieve this, nothing competes with a well-designed application that is tailored to the needs of a well-known target audience. Such applications will by definition be adopted within a given niche and will dispense unique value to the users. A generic task manager may be suitable for simple projects and may require fiddling around with the settings to get it to work for a specific use case, but a task manager dedicated to culinary chefs will natively understand and care for concepts such as “ingredients” and “recipes”, which will be baked into the product (no pun intended).

6.2 Improvements and future research

Even though Google users abound, using exclusively Google Calendar as an calendar integration is not a universal solution. In the future, it would be interesting to explore the possibility of integrating other calendar applications such as Apple Calendar, Outlook, and others. This would allow users to use the application with their preferred calendar application and would also allow for a more seamless integration with the calendar application, which would be a great benefit to users.

Expanding on the notion of “delegatees” explored in this project, a task manager with built-in collaboration would be welcome to further satisfy the needs of business users. This is because a calendar can become social and collaborative by itself, and it is not uncommon for colleagues or friends to share their calendars with others. This is especially true for business users, who often need to coordinate their activities with other members of their team. It would certainly not be far-fetched to have business teams be formed and given access to their shared task assignments and calendars. This would allow for a more efficient and transparent way of working together, and it would also allow for a more efficient way of tracking the progress of a project and would pave the way to generating insightful analytics dashboards, another place where machine learning would shine by finding patterns and making it possible to optimize overlapping schedules and projects based on people’s availability, area of expertise and so on.

Recent reports have shown that job creation and entrepreneurship is at its highest peak and that the United States of America is leading the way in terms of new business creation, with literally millions of companies being born each year. This is a great sign for the economy and it shows numerous opportunities in the business world when considering task managers embarking on a journey to become a collaborative platform for teams and businesses within a specific line of work. In the meantime, ProductiviDo comes to the rescue of the millions of people who are looking for simplicity and intuitiveness in a task manager to get their work done with less technological grinding.

Demo of the app

Reviewing the process of building a first React Native application

Sébastien Lavoie — Sat, 04 Mar 2023 12:41:00 -0600

Introduction

In the context of an assignment as part of a BSc in computer science, I had to come up with a React Native application. Specifically, I chose to build an app to help make and break habits through the use of a solid system that’s backed by science, which is presented through a large excerpt that accompanied the end result. It helps people to consistently stick to habits until they become an intrinsic part of their routine. Moreover, it helps to maintain an actual routine and to build a sense of accountability and capability in oneself, because big successes come from small steps taken in the right direction time and time again.

Instead of giving dopaminergic hits like other apps which strive to reward their users in one way or another for completing their tasks and goals or generating anxiety around items not being completed, this app focuses on giving full control to the user with a proven system to turn their habits into automated behaviours with ease. That was the idea, at least.

Concept development

The origin

The idea for this application came from listening to the Huberman Lab podcast from Dr. Andrew Huberman in an episode entitled The science of making & breaking habits. Starting from this excellent learning resource, further literature was devoured to inform the final concept, most notably Psychology of Habit from the Annual Review of Psychology and Intervention to Modify Habits: A Scoping Review published in Sage Journals.

Time restrictions

It was entirely feasible to come up with a simpler concept that would be doable in roughly 10 weeks. Like many popular applications on the market today, it is expected that new features will be added after the official release date once additional and valuable feedback is received from users. The core idea can and will be implemented in this short time frame. After all, this application can pivot towards a simpler presentation should there be a need to and as the Zen of Python says: “Simple is better than complex”. Niceties could be added to the user interface should time allow: however the initial development will focus on a narrower set of features so that the roadmap can be successfully followed and the final product delivered in a timely manner.

Main concern during development

A bad implementation of the system could mean that flexibility could be lost at the cost of ease of development. In other words, due to a strict, looming deadline, some shortcuts could be considered to cut corners in the underlying logic of the application to save time without affecting the quality of the product from the user’s perspective. Nonetheless, this could lead to more headache down the road when it becomes necessary to refactor the application in order to satisfy the need for a more modular approach, which would simplify further development.

Wireframing

Low-fidely as well as high-fidelity wireframes were created using Figma. An exhaustive presentation of the final application was included in an appendix, depicting the logo, the color palette, the typography used, a list of the UI elements and a complete and faithful display of all the screens. Technically, the high-fidelity wireframes were designed using Figma components and placed inside “frames” to export a PDF. Most UI elements were hand-drawn, except for a few free icons taken from the Material Design community. Numerous user flow diagrams were included to illustrate how the wireframing took shape once the logic to navigate between screens was determined.

User feedback

User feedback was critical to the success of this project. Users helped refine certain visual aspects, such as making sure there was enough padding between the different elements by testing with devices using a smaller screen.

Improvements to the original design

Other notable improvements included redesigning the user flow when creating a new programme so that it would be easier to follow. Instead of dealing with multiple habits at once, the slightly updated design made it possible to fully complete the cycle when adding a new habit. Similarly, once habits were added, the newer flow to tackle habit stacks made it simpler to navigate back to the main screen to confirm the selection of habits and to review the programme as a whole.

Without users inquiring about having a satellite view in the map, there wouldn’t have been any option to toggle the style of the map either. This became a needed addition in places where roads are sparse while the terrain remains easily recognizable.

Prototyping

Early iterations

While shaping the initial application alongside both wireframing and concept sketching, a few iterations of the different screens were designed from scratch. General ideas and concepts were discussed and analyzed to fit with the goal of creating a mindful habit tracker while taking into consideration hard requirements such as the time available for the development cycles.

The application started with a strong focus on accountability. However, it was quickly realized that the technical stack would need to be more ample and would necessarily require a higher budget to fund the use of online services to store a database of “habit contracts” that users would create and optionally make public on their own. Needless to say, the single developer involved in the creation of this application did not have the resources nor the willingness to deal with legal issues that would arise from managing such personal information.

Privacy concerns

Additionally, there would not have been the easy possibility of making accessible all the data from a habit contract since personally identifiable information such as location, accountability partner names and so on would be revealed to the world. For these reasons and many more, the set of features relating to accountability was removed from the application to ensure that user privacy would be dealt with properly at this scale of operation.

In this regard, to avoid any potential issue with privacy, no data whatsoever is stored remotely. React Native Async Storage was used to store data locally on users’ devices, even removing the need for an internet connection (except for the need to find the user location and set an address, which is an optional step when creating a programme).

To make use of the async storage, Redux Toolkit was used to deal with all the state management and is responsible for dispatching actions throughout the application. Importantly, users do not need to leave the application open at all times since Redux Persist was used to store Redux data to the async storage and to rehydrate it when the application is re-opened.

Development

As we can now attest, a lot happened before developing the actual application, but this fact did not make the development itself less interesting to narrate! In a little over two months, this React Native application started from nothing and grew to a fully-fledged product.

Initial setup

The initial steps taken were all about setting up the project correctly with most of its JavaScript dependencies, beginning with a .gitignore file to prevent adding secrets and other unneeded artifacts to the project, an app.json to define the metadata required to publish an application with Expo and a package.json listing all the major dependencies to be installed with Yarn in this case. Secondly, Reactotron was set up with Redux to provide access to the application state in real time. Strict mode was then enabled to help avoid bad programming practices and third-party libraries were silenced with React Native’s LogBox module.

State management

Once the basic setup was in place, Redux Persist was added to work with React Native Async Storage. Then, the testing setup was integrated into the project before adding any screen to the application using Jest configured with mockAsyncStorage to avoid issues with the persistent storage while testing. Despite barebone Redux being useful on its own, Redux Toolkit provides some useful utilities and shortcuts that were taken advantage of, including createSlice to easily “slice” parts of the state to retrieve and store information in isolation, combineReducers to list all the slices of state in the same “root reducer”, and configureStore to connect the persistent storage to the Redux store and set up access to the store itself in the rest of the application.

Styling the app

Before adding logic to the project, react-native-extended-stylesheet was used to add functionality to the way the styling could be done by having the ability to reference variables, do calculations inside CSS fragments, etc. Styles were set globally right from the start to avoid code duplication and where deemed useful, some screens had specific stylings applied exclusively to them from separate files.

As a next step, the general structure of the app was set up with a status bar and a SafeAreaView component to make sure that rendering happened within safe limits on the screen. In order to style the application and render different screens, React Navigation was used to make the navigation possible and to initially render a fixed screen at a time while it was being designed based off the high-fidelity wireframes. One by one, the screens were designed with all the buttons in the right place and some dummy content to render all the different UI elements. This led to using a multitude of third-party libraries, including notably react-native-maps to work with native maps on both Android and iOS devices.

Premature refactoring

With the screens in place, the code was re-arranged to allow for better flexibility while developing. New directories for components were created, and the smallest components of all were extracted from the larger ones to start splitting concerns and have specific destinations to receive parts of the states via Redux selectors.

Global styles were then cleaned up considerably and local styles were mostly eliminated as they were being re-used elsewhere without notice. At this point, without yet having anything useful to demonstrate, users reviewed where the application was going and suggested possible improvements while it was still easy to move UI elements around without breaking anything.

Once all the screens were designed and ready to include programmatic logic, the screens were then linked together so that the user could –without doing anything useful yet– navigate from one page to another. After that, a menu was included in the top-left corner to navigate to specific pages from anywhere within the app. This behaviour was later customized so that some pages would show the “back button” (a chevron icon pointing to the left) to make going back to the previous screen easier than scrolling to the bottom of a longer page. On top of this, some screens received a special treatment where the menu is hidden entirely, such as when deleting a programme from the app. While not strictly required, this made it obvious to the user that they should focus on the content of that particular screen.

Customizing UI elements

At this stage, the application was ready to receive its final touch-ups to look as polished as the expected product. This included getting our hands on React Native Bouncy Checkbox to give a more joyful feel to the most boring parts of the application and using React Native DateTimePicker to input the time of the day in a more meaningful and straightforward way.

Setting up simple states

Using the useState hook from React and useDispatch from Redux, basic states were set up to toggle the styles of buttons and to allow basic interactivity, such as expanding and collapsing sections of the user interface. Using some dummy content in the Redux store, other simple events were taken care of, for example removing a habit, creating a new habit and so on. With the basic logic and states in place, more complex flows were added, such as the need to loop through habits to display them as “habit stacks” or looping through the days in a programme to display three phases for each day, each phase containing possibly multiple stacks of habits and each habit being a self-contained source of data with a table displayed with react-native-tableview-simple.

Testing on different platforms

Although admittedly a bit late in the process, the application was then tested fully on Android and in the Expo website. Trading off speed of development for the inconvenience of guaranteeing a pixel-perfect application at each step was most definitely worth it since very few changes were required in the end, this being the main idea behind using something like React Native in the first place so that code can be written once and for all. Despite all these promises, some issues related to dependencies were faced with big, red messages showing an alarmingly large list of errors in the Expo Snack interface. Thankfully, it was only a matter of upgrading locally to match the latest SDK available at the time from Expo (v46.0.0).

There were some minor issues observed on different platforms which were fixed on the development machine using simulators. For instance, the map view was somewhat laggy on iOS originally, so instead of moving the marker around on the map, it was decided to leave it fix on top of the center of the map with a greater zIndex to make it visible at all times in order to have only the map view to re-render each time the map was moved. On Android, the time picker was a bit fiddly to work with and so to circumvent the problematic situation, the picker would be shown once automatically to the user when the related screen was opened, removing the need to display a space for the picker on screen and instead having it fill out the screen in the style of a modal.

Improving the developer experience with Redux

Reactotron was useful in the beginning but started to crash very often at this point of the development. After un-starring the project on GitHub and starring React Native Debugger instead, things were smooth again. Reactotron required messing a little bit with the testing setup by removing everything related to it first, then React Native Debugger made it all simple again thanks to its seamless integration with Redux which does not need to be injected as middleware when configuring the Redux store.

Refactoring again

Now that most of the logic was implemented, smaller components were created from the monstrous ones created thus far. In most instances, components were already existing on their own but they were all positioned in the same file without being prefixed with the keyword export. Equally important, all ESLint warnings were cleared up one after the other to avoid re-renders and unused bits of code. Because Expo tends to be picky with missing import statements, import React from ‘react' was carefully added to almost every file in the project where it was needed.

Last-minute cleanup

Finally, once the application was usable and the source code a little more pretty, import statements were grouped by categories, warnings from third-party libraries were silenced with LogBox, spacing around paragraphs was reviewed and optimized and the app was scrutinized once again to look for the presence of bugs.

Unit testing

Navigating

While the development took place, testing happened all along. The first couple of tests to be included in the test suite were added while validating that navigation occurred correctly between screens. At once, tests were also added when creating the screens to make sure that they would render consistently in the UI by creating snapshots with Jest.

Utility functions

More concrete unit testing happened with the utility functions being called by the actions from the Redux store. Because these functions define what happens when an action is dispatched with Redux, there is a lot of potential for bugs to creep in. To make debugging less painful in these cases, dummy and minimal states were set up as part of the unit tests to check for inconsistencies against the input value and the expected one. While Jest offers a complete range of features, the matchers used most often from this library were toBe to check for exact values (e.g., Boolean and numbers) and toEqual to assert a deep equality on objects and arrays. Mock functions were set up with Reactotron, but that need went away when the developer migrated to a more stable piece of software (i.e, React Native Debugger).

Database & asynchronous code

In the future, should this application be deployed to the cloud, there will be a need to use setup and teardown functionality against a database and to add tests for asynchronous calls. This was not required for the present version of the application, which focuses on allowing users to be as independent as possible from the Internet while respecting their privacy.

Evaluation

Overview

All in all, despite a strict deadline and few (more truthfully, close to none) monetary resources, it was possible to deliver a working solution to a tangible problem, namely that of increasing productivity by knowing what is most valued in one’s life circumstances. While the application can be considered feature-complete, it could be the beginning of a long journey towards sharing an application that has real potential to improve people’s lives by solving a problem that is hard to pinpoint without enough awareness.

Technical aspects

On the technical side of things, it would have been preferable to split the state in a more logical way right from the beginning. Even though a general idea of the state was drawn inside an IDE by creating a JSON object to represent the schema to be adhered to, the state was allowed to mutate along the way, which caused issues by having to move reducers around and by having to update the selectors to look at a different hierarchy of the state. By contemplating the real meaning of a Redux “slice” in which the state is meant to be entirely independent from other slices of the state, it makes it obvious that some types of object will remain independent while others will eventually require to communicate with their siblings. Thinking this logic through before starting to make things happen in the UI is, in hindsight, a fruitful endeavour.

Communicational aspects

On the soft skills side, a mistake was made by not sharing the original concept with users sooner. Although the final product would likely resemble what it ended up being, interactivity in the application could have been designed better regarding some aspects. For example, the component responsible for displaying the frequency of execution could very well become an actual calendar. Designed in a compact way, a calendar surely would be more familiar to most users instead of having a list that needs to be scrolled into view. Functionally speaking, ticking a box in a calendar-like view would be exactly equivalent to checking off a box next to a row item in a list, but the presentation would be more familiar to most users and, quite understandably, more intuitive too.

Demo of the app

Resources and references

If you like this type and format of content, you might also enjoy a follow-up story about building a task planner, also brought to life with the help of React Native!

Building the next Facebook in a couple of weeks (as a humble experiment)

Sébastien Lavoie — Fri, 14 Oct 2022 18:49:00 -0500

Introduction

The following is a report that was part of a project I delivered during my BSc in computer science, reformatted from LaTeX to Markdown. While not being utterly interesting (unfortunately, the source code cannot be freely published due to the nature of the work…), it gives a glimpse of my thought process while building this Django website. I have learnt a few lessons from it and maybe, with some imagination, you might too :). To read a nicely formatted version of this article, you can refer to the original report instead.

Meeting the requirements

In order to meet all the requirements when building this application, a few different techniques, strategies and concepts were put to good use. Firstly, all Django views are class-based and rely on Django REST Framework to reduce the boilerplate needed to write the views. One such (simple) view is shown below:

 python
 
 
 
class Profiles(APIView):
 """Used when listing all profiles at once."""

 # allow everyone to see all basic profiles
 permission_classes = [IsOwnerOrReadOnly]

 def get(self, request):
 profiles = UserProfile.objects.all().order_by("-id")
 serializer = ProfileSerializer(profiles, many=True)
 return Response(serializer.data)

All views in turn rely on serializers to parse incoming data and to transform it into appropriate structures that can be used internally by Django. Some serializers are obviously more complex than others, but for demonstration purposes and for the sake of brevity, an example of a class-based serializer is reproduced here:

 python
 
 
 
class UserPublicSerializer(ModelSerializer):
 """Serializer the User model to get back user information that can
 safely be shared around in the application to other users."""

 # We need easy access to the profile image when listing all profiles
 # at once
 profile_image = SerializerMethodField()

 class Meta:
 model = User
 fields = ["id", "name", "profile_image"]

 def get_profile_image(self, obj):
 return obj.userprofile.image.url

The actual implementation details for signals, forms, URLs, other views and components can be explored in the source code submission provided with this report.

When it comes to version control, Git was used religiously with GitHub to host a private repository. The Conventional Commits specification was followed to help create meaningful commit messages.

Defensive coding strategies were used, both in Python and in JavaScript. In the backend, exceptions were raised directly where no appropriate actions could be taken:

 python
 
 
 
def clean_email(self):
 """Verify that the email is available."""
 email = self.cleaned_data.get("email")
 query_set = User.objects.filter(email=email)
 if query_set.exists():
 raise forms.ValidationError("email is taken")
 return email

In the views, conditional statements were sprinkled everywhere where necessary to avoid expansive computations (e.g., processing a profile image when the request is invalid) and to return early from functions:

 python
 
 
 
# ...
if profile is None:
 return Response(
 "Profile not found!", status=status.HTTP_404_NOT_FOUND
 )

if profile.user.id != request.user.id:
 return Response(
 "You do not have the required permissions "
 "to update this profile!",
 status=status.HTTP_401_UNAUTHORIZED,
 )

serializer = ProfileUpdateSerializer(profile, many=False, data=data)
if serializer.is_valid():
 serializer.save()
 return Response(serializer.data)
# ...

On the frontend, a kindred approach was used to assemble robust requests:

 javascript
 
 
 
try {
 const response = await axios.post(
 `${process.env.REACT_APP_API_URL}/auth/jwt/verify/`,
 body,
 config,
 )
 if (response.data.code !== "token_not_valid") {
 dispatch({
 type: AUTHENTICATED_SUCCESS,
 })
 } else {
 dispatch({
 type: AUTHENTICATED_FAIL,
 })
 }
} catch (err) {
 dispatch({
 type: AUTHENTICATED_FAIL,
 })
}

With security in mind, views were by default protected and accessible only to authenticated users unless a statement such as the following allows all users to read an endpoint:

 python
 
permission_classes = [IsOwnerOrReadOnly]

Requirements were also exceeded by using advanced techniques and tools: Docker, Docker Compose, Poetry, React, Redux, Material UI as well as setting up an SMTP backend to send emails to users were some of the additions made to the project to prove this claim – these will be covered in more details in later sections of this report.

While being a simple application considering time constraints and budget, the solution brings some novelty to the table, making it a valid application that is production-ready while also serving as an excellent prototype for a much bigger project. Some interesting features not commonly found elsewhere include:

Being able to chat in real-time with all users of the platform in a time-sensitive context in a way that supports high concurrency with Django Channels and Redis. In other words, messages disappear automatically after a specified delay, making for a special chat room where one lives in the moment.
The application allows users to easily follow others to then be able to quickly search through their posts by filtering them. The added tweak resides in the fact that all posts are given “total points” without “up” or “down” counts being disclosed directly.
Posts can be hidden at any time by users yet remain viewable by showing the author as being anonymous.
The colourful profile list view allows filtering of all the profiles at once by name and shows distinctive information about users, such as the list of people they follow or the list of people who are following them as a non-obstrusive modal (Material UI pop-up).

As will be discussed in the section State of the art in web development, this solution follows best practices and aims to represent the state of the art, both in terms of technical execution and in the contemporary look of the final product, which is brought into the spotlight in the following figures.

Running the application

Installing and running the web application

Accessing user accounts

All accounts are registered with the same password: pass1234.

To log in, simply use one of the following email addresses:

 
 
 
admin admin@gmail.com (superuser for Django admin)
Andrea andrea@gmail.com
Bob uol.grader@gmail.com
Hider hider@gmail.com (hidden profile)
Mia mamamia@gmail.com
Suliman suliman@gmail.com
Tuan tuan@gmail.com

If you set the SEND_ACTIVATION_EMAIL setting to True in the configuration file socialnetwork/settings.py, emails will be sent from the account uol.grader@gmail.com, which is a real account created to manage emails for this application.

Running locally

Backend

To avoid a layer of abstraction as setting up Redis on some systems may be more difficult, Django’s backend is used for the channels by default. Should you require to use Redis instead, please follow the instructions in settings.py:

 python
 
 
 
CHANNEL_LAYERS = {"default": {
 "BACKEND": "channels.layers.InMemoryChannelLayer"}
}
# To use Redis locally, please comment the above line and uncomment the
# following two dicts:
# CHANNEL_LAYERS = {
# "default": {
# "BACKEND": "channels_redis.core.RedisChannelLayer",
# "CONFIG": {"hosts": [("redis", 6379)]},
# }
# }

# CACHES = {
# "default": {
# "BACKEND": "django_redis.cache.RedisCache",
# "LOCATION": [("redis", 6379)],
# "OPTIONS": {
# "CLIENT_CLASS": "django_redis.client.DefaultClient"
# },
# }
# }

Then, a simple way to get Redis running would be to launch it with Docker:

bash

docker run -d -p 6379:6379 redis

Moving on to installing Django and the rest of the dependencies for the backend:

 bash
 
cd backend

# Activate a virtual environment, e.g.:
python3 -m venv .venv && source .venv/bin/activate

# Install dependencies
pip install -r requirements.txt

# Run the server on port 8000 with existing data
python manage.py runserver

Dependencies can also be installed with Poetry thanks to the provided files pyproject.toml and poetry.lock with the following command:

bash

poetry install

To keep the Docker image simple, pip is used to install the requirements, although beware that Poetry’s dependency resolver will be more predictable in a production application.

Frontend

 bash
 
cd frontend

# Install dependencies
npm install

# Run the server on port 3000
npm run start

Access the application at http://localhost:3000.

Using Docker

A docker-compose.yaml has been prepared to launch all the required parts at once (Redis, Django and React).

bash

docker-compose build
docker-compose up -d

Some other useful commands:

 bash
 
docker-compose down
docker-compose logs
docker-compose ps -a

This container could be set up to run in a cloud infrastructure such as Google Cloud Platform inside a virtual machine. This setup goes above and beyond what was taught in this module, though, therefore resources were not allocated to the actual deployment.

Local deployment

An alternative to the (costly and unfunded) deployment on GCP can be done on a local machine, using Docker to containerize the application and a service like Cloudflare Tunnel to allow traffic from the external world to reach the application, effectively converting the machine into a server.

Summary of the steps needed to deploy locally

Buy/use a domain name and configure its DNS with Cloudflare.
Update Django’s settings.py to allow the domain name to reach the Django application – avoiding CORS issue when localhost:3000 tries to connect to localhost:8000 using that domain – (i.e. ALLOWED_HOSTS).
Install the CLI tool cloudflared, log in to your Cloudflare account with cloudflared tunnel login.
Create a new tunnel: cloudflared tunnel create test-tunnel.
Route that tunnel: cloudflared tunnel route dns <T> <N>, where <N> is the web address to use as a sub-domain and <T> is the tunnel ID.
Add this sub-domain to the DNS management console in the Cloudflare dashboard.
Configure Cloudflare to use the web application:

 
# ~/.cloudflared/config.yml
url: http://localhost:3000
tunnel: SOME_ID_GIVEN_BY_CLOUDFLARE
credentials-file: ~/.cloudflared/SOME_ID_GIVEN_BY_CLOUDFLARE.json

Finally, run the tunnel with cloudflared tunnel run and go to the configured website at its subdomain (e.g., name.domain.com).

Functionality implemented

This application implements all the necessary functionality at the account management level with Djoser. In effect, users can:

Sign up for a new account;
Activate their account via email upon creation (this behaviour is disabled by default for convenience but can be reactivated as mentioned earlier);
Reset their password via email;
Log into their account;
Change their displayed name;
Make their profile hidden to other users;
Log out from their account;
Delete their account permanently by validating their password.

User profiles provide the following features:

Number of followers as well as a complete list of followers shown;
Number of people that a user is following as well as a complete list of these people;
Number of points a user has “given” to posts they like;
Number of points a user has “taken” from posts they dislike;
Where the user is located;
Each user can display a biography;
The date at which a user joined the social network;
The latest date at which the user updated their profile;
A “status” field to prominently feature a statement, which is also shown in the profile listing;
A list of posts written by the user, where the owner can create new posts, delete, edit or hide existing posts so they are no longer displayed publicly in their profile nor in the list of public posts;
An image gallery the user has uploaded, where the owner can add or remove pictures;
The ability for each user to delete their account, effectively cascading a delete of their interactions in the application such as their posts, profile image, etc.;
Users can edit the information they share with others;
To avoid profile pictures slowing down navigation – most notably in the profile list view – all images are automatically resized to maximum 300 by 300 pixels when a user uploads a new image;
Finally, users can also hide their profile entirely – doing so will then mark all their posts as being anonymous and they will not be reachable by any other user of the network.

Following the “profile” view, the “profile list” view (linked with the text “Meet” in the navigation bar) shows all public profiles with most of the information users share. To view the details of a profile (such as a birth date and the date of the last edit of a user), it is necessary to be authenticated, otherwise unauthenticated users will be redirected back to the “profile list” view and an error alert will be flashed. Additionally, the number of followers and people users are following are displayed right from the list view and allow to click to retrieve a complete list of people who are followed. The different icons shown on this page really pop out: the more followers a user has, the bigger the number of people shown in the actual icon representation; also, an icon indicating a value of “0” is slightly greyed out for readability and to let users know they won’t be able to interact with these icons.

As a distinctive mark of interest, everything belonging to a user is marked with a fingerprint icon: when a user views their own profile or posts, they will be able to quickly identify that this information is theirs as long as they are logged in.

Posts implement a basic editing view and allow their author to hide them. Furthermore, posts receive and lose points based on the opinions of users in the network and will end up with positive or negative scores, similar to what Reddit and Stack Overflow have done but without splitting the count in either direction.

The “Read” page – to be found in the navigation bar – shows posts from people users follow at the top, allowing to filter the content of posts based on their interests. The total number of points is shown next to each post entry. As a section section on that page, users have the ability to see a list of public posts as well as search for keywords of interest, just like in the first section just described.

On any page that gets longer than 500 pixels when scrolling down, there will be a little arrow icon allowing users to swiftly glide to the top of the page.

When clicking on the avatar icon displayed in the top-right corner of the application, a “drawer” (in Material UI’s terms) will open to allow users to quickly jump to their profile and to log out of the application.

Behind the scenes, administrators and superusers can be created with full privileges to modify and delete other accounts. These special accounts will be hidden by default from the public-facing frontend, although their profile can later be made public and used as any other account on the website.

Last but not least, there is a public chat room where all users of the application can go to have a spontaneous discussion. In fact, the web application is programmed to automatically discard messages that are older than 20 seconds (by default), allowing users to share special moments that are very much unique and time-limited while avoiding being overwhelmed by content. In the event that a constant flow of messages might be entering the chat room at a given time, users will still have the ability to scroll up in the view (assuming they read fast enough). If they do not scroll up, the view will always focus on the latest incoming message so their attention span will be maintained on this very moment. Every time a user reloads the page or goes somewhere else in the application, the content of the chat window will disappear on purpose, because good discussions are meant to happen in real-time on this website. Users will not be distracted by anything else other than a little avatar icon and people’s names so they can know at a glance who is interacting with them… but they will need to have a good memory to remember everything. After all, the idea behind this chat application really is to exchange some good thoughts in the moment. What lives on is only the memory of time well spent with others.

At the API level, users can interact with the application directly via API endpoints, provided they send their authentication token should a view have a requirement in this regard. These endpoints are listed succinctly below, but a file openapi-schema.yml has been provided in the backend directory for a complete reference.

 
 
 
accounts/ profiles/
accounts/ profiles/<int:user_id>
accounts/ profiles/<int:user_id>/image
accounts/ profiles/<int:pk>/followers
accounts/ profiles/<int:pk>/followers/add
accounts/ profiles/<int:pk>/followers/remove
accounts/ profiles/gallery/add
accounts/ profiles/gallery/remove/<int:gallery_pk>
accounts/ ^media/(?P<path>.*)$
api/ posts/<int:pk>/
api/ posts/author/<int:pk>/
api/ posts/<int:pk>/up/
api/ posts/<int:pk>/down/
api/ posts/<int:pk>/pointsby/
api/ posts/

Executing the unit tests

To run the unit tests, it is a matter of activating a virtual environment (as described in the section Running locally) and using the built-in test command provided by Django in the following manner, which must be run from within the backend directory:

 bash
 
 
 
$ python manage.py test
Found 119 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
..............................................................
--------------------------------------------------------------
Ran 119 tests in 0.584s

OK
Destroying test database for alias 'default'...

Logical approach

Frontend framework: React

The application was designed with the goal in mind of having a modern frontend framework relying on an excellent CSS framework to provide icons and other components. Speaking of components, React was chosen for its strong focus on designing small components that can be reused. Taking advantage of this approach, some components such as the “profile intro” (the box showing the main information regarding a user profile) are literally displayed on different pages, such as when viewing a single profile or when viewing a list of profiles.

Similarly, a “post” entry represents the exact same React component when viewed in isolation or when browsing for many more posts. When search bars are used, these share the same characteristics and behaviors across the page while managing a different state.

React components and icons: Material UI

On the design side, the presentation of the website was made much more consistent with the help of Material UI, which provides many ready-made React components. The whole application was built around the concept of adding building blocks from Material UI such as a “box”, “button” or “typography” to guarantee that all aspects of the application look homogeneous and with the same modern style.

Components such as a “drawer” and a “navbar” really sped up development and were expected to be used extensively right from the start.

API: Django Rest Framework

Since the use of Django was mandatory for the backend part of this work, Django REST framework was an ideal choice considering the need for an API to be directly accessible to end-users and to benefit from an easy-to-use toolkit to build an API that can be accessed from React without breaking a sweat.

Django REST Framework simplifies data serialization and even allows dealing with nested serialization in a straightforward way. Because it comes with powerful features for authentication and permission management, it was also a great option for this specific use case which depend easily on these sets of features which would arguably be very complex, error-prone and time consuming to implement manually.

User management: Djoser

Beyond Django’s default user management system, there was a desire to extend the default behaviour, for instance to use an email address instead of a username to authenticate users. Djoser makes these changes and much more a lot more simple, adding easy management of logins, logouts, password confirmation resets, activation emails and so forth.

By leveraging Django’s built-in features with Djoser, the user model can be extended with ease and flexibility.

Asynchronous communication

To build the chat application, Channels and WebSocket were considered as one of the best combination of libraries because they are simple to use and allow high concurrency to be possible. Channels makes it easy to create an asynchronous WebSocket consumer to deal with many users connecting to possibly many different groups: it is therefore an ideal option for a growing social network.

The WebSocket library in JavaScript is then used to communicate with Channels via the WebSockets technology, sending and receiving messages with additional payload to extend the functionality of the chat application.

Deployment: Docker, Cloudflare Tunnel

To deploy an application to production, Docker Compose is a robust and reliable solution, especially for this use case where different microservices can be pieced together seamlessly, sharing resources across a single network on different ports.

Docker makes it possible to containerize parts of the application (i.e., the backend, frontend and in-memory cache database) to be run potentially on many virtual machines in the cloud and Docker Compose makes the process of orchestring an application such as this one much more accessible than configure web servers from start to finish.

Poetry, a package and dependencies management system for Python, allows requirements to be pinned to specific versions and ensures reproducibility is achieved, which is critically important when it comes to deploying to production. Its dependencies resolver is much more reliable when the exactitude of a list of requirements must be met.

In terms of deploying a real application on a small scale, Cloudflare Tunnel was also considered as it is useful to share prototypes during development and to instantly deploy a local server. Furthermore, it can work hand in hand with Docker Compose and Poetry since a container can be run in the background and the application can be exposed on multiple ports locally without having to configure firewalls.

Because pip is traditionally used in the Python world to manage requirements, the command pip freeze was used to generate a standard list of pinned dependencies, although for an actual deployment to production, an open source alternative like Poetry would likely be preferable.

Formatting: Prettier, Black, Vulture, Pylint

While code formatting is of utmost importance for readability, it is also a tremendous waste of time to try to do it manually. For this reason, multiple tools were used to aid with this gargantuan task. Prettier was used on the frontend side to format everything related to JavaScript and CSS.

On the backend side, Black was the primary formatter used. Its use was complemented with Pylint, which helps to clean up and refactor the code by finding hard-to-spot warnings, such as unnecessary return statements or the use of more complex expressions when an equivalent such as a list comprehension could be used.

Finally, to keep the code tidy and alive, Vulture was used to find “dead” code not in used anywhere else. Even if code is well formatted, code that is not needed become a liability. In the source code world, less really is more.

API calls: Axios

The Axios JavaScript library was used for the attractiveness and flexibility of its API. Because it supports fully the Promise API and allow making asynchronous calls with the async/await syntax, it makes for a good tool to communicate with the backend. It has extensive documentation and excellent support on various web platforms including GitHub, which is an important consideration when thinking about deploying an application in the real world.

There are new and shiny technological options all the time, but a battle-tested software like Axios remain a competent tool apt for the job.

State management: Redux and Immer

Despite the Context API from React being powerful and easy to use, Redux and Immer really make dealing with state management a breeze. Redux on its own is one of the best in its category to provide state management at scale: its documentation is also fantastic and detailed and its popularity on Stack Overflow is only a plus in its favour should there be a need to fix issues while using it (because there will inevitably be such a need). The Redux workflow with actions being dispatched with types makes sense and adding new features is very fast without having to change existing pieces of states when combining reducers.

One possible drawback of using plain Redux to manage the store is that states can be mutated and unexpected consequences may ensue. For this reason, Immer was included so that dealing with a Redux store is stripped down to a direct object assignment, where Immer takes care of updating items and even nested items as needed.

Design and implementation decisions

Because deployment with Docker was a primordial concern, the application was built with a backend that is completely decoupled from a frontend. In fact, with just a little bit of ingenuity, Django could be swapped entirely with another web framework as long as the same endpoints are provided to the frontend with the necessary technologies (such as web sockets) being implemented. In a similar way, the frontend, which is built primarily with React, could be upgraded to another popular alternative such as Vue.js. This gives flexibility and should there be a greater need for optimization once the social network takes off for a real spin, there is the possibility to bundle React with Django by building minimized versions of the assets and shipping everything as a Docker container that can be run on powerful machines in the cloud.

Beyond this original concern, more concrete decisions were taken. For instance, Django signals were used to simplify how user profiles are created. Instead of allowing users to create a profile from their user account, the experience was unified by transparently automating this process whenever a user account is created such that it is attached to a newly created profile associated with it. Leaving the option to the end-user of manually creating a profile could be confusing at best and lead to unexpected results at worst, where user accounts and user profiles IDs become out of sync, which is a nice side-effect of having them created as well as deleted at the same time.

From the start, Djoser was chosen to override specific built-in functions performed by Django and to facilitate email management. To integrate Djoser with the administrative bits of the application – namely, the Django admin interface – Django forms were used to customize how users are to be registered as well as superusers and staff accounts. By overriding the user creation, it is now possible to update parts of the process with simple configuration variables implemented by Djoser, such as forcing users to retype their passwords or not.

With Django models, the base model became a UserAccount, which allow users to join the network. However, the functionality related to account management is kept separate from other features of the application by interfacing with the accounts using a UserProfile model on which a user field exist. In turn, this model integrates other parts of the models, such as many-to-many relationships with followers and a gallery image model, which is also linked as a many-to-many relationship. Another part of the application implements a Post model where the author field corresponds to a UserAccount, effectively linking a different part of the application to the user accounts. Again, a Post then interfaces with other models to take points into account, which are also linked to user profiles.

To manage all kinds of POST requests as well as to guarantee that models communicate as expected between each other, serializers using Django REST framework features were used in the process. These generally use a SerializerMethodField to define more complex behaviors, such as getting all non-hidden followers for a single profile.

Views were implemented with DRF APIView, bridging the gap between a RESTful API and the ability to define simple views using methods like get and delete. Views rely on serializers and specify a permission_classes list of custom values, which were implemented separately in a permissions.py file. This allows customizing the default behavior so that by default all views require authentication unless explicitly stated otherwise by these permission classes. This is also more secure, preventing users from inadvertently being able to access what should have been protected resources.

In terms of API definition, simplicity was key: every endpoint regarding authentication is accessed under /auth while our specific implementation of user accounts is accessed under /accounts. Additionally, all endpoints to deal with user posts are to be found with an endpoint starting with /posts. Finally, there is another set of endpoints to work with profiles, these being accessible under /profiles.

The Django chat application, due to its asynchronous nature, uses different technologies behind the scenes, including notably WebSockets. Channels was chosen to implement this portion because it extends Django’s capabilities beyond HTTP and is ideally suited for chat applications like the one being built as part of this social network.

Evaluation of the final product

What worked well

Opting for React made for a flexible framework that behaves extremely well with Django. React has complete documentation and extensive support offered on different medium, making it ideal for a robust and complex web application. Coupled with Material UI, the frontend aspect of the work was taken care of and didn’t need particular attention when developing. For any basic functionality that was not available out of the box in JavaScript, the Lodash library was used to make object comparisons and such much more readable and understandable when multiple conditions were being evaluated in a JSX expression, often with ternary operators.

The state was managed beautifully with Redux and the Redux Devtools web browser extension, allowing for rapid iterations and feedback where debugging would otherwise become very cumbersome. The useState hook was used profusely to separate concerns as well.

Keeping with React, the application was divided into logical sections that made it easy to add new features. Small components were created for different parts of the application, Redux actions and reducers were stored in their respective directories, containers and other higher-order components were given a special place in the frontend hierarchy, utility functions were well organized and accessible, pages and custom hooks also had their own place to reside.

Deploying with Docker remained a clean process, where a single Dockerfile was created to power the backend and another Dockerfile added for the frontend. Finally, all these instructions were put together with a readable docker-compose.yaml file, which purpose was to join all the different containers in a single place and to allow adding more microservices, such as Redis. Postgres was not used in this version for practical reasons when sharing the source code of the web application with others, but only a few steps would need to be taken to update Django’s settings file as well as pulling from DockerHub a suitable image to run Postgres.

Testing with Django went particularly well: the documentation had a clear guide about testing and any aspect of the application – serializers, views, models, forms, consumers, signals and so on – were tested according to the Django standards, leading to a whopping total of 119 passing unit tests, which are to be found inside a tests directory inside each Django application within the project.

What could have been improved

Planning of the technical stack could have gone much better. During the experimentation phase in the early steps of this project, good portions of functionality were implemented using Django templates without any frontend framework, except for the CSS framework Bootstrap. Features such as user notifications, personal messaging between two users with the ability to use different “inboxes” and “threads” was a very good selling point of the first version of this web application. Alas, due to time constraints, these useful additions were left behind (preserved with a Git history) but did not manage to make it to the final product. It would have been much more productive to take a closer look at the panoply of requirements to be implemented from the very beginning and determining the best fit as early as possible to avoid rewriting code from one framework to another.

Although Redux was a lifesaver in many circumstances, it was also a hurdle in terms of productivity because of its complexity and different moving parts. Being more careful to not use Redux at all costs everywhere possible, dispatching updates in the application would surely be simplified with the Context API using pure React or even some useEffect hooks, which were used profusely with good results. Immer was also introduced a bit later in the thought process when dealing with nested JSON objects. Although it made the remaining development easier, it was also probably a red flag meaning that the Redux store could have been simplified into smaller reducers where different selectors could access parts of the store that wouldn’t need to be nested objects. This may also indicate a flaw in the way models were implemented, but most likely there were errors made when dispatching messages in a part of the Redux store that really should belong somewhere else. In concrete terms, dispatching an event regarding users inside the “user” reducer was probably more complicated than simply dealing with all notifications in a different reducer. In actuality, this led to some dispatch actions that did more than one thing, which is not ideal when thinking about the concept of separation of concerns.

Although this is not perceptible in the final product, Django migrations were at times a pain to work with. This is because the models weren’t thought through very well at the beginning and despite the iterative process being an inherent part of software development, iterating over models in Django definitely counts as an exception to the rule where clearly defined models will not cause migrations to break or need to be modified in any way. It would have been more productive to produce well-designed diagrams, depicting the architecture of the application as well as the complete schema of the database to avoid surprises down the road.

State of the art in web development

On a technical aspect, many parts of this web application conform to modern web standards. The latest stable release versions of libraries were used whenever convenient and/or possible. This non-exhaustive list would include, at the time of this writing, React 17.0.2, Redux 4.1.2, WebSocket 1.0.34 and Material UI 5.5.0 for the frontend. On the backend, Django 4.0.3, Channels 3.0.4, Djoser 2.1.0 and Redis 4.2.0 were used.

When dealing with dependencies, Poetry was used with great benefit to make sure that Docker containers could be deployed reliably. Using Docker and Docker Compose was another touch that was added since most contemporary software will ship with a Docker solution for convenience. An excellent example in this regard would be PlantUML, a Java-based application to generate diagrams from textual descriptions that can be deployed in only a few seconds via Docker, launching a local server with the full capabilities offered by the piece of software in question. Nowadays, with Docker containers being more secure and very fitting for a deployment to the cloud at most big technology companies, it really is a best practice adopted by good software teams to work with containerized versions of their products.

The wider community was consulted in an effort to bring the maximum quality possible to the end result. Concretely, advice was taken from prominent figures in the web development world, including Dennis Ivanov and Laith Harb, both Django and React experts and Corey Schafer, an accomplished software developer from the Python world. Nigel Poulton – author of Docker Deep Dive – served as a good reference for the deployment part. Real Python was a godsend with its in-depth articles, for instance about debugging code with Pdb. Less well-known yet high-quality content producers inspired work with Djoser and the implementation of user posts, including Bryan Dunn and Legion Script. Cloudflare was also one of the best resources used to deploy a secure web server locally and to learn about JSON web tokens and their use specifically with Python. Needless to say, the official documentation from each major framework and tool was referenced all way through, many names which are going to sound familiar by now – Django REST Framework, React, Redux, Immer.js, Django, Djoser, Channels, etc.

sglavoie.com – Tag: BSc

Building a task planner with React Native: an academic journey

Preamble

1 Introduction

1.1 Inspiration: the main contenders

1.2 Drawbacks of existing solutions

1.3 Market overview

1.4 Motivation

2 Literature review

2.1 Previous work

2.1.1 Todoist

2.1.2 Trello

2.2 Contributions from the literature and gaps being filled

2.2.1 Initial design justifications

2.2.2 Implementation intentions

2.2.3 Calendars, planning & scheduling

2.3 The four pillars forming a new approach: evaluating their effectiveness

2.3.1 Inscribe

2.3.2 Prioritize

2.3.3 Focus

2.3.4 Review

3 Design

3.1 Domain and target audience

3.2 Design decisions and principles

3.3 Structure of the application

3.4 Libraries and services

3.5 Plan of work

3.6 Testing and evaluation

4 Implementation

4.1 Overview

4.2 Features implemented: a visual tour

4.3 Techniques and methods

5 Evaluation: results and discussion

5.1 Successes

5.1.1 Planning and execution

5.1.2 Functionality achieved

5.2 Failures and limitations

5.2.1 Google Calendar integration

5.2.2 Unit testing

5.2.3 Advanced features powered by AI

6 Conclusion

6.1 Salient takeaways

6.2 Improvements and future research

Demo of the app

Reviewing the process of building a first React Native application

Introduction

Concept development

The origin

Time restrictions

Main concern during development

Wireframing

User feedback

Improvements to the original design

Prototyping

Early iterations

Privacy concerns

Development

Initial setup

State management

Styling the app

Premature refactoring

Adding navigation

Customizing UI elements

Setting up simple states

Testing on different platforms

Improving the developer experience with Redux

Refactoring again

Last-minute cleanup

Unit testing

Navigating

Utility functions

Database & asynchronous code

Evaluation

Overview

Technical aspects

Communicational aspects

Demo of the app

Resources and references

Building the next Facebook in a couple of weeks (as a humble experiment)

Introduction