Giter VIP home page Giter VIP logo

openbadges-discovery's Introduction

discovery

Discovery tool for Open Badges

Quick Start

With mongo running locally...

npm install
echo '{  
  "url": "http://localhost:3000",
  "cookie": {
    "secret": "macadamianuts"
  },
  "database": {
    "app": "mongodb://127.0.0.1:27017/app",
    "test": "mongodb://127.0.0.1:27017/test"
  }
}' > config.json
DEV=1 node app

Then navigate to http://localhost:3000.

This app can also be deployed to Heroku.

Configuration

Parameters

Available app parameters are:

  • COOKIE_SECRET: required Should be a large, unguessable string.
  • URL: required The url (protocol, host, port) where your app lives. This is used as the Persona audience, and must match what you see in your browser's url bar exactly.
  • DATABASE_APP: required Mongo url for your app database.
  • DATABASE_TEST: optional Mongo url for your test database, required if you want to run tests.
  • PORT: optional Port the server will run on. Defaults to 3000.
  • DEV: optional Run in development mode. Defaults to false.
  • NEWRELIC_KEY: optional Your newrelic license key, if you have one. Setting this turns on New Relic logging.
  • NEWRELIC_NAME: optional Your app name in New Relic.
  • NEWRELIC_LOG_LEVEL: optional The log level to use.

Alternatives

Configuration parameters can be provided via commandline arguments, a config.json file, or environment variables.

For example, node app --cookieSecret=macadamianuts or adding a config.json with the contents:

{
  "cookie": {
    "secret": "macadamianuts"
  }
}

are equivalent to setting COOKIE_SECRET in the environment.

See js-config-store for more information.

Developers

Data Setup

app/fake-data.js is currently defunct. You can run node app/google-data to wipe the app database and load in initial data from a Google spreadsheet as detailed below.

Google spreadsheet data

The Google data reader makes many assumptions about the format of the spreadsheet. In general to load data this way:

  • set the following configuration:
    • GOOGLE_EMAIL: the email address of an account with read access on the spreadsheet
    • GOOGLE_PASSWARD: the password for the same account
    • GOOGLE_KEY: the spreadsheet key, found in the url
      • e.g. https://docs.google.com/spreadsheet/ccc?key={THIS IS THE KEY}&usp=drive_web#gid=0
  • build your spreadsheet as follows
    • define your badges using as many sheets as you would like with the following column names
      • Badge name: name
      • Description: description
      • Tags: comma-separated list of tags
      • Creator: creator
      • Image file: url of badge image
      • Criteria: criteria as HTML
      • Keeping: rows with a blank cell here will be skipped
    • define your pathways, one sheet per pathway with the following column names
      • Name: name
      • Description: description
      • Image file: url of pathway image
      • Tags: comma-separated list of tags
      • Creator: creator
      • Badge name: name of badge to include in pathway
      • X: x position on grid, starting at 0
      • Y: y position on grid, starting at 0
      • Core: any value here indicates this badge is core to this pathway
      • Note title: title of note
      • Note body: body of note
    • on the first line, fill out Name through Creator
    • for each badge in the pathway, fill out Badge name through Core
    • for each note in the pathway, fill out X, Y, Note title, and Note body
    • make sure all pathway sheets have the word "pathway" in the sheet name

This is an older style of Google spreadsheet url, YMMV on the newer updated style.

This mimics retreiving the criteria url a badge would normally provide and parsing the content there to retrieve an HTML snippet for display.

Precommit Hooks

At the moment this project is using precommit-hook to run jshint and tests before commits. Feel free to propose changes to the jshint configuration; it is by no means final.

It also runs bin/beautify --warn which will report files that don't live up to formatting conventions, but currently will not fail the validation step. Run bin/beautify -h for a help statement.

Development Mode

Development mode can be enabled to rebuild CSS, recompile templates and rebuild the clientside JS, unminified, on each request.

This should NOT be turned on for production.

openbadges-discovery's People

Contributors

shiba4life avatar stenington avatar zeejab avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

openbadges-discovery's Issues

Listing page badges/pathways view/model/collection

See wireframes for D1/M1 and D2/M2

This includes Backbone views, models and collections to render a paginated list of badges and pathways using the templates provided in #48 and #49.

  • Selecting a filter should redraw the list of items
  • Selecting view more should show more
  • Excludes favorites functionality for now

Tag taxonomy

As mentioned in #12, this can serve as a discussion thread for tag taxonomies.

Below is my understanding of the issue. (Please correct me if I'm wrong.)

Overview

We've been talking about the pathways app having some sort of hierarchical view of all of the badges it knows about and being able to cluster them under the relevant job sectors, for example. An obvious mechanism for this sort of thing is tags, but there's an important piece to consider. The assertion spec allows tags, but those are issuer supplied tags only. Relying on those to form a hierarchical view of the badges ecosystem is problematic in a few obvious ways:

  • what if issuer A uses "healthcare", issuer B uses "Health-Care", and issuer C uses "medicine" as their tags?
  • what if an issuer doesn't tag their badge classes?
  • what if an issuer adds incorrect or inappropriate tags to their badge class to boost it?

Additionally, we talked about identifying a user's Holland Code, for example, and using that to match to badges. But again, would we then ask issuers to assign the appropriate Holland Codes to their badges? It's sounds more like the work for an expert 3rd party to do, but a) there's not currently a mechanism for that and b) tagging an ever-growing ecosystem seems daunting.

Prototype vs. real world

