Den moderna webbutvecklare som inte anser Ajax när man planerar eller bygger sina webbplatser missar potentiellt ett kraftfullt verktyg för att förbättra användbarheten.

Det finns dock utmaningar att implementera Ajax-funktionalitet på en webbsida.

I den här artikeln diskuterar vi lösningar på fem av de vanligaste utmaningarna som en utvecklare står inför när du använder Ajax för att förbättra innehållet på deras hemsida.

Även om det finns mycket mer att diskutera och undersöka om alla fem ämnen, bör det här inlägget ge nybörjare och mellanliggande Ajax-utvecklare några tips om hur man implementerar Ajax-funktionaliteten på ett mer användarvänligt och tillgängligt sätt .

Problem # 1: Innehållet är inte bakåt-kompatibelt

Det här problemet uppstår när en designer har införlivat JavaScript och Ajax-förbättringar i sin webbplatsarkitektur utan att göra bestämmelser för webbläsare som har inaktiverat JavaScript.

Ingenting är fel när du planerar en webbplats med JavaScript och Ajax. Faktum är att JavaScript-överväganden i själva verket bör vara integrerad i planeringsprocessen. Men du bör fortfarande se till att webbplatsen är bakåtkompatibel (eller att den försämras graciöst) vid lanseringen.

Lösning: Implementera Ajax som en förbättring till en redan fungerande webbplats

Medan Ajax kan vara en integrerad del av din planering av webbplatsens arkitektur, se till att allt innehåll är tillgängligt via konventionella server-sidor.

Låt oss säga att du har en "Medarbetarinformation" -sida som har en separat länk för varje anställd. Med hjälp av serverns teknik kan du visa innehållet för en viss anställd baserat på ett värde som passerat genom frågesträngen, så här:

Alla länkar ovan pekar på samma sida, sidan "Medarbetare" , som ändras enligt variabeln i frågesträngen. Varje medarbetares uppgifter skulle laddas från servern, vilket kan göras på ett antal sätt: via serverns sida ingår; genom en databas; eller till och med med hjälp av XML.

Vilken anställdslänk som helst klickar, hela sidan måste fyllas i för att den begärda informationen ska levereras.

Så, innehållet är fullt tillgängligt innan några Ajax-förbättringar läggs överst. Sedan kan du använda JavaScript, uppdateringen av hela sidan kan avbrytas och innehållet laddas istället via Ajax. Den klickade länken kunde identifieras med ett ID eller genom att kontrollera värdet av HREF-attributet i ankret.

Även om innehållet är fullt tillgängligt med JavaScript-avstängt, kommer de flesta användare att se den förbättrade Ajax-driven versionen.

Principen om progressiv förbättring för Ajax är välkänd, eftersom den vanligtvis används för diskreta JavaScript-tekniker och är inneboende i CSS, vilket illustreras av grafen nedan:

Ajax as an Enanchement Layer

Så bygg din webbplats för att fungera utan JavaScript, och lägg sedan till JavaScript som en förbättring, precis som du skulle markera ditt innehåll i HTML och sedan "förbättra" det med CSS.

Problem nr 2: Webbläsarens laddningsindikator utlöses inte av Ajax-förfrågningar

Nästan varje webbläsare har ett sätt att visuellt indikera för användaren att innehållet laddas. I nuvarande webbläsare visas indikatorn på fliken som laddar innehållet.

Bilderna nedan visar denna animerade indikator från några populära webbläsare.

IE Browser Loading
Internet Explorer laddningsindikator är en solid cirkel med en gradient som spinnar medan innehållet laddas.


Firefox Browser Loading
Firefox visar en liknande ikon av små snurrande cirklar i olika nyanser av grått.


Chrome Browser Loading
Google Chrome spinner en halvcirkel.

Problemet är att Ajax-förfrågningar inte utlöser denna "laddning" -indikator som är inbyggd i webbläsare.


Lösning: Sätt in en liknande laddningsindikator nära innehåll som laddas

Den gemensamma lösningen på detta är att införliva en anpassad framdriftsindikator i Ajax-förfrågan. Ett antal webbplatser erbjuder gratis "Ajax loading" -grafik.

Preloader.net
Preloaders.net har ett antal fina anpassningsbara animerade grafik att välja mellan.

Genomförandet av denna anpassade laddningsgrafik eller framdriftsindikator i din webbplatss Ajax-funktionalitet handlar helt enkelt om att visa och gömma det vid lämpliga tider via JavaScript.

Din Ajax-kod kommer att innehålla kodkod som berättar om begäran är igång eller slutförd. Med hjälp av JavaScript kan du visa den animerade grafiken medan förfrågan behandlas och sedan gömma den när åtgärden har slutförts.

Problem # 3: Användaren vet inte att en Ajax-förfrågan har slutförts

Detta är relaterat till det föregående problemet men misslyckas ofta, eftersom utvecklaren kan anta att försvinnandet av "laddning" -indikatorn är tillräcklig för att informera användaren om att innehållet har laddats helt. Men i de flesta fall är det definitivt bättre att indikera att innehållet har uppdaterats eller uppdaterats.

Lösning: Använd ett distinkt "Request Completed" -meddelande

Detta kan göras på samma sätt som formulärinsändningar bekräftas. Efter att en länk har lämnats in den Digg , kan du på så sätt mycket tydligt veta att din inlämning har mottagits:

Digg's Form Submitted Indicator

Även om den här indikatorn inte pekar på en slutförd Ajax-förfrågan, är principen densamma: "Succes" -fältet visas efter den sida som skickar formuläret slutfört, och rutan är färgstark och distinkt.

