Wednesday, November 19, 2008

Presentation Schedule

Please be sure to follow the format given in the project description. I look forward to seeing your presentations!

24 Nov

  1. XForms - team 1
  2. Google Web Toolkit - team 6
  3. Java Applets - team 5
  4. Adobe Flex - team 2
  5. Google Android - team 3
1 Dec
  1. Adobe AIR - team 8
  2. Google Maps API - team 7
  3. Yahoo Pipes - team 9
  4. Curl - team 10
  5. Mobile RIA frameworks - team 4

Monday, October 13, 2008

Project 5

Due Date: Monday, 8 December (firm)

Group Project

Objectives

Familiarity with

  • client-side JavaScript
  • DOM event handling
  • jQuery library
  • AJAX
  • mashups
  • public web APIs

Description

In this project, you will develop a browser-based mashup (from at least two sources) of your choice, pending on instructor approval. No later than Friday, 14 November, should you have discussed your project choice with the instructor and finalized the project requirements. This project is a great opportunity for your group to get really creative. (Hint: keep it simple! As many of the examples show, some useful mashups are extremely simple.)

General requirements

For full credit, your mashup should have the following characteristics:

  • some form of persistent data
  • data and/or functionality from two or more source APIs
  • clear, useful functionality on top of the source data/functionality

Examples

Sample project

The default project, in case you prefer not to come up with your own, is a continuation of the food and health themes from Project 3. The requirements for this option, called the Recipe Sanity Check Mashup, are as follows.

  • The user enters the ingredients of a recipe into a table with a column for the ingredient name and another column for the quantity.
  • The user then presses the "check" button.
  • For each ingredient, the application then shows the following information:
    • energy in kcal for the given quantity
    • some pictures that pop up on demand
  • The application also calculates the total energy for the recipe.
Extra credit is given for the following additional functionality:
  • (Less hard) Links to health-related articles for each ingredient.
  • (Less hard) Storing data for ingredients not yet in the database.
  • (Harder) Storing, retrieving, and searching recipes.
Nonfunctional requirements:
  • Browser-based mashup in JavaScript with one or more suitable libraries such as jQuery.
  • Per-ingredient calory data comes from Google Base, where you can manually enter this information through your Google account. Recipes can be stored there as well.
  • Photos come from a source such as Flickr. You should narrow the search using suitable tags.
  • Health-related articles can come from the British NHS.

Alternative approaches

You are also welcome to build a hosted mashup using platforms such as Yahoo! Pipes, Microsoft Popfly, Ning, or IBM Mashup Center. You will need a Yahoo! account to use Pipes, or a developer account on one of the other services, and you will learn on your own how to use them.

Submission

Please send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date. Be sure to include your departmental Linux ID in your email message.

Project 4

Due Date: Wednesday, 29 October

Individual Project

Objectives

Familiarity with

  • client-side JavaScript
  • DOM event handling
  • JavaScript timers
  • jQuery library

Description

In this project, you will implement a simple browser-based timer.

Functional requirements

The timer has the following controls:

  • One two-digit display of the form 88.
  • One multi-function button.

The timer behaves as follows:

  • The timer always displays the remaining time.
  • Initially, the timer is stopped and the (remaining) time is zero.
  • If the button is pressed when the timer is stopped, the time is incremented by one up to a maximum of 99. (The button acts as an increment button.)
  • If the time is greater than zero and three seconds elapse from the most recent time the button was pressed, then the timer beeps once and starts running.
  • While running, the timer subtracts one from the time for every second that elapses.
  • If the timer is running and the button is pressed, the timer stops and the time is reset to zero. (The button acts as a cancel button.)
  • If the timer is running and the time reaches zero by itself (without the button being pressed), then the timer stops and the alarm starts beeping indefinitely two times a second.
  • If the alarm is sounding and the button is pressed, the alarm stops sounding; the timer is now stopped and the (remaining) time is zero. (The button acts as a stop button.)
  • The label of the multi-function button should indicate the current function of the button, such as increment, cancel, or stop.

Nonfunctional requirements

  • All code for dynamic client-side functionality must be provided in the form of external JavaScript source files using components from the jQuery library; embedded JavaScript within XHTML documents is not permitted. Your JavaScript code should include inline comments where appropriate.
  • All content must be valid XHTML 1.1 documents. You are advised to use a validating editor or the W3C Validation Service to ensure that your content is valid. For convenience, you may want to place a link on each document that runs the validation service on this document. Your document should state the correct document type at the top.
  • All rendering styles must be provided using a single shared valid CSS2 style sheet. There must not be any rendering styles in the documents themselves. You are advised to use a validating editor or the W3C CSS Validation Service to verify that your style sheet is valid.

Grading

Total: 10 points

  • Increment state /1
  • Counting state /1
  • Alarm state /1
  • Working timers /1
  • Error checking (limits checking in increment mode) /1
  • Changing Label on button /1
  • Visual presentation look/feel /1
  • Proper separation of document, styles, and behavior /1
  • Proper architecture in behavior part /1
  • Inline comments /1

Submission

Please send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date. Be sure to include your departmental Linux ID in your email message.

Sunday, October 12, 2008

Project 6

Due Date: Wed 29 Oct (outline); Mon 24 Nov (presentation)

Group project

Description

In this project, you will have the opportunity to investigate a topic of interest in the area of client-side web development.

Given the remaining time of the semester and the length of each presentation, you are not expected to conduct an exhaustive study of your topic. The purpose of this project is for you to find and present some starting points for using a particular technology or discuss the utility of some general approach. Please consult with me if you have any questions.

Deliverables

