Skip to content

blahosyl/task-manager-frontend

BranchesTags

Repository files navigation

On Fire 🔥 - the cheerful productivity app

This app lets users track tasks in a simple, visually pleasing and functionally colored app. It features multiple filtering options at a click, and an intuitive UI without overwhelming settings & lists.

App showcase

Developer: Dr. Sylvia Blaho

See the development progress and further plans on the Project Kanban board.

GitHub last commit GitHub contributors GitHub language count

Table of Contents

Table of contents generated with readme-toc

UX/UI

The app is intended for smaller groups/teams to complete relatively simple, everyday tasks. Currently, all logged-in users can see and comment on all tasks, so it is suitable for implementing in a closed environment or for tasks that do not contain sensitive information.

Accordingly, I chose a less work-oriented project for the mockup content: a typical Berliner team of tech workers organizing a team event: a grill party on a boat.

Since the available development time for the current version of the app was only a little over 3 weeks, more fine-grained access control using projects has been relegated to version 2.

Strategy

Most popular productivity apps focus on corporate contexts, consist of a lot of complicated fields and charts, and focus less on the look and feel. The goal of this project is to develop an app that is more suited to non-work tasks and emphasizes ease of use and a positive user response.

The polarity of project execution

The name of the app evokes the polarity of situations and emotions that occur during every project. The positive end of the spectrum is when we's breezing through tasks, colloquially referred to as "You're on fire!" At the other end, there's the feeling that everything else is on fire, and we're paralyzed by indecision as to which one to put out first – or we're desperately trying to convince ourselves that "this is fine!", as immortalized by the widely memeified Gunshow webcomic.

Someone's emotional state and general well-being influences their productivity just as much as factors considered more objective, such as their skill level and time commitment.

Conservative design of productivity apps

Unfortunately, the polarity described above is seldom taken into account. Supporting productivity is mostly thought of as just issue tracking. Many productivity apps focus on function rather than design, and have a surprisingly uniform look, often in dark blue and gray.

Cumbersome filtering

Filtering relevant tasks often means having to go through complicated menus or dropdowns.

Scope: holistic productivity

Assisting productivity is more than just tracking tasks. Users should feel content and energized, which supports sustainability and true productivity.

This is why the goal of the app is to fuse function with bold, accessible and upbeat design.

Bold colors carrying meaning

The color scheme of the app is reflected in the visual design of the cards containing individual tasks in a fuctional way: each priority status corresponds to a main color scheme from the palette.

Playful indications of overdue tasks

Overdue tasks are indicated by 🔥 emojis (the more overdue the task is, the more 🔥 emojis appear). This conveys important project information while at the same time maintainly a levity to the situation.

Easy filtering at a click

The app comes with built-in filters for the most likely use cases. These are accessible at one click from multiple views without having to reload the page.

Structure

Components

The component tree of the app is depicted below (generated with ReacTree).

It illustrates the extensive reuse of not only small components like Avatar or Asset, but also larger components like TaskList, ProfileList and Task.

This is discussed in more details in the section DRY.

Start of component tree

2nd part of component tree

3rd part of component tree

4th part of component tree

5th part of component tree

Access management structure

The project implemented signup, signin and signout functionalities by using Allauth in the backend.

CRUD functionalities are only available to logged-in users.

  • Pages available to Logged-out Users:
    • Landing (default)
    • Signin
    • Signup
    • Pages available to Logged-in Users:
      • Tasks
        • TaskKanban (default)
        • TaskList
        • TaskDetail (includes all Comment-related components)
        • TaskCreate
        • TaskEdit
        • TaskDelete (implemented with modal on TaskKanban/List/Detail)
      • Profiles/Users
        • ProfileList/Teammates
        • ProfileDetail
        • ProfileEdit
        • Username Edit
        • Password Edit

CRUD in the FrontEnd

The assessment criteria for the MVP require at least TWO forms, with validation, that allow users to create and edit resources in the Back-End API".

