Groups

You can work in groups of two on this assignment.

Pair Programming


It is strongly recommended that you use formal “pair programming”, where one person (the driver) types/creates and the other (the navigator) observes/assists. Moreover, you should alternate roles so each person takes on each role for a roughly equal amount of time. Remember that a spokesperson will be randomly designated at checkout time, so both group members need to be comfortable presenting the work.

Repositories

Before configuring a repository, decide if you will be working in a group or not. If you will be working in a group, decide who will create the GitHub group and who will join it.

Follow the same basic process outlined in Studio: IoT Games to create/join a group, download the resulting repository (with GitHub Dekstop), and import it into the Particle Desktop IDE.

The GitHub Link is: https://classroom.github.com/g/RXQqp4A0

Files in your repository:

The repository currently contains:

  • login.html is an empty HTML file
  • NOTE: You will need to add more files to this. All files for this assignment can be added to the root of the project directory. You can create new files in Particle Desktop by Right-clicking on the main folder, selecting New File, then entering the file’s name. Be sure all files have sensible names, that HTML files end in .html and that CSS files end in .css.
  • README.md is a Markdown file containing questions you need to answer when you submit your work.

The Problem

Congratulations! You’ve been recruited by DB, Inc. (a.k.a. DBI) to help build an IoT product for one of their customers. The customer has already met with DBI and started the conversation with the following demo (includes audio narration):


During initial discussions, management decided to create a dictionary of terms used by the customer:

Customer Terms
  • Garage Door Opener (or just opener): refers to the electronic device with a motor that opens and closes the door. It also has a light on it that lights up the interior of the garage.
  • Remote: the small handheld remote control shown in the video.
    • If the door isn’t moving, pressing a button causes the door to start opening or closing.
    • If the door is moving, pressing the button causes the door to stop where it’s at.
  • Wired Button (or just button): In addition to the handheld remote, there is a button mounted on the wall of the garage. When pressed it behaves in the same fashion as the button on the remote.
  • Auto-Close Feature: The customer wants the ability for the door to automatically close after being opened for a defined amount of time. For example, if the auto-close feature is on and its time is set to 10 minutes, the door will always try to close after being open for 10 minutes. The user could decide to never again intentionally close the door and they would be assured that it would automatically close 10 minutes after each time it was opened.
  • Screen (or page): This refers to content that will be displayed on a device. The customer used the term “screen” to describe groups of things that would be shown at the same time on a screen.
  • Control: This generically refers to the UI elements used for input, like buttons, slider bars, text fields & anything that the user may interact with through clicking/touching/keyboard/mouse.


The customer has described the following problems and they feel that an IoT-approach may be the solution:

Customer Problems
  • They often leave home and can’t remember if they closed the door.
  • They occasionally need to let friends/family/neighbors in at unexpected times. Currently they need to either leave the remote control with someone, stay home to allow people in, or leave the door open. (None of these are desirable: they only have one remote, they have a busy work schedule, and there have been recent thefts in the neighborhood)
  • They want to be able to control the door from anywhere, possible using either a computer or a mobile device.
  • The opener has a built in light that turns on automatically when the door moves and then turns off 5 minutes after the door has stopped moving, but they would like more control over its behavior:
    • Have a manual override to turn the light on instantly,
    • Have a manual override to turn the light off instantly,
    • Set its brightness, and
    • Be able to adjust the amount of time until it automatically turns off (when it’s behavior is not being overridden).

Your (First) Assignment