This project consists of the following deliverables:

  • Brief outline of your presentation due on 29 October.
  • In-class presentation of your findings (10-15 minutes, followed by up to 5 minutes of questions) held on 24 November and 1 December.
    • Where appropriate, presentations should address "who/what/when/why/how" questions, discuss the significance and availability of the technology, and how it relates to competing technologies.
    • Presentations about specific software libraries, frameworks, or platforms must include a brief working demo of up to 5 minutes.
  • Accompanying materials, such as electronic copies of your visual presentation, code examples, etc.

Groups are encouraged to involve all members in the presentation. For example, two people could present separate parts of the findings, and the third could give the demo. Please choose what you believe works best for your topic.

Possible topics

Here are some possible topics:

You are encouraged to propose other topics, subject to instructor approval.

Submission

Please refer to the online submission procedure. Each team is to make exactly one submission. Any written materials should be submitted either in PDF format or through Google Docs.

Monday, September 22, 2008

Project 3c

Due Date: Friday, 10 October

Individual Project

Objectives

Familiarity with

  • automated testing
  • test-driven development (TDD)
  • client-based testing
  • Selenium IDE

Description

In this project, you will add client-based testing to your prototype from project 3b. Use the Selenium testing IDE to develop test cases that cover the various scenarios listed again below.

All nonfunctional requirements from the previous projects 3a and 3b still apply.

Grading

Total: 10 points

  • 2 - nonfunctional requirements
  • 1 - Member authenticates
  • 2 - Member records a meal
  • 2 - Member records an exercise activity
  • 2 - Member records vital signs
  • 1 - Member calculates average food energy

Submission

Please send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date. Be sure to include your departmental Linux ID in your email message.

Project 3b

Due Date: Wednesday, 8 October

Individual Project

Objectives

Familiarity with

  • XHTML
  • DOM (document object model)
  • JavaScript
  • client-side scripting and DOM event handling

Description

In this project, you will extend your prototype from project 3a to include two types of dynamic client-side behavior:

  • enhanced input controls
  • simple processing of input data

Specifically:

  • Incorporate a date/time picker for entering date and time of meals, activities, vital signs, for choosing the time period for the average energy report, etc.
  • Record all tags entered by a user in a suitable data structure. Incorporate a tag picker that allows the user to pick existing tags from a list or enter new ones.
  • For each meal, estimate the ingested energy as 100 times the number of words in the description. Display the result as the meal is recorded. Add an object representing the meal to a suitable data structure.
  • For each activity, estimate the expended energy as 50 times the number of words in the description. Display the result as the activity is recorded. Add an object representing the activity to a suitable data structure.
  • Use the internal data structures to compute the average food energy consumed per day during a given time period.

All code for dynamic client-side functionality must be provided in the form of external JavaScript source files using components from the jQuery library; embedded JavaScript within XHTML documents is not permitted. The visual design requirements and nonfunctional requirements from project 3a still apply.

Grading

Total: 10 points

  • 1 - valid XHTML 1.1 (browser shows standards compliance mode)
  • 1 - external CSS, no style attributes in content documents
  • 2 - external JavaScript, no embedded code
  • 1 - date/time picker
  • 2 - tag recording and picker
  • 1 - calculate energy intake from meal
  • 1 - calculate energy expense from activity
  • 1 - calculate average net intake/expense

Submission

Please send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date. Be sure to include your departmental Linux ID in your email message.

Monday, September 8, 2008

Project 3a

Due Date: Wednesday, 17 September

Individual Project

Objectives

Familiarity with

  • separation of concerns between content and visual styles
  • XHTML
  • CSS
  • divs, tables and CSS layers (not to be confused with the deprecated, non-standard layer element)
  • forms

Description

In this project, you will put together a small static prototype for a few scenarios from a simple online food and exercise diary. Specifically, your prototype should represent the following scenarios:

  • Member authenticates (logs in)
  • Member records a meal or exercise activity (including date and time consumed, title, description, and space-separated tags)
  • Member records vital signs (including date and time measured, as well as mass, height, and heart rate)
  • Member calculates average food energy (in kcal) consumed per day during a given time period

The visual design requirements for this static prototype is as follows:

  • All pages must have the same, consistent layout
  • All pages must have the same, consistent text styles, using some cool fonts and colors other than the default
  • Use divs to divide each page into (common) navigation and (page-specific) content
  • Use layers to place a cool logo somewhere (consistent) on each page
  • Use forms wherever the user needs to be prompted to submit some information

The static prototype of the system, by its nature, ignores any attempts to change the data in the system. It does not perform email notification either.

Your system must also satisfy the nonfunctional requirements stated below. It is recommended to use Aptana to author the XHTML documents and CSS style sheets for this static version; you can then browse the documents locally or remotely using a web browser.

Nonfunctional Requirements

  • All content must be valid XHTML 1.1 documents. You are advised to use a validating editor or the W3C Validation Service to ensure that your content is valid. For convenience, you may want to place a link on each document that runs the validation service on this document. Your document should state the correct document type at the top.
  • All rendering styles must be provided using a single shared valid CSS2 style sheet. There must not be any rendering styles in the documents themselves. You are advised to use a validating editor or the W3C CSS Validation Service to verify that your style sheet is valid.

Grading

Total: 10 points

  • 1 - valid XHTML 1.1 (browser shows standards compliance mode)
  • 1 - external CSS, no style attributes in content documents
  • 1 - correct use of divs and tables
  • 1 - overall visual design
  • 1 - consistent layout and navigation
  • 1 - scenario: authentication
  • 1.5 - scenario: record meal/activity
  • 1.5 - scenario: record vitals
  • 1 - scenario: average kcal

Submission

Please send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date. Be sure to include your departmental Linux ID in your email message.