---
tags: mstu5003, webapp, html, css, bootstrap, inclusiveteaching, socialjustice
---
# Final Project: inclu

Team: Nicole Aberg-Cobo, Michelle Avenant, Tina Keswani, Lucius Von Joo
See demonstration: https://codepen.io/lav2111/collab/WNZobZO?editors=1010

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

:::

**Phase I:** How educators (i.e. users) can create new lesson resources using the website.

Given the scope of this project, we have decided to focus on just one page in this platform: the "Prepare My Lesson" page whereby users can create lesson plans to add to the website's directory. This page also serves as a resource for helping teachers (particularly those new to creating inclusive, social justice-focused lesson plans) think through the various elements their lesson plans need to include.

Future development phases will include:Homepage design, community aspects such as collaboration and discussion (via creating user accounts, message boards and comments sections for each lesson plan), and levels and badges to signal users who have contributed significant resources and spent significant time on the site, and could therefore be considered "experts".

:::info
:information_source: For our Final Project **(Due Dec 19th)** we continued to build out **Phase I**, the user creation of a lesson resource with more complex bootstrap, css and javascript concepts and functionality. In looking at our page, we initially thought each section would be its own page, but decided on the accordion format so users can quickly move between sections.

In addition, our example takes the title and sections 2 through 6 (**not section 1)** data and SETS it to the bottom of the page in what we called a lesson template. Eventually this would be SET in a database as well as display on a final "confirmation" page for the user to see their full lesson in a template and download or print it if they wish to. We would also look to abstract into a single function what our current functions repeat for each section (i.e. have all Next buttons call the same function), perhaps a function that gets the users inputted data and pushes a complete lesson `object` in the lessons `array of objects` all at once when the user submits.

Lastly, we were able to `push` some of the user input as an object into our lessons array with the `addLesson` function.

**Please note** :mega: The **Next** button must be clicked in each section (even though it currently does not take the user to the "next" section) so that the functions are called. The **Submit** button in section 6 is the final button to click which displays the bottom template.
:::

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

**Codepen: https://codepen.io/lav2111/collab/WNZobZO?editors=1010**

Using Bootstrap's framework for `CSS` , a form has been created using the [accordion flush method](https://getbootstrap.com/docs/5.0/components/accordion/) 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 one of which is `form-control` which allowed us to have clean size, colors and display text in inputs.

