morea-framework / v2-core Goto Github PK

Support prerequisites, which are modules (typically from other Morea sites) whose learning outcomes are assumed to be achieved prior to beginning work on this module.

Prerequisites are a new, top-level entity like Module, Outcome, Reading, Experience, Assessment. Despite this fact, we will not rename the framework Pmorea.

See this posting for a method:

http://blog.parkermoore.de/2014/08/01/header-anchor-links-in-vanilla-javascript-for-github-pages-and-jekyll/

Provide first-class support for due dates. This means:

• In a reading or experience, provide a due-date yaml tag in the header.
• This due date shows up as a label.
• This due date is also input to a calendar page. Clicking in the calendar takes you to the assignment.

I am not sure whether this is fixable because it may be all about Jekyll, but I often find managing posts (master/src/_posts) a bit painful, especially because it seems filenames have to start with a date(?). I am wondering whether there would be a way to have a single file for instance, with all the posts in it. I just spend quite a bit of time editing posts manually and do make mistakes. Of course, some of us could develop an amazing ncurses tool to visualize posts ;)

This is not really a clear "issue" and if it's not even a MOREA issue then feel free to remove this :)

"Fyi, Jekyll 4.2.0 broke more for me. Reverting to 4.1.0 works. Not sure if anybody’s experienced that. The brokenness was the clicking on a module’s icon in the Modules view show a strange blank page."

When you view an Assessment from the Assessments tab the links to the outcomes assessed work.

When you view the same Assessment from the Module page the outcomes assessed links are incorrect and do not lead to a valid outcome.

Currently, a "local file" such as a reading gets published under the morea/ directory. For example:

 http://philipmjohnson.github.io/ics613s15/morea/introduction/reading-grading.html

However, that same module (introduction) is under the modules directory:

 http://philipmjohnson.github.io/ics613s15/modules/introduction/

A more uniform and easy to understand URL scheme would locate the local files "under" the module URL. So the first URL at top would look like this:

 http://philipmjohnson.github.io/ics613s15/modules/introduction/reading-grading.html

When Jekyll 3.0 is released (estimated Q1 2015), it will simplify installation and configuration of Morea, since Jekyll 3.0 will not require Python and will have a Windows installer.

There may be other advantages to Jekyll 3.0, but simplification of local installation is the primary win.

Use a ruby plugin to generate a .ics file in the schedule directory. People can then import this into their Google Calendar if they want to display events there.

Currently, labels come in one color. Multiple users have requested support for multiple label colors. However, label colors must be custom to each Morea theme. So, let's propose that each theme should provide three colors for labels, called label-color-1, label-color-2, and label-color-3. The YAML front-matter should be augmented to support a new syntax for labels:

morea_labels:
  - ["this is the label", label-color-1]

This syntax allows the user to explicitly specify the label color. Note that when you want label-color-1, you can use the traditional syntax instead. So the following is a shorthand for the above:

 morea_labels:
   - "this is the label"

You can mix and match:

morea_labels:
  - "my first label"
  - ["a different color label", label-color-2]
  - "another label"

Here's a couple links:

http://www.nytimes.com/2014/12/27/us/college-science-classes-failure-rates-soar-go-back-to-drawing-board.html

http://www.nytimes.com/2014/11/23/sunday-review/studying-for-the-test-by-taking-it.html

Cam discovered that Google Analytics can provide interesting information about how students use a site, such as how they traverse the various pages.

To simplify use, provide an option in the site's config.yml to specify the google analytics property tracking id.

Provide better support for navigation within a site:

http://getbootstrap.com/components/#breadcrumbs

One user complained that it was difficult to figure out where in a reading or module "pane" to click.

To solve this, make the entire pane clickable.

As I've gotten more facile with GitHub Actions, it's occurred to me that they create a straightforward way to simplify the use of the Morea Framework so significantly that it motivates a new major version number increment to 2.0.

The problem with Morea 1.0: managing the master and gh-pages directories and branches

Currently, setup of Morea sites is complicated by the fact that each site requires two local subdirectories, a "master" subdirectory (containing the source files and set to the master branch on GitHub) and a "gh-pages" subdirectory (containing the HTML, and set to the gh-pages branch on GitHub).  

Publishing a site requires you to run a script that runs Jekyll, then puts the HTML into the gh-pages directory, then commits both the master branch and the gh-pages branch. 

Here are some of the problems with this approach: 

• You need special, currently unix-only scripts to build and publish a site. 
• You need a run a script (morea-pull) to pull both branches, and you must do that before publishing.  Otherwise you are in danger of getting a large number of conflicts in the gh-pages directory in the case that multiple people are working on the same site. 
• Windows people have a very difficult time with Morea.  Maybe that should be "impossible time".
• Explaining this to new users is complicated.

The solution: use GitHub actions to build the site

Here's a simple change with profound usability impact: create a GitHub action that runs Jekyll and commits the HTML to the gh-pages branch each time there is a commit to the master branch.

This has the following implications:

• You do not need any special scripts for Morea. Instead, you download the master branch using the Git client of your choice. You run the system with a simple jekyll serve --baseurl ''. You commit (and publish) your changes using the Git client of your choice.
• You do not need multiple local subdirectories. You just have a directory containing your Morea source code (the master branch).
• For simple changes, you can go directly to GitHub and use the browser-based editor to modify a source file and commit it. In some cases, a user might be able to manage their Morea site exclusively through the browser-based editor and never have to install anything localy.
• The barrier to entry for Windows people is reduced.
• Merge errors are much easier to deal with, because they can only occur within the master branch. (GitHub Action execution is atomic and sequential, so gh-pages will never have a merge conflict if it's only written to by the GitHub Action).
• If there is a build failure, you will get an email from GitHub with a link to the Action log, which will indicate what failed.
• Users who want to push commits to GitHub (as a backup strategy) without triggering a rebuild of the page will need to use a branch-and-merge strategy. This adds a bit of complication for new users.

How to implement this change

The implementation should be extremely easy:

• Write the GitHub Action.
• Delete all scripts.
• Update documentation to explain the new workflow.

I am thinking Summer 2021. Seems awkward to do this during the semester. This would also be a reasonable time to do some maintenance upgrades (jekyll, bootstrap, etc.)

The current approach of cloning the basic-template and deleting its sample files creates problems when those later files have to be updated.

A better approach is to have a new repo, called "core", with an empty morea/ directory. Provide a sample zip file that novices can download with sample content for the morea/ directory.

Currently, linking in Morea sucks.

To solve this, implement a fluid tag that expands into the correct URL given the morea-id for the target object. For example:

 {% morea-link reading-grading %}

That way sites will display correctly with either http or https