The present version of the app contains 3 such forms: Comment, Task and User. A profile instance is created automatically for each new user. (See the API documentation for more details on data structure).

The 5th model, Watcher, offers the same functionality not via a form, but by clicking the eye icon on a task.

Note

Since a Watcher instance only contains two ForeignKey fields, editing and deletion are effectively the same, since changing either the watcher or the watched task will amount to a different Watcher instance

3 of the API models have full CRUD in the UI: Comment, Task & Watcher.

Deletion of Profile and User instances is possible in the API, but not in the front end. This has UX reasons, as explained in the section UX improvements.

Users can only access CRUD on their own resources, not on those of other users.

Model Create Read Update Delete
Comment CommentCreateForm TaskDetail > Comment CommentEditForm TaskDetail > Comment
Profile created automatically with User ProfileDetail > Profile ProfileEditForm N/A
Task TaskCreateForm > TaskForm TaskDetail > Task TaskEditForm > TaskForm Task
User SignInForm ProfileDetail > Profile UsernameForm & UserPasswordForm N/A
Watcher TaskList & TaskDetail & ProfileDetail > Task TaskList & TaskDetail & ProfileDetail > Task TaskList & TaskDetail & ProfileDetail > Task TaskList & TaskDetail & ProfileDetail > Task

UI information design

Keeping with established principles, I structured information from top to bottom & left to right.

My goal was to strike a balance between putting as many links on a page as possible and not overcrowding the page: anitcipating user needs regarding what they are most likely to do next from any given page.

Skeleton

According to the mobile-first principle of design, I only made wireframes for mobile views before the start of development.

As suggested by my mentor, I have made wireframes for the following pages:

Landing page wireframe

Landing page wireframe

Task Kanban wireframe

This wireframe also features an expaneded navigation menu.

To improve on UX, filtering was later implemented using tabs rather than a dropdown selector.

Task Kanban page wireframe

Task create/edit wireframe

A number of elements on this wireframe were implemented using other UI elements than shown below. To make the UI more uniform, the fields of create/edit forms of the app ended up either being text fields or dropdowns (with the exception of the date and upload fields).

Task Kanban page wireframe

Surface

App name

The name "On Fire" incorporates the duality of accomplishing a lot vs. everything else around us seeming irredeemable. It reflects the ups and downs of task execution well.

Visual design

Color palette

I aimed for balance between harmony and contrast: terracotta and marron with a warm shade of teal.

Main color palette

The main colors shown above are supported by their darker and lighter shades to make a monochromatic but high-contrast color scheme for each task priority.

Logo

The logo evokes the Kanban board with different colored task cards forming a grid. It matches the main app colors.

Images

Elements on background images are positioned with intention, matching the image itself.

Only pages with relatively little content have background images, as these would be too distracting on pages with multiple tasks, filters or profiles.

Rounded shapes

As a counterpoint to businesslike straight edges, I have designed the app with the corners of most components rounded. This evokes a sense of playfulness and relaxation.

Emojis & gifs

Predictably, the 🔥 emoji features heavily in both the app name and the task overdue indicator.

Putting the emojified version of the "this is fine!" meme on the home page further underscores the app's theme.

To enhance playfulness, emojis are also included in the CRUD confirmation messages.

Typography

I made a long list of suitable candidates of suitable Google Fonts, then I made mockups of the app with the short-listed candidates. These can be seen under the corresponding GitHub issue.

In the end, I decided to use Kodchasan, as it evokes handwriting, while at the same time being very well legible. In addition, this font has a wide selection of weights and styles.

Mockup content

To carry on the playful theme, the mockup user images are in a cartoon style and in colors harmonizing with the overall theme.

UX Improvements

At the suggestion of my mentor, I have focused on UX improvements rather than maximizing models & CRUD in this first iteration of the project.

I have planned 49 user stories for UX improvements, and managed to complete most of them, heavily focusing on tasks and profiles:

I highlight a number of them below; the details and implementations can be found in the individual GitHub issues.

Color for visual effect as well as conveying information

While I intended the app to be visually interesting and colorful, I did not want this to be gratuitous. Instead, the bold colors of the app server as a visual indication of task priority.

Conditionally rendered names

To facilitate legibility, user's names are rendered conditionally depending on whether a firstname and lastname is filled in in their profile (the username is always present).

  1. show first and last name if both are available
  2. show first or last name if either are available
  3. show username if neither are available

In some cases, 1. is shortened to only show the first name even if a last name is available.

Tasks without an image

The Moments project that this app is based on requires an image to be added to every task created. This makes sense for the use case of the Moments app, being a photo sharing platform.

For the current task manager app, however, images play a much less important role than other types of content, also reflected in the layout of the Task Detail page. Thus, it would be unpractical to force users to add a photo to every task they create, so this is made optional.

I also decided not to use a placeholder image for tasks that do not have an image attached, as this would create an unnecessary distraction without adding information or a positive UX experience. Instead, the CardImage is displayed conditionally only if there is an image.

No empty task card for deleted tasks

When manually entering URL of a deleted task into the browser address bar, an empty task card was shown.

Empty task card shown for deleted tasks

While this is also present in the Moments sample project, it is not good UX, which is why I decided to change it for the present app.

Now, these pages show the "Not Found" page, which is much less jarring.

Explicit confirmation after user CRUD actions