En liknande grafik eller indikator kan användas vid slutet av en Ajax-förfrågan för att berätta för användarna att innehållet har uppdaterats. Detta skulle genomföras utöver, istället för, den framstegsindikator som föreslogs för det tidigare problemet.

Ett liknande men subtilare sätt att ange att ett innehålls område har uppdaterats är gul blek teknik . Denna metod är bekant för användarna, diskreta och fungerar bra med Ajax-laddat innehåll.

Problem # 4: Ajax-förfrågningar kan inte komma åt webbtjänster från tredje part

De XMLHttpRequest objekt, som ligger till grund för alla Ajax-förfrågningar, är begränsat till att göra förfrågningar på samma domän som sidan som gör begäran. Men det finns fall där du vill få tillgång till tredje parts data via en Ajax-förfrågan. Många webbtjänster gör deras data tillgängliga via ett API.

Lösning: Använd din server som en proxy

Lösningen på det här problemet är att använda servern som en proxy mellan tjänsten och webbläsaren från tredje part. Även om detaljerna i den här lösningen ligger långt bortom omfattningen av denna artikel, går vi över grundprincipen på jobbet.

Eftersom en Ajax-förfrågan härstammar i klientens webbläsare måste den referera till en fil på en annan plats men på samma domän som källan till begäran.

Din server är emellertid, till skillnad från klientens webbläsare, inte begränsad på detta sätt. Så när sidan på din server heter, går den i bakgrunden som den normalt men med tillgång till någon domän.

Detta innebär inte någon säkerhetsrisk för användaren eftersom begäran om tjänsten från tredje part görs på din server. Så, när informationen har erhållits på servernivå, är nästa steg i Ajax-samtalet att skicka ett svar tillbaka till klienten, vilket i det här fallet skulle innehålla data som erhållits från den tredje partens webbtjänst.

Using Your Server as a Proxy to Access Web Services

Om du vill ha mer information om denna kraftfulla metod för att kombinera webbtjänståtkomst med anpassad Ajax, kolla definitivt andra resurser, varav några listas nedan.

Vidare läsning:

Problem # 5: Deep Linking är inte tillgängligt

Detta är ett svårare problem, men kanske inte krävs beroende på din typ av webbplats eller program. Problemet uppstår när innehåll laddas via Ajax och sedan ändras "tillståndet" på webbplatsen utan den webbadress som pekar på sidan som påverkas.

Om användaren återvänder till sidan via ett bokmärke eller delar länken med en vän visas det uppdaterade innehållet inte automatiskt. Webbplatsen skulle istället återgå till sitt ursprungliga tillstånd. Flash-webbplatser brukade ha samma problem: de låter inte användare koppla till något annat än den ursprungliga skärmen.

Lösning: Använd inre sidankroppar

För att säkerställa att en viss "stat" på en Ajax-driven webbsida är länkbar och bokmärkt kan du använda interna sidlänkar som ändrar webbadressen men inte uppdaterar sidan eller påverkar dess vertikala position.

Den här enkla koden visar hur det här görs:

var currentAnchor = document.location;currentAnchor = String(currentAnchor);currentAnchor = currentAnchor.split("#");if (currentAnchor.length > 1) {currentAnchor = currentAnchor[1];} else {currentAnchor = currentAnchor[0];}switch(currentAnchor) {case "section1":// load content for section 1break;case "section2":// load content for section 2break;case "section3":// load content for section 3break;default:// load content for section 1break;}

Ovanstående är inte ett fungerande kodstycke utan snarare ett teoretiskt exempel för att visa de viktigaste stegen som berörs.

De två första koderna anger den aktuella sidadressen (URL) i en variabel. Då konverteras platsen till en sträng så att vi kan manipulera den.

Därefter splittar vi strängen i två delar via ankarsymbolen (#) och kontrollerar sedan för att se om den matris som skapas från delningen är större än ett objekt. Större än ett objekt innebär att webbadressen har ett ankare.

Om webbadressen bara har en del betyder det att inget ankare är närvarande. Det efterföljande "switch" -förteckningen laddar innehållet enligt ankarets värde. Omkopplaren har ett "standard" alternativ om inget ankare är närvarande, vilket skulle vara detsamma som att ladda sidan i sitt ursprungliga tillstånd.

Dessutom skulle vi tillämpa kod för att hantera länkar som pekar direkt på specifikt innehåll genom interna ankare. En länk som pekar på "content2" skulle ladda innehållet i "content2" och strängen "# content2" skulle läggas till den aktuella webbadressen.

Detta skulle ändra webbadressen genom att lägga till ett internt ankare utan att ändra sidan på sidan utan att behålla en identifierare som anger önskad status på sidan.

Denna förklaring är bara teori. Konceptet fungerar, och det fungerar väldigt bra. Men jag har inte förklarat alla möjligheter, nackdelar och andra subtiliteter att bygga en webbplats eller sida på detta sätt.

Följ länkarna nedan för en mer omfattande diskussion om ämnet, eller experimentera med det själv. Observera också att detta kan testas med innehåll som ändras med JavaScript ensam, och behöver inte använda Ajax.

Vidare läsning:


Detta inlägg skrevs uteslutande för Webdesigner Depot av Louis Lazaris, en frilansskribent och webbutvecklare. Louis körs Imponerande Webs , där han postar artiklar och handledning om webbdesign. Du kan följa Louis på Twitter eller ta kontakt med honom genom sin hemsida .

Känner du till några lösningar på dessa eller andra Ajax-utmaningar? Vänligen dela dina kommentarer nedan ...