I'm blogging along with the laracasts series Pest Driven Laravel created by Christoph Rumpel as I work on a project I hope to open source. I'm just documenting how I'm working, the resources I'm using, the problems I run into and some cool things I'm reminded of as I develop.
The project I'm making is very similar to a to-do app in many ways, which is great because I've made 5 or 6 of them in other languages already. This is my first CRUD app in Laravel, so I'm trying to balance learning a new framework and philosophy with trying to keep my MVP simple and usable. It's a real struggle so far.
In episode 1, Christoph discusses the benefits of test driven development including a focused method of iterative development (I'm paraphrasing) and the practice of refactoring integrated into the development process. These both sound fantastic-- how many of us have (the benefits of) real tests? TDD is a topic of contention in whichever language you choose, and generally so far I've taken the advice: if you don't have users, you don't need tests. I've eschewed cleaner coding practices for a more complicated, bloated, and completed program. Then, I've proceeded to use those programs myself and look at my code months later while considering adding a new feature and wonder: who even WROTE this? But today is different. Today, I have users.
I'm going to start describing this project by including some behaviors I want users to be able to experience when they use the app. This is also an exercise in the first video of the course. I will write a clearer summary soon, and part of describing it requires separating types of behaviors and the authentication roles required to interact with each type of behavior. For example, the to-do behavior of the application has different 'user stories' for events (tasks that are associated with an appointment date and time) than for a more general task class. So let's start by just talking about the event-type tasks-- not because this is the way I'd ideally like to develop, but because appointments are more urgent to the users of the app than tasks are(1).
Volunteers
The future 'about' section of the app (currently a draft) describes volunteers of the application as:
[users] who have already established functional processes through experience in their domains and are willing to provide insight to contributing developers and to administrators about how technical solutions may improve their ability to help others in their community
Volunteers should be the most numerous user group type, the type of user that can see the fewest features of the app. But the app is mostly for them. So I'm thinking about designing the interface mostly around what the volunteers will be able to see. Unlike a typical to-do app, volunteers don't make the tasks; the user dashboard will be kind of like a job board in that way. But they should be able to sign up for tasks, interact with tasks they've signed up for, and get more information about those tasks really easily. Even if that usability comes at the expense of extra bloat the Administrators and Organizers-- because the goal is to get feedback to improve functionality, and I don't expect much useful feedback from users who are bogged down in complicated flows and don't have a solid understanding of how to do what they need to do. But I digress.
For now I'm going to focus on testing that volunteers:
- can view a list of tasks
- can view sorted lists of tasks (tasks assigned to them, budget, etc)
- can sign up for a task
- can remove themselves from a task
- can add additional info for a task
- can mark a task as completed
Organizers
The 'about' section of the app refers to organizers generally:
Administrators and employees of nonprofit organizations who (a) can benefit from project organization and task automation, especially in cases where the reduction of time allocation for administrative tasks may be allocated towards the scope/scale of their organization's output and (b) are willing to advocate within their organization for more effective and compassionate processes
Employees are actually a different auth group from organizers, but that about isn't written as a way to think about code. So I'm taking the time to consider more clearly. Administrators have a more global idea of what needs to be done in the organization. But a less granular goal for behavior doesn't translate into a more obvious design. Because they know what needs to be assigned and has to get done and are responsible for creating tasks and maintaining them to completion, and because volunteers need to have a very simple experience, designing for administrators means considering complexity and bloat. These users aren't necessarily more available (to use and learn the app) or more technical than the volunteers-- I think these are assumptions that other organizations can make more safely.
Organizers:
- can view a list of tasks
- can create tasks
- can edit all task fields
- can view sorted lists of tasks (tasks assigned to them, budget, etc); can sign up for a task; can remove themselves from a task (this is the same behavior volunteers should have)
- can assign a volunteer to a task
- can unassign a volunteer from a task
- can cancel a task (this shouldn't delete the task)
- can delete a task created in error
- can add additional info for a task (optionally in response to requests for additional information-- let's handle this later)
- can mark a task as completed and confirm a task has been completed; a confirmation from this role means something different for the state of the task (and the checklist) than a volunteer's confirmation.
Administrators
For now, administrator roles mostly have additional functionality with behaviors that aren't directly related to events. Paid employees who choose to use the app fall into this category, as do some organizers who need escalated permissions.
One of these behaviors is going to be adding Organizers and Volunteers. Most of this behavior is going to be handled through the Teams feature of Jetstream (yay!) but there's some domain-specific logic that I'm also going to ignore for right now. Another behavior will be handling contracts, groups of tasks not unlike a Jira epic. Contracts and tasks will both have similar completion states, and this is something that also has to be on the back burner while designing these tests.
So that's the first post about reteer. And my first DEV post. I'm hoping to write my first tests today and get some additional functionality by the end of the day. Anything worth doing is worth doing badly-- and I think this is a project worth doing. If you do too, say hey.
Oh, and the project is:
Reteer is an open source application being designed to reduce organizational overhead within volunteer organizations. It is designed for groups with extremely low budgets who rely on donations and volunteer work to do good.
(1). Actually, there's going to be at least two more role types in the application than we're going to discuss now. I have a brainstorming User Actions document that has more behaviors and groups than this post contains, and I'm trying to be okay with letting them sit for a while.
Top comments (0)