Draft Version¶

Long before a piece of software is ready for testing, a "demo" or "proof of concept" or "rapid prototype" version is often created. This version demonstrates the user interface and basic functionality, but in a very limited version. For example, a "search" feature might not be implemented at all, but a "canned" search term can be entered and the software will show "canned" results.

This demo version allows the client to decide whether the interface is convenient, helpful and intuitive. It also helps the designers get a handle on what kinds of data will be available at different times, so that tables, queries, inserts and the like can be considered and nailed down more precisely than they were in the design phase.

For the purposes of this project, the draft version is the first release of your own project, as described in your plan. The emphasis should be on the interface: what pages you will have, how they will be connected, what forms you'll have, and so forth, even if they have to be "mock" versions at first. Note that the software must actually work; it can't be vaporware.

Core Features¶

This project phase falls roughly one third of the way through the time we have for coding the project, so you'll also want to have made some progress on that front. So, in addition to having the basics of the interface worked out, you'll want to have implemented some (not all) of your core features. (You'll want to have all or most of the core features implemented by the in-class project presentations, reserving the bells and whistles for exam week.) You can decide what you want to attack first, but it often makes sense to implement adding data before you implement searching the data, so that you can use your software to put in your test data. Some people like to start with logins and session management; others prefer to defer that in favor of the main site content. This is your choice, but you should think about how to manage your time during the project and make sure you get enough done by this milestone, so that the next phase is not too grueling.

How to Submit it¶

It's sufficient for me to have access to the team account so that I can run your code. Make sure there is a clear directory for me to grade that no one on the team will touch while grading is proceeding. Call the directory draft.

What to turn in¶

I will need some help in grading these, since everyone is doing something slightly or radically different. Therefore, the Google doc needs to describe:

• Briefly remind me what the project is about.
• The account and directory with the your code to run/grade.
• The URLs of the web pages I need to look at or test, if it's not obvious and you don't yet have a menu bar.
• The sample usernames, items, and other inputs, so I can use the forms.
• Directions on how to use your pages. That means telling me where to click, what data to enter, what usernames/passwords I need, and so forth. It's amazing how dumb I can be with someone's web app, so be really clear here.

Just try to put yourself in my shoes when I'm looking at your app. You don't want me to think it's broken or missing something when I'm just not using it correctly or have overlooked something.

I also want to comment on your code. I think the Google Docs commenting system is best. That will take a few steps on your part, but you've done this before in the last few assignments.

The title of the document is very important, otherwise I will mis-place it and lose time finding it. The title of the document will be CS304-SEM-YYYY-draft-TEAM where the SEM is the semester (Fall/Spring), the the YYYY is year, and the TEAM is name of your project or team account or your names.

Since Google often makes these documents hard to find (weird for a search company...), please submit the URL via this

URL submission Google Form

Code Upload¶

Note that if you have lots of files, which you might, copy/pasting all the code into the document can be tedious. Here's a shortcut that might be helpful:

1. Concatenate all your files together into a single file: cat app.py other.py templates/*.html static/* > app-all.txt
2. Copy/paste the contents of app-all.text into a Google Doc.
3. Select All and then change the font to Courier New and the size to 10pt.
4. Scan over the code to make sure it's formatted reasonably.
5. Share it with me and with your teammates.

How I will test == How you should test¶

Just to be clear, here's how I will test your code:

• I will login to your team account.¹
• I will activate the venv that is in your team account
• I will cd to your draft directory. ²
• I will run your app.py
• I will test your app in the browser, using the directions that you gave me in the Google Doc.
• I will review and comment on the code in the Google Doc. (Some teams put their code in a separate Google Doc from the one with the directions, and others just create one Google Doc. Either is fine with me, as long as I have both.)

Grading¶

Your draft version should have:

1. Most of the UI figured out (pages, menus, etc)
2. Some core functions working. Note that "core functions" means something the web app does, not a Python function. Furthermore, your web app is a database with a web interface, so the core functions are all database operations, like insert, updating, searching, and so forth. (Think about homeworks 3, 4, and 5).
3. No vulnerabilities (SQL injection, XSS)
4. Good documentation and modularity

Also, this is very important: separate your code for each phase: have a separate place (folder) for your draft version, another for your alpha version and so forth.