Get a quick review of the user flow of the app to see where you are heading.
- [Voiceover] As we get started working on the stand-alone Task Book app, I think a review of the user flow is in order. Now that you have a firm understanding of the content model, data structures, and how tasks work on the back end of WordPress, the user flow of the stand-alone app will make a lot more sense, and most of what you see will map directly to what we've been working with up until this point. When a user first visits the Task Book app, they land on a Login page. This Login page, in turn, redirects them to WordPress for authentication, so there you'd log in just like you would any other WordPress site before you get redirected back to Task Book app, and here you land on the task list page.
The "Task list" page, or view, is the list of the 10 most recent tasks indexed by the current user. You remember in the previous chapter, we set up each task as a private task, so a user who logs in will only see their own tasks, and thanks to how we configured capabilities and how we configured the REST API, the user will in fact see all their tasks as an index. If the user has no tasks, or if they want to log a new task, they will click on "New task". This takes them to the "New task" view, and from here they fill out the same information that you would fill out on the WordPress back end.
Task title, the task description, then the prediction field, and the pre-stress level field. When the user clicks on "Create task", they are redirected back to the "Task list", and now the new task will appear at the top of the list, because it's the most recent task. The new task will be marked "In Progress", because so far, we've only filled out the prediction and pre-stress level fields, not the outcome field. To update the task, the user can now click on the task card here. They'll be directed to the "In progress task" view, where they can see the task title, the description, the prediction, and the pre-stress levels, and then they have the ability to fill out the actual outcome field and select the post-stress level field.
If this is filled out and they click "Update task", they are taken to the "Completed task" view, which is just a breakdown of the entire task, and now none of the content is editable anymore. And when they go back to the "Task list", they'll now see the task marked as "Completed" instead, so this is that status field we were talking about previously. On top of all this, we also have the "Review" view. In this view, we take the pre- and post-stress levels from each of the tasks and display them on a graph, so you can see the difference between pre- and post-stress levels over time.
Make sense? Alright, let's go.
- Planning the application
- Extending WordPress with a plugin
- Setting up the standalone application
- Configuring OAuth 2 in WordPress
- Building the task list view
- Building the new task view
- Creating a new task via the REST API
- Displaying conditional content
- Visualizing data using Graph.js