This week is the first time in the semester when you’ve actually had to do real design; in other words, given some high level requirements, create an approach to addressing the problem through technology.
As hard as it has been to learn how to use Javascript, GitHub, or IntelliJ, or ESLint, or Meteor, all of that pales in comparison with how hard it is to do design effectively!
That said, if you struggle with Javascript or GitHub or IntelliJ or ESLint or Meteor, then that saps valuable time and energy away from the struggle with the design problem. The goal of the first half of the semester was to get you to as comfortable as possible with a palette of technology, so you can focus on design (and teamwork and project management) during the second half of the semester.
When developing a web app, it is typically useful to distinguish between the landing page and the home page.
The landing page is the page users first come to when they retrieve the top-level URL. It is a public page that does not require authentication to access. The landing page should provide an overview of your application with screen shots of interior pages. Visitors should be able to gain enough information about your application to know whether they will want to login or not.
The home page is the page a user goes to after being authenticated. The home page typically provides information specific to the logged in user.
From the earliest stage of mockup development, you should be talking to users. When I mean users, I mean “people who might want to use your app but are not in ICS 314”. Preferably people who are not even in computer science. You will be amazed how quickly you can gain inspiration from “real people” about desirable features and things to avoid doing.
Digits used a table for simplicity’s sake, but almost all of your apps will improve if you use Semantic UI Cards. Start with cards unless you have a really good reason not to.
If you forget to include .gitignore, then your repo will include the IntelliJ IDEA files (.iml and .idea/). That’s bad, because those files are not meant to be shared between users so when you work in a team, your IntelliJ settings will get messed up.
Worse, if you don’t have .gitignore, you are likely to commit the node_modules directory. That means you are uploading and downloading about 3,000 files more than you have to, and since some of those files can be OS-specific, your app won’t work across all platforms.
For your app to be effective, think about ways it can “push” useful information to the user. No one wants to have to visit an app every single day to “pull” information out of it, or to “see if there’s something new”.
View text fields and text areas as “black boxes”: there’s generally nothing useful your app can do with that information. On the other hand, checkboxes, radio buttons, and menu selections have “semantics”: you can more easily take useful actions based upon the values.
For example, consider a “campus jam” app. If you have a text field called “what instruments do you play?”, it’s hard for the app to make use of that. Alternatively, consider an app with one set of checkboxes along with the question, “What instruments do you play?” and another set of checkboxes with the question, “What instruments do you want to play along with?”. Now the app can automatically match up musicians based on what they play and what they want to play with.