I added confirmation notifications after a user successfully completes a CRUD operation, or presses the Cancel button on a CRUD form (#29). At the suggestion of my mentor, I used the toastify package, as it comes with push-style notifications out of the box.

Modal confirming task deletion

Since tasks are the most important in this app, I wanted to protect them from accidental deletion. This is why I added a confirmation modal to the task deletion function, as illustrated in the Features section.

Comments are not considered as important or time-consuming to create as tasks, so here I opted for convenience over caution, and let users delete comments without double-checking.

No deletion of Users or Profiles

For a content sharing app such as Moments, it is straightforward that when a user deletes their profile, their contributed content is also deleted.

For a task manager app, however, this has undesired consequences: the team most likely wants to retain tasks owned by users who are no longer working with them.

Therefore, I did not implement User/Profile deletion in this version of the app. The UX considerations described above call for more careful planning, which is outside the scope of the current 3-and-a-half-week development window.

Tooltip for watch/unwatch icon

I have added tooltips to the watch/unwatch icon, to make it more explicit for users that the icon is functional.

Visually pleasing "Not Found" page

A broken link is always annoying at best, anxiety-inducing at most. This is why I styled the "Not Found" page to be interesting, aesthetically pleasing and in harmony with the rest of the app design, with an eye-catching background image and a link to the home page.

Not Found Page

Slight timeout on redirect

I have noticed that retrieving the currentUser can be a bit slow sometimes, which caused the signup page to show instead of the page the Logged-in User requested. This is why I added a slight timeout to the redirect function adapted from the Moments app.

Project Management | Agile Methodologies

Themes, Epics, Stories & Tasks

The work to be done was divided into the following Themes:

  • Access management
  • CRUD
  • View content
  • Site elements
  • UX improvements
  • Setup & deployment

Each theme was then divided into Epics, and Epics into User Stories, as seen here (click here for the original Sheet):

Themes, Epics & User Stories

Each epic was assigned a distinctive color, which was also used for its label in GitHub Issues. Epics belonging to the same Theme were assigned colors of similar hues. This facilitated getting an overview of the work items.

Finally, User Stories were broken down into tasks. These can be seen for each User Story individually in GitHub Issues and on the Project Board.

Each user story has a list of acceptance criteria, which are the expected outcomes when the story is tested. An issue is only closed if manual testing confirms that the acceptance criteria are fulfilled.

The commits corresponding to each User Story are linked in each the GitHuB Issue.

As this was my first project using React, some User Stories have a very detailed task list, both as learning and as documentation/reference. Issues that have tasks that were already familiar only have high-level bullet points.

At the suggestion of my mentor, I have added several user stories to improve User Experience to the initial list:

Some work items that have initially been classified as Epics have later been reclassified as User Stories – typically these were "meta" items to do with testing and documentation.

Estimation

Estimating the time it would take to complete each User Story is notoriously difficult, doubly so with the first project in a new framework. This is why I did not assign sizes to the individual User Stories, instead, I treated them as one unit.

This proved to be the right strategy in retrospect, as inexperience caused me to take disproportionately long on tasks that would be much faster the second time around. On the other side, some other tasks could be completed much faster than estimated. All in all, the lack of relative sizing of individual User Stories did not have an adverse effect on the project.

Project Board

The Issues were added to the Project Board in GitHub Projects.

I have customized the Kanban columns to fit the project needs, and also added swimlanes representing milestones.

The project contains issues from both the FrontEnd and the API repository.

Project Board

Labels

I have used several categories of labels during the project:

  • Priority labels (those starting with p:)
  • An epic label to enable filtering between Epics and User Stories on the Project Board
  • A label for each epic (those starting with e:), to be assigned to the Epic and all its corresponding User Stories(since GitHub Issues does not provide any other way to link these). The individual epic labels are color-coded to match the Google Sheet containing User Stories
  • Other miscellaneous labels such as bug, enhancement, mentor, etc.

These have provided an excellent way to both filter Issues and to maintain an easier visual overview of them.

Prioritization: MoSCoW

As the available time for development was only 2.5 weeks (setting the last few days aside for testing and documentation), sorting User Stories into must have, should have, could have and won't have was done on the whole group of User Stories rather than on a sprint-by-sprint basis.

I have modified the MoSCoW method slightly in that I split the won't have label into two:

  • Issues with the label wont have are used for issues that will not get done in a give sprint as well as for duplicates or mistaken issues (the latter were closed when identified as such)
  • Issues not completed for the first release of the project but still to be done in further development work are assigned the label v2.

The links below show the User Stories excluding "meta" issues such as testing & documentation.

The statistics on total issues & User Stories excluding "meta" issues can be seen on the Statistics tab of the User Stories Google Sheet.

Epics that had User Stories of various levels of prioritization received all applicable labels. As the User Stories in the Epic were completed, the labels of completed User Stories were removed from the Epic.

Timeboxing

The available development time for the project was 3 weeks and 3 days. Accordingly, work items were divided into 4 milestones:

  1. API, auth, start page & task list
  2. CRUD & basic views
  3. UX, styling & comments
  4. Testing & documentation

The first 3 milestones were assigned the User Stories discussed so far, while the last milestone was planned for "meta" tasks like testing and documentation.

Each milestone was assigned to a sprint around 5 days in length.

However, as tends to happen in real life, different sprints had different velocities, which is reflected in the uneven number of User Stories completed in each sprint.

Sprint planning

At the beginning of every sprint, I reviewed the Issues assigned to the current milestone and decided the order in which they are to be implemented, in a more fine-grained way than the existing prioritization labels.

I also defined tasks for the highest priority items, with tasks definitions for lower-priority items following as soon as it became plausible that I can finish them that sprint.

Whenever I have received updated information about prioritization or implementation from my mentor or the Code Institute community, I would also make appropriate changes in prioritization during sprints.

Sprint retroactives

At the end of every sprint, I reviewed the items that were not completed, and either reassigned them to the next sprint, or to version 2 of the project.

Features

This section briefly introduces the features implemented in the current version of the project. For videos demonstrating how each feature works, see the Manual feature testing section of TESTING.md.

General features

Landing page

This page greets visitors who are not logged in. It has a striking and energetic background image, a short description of the app, and links to the Signin & Signup pages.

Landing page

Signup page

The signup page contains the Signup Form and a link to the Signin page. All fields of the signup form are validated.

The design features a salient custom image, and the position of text elements is responsively adapted to complement the image.

Singup page

Signin page

The signin page contains the Signin Form and a link to the Signup page. The all field of the signup form are validated.

The design features another custom image, and the position of text elements is purposely showcasing the image.

Singin page

Navigation bar

The Navbar is present on every page, and contains the links that are anticipated to be most frequently needed by users.

Navbar for visitors

The navbar for visitors features the logo and app name on the left, and the Signin and Signup icons on the right.

Navbar on desktop for visitors

It is collapsed on small and medium viewports.

Collapsed Navbar on mobile

When clicking the hamburger icon, the Navbar expands.

Expanded Navbar on mobile for visitors

Navbar for Logged-in Users

For this view, I have made considerable changes compared to the Moments project:

  • instead of links tofiltered views, the Navbar only has links to the Kaban & List pages, since these have extensive filtering options included.
  • I moved the + icon with the other Logged-In links
  • the NavBar only expands on large screens and above, to avoid overcrowding
  • only the user's short name is shown in the navbar

Navbar on desktop for Logged-in Users

On medium and smaller screen sizes, the Navbar includes an extra link to the Profile List page. This is not needed on larger viewports, as these have the Profile List shown in a sidebar on the main page of Task List and Profile Detail, and a link to the Task List is included on the Kanban page.

Expanded Navbar on mobile for Logged-in Users

I have changed the icon default, active and hover colors to provide more contrast to the background for accessibility reasons.

Navbar on desktop for Logged-in Users

Footer

The footer is also present on every page, but the information contained here is predicted to be used less frequently: the developer name and social media profile links.

Footer

Task features

Task detail page

The card header contains an avatar with a link to the assigned user's profile, the due date / watch box contains the watch/unwatch icon, and the bottom part of the card displays the avatar of the tasks's owner (creator) with a link to their profile.

Other fields are show when they are not empty.

The Color scheme of the card changes based on the priority of the task:

  • low (teal)
  • med (maroon)
  • high (terracotta/orange)

Task Detail page

Cards that are owned by (created by) the currently Logged-in User also have a vertical dots icon on the top right. Clicking this enables editing or deleting a task.

Comments

The bottom of the Task Detail page shows the comments on the task (if any), as well as the Comment Create Form. Each comment shows the author's avatar and conditionally rendered name.

Users can edit or delete their own comments using the vertical dots dropdown next to them.

Comments

Task List page

The task list features a more compact version of the task cards, with only the following information shown:

  • assignee
  • priority
  • status
  • title
  • excerpt
  • due date
  • watch/unwatch icon

The card body can be clicked to go to the Task Detail page. This link is not stretched to the whole card, because the card header contains a link to the assigned user's profile, and the bottom part of the card contains the watch/unwatch icon.

The conditional color scheme works just like on the Task Detail page.

Task List page

Kanban board

The main task view implemented in this app is a task Kanban board, where tasks are automatically sorted based on their status. Inspired by GitHub Projects and Trello, I implemented horizontal scrolling for this view for small screens.

This page has the information and layout that a user is likely to want to see, which is why it is the starting page for logged-in users.

Since the size of the task cards in this view is the smallest of all, the content of the task cards shown in this view is the most minimal/compact. This is governed by the conditional rendering logic in Task.js.

The conditional color scheme, watch/unwatch and stretched link functionalities work just like on the Task List page.

Task Kanban board

Filtering with tabs

Filtering is implemented with a tabbed structure on the Task list, Kanban and Profile Detail pages.

On the Task list and Kanban, 4 columns are shown:

  • tasks assigned to the logged-in user
  • tasks watched by the logged-in user
  • tasks created (owned) by the logged-in user
  • all tasks

On the Profile page, the list shown depends on the user whose Profile page is viewed:

  • tasks assigned to the viewed user
  • tasks watched by the viewed user
  • tasks created (owned) by the viewed user

Each filtered column also shows how many tasks are in each one. Whenever a task is changed in one column (re-assigned, watched/unwatched or deleted), the change is reflected in all columns without having to reload the page.

Searching tasks

A search bar appears on the Task list, Kanban and Profile Detail pages. It returns tasks specific to the viewed tab as the user types, without having to press a button.

Fields searched are:

  • title
  • excerpt
  • description
  • assignee
  • owner

Task search

Watch/unwatch function

Users can choose if they want to watch tasks regardless of whether they are assigned to them or the tasks were created by them.

The watch button is an eye icon, and a toolip instruction is show when hovering over it. This changes dynamically depending on whether the logged-in user is already watching the task or not.

Watch/unwatch icon

The count of users watching a task is shown next to the eye icon. This is also updated without having to reload the page.

This functionality is available everywhere where a task card is shown:

Teammates component

This appears on large viewports on the following pages:

It shows the list of teammates in descending order of profile creation, with infinite scroll.

Users' names are shown conditionally: the first and/or last name is shows if it is available, otherwise, the username is displayed.

Teammates sidebar

Clicking on a profile avatar or name leads to the relevant profile detail page.

Clicking on the heading Teammates leads to the profile list page.

On small screen sizes, the Navbar includes an extra link to the profile list page.

Task Create Form

This is used for creating new tasks, and is available to all Logged-in Users.

Since the title field is compulsory on all tasks, the create button is disabled on the form when the page loads, with an information message under it. As soon as the title field gets some content, the button is enabled and the message disappears.

This form contains the following types of fields:

  • 3 text fields (title, excerpt, description)
  • a date field
  • an image upload field
  • two dropdown selectors with fixed options (status & priority)
  • and the assignee dropdown where options are dynamically fetched and conditionally rendered.

The form is responsive, and the buttons are placed at the most convenient location on each screen size.

Task Create Form

Task Edit Form

The Task Edit Form has the same structure as the Task Create Form, which help user navigation and also makes use of the same component in the code.

The title of the page and the submit button text change conditionally depending on which form is rendered.

The Task Edit Form fetches the existing data from the API and pre-fills the fields with these.

Only the owner (the user who created the task) can edit or delete it. The reasoning behind this is that they know the requirements, so they can judge whether a task can be completed or not.

Task Edit Form

In a future version, I plan to add some partial edit permissions to task assignees as well (#98).

Assignee dropdown

This is part of the Task Create Form and the Task Edit Form.

It fetches the list of all profiles from the API, and displays them conditionally as options in the dropdown: it displays the first and/or last name of the user if these are filled in. Otherwise, it displays the username.

Assignee dropdown selector

Task Deletion

Since tasks are the most important objects in this app, I have enhanced the deletion functionality of the Moments app with an extra confirmation step. When clicking the trashcan icon on the Task Dropdown menu, a modal pops up confirming whether the user wants to delete the task. This helps avoid accidental errors.

Task Deletion modal

Profile features

Profile list

This is the full-page version of the Teammates list under the /team URL. The sidebar version only shows the avatar & conditionally rendered name of the user, whereas the full-page profile list also shows the pronouns and role if these are filled in.

Profile List

Profile Detail page

This page shows a user's profile information and tasks related to them (assigned to, watched by or created by the viewed user).

For logged-in users, this page shows all profile fields including empty ones. In addition, the conditionally rendered user name has the suffix "(me)" to indicate the user is viewing their own profile.

Own Profile Detail page

For all other users, only filled-in fields and the conditionally rendered name is shown.

Profile Detail page

For users viewing their own Profile Detail page, a pencil icon is shown. This opens the Profile/Username/Password edit dropown menu.

Profile Edit dropdown

Profile Edit Form

This form lets users edit their own profile data. All fields are optional, so the save button is never disabled.

Profile Edit Form

Username Change Form

The Username Change Form is based on the Moments project, validated, with added CRUD messages confirming the change of username, or cancelling the change.

Username Change Form

Password Change Form

The Password Change Form is based on the Moments project, validated, with added CRUD messages confirming the change of password, or cancelling the change.

Password Change Form

Future features

Since development time for this version of the project was only a bit more than 3 weeks, and this was my first project using React & DRF, several desired features could not be implemented in this short time frame:

  • drag & drop tasks on Kanban board
  • delete task/profile image in UI
  • ask for current password before changing login credentials
  • tag other users in comments
  • send notifications when due date is close or task status changes
  • the other features relegated to version 2

Code features

Customization

Although this app started out based on the Moments project, it features extensive code customizationin the form of custom hooks, refactoring, component reuse, widely used conditional logic & rendering, and additional libraries.

Regular testing

The code was continually tested and validated with ESLint throughout development. At the end of the development process, a final, comprehensive round of testing and validating was completed. The results are detailed in TESTING.md.

Adequate commenting

Apart from making sure that the app functions as intended, I have also taken special care to make sure the code is well organized and appropriately commented. Since I am just becoming familiar with React (and dealing with executive functioning issues), I have erred on the side of "more is more" for code comments and docstrings for methods that were new to me.

DRY

I have also done my best to adhere to the principle of Don't Repeat Yourself (DRY):

  • I refactored the TaskCreateForm and TaskEditForm to use the same component, TaskForm, which fulfills both functions depending on the taskEdit prop.
  • the TaskList component is used in both TaskTabs (rendering both the List and Kanban pages) and ProfileDetail
  • the Task component is used in TaskList (on both the List and Kanban pages) and TaskDetail
  • the ProfileList component is used in TaskList (conditionally depending on the taskList prop), TaskDetail and ProfileDetail, as well as on its own under /team
  • smaller components, such as Avatar, Asset or NotFound are used throughout the app.

The full component tree can be viewed in the section Components.

I also completed a number of Issues just for refactoring code.

Security

npm audit fix was run after every time a new package was installed. It is beyond the scope of the correct project to fix all dependency warnings, as these are typically handled by more senior developers or dedicated security engineers.

There are no secret keys or URIs stored in this app (as opposed to the API).

All passwords are stored in a password manager, and not written down in plain text electronically or on physical paper.

Unfortunately, the infrastructure for project submission at Code Institute requires the admin credentials to be submitted in plain text.

GitHub branches

Since this is a one-person project, it would have been overly complicated to make use of feature branches for all user stories. Therefore, I conducted most development on the main branch.

However, for features or bug fixes that I judged to be especially risky for breaking existing functionality, I created separate featrue branches.

Normally, these would be deleted after they are merged or decided not to be merged. Since this project is submitted for assessment, feature branches are kept as a reference.

Testing

See the document TESTING.md for details.

Technologies used

Languages used

  • JSX – write HTML with JavaScript
  • JavaScript – programming language for web development
  • HTML – markup language for structuring and presenting content
  • CSS – web style sheet language

Frameworks & Libraries used

Other dependencies used

Testing libraries

  • @testing-library/react – React DOM testing utilities
  • @testing-library/jest-dom: – test the state of the DOM
  • @testing-library/user-event: – simulate user events

Tools used

Deployment

The following instructions describe the deployment process with the tools used for this project. Of course, you can choose other tools/providers for the individual functions described below, e. g., a different Postgres database instead of Neon, or a different development environment instead of GitPod. Naturally, detailed instructions are only provided for the tools used in this project.

Prerequisites

[! WARNING] The setup has been known to be prone to version conflicts, so use the exact versions specified in requirements.txt

Fork the repository

You can fork the repository by following these steps:

  1. Log in to GitHub (if you don't have a GitHub account yet, you can create one for free).
  2. Navigate to the project website https://github.com/blahosyl/task-manager-api.
  3. Click on Fork in the upper right part of the screen.
  4. On the next page you have the possibility to change the repository name. To do this, simply write your desired name in the text field in the center part of the screen. You can also leave the name as it is.
  5. Click Fork in the bottom right part of the screen.

Tip

If you do rename the repository, make sure to keep the GitHub naming conventions in mind.

Deploy in the development environment

  1. Open the repository in a new workspace in GitPod.
  2. Create a new React app by typing the following into the terminal:
    npx create-react-app . --use-npm
  3. Install all required dependencies from the package.json file by typing npm install into the terminal (without any arguments).
  4. Because of a conflict between the GitHub template provided by Code Institute and Node, you might have to downgrade your node and npm versions. Run nvm install 16 && nvm use 16 in the terminal to use node v16.20.2 (npm v8.19.4).
  5. To connect the app to the deployed API, go to /src/api/axiosDefaults.js, and add your deployed API's URL to axios.defaults.baseURL, replacing the current URL.
  6. Start the app in the development environment by typing npm start into the terminal.

Deploy to production

Pre-deployment steps

Make sure to complete the following pre-deployment steps in your development environment, especially if you made changes to the project:

  1. Check that a Procfile is present in the repository at the root level. It should have the content web: serve -s build.
  2. Commit any changes you made to the code.
  3. Push your changes to GitHub.

Steps on Heroku

  1. Log in to your Heroku account (or create a new one if you have not done so yet).
  2. Create a new Heroku app by selecting your region and app name.
  3. Under Deploy > Deployment method in Heroku, select GitHub and connect Heroku to your GitHub account.
    • Type in your repository name, then click Search.
    • When your repository appears, click Connect next to it.
  4. Under Deploy > Manual deploy in Heroku, select Deploy branch to deploy manually.
    • Once the process is finished, the following message will appear:
      Your app was successfully deployed
    • Click View under the message, and a new tab will appear with your deployed app.
  5. (optional) Under Deploy > Automatic deploy in Heroku, select Enable Automatic Deploys if you want your app to be rebuilt each time you push to the main branch of your GitHub repository (but make sure your settings.py file always has DEBUG=False when you do).

Credits

Code credits

This project was developed on the basis of the Moments walkthrough project by Code Institute.

Many features and the overall feel was inspired by Trello.

I have also consulted the project Tick It by Jamie King and implemented the Task deletion confirmation modal based on it.

Spencer Barriball kindly provided a suggestion to get rid of the non-breaking warning in the Profile Edit Form, which is also present in the Moments walkthrough project by Code Institute.

Tutor John Rearden was kind enough to keep working on making infinite scroll work for Profiles, which we could not solve in the tutoring session, and came up with a solution: using a custom API call instead of using fetchMoreData().

Related advice

Following a suggestion by Kelly Hutchison, I added Frontend validation by adding the required prop to the form fields in the SignInForm (Issue). I then extended this to required fields in all forms in the project #96.

Study/lookup sources

Text

All text was written by me.

Media

Image credits

Readmes

Acknowledgements

I would like to express my gratitude to my mentor, Marcel Mulders for his incredibly useful and understanding support throughout the project. Issues raised by him or discussed with him can be found here (see the individual ticket descriptions for the details of his contribution).

I am also grateful to the Code Institute tutoring team, in particular, to John, Oisin, Rebecca, Roman, Roo and Thomas for their help. The details of their contributions can be found here.

I would also like to thank Peter Litauszki for photo and video editing help.

About

On Fire 🔥 - the cheerful productivity app | PP5 Code Institute

pp5-task-manager-frontend-eebb66e2c99d.herokuapp.com/

Topics

react productivity design jsx reactjs colors task-manager productivity-tools productivity-app react-hooks

Resources

Readme
Activity

Stars

0 stars

Watchers

1 watching

Forks

1 fork
Report repository

Releases

No releases published

Packages

No packages published

Languages