Difference between revisions of "Developer Space/Components"

From wiki.gpii
Jump to: navigation, search
(Editing and Categorizing Components)
(Editing and Categorizing Components)
Line 148: Line 148:
  
 
Once the component is successfully imported it will be added to a editing and curation queue as unpublished content. The editor prepares the document for publication and puts it into the curation queue where the curator schedules it for publishing (see next section).
 
Once the component is successfully imported it will be added to a editing and curation queue as unpublished content. The editor prepares the document for publication and puts it into the curation queue where the curator schedules it for publishing (see next section).
 +
 +
[[File:Ds.gpii.net_admin_workbench_curation.png|Editor picks item from Queue]]
 +
  
 
0. Read the description of the component (if you don't understand what its about or why it has to do w/ a11y , don't bother and go to the next one)
 
0. Read the description of the component (if you don't understand what its about or why it has to do w/ a11y , don't bother and go to the next one)

Revision as of 18:13, 11 January 2018

Open component repository

Executive Summary

This document contains a accompanying user guide and developer documentation for the GPII Developer Space Component Repository, which is online as part of the GPII Developer Space at. If you are interested in contributing visit the site directly at http://ds.gpii.net/components. and refer directly to the relevant section in this document.

The repository is constantly extended and allows structured search in a compehensive list of building blocks for Assistive Technology development and implementation. The repository is as inclusive as possible, addressing different needs and solutions by a diverse set of software and hardware. The components listed on this page fulfil some minimal requirements for documentation and categorisation, that we define in this document. If you want to add a component to the list please go to https://github.com/dspace-projects/additions/issues, drop a mail on http://lists.gpii.net/cgi-bin/mailman/listinfo/dspace or post to our twitter account at https://twitter.com/GPII_DevSpace.

The goal of this public deliverable of the Prosperity4All Project is to provide particularly technical documentation about the background of the site and the curation process, which aims to be transparent, sustainable and scalable. The document is the last one in a range of documents (D202.1 and D202.2) where we have described, how we created and designed this repository and looked at technical convergence of components through standards and APIs. If you want more detailed information about the underlying architecture of the whole Developer Space refer to D201.5 as this document documents particularly the component listing. Additionally you should visit and browse the actual main deliverable of the project, which is online at http://ds.gpii.net/.

Background and Related Efforts

The component repository is not a unique effort in the sense that it collects accessibility related components. However, it differs from existing efforts in multiple ways. Even before the efforts started in this project the Spotlight / featured tools and components on the RaisingTheFloor web site provided a listing of developer targeted tools and components. This listing has been incorporated into the GPII Developer Space along with other developer targeted content. RaisingTheFloor is committed to curate this content beyond the project via the GPII Developer Space. The original listing also contains project specific listings like the AEGIS: Overview of demonstrators . It is the goal of the GPII Developer Space to provide a platform for such listings in the future and interlink open project results from commercial or academic endeavours in more sustainable way. Today many AEGIS demonstrators live on github such as http://hanshillen.github.io/jqtest/ where there can be easily forked and used by developers. We want to encourage projects to bring content to places where the developers actually are, without creating a new place that diverts traffic. This is why we also provide an interface that just provides an alternative interface to existing sites. The same goes for technology specific efforts like the W3C WAI Component Gallery. We were easily able to incorporate most content as it was hosted here as well as we also depend on external activities like Project A11y to identify open source content. The biggest difference of the component repository is that we have identified over 1000 accessibility related open source components, that we started to categorize on https://ds.gpii.net/develop/components .

The Interface for Searching, Browsing and Bookmarking Components

Screenshot of the Developer Space Component Repository

The above screenshot shows the current interface to the component repository with more than 700 curated component listing (the rest is still in the moderation queue). In the main part (1) a summary of different components. For components that were imported the number of followers (stars) and code forks is shown as an indicator for the popularity and distribution is shown (2) . Additionally can quickly bookmark or rate a component (3).

Instead of having many subcategories (like tools, code, hardware) the interface relies solely on a so called faceted search. The search field (4) can be used to query the collection. This collection can then be narrowed down by selecting facets that are shown on left hand side of the screen (5). Based on earlier user research we currently support filtering by the following facets:

  • Technology: mostly the used programming language
  • Licence: open source licence type specifying permitted distribution
  • User Needs: Major disability categories
  • Type: related to the usage as independent developer tools or e.g. as programming framework
  • Technique: what strategies to solve accessibility needs can be applied using the component

Example selecting javascript components that support adjusting the contrast

Using this interface the user can quickly apply different browsing strategies such as exploring all MIT licenced components that help with physical disabilities or specifically searching for a reactive web component that changes contrast on a web site. Once interesting components have been discovered

Links to components shown at the bottom of the Accessibility Masterlist entry

The site consequently interlinks content providing a rich browsing experience. By clicking e.g. on a technique the user is redirected towards the solution masterlist which in turn lists all possible components but also other educational material. Through the applied categorization the site thus provide a rich experience and fosters learning and expoloration. It also provides a like to practical material such as the components from the theoretical background to motivate real implementations.

Roles within the Developer Space

The concept of roles as we will describe it here is the basis for access control and defining content management processes. A natural person that logs in to the developer

Users

Users of the GPII Developer Space are described using the following four "epics":

  • I develop AT I want to make my product more accessible
  • I want to make an accessible website
  • I teach and research accessibility
  • I make policies on accessibility
  • I want to get the latest on accessibility

While the searching the GPII Developer Space can be done spontaneously (and should not require any documentation or a technical role), we also want to engage those users as pro-sumers. Logged in users contribute in multiple ways to the site:

  • Provide useful comment and feedback on components
  • Suggest new components and other content
  • Provide feedback on the overall site

Editors

Editors are community members or power users. Their main work is to organize the collection of resources thus adding value beyond quantity. In this document we describe how editors should categorize content.

Editors are typically volunteers from the RaisingTheFloor consortium and the overall GPII. Categorizing one thousand components needs a large number of volunteers initially. Currently partners from the funded Prosperity4All project took on this job. We believe less volunteers are needed once most of the content is categorized.

Curators

Curators are needed to release components. The role of the curator is to assure the quality of the content concerning both the usefulness and the legal compliance of the content.

The the checks to be done are described in the last section of this document. It should suffice to have a single curator for the component registry. It makes sense in terms of quality assurance to separate curation from editing. Curators should be contractually bound to the operator of the site (RaisingTheFloor International) in order to protect the operator from potential legal complications by enforcing some rules. Curators could also be seen as community managers or moderators. They have the right to modify, release or withdraw any content.

A special task for the curators is currently maintaining the GitHub interface to the developer space and to add content into the categorization cue for the Editors.

Administrators

The role of the administrator is to maintain the necessary software, define roles and access policies and to oversee the curation process.

One important prerequisite of the whole system is that the administrator can assign roles to users. In case the system needs to scale also other roles might assign less privileged roles. Currently we are envisioning that most users do not need special privileges, so the administrator knows and manages all curators and editors.

Currently the administrator is meant to be a web developer with skills in HTML, PHP and Drupal. The development of the code for the repository is coordinated by RaisingTheFloor International as part of the overall DeveloperSpace with contributions by KIT (repository imports), Pushing7 (drupal integration) and Illunion (feedback).

The overall Developer Space site is built on Drupal 7 technology (for the underlying architecture please refer to D201.5 of the Prosperity4AllProject). The component repository specifically relies on the Search and Facets API, that provides the necessary interfaces for efficient browsing via an Apache SOLR server. The curation scheme above is implemented using the Workbench Moderation module . Those parts are shared with the other content of the Website.

Specific attention to administrators should be given to the Github Feeds Importer that is described as part of this document.

Adding Components

Suggesting New Components

New Components can be suggested using the Issue tracker on Github: https://github.com/dspace-projects/additions/issues/ . Please share direct links to github repositories if possible. In case the project (source code) is hosted in other places please leave a comment here.

Example of developer contributing content

As explained above the DSpace lives from the fact that if features a diverse set of components that an implementer can build into his products or can help him improve his product in other ways (e.g. by testing). The listing lives from suggestions from the community. As most open source development has moved to GitHub as a platform (Google Code as well as Microsoft Codeplex have been archived with migration paths to Github), it became more and more apparent that we need to support a Github centric workflow to cover the majority of open source developments. This includes particularly component from the GPII projects, such as Cloud4All and Prosperity4All.

You may also use this issue tracker to update or remove project URLs.

New components can be scheduled for inclusion by "staring" the project via github's native interface. This provides an ease two-click workflow to review new suggestions. Using the DSpace user account in Github the curator can follow the link in the issues (or also e.g. an email with a suggestion), quickly assess the relevance of the suggestion (not categorizing at this point) and click the "star" icon. The item will be automatically scheduled for addition on the DSpace website (see below).

Staring component on Github to trigger inclusion


Another important aspect of this workflow is that it allows us to disseminate components over github's social network. Additions to the DSpace will be fed to all followers on github automatically via the timeline visible on github's homepage to signed in users:

Screenshot of user riedel of mainpage of github.com

Strategies for finding new components

One important feature of the staring feature is that it works both ways. In a addition to having followers, that are informed about new findings, we are informed about new finds from the people in our social developer network. While the automatic suggestion feature of github mostly focusses on popular content that is either too unspecific to assistive technology or already included, the simple timeline view helps to find new things quickly as we are following accessibility related developer profiles. See image.

Filtering user profiles for interesting components

Another strategy to find new content is to identify early adopters of accessibility related technology (e.g. by following git commits to knowledge basis such as the A11Y projects). By listing all starred components from their github profiles we are quickly able to find new components (see below). If the user shares relevant findings, we will continue to follow this user to get updates via our own timeline.

Github timeline for Developer Space curation user

Understanding the Importing and Updating Pipeline

Drupal Feeds Plugin

New github projects are periodically imported via a Feeds plugin on ds.gpii.net

Importing task aumatically run every 3 hours

The whole workflow for aggregating new github projects is backed by a Drupal module that was developed at KIT in the prosperity project to particularly fit the needs of the DSpace (but can be used beyond this). The module still supports two interfaces to github. One remote entity interface, that allows interfacing github content as Drupal entities via GitHubs API and one to autofill content using fields from Github.

Currently the following information is sourced automatically from github and mapped into Drupal:

  • Component name
  • Component author
  • Short Description
  • Readme file
  • Licence
  • Programming Language
  • Descritive Tags
  • Number of stars
  • Number of forks
  • Website link


The Mapping of Github information to DSpace

We use the same internal mapping logic to extend the Feeds interface that is used to import new component listings that are displayed on the GPII Developer Space. The API particularly supports the pagination of queries to Githubs open API and calls to fill out child elements such as the description.

The listings are automatically updated (due to some performance issues on caching, currently you need to clear the drupal cache manually to accept updates). Newly imported content is not yet published but must undergo categorization first. We use the github URL as a unique identifier for updates. This means that renaming of repositories might lead to duplicates. The next image shows the current mapping of the importing workflow that might be adapted to future needs.

Configuration of the github mapping

In order to support such a large number of queries a github API token is needed. The API token can be configured inside drupal. The API token also identifies the account that will be used to base the import upon. Future versions might support an even more integrated workflow, e.g. for unlisting components simultaneously or for feeding suggestions via the web interface directly to the issue list. The current source code of the components is available at: https://github.com/dspace-projects/ds.gpii.net

Using the Feeds important we can add fields to each component listing that will be retained during synchronization. This particularly includes the categorization (see below)

Also other content such as reviews and comments can be added to the component. Components can also be interlinked throughout the site, e.g. in tutorials or through the categorization.

Editing and Categorizing Components

Once the component is successfully imported it will be added to a editing and curation queue as unpublished content. The editor prepares the document for publication and puts it into the curation queue where the curator schedules it for publishing (see next section).

Editor picks item from Queue


0. Read the description of the component (if you don't understand what its about or why it has to do w/ a11y , don't bother and go to the next one)

1. Decide if it is a component at all (not everything from github is actually one, there is also things like documentation, also here: go to the next one)

2. Decide if the components is either a framework (like infusion, asterics, react) framework specific (like a react autocomplete field, ...), a testing tool, a code snippet or a whole implementation or neither of the above

3. If the component is particularly addressing a need of one of the major disability classes

4. If the component provides a solution in terms of the masterlist (probably all the components should address at least one item, otherwise sth. is missing).

5. Check if the components relates to a requirement as specified by the EN (Section 5-13 of http://mandate376.standards.eu/standard/) and tag it.

6. Go to the next one.


Type

Needs

Solutions

Procurement Requirements

Curating and Publishing Components

Minimal Requirements

Scheduling for Publication

Summary and Future Work