My Lifelong Learning Lab - High-Level Design Document

Thu Aug 4 13:58:31 UTC 2016

Thanks Tony – yes, I see the issues you highlight with the installer (which I can fix in my fork of the CA dependency & will do as part of the refactor to start using gpii-handlebars). Whoops (this is one of several reasons that code is only in a personal repo right now…)

Will definitely have a look at the other gpii projects you highlight below, and I'd like to join any discussion about *ouchDB that's currently going on. It would be great if we could align on things like user management where it makes sense to do so, especially since some of the My3L work is intended to be used in APCP. When are those meetings taking place?

As a side note, my go-to on a UNIX-type system for serving static sites locally for testing / development / demos is python -m SimpleHTTPServer portNumber from the root directory – this works reliably on any UNIX-type environment that has Python installed, including Mac OS X, gets around the XMLHttpRequest issue, and all in all is a reasonable facsimile of what it's like serving the project from nginx or Apache without actually having to go through setting those up.

Alan

From: fluid-work <fluid-work-bounces at lists.idrc.ocad.ca<mailto:fluid-work-bounces at lists.idrc.ocad.ca>> on behalf of Tony Atkins <tony at raisingthefloor.org<mailto:tony at raisingthefloor.org>>
Date: Thursday, August 4, 2016 at 4:04 AM
To: Fluid Work <fluid-work at fluidproject.org<mailto:fluid-work at fluidproject.org>>
Subject: Re: My Lifelong Learning Lab - High-Level Design Document

Hi, Alan:

I tried out your repo.  I wasn't able to successfully run npm install, as the chart authoring dependency fails to install.  I suspect it's because grunt and its plugins that are used in your post install step within that package are dev depencies and not plain old dependencies.  Thus, they are not available for the postinstall step within the chart authoring dependency itself.  You might not see this if you have the required packages installed globally, but it fails at least for me in OS X, and in my experience will also fail in CI environments.  It's worth addressing (for example, by moving the required dependencies to the main block).

I also don't tend to have anything lying around to host content, and that's required to work around the file:// sandboxing of XMLHttpRequest calls in Chrome.  So that I could try out your work, I threw together a quick harness based on gpii-express that will host all your content:

http://pastie.org/10929289

If you save that to the root of your package and install gpii-express and infusion as dev dependencies, you'll have a standalone server for demo purposes.  As the current gpii-express code is not merged and published yet, you'll want to use a command like the following to install it:

npm install --save-dev git://github.com/the-t-in-rtf/gpii-express#2f224862730bca57fa1f036f24f26e1d43748419<http://github.com/the-t-in-rtf/gpii-express#2f224862730bca57fa1f036f24f26e1d43748419>

Once you register your module's content using fluid.module.register, the above can be made to use package-relative paths and moved somewhere more appropriate.  Of course, if your tests are better suited for testem, you could also use that to host your demo content by just adding a testem.json configuration file.

With those bits of initial setup out of the way, I was able to try out your work.  I can see a few areas where at least some of us should get together, for example:

  *   user management: This is something I know Simon and Cindy are busy with already, and I've done a lot with local user management.
  *   CouchDB and/or gpii-pouchdb:  Antranig, Cindy, Simon and I have been talking through some of these issues each week, I suspect you might get something out of those meetings.  It sounds like you'd also be interested in more advanced topics than we've hit yet, for example, views, and full text searching.
  *   Other tools to try:  We've already discussed gpii-binder and gpii-handlebars, but we should talk through whether and of the following might also  be of use:
     *   gpii-pouchdb: as a replacement for CouchDB in tests and demo instances.
     *   gpii-pouchdb-lucene: provides test and demo integration of Lucene and gpii-pouchdb.  If you need full text searching at all, it could be of use.
     *   gpii-location-bar-relay: Allows you to bind particular variables to the browser state and location bar.  I'm imaging you would use this with your navigation controls, so that (for example) a user who navigates to yesterday's timeline and hits "back" in their browser will come back to today.
     *   gpii-webdriver: Real world browser testing, including full keyboard navigation and browser state (i.e. hitting the back button) testing.

As I've mainly mentioned each of these in passing in various meetings, I'm happy to arrange a demo and Q & A session for any that are of interest to you or the wider group.
Anyway, exciting stuff, keep in touch as you make progress, I'm excited to see how it goes.

Cheers,

Tony

On Wed, Aug 3, 2016 at 8:17 PM, Harnum, Alan <aharnum at ocadu.ca<mailto:aharnum at ocadu.ca>> wrote:
I'd like to draw the attention of the Fluid community to a new document on the wiki at https://wiki.fluidproject.org/display/fluid/My+Lifelong+Learning+Lab+%3A+High-Level+Application+Design+Document

This is a high-level philosophical/technical document intended to help shape the development activities of the My Lifelong Learning Lab (My3L) project, which has emerged as part of the work on Floe preference exploration and self-assessment (https://wiki.fluidproject.org/display/fluid/%28Floe%29+Preference+Exploration+and+Self-Assessment), as well as starting to build self-assessment components for the APCP metrics project. While we've sometimes referred to this work collectively as a "dashboard" project, this has been largely because it's been the closest shorthand for what we want to achieve, which I think is something rather more expansive.

At the moment the document represents my attempt to grapple with the development side of the larger space being explored by those working on the project (my existing development exploration along these lines can be found in the repository at https://github.com/waharnum/learningDashboard/tree/FLOE-455). I think it's quite a big, exciting space to explore, and an opportunity to pursue some of our interests in end-user computing in a targeted way.

I'd very much like to hear the opinions of the community in general about both the document's general philosophical direction and specific technical recommendations.

-Alan

ALAN HARNUM
SENIOR INCLUSIVE DEVELOPER
INCLUSIVE DESIGN RESEARCH CENTRE, OCAD UNIVERSITY

E aharnum at ocadu.ca<mailto://aharnum@ocadu.ca>

OCAD UNIVERSITY
100 McCaul Street, Toronto, Canada, M5T 1W1
www.ocadu.ca<http://ocadu.ca/>

_______________________________________________________
fluid-work mailing list - fluid-work at lists.idrc.ocad.ca<mailto:fluid-work at lists.idrc.ocad.ca>
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20160804/3a478d4d/attachment.htm>