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

Code Review¶

I'd like to help with reviewing on your code, so I'd like you to upload your code to Gradescope so that I can comment on it easily and you can see my comments. Only one submission per group, but remember to include all your group members on the submission

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 JavaScript 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 like Lookup and CRUD).
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.