{"id":132,"date":"2013-06-21T13:23:41","date_gmt":"2013-06-21T17:23:41","guid":{"rendered":"http:\/\/localhost\/cs4760\/2014\/?page_id=132"},"modified":"2017-12-24T13:47:04","modified_gmt":"2017-12-24T18:47:04","slug":"project-assignment-2-website-and-interaction-design","status":"publish","type":"page","link":"https:\/\/cs4760.csl.mtu.edu\/2018\/assignments\/cs4760-assignments\/project\/project-assignment-2-website-and-interaction-design\/","title":{"rendered":"Project Assignment 2 – Website and Interaction Design"},"content":{"rendered":"

Website<\/h2>\n

Design and implement a website for your project. Recall that a website is a domain of HCI and your site will be evaluated accordingly. The website does not need to be elaborate, but it should serve the purpose of the users of your website. Users of your website are your development team (CS & HU students), me (the instructor), graduate students, and your client (the scientist). We use your website to track your progress and evaluate your design and documents. Graduate students will provide additional documents for projects. When your client and I review your project, we will want to refer to the graduate student document, so your website must have links to their documents on a per document basis. Graduate students are also users of your web site. They will refer to your website to find your design documents for the project, which they need to write their documents. Consequently your design documents must be posted timely and kept current. Other users might discover you website and want to know more about your project. In the era of modern web search engines more people may view your web pages than you suspect. In fact, I have received email from some companies interested in a course project.<\/p>\n

All design documents should be linked in your website in a format readable by all web browsers. Initially, the website will include a home page with application name, and team membership. The initial website will also contain the interaction design documents (described below). The documents are to be posted online by the due date. The documents do not have to be a single file, but they should be recognized as a group and easily navigated in the website.<\/p>\n

You may use most any tool or templates that you\u2019d like to make your team website. It should be a static website, meaning made up of html, jpg and pdf documents. There should not be a database backend. Consequently, something like WordPress would NOT be appropriate. The website should not have redirection, meaning in a .htaccess file. I have two goals for the website:<\/p>\n

    \n
  1. A central location to store your design documents that I can zip and save for posterity.<\/li>\n
  2. A media for sharing your documents with your client, team and grad student.<\/li>\n<\/ol>\n

    I do not expect anything elaborate in these websites in terms of styling or design. Your design for the website should pay attention to ease of access and finding documents.<\/p>\n

    Team & Project Documents:<\/h2>\n

    Team\u00a0Charter<\/h3>\n

    Your team charter is NOT\u00a0posted on website but should be uploaded to your team directory, so that I can view it.<\/p>\n

    Meeting\u00a0Minutes<\/h3>\n

    Your team is to keep meeting meeting notes and post them on the team website. This a lecture about teams\u00a0 for a detail description of meeting notes. Karla and I plan to study your team process and plan to use your meeting minutes to learn the details of your team process. So, Karla and I request that your minutes\u00a0 contain:<\/p>\n

      \n
    • Team Name<\/strong><\/li>\n
    • Date, time and duration<\/strong> of the meeting<\/li>\n
    • Location or Media<\/strong> of the meeting, for example “in-person at Reki 101” or by “Google Hangouts”<\/li>\n
    • Attendance<\/strong> – list of team members present at the meeting.<\/li>\n
    • Action Items<\/strong> – list of tasks and team member assigned to do the work<\/li>\n
    • Discussions, Decisions and Rationale<\/strong> – list of topics and decisions made with rational for the decision.<\/li>\n
    • Next Steps<\/strong> – list of topics for the next meeting<\/li>\n<\/ul>\n

      Post your meeting minutes on the website immediately after the meeting.<\/p>\n

      Scientist Meeting Notes<\/h3>\n

      Your team should make notes during your meeting with scientists and post them on your team websites. These notes are different from team minutes. These meeting notes are for recording all that you learn from your meeting with the scientists. So you will try to record as much as you can during the scientists meeting. See my lectures on interviewing for more details.\u00a0Karla and I plan to study\u00a0the interaction between your team and\u00a0scientist. We\u00a0plan to use your scientists meeting minutes to learn the details of your interaction with your scientists. So, Karla and I request that your\u00a0notes\u00a0contain:<\/p>\n

        \n
      • Team and Scientists Names<\/strong><\/li>\n
      • Date, time and duration<\/strong>\u00a0of the meeting<\/li>\n
      • Location or Media<\/strong>\u00a0of the meeting, for example “by Zoom” or “by Phone”<\/li>\n
      • Attendance<\/strong>\u00a0– list of team members and scientists present at the meeting.<\/li>\n
      • Discussion items\u00a0<\/b>– list of items discussed with specifics about the topics.<\/li>\n<\/ul>\n

        Scientist meeting notes should posted on the your team website immediately after the meeting.<\/p>\n

        Design Documents:<\/h2>\n

        These are the design documents that must be posted on your team website. Note that many of these documents should be a collaborative effort between the CS and HU students on your team, while others are the primary responsibility of either the CS or HU students. For the app itself, CS and HU students should collaborate on interface design. HU students will also be responsible for suggesting design and creating content for the reference\/help material which will be incorporated into the app (such as an in-app tutorial). This content should be taken into account when designing the app interface.<\/p>\n

        The design documents must include:<\/p>\n

          \n
        • Brief overview of the system, including the device and any other device used by the system (CS & HU students)<\/li>\n
        • Descriptions of important stakeholders, including users\u00a0(CS & HU students)<\/li>\n
        • 4 user personas (See lecture notes)\u00a0\u00a0(CS & HU students)<\/li>\n
        • Descriptions of the environment that users will be in while using the device and performing tasks\u00a0\u00a0(CS & HU students)<\/li>\n
        • Scanned or transcribed notes from the interviews with the scientist and among yourselves\u00a0\u00a0(CS & HU students)<\/li>\n
        • 2 scenarios describing the nominal use of the application, drawing on your personas (See lecture notes and below)\u00a0\u00a0(CS & HU students)<\/li>\n
        • Simplified hierarchical task interaction design (See lecture notes and below) (CS students)<\/li>\n
        • A Preliminary Instructional and other Content Design Plan for the app. (HU students)<\/li>\n
        • A description of your database schema (CS students)<\/li>\n<\/ul>\n

          These documents do not include sketches of the interface\u2019s visual design; your interface’s visual design will be presented during the cognitive walkthrough.<\/p>\n

          After your website is reviewed in class, graduate students will give you links to their stakeholder analysis documents. You are to link the graduates’ stakeholder analysis to your website. The links should be clear and well organized, so that users of your web site will easily recognize them. You should also review the graduate students\u2019 user-task-goal analysis documents and compare them to the nominal interaction diagram and scenario documents. If there is substantial disagreement, your group should discuss them with the graduate students. A good user interface cannot be designed without a thorough understanding of the users, their goals and the tasks to be performed with the interface.<\/p>\n

          Stakeholders and Users<\/h3>\n

          List and describe the stakeholders. You should name their role and level in the onion model. Some specific stakeholders you may want to also give proper names, for example the scientists for your project. You should also identify the different users of app and classify them as primary or secondary. Briefly describe the user characteristics that you think are important for the design, for example are they novice or expert users.<\/p>\n

          Personas<\/h3>\n

          Usability expert Carol Barnum (Usability Testing Essentials: Ready, Set…Test! Morgan Kaufman, 2010) defines personas as \u201cfictional representations of people that are created from real data about your users\u201d (94). Remember that although personas require creativity, the information presented should be relevant to the product or document that you are creating and should help designers \u201cunderstand user motivation, fears, concerns, and goals as they relate to your product\u201d (97).<\/p>\n

          Nominal Use Scenario<\/h3>\n

          The nominal use scenario is a verbal description of a nominal (error free) sequence of events using the system. It should describe how the major stakeholders (primary and secondary stakeholders) interact with the system or the application. The description should be several paragraphs, one paragraph for each stakeholder interacting with the system.\u00a0 It should read like a story.<\/p>\n

          Simplified Hierarchical Task Analysis<\/h3>\n

          A complete<\/em> hierarchical task analysis (HTA) diagrams the different uses of the application in a tree, where the higher level are associated with goals, intermediate levels represent the tasks to achieve these goals, and the lower levels represent actions to perform the tasks. Links in the tree associate tasks with goals, and actions with tasks. A complete HTA can consume lots of time and paper.<\/p>\n

          I suggest making a simplified<\/em> HTA which dispenses with links and uses intended tabs to represent the hierarchy.\u00a0 The intent of the simplified HTA is to represent the views of the application by the different indentation levels. A single indentation level may represent more than one view. Try to represent all the views. In other words, the simplified HTA still represents all the uses of the applications, but does not attempt to diagram the actions. You may need to use several indentation tables for application goals that have little in common.<\/p>\n

          I suggest using a top-down approach to develop the simplified HTA. First list all the major goals or tasks of the application; this will represent the views. Then indent and list the actions to achieve the corresponding goal or task; this will represent UI elements in the view. Try to name the tasks and sub-tasks with words that might be used in the application view.<\/p>\n

          Database<\/h3>\n

          All Citizen Science projects collect data for scientist to use. In order for the scientist to have access to the data, your app should upload the data to a website.<\/p>\n

          Domain Classes<\/h4>\n

          Grails and GORM create the database table from the Grails project domain classes. The domain class is a collection of typed class members. The domain class represents the table in the database or a row of the table. The class members name represents the column names in the table.<\/p>\n

          Schema Specifications<\/h4>\n

          A database schema is the design of tables composing your database. I expect that your schema design to evolve during development, but you should begin the design now. An appropriate design format is list of domain classes\u00a0with an intended list of \u00a0class member names (column names in the table) with type and description. The format is:<\/p>\n

          Domain\u00a0: <name> – <description><\/p>\n

            \n
          • var1 – <type>, <description><\/li>\n
          • var2, – <type >, <description><\/li>\n
          • \u2026<\/li>\n<\/ul>\n

            Schema Specification Example<\/h4>\n

            Suppose you are designing the “Army App” data base that soldiers use to read missions and report incidents that can have photos or recordings (read lecture notes). \u00a0Your schema design might be:<\/p>\n

            List of Domain Classes:<\/p>\n

              \n
            • Mission \u2013 list of\u00a0mission names with dates<\/li>\n
            • Incident \u2013 list of incidents<\/li>\n
            • Incident_photo \u2013 associates photos with missions<\/li>\n
            • Incident_recording \u2013 associates recordings missions<\/li>\n<\/ul>\n

              Domain Class: Mission – list of missions<\/p>\n

                \n
              • name \u2013 String, mission name<\/li>\n
              • date \u2013 Date, date of mission<\/li>\n<\/ul>\n

                Domain Class: Incident \u2013 list of incidents<\/p>\n

                  \n
                • mission \u2013 Mission, foreign key into missions table<\/li>\n
                • date \u2013 Date, date of incident<\/li>\n
                • Time \u2013 long, time of incident<\/li>\n
                • latitude \u2013 double, latitude coordinate of incident<\/li>\n
                • longitude \u2013 double, longitude coordinate of incident<\/li>\n
                • type \u2013 String, incident type = (civil, suspicious, littering, theft, \u2026)<\/li>\n<\/ul>\n

                  Domain Class: Incident_photo<\/p>\n

                    \n
                  • incident \u2013 Incident, foreign key into incident table<\/li>\n
                  • date \u2013 Date, date of photo<\/li>\n
                  • time \u2013 long, time of incident<\/li>\n
                  • latitude \u2013 double, latitude coordinate of photo<\/li>\n
                  • longitude \u2013 double, longitude coordinate of photo<\/li>\n
                  • file_uri \u2013 String, URI (path with name) to the photo file<\/li>\n<\/ul>\n

                    TABLE: Incident_recording<\/p>\n

                      \n
                    • incident \u2013 Incident, foreign key into incident table<\/li>\n
                    • date \u2013 Date, date of recording<\/li>\n
                    • time \u2013 long, time of incident<\/li>\n
                    • latitude \u2013 double, latitude coordinate of recording<\/li>\n
                    • longitude \u2013 double, longitude coordinate of recording<\/li>\n
                    • flie_uri \u2013 String, URI (complete path) to the recording file<\/li>\n<\/ul>\n

                      HU4628 & CS4760 Collaboration<\/h2>\n

                      Both CS and HU students should have access to the directory and website. Your team will work together to create the progress and design documents indicated above. When HU team members finished their help design plan and their\u00a0audience and task analysis, CS students should\u00a0help the HU students post their assignments on the websites.<\/p>\n

                      Note that although the HU and CS students sometimes have\u00a0separate task analyses, you should discuss the all the tasks\u00a0with the entire team\u00a0because all the tasks\u00a0are\u00a0associated with the design and development of your app.<\/p>\n

                      Email Me<\/h2>\n

                      Send me (pastel at mtu.edu) and Karla Kitalong (kitalong at mtu.edu)\u00a0 an email informing us that your website is initiated (home page is up), so we can review the website and make any suggestions. The subject line of the email should be<\/p>\n

                      cs4760-HU4628 Project Assignment 2 \u2013 <team name><\/p>\n

                       <\/p>\n","protected":false},"excerpt":{"rendered":"

                      Website Design and implement a website for your project. Recall that a website is a domain of HCI and your site will be evaluated accordingly. The website does not need to be elaborate, but it should serve the purpose of the users of your website. Users of your website are your development team (CS & […]<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":82,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"page-templates\/front-page.php","meta":{"footnotes":""},"class_list":["post-132","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/pages\/132","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/comments?post=132"}],"version-history":[{"count":53,"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/pages\/132\/revisions"}],"predecessor-version":[{"id":2043,"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/pages\/132\/revisions\/2043"}],"up":[{"embeddable":true,"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/pages\/82"}],"wp:attachment":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2018\/wp-json\/wp\/v2\/media?parent=132"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}