HW4: Project functionality & milestones

CS 359B Spring 2018

Deadlines:  

Wireframes:  Wednesday - April 25, 2018 11:00 am

Milestones:   Friday - April 27, 2018, 11am

FYI, class plan for the next 3 weeks

Your goal is to have the first working version of your project ready for the Midterm presentation. Is this possible? Yes, see FAQ.

But first, congratulations on the excellent work in the first 3 weeks of classes. By now, everyone should have a clear understanding of (i) what a dapp is, (ii) what benefits the blockchain can bring to apps, (iii) how to interact with dapps using MetaMask, (iv) main limitations of dapps, and (iv) how to build a simple hello-world wallet dapp. If you feel you don’t grasp any of the above concepts, come talk to us in office hours or slack.

Below are the high-level goals and deliverables for the next 3 weeks.

Every Monday at 11 am there will be a short HW due, as a report of the previous week. (We will have a character limit so that you don’t waste too much time on write-ups). Each HW will include a snapshot of your code (github takes care of that), screenshots of the current state of your dapp, completed milestones, missed milestones, and an updated list of upcoming milestones. 

Below are the deliverable for HW4.

1. Contemplate the functionality of your dapp

Due: Wednesday - April 25, 11am

Deliverables: Thumbs-ups to useful comments you received by classmates and mentors

Go back to step 12 of dapps.stanford.edu/proposals/review and read the feedback you received. You will notice that by now you have also received feedback from class’ mentors. Read the feedback and try to incorporate it to improve your idea. It is OK if your idea changes significantly based on feedback. That is the whole point of receiving feedback.

Your goal in this step is to come up with the functionality and flow of your dapp.

Deliverable

Give a thumbs up to good, thoughtful pieces of feedback you received from mentors and peers.

We will take into consideration your thumbs-ups to mentor feedback when pairing you with mentors. So we will try to match you with mentors who gave you feedback you appreciated.

2. Present dapp functionality through wireframes

Due: Wednesday - April 25, 11am

Deliverables: (i) A Google slides presentation,

(ii) A class presentation on Wednesday.

Put together Google slides with wireframes of the interactions and workflow of your proposed dapp. These will be used to help others understand what your dapp is going to be and how it is going to be used. We will ask you to submit them to dapps.stanford.edu, in a similar way you submitted your presentations to HW2.

Class presentation

During your presentation show visually an entire workflow of the interaction of a user with your app. For example, imagine Alice is using your app. Who is Alice in this case? (e.g. a person who wants to play a game, an employer who needs to validate if a job applicant is indeed a Stanford graduate).  What does Alice see on her screen first?  (Landing page) Then, where does she click next, and why? (What’s her goal) What happens after that? (Show the next screen she sees) What happens next? And so on and so forth, until you explain the whole app workflow.

This time you will be presenting from OUR computer at the front so that you can point and click to your slides/wireframes yourself. We will ask you to walk to the front of the room, when your turn comes.

Wireframe guidelines

Your wireframes do not need to look nice, but they need to have enough information for the audience to follow along. You can even take pictures of your whiteboard or paper sketches. You can also use simple boxes directly on Google slides. You can use wireframing tools like Balsamiq and Mockflow.

See below for some good examples of wireframes.

Also consider including a user experience workflow diagram to be read by us offline, if it improves clarity. I.e., a diagram that shows how the user transitions from page to page in your app. This is optional. So do it only if the flow is not clear from your wireframes.

Submission of deliverables

Similar to HW2:

1. Submit your project title on step #12 from the task list on dapps.stanford.edu. Only one person from each team needs to submit.
2. Put your wireframes in a slide deck to present in class.

1. Use a widescreen deck format like this
2. Place your presentation in this google drive folder, with the prefix “HW4: ”
3. Click “File > Publish to the web > Publish”, copy the resulting link, and paste back in step 12 of dapps.stanford.edu
4. Test that your slide plays well by visiting step 13. Use this step to practice your slides and make sure you stay on time. You will have 2.5 mins to present.

3. Write up of dapp architecture and milestones

Due: Friday - April 27, 11am

Deliverables: (i) A write up of project architecture and milestones until Midterm.

This is what we called “mini white paper” in HW2, which we decided to reduce in scope and pushed its deadline until after you have built a working CardinalToken dapp, experimented with MetaMask, and finalized your idea and its functionality based on the feedback you received.

Take into consideration feedback received in class on your wireframes. Give thumbs up to good feedback. Improve and finalize your idea. Decide your action plan and milestones for midterm.

Deliverables

First, give kudos (thumbs-up) to thoughtful, useful feedback you received on your presentations.

Then, submit the following write up. 2 pages max. It is important for you to think through and have solid answers to these questions. But, we want you to spend more time learning how to code dapps and less time on write-ups.

1. Functionality - It is OK if idea changed based on feedback

1. Team members, including any external team members or collaborations
2. Project title and Twitter-length description. (~280 characters)
3. Who is the target user? (1 sentence)
4. What problem/pain point is your project solving? (1 sentence)
5. Bullet point list of features your dapp will have. Explain only non-obvious features

2. Technical Architecture
   Describe the technical architecture of your dapp. This depends on your dapp, so we will not give you specific questions to answer. Example questions are below:

1. Technical challenges and solutions
2. What data is stored on the blockchain, and what functionality lies on the blockchain?
3. What goes into the web app? Will you use a traditional database?
4. How do you communicate information between the two parts?
5. What else do you need? external services, oracles, etc. Do they exist?
6. Feasibility analysis (would this service make sense, e.g., in terms of storage and gas costs)

3. Implementation Plan until Midterm (fill in the table below)

1. Provide reasonable milestones, relevant to your project for the next 2.5 weeks. Try to distribute work equally. Remember the goal is to have a v1 of your dapp usable through MetaMask by Midterm. (see FAQ)  
2. Provide division of work. Allocation of responsibilities among the team members. Which team member does what. It is ok if this changes. We will ask you for a brief report afterwards.

You can answer questions (3.a) and (3.b) in a format like this

Submission - Write-up in google docs & Code in GitHub Classroom

Submit write-up in this google drive folder. Make sure all your previous slide decks are also in the same folder. If not, add them.

Like in HW3, we will be using GitHub classroom for submitting code. See HW5 for instructions.

FAQ

Q: Is it realistic to have a v1 of my dapp ready by Midterm?

A: Yes. Chose the functionality wisely so that you can get it done. Work in a full stack mode and implement features all the way through, one at a time. Start with the simplest feature you can imagine and get it functional all the way. Then move to the next feature. For example in class we built features of the CardinalToken wallet in an hour. We first got it to display the balance of a Metamask user. We then got it to be able to send tokens to other accounts. Afterwards you were able to make it mint new tokens as part of your HW3. So, instead of implementing all sorts of frontend features (for example), and then moving to the backend, we finished each feature all the way, one at a time. In the end we had a dapp usable by end users within an hour, even though its functionality was very limited.