TL/DR

• The user MUST be able to create notes on an OER (high priority)
• The user SHOULD be able to create notes on arbitrary fragments (future release)
• "Too hard for me" etc could be implemented as human&machine-readable notes
• Notetaking supersedes bookmarking
• Topic-specific notes are also conceivable. Perhaps as an extension or separate feature.

User stories

As a user
When I inspect an OER
In order to later come back to the OER (or fragment thereof)
I want to create a written note

As a user
Given that I have notes
I want to see a list of all my notes

As a user
When I inspect an OER
In order to use my notes
I want to see all my notes that pertain to the current OER

As a user
When I see some OER cards
In order to know which ones contain notes
I want to see an informative icon on the card

Task

• Enable basic note-taking per OER, by copying the diary feature from previous prototypes
• Rename the "bookmarks" page to "notes"
• Make the notes page show all the notes chronologically, along with OER title and date

Future work

• Ask the user for confirmation before deleting a note
• Allow the user to select a fragment
• Add a handful of one-click preset notes, e.g. "too hard for me"
• Consider adding recommendations per note
• Allow the user to reference wikitopics in a note
• Allow the user to reference other users in a note (e.g. sharing journeys, tutoring etc)
• Allow the user to reference other OERs in a note

Ensure that user passwords are encrypted

In order to update the user's TrueSkill profile
The backend needs to know the start and stop positions from the video player

As a user
when I start typing into the search field
I want to see dynamic suggestions of wiki-concepts, based on auto-completion
Similar to the search field in wikipedia.org

Pro

• reduce the typing load for the user
• reduce the problem of "no results", by encouraging the user to use search terms that are covered by wikipedia
• adhere to common UX principle

Currently, the description below the video looks a bit daft and it's difficult to read.

Tasks

• Add line breaks
• Limit the height. Use scrollbar if necessary

Create the relevant backend api to receive a set of wikipedia entities and serve back the local knowledge graph

As a participant in the first user study
I don't want to see any placeholders, coming-soons, or greyed-out links to features that haven't been implemented yet.

TASKS:

• implement some of these features as practical and useful for the first user study
• hide the other features from the user

As a user
When I hover over the title of an entity (e.g. "Linear Regression")
Regardless of where I am on the site
I want to be able to do something with that entity, e.g.

• define
• mark as known
• test me
• etc

This should work within chunks and also in other places, e.g. trueskill overview etc

As a user
When I see an OER (or a set of OERs or a pathway) that buddies of mine travelled recently
In order to feel connected and in touch with their progress
I want to find useful traces and notes they left for others who are travelling in a similar direction

Reciprocally...

As a user
When I make progress on OERs
In order to feel connected and show my progress to fellow travellers among my buddies
And in order to retrace my own journey
I want to leave useful traces and notes

Design challenges

Getting this right will likely involve:

• Providing full transparency without overwhelming the user with information
• Leveraging a mix of graphical and textual information
• Testing with several groups of real users

This task is to implement user login feature of the x5learn dashboard

Create a Wikipedia graph database in the back end

Tasks

• change password, forgot, reset, confirmation, etc.... i.e. the entire templates folder

As a user
When I go to any page on the site with a small screen (mobile) device
Given that the site is not yet optimised for small screens
I want to see a message that explains that I need to use a laptop/desktop computer to use the site.

When scrolling through the list of search suggestions, it happens easily that an item is selected by accident, which changes the search text and things get confusing.

Solution: Make it so that hovering highlights the suggestion but the search text doesn't change unless the user clicks.

It might be worth setting up a queue to automatically "wikichunkify" the OERs that were found by users.

Details tbd

As a user
When I go to the history page
In order to get an intuitive view of the fragments I watched/read
I want to see them in chronological order
And I want to see the most recent ones at the top

Tasks

• Change the current grid layout to a single column
• Add a "load more" button when needed
• Consider grouping/separating the fragments by date, using headings. E.g. similar to the browsing history in Google Chrome

Current status

• The user can only search for wikitopics
• Results are limited to our selection of 6000 wikichunked youtube videos (CSV file).

Goal

• The search should also return results for matches that aren't wikitopics, e.g. similar words in the title, description or transcript.
• Results should also include OERs from X5GON, despite the fact that (a) they haven't been wikichunked and (b) they cannot generally be embedded, due to the diversity of formats (even within videolectures) that would require too many different players than we could currently manage.

