Share
Misschien heeft u, of iemand die u kent, de moeilijkheden ondervonden van computerinteractie voor gehandicapten. Over het algemeen hebben besturingssystemen en softwaresuites voorzieningen getroffen voor toegankelijkheid voor slechthorenden, slechtzienden en internationalisering; het open web is echter niet zo snel ingehaald. Veel sites negeren de toegankelijkheid volledig.
Misschien is een van de redenen hiervoor dat er waarschijnlijk geen bron is van up-to-date, verteerbare content die volledig is toegespitst op toegankelijkheid.
Het toegankelijkheidsproject (a11yproject.com) verandert dit. Door een open platform aan te bieden (via GitHub), bouwt a11yproject een door crowd-sourcing, zelfverzonnen verzameling van content die verteerbaar, bijgewerkt, en vergevensgezind. (Zie hun pagina over.)
Het Accessibility-project is een goed voorbeeld van hoe technologie kan helpen bij de ontwikkeling van samenwerkingsverbanden. Iedereen kan bijdragen. De kosten van ondersteuning hiervoor zijn bijna niks en het beheer van de site is minimaal, aangedreven door de community.
Er zijn veel mensen achter een ander project, zoals Dennis Gaebel van Gray Ghost Visuals, Dave Rupert over bij Paravel, Jamie Piper bij Alliants, Mat Marquis en een hoop andere. (Kijk eens naar de lijst met bijdragers van avatars onderaan de homepagina.)
Dit is een groep die de moeite waard is om toe te treden, en het geweldige deel is, je kunt dit doen door gewoon een bijdrage te leveren!
Het Accessibility Project is opgezet voor externe, asynchrone samenwerking. De site gebruikt geen database en vereist geen hostingprovider. Hier is hoe ze het doen.
De site wordt volledig gehost door GitHub via GitHub Pages. GitHub-pagina's stelt GitHub-gebruikers in staat om statische inhoud te publiceren en dient die als een webpagina.
GitHub-pagina's is over het algemeen gemaakt om projecten en gebruikers te ondersteunen, waardoor ze een plek krijgen voor het hosten van documentatie, voorbeelden, enzovoort. De mensen van GitHub hebben ook pagina's gemaakt die compatibel zijn met Jekyll.
Jekyll is het op Ruby-juweel gebaseerde werkpaardkader achter The Accessibility Project. Gebouwd door Tom Preston-Werner en anderen op GitHub, is Jekyll een statische site generator waarmee gebruikers berichten en pagina's kunnen maken Markdown of Textiel (hoewel a11y berichten alleen Markdown zijn).
Jekyll gebruikt YAML-configuratie-instellingen voor de voorkant om pagina's / berichten lokaal te genereren. Deze berichten en pagina's komen eruit als statische HTML-, JavaScript- en CSS-bestanden. (Bekijk hier meer over Jekyll: Jekyll gebruikswiki op GitHub.) Als je een bijdrage wilt leveren aan The Accessibility Project, is dit de beste manier om een nieuw bericht te maken.
Accentsconagua
bundel om alle afhankelijkheden te installeren. De Gemfile specificeert drie edelstenen die zullen worden geïnstalleerd. (Ook heeft u Bundler nodig voor bundel werken.)hark -T om opdrachten op te geven die u kunt gebruiken die specifiek zijn voor dit project. hark, of "Ruby make", is een hulpmiddel waarmee herhalende of geautomatiseerde taken kunnen worden geabstraheerd naar een bestand in de werkdirectory (een Rakefile genoemd) en aangeroepen via de opdrachtregel.rake post title = "Iets interessants over toegankelijkheid" om een bericht te maken.Een nog coolere functie van GitHub Pages: het zal uw Jekyll-site voor u samenstellen, als u dat wilt.
Waarom zou je met een statische site-generator willen gaan? Er zijn veel redenen waarom dit een goed antwoord is op veel ontwikkelingsproblemen. Ten eerste zijn statische bestanden eenvoudig te bedienen. In principe kan elke webserver statische bestanden gebruiken. Verder is het bedienen van statische bestanden in het algemeen ongelooflijk snel en efficiënt.
Evenzo is de overhead van het bedienen van statische bestanden veel lager op de server. Het offloaden van het beheer van inhoud naar een lokale ontwikkelomgeving vermindert de onzekerheid en de noodzaak van een op sysadmin georiënteerde omgeving.
Een andere goede reden om met een statische site-generator te gaan is beveiliging; statische sites zijn oneindig minder kwetsbaar voor beveiligingsproblemen zoals SQL-injectie dan websites die afhankelijk zijn van databases. Ten slotte leent de meeste periodiek gebaseerde inhoud zich al voor statische bestanden; de inhoud wordt niet gegenereerd door een datagedreven algoritme of livestreamed data. Het is eerder inhoud op tekstbasis die niet zal veranderen (tenzij bewerkingen handmatig worden gemaakt). Het belangrijke onderscheid hier is dat de berichten handmatig worden gemaakt en de lay-out in de omgeving van de inhoud verandert niet dynamisch. Dit zijn allemaal tekenen dat het gebruik van statische bestanden een goede oplossing is.
RVM is een tool die meerdere installaties van de programmeertaal van Ruby beheert. RVM gebruikt .rvmrc bestanden om ervoor te zorgen dat de juiste versie van Ruby is geselecteerd om voor een bepaald project te worden uitgevoerd. Een handige hint: elk bestand dat begint met een . is waarschijnlijk een configuratiebestand; in het bijzonder. * rc-bestanden of "runtime-configuratie" -bestanden worden over het algemeen geëvalueerd op het moment van uitvoering / runtime, meestal slechts eenmaal.
Het codebestand CodeKit wordt gebruikt om instellingen te genereren voor CodeKit, die de SASS-bestanden voor het project compileert. Deze configuratie helpt de conformiteit tussen verschillende gebruikers te behouden. Mogelijk herkent u het bestandstype (JSON): het bestand is een geldig JavaScript-object. JSON wordt ook gebruikt voor vele andere omgevingsconfiguraties.
De "beste moderne webworkflow" is een ongrijpbaar onderwerp, maar veel mensen hebben onlangs gepubliceerd over de flexibiliteit en bruikbaarheid van het integreren van functiegerichte ontwikkeling die draait om discussie met GitHub-problemen en Pull-aanvragen. (Bekijk het geweldige Sprekersdeck van Zach Holman over het onderwerp.) Om een probleem op te lossen, ga je gewoon naar een project en klik je op Problemen en leg je het probleem uit. De projecteigenaar kan uw probleem categoriseren en erop reageren; Als een patch of pull-aanvraag het probleem oplost, kan natuurlijke taal worden gebruikt in het Git commit-bericht om het probleem als opgelost te markeren. Bijvoorbeeld "Probleem # 42 opgelost". Vervolgens kunt u een pull-aanvraag indienen die verwijst naar een specifieke commit; als dat pull-verzoek wordt geaccepteerd, wordt dat probleem gemarkeerd als opgelost.
Maar laten we een stapje terug doen, voordat we het over koppen hebben die uren over Git-workflows praten.
De manier waarop het Accessibility-project GitHub gebruikt, is een manier om content te beheren, zowel in de pre-gepubliceerde fase als in de gepubliceerde fase. Als je een idee hebt voor een artikel, kun je het maken (via een GitHub Gist of een klap). Zodra dit is gebeurd, begint het indienen van een probleem op de GitHub dat verwijst naar je Gist / Clap het gesprek over je specifieke artikel. Neem tenslotte het artikel uit de Gist naar een door Jekyll aangedreven post. Dit omvat enkele eenvoudige terminalopdrachten, een commit en een pull-aanvraag om het probleem op te lossen dat u over dat artikel hebt ingediend. Dus, hier zijn de basisstappen.
rake post title = "jouw titel" in je lokale kopie van de repositoryrake server en bezoek http: // localhost: 4000 om uw bericht (en de rest van de site) te bekijkenharkcontrole om er zeker van te zijn dat je niets kapot hebt gemaakt. (Als je dat wel hebt gedaan, is dat een onderwerp voor de opmerkingenthread.)Als je nog niet klaar bent om je Jekyll- of Git / GitHub-vaardigheden te gebruiken, kun je ook om hulp vragen bij het plaatsen van je commit in een commit. Reageer op het bijbehorende probleem van het bericht. Bekijk ook deze screencast op onze broer / zus Tuts + -site, NetTuts.
In het geval dat u het nog niet gemerkt heeft, draait dit hele proces van inhoudcreatie rond gekoppelde gespreks- / inhoudsthreads op GitHub. Dit biedt een manier om een gesprek op natuurlijke wijze te combineren met een bijbehorende actie. Dit is een essentiële integratie voor elke vorm van samenwerking.
De site is gebaseerd op een Sass / Compass-poort van Twitter Bootstrap, dus er is niets verrassends innovatiefs aan het ontwerp van de site. Het staat echter ook open voor bijdragen en samenwerkingen; Problemen die op GitHub zijn ingediend, zijn niet alleen bedoeld om samen te werken aan postideeën, maar ook om erop te wijzen onnauwkeurigheden, ontoegankelijkheid en bugs. Zelfs daarna, is iedereen welkom om problemen in te dienen en verzoeken in te dienen om de site op wat voor manier dan ook te verbeteren; denk dat de site een nieuwe skin zou kunnen gebruiken?
* Beroemd worden is niet gerelateerd aan het indienen van uw pull-aanvraag.
Het Accessibility Project wordt exclusief gebouwd met behulp van SASS en Compass; Als u ontwerpwijzigingen wilt indienen, moet u dit doen met SASS en Compass.
Hoewel sommigen dit een beperking vinden, heeft het een doel. Ten eerste maakt het de codebasis minder complex; als het project vanilla CSS, LESS en SASS probeerde te ondersteunen, zou het resultaat leiden tot grote afhankelijkheidshoofdpijn. Het vereist ook bijdragers om zowel LESS- als SASS-bestanden bij te werken - iets dat veel minder waarschijnlijk is om betrokkenheid te stimuleren. Ten slotte zullen degenen die gedreven zijn om bij te dragen en ook de vaardigheden of de inhoud van de kwaliteit hebben om een bijdrage te leveren, SASS al kennen of een middel hebben om het te leren. Hoewel dit exclusief lijkt, moeten we ook bedenken dat dit op een bepaald moment het geval is met welke technologie dan ook; degenen die niet weten (en niet willen leren) hoe ze hun JavaScript met jQuery kunnen integreren, kunnen eenvoudig geen jQuery-plug-ins schrijven.
Open-source is een verbazingwekkend krachtige tool. Het gebruik van platforms zoals GitHub en hulpmiddelen zoals Jekyll zorgen voor een open-source glans. Communicatie geïntegreerd met werkdocumenten is essentieel om efficiënt samen te werken, vooral als het werk dat wordt gedaan parallel loopt met anderen die soortgelijk werk doen.
Het toegankelijkheidsproject is een goed voorbeeld van het feit dat al deze principes hun vruchten afwerpen. Met bijna veertig geweldige bijdragers tot nu toe, is het een weergave van de kracht van open-source en de bereidheid van mensen om samen te werken om iets groots te maken. Het project maakt weinig tot geen overhead voor deze site.
?