In our [original Web App UI](https://hackmd.io/BGr51Dn6SAuVREJu08d16w?edit) (lines 31-46) we gave the user a file upload option on the top so they can circumvent having to go through the process of creating a lesson if they already had one ready. In rethinking this, with data integrity in mind, we want users to create all lessons through **inclu's** interface so that each lesson in the system has consistent data that we can use for display and searchability purposes. Instead of being able to upload a completed lesson plan, we allow them to upload supplementary material at the end (see section 6 where they can upload a file).

In the following sections, we have detailed significant changes we have made to the interface in this project.

### **Section 1:** Tagging classroom interests and accommodations (to be associated with the lesson resource)
We initially had rows where a teacher would input a lot of text for each of the students in their class, but instead we moved towards multi-selects for collective interests and accommodations (again thinking about data integrity). This allows users to select multiple values from from pre-defined lists and hence lesson objects can be SET with consistent properties (Learning Profile, which was part of the original Web App UI, was removed since this is unique to a single student).

Functionally, streamlining the interest and accommodations tags users selects will help determine how lessons are consistently stored and retrieved. The Inclu system is not only a guide for teachers to address key elements required in lesson design, but also will serve as a resource library, browsable by specific properties, for fellow users to access.

However, in the interests of flexibility and inclusivity, we added a large text entry area for teachers to submit options that they feel are missing from the predetermined pull-down list. These added terms can eventually be reviewed by the site adminstrators on the back-end before adding necessary tags to the multi-select list, growing the library's bank of terms.

- In JavaScript terms: each lesson resource `object` will have one or more `attributes` within **Interests** and **Accommodations** associated with it. An `array` of `string` `values` for each of these categories will be established. What the user selects is associated as a `property value` with that lesson resource `object`.

:::info
:information_source: We tried to initally use a html/css/javascript package that was loaded to design the dropdown so the selections appear as "tags" when you select them.
However, this conflicted with the Bootstrap format and interfered with the accordion functionality, so we changed this to a Bootstrap-friendly multiselect tool.

:::

- 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 and accommodations are associated with that lesson resource `object`.
- Clicking the **Next** button will take users to the section of the 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** and **Accommodations** `array of values` could appear as `labels` wherever the lesson resource `object` is displayed with different (but accessible) `color` `attributes` . (For example, chosen values for **Interests** could be in blue.)
In addition, the Next button would open up the next part of the accordion, but in this example it does not. In researching how to do this, only jquery examples were available. We are also debating on whether the Next button for each section of the accordion is necessary. However, we do ultimately want users to definitively make selections, and the Next button also serves as a checking mechanism for null values.:mega:

:::

### **Section 2:** Choosing social justice topics and setting familiarity and comfort levels
This section applies javascript concepts on a click event of the Next button to trigger the function call to addTopic(), which uses the querySelector to select the checked topics. It first checked to see that something is selected; if not, the alert function asks the user to choose at least one issue. It then loops through the checked issues and forms an `array` building `list items` in a string of html that will display once the full form is submitted (from section 6)

<button class="btn btn-primary col-md-4 mb-6 mt-3" onclick="addTopic()">Next</button>

function addTopic() {  
  var checkedIssues = document.querySelectorAll('input[type="checkbox"]:checked');
  console.log(checkedIssues);
  if (checkedIssues.length == 0) {
    alert("Please choose at least one issue")
  } else {
    let issueListHtml = "";
    for(let issue of checkedIssues){
      issueListHtml += `<li>${issue.value}</li>`
  }  
    console.log(issueListHtml);
    listTopic.innerHTML = issueListHtml; 
  }
}

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. **This is for display only. These don't get SET at the moment so selections will not print to the console**

:::info
**Next Phase Note** (from original HackMD for Web App UI): 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 plan applies sufficient rigor and thoughtfulness, ensuring the user is considering all necessary aspects of a successful inclusive instructional experience. These are not all the questions we may ultimately guide users 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` for 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` at the end, applicable data that has been selected in sections 2 through 6 will be displayed below the form for now. Eventually this would be its own confirmation page so the user can review what they inputed and download or print their lesson plan.
:::

### CSS
The increased functionality of this iteration of the page - particularly as it pertains to using JavaScript - has presented increased instances in which custom CSS can be used. This is particularly relevant to colour palettes, which are not only an aesthetic element that enhances UI but an important factor for accessibility.

It is worth noting - and critiquing - that Bootstrap's default blue colour palette for features such as clicked accordion buttons (see [this page](https://https://getbootstrap.com/docs/5.0/components/accordion/) for reference) garners a WCAG compliance (visual accessibility) [rating](https://https://snook.ca/technical/colour_contrast/colour.html#fg=2971E6,bg=E7F1FF) of "sort of".

In contrast, the colour palette we chose - particularly the yellow and indigo combination for when buttons are hovered over or clicked - is rated as fully accessible using the same metrics.

Thus, **this project's colour customisation via CSS provides an integral accessibility functionality for this site: it is not just for aesthetic flair.**

This being said, we have learnt in this process that customising the colours of Bootstrap input elements is tricky, and so we have not managed to complete this task as thoroughly as we would have liked to. However, this frustrating process has given us important insight into the visual accessibility issues Bootstrap presents as a web design tool.

### Shelved for now: Tooltips
One aspect we wanted to add to this project was tooltips for users to hover over so they could gain more information about an aspect of the form if they didn't quite understand what was required of them.

We attempted to build tooltips into the page via CSS, as demonstrated [here](https://https://codepen.io/msa2218/pen/MWEjBay?editors=0100), but found that these were incompatible with our existing page, especailly in the accordion sections.

Although frustrating, this gave us insight into some of the limitations posed by Bootstrap, especially when trying to combine different interactive elements. We would like to find ways to solve this problem in future iterations.

### Javascript: a big challenge
Incorporating functions to our project was harder than expected. The first struggle began with understanding how to print content that was not a text input. Once we understood that, with help from David Zikovitz, we were able to print out all content in sections 2 through 6.
Section 1, being a multiselect turned out to be even more difficult to printout and that is why we did not manage to print it out.
When pushing the user input into the array, we had trouble getting the values for checkboxes.

:::success
**A summary of the application experience and how it addresses the defined problem**

With this final project we built upon our web app UI and made it more functional. The UX was changed to an accordion format for ease of navigation. A carefully-selected colour palette was uniformly applied to give the page visual continuity and aid visual inclusivity. The layout changed to reduce custom data input, reducing unnecessary work for back-end data managers and ensuring more data integrity. Functions were added to grab inputted data and display it in a template for use by the creator and other site users.

**Reflections on what we've learnt this term**
The pacing of this course was effective as it built upon more and more complex topics at a manageable but challenging rate. From an interactive perspective it has been very helpful to see how all three aspects of basic web coding (html, css and javascript) interact with each other. Some of us had better understandings of one of the aspects (whether it be html or css or javascript), but getting a more in-depth look at how setting and getting occurs when you define elements a certain way (with ids, classes, etc) and how these can be modified really made us understand not only coding aspects but designing aspects in terms of programming logic and data.

As we built our understanding of how data is used in these contexts, we learnt to think about how best to gather, store, retrieve and use data in the context of web programming - which might be quite different to how we intuitively think about it as humans (our minds are quite different to the "mind" of a computer).

When researching new ways to do things, we gained practical experience of how developers do use concepts in different ways to get the same results (looping is an example of this), but we also found that understanding more complex topics might actually make things easier or more efficient to code in the future (i.e. databases or things like jquery). This also gave us insight into the role of the programmer, as there are so many different ways to approach problems and configure the system, even if the front-end result appears the same.

It was also interesting to think about our applications from a user experience perspective. Sometimes we just want the code to work and aesthetics are fairly unimportant. In other instances, visual elements like colours play an important role in making the site visually accessible and helping the user navigate through it (for example, by displaying "submit" buttons in different colours or with bolder outlines when they have been clicked). We have so much more to learn regarding the psychology of user experience and the role that resources like CSS can play in this.

We also learnt to appreciate the importance of consistent semantics not only for computing purposes but so that different programmers can understand each other's intent in design, data, form, style and function.

:::

:::info
**Future Possibilities for this web page**
There are still lots of improvements we could make to this page to aid navigability and increase its functionality, for example:
- A progress bar could reflect how far a user is through the lesson planning process: https://getbootstrap.com/docs/4.0/components/progress/
- Increased colour continuity: Many Bootstrap elements (for example the checkboxes and sliders in section 2) are not amenable to simple colour changes via CSS coding and we have yet to find ways to accomplish this at this time. This prompts further research into how (or whether) we could customise the colours of these elements in the future.
- Tooltips could help clarify some of the questions users are asked.
- Debugging: Our page would benefit from debugging to catch existing bugs and tackle other errors in the code that could affect its performance if it's further developed in the future.
- User testing: While we are a team of seasoned educators, intuition alone is not the best guide for building an app that users can navigate easily without external guidance.
- Using Javascript to print out other types of user input, different than checkboxes or text.
- Using arrays and objects in Javascript to create a "database" (or what would turn into one) of user input.
- We ask for certain types of data from the user in this version that do not print our anywhere; other interests and accommodations, familiarity and comfort with topic, importance of objectives time, possible file upload. These will in future versions be analyzed at the back-end and used as tags for lessons or new information to be included in inclu.
:::