Difference between revisions of "Developer Space/Components"

From wiki.gpii
Jump to: navigation, search
(The Interface for Searching, Browsing and Bookmarking Components)
m (Adding Components)
Line 82: Line 82:
  
 
=== Suggesting New Components ===
 
=== Suggesting New Components ===
=== Using Github ===
+
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.
=== Strategies for finding new componets ===
+
 
 +
TODO Image
 +
 
 +
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.  T
 +
 
 +
=== 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
 +
 
 
== Understanding the Importing and Updating Pipeline ==
 
== Understanding the Importing and Updating Pipeline ==
  

Revision as of 20:32, 10 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

TODO:IMAGE

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

TODO:IMAGE

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

TODO Image.

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.

TODO Image

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. T

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

Understanding the Importing and Updating Pipeline

Drupal Feeds Plugin

The Mapping of Github information to DSpace

Editing and Categorizing Components

Type

Needs

Solutions

Procurement Requirements

Curating and Publishing Components

Minimal Requirements

Scheduling for Publication

Summary and Future Work