DBI has asked you to create the user interface for their first prototype IoT garage door opener.  After the initial interviews with the customer, meetings with DBI management, and discussions with other members of the development team, they have developed some guidelines:

  • Your current work is purely a UI prototype. There’s no need for JavaScript or any other code.  All work should be HTML and CSS. You may need to explain behavior during checkout. For example, if a button would disappear or change appearance due to some action, you should be prepared to explain that during your demo. All such behavioral changes in the UI should be explained in the README file.
  • Don’t use the <form> element. (We aren’t using forms on any assignments)  
  • HTML should focus on overall organization and content, but not style, which should be handled by CSS.
  • All styles should be in a common CSS file. Avoid the use of in-file or in-line styles.
  • The project will need several “screens”. For now each screen should be a separate HTML file.
  • DBI wants to support specific modern devices. They expect all screens to work perfectly on desktop browsers, iPhone 8 (375x667), Galaxy S5 (360x640), and the Nexus 6P(412x732). Fortunately these can all be emulated via Chrome or Firefox’s developer tools. There’s no need to be concerned with anything smaller than 360x640.
    • Your work should follow the principles of “Responsive Web Design”.  It should look good on a variety of devices, at different resolutions, and in both portrait and landscape orientations. The developer tools on most web browsers allow you to see screens in common mobile device formats. W3 Schools has a “Responsive Web Design - Introduction” you may want to review.  Another Google’s “Responsive Web Design Basics” and “Web Fundamentals” (which contains a section on “Design & UI” with subsections covering Responsive Design) are also great resources. 
  • This will eventually become either an App or a web site that is mainly used via mobile devices. Mobile users (and DBI) don’t like to scroll, so consider any screen that requires scrolling (on any device) to be prohibited.
  • When viewing the webpage as an App, this may be used on small devices by people with poor eyesight and large fingers. Be sure that:
    • Items are large and easy to read
    • Any items a user may need to touch are far enough apart that large fingers would not be touching multiple items
    • Any item a user may need to touch is large enough to be an easy target
  • The required screens are:
    • Login:  This will be the first screen users see when using the product for the first time, or when accessing it from a new device or browser, etc. (i.e., when it needs to verify the authenticity of the user before letting them change the status of the door). It should allow entry of a username and password. 
    • Account Creation: This screen should allow users to enter:
      • Desired username
      • The desired password (twice to ensure it’s entered correctly). 
    • Status and Basic Controls: This will be the first screen shown when logged in. Since a good user interface should always provide easy access to the most important features, this screen replaces and augments the functionality of the traditional remote control. It should:
      • Indicate if the door is up, down, opening, or closing (When using the traditional remote the user can see the status of the door visually, but that may not be possible when operating the door remotely, so this needs to be shown somehow),
      • Indicate if the light is on/off,
      • Allow the user to change the door’s status, and
      • Allow the user to change the light’s status (the instant off/instant on).
    • Advanced Feature Support:  These may be combined in one screen or split into several.  If you combine them, ensure that they will be easy to use:  
      • Support for the “auto-close” feature:
        • Ability to enable/disable the feature and
        • Ability to set the amount of time (the expected range is 5 min - 24 hrs)
      • Control the light’s behavior
        • Ability to set the light’s brightness
        • Ability to set the amount of time until the light automatically turns off (the expected range is 5 min - 4 hours)
  • You should make an effort to pick controls that will simplify interaction as much as possible.
  • Due to a previous lawsuit involving improper use of a copyrighted font, ownership of content and intellectual property is very important to DBI. Consequently, they expect you to create all HTML and CSS content yourself. You are not allowed to use outside libraries.  You may refer to existing libraries as examples, but all submitted work should be yours and you should cite any sources that influenced your work.  
  • For the mock-up you may use artwork that is not your own, however:
    1. DBI strongly prefers things with a license that allows for free commercial development and
    2. You must cite the source of any artwork as a comment in-line where the artwork occurs and indicate the comment should any details about its licenses or copyrights.
  • Submitted code (HTML & CSS) should be well organized and formatted (indentation, etc.).
  • Submitted code (HTML & CSS) should pass validation tests. You can go here (https://validator.w3.org/#validate_by_upload) to upload a file for validation or copy/paste it into the form here (https://validator.w3.org/#validate_by_input).
  • Code should be commented to make it easy to read and modify.  
  • Screens should include navigation controls so it’s easy to get from one screen to another and back.  No sequence of operations should lead to a screen without being able to get back to its predecessor. 

Work Flow & Artifacts that are Due

The only materials due will be the HTML and CSS, but you are encouraged to start with user stories, usage scenarios, and paper prototypes to establish a vision of how you will support all the features. 

Tentative Rubric 

Login Screen (11 points)
  • fields to enter username & password
  • login button
Account Creation Screen (11 points)
  • fields to enter username & password (twice for verification)
  • submit/create button
Status & Basic Controls Screen (21 points)
  • display the status of the garage door
  • display the status of the garage’s light
  • button to change status of door
  • button to change status of light
Advanced Features Screen (21 points)
  • ability to enable/disable autoClose feature
  • ability to change amount of time before an autoClose is executed
  • ability to adjust desired brightness of the garage’s light
  • ability to change amount of time before light automatically turns off
Miscellaneous (20 points)
  • responsive web design
    • no scrolling should be required on any screen
    • buttons, input fields, & text should all be large enough for all earlier mentioned screen sizes
Best Practices (16 points)
  • should successfully validate with no errors
  • keep CSS in its own CSS file (no CSS mixed in with your HTML)
  • comment your code
  • completion of README.md

Submission & Checkout

As outlined in the course policies, you must commit work and demo it by class time on the due date for full credit. The commit process was described in Studio: IoT Games .

You need to be prepared to demo and explain your work during your checkout as well as answer the questions in the README.

Checkout and review will be done on a first-come-first-serve basis.  If you aren’t done before class you risk not being able to check out during class time.  Work demoed after class time is considered late and will either not count as a grade or will consume late day coupons.