Share
Kanskje du, eller noen du kjenner, har opplevd vanskelighetene med datakommunikasjon for de funksjonshemmede. Generelt har operativsystemer og programvarepakker gjort bestemmelser for tilgjengelighet for hørselshemmede publikum, synshemmede publikum og internasjonalisering; Den åpne nettsiden har imidlertid ikke tatt opp så raskt. Mange nettsteder ignorerer tilgjengeligheten helt.
Kanskje en av grunnene til dette er at det uten tvil ikke er en kilde til oppdatert, fordøyelig innhold som fokuserer helt på tilgjengelighet.
Tilgjengelighetsprosjektet (a11yproject.com) endrer dette. Ved å tilby en åpen plattform (via GitHub), bygger a11yproject et mengdeinnkjøpt, selvkuratorisk sett med innhold som er fordøyelig, oppdatert, og forgiving. (Se deres om side.)
Tilgjengelighetsprosjektet er et godt eksempel på hvordan teknologien kan bidra til samarbeidsutvikling. Alle kan bidra. Kostnaden for støtte til dette er nesten ingenting, og ledelsen av nettstedet er minimal, drevet av fellesskapet.
Det er mange mennesker bak a11yproject, inkludert Dennis Gaebel av Gray Ghost Visuals, Dave Rupert over på Paravel, Jamie Piper på Alliants, Mat Marquis og en rekke andre. (Ta en titt på bidragsyternes liste over avatarer nederst på hjemmesiden.)
Dette er en gruppe verdt å bli med, og den fantastiske delen er, du kan gjøre det ved å bare bidra!
Tilgjengelighetsprosjektet er opprettet for ekstern, asynkron samarbeid. Nettstedet bruker ikke en database, og krever ingen hostingleverandør. Slik gjør de det.
Nettstedet er helt vert for GitHub via GitHub Pages. GitHub Pages gjør at GitHub-brukere kan publisere statisk innhold, og tjener det som en nettside.
GitHub Pages er generelt opprettet for å støtte prosjekter og brukere, noe som gir dem et sted å være vert dokumentasjon, eksempler osv. Folkene på GitHub har også laget sider som er kompatible med Jekyll.
Jekyll er Ruby-gem-basert arbeidshestramme bak Tilgjengelighetsprosjektet. Bygget av Tom Preston-Werner og andre på GitHub, er Jekyll a statisk nettsted generator som lar brukerne opprette innlegg og sider i Markdown eller Tekstil (selv om alle innlegg er bare Markdown).
Jekyll bruker YAML-konfigureringsinnstillinger for å opprette sider / innlegg lokalt. Disse innleggene og sidene kommer ut som statiske HTML-, JavaScript- og CSS-filer. (Se mer om Jekyll her: Jekyll bruk wiki på GitHub.) Hvis du vil bidra til tilgjengelighetsprosjektet, er dette den beste måten å opprette et nytt innlegg på.
Accentsconagua
bunt å installere alle avhengigheter. Gemfile angir tre perler som vil bli installert. (Også, du trenger Bundler for bunt å jobbe.)rake -T å liste kommandoer du kan bruke som er spesifikke for dette prosjektet. rake, eller "Ruby make", er et verktøy som gjør at repetitive eller automatiserte oppgaver kan abstraheres til en fil i arbeidskatalogen (kalt en Rakefile) og påkrevd via kommandolinjen.rake post title = "Noe interessant om tilgjengelighet" å opprette et innlegg.En enda kulere funksjon av GitHub Pages: den vil kompilere Jekyll-nettstedet ditt for deg, hvis du vil.
Hvorfor vil du gå med en statisk nettstedgenerator? Det er mange grunner til at dette er et godt svar på mange utviklingsproblemer. For det første er statiske filer enkle å betjene. I utgangspunktet kan enhver webserver servere statiske filer. Utover dette er det vanligvis å betjene statiske filer utrolig rask og effektiv.
På samme måte er overhead for å betjene statiske filer mye lavere på serveren. Avlasting av innholdsstyring til et lokalt utviklingsmiljø reduserer usikkerheten og nødvendigheten av et sysadmin-orientert miljø.
En annen god grunn til å gå med en statisk side generator er sikkerhet; Statiske steder er uendelig mindre utsatt for sikkerhetsproblemer som SQL-injeksjon enn databaserte nettsteder. Til slutt gir det mest periodiske innholdet seg til statiske filer allerede; innholdet genereres ikke av en data-drevet algoritme eller livestreamed data. Snarere er det tekstbasert innhold som ikke vil endres (med mindre endringer er gjort manuelt). Det viktige skillet her er at innleggene er manuelt opprettet, og utformingen rundt innholdet endres ikke dynamisk. Dette er alle tegn på at bruk av statiske filer er en god løsning.
RVM er et verktøy som administrerer flere installasjoner av Ruby programmeringsspråket. RVM bruker .rvmrc filer for å sikre at den riktige versjonen av Ruby er valgt for å kjøre for et gitt prosjekt. Et nyttig hint: enhver fil som begynner med en . er mest sannsynlig en konfigurasjonsfil; spesielt * .rc-filer, eller "kjøretidskonfigurasjon" -filer, blir generelt evaluert ved utførelse / kjøretid, vanligvis bare en gang.
CodeKit config-filen brukes til å generere innstillinger for CodeKit, som samler SASS-filene for prosjektet. Denne konfigurasjonen bidrar til å opprettholde samsvar mellom ulike brukere. Du kan kanskje gjenkjenne filetypen (JSON) - filen er et gyldig JavaScript-objekt. JSON brukes også til mange andre miljøkonfigurasjoner.
Den "beste moderne web-arbeidsflyten" er et unnvikende tema, men mange har nylig publisert om fleksibiliteten og brukervennligheten av å integrere funksjonsorientert utvikling som dreier seg om diskusjon med GitHub-utgaver og trekkforespørsler. (Sjekk ut Zach Holmans flotte Speaker Deck om emnet.) Hvis du vil sende et problem, går du ganske enkelt til et prosjekt og klikker på Utgaver, og forklarer problemet. Prosjektets eier kan kategorisere problemet ditt og svare på det; Hvis en patch- eller trekkforespørsel løser problemet, kan naturlig språk brukes i Git commit-meldingen for å markere problemet som løst. For eksempel, "Fast problem # 42". Deretter kan du sende inn en trekkforespørsel som refererer til et bestemt forpliktelse; Hvis den trekkforespørselen blir akseptert, er dette problemet merket som løst.
Men la oss ta et skritt tilbake her, før vi kommer inn over hodet vårt, og snakker om Git-arbeidsflyter i flere timer.
Måten Tilgjengelighetsprosjektet bruker GitHub, er som en måte å administrere innhold, både i sin pre-publiserte scene og i publisert scenen. Hvis du har en ide for en artikkel, kan du opprette den (enten gjennom et GitHub Gist eller Clap). Når dette er gjort, begynner å sende et problem på GitHub som refererer til Gist / Clap, samtalen om din spesielle artikkel. Til slutt, ta artikkelen fra Gist inn i en Jekyll-drevet post. Dette innebærer noen enkle terminalkommandoer, en forpliktelse og en trekkforespørsel for å løse problemet du har arkivert om denne artikkelen. Så, her er de grunnleggende trinnene.
rake post title = "din tittel" i din lokale kopi av depotetrake server og besøk http: // localhost: 4000 for å se på innlegget ditt (og resten av nettstedet)rake sjekk for å sikre at du ikke brøt noe. (Hvis du gjorde det, er det et emne for kommentar-tråden.)Hvis du ikke er snus på Jekyll eller Git / GitHub-ferdighetene dine ennå, kan du også be om hjelp til å rulle innlegget ditt i en forpliktelse. Kommenter på postens tilhørende utgave. Vær også sikker på å sjekke ut denne screencast på vår søsken Tuts + site, NetTuts.
Hvis du ikke har lagt merke til, handler hele denne innholdsopprettingsprosessen rundt koblede samtale / innholdstråder på GitHub. Dette gir en måte å kombinere en samtale med en tilhørende handling naturlig. Dette er en kritisk integrasjon for enhver form for samarbeid.
Nettstedet er avhengig av en Sass / Compass port av Twitter Bootstrap, så det er ikke noe overraskende innovativt om utformingen av nettstedet. Det er imidlertid også åpent for bidrag og samarbeid; Problemer arkivert på GitHub er ikke bare for samarbeid på postideer, men også for å påpeke unøyaktigheter, utilgjengelighet og feil. Selv om dette er tilfelle, er det noen som er velkommen til å sende inn problemer og trekke forespørsler for å bedre nettstedet på noen måte; tror at nettstedet kunne bruke en ny hud?
* Bli kjent er ikke relatert til å sende inn din forespørselsforespørsel.
Tilgjengelighetsprosjektet er utelukkende bygget med SASS og Compass; Hvis du vil sende inn noen designendringer, må du gjøre det ved å bruke SASS og Compass.
Mens noen kan vurdere dette som en begrensning, tjener det et formål. For det første gjør kodebasen mindre kompleks; Hvis prosjektet forsøkte å støtte vanilje CSS, LESS og SASS, ville resultatet medføre store avhengighets hodepine. Det vil også kreve bidragsytere til å oppdatere både LESS og SASS-filer - noe som er mye mindre sannsynlig å oppmuntre til engasjement. Til slutt, de som er drevet til å bidra, og har også ferdigheter eller kvalitetsinnhold til å bidra, vil enten allerede vite SASS, eller vil ha et middel til å lære det. Selv om dette virker eksklusivt, må vi også vurdere at dette på et eller annet tidspunkt er tilfelle med hvilken som helst teknologi; de som ikke vet (og ikke er villige til å lære) hvordan å integrere deres JavaScript med jQuery kan ikke skrive jQuery plugins.
Open-source er et utrolig kraftig verktøy. Bruke plattformer som GitHub og verktøy som Jekyll gjør åpen kilde skinne. Kommunikasjon integrert med arbeidsdokumenter er viktig for å samarbeide effektivt, spesielt hvis arbeidet som gjøres er parallelt med andre som gjør lignende arbeid.
Tilgjengelighetsprosjektet er et godt eksempel på at alle disse prinsippene kommer til å bli oppfylt. Med nesten 40 førsteklasses bidragsytere til dags dato, er det en visning av kraften til åpen kildekode og viljen til folk å samarbeide for å gjøre noe bra. Prosjektet oppstår svært lite eller ingen overhead for at dette nettstedet skal eksistere.
?