The workaround we discussed for the purposes of prototyping was just to control the dataset on which we operate. E.g. rather than opening up the badge directory to the entire world, we'll populate it ourselves with data we manage. In that case, we could hire an expert to tag each badge with a Holland Code (or whatever) and expect things to work. The tradeoff is that it becomes much less obvious how to then roll the system out to the world and expect it to keep working.

Proposal

I suppose a sort of middle ground could be reached by using a person's quiz results to point them to other badges currently in a pathway, as opposed to any badge anywhere. Or alternatively we could allow tagging of pathways themselves, and use the quiz results to point people to certain pathways. I think that would have a few advantages:

  • including a badge in a pathway acts as a rough filter that the badge isn't spam
  • if people start to build spam pathways, we do have control of that DB and can block users or delete pathways, if needed
  • we know we need to seed the discovery app with predefined pathways anyway, so it doesn't represent unreasonable extra work.

Build shuffle v1

Build the shuffle functionality that displays recommended badges that can be added to a pathway.

Note the recommendations won't necessarily be any good (providing/improving them is part of openbadges-directory).

Narrow target platform/browsers

As mentioned in #3, the more we can narrow our target platform/browsers the more we can focus on building features. To that end I'm wondering:

  • what platform/browser will we use for our user testing?
  • how do we expect people to find and use the final product at the end of the grant?

If we know anything about the computers we'd use for our user testing, that would be useful information now. Obviously if we plan to do user testing by walking around with an iPad showing people what we have, for example, it had better work well on an iPad.

Also, if we know of groups who plan to use this product at the end of the grant, it would be useful to ask them now what kinds of devices and browsers they have at their disposal.

What is the actual goal of this project?

Hi,
I'm following the project. But I barely can see what the actual goal is. What should be accomplished? Do you "just" want to build different clients such as mobile app, web app and desktop app? What's the backend?

I couldn't attend to any community call, yet. Are there more information about the goal, I haven't seen yet?

Thank you :)

Implications of mixing badges and pathways

The discovery app wants to treat badges and pathways as essentially identical things, but I have the sense that that's a little bit tricky to implement. For example if we want the directory project to be in charge of badges but also to have featured badges, it's starting to feel like we need to periodically import directory badges in to the discovery project and then do all the searching/filtering/etc. on the discovery side, further shifting the balance of work this way.

Explore pathway representation

It just sort of clicked in my head that the way we've divided data between the discovery and directory projects puts the burden of doing cool recommendations stuff with badges and pathways on this project.

To that end, we may want to schedule some time to play around with different ways of representing a pathway in a database, and the repercussions of doing so. In particular, it may be worth exploring some graphing databases like Neo4j to see if that would provide a significant advantage over cobbling something together in mysql.

Listing page template

See wireframes for D1/M1 and D2/M2

Includes header, footer, filter dropdown, search bar, sign in/up.

Does not include the pathways/badges themselves, functionality behind any buttons/search, the quiz, or the user summary view when logged in.

Design Pathway Page Wireframes (Responsive On Mobile)

Following #5, this is the Pathway Flow. We have been using the grid from our earlier prototype with @stenington as a reference to design this. Especially interested in some feedback on the design by @LucasBlair re: how content will fit in, what are some challenges you see with current design. We ll be working on solidifying this flow over sprint as well with @xmatthewx who is working on the backend UX of the system via Badgekit 🎯
discovery ux-09-09
You can use pink numeration to refer to specifc wireframes:)
As with issue #5 we will also discuss this on Mondays Discovery call to get through questions and clarify touch points
cc/ @threeqube

Listing page API endpoints

This is a bit of a placeholder until #51 gets worked out, but the listing page will need something like a GET /api/achievement endpoint that returns badges and pathways, paginated and filtered/sortable by

  • featured status
  • latest
  • type (badge or pathway)
  • tag

Render a re-arrangeable pathway grid

Work out the rendering of a re-arrangeable pathway grid. The rest of the page will be dealt with in another ticket.

I think the pathway being re-arrangeable has the greatest impact on how the templates will look, so may as well do that up front and then limit it to having clicked the rearrange button later.

Note that badges in a pathway can be made mandatory, which simply means they cannot be deleted from the pathway. This is not accessible through the UI but can be set in the database.

Create quiz content

When a user first starts, the discovery tool needs some context to get oriented and start generating recommended badges. We'll fulfill that with an initial strawman quiz.

cc/ @emgollie

Build the listing page

The listing page is basically a view on a combo of directory and pathways data. Data will have to be fetched from each and collated in some fashion.

This should include filters, or if not then that should become an additional ticket.

Privacy controls

Will there be any privacy controls in the MVP product? Are all pathways and user accounts publicly viewable?

Design Directory Wireframes (Responsive On Mobile)

Per the teams' decision I started with the responsive wire-frames first. Below wireframes in sequence: from someone coming to the site, to them logging in (persona), to searching through the directory and checking their profile (dashboard).

Will present these on Mondays 4pm Discovery Call & Plan is to iterate through them and address many questions that I am sure will come up during our NYC-Sprint 🌆

discovery ux-08

use numeration in pink to leave comments for specific wireframes
*D3: I inserted @carlacasilli 's mention for a pre-assessment quiz so we could gather information to make suggestions, but not sure if that will make it to MVP.

cc @stenington @threeqube

Mobile Safari dragging bug

Mobile Safari 7 on my phone offsets the badge image when dragging like so (my finger would be on the green square overlapping the yellow target):

For some reason the calculated max-height changes on the badge image when .ui-draggable-dragging is added to the containing .badge element, and it overflows to display below. It doesn't happen on desktop browsers that I've noticed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.