### Functional and technological specification Put your specification in your *readme.md* in your gitlab.liu.se repo. Use [markdown](https://docs.gitlab.com/ee/user/markdown.html). **Submissions by email will not be considered.** #### Functional: Describe your project vision and core functions. Don't mention every little detail - this is for us to help you define a suitable scope. Compare to other services for inspiration or create some image that helps us see the process. Make sure you seem to mach the requiremets. #### Technological: Describe (1) client framework (2) server framework/backend setup. *Making intelligent framework choices* is part of the course. Take time to research your options. Also, frameworks have varyingly complexity. Ember and Angular is perhaps most complicated and React the simplest out of the box but you end up adding parts. Choose something that fits your experience level, but is also at a suitable level for the course. Grading is based on how far you go in terms of technical competence in front and backend, but to some extent mostly front-end. Remember, the specification is not a contract - you can change any way you want after submission. After the deadline we will give you feedback. Comments will relate to scope and complexity, not so much functionality. Comments will be in the form of cautions and suggestions. Since you are free to make your own choice about technology, we do not and cannot know every detail, but we look for technical risks and realistic scope. Also, remember, our approval doesn't mean you have a contract to pass the course - examination is based on the end result. **Don't wait for our feedback, as a rule 99 out of 100 projects are acceptable. You should get started working right away.** --- ### Project status seminar: Sign up will be announced on course web page news. Students that have substantial progress now tend to finish and get good grades. You participate in a 2 hour workshop, the whole team presenting your project for about 10 minutes. **One one person should book time in webreg.** Show your pejects. Live demonstration och recorded presentations. Also, talk only briefly about the frameworks in genreal and spend your time on whats in your proejct, your expreinces and difficulties and streagths you've expreinced. You should not go through every littel detail of the systen, but can show important peiced of code. **Seminars will run back-to-back so you must be prepared and practice demonstrating your system.** --- ### Individual oral code screen-cast: Links on you gitlab.liu.se repo. Every student will individually present the code and system parts. You should show and speak in your own voice to explain. Incldue a video of yourself in the video. The screen cast should be published online somehow, on youtube, OneDrive or vimeo or some other place. *Put the link you your screencast in your readme-file on gitlab.liu.se.* The screen-cast should be visible for anyone with the link without password or specific access. This is so that we can also elicit others to help us in the review process. **E-mails containing screencasts or links to screenacsts are will NOT be considered.** You can find a Wikipedia article on software for (screen casts here)[http://en.wikipedia.org/wiki/List_of_screencasting_software] **For some students we may require a personal demonstration at IDA and will in those cases email your on your student email. One reason may be that you have not presented anything substantial on the mid-course seminar. Also, we may not understand your level of knowledge. Furthermore, there might be some uncertainty about your code/project.** --- ### Project Screencast: Link on your gitlab.liu.se repo. In your project screen cast you should present your web project. Use the keywords {TDDD27, LiU, projectname } in the title to make it easier to find. Give a general overview *what you have done* but also present some technical challenges and *how you have solved them* The screen cast should be published online somehow, on youtube, OneDrive or vimeo or some other place. *Put the link you your screencast in your readme-file on gitlab.liu.se.* The screen-cast should be visible for anyone with the link wihout password or specific access. This is so that we can also elicit others to help us in the review process. **E-mails containing screencasts or links to screenacsts are will NOT be considered.** You can find a Wikipedia article on software for (screen casts here)[http://en.wikipedia.org/wiki/List_of_screencasting_software] --- ### Final source code hand-in: What's on gitlab.liu.se on the deadline is your hand-in. You don't have to do anything special.