Tasks

• Reactivate the existing code for delegating searches to the X5GON API.
• For non-youtube results, replace the embedded player with an external weblink (new tab)
• For non-youtube results, replace the "play" icon with a "web" icon

Notes

• We can keep all the search functionality that is specific to wikitopics. Particularly, the autocomplete suggestions and the yellow highlights.
• We can discuss whether wikitopic matches should be ranked higher than matches in e.g. the title or description.

As a user
When I see a topic in a chunk
I want to see at a glance what the system thinks about my knowledge and interest in this topic
And I want to change this if needed

Current implementation and problems

Our current version (see issue #26) provides a table with a number for each topic, representing the amount of the user's exposure to information about this topic, as measured by activity on our platform. This is a good start but there are considerable weaknesses:

• Amount of exposure is a weird metric. Its practical use for the learner is doubtful.
• The measurement doesn't take into account the learner's activity outside our platform, including prior knowledge.
• The table data cannot be changed by the user.
• The table is detached from what the learner is currently looking at.

Proposed redesign

What if each topic in a chunk had an icon next to it, representing the user's level of knowledge, e.g.

• low
• normal
• high

Similarly, a second icon should represent the user's level of interest in the topic.

Both icons should be interactive

• perhaps via keyboard shortcuts, e.g. "k" for knowledge and "i" for interest?
• perhaps medium priority

Tasks

OER Inspector modal

• When clicking on a topic, play the video at that point and add a widget next to the video player, allowing the user to set their level of knowledge and interest. Yvonne suggested using sliders for this - probably the best choice, I agree.
• Add to the widget a field for comments (note to self / share with peer)
• Add to the widget some kind of way for users to get recommended fragments on that topic in other OERs, in other contexts, based on level of knowledge and interest. This could be through a list of recommendations (e.g. explain this with puppets, explain this with animals, etc) or buttons like "too hard for me" / "too easy for me"

Knowledge profile page

• Include knowledge and interest in the global table of topics
• Consider useful options for sorting the table
• Consider how the system might fill in missing data e.g. by inferring from similar topics, or simply setting everything to "normal" by default
• Consider how the user can visually distinguish between self-reported and system-inferred values, e.g. using different colours or icons

Topic in the chunk

• Add sliders in the submenu of each topic (e.g. underneath the definition)
• Consider adding dynamic icons (for knowledge and interest) next to the title of each topic

Caveats

• For every element of the interface, it must be clear (to us and to the user) whether it pertains to the topic in general (as represented by its wikipedia article) or to the specific mention of the topic in the OER (e.g. as represented by the fragment of text/transcript). We need to design this carefully.

When using the chunk hover menus,
the drop menus sometimes exceed the right screen edge
or the bottom screen edge.

see here:

https://stackoverflow.com/questions/11512032/detect-if-dropdown-navigation-would-go-off-screen-and-reposition-it

Tasks

Bottom edge

• simply add more bottom padding to the cards grid

Right edge

• open the submenu on the left instead of right when close to the right screen edge

This issue is purely frontend-related.

I need to refactor how the popup menus (e.g. when the user hovers over a chunk) are rendered in the browser.

Currently, the menus are children of the button that triggers the popup. I chose this solution during early prototyping because it was quick to implement while keeping the code clean and simple. For the purpose of testing whether popups are a good idea, it was the best solution. However, it isn't suitable for production because it causes some popup content to be rendered behind other content.

For the production-ready solution, my strategy is to:

• structurally decouple the button elements from the menu elements
• render menus in a separate layer above the regular content
• add some logic to ensure that the correct menu is rendered at the correct position
• position the menus smartly with respect to the trigger buttons, surrounding content and window borders

As a user
In order to persist my state and get personalised information and control my data
I want to log into my account

Current solution

In the current Elm implementation, each Fragment contains the OER data it pertains to.

type alias Fragment =
  { oer : Oer
  , start : Float -- 0 to 1
  , length : Float -- 0 to 1
  }

This implementation is neat in the sense that it keeps the frontend code clean and simple. However, it makes the Fragment type less suitable for use in client-server communication, as Oer data can be large.

Better solution

A more network-friendly solution would avoid storing the entire OER in the Fragment and instead use only its URL.

type alias Fragment =
  { url : String
  , start : Float -- 0 to 1
  , length : Float -- 0 to 1
  }

Pro

• better network performance when dealing with large OERs and/or many fragment-wise recommendations

Con

• increased complexity in the frontend code, as Fragments and OERs must be loaded and managed separately.

User story

As a user
When I see a card that represents a text-heavy OER (e.g. video lecture on Youtube)
In order to quickly see the top 5 concepts that the OER is about
I want to hover over the card and see something like a tag cloud replacing of the thumbnail

Motivation

The idea came from someone who saw the latest demo video. I thought it's worth a try.

Initial thoughts on design

• The cards are small, which limits the font sizes we can use, and the number of items per card.
• As a first start, I would keep it very simple and keep the font size fixed. No rotation either as I'm concerned about accessibility. So it'll just be a list.
• I assume that each tag is a wiki entity. (Any better ideas?)
• How do we choose the top 5?
  • by number of occurrences (chunks) in the OER
  • by inferred urgency for the learner (list of interests? prerequisites?)
• How might we use colour or brightness to indicate useful features for each tag? Initial ideas:
  • Grouping tags by colour
  • Colour to indicate inferred relevance to the user (interest / urgent prerequisite / ..?)
  • Brightness to indicate the relative amount of text dedicated to that particular tag, e.g. proportion of chunks on the topic divided by the total number of chunks?

Strategy

This should take less than an hour to prototype in Elm. I'm going to build it quick&dirty to see how usable and useful this would be. We can then show it to the team and get their feedback. Happy to throw the idea away if we decide to hate it.

Going crazy

Here is a really wild idea:

• Consider the rectangle that holds the thumbnail.
• Hovering near the top edge: tag cloud for the whole OER.
• Hovering near the bottom edge: tag cloud for a particular chunk (depending on horizontal mouse position).
• Anywhere in between gives you a tag cloud for a range of chunks (window width increasing with higher mouse position)
  Smells like a CHI paper?

Our current title image (mountains) is this:
https://pixabay.com/photos/rough-horn-alpine-2146181/
At the time of writing this, the license label says: "Free for commercial use, No attribution required".

I've only heard positive feedback so far. However, Yvonne thinks we can do even by making it something with animals that symbolise curiosity. E.g.
https://stock.adobe.com/gr_en/images/three-dolphins-close-up-portrait-underwater-while-looking-at-you/119968154

As a user
When I click on a chunk
I want to be taken to the corresponding minute in the video
(or page in the text, respectively)

As a user
When I am logged in
In order to log out
I want to use the typical menu on the right side of the page header (avatar icon)

As a user
When I type something in the search field and press submit
In order to see where exactly my search words occurred
I want to see the corresponding chunks highlighted in each OER

Let's come up with a good pipeline for unit / integration / acceptance testing

e.g. CircleCI hooks nicely into github, preventing PRs to be merged if tests fail.

In the current implementation, the Wikipedia definition is accessible by hovering into a sub-submenu and clicking on "define".

Arguably, the use of sub-submenus for this purpose is a bit bizarre. It requires precise aiming with the mouse. Besides, the click is unnecessary.

A smoother solution would be to include the definition directly in the submenu (rather than sub-submenu).

As a user
When I see a number of search suggestions
In order to quickly select an option
I want to traverse them using the arrow keys (up/down)

Notes

• Using the tab key already works, due to default browser behaviour. However, some users are used to using the arrow keys, as offered by many modern web applications
• A quick fix should do for now. A later solution might include a bog-standard, out-of-the-box search widget, e.g. based on elastic search

Task

• Change browser focus based on arrow key events

As a participant in the first user study
When I search for material
I only want to see CHI presentations
And no other material such as Open CourseWare etc

If we track anonymous users via cookie, there should be a standard banner.

Some design inspiration:
https://cookieconsent.insites.com/demos/

As a user
When I click on a topic in a chunk
Then I want the video to play from the corresponding position

Note

Consistent browser support requires embedding via iFrame API
https://developers.google.com/youtube/iframe_api_reference

Tasks

• Use iFrame API to embed videos
• Ensure this works on OER cards
• Ensure this works with open videos, when paused and when playing
• Test in Chrome and Firefox

As a test user trying out the interface prototype
When I go to a subpage whose functionality hasn't been implemented yet (e.g. Notes or Peers)
I want to understand that this part of the site is work in progress and that there is nothing to see here yet

Task

• Put a placeholder in for each subpage. At least something generic like "coming soon"
• Disable the links to these subpages in the navigation drawer

As a user
In order to refresh my memory, backtrack, reflect, revise and keep track of my learning journey
I want to see a detailed history of my actions.
Or would I rather want a summary of content or information that I saw recently?

Questions

I wonder...

• Are "history" and "recent items" separate concerns or two versions of the same thing?
• If they are separate: Does the user need them both or is one enough?

Options, pros and cons...

See the comment in issue #44

Tasks

• Add links to page header: signup and login / logout
• Distinguish logged-in and anonymous users
• Prettify the templates for signup and login, including a page header that looks similar to the main application.

As a user
When I type in the search field and press submit
And the search returns no results
Then I want to see a message saying there were no results

Conceivably, our frontend could directly call wikidata.org to get the names of entities. Example:

https://www.wikidata.org/w/api.php?action=wbgetentities&props=labels&ids=Q170063|Q180481&languages=de

It seems possible to call the API from the browser, using Cross-site requests. Particularly, using the JSONP method:

https://www.mediawiki.org/wiki/API:Cross-site_requests#JSONP_usage

Pro

• Multilingual results for the user
• Less work for our backend
• Less implementation work for us developers

Con

• We don't know how their API responds to frequent, large requests.
• Do we need to use preloading carefully, in order to prevent users from getting temporarily blocked?
• Would less preloading cause noticeable lag in the UX?

Currently in the code

app.config['DEBUG'] = True

I suppose this should be an environment variable. @sahanbull your opinion please?

As a user
When I revisit the site
I want to see my current state as I left it last time

Tasks

• Persist the user's name in the user profile
• Persist the user's notes and history in the user state
• Store the user state in the user_login table (for logged-in users) or a guest_user table (for non-logged in users)
• Manually test the key use cases in the browser

Future work

• Thorough and automated testing
• Persist viewed fragments in history (Issue #76)

As a user
When I have interacted with the system for a while
I want to see an overview of what the system thinks I know

Immediate task

• add the simplest and quickest solution that could possibly
  • create value for the user
  • give us feedback on how to improve (MVP approach)
• as a start, let's create a table: clear and unspectacular

Long-term strategy

• Let's prioritise transparency now, flashy looks later
• Let's explore UX solutions while developing the backend logic and representation
• Let's explore different types of visualisation: Table, tag cloud, concept map, 3D landscape, ...
• Let's make the next version interactive

As a user
When I see an OER card
Then I want to get a visual sense of how the key topics relate to each other.

Currently, we are using the upper part for just black text on white background. This is fine but there might be potential to use the space for more informative graphics. For instance:

• Clustering of main topic(s) vs examples
• Where do the main topics occur in the timeline?
• Putting the main topic in context with subtopics and broader topics
• Highlighting the sections we predict will be most valuable (interesting, rewarding, satisfying...) for the user

It would be nice to experiment and see what is most useful.

This function is to add the password recovery using email address

As a frontend developer,
In order to iteratively implement and test some of the use cases in scenario 1 (too hard for me, etc)
I need some kind of fictional protagonist, i.e. a dummy user.

Ingredients

The dummy user needs to have the following:

History of watched content

• must be plausible in the context of scenario 1
• can be made-up. No need for "real data"
• should be "frozen" and easy to recall during repeated tests

Something like a Trueskill profile

• probably necessary for generating pathways
• not sure yet how to represent or fake this effectively. Hopefully, the choices will become clear during prototyping

Implementation

For now, I'll be happy with the simplest possible solution:

• hardcoded
• implicit in canned server responses

Later steps could be:

• explicit data structure (e.g. singleton class or dict) to represent the dummy user
• multiple dummy users that I can easily switch between to test different stages or use cases
  • e.g. by changing a variable in the backend
  • or by logging in as different dummy users
  • dummy users can represent different stages or decision points in same scenario
• at that point the data structure should be clear enough for us to narrow down on a database schema

As a user
When I see a topic in a chunk
In order to later come back to the topic (or to the fragment, or to the oer)
I want to create a note

As a user
Given that I have notes
I want to see a list of all my notes

As a user
When I see a resource that contains notes
I want to find the notes in the timeline and in the chunk dropmenu
And I want to access the details of the note (in order to comment or delete the note)

Tasks

• In the chunk dropmenu, when the user clicks on "Add note" under a topic, a note icon should appear on the OER's timeline, indicating that a note exists at that position.
• On the notes page, the user's notes should be shown chronologically as a vertical list. Each item should at least contain the OER card (with the position of notes highlighted), a free-text field for comments, and a "delete" button.
• Optionally also: a multiple-selection list (checkboxes) of topics that the note pertains to. The list should be editable, allow null, and contain an "other" field. Default should be the topic through which the note was created.
• Optionally also: an editable range (fragment) that the note pertains to. Default should be the chunk in which the note was created.
• Optionally also: a checkbox "Notify researcher" (for the initial user study)
• In the chunk dropmenu, every topic that a note pertains to should have a note icon next to it. Pressing the icon should take the user to the notes page and show a filtered list of notes pertaining to that topic. As a matter of good UX practice, the user should be able to remove this filter, e.g. using a button "show all notes".

Future work

• option to share a note with specific peers. Perhaps this could become the key mechanism for users to share journeys.

Page Previews

Since our UI relies a lot with Wikipedia entities, wouldn't it be nice if our UI offered page previews like they now have on the Wikipedia website. A quick Google search revealed a variety of existing solutions for implementing previews of Wikipedia pages in other pages. None of the implementations I found are trivial.

TL;DR

It's tricky to implement. Let's test whether people really need this. The current solution (short text descriptions in popup) isn't very fancy but works for now and might even be sufficient in the long term.

Testing desirability

We should test whether our users would actually appreciate such a feature before jumping to solutions. Asking some test users won't hurt.

Current state: Descriptions from Wikidata

Currently, our UI doesn't offer page previews but it does offer descriptions of entities, available through the popup-megamenu. We get these entity descriptions (along with the names of entities) from the Wikidata API. The descriptions tend to be very short, which is nice for the purpose of including them in the wiki-chunk popup menu. Based on initial self-observation, descriptions can occasionally be useful for disambiguation (e.g. which John Cage are they talking about?) or to refresh the learner's memory. However, they are sometimes too brief and incomplete to function as proper definitions of an unfamiliar concept. Besides, some entities appear to have no description.

Get content from Wikipedia

Presumably, it might help users to get proper definitions or content summaries similar to the popups on Wikipedia. To implement something this, I see two options:

A: Build our own previews

We could to call the Wikipedia API, in addition to the Wikidata API, in order to get text (multilingual) and images (if available) as they appear on the page. These posts explain how:

https://stackoverflow.com/questions/8555320/is-there-a-clean-wikipedia-api-just-for-retrieve-content-summary

https://stackoverflow.com/a/43748047

B: Use an off-the-shelf solution

I won't list all the options here because we should test desirability first and clarify requirements if any.
Besides, Wikipedia page previews are a fairly new and hot topic. More solutions might become available while we're testing and working on other stuff.

Apparently, some users like to click the "magnifying glass" icon, rather than pressing the return key.

# Task

• make the icon clickable - same function as pressing return

Feature description

As a user,
When I see the name of a concept that interests me (e.g. Linear Regression)
In order to find it again when I have time
And in order to get better recommendations (more about this topic)
I want to put it on my radar.

See screenshot:
https://monosnap.com/file/J79teUO6YJXTNLLXJbDuhimxlKqitj

Similarily,
When I see the name of a concept that I know well
In order to get better recommendations (less about this topic but maybe more about follow-up topics)
I want to mark it as mastered.

How might this feed into the TrueSkill profile?

My understanding is that:

1. In order to give helpful and satisfying recommendations, we'll need at least these two dimensions for each topic:

• familiarity: to what extent has the user engaged with the topic in the past?
• interest/intent: to what extent does the user want to engage with the topic in the future?

2. The above feature seems like a simple, efficient and user-friendly way towards transparent recommendations. Any better ideas? Let's discuss