Brainstorming Guide

As stated before, the purpose of this guide is to give you an idea of how you would create a new app for the first time. It preferred that the author of a new app should have a very good understanding of the FW App system and how they work, and thus, a seasoned developer is usually the best one to embark on creating a new app. Make sure you are very familiar with both our Main Docs and the Conceptual Introduction from our initial training. For aid in this process, we will be using the brainstorming process from the app Message Center, just so you can concretely see how the process works. One of the most critical phases of developing a new app is actually the brainstorming process. Because a person who does not know where they are going will never get there. While to some, this process may seem tedious and unnecessary since we are "developers" and not "designers," after having developed many apps from scratch myself, this process is indispensable to having a smooth developing process once you are actually to the point of developing. There are a few steps in this phase.

Talk about the Need

Our FW Apps are never something that are made simply for practice in programming, so they are imminently practical. Odds are, if you are creating an app from scratch, someone on the Informatics Admin team has been wanting an app to do this kind of functionality for a while. So, then, you need to have a meeting with the admin, see what it is that you are supposed to be developing. What is the purpose of the app? What are the diversity of its functions? Is it going to be multipurpose? Is there something that is currently functioning in this way, and if so, how does it work? If they are wanting to replace it, what specifically is deficient about the current system? The more questions you ask here will set you up for success in developing the plan of what you are going to create.

In our example of Message Center, this initial meeting went well. We were using a legacy system similar to Message Center, but we wanted to migrate it to the new FW system rather than keep it on Popsicle (the old system which was fully migrated to FW by 2018). The request was simple: it needed to be an app that could serve a dual purpose: it needed to be able to send email messages with a template that was pre-created by the apps (or with a blank template), and also have an ability to have a "channel" which was a kind of chat room in which people could post messages for others to read and respond to those chats.

It is also important to determine what is essential to your app. What consists of the "core" of the app to be released first, and what can be added with future development. It was decided that later iterations of Message would add things like the History pages, but that the core of the app would be just the emails and the channel feature.

Plan the Database

Now that you have a conceptual concept of what the app will consist of, you need to plan what your Database will look like. Make sure to refresh yourself on the current Database Naming Conventions before you start. Make sure to also include the GC department for every table unless you have a specific design related reason not to (if you need global tables). You need to think of all the tables and how they relate to one another, and each row on the table. You can do this on paper, or you can use a database planning app, similar to the one you used in a Database class. Make sure that you include database tables for future developments of the app as well, so that you can minimize the database releases (for example if you know of a feature that is not in the "core" of the app that will take a database migration, you might as well add the database for it now). For Message Center, the developer used Visual Paradigm, which at the is a free database planner, but now it actually costs money. You can make one using another free version or you can even draw it on a piece of paper, it depends on what suits your fancy. The important thing is that you know: 1) all the tables you will need, 2) all the rows on said tables, and 3) how each table relates to the others.

As an example, this is the database design that was used by the developer of Message Center. Of course, this is not unchangeable, and in fact, the shortcode for the app was changed before it went to final production (from msgCen to msgc), but this will give you an idea of what is required to plan a database.

Do the BREAD Analysis

This BREAD Analysis can be done separately from or kind of along with your Database plan in the previous step. This is essentially designing your backend routes & controllers, keeping in mind what permission levels there will need to be and what each controller needs to have. So, what the BREAD analysis means is going through and figuring out what controllers you will need (generally this will map almost 1-1 with your models, but will discuss that further on in the email), and then determining which actions on those controllers you will need to implement. As part of this analysis, you will need to determine how many roles your app should start with (at least admin and base), and what parts of the app each user role will have access to. After you have your database and all your roles, you need to determine which of the database tables will correspond with a specific Controller on the server side. This should be fairly quick, and could just be a small document describing which role has access to which tables. Most of the work in BREAD analysis is done for you in your Database plan you have made.

For Message Center, there was not actually an official BREAD analysis done and typed up, but the developer could have told the admin which tables would have which permissions. A few examples would be (I won't do it for each table, but you will get the idea):

• Email Template: This is only able to be Added, Edited or Deleted by Admin (as long as they also have permissions in access control), and it is able to be Browsed or Read by base users (provided they have permissions in access control)
• Email Message: The whole BREAD is able to be done by all roles.
• etc.

This does not have to be super complicated, and can merely be able to be verbally suggested as you are going through your database design with the admin.

Plan the Visual of the Client Side

Again, this is something which can be done differently based on your personality, but you need to have a general concept of how you will make the app to look when it is doing certain things. It is not important at this point if you know exactly how you will code certain features or not, or if this general plan will change as you are developing. For each page or modal you will make, you need to have some sort of a mockup for what it will look like. This can be a rough sketch on a piece of paper, or a more detailed graphic design on the computer. At this phase, you are NOT coding anything, you are merely making sure you know what the page will look like, and getting it on paper so that the dev admin team can see.

For the sake of simplicity, I will only show a couple of the mockups for Message Center to give you an idea of what kinds of things to draw. In the case of Message Center, the developer created these in Paint just to get a general idea of what he was planning to do. Yours do not need to be quite this detailed, unless you want them to be, but it needs to be enough so that the admin know what they are looking at and can helpfully visualize it. Keep in mind, at least a brief sketch of EACH modal and EACH page should be shown here.

Here are a few of the concepts related to the Email Functionality:

Here are a few of the concepts related to the Channel functionality:

Since you have used Message Center, you can probably identify areas in which the final product differed from the original concept, but the general idea was there from the beginning.

Final Planning Meeting

Once you have done all this brainstorming, which may feel tedious, you are able to present your work to the Informatics Admin. This will enable you to tell them exactly how the app will function, and allow them to give you feedback before you have actually coded anything. The idea is that drawing a picture of how you think in your head something should work will be much easier than actually figuring out how to make it work. This will allow you to make any potential course corrections where you had misunderstandings in the initial meeting before you actually begin coding. Additionally, if you do not have a clear enough idea to draw a picture of what you want it to look like, then you certainly won't be able to code it properly anyway. Most of the time, the admin are as excited as you are to begin the process and actually see what it will look like as a finished product. The more detailed your drawings, the more the admin will be able to visualize what you are thinking with you. After you have actually finished with this meeting, and have an idea of the various tweaks that the admin want you to make, you are actually able to move on to generate the app and begin developing it.