Manna was a project done in conjunction with Professor Heimann from CMU. This project was done as an independent study with the guidance of my professor, and it was mostly a solo project on my end. From start to finish, I was responsible for the development of the web application Prof H identified a problem within his Church, ACAC Pittsburgh, and tasked me to do create an application that would simplify the process of countless email threads and attachments to a system where Deacons of the church could open cases to provide aid for someone and attach relevant documents so that other Deacons could vote and discuss.
Deacons provide monetary aid to members in the church through writing an application and having other deacons discuss and vote on whether or not the aid should be granted. This process happened all over email or text, thus causing a rift in organization as discussions and votes were clouded by countless emails all under one thread. Furthermore, requesting documents or follow ups to a topic made it impossible to track for users. Each case needed Deacon's to vote on, and ensuring that every deacon was not only informed but also involved with the discussion was crucial. With numerous cases being presented weekly, sometimes cases fell out of the spotlight as more cases came in, so keeping deacons on top of what cases needed attention was also a huge pain point.
A web application was needed so that deacons could manage cases all in one place. This web application needed to solve for two things: providing a space for discussion and also organize documents related to cases as well as individuals. This web application needed to organize cases so that deacons can look up current or past cases. Furthermore, this application needed to cater towards an older audience, so it had to be easy to use as well as simple.
The project requirements were quite straightforward: I needed to design and implement a system that would be mobile-friendly and that could help deacons manage cases. The application needed to be able to attach files to cases, vote on cases, comment and disucss on cases, and index or search cases.
Areas I focused on:
The first few days of the project were to create the database needed for this application, so I made an ERD and created a developmental database on SQL lite for the purposes of this project. Key tables were that there had to be users, which were the deacons, and each deacon could create cases online. Each case would have document(s) that could be attached and each case would have a vote count.
From there, I started designing the UI for the application. Overall, it was quite simple, and I based my designs on something a little more minimal from something like UDFORE. I primarily started my designs from a mobile screen, as the focus was to make sure the mobile experience was worthwhile. When the mobile screens were done, I simply just “enlarged” the sections to fit a webpage. I tried to keep the designs simple since I wanted to just make sure that it was functional yet it could easily resize and be responsive towards all screens. I also made an invision app with intentions of user testing with deacons, but since Prof H was a deacon and due to time constraints, he gave the go ahead to proceed.
The home page was an important aspect of application because it served as a way to remind deacons as to what cases needed their attention. A general use case would be the following:
From the home page, a user could go through the nav bar and submit an application or look up all cases, recent cases, or cases by client. The purpose of the home page was to show the important cases that needed immediate attention, but also provide a way so that a user could do other actions if needed.
One thing I struggled with when designing was the Nav bar itself. I wanted the logo to be centered with buttons under it on mobile, but on computer screens, I wanted them to be separate so that it would take up space and act as a long nav bar. For the sake of time, I did not want to deal with collapsing the nav bar buttons into a hamburger bar, and since there were only a few actions, it felt okay to keep the buttons the same size for mobile and for web.
A big ask was that whenever a case was created, there needed to be a comments or discussion section as well as a voting portion. The basis for this application was so that deacons could not only create cases for people, but also vote and discuss about them so that they did not have to meet up in person. In order to further cut down implementation time, I leveraged Disqus’ platform, as they had a package built for Ruby on Rails. With that, I was able to attach a thread to each case, but not have to worry about managing and adding more to the database design, as well as creating a whole content system that involves with editing, replying to, etc.
When it came down to the voting, I had to focus on two parts: making sure that each user can only vote once but can change their vote if needed, and disable voting for closed cases. The voting itself was quite easy as it was just incrementing an integer tied to a case for both Yes and No votes. I built it so that the user would only have one vote, and if they change their vote, it would remove the previous vote and add the new vote to the respective category. If i were to do this again, I think I would at least make it more obvious to the user that this is happening. Voting was a small modal that popped up to allow the user to just click either yes or no, and the voting section would update itself afterwards. Another aspect that I would change is that the voting section on each case page was just a number as “3 | 2.” It is not really obvious to all that the green means yes and the red means no, and furthermore the only way for a user to vote is to click on the section itself, which may not be that intuitive. Granted, the system would be used for roughly 20 people, and they would all be onboarded, but this would be a case where I tried to make things a little too minimal, which may add friction to a user.
Creating a case was also the main focus of this project, as it needed to be easy to fill out. I wanted to streamline this process so that time could be spent discussing cases more so drafting or creating a case. Thus, the case creation page was rather reduced to the bare minimum: subject, client, deacon, description, and files attached. One quality of life improvement was that the deacon section would be autofilled based on account, and it would exist as a dropdown menu: there were only about 10-15 deacons, thus the list was manageable. The drop down was necessary so that deacons could also help create cases for other deacons, which was common due to time constraints. Clients, on the other hand, were harder to manage, and due to the interest of time, they were kept as just a normal text box. We wanted to minimize collisions with clients with the same name, so we kept it up to the deacon to provide a proper name that could identify a client properly.
Another challenging aspect of this project was actually attaching a file or multiple files to each case. First off, I never really had any experience with attaching files and making sure they get sent to a database: at most, it was just attaching a file to an input tag and calling it a day. With this project, I had to make sure there was a way to attach multiple files, and provide a way to show what was attached and a way to remove it if needed. As anyone would say, styling input tags is quite tricky because usually there’s a “choose button” and a section that shows a file type. However, I had to have a button that triggered the file selector if there were no files attached, and for each file that was attached, a user could either delete it by clicking “X” or change it by clicking on the file name itself. When it came to actually viewing a case, a list of underlined document names were shown, so when a user clicked on the name, it would open a new tab and show the document.