---
tags: mstu5003, webapp, html, css, bootstrap, inclusiveteaching, socialjustice
---
# Web App UI: inclu

Team: Nicole Aberg-Cobo, Michelle Avenant, Tina Keswani, Lucius Von Joo

:::info
**inclu** is a web platform that provides secondary school educators with crowd-sourced, social justice-themed lessons to support them in creating inclusive classrooms. It also establishes a community for educators to share experiences and tactics from their classrooms, as well as rate lesson resources.
:::

**Phase I:** How educators (i.e. users) can create new or upload existing lesson resources.

**Phase II:** Homepage design. User registration (i.e. profile creation). Approving submitted lesson resources. Browsing and searching for existing lesson resources. Rating and commenting on lesson resources.

**Phase III:** The inclu community: collaboration, discussion, storytelling, sharing experiences amongst educators. Points for interacting with the system (uploads, replies, etc).

**Phase IV:** Levels and badges for educators to become experts, mentors and coaches in the community. User editing of their existing resources.

:::info
:information_source: For Project 001 **(Due Oct 17th)** we are focusing on **Phase I**, the user creation of a lesson resource. For simplicity, we kept each section, which should eventually be a new html page, on one page.
:::

## Phase I: Signed-In user creation of a lesson resource

**See mock-up: https://codepen.io/nma2162/collab/d61459c30dba34b4275fcd272ddbad01**

Using Bootstrap's framework for `CSS` , a form has been created to step a user through creation of a lesson resource. Based on Bootstrap's [Grid System](https://getbootstrap.com/docs/5.1/layout/grid/) the parent `container class` has several components we are utilizing.

### Section 0:** Upload an existing lesson resource
This `child` `div` within the column establishes an `input` to upload a file.

      <div class="mb-3">
        <label for="formFileMultiple" class="form-label question">If you have a lesson resource, please upload your file(s)</label>
        <input class="form-control" type="file" id="formFileMultiple" multiple>
      </div>

- Pushing the **Choose Files** button will open up a window where a user can choose a file from several sources some of which include their computer, google drive or dropbox.

- The `id` formFileMultiple will uniquely identify the file upload `object`, so its `value` can be retrieved in the system and be used in, for example, search results display or associated with a user's profile

- Clicking the **Next** button will take users to a new `html` page asking them if they would like to have their resource evaluated (i.e. take them through a set of questions to determine rigor of the lesson) as well as save any files into the inclu system with it's associated filename`attribute` and date timestamp. Selecting 'yes' for evaluation will take them to **Section 1**.
:::info
:information_source: The challenge here was thinking through how we want the user to follow different paths if they have an existing resource and want to evaluate it, have an existing resource and don't want to evaluate it or if they have nothing.
:::

### **Section 1:** Tagging classroom interests, learning profiles and accommodations (to be associated with the lesson resource)
- Each section will start with a question. A question `class` has been defined in our `css` to allow for standard and consistent formatting on every page that has a question:

.question {
  font-size: 16px;
  margin-bottom: 10px;
  margin-top: 10px;

- Each lesson resource `object` will have one or more `attributes` within **Interests**, **Learning Profiles** and **Accommodations** associated with it. We will establish an `array` of `string` `values` for each of these categories. What the user selects is associated with that lesson resource `object`.

:::info
:information_source: The question here was whether we can have text boxes whereby, as a user starts typing, pre-existing/pre-set up lists start to appear (ex. a list of interests, a list learning profiles, etc.) to choose from instead of having long lists of checkboxes already on the page that they need to multi-select from?
:::

- In javascript, when working with the `string` `values` we can display the `values` in, for example, search results so that when a user sees a resource they can see what types of interests, learning profiles and accommodations are associated with that lesson resource `object`.
- Clicking the **Next** button will take users to a new `html` page called **Section 2**, as well as save all category`attributes` with the associated lesson resource `object` in the inclu system.
:::info
**Next Phase Note**: Each category's **Interests**, **Learning Profiles** and **Accommodations** `array of values` could appear as `lables` wherever the lesson resource `object` is displayed with different (but accessible) `color` `attributes` . Example, chosen values for **Interests** could be in blue, etc.:mega:
:::

### **Section 2:** Choosing social justice topics and setting familiarity and comfort levels
- Along with selecting social justice topics that will be associated with the lesson resource `object`, two `input` `ranges` were created that allow users to select, on a scale, how familliar and comfortable they are with the topic(s) they are submitting.

<h6>How famliar are you with the topic?</h6>
        <div class="mx-0 w-100">
          <label for="customRange3" class="form-label float-start">Not at all</label>
          <label for="customRange3" class="form-label">Somewhat</label>
          <label for="customRange3" class="form-label float-end">Extremely</label>
          <div class="range">
            <input type="range" class="form-range" min="0" max="6" step="1" id="customRange3" />
          </div>

:::info
**Next Phase Note**: Each point on the scale will represent an internal value of 1 through 6 which, through javascript, will be calculated for an average score to help the internal reviewer assess the comfort level of the user with the lesson resource. :mega:
:::

:::info
:information_source: **Sections 3, 4, and 5** ensure the lesson applied the right amount of rigor and thoughtfulness so that the user is considering all necessary aspects of a successful inclusive instructional experience. These are not all the questions we may guide with, but we wanted to present some idea of what a user might need to `input` to prepare their lesson resource.

With **Section 3** we tried out a star rating system to see how it looks and functions as this will eventually be implemented for rating lesson resources.
:::

### **Section 6:** Differentiation and Time
- A toggle <i class="fa fa-toggle-on"></i> feature allows the user to set the types of differentiation considered as a part of the lesson. A `boolean` type will be used for each one.
:::info
**Next Phase Note**: Users will be able to filter their search results based on these `boolean` values associated to the lesson resource `object`.:mega:
:::

- We added an `input` field of `type` time so a user can set how long the lesson will take to teach in the classroom. This will also allow users to filter search results based on how long a lesson will take.

:::info
**Next Phase Note:** When the user finishes uploading or creating a lesson resource and hits the **Submit** `button` in Section 6, the inclu team is notified and will review for approval. Once approved, the user will be notified that the lesson is activated on the site for other users to see and use. As resources are approved, an info map (visual) on the homepage changes. Themed/topical visual bubbles will get bigger according to the social juctice values selected in Section 2 and based on how many resources the system has with those selected values.

In future phases we will implement a points system, the more resources a user creates, comments on and rates, the more points the user receives. Points allow for different levels of access to lesson resources. :mega:
:::

:::success
**What we learnt, what was challenging, how we think we need to improve, and what the next steps are for us and our learning!**

Thinking about how the data (values, inputs, types, etc) will eventually be used is important because it can change how we initially design or code. For example, giving users open text to type in an interest (versus giving them a list of interests to select from) can lead to problems with categorising resources or unclean data that's tricky to manage.

What we also found challenging here was finding elements that could be expressed using only HTML and CSS. Even though at the beginning this proved to be a little frustrating, it was very helpful in helping us understand the limits of HTML and CSS and the value of JavaScript, especially when working with Bootstrap. In this iteration we trialed multiple different ways users can input data. While this taught us a lot, we might opt for a simpler user interface in the future.

Throughout our coding process, we made an effort to understand how Bootstrap defaults addressed universal access through fonts, colors, and overall layout. While bootstrap V5 has the best user accessibility features, we found that button highlighting emphasized form over universal access (Bootstrap's defaults don't offer WCAG-compliant contrast when the user hovers over buttons). Admittedly, we found it challenging to understand some of these design principles (for example, the WCAG contrast standards and how they work) while learning initial code. Though this slowed our process, addressing these features from the ground up is essential in avoiding the too-often supplemental approach. With this in mind, we still have questions for future design accessibility. For example, how well do screen readers navigate the slider input range options we designed?

Continuing the theme of colour customisation, we never managed to figure out how to change the colour of Bootstrap user input elements like radio buttons, checkboxes, sliders, and toggles. We're not sure if this is an indicator of our inexperience or of shortcomings in Boostrap's customiseability - either way, this is an area for future research!

This system has many parts to it and each team member interestingly (and not surprisingly) wanted to focus on parts they may have either had some experience with or felt needed attention (i.e. visual appearance vs. the code iteself vs. the application design and use, etc). It's great to be part of a team with varied interests and expertise as this really helped us enhance parts of our UI and allowed us to consider many more affordances that our UI can provide for our users.

Ultimately, we want our users to have a smooth, streamlined experience where they can easily contribute or search for lesson resources or get support from the community on how to use those resources. Teachers don't always have the luxury of time on their hands so we hope to help by giving them the tools and support they need to build more inclusive classrooms.

:::