Comment ils l'ont fait le projet d'accessibilité

Peut-être que vous, ou quelqu'un que vous connaissez, avez connu les difficultés d'interaction de l'ordinateur pour les personnes avec facultés affaiblies. En général, les systèmes d’exploitation et les suites logicielles ont prévu l’accessibilité pour un public malentendant, malvoyant et pour l’internationalisation; Cependant, le Web ouvert n'a pas rattrapé aussi rapidement. De nombreux sites ignorent complètement l'accessibilité.

Une des raisons en est peut-être qu’il n’ya pas de source de contenu digeste, à jour et entièrement centré sur l’accessibilité..

Le projet d'accessibilité (a11yproject.com) est en train de changer cela. En proposant une plate-forme ouverte (via GitHub), a11yproject est en train de créer un ensemble de contenu multiculturel et auto-curating digestible, à jour, et indulgent. (Voir leur page à propos.)

Le projet d'accessibilité est un excellent exemple de la façon dont la technologie peut aider à soutenir le développement collaboratif. Tout le monde peut contribuer. Le coût du support pour cela est presque nul et la gestion du site est minime, conduite par la communauté.


Les gens

Il y a beaucoup de gens derrière tout projet, y compris Dennis Gaebel de Grey Ghost Visuals, Dave Rupert chez Paravel, Jamie Piper chez Alliants, Mat Marquis et une foule d'autres. (Consultez la liste des avatars des contributeurs au bas de la page d'accueil.)

C’est un groupe qui vaut la peine d’être rejoint, et la partie la plus intéressante est que vous pouvez le faire simplement en contribuant!

Alors, comment font-ils?

Le projet d'accessibilité est configuré pour la collaboration asynchrone à distance. Le site n'utilise pas de base de données et ne nécessite aucun fournisseur d'hébergement. Voici comment ils le font.


GitHub

Le site est entièrement hébergé par GitHub via GitHub Pages. GitHub Pages permet aux utilisateurs de GitHub de publier du contenu statique et sert de page Web..

GitHub Pages est, en général, créé pour soutenir les projets et les utilisateurs, en leur donnant un emplacement pour héberger de la documentation, des exemples, etc. Les gens de GitHub ont également créé des pages compatibles avec Jekyll.


Jekyll

Jekyll est le framework de travail basé sur Ruby-gem qui se cache derrière The Accessibility Project. Construit par Tom Preston-Werner et d’autres chez GitHub, Jekyll est un générateur de site statique qui permet aux utilisateurs de créer des messages et des pages dans Markdown ou Textile (bien que tous les posts ne soient que Markdown).

Jekyll utilise les paramètres de configuration YAML pour aider à générer des pages / publications localement. Ces publications et pages apparaissent sous forme de fichiers HTML, JavaScript et CSS statiques. (Pour en savoir plus sur Jekyll, consultez le wiki d'utilisation de Jekyll sur GitHub.) Si vous souhaitez contribuer au projet d'accessibilité, c'est la meilleure façon de créer un nouveau message..

  1. Cloner le référentiel
  2. Utilisation paquet installer toutes les dépendances. Le Gemfile spécifie trois gems qui seront installés. (En outre, vous aurez besoin de Bundler pour paquet travailler.)
  3. Utilisation rake -T pour répertorier les commandes spécifiques à ce projet que vous pouvez utiliser. râteau, ou "Ruby make", est un outil qui permet de résumer des tâches répétitives ou automatisées dans un fichier du répertoire de travail (appelé Rakefile) et de les appeler via la ligne de commande..
  4. Utilisation rake post title = "Quelque chose d'intéressant à propos de l'accessibilité" créer un post.
  5. Ajoutez votre message via le flux de travail normal de Git (voir ci-dessous quelques astuces utiles pour ce projet spécifique).

Une fonctionnalité encore plus cool de GitHub Pages: il compilera votre site Jekyll pour vous, si vous le souhaitez..

Une note rapide: pourquoi statique?

Pourquoi voudriez-vous aller avec un générateur de site statique? Il y a beaucoup de raisons pour lesquelles c'est une bonne réponse à de nombreux problèmes de développement. Premièrement, les fichiers statiques sont faciles à servir. Fondamentalement, tout serveur Web peut servir des fichiers statiques. Au-delà, servir des fichiers statiques est généralement incroyablement rapide et efficace.

De même, le temps de traitement des fichiers statiques est beaucoup moins important sur le serveur. L'imputation de la gestion du contenu dans un environnement de développement local réduit les incertitudes et la nécessité d'un environnement axé sur l'administrateur système..

Une autre bonne raison d’utiliser un générateur de site statique est la sécurité; Les sites statiques sont infiniment moins vulnérables aux problèmes de sécurité, tels que l'injection SQL, que les sites dépendants de la base de données. Enfin, la plupart des contenus à base périodique se prêtent déjà aux fichiers statiques. le contenu n'est pas généré par un algorithme piloté par les données ni par des données livestreamed. Il s'agit plutôt d'un contenu textuel qui ne changera pas (à moins que des modifications ne soient apportées manuellement). La distinction importante ici est que les articles sont créés manuellement, et la mise en page autour le contenu ne change pas dynamiquement. Ce sont tous des signes que l'utilisation de fichiers statiques est une bonne solution.

Expliquer des fichiers étranges: .rvmrc

RVM est un outil qui gère plusieurs installations du langage de programmation Ruby. RVM utilise .rvmrc fichiers pour vous assurer que la version appropriée de Ruby est sélectionnée pour s'exécuter pour un projet donné. Un conseil utile: tout fichier commençant par un . est très probablement un fichier de configuration; en particulier, les fichiers. * rc, ou "fichiers de configuration d'exécution", sont généralement évalués au moment de l'exécution / de l'exécution, généralement une seule fois.

Expliquer des fichiers étranges: codekit-config.json

Le fichier de configuration CodeKit est utilisé pour générer les paramètres de CodeKit, qui compile les fichiers SASS du projet. Cette configuration aide à maintenir la conformité entre les différents utilisateurs. Vous pouvez reconnaître le type de fichier (JSON) - le fichier est un objet JavaScript valide. JSON est également utilisé pour de nombreuses autres configurations d'environnement.


Problèmes GitHub + demandes d'extraction

Le "meilleur flux de travail Web moderne" est un sujet difficile à atteindre, mais de nombreuses personnes ont récemment publié des articles sur la flexibilité et la convivialité de l'intégration du développement orienté fonction, qui tourne autour de la discussion avec GitHub Issues et Pull Request. (Consultez l'excellent dossier de conférenciers de Zach Holman sur le sujet.) Pour déposer un problème, il vous suffit de vous rendre dans un projet, de cliquer sur Problèmes et d'expliquer le problème. Le propriétaire du projet peut classer votre problème et y répondre. si un correctif ou une demande d'extraction corrige le problème, le langage naturel peut être utilisé dans le message de validation Git pour marquer le problème comme résolu. Par exemple, "Problème résolu n ° 42". Ensuite, vous pouvez soumettre une demande d'extraction référençant un commit spécifique; si cette demande d'extraction est acceptée, le problème est marqué comme résolu..


Mais revenons un peu en arrière avant de parler de flux de travail Git pendant des heures..

Le projet d’accessibilité utilise GitHub pour gérer le contenu, à la fois au stade de la publication préalable et de la publication. Si vous avez une idée pour un article, vous pouvez le créer (via un GistHub ou un Clap). Une fois que cela est fait, déposer un problème sur le GitHub qui fait référence à votre Gist / Clap commence la conversation sur votre article particulier. Enfin, prenez l’article de The Gist dans un message alimenté par Jekyll. Cela implique quelques commandes de terminal simples, une validation et une demande d'extraction pour résoudre le problème que vous avez généré à propos de cet article. Alors, voici les étapes de base.

  1. Ecrivez votre brillante idée dans un GitHub Gist ou Clap
  2. Faites référence à cette idée dans un numéro de la page des problèmes de a11yproject.com
  3. Discutez de l'idée avec d'autres via le numéro GitHub
  4. Affiner le contenu et créer un message via Jekyll rake post title = "votre titre" dans votre copie locale du référentiel
  5. Courir serveur de rake et rendez-vous sur http: // localhost: 4000 pour consulter votre message (et le reste du site)
  6. Courir rake check pour vous assurer de ne rien casser. (Si vous l'avez fait, c'est un sujet pour le fil de commentaires.)
  7. Si tout est correct, envoyez une demande de rappel en référence à la publication de votre publication; assurez-vous d'inclure "Corrections # 42" dans votre message de validation si votre problème était # 42.

Si vous n'êtes pas encore prêt à maîtriser vos compétences Jekyll ou Git / GitHub, vous pouvez également demander de l'aide pour intégrer votre message à un commit. Commentez la publication associée à l'article. Assurez-vous également de visionner ce screencast sur notre site Tuts +, NetTuts.

Synergie

Au cas où vous ne l'auriez pas remarqué, tout ce processus de création de contenu s'articule autour de fils de conversation / contenu liés sur GitHub. Cela permet de combiner naturellement une conversation avec une action associée. Ceci est une intégration critique pour tout type de collaboration.


Plus de noix et de boulons

Le site s'appuie sur le portage de Sass / Compass de Twitter Bootstrap. Son design n'a donc rien d'innovant. Cependant, il est également ouvert aux contributions et aux collaborations. Les numéros déposés sur GitHub ne servent pas uniquement à collaborer sur des idées de publication, mais également à signaler inexactitudes, inaccessibilités et bugs. Même au-delà, tout le monde est invité à soumettre des problèmes et à extraire des demandes pour améliorer le site de quelque manière que ce soit; pense que le site pourrait utiliser une nouvelle peau?

  1. Déposer un problème descriptif
  2. Vous attribuer
  3. Construire la peau
  4. Soumettre une demande de tirage attachée au problème
  5. Deviens célèbre *

* Être célèbre n'est pas lié à l'envoi de votre demande de tirage.


SASS + Compass Only

Le projet d'accessibilité est exclusivement construit en utilisant SASS et Compass; si vous souhaitez soumettre des modifications de conception, vous devez le faire avec SASS et Compass..

Bien que certains puissent considérer cela comme une limitation, cela sert à quelque chose. Premièrement, cela rend la base de code moins complexe; si le projet essayait de prendre en charge les CSS, LESS et SASS de vanilla, le résultat entraînerait de graves problèmes de dépendance. Il faudrait également que les contributeurs mettent à jour les fichiers LESS et SASS, ce qui est beaucoup moins susceptible d’encourager la participation. Enfin, ceux qui sont motivés à contribuer et qui possèdent les compétences ou le contenu de qualité pour le faire connaissent déjà le SASS ou auront un moyen de l’apprendre. Bien que cela semble exclusif, nous devons également considérer que cela, à un moment donné, est le cas de toute technologie; ceux qui ne savent pas (et ne veulent pas apprendre) comment intégrer leur JavaScript avec jQuery ne peuvent tout simplement pas écrire de plugins jQuery.


Conclusion

Open-source est un outil incroyablement puissant. L'utilisation de plates-formes telles que GitHub et d'outils comme Jekyll fait briller les technologies open source. Une communication intégrée aux documents de travail est essentielle pour une collaboration efficace, en particulier si le travail effectué est parallèle à celui d'autres personnes effectuant un travail similaire..

Le projet d'accessibilité est un excellent exemple de la concrétisation de tous ces principes. Avec près de quarante contributeurs de premier plan à ce jour, il s'agit d'une démonstration du pouvoir de l'open source et de la volonté des gens de collaborer pour créer quelque chose de grand. Le projet n'engendre que très peu voire pas de frais généraux pour que ce site existe.

?