Riak on verkkopohjainen tiedontallennusjärjestelmä. Verkkopohjaisen tietojärjestelmän kehittämisprosessi

Alun perin sen tekijät pitivät World Wide Webiä (WWW) "tiedonjakotilaksi, jossa ihmiset ja tietokoneet voivat kommunikoida keskenään". Siksi ensimmäiset verkkosovellukset olivat alkeellisia tiedostopalvelimet, joka palautti staattisia HTML-sivuja niitä pyytäneille asiakkaille. Siten Web aloitti dokumenttilähtöisenä.

Seuraava vaihe Webin kehityksessä oli sovellusten käsitteen syntyminen, joka perustui CGI:n (tai FastCGI:n) kaltaisiin rajapintoihin ja myöhemmin ISAPI:iin. Common Gateway Interface (CGI) on tavallinen palvelinliitäntä, jonka avulla palvelinsovelluksia voidaan suorittaa URL-osoitteen kautta. Tällaisten sovellusten syöttötiedot olivat HTTP-otsikon sisältö (ja pyynnön runko käytettäessä POST-protokolla). CGI-sovellukset loivat HTML-koodin, joka palautettiin selaimeen. Suurin ongelma CGI-sovelluksissa oli se, että jokaisen asiakaspyynnön yhteydessä palvelin suoritti CGI-ohjelman reaaliajassa ja latasi sen erilliseen osoiteavaruuteen.

Internet Server API:n (ISAPI) tulo ei ainoastaan ​​ratkaissut CGI-sovelluksissa syntyneitä suorituskykyongelmia, vaan tarjosi kehittäjille myös rikkaamman ohjelmiston käyttöliittymä. ISAPI DLL:t voidaan liittää tiedostopäätteisiin erityisen metakannan kautta. Nämä kaksi mekanismia (CGI ja ISAPI) toimivat perustana ensimmäisen tyyppisten verkkosovellusten luomiselle, joissa asiakkaan toiminnoista riippuen suoritettiin palvelinkoodi. Siten Web-sivujen sisällön dynaaminen luominen tuli mahdolliseksi ja Webin sisältö lakkasi olemasta puhtaasti staattista.

ISAPI-liitäntä on ominaisuus Microsoft Internet Tietopalvelin. ISAPI-sovellukset ovat dynaamisia latauskirjastoja (DLL), jotka toimivat Web-palvelimen osoiteavaruudessa. Ajan myötä myös muut Web-palvelimet pystyivät ajamaan kirjastoina toteutettuja sovelluksia. Netscapen Web-palvelimien tapauksessa tätä ohjelmointirajapintaa kutsuttiin NSAPI:ksi (Netscape Server API). Aika suosittu Apache-verkkopalvelimet On myös mahdollista ajaa Web-sovelluksia kirjastoina; tällaisia ​​kirjastoja kutsutaan nimellä Apache DSO (Dynamic Shared Objects).

Luonnollisesti sekä CGI- että ISAPI-sovelluksia käytettäessä kehittäjät ratkaisivat pohjimmiltaan samat ongelmat, joten luonnollinen askel oli uuden, korkean tason käyttöliittymän syntyminen, joka yksinkertaisti HTML-koodin luomista, mahdollisti komponenttien ja tietokantojen käytön. ISAPI-suodattimen pohjalta rakennetusta Active Server Pages (ASP) -objektimallista tuli tällainen käyttöliittymä.

ASP:n pääidea sovellusrajapinnan luomisen kannalta on, että web-sivulla on koodinpätkiä, jotka Web-palvelin tulkitsee ja joiden sijaan käyttäjä saa näiden koodinpätkien suorittamisen tuloksen.

Pian ASP:n tulon jälkeen luotiin muita tekniikoita, jotka toteuttivat ajatuksen Web-palvelimen suorittaman koodin sijoittamisesta Web-sivun sisään. Tunnetuin niistä nykyään on JSP (Java Server Pages) -tekniikka, jonka perusideana on Java-koodin (servlet) kertakäyttöinen kokoelma ensimmäisellä käyttökerralla, tämän servletin menetelmien suorittaminen ja sijoittamalla näiden menetelmien suorittamisen tulokset selaimeen lähetettyyn tietosarjaan.

Uusin versio Aktiiviset tekniikat Server Pages on ASP .NET, joka on avain Microsoft .NET Framework -arkkitehtuuriin. ASP .NET:n avulla voit luoda Web-sovelluksia ja verkkopalveluita, joiden avulla voit toteuttaa dynaamisen HTML-sivujen luomisen, mutta myös integroida palvelinkomponentteihin ja joita voidaan käyttää ratkaisemaan monenlaisia ​​liiketoimintaongelmia, jotka ilmenevät nykyaikaisten järjestelmien kehittäjille. Web-sovellukset.

Yleensä Web-palvelinasiakas ei voi olla vain henkilökohtainen tietokone, joka on varustettu tavallisella Web-selaimella. Mobiililaitteiden laajan käytön myötä on noussut esiin myös ongelma tarjota web-palvelimille tietoa, jota nämä laitteet voivat tulkita. Koska mobiililaitteilla on erilaiset ominaisuudet kuin henkilökohtaiset tietokoneet(rajoite näytön koko, pieni muisti ja usein kyvyttömyys näyttää muuta kuin muutaman rivin mustavalkoista tekstiä), niille on olemassa muita tiedonsiirtoprotokollia (WAP - Wireless Access Protocol) ja vastaavat merkintäkielet ( WML - Wireless Markup Language, СHTML - Compact HTML jne.). Tällöin tehtävänä on siirtää tiedot mobiililaitteeseen sopivassa muodossa (ja tätä tarkoitusta varten on olemassa erityisiä sivustoja), tai mikä näyttää mukavammalta, laitteen tyyppi tunnistetaan, kun se ottaa yhteyttä palvelimeen ja lähdedokumentti muunnetaan (esim XML-muoto) tietyn mobiililaitteen vaatimaan muotoon (esimerkiksi XSLT-muunnoksen avulla).

Toinen tapa tukea erityyppisiä asiakkaita on luoda "älykkäitä" palvelinkomponentteja, jotka voivat luoda eri koodi riippuen asiakastyypistä. Tämä lähestymistapa on toteutettu erityisesti Microsoft ASP .NET:ssä.

Toinen suunta web-sovellusten asiakasosien kehityksessä on ollut sovelluksen logiikan osan sijoittaminen (kuten syötetietojen oikeellisuuden tarkistaminen) itse web-selaimeen. Erityisesti nykyaikaiset verkkoselaimet pystyvät tulkitsemaan komentosarjakieliä (VBScript, JavaScript), koodia, joka, kuten ASP-koodi, on upotettu Web-sivulle, mutta jota ei tulkitse Web-palvelin, vaan selain ja , vastaavasti suoritetaan asiakaslaitteella. Lisäksi nykyaikaiset selaimet pystyvät näyttämään ja suorittamaan Java-sovelmia - erityisiä Java-sovelluksia, jotka käyttäjä saa osana Web-sivua, ja jotkut selaimet voivat toimia myös ActiveX-komponenttien säilöinä - jotka toimivat erityisten COM-palvelimien selaimen osoiteavaruudessa. , myös osana Web-sivua. Sekä Java-sovelmat että ActiveX-komponentit voivat toteuttaa melkein mitä tahansa toimintoja.

Huomaa, että käytetyn datan määrän ja verkkosivustojen vierailijoiden määrän kasvaessa myös verkkosovellusten luotettavuuden, suorituskyvyn ja skaalautuvuuden vaatimukset kasvavat. Seuraava vaihe tällaisten sovellusten kehityksessä oli verkkosovelluksessa toteutetun liiketoimintalogiikan ja usein tietojenkäsittely- ja tapahtumapalveluiden erottaminen sen käyttöliittymästä. Tällöin ns. esitysosa jää yleensä itse web-sovellukseen ja liiketoimintalogiikka, tietojenkäsittely ja tapahtumatoteutus siirretään sovelluspalvelimelle bisnesobjektien muodossa. Sovelluspalvelimen tyypistä riippuen nämä liiketoimintaobjektit voivat olla itsesuorittavia COM-palvelimia, CORBA-palvelimia tai palveluita käyttäviä COM+-objekteja. Windowsin komponentit 2000 tai EJB:t (Enterprise Java Beans), jotka suorittaa J2EE (Java 2 Enterprise Edition) -spesifikaatiota tukeva sovelluspalvelin. Tällaiset objektit voivat käyttää OLE DB:tä, ODBC:tä, JDBC:tä tietojen käyttömekanismina (tämä riippuu siitä, kuinka liiketoimintaobjekti on toteutettu).

Usein tällaiset liikeobjektit tarjoavat pääsyn yrityksen tietojärjestelmien tietoihin tai toteuttavat osan niiden toiminnoista. Usein ne mahdollistavat esimerkiksi verkkosivuston integroinnin CRM- (Customer Relationship Management)- tai ERP- (Enterprise Resource Planning) -järjestelmiin, sivuston vierailijoiden tietojen tallentamisen yritysjärjestelmiin ja potentiaalisille asiakkaille tilauksen tekemiseen tarvittavien tietojen tarjoamisen.

Koska nykyaikainen Internet ei ole niinkään väline yrityksen läsnäolon osoittamiseen markkinoilla tai markkinointiväline, vaan pikemminkin liiketoiminnan väline, tällaisten asiakassuhteiden järjestäminen Internetin kautta muuttuu tehtäviksi, kuten tavaroiden ja palveluiden myynti. melko tärkeä. Ja tässä päätökset verkkokauppa kirjoita "yritysasiakas" (B2C - business-to-consumer). Yhtä tärkeitä tehtäviä ovat Web-sovellusten integrointi kumppanien dataan ja sovelluksiin yritysten välisen (B2B - business-to-business) -järjestelmän toteuttamiseksi, joka mahdollistaa yritysten välisen kaupankäynnin, tuoteluetteloiden vaihdon, huutokaupat, sähköisten kaupankäyntialustojen luominen.

Huomaa, että tällaisen ratkaisun kiinteänä osana web-palvelimen tulee pystyä paitsi ajamaan sovelluksia ja olemaan vuorovaikutuksessa sovelluspalvelimen kanssa, myös käyttämään integraatiopalveluita, sovellus- ja tiedonhallintapalveluita sekä kehittäjille tarkoitettuja palveluita.

Seuraava askel Web-sovellusten kehityksessä on yritys- ja kumppanitietojen käytön lisäksi pääsyn saaminen yrityssovelluksiin. Tämän ongelman ratkaisemiseksi, joka liittyy verkkosovellusten integrointiin yritysten sisäisiin tietojärjestelmiin ja sovelluksiin, jotka varmistavat vuorovaikutuksen asiakkaiden ja kumppaneiden kanssa, käytetään erikoisratkaisuja, joita kutsutaan yritysportaaleiksi.

Usein osa portaaliratkaisua ovat työkaluja Verkkosivuston sisällön - loppujen lopuksi tietomäärän - hallintaan käyttäjien saatavilla käyttämällä verkkosivustoja suuret yritykset ja portaalit, on nyt sellainen, että näiden tietojen "manuaalinen" hallinta ei ole mahdollista.

Yhteenvetona yllä olevasta voimme korostaa verkkoarkkitehtuurin pääpiirteitä [, ]:

• ei tarvitse käyttää lisäohjelmistoja asiakaspuolella - tämän avulla voit toteuttaa asiakasosan automaattisesti kaikilla alustoilla;
• kyky yhdistää lähes rajoittamaton määrä asiakkaita;
• yhden tiedon tallennuspaikan ja tietokannan hallintajärjestelmän ansiosta, vähimmäisvaatimukset säilyttää tietojen eheys;
• käytettävyys, kun palvelin ja viestintäkanavat ovat toiminnassa;
• ei ole käytettävissä, jos palvelin tai viestintäkanavat eivät ole toiminnassa;
• Web-palvelimen ja tiedonsiirtokanavien melko alhainen nopeus;
• Tietomäärän suhteen Web-järjestelmien arkkitehtuurilla ei ole merkittäviä rajoituksia.

Kaavamaisesti tällainen arkkitehtuuri (kolmitasoisessa versiossa) voidaan esittää kuvan 1 mukaisesti. 5.9.

Riisi. 5.9.

5.1.8. Palvelukeskeinen arkkitehtuuri

Ratkaisu moniin yllä kuvattuihin ongelmiin, joita syntyy luotaessa nykyaikaisia ​​Web-sovelluksia, on nyt alkanut kohdistaa Web-palveluihin - alustaan, objektimalliin ja asiakasriippumattomiin ohjelmistokomponentteihin, joita voidaan kutsua as(sekä Webistä). itse palvelut ) HTTP-protokollan kautta ja XML-kieli SOAP-protokolla. Web-palveluiden kuvaamiseen käytetään XML-tyyppistä WSDL-kieltä ja UDDI-rajapinnalla web-palvelurekisterit, joista kehittäjät ja yritykset voivat etsiä tarvitsemiaan palveluita sekä julkaista tietoja palveluistaan.

Verkkopalveluiden tuesta on tullut tärkeä strateginen painopiste monille sovelluspalvelimiin, tietokantojen hallintajärjestelmiin ja sovellusten kehitystyökaluihin erikoistuneille yrityksille.

(SOA, palvelukeskeinen arkkitehtuuri) – modulaarinen lähestymistapa kehitykseen ohjelmisto, joka perustuu palvelujen (palveluiden) käyttöön standardoiduilla liitännöillä.

OASIS (Organization for Open Standards for Structured Information) määrittelee SOA:n seuraavasti (OASIS Reference Model for Service Oriented Architecture V 1.0): Service Oriented Architecture on paradigma hajautettujen tietoresurssien, kuten sovellusten ja tietojen, järjestämiseen ja käyttämiseen eri omistajien vastuulla. saavuttaa halutut tulokset kuluttajan toimesta, joka voi olla loppukäyttäjä tai muu sovellus.

SOA perustuu uudelleenkäytettävyysperiaatteisiin toiminnallisia elementtejä IT, ohjelmistojen päällekkäisyyden poistaminen, vakiotoimintaprosessien yhtenäistäminen, yrityksen toimintamallin siirtämisen varmistaminen keskitettyihin prosesseihin ja teolliseen integraatioalustaan ​​perustuva toimiva organisaatio.

Ohjelman osat voidaan jakaa eri puolille eri solmuja verkkoihin, ja niitä tarjotaan itsenäisinä, löyhästi kytkettyinä, vaihdettavina sovelluspalveluina. Ohjelmistojärjestelmät SOA:n mukaisesti kehitettyinä ne toteutetaan usein verkkopalveluiden kokonaisuutena, joka on integroitu käyttäen tunnettuja standardiprotokollia (SOAP, WSDL jne.).

SOA-ohjelman komponenttirajapinta tarjoaa tietyn komponentin (käyttöjärjestelmä, alusta, ohjelmointikieli, toimittaja jne.) toteutustietojen kapseloinnin muista komponenteista. Näin ollen SOA tarjoaa joustavan ja tyylikkään tavan yhdistää ja käyttää uudelleen komponentteja monimutkaisten hajautettujen ohjelmistojärjestelmien rakentamiseen.

SOA on osoittautunut hyvin suurten yritysten rakentamiseen ohjelmistosovelluksia. Useat kehittäjät ja integraattorit tarjoavat SOA-pohjaisia ​​työkaluja ja ratkaisuja (esimerkiksi IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, IVC Jupiter, TIBCO, Diasoft alustat).

SOA:n käytön päätavoitteet suurissa tietojärjestelmissä, yritystasolla ja sitä korkeammissa ovat:

• vähentää sovelluskehityksen kustannuksia virtaviivaistamalla kehitysprosessia;
• koodin uudelleenkäytön parantaminen;
• riippumattomuus käytetyistä alustoista, työkaluista ja kehityskielistä;
• luotujen järjestelmien skaalautuvuuden lisääminen;
• luotujen järjestelmien ohjattavuuden parantaminen.

SOA-periaatteet:

• arkkitehtuuri sellaisenaan ei ole sidottu mihinkään tiettyyn tekniikkaan;
• järjestelmän organisaation riippumattomuus käytetystä laskenta-alusta(alustat);
• järjestelmän organisaation riippumattomuus käytetyistä ohjelmointikielistä;
• tietyistä sovelluksista riippumattomien palvelujen käyttö yhtenäisin käyttöliittymin;
• palveluiden järjestäminen löyhästi kytketyiksi komponenteiksi kiinteistöjärjestelmiin.

Arkkitehtuuri ei ole sidottu mihinkään tiettyyn tekniikkaan. Se voidaan toteuttaa käyttämällä laajaa valikoimaa teknologioita, mukaan lukien tekniikat, kuten REST, RPC, DCOM, CORBA tai verkkopalvelut. SOA voidaan toteuttaa jollakin näistä protokollista ja se voi esimerkiksi käyttää lisäksi mekanismia tiedostojärjestelmä, tiedonvaihtoa varten.

Pääasia, joka erottaa SOA:sta, on itsenäisten palveluiden käyttö selkeästi määritellyillä rajapinnoilla, joita tehtäviensä suorittamiseksi jotkut voivat kutsua. tavallisella tavalla, edellyttäen, että palvelut eivät tiedä etukäteen mitään niille kutsuvasta sovelluksesta ja sovellus ei tiedä, kuinka palvelut suorittavat tehtävänsä.

SOA voidaan ajatella myös tietojärjestelmäarkkitehtuurityylinä, joka mahdollistaa sovelluksia, jotka on rakennettu yhdistämällä löyhästi kytkettyjä ja yhteentoimivia palveluita. Nämä palvelut toimivat vuorovaikutuksessa jonkin tiukasti määritellyn alustariippumattoman ja kieliriippumattoman käyttöliittymän (esimerkiksi WSDL) perusteella. Käyttöliittymän määritelmä piilottaa palvelun kielikohtaisen toteutuksen.

Siten SOA-pohjaiset järjestelmät voivat olla riippumattomia kehitysteknologioista ja -alustoista (kuten Java, .NET jne.). Esimerkiksi C#-kielellä kirjoitetut .Net-alustoilla ja Java EE -alustoilla Java-kielellä kirjoitetut palvelut voidaan kutsua yleisellä yhdistelmäsovelluksella yhtä menestyksekkäästi. Joillakin alustoilla toimivat sovellukset voivat kutsua muilla alustoilla toimivia palveluita, mikä helpottaa sitä uudelleenkäyttö komponentit.

, , Pääte , Sovelluspalvelin , Tietokantapalvelin , Hajautettu järjestelmäarkkitehtuuri , , Palvelukeskeinen arkkitehtuuri .

Tällä hetkellä tarjoavien verkkosivustojen määrä erilaisia ​​palveluita pääsy dynaamisiin tietoihin. Tällaiset verkkosivustot eivät ole enää vain strukturoitua staattisen tiedon joukkoa, vaan vaihtelevan monimutkaisuuden tietojärjestelmiä, joita kutsumme web-orientoituneiksi, ts. käyttämällä verkkokäyttöliittymää pääasiallisena vuorovaikutuksen välineenä käyttäjän kanssa.

Tämän työn tarkoituksena on analysoida verkkopohjaisia ​​tietojärjestelmiä ja tuoda esiin yhteisiä lähestymistapoja niiden kehittämiseen.

Tietojärjestelmien päätehtävä on tiettyyn aihealueeseen liittyvän tiedon luominen, käsittely ja tallentaminen. Useimmat tietojärjestelmät käyttävät relaatiotietokantoja tiedon tallentamiseen. Verkkopohjaisissa tietojärjestelmissä tämä tietojen tallennustapa on myös parempi. Siksi ensimmäinen välttämätön komponentti on tietokanta, joka tallentaa tiedot ja metatiedot tietojärjestelmä.

Seuraava verkkopohjaisten tietojärjestelmien yhteinen piirre on, että käyttäjillä on oltava erilaiset oikeudet suorittaa erilaisia ​​toimintoja tietojärjestelmätiedoilla. Useimmissa verkkopohjaisissa tietojärjestelmissä kaikki käyttäjät voidaan jakaa kahteen luokkaan - rekisteröityneisiin ja rekisteröimättömiin. Rekisteröimättömät käyttäjät yhdistetään yleensä järjestelmän yhteen käyttäjään, jolla on vähiten oikeuksia. Siksi web-pohjaisen tietojärjestelmän toinen välttämätön komponentti on todennusalijärjestelmä, joka suorittaa seuraavat päätehtävät.

Ensisijaisen käyttäjän todennuksen suorittaa käyttäjä syöttämällä käyttäjätunnuksensa ja salasanansa.

Automaattinen todennus. Ensimmäisen todennuksen jälkeen käyttäjälle annetaan istuntotunniste (token). Myöhemmissä pyynnöissä tämä tunnus tunnistaa käyttäjän automaattisesti.

Siten autentikointialijärjestelmä muodostaa perustan rajoittaa käyttäjien pääsyä järjestelmässä kiertävään tietoon. Siksi kolmas yhteinen komponentti Verkkopohjainen tietojärjestelmä on kulunvalvontaalijärjestelmä, jonka on suoritettava seuraavat päätehtävät:

Nykyisen käyttäjän oikeuksien määrittäminen;

Käyttöoikeuksien määrittäminen;

Oikeuksien automaattinen muutos tiettyjen tapahtumien sattuessa.

Tällä hetkellä kulunvalvontaalijärjestelmän toteuttamiseen käytetään pääasiassa toiminnallisten ja modulaaristen lähestymistapojen yhdistelmää. Erilaisia ​​luokkia aihealueen tiedot käsitellään erillisillä järjestelmän skripteillä (moduuleilla) ja se toteuttaa koko tarvittavan joukon toimintoja yhden kategorian tietojen käsittelyyn. Tässä tapauksessa tietyn suojauspolitiikan toteuttava kulunvalvontaalijärjestelmä on "hajallaan". lähdekoodeja tietojärjestelmä.

Monilla verkkopohjaisilla järjestelmillä on taipumus laajentua, ja usein kehitysprosessi jatkuu jatkuvasti melko pitkään tietojärjestelmän toiminnan rinnalla. Aina ei kuitenkaan ole mahdollista heti ennakoida ja ennakoida mahdollisia kehityspolkuja. Siksi on edullista, että järjestelmää voidaan laajentaa suhteellisen helposti. Valitettavasti yllä oleva lähestymistapa tekee laajennusprosessista erittäin vaikeaa.

Tämän ongelman ratkaisemiseksi ehdotetaan seuraavaa lähestymistapaa. Otetaan käyttöön käsite tietoobjekti, joka on joukko tietoja ja menetelmiä, jotka liittyvät tietyn luokan (tietokategorian) yhteen esiintymään ja on turvallisuuspolitiikan sääntöjen soveltamisyksikkö, ts. tietoobjekti on perusyksikkö tietojärjestelmään toteutettu kulunvalvontataso. Sitten kaikki muut web-suuntautuneen järjestelmän komponentit voidaan liittää tiedonhallintaalijärjestelmään, joka esitetään tietoobjekteina.

Tämä konsepti luo vahvan perustan tietojärjestelmän itsensä kehittämiselle.

Näin ollen verkkopohjaisten tietojärjestelmien kehittämisen yleisten lähestymistapojen analyysin perusteella on mahdollista merkittävästi lisätä kehittämisen ja edelleen kehittäminen määritellyistä tietojärjestelmistä, alentaa ylläpitokustannuksia ja hankkia järjestelmä, joka pystyy toteuttamaan joustavasti vaaditun monimutkaisen tietoturvapolitiikan.

1. Braude E. D. Ohjelmistokehitystekniikka. – Pietari: Pietari, 2004, – 656 s.

Web-sivustoista verkkosovelluksiin

Osa 1. Verkkosivusto vai verkkosovellus?

Hyväksyä oikeita päätöksiä analysoimalla läsnäoloasi verkossa

Sisältösarja:

iPadien, iPhonejen, Androidien ja sovelluksiin keskittyvien laitteiden maailmassamme ei ole enää modernia sanoa: "Minulla on staattinen Web-sivusto." Jos sinulla ei ole kehittynyttä hakukonetta, vähintään kolmea maksutapaa ja pari sivua, joilla on hankala Ajax-vuorovaikutus, sinua voidaan kutsua "juttuneeksi 1990-luvulle". Monien kehittäjien on tehtävä joitain temppuja vastatakseen johdon pyyntöihin: Lisää interaktiivisuutta! Pysy ajan tasalla Amazon.comin tai Bingin tai IBM:n kanssa! Tee Web-sivusto... Web-sovellus. Jos kuitenkin laajennat olemassa olevia sivustoja, tuloksena voi olla vähemmän keskittynyt ja joskus vähemmän toimiva Web-näkyvyys.

Web-sivustot eroavat pohjimmiltaan Web-sovelluksista. Jos rakennat Web-sovelluksia, sinun on tiedettävä, mikä erottaa ne tavallisesta Web-sivustosta. Ja jos olet tottunut luomaan staattisia sivuja ilman JavaScriptiä, saatat joutua muuttamaan sivustosi verkkosovellukseksi.

Tässä artikkelissa opit tekemään tietoisia päätöksiä, jotka auttavat Web-projektejasi saavuttamaan tavoitteensa. Opit Web-sivustojen ja verkkosovellusten eroista ja siitä, miten nämä kaksi käsitettä eroavat toisistaan. Kun ymmärrät tärkeimmät erot, olet valmis tekemään (tai ainakin vaikuttamaan) päätöksiä siitä, miltä Web-läsnäolosi tulisi näyttää.

Verkkosivustojen ei tarvitse olla verkkosovelluksia

On tilanteita, joissa sinulla on verkkosivusto ja Ei hyvä syy muuntaa se verkkosovellukseksi. Tai joskus ihmiset viettävät paljon aikaa verkkosovelluksen luomiseen ja parantamiseen, mutta sen parantamisen sijaan he vain juoksevat ympyrää. Ehkä olisi parempi olla tekemättä kaikkea tätä työtä ja pitäytyä melko yksinkertaisessa Web-sivustossa. Tässä osiossa esittelemme Web-sivustojen ja verkkosovellusten väliset erot.

Verkkosivustot ovat ensisijaisesti tiedotustarkoituksiin

Täysin staattisen Web-sivuston yksinkertaisin määritelmä on sana tiedottava. Klassinen esimerkki tällaisesta sivustosta on Wikipedia, joka oli tarkoitettu pelkästään tiedotussivustoksi. Wikipedian ulkoasu ei ole silmiinpistävä tai jännittävä, eikä se ole täynnä ponnahdusikkunoita ja karttoja vierityspalkeilla. Kuten kuvasta 1 näkyy, sen sisältö on yksinkertaisesti informaatiota, joka on esitetty hieman monimutkaisemmassa muodossa kuin hyperlinkkisanakirja.

Kuva 1. Esimerkki Wikipedia-sivusta

Usein paras tapa välittää tietoa on yksinkertaisten staattisten Web-sivustojen kautta. Jos tavoitteesi on levittää tietoa tuotteesta, palvelusta tai itse tiedosta, Web-sivusto on hyvä lähtökohta. Tietenkin Web-sivustot joutuvat käsittelemään pushbackia. Ne eivät ole havaittavissa, ne eivät ole millään tavalla yhteydessä Twitterin maailmaan. Kuitenkin useimmat ihmiset tapaaessaan uusi aihe Wikipediaa kuullaan edelleen, joten staattiset sivustot voivat olla arvokkaita.

Verkkosivustot voivat olla dynaamisia

Useimmat blogit ovat itse asiassa web-sivustoja. Vaikka blogeja hallinnoivat ohjelmat, kuten WordPress tai Movable Type, ne johtavat tietosivustoihin, jotka koostuvat pääasiassa yksinkertaisista, ei-interaktiivisista sivuista. Tämä korostaa tärkeän eron: Web-sivustoa ei määritetä sen perusteella, miten se on luotu, vaan se, miten vierailijat käyttävät sen tarjoamia tietoja ja ominaisuuksia. Tämän eron ymmärtäminen voi auttaa sinua keskittymään siihen, miltä Web-läsnäolosi näyttää käyttäjän näkökulmasta.

Alkuvaiheessa kannattaa keskittyä sivuston käyttökokemukseen. Käyttäjä ei ole kiinnostunut siitä, mille tekniikoille sivustosi on rakennettu: HTML ja CSS, ColdFusion, PHP tai Perl. Käyttäjät yksinkertaisesti arvioivat sivuston sen perusteella, mitä he näkevät. Jotta ymmärrät, minkä tyyppistä sivustoa olet luomassa tai tutkit, sinun on pidettävä pieni tauko ohjelmointiin. Avaa vain selain, käy sivustollasi ja arvioi se.

Verkkosovellukset ovat yleensä interaktiivisia

Jos sivustosi ei ole informatiivinen, se on todennäköisesti interaktiivinen. Tämä tarkoittaa, että käyttäjä ei ole passiivinen kuluttaja, vaan aktiivinen osallistuja sivustolle. Käyttäjä tekee hakuja, painaa painikkeita, täyttää lomakkeita, tekee ostoksia ja yleensä työskentelee näppäimistön ja hiiren kanssa koko ajan.

Tietokonepeliä voidaan pitää interaktiivisuuden standardina. Pelissä käyttäjät ovat jatkuvasti vuorovaikutuksessa tietokoneen kanssa. Ampuvatpa he zombeja tai kävelevät miinakentän läpi, pelaajat painavat jatkuvasti painikkeita ja tekevät päätöksiä, jotka edellyttävät heidän painamista uudelleen ja niin edelleen. Tietenkin useimmat verkkosivustot eivät saavuta tätä interaktiivisuuden tasoa.

Useimmat Web-sivustot ovat jossain määrin hybridejä. Katso esimerkiksi Amazon.comin kotisivua, joka näkyy kuvassa 2. Amazon.com on hybridi, joka on kuitenkin tietosivusto.

Kuva 2. Amazon.com

Yllä näkyvä näyttö tarjoaa paljon tietoa. Kirjat, kirjailijat, hinnat ja luokat ovat kaikki erilaisia ​​tietoja. Tällä sivulla käyttäjän päätavoite on kuitenkin vuorovaikutus. Käyttäjä voi siirtyä mihin tahansa tuoteluokkaan. Tai hän voi tutustua kirjaan yksityiskohtaisesti ja ostaa sen. Käyttäjä voi etsiä tai nähdä, mitä hänen ostoskorissaan on. Kaikki nämä ovat erityyppisiä vuorovaikutuksia.

Koska mikä tahansa verkkosivusto edustaa minkä tahansa Tietoa, sinun on määritettävä tasapaino tiedon ja vuorovaikutteisuuden välillä. Mitä teet enemmän: luet vai olet vuorovaikutuksessa? Käytätkö yhdellä sivulla 30 sekuntia vai 10 minuuttia? Jos olet paljon vuorovaikutuksessa ja vietät vähän aikaa kullakin sivulla, sinulla on interaktiivinen sivusto.

Mitä eroa on tiedottavilla ja interaktiivisilla sivustoilla?

Toistaiseksi olemme keskustelleet melko yksinkertaisesta tavasta arvioida verkkosivustoja. Sivusto on joko informatiivinen tai interaktiivinen. Musta tai valkoinen.

Useimmat interaktiiviset verkkosivustot ovat itse asiassa hybridejä. Jos tietoa ei ole, käy ilmi, ettei ole mitään, jolla se olisi mahdollista olla vuorovaikutuksessa. Kuvittele, millaista olisi, jos Amazon.com-sivustolla olisi vain painikkeita – ei kirjoja, ei DVD-levyjä. Sivustolla ei olisi järkeä. Sinulla on oltava joitain tietoja työskennelläksesi. Siten jopa interaktiiviset sivustot ovat itse asiassa hybridejä: tiedon ja vuorovaikutuksen yhdistelmä.

Saatat kysyä: miksi edes ajatella eroja interaktiivisten ja informatiivisten sivustojen välillä? On tärkeää ajatella eri tavalla sivustosta, jonka kautta haluat tarjota tietoa käyttäjille, ja sivustosta, jonka kautta haluat tarjota interaktiivisuutta. Nämä näkemyserot ohjaavat useimpia tärkeimpiä suunnittelupäätöksiäsi. Vaikka luot harvoin puhtaasti informatiivisia tai puhtaasti interaktiivisia sivustoja, on tärkeää määrittää, mihin sivustosi suuntautuu.

Tiedot toimitetaan parhaiten ilman käsittelyä

Jos sivustosi on enemmän tietoa sisältävä, tämä määrittää sen käytön skenaarion: käytä sitä tiedon välittämiseen yleisöllesi. Tämän jälkeen jää vain määrittää toteutustavat. Koska käyttäjät tarvitsevat tietoa, mikä on paras tapa välittää tiedot? Mikä on paras tapa esittää dataa, jota on yleensä saatavilla suuria määriä, verkossa luettavaksi?

Tällä hetkellä kaverit tekevät e-kirjoja, parannetut painokset ja seuraavan sukupolven julkaisutuotteet alkavat heiluttaa käsiään innoissaan. Tietoa tulee välittää uudelle lukijasukupolvelle nykyaikaiset keinot, eikö? Tietojen esittämiseen on uusia tapoja: kelluvat merkinnät, lisätietoa sisältävät ponnahdusikkunat ja upotetut videot.

Kyllä, siellä on paikka laajemmalle tiedolle.

En väitä, että sinun pitäisi välttää lisättyä mediaa tai että sinun ei pitäisi yrittää ylittää rajoja, mikä on mahdollista Web 2.0/3.0 -tyylisen lähestymistavan avulla. Tällaisten työkalujen tarkoituksena ei kuitenkaan ole varsinaisesti tiedon saaminen ulos nopeasti ja tehokkaasti. Suurin osa uusista tiedon esitystavoista on käytössä immersiivisissä ja jopa viihdesovelluksissa. Nämä menetelmät eivät vain välitä tietoa, vaan ne muuttavat sen havaitsemismekanismia.

Tietosivusto ei yritä olla kokeellinen. Jos sivustosi tarkoitus on viihde, tarvitset interaktiivisen sivuston.

Ongelma tällaisessa ajattelussa on, että se olettaa, että historialla on vähän merkitystä ja että käyttäjissä ei ole hitautta. Ihmiset tottui siihen lue kirjoja, lue sanakirjoja, lue Wikipediaa. He lukevat siirtämällä silmänsä sivun yläreunasta alas ja monilla kielillä vasemmalta oikealle. He lukevat paljon tekstiä ja yleensä lukevat sen häiriintymättä. Itse asiassa he haluta Lue nämä tiedot häiritsemättä.

Tietoa sisältävien sivustojen ei pitäisi pyrkiä olemaan räikeimpiä, houkuttelevimpia ja monipuolisimpia sivustoja. Samalla on runsaasti mahdollisuuksia Esimerkkejä kuvien käyttämisestä havainnollistamiseen löydät suosituilta sivustoilta, kuten dictionary.com, Wikipedia ja muut paljon tekstiä sisältävät sivustot. Erilaisten visuaalisten elementtien käyttöä kannattaa ehdottomasti harkita: kokeile eri fonttien käyttöä ja tee sivustosi navigoinnista helppoa ja selkeää. Annat pääsyn tietoihin, joten kaikki, mikä häiritsee sitä, toimii lopulta sinua vastaan.

Interaktiivisuus perustuu jaksoittaiseen toimintaan

Mikä erottaa interaktiiviset sivustot tietoa tarjoavista sivustoista? Jos tiedottavat sivustot yrittävät häiritä käyttäjää mahdollisimman vähän, interaktiiviset sivustot yrittävät tehdä tämän mahdollisimman paljon. Sivustosi pitäisi saada käyttäjät jatkuvasti haluamaan napsauttamaan, vetämään tai korostamaan jotain. Luot ympäristön, jossa voit siirtää tietoa suuntaan tai toiseen. Enää ei riitä, että käyttäjät lukevat passiivisesti tekstiä ja katselevat kuvia tehdä päästäkseen eteenpäin.

Siksi interaktiivisuuden avaimeksi tulee näiden keskeytysten toteuttaminen. Sinun on oltava tietoinen kosketuspisteiden luomisessa. Jos sivustollasi on paikkoja, joihin voit mennä yksinomaan Hyperlinkkejä käyttämällä saatat tehdä huonoa työtä tietojen ja vuorovaikutusten suunnittelussa. Toisaalta, jos käyttäjän on napsautettava painiketta, täytettävä lomake ja sitten laajennettava osio tarvitsemillaan tiedoilla, olet todennäköisesti menossa oikeaan suuntaan.

Toinen tapa ratkaista vuorovaikutteisuuden upottaminen verkkosivustoon on sekvenssikartan rakentaminen. Ota kuvakaappaus tietty sivu ja päätä sitten, mitä haluat nähdä Seuraava sivustosi sivu. Ota toinen kuvakaappaus, sitten toinen ja niin edelleen, kunnes sinulla on neljä tai viisi (tai kymmenen) kuvakaappausta, jotka havainnollistavat vaiheita, joilla käyttäjä viedään pisteestä A pisteeseen B.

Määritä, kuinka käyttäjä siirtyy näytöltä toiselle. Napsautako hän tavallista linkkiä? Painaako hän nappia? Kuinka paljon hän liikuttaa hiirtä? Kuinka paljon toimintaa tapahtuu näytöllä? Mikä on käyttäjä tekee? Tämä mahtava keino määrittää, mitä keskeytyksiä pitäisi olla. Kuinka usein käyttäjän tulee olla mukana päättämässä, minne mennä seuraavaksi? Kuinka monta keskeytysvaihtoehtoa tarjoat, jos käyttäjä ei ole mukana päätöksenteossa?

Esimerkki interaktiivisesta sivustosta: Audi.com

Katsotaanpa esimerkkiä nähdäksesi, kuinka hyödyllinen reittikartta voi olla. Tutustu yhden johtavien luksusautojen valmistajien Web-sivustojen sarjaan. Koska tämä sivusto tarjoaa erittäin kalliita ostoksia, sivusto on pakko houkutella ja yllättää käyttäjä.

Kuva 3 näyttää Audi.com-sivuston aloitussivun. Sivusto näyttää kiiltävältä jo ennen kuin olet vuorovaikutuksessa sen kanssa.

Kuva 3. Audi.com-kotisivu

Käyttäjä voi välittömästi aloittaa vuorovaikutuksen sivuston kanssa. Kuva 4 näyttää miltä sivusto näyttää hiiren napsautuksen jälkeen. Auton alla on useita värillisiä kappaleita, joista minkä tahansa napsauttaminen muuttaa auton värin välittömästi. Hakematta valikoista tai muualta, käyttäjä voi heti aloittaa vuorovaikutuksen sivun kanssa.

Kuva 4. Audin verkkosivun aloitussivun kuva muuttuu hiiren napsautuksella

Päällä tässä vaiheessa Audi.com käyttää paljon suhteellisen vanhaa tekniikkaa. Valikot, jotka avautuvat, kun viet hiiren niiden päälle, eivät ole mitään uutta. Tämä oli jotain, joka voitiin tehdä DreamWeaverilla kauan sitten. Audin verkkosivusto yrittää kuitenkin olla interaktiivinen. Joten sen sijaan, että näyttäisivät valikon kohtia ja napsauttaisivat mitä tahansa niistä, ne näyttävät täysimittaiset kuvat, määrittelytaulukot ja upotetut sivut.

Kuva 5 näyttää enemmän sisäiseltä sivulta kuin kotisivulta. Audi.com käyttää valikkoja paljon muuhunkin kuin vain navigointiin. Kun viet hiiren valikon päälle, näkyviin ei tule vain napsautettavat kohteet, vaan myös täysimittaiset kuvat ja luettelot ajoneuvovaihtoehdoista.

Kuva 5. Kun siirrät hiiren valikon päälle, kaikki kuvat ja vaihtoehtoluettelot tulevat näkyviin

Se on älykäs lähestymistapa interaktiivisuuteen. Käyttäjien ei tarvitse napsauttaa paljon, mutta sivusto tarjoaa heille monipuolista visuaalista palautetta. Käyttäjästä tuntuu, että sivustolla tapahtuu paljon. Vuorovaikutukseen ei aina liity monimutkaisia ​​Flash-animaatioita tai joystick-manipulaatiota. Joskus hyvin sijoitettu kuva, kuten Audin verkkosivuilla, riittää täysin.

Kuva 6 paljastaa toisen vuorovaikutteisuuden aspektin: yksinkertaisuuden. Tämä on yleistä tekstivalikko, jonka ulkonäössä ei ole mitään erikoista. Valikko putoaa kuitenkin pois erittäin selvästi, ja sen nykyinen kohta on korostettu värillisesti. Tässä ei ole mitään vallankumouksellista, mutta kun otetaan huomioon koko sivuston toimintatapa, käy ilmi, että käytät rahaa lukemiseen ja sinua kiinnostavien asioiden löytämiseen. minimiaika. Vie hiiren osoitin valikon päälle, siirrä se haluamasi kohteen kohdalle ja napsauta. Ei yksinkertaisesti ole minnekään hämmentyä. Olet aina varma, että saat mitä haluat.

Kuva 6. Navigointivalikot ovat yksinkertaisia ​​ja niitä kannattaa napsauttaa.

Kuva 7 esittää sisäsivua. Toki sisäsivu on hieman heikompi ja vähemmän mukaansatempaava kuin hyvin suunniteltu kotisivu. Täällä on monia muita vaihtoehtoja, joista jokaisen napsauttaminen muuttaa auton kuvan keskellä. Jokaisella mallisivulla on useita kuvia, jotka muuttuvat käyttäjän toimien mukaan. Värin, vanteen tyypin tai sisustuksen valitseminen muuttaa kuvan välittömästi.

Kuva 7. Päällä sisäiset sivut vaatii enemmän napsautusta kuin lukemista

Ilmeisesti paljon suunnittelijoiden ja ohjelmoijien työtä on tehty tälle sivustolle. Se ei ole vuorovaikutteisuuden malli, jota monet sivustot voivat käyttää. Tärkeintä tässä on kuitenkin, että käyttäjien on oltava vuorovaikutuksessa sivuston kanssa voidakseen jatkaa. Suurempi interaktiivisuus mahdollistaa pääsyn sivustolta lisää tietoa.

Tulostamalla kuvakaappauksia näet helposti, kuinka käyttäjät ovat vuorovaikutuksessa sivuston kanssa ja mitä he saavat tästä vuorovaikutuksesta. Käytä jonkin aikaa tämän harjoituksen tekemiseen. Jollekin saattaa tuntua typerältä katsoa lattialle asetettuja kuvakaappauksia, mutta tämä on parempi kuin verkkosivusto, jolle astuessaan käyttäjä alkaa kyllästyä ja poistuu nopeasti.

Interaktiivisuuden lisääminen ei ole niin helppoa

Interaktiivisella lähestymistavalla pääkysymykseksi tulee missä tarkalleen Näytöllä on oltava vuorovaikutusta. Tämä ei ole vain päättelyä, kuten "Tämä widget on sijoitettava vasemmalle yläkulma? Tai ehkä oikealla?" On olemassa kaksi peruslähestymistapaa (joista toinen ei ole kovin hyvä):

• Interaktiivisuuden ei tarvitse olla fyysisesti keskellä. Sen tulee olla paikka, johon käyttäjän huomio on suunnattu. Käyttäjän on oltava vuorovaikutuksessa sivuston kanssa jatkaakseen eteenpäin.
• Interaktiivisuutta on sijoitettu kaikkialle, missä on tietoa. Vuorovaikutus on vaikuttavaa, mutta siitä ei ole välttämätöntä siirtyä eteenpäin.

Ensimmäinen lähestymistapa on parempi. Vuorovaikutteisuutta ei voida "kierrellä" olemassa olevaan sivustoon. Miksi? Vuorovaikutus ei sovi hyvin noin tiedot. Sen sijaan sen pitäisi olla itse tiedon sisällä. Yllä olevissa kuvissa , , ja vuorovaikutukset on sidottu itse tietoihin - valikkokohtiin. Et voi saada yhtä ilman toista.

Tietojen ja vuorovaikutusten yhdistäminen

Hybridisaatio-ajatukseen palatakseni, interaktiivisimpienkin sivustojen on esitettävä tietoa jossain vaiheessa. Harkitse esimerkiksi videopelejä. Siellä täällä peleissä on taukoja, joiden aikana pelaaja on passiivinen katsoja kohtauksille, jotka tarjoavat pelaajalle tarpeellista tietoa.

Toisaalta useimpien tietosivustojen on jossain vaiheessa sallittava käyttäjän napsauttaa tai etsiä jotain. Kuvittele, jos kaikki Wikipedian tiedot olisi tallennettu yhdelle sivulle! Ja silloinkin käyttäjän on vieritettävä sivua; ja tämä on myös vuorovaikutusta. Kaikki sivustot ovat hybridejä. Useimmissa sivustoissa mikään näistä näkökohdista ei ole ylivoimainen, esimerkiksi 90 % tiedoista ja vain 10 % vuorovaikutteisuudesta (tai päinvastoin). Useimmilla sivustoilla suhde on noin 75/25. Sinun on tehtävä päätös interaktiivisella sivustollasi olevan tiedon määrästä tai tietosivustosi vuorovaikutusten määrästä. Tietysti näiden on oltava hyviä päätöksiä.

Voit luoda uskomattomia tapoja vuorovaikutukseen, mutta sinun on silti pystyttävä tarjoamaan hyvää tietoa. Sinulla voi olla paljon tietoa, mutta jossain vaiheessa sinun on tarjottava interaktiivisuutta.

Hybridien luominen on paljon vaikeampaa

Ongelman ydin on tämä: riippumatta siitä, kuinka hyvä olet luomaan interaktiivisia kokemuksia, sinun on myös oltava hyvä suunnittelemaan tietoa. Jos olet paras tiedon suunnittelija, sinun on silti opittava luomaan interaktiivisia kokemuksia. Ei ole helppoa tehdä molempia hyvin samanaikaisesti. Useimmat ihmiset ovat hyviä yhdessä asiassa, mikä saa heidän sivustonsa erottumaan siitä, missä he ovat hyviä. Outoa ja ironiaa tässä on, että jos sivusto on todella hyvä yhdessä asiassa (interaktiivisuus tai tiedot), niin yleensä muu puoli on huonosti kehittynyt. Tietenkin tavoitteena on tehdä molemmat hyvin, jotta saadaan erittäin vahva sivusto tai sovellus.

Ensimmäinen ja tärkein sääntö on, että sinun ei pidä työskennellä yksinomaan interaktiivisuuden parissa tiedon kustannuksella tai päinvastoin. Todennäköisesti olet hyvä yhdessä asiassa ja huono toisessa. Yritä työskennellä lujasti yhden kanssa ja työskennellä toisella tarpeen mukaan. Jos olet omaksunut 75/25-säännön (tietoisen ja interaktiivisen sisällön suhteesta sivustolla), kannattaa ehkä myös jakaa aikasi samassa suhteessa. Tämä on ehdottomasti hyvä paikka aloittaa.

Seuraava askel on suorittaa tehtävät uudelleen. Suunnittele sivustoja ja suunnittele vuorovaikutusta jatkuvasti. Suunnittelijoiksi, jotka jatkavat Web-sivustojen luomista vapaa-ajallaan, tulee yleensä parhaat suunnittelijat kuin ne, jotka oppivat soittamaan kitaraa vapaa-ajallaan.

Ja lopuksi sinun on harjoitettava ja vahvistettava heikkoja kohtia. Jos vietät päiväsi työskennellessäsi informaatiotäytteillä sivustoilla, etsi, mihin sivuston osiin voisit lisätä hieman interaktiivisuutta. Luo kokoontaitettavia alueita JavaScriptin tai jQueryn avulla. Kasvata tietosivustoasi niin, että tiedon ja interaktiivisuuden suhde on 60/40. Myös päinvastoin on totta. Etsi tapoja lisätä tiedon määrää interaktiivisella sivustollasi. Luo tietosivupalkkeja, jotka tulevat näkyviin oikeaan aikaan ja näyttävät enemmän tietoa kuin tavallisesti antaisit. Vahvista heikkoja kohtia.

Käytä sivustojasi

Täällä voit pyörittää silmiäsi ja päättää, että ne kertovat sinulle jotain täysin ilmeistä. Ota aikaa yllättyäksesi.

Käytä verkkosivustojasi. Usein ja paljon.

Kuulostaa yksinkertaiselta, eikö? Kuitenkin aivan kuten näyttelijät eivät halua katsoa heidän esityksiään tai monet muusikot eivät kuuntele omia CD-levyjään, monet verkkosuunnittelijat eivät vieraile suunnittelemillaan sivustoilla. He kirjoittavat koodin, suunnittelevat, lataavat sivuston ja unohtavat sen. Heillä ei ole aavistustakaan sivuston tulevasta kohtalosta. He pyrkivät toteuttamaan kuvitteellisen käyttötapauksen, johon liittyy näkymätön ja olematon käyttäjä, mahdollisimman nopeasti. Tämä ei ole hyvä tapa.

Joten sinun on käytettävä verkkosivustoasi. Jos et pidä siitä, käyttäjäsi eivät välttämättä myöskään pidä siitä. Älä ole niin nopea hylätä ongelmia sanoilla "no, se johtuu vain siitä, että tiedän, miten se toimii" tai "kukaan käyttäjistä ei ole minun kaltainenni". Paljon parempi kysymys itsellesi on: "Kuinka voin parantaa sivuston käyttökokemusta riippumatta siitä, ovatko sivuston käyttäjät samanlaisia ​​kuin minä vai eivät?" Tämä ajattelutapa voi muuttaa perusteellisesti tapaa, jolla ajattelet sivustostasi.

Johtopäätös

Tie loistavaan verkkosuunnitteluun ei edellytä tämän artikkelin – tai minkä tahansa muun – lainaamista uudestaan ​​ja uudestaan, kun luot sivuasetteluja ja kirjoitat JavaScript-koodia. Sen sijaan sinun tulee mukauttaa tässä artikkelissa kuvatut periaatteet itsellesi ja käyttää niitä ponnahduslautana omien periaatteiden muotoiluun. Verkkosivustosi ja sovelluksesi ovat parempia, jos ajattelet tätä artikkelia etkä vain käytä sitä sokeasti.

Tässä artikkelissa esittelimme periaatteet, joiden avulla voit määrittää, onko Web-näkyvyys enemmän kuin Web-sivusto vai Web-sovellus. Tärkeää on se, että päätät, että Web-läsnäolosi pitäisi olla informatiivisempaa tai interaktiivisempaa tai että se on hyvä sellaisenaan. miettiä mitä aiot tehdä. Nyt voit tehdä tietoisia ja tietoisia päätöksiä.

Nyt on aika rikkoa sääntöjä tai riidellä lukemiesi kirjoittajien kanssa. Tämä tarkoittaa, että sinun on selvitettävä, mikä toimii sinulle parhaiten. Sinun tilanteesi on erilainen kuin minun tai kenenkään muun. Sinun on "kirjoitettava oma artikkeli" siitä, mikä sopii sinulle. Tämä on hyvä asia. Toistaiseksi toivon, että tämä artikkeli antaa sinulle hyviä ajatuksia. Jätä kommentti artikkelin alareunaan ja kerro minulle, mikä olen oikeassa ja mikä väärässä. Olen kiinnostunut kuulemaan tilanteestasi ja siitä, miten Web-läsnäolosi kehittyy sitä silmällä pitäen.

Ja sen päivittäminen ja ylläpito on käyttöjärjestelmän toimittajalla. Sovelluslogiikka keskittyy palvelimeen, ja selaimen tehtävänä on lähinnä näyttää verkon kautta palvelimelta ladattua tietoa ja välittää käyttäjätietoja takaisin. Yksi tämän lähestymistavan etu on se, että asiakkaat ovat riippumattomia käyttäjän käyttöjärjestelmästä ja verkkosovellukset ovat siten monialustaisia ​​palveluita. Tämän monipuolisuuden ja suhteellisen helpon kehittämisen ansiosta verkkosovellukset tulivat laajalti suosituiksi 1990-luvun lopulla ja 2000-luvun alussa.

Tekniset ominaisuudet

Rakentamisen merkittävä etu Web-sovellukset Selaintoimintojen tukeminen edellyttää, että toiminnon on toimittava käyttöjärjestelmästä riippumatta tästä asiakkaasta. Sen sijaan, että kirjoittaisit eri versioita Microsoft Windowsille, Mac OS X:lle, GNU/Linuxille ja muille käyttöjärjestelmille, sovellus luodaan kerran satunnaisesti valitulle alustalle ja otetaan käyttöön siinä. Kuitenkin eri toteutus CSS tai Java-sovelmat täydelliseen tai osittaiseen toteutukseen käyttöliittymä. Koska useimmat selaimet tukevat näitä tekniikoita (yleensä lisäosien kautta), Flash- tai Java-sovellukset voivat toimia helposti. Koska ne antavat ohjelmoijalle enemmän hallintaa käyttöliittymässä, ne pystyvät kiertämään monia selainkokoonpanojen yhteensopimattomuutta, vaikka Java- tai Flash-asiakaspuolen toteutusten väliset yhteensopimattomuudet voivat johtaa erilaisiin hankaluuksiin. Arkkitehtonisen samankaltaisuuden vuoksi perinteisten asiakas-palvelinsovellusten, jollain tavalla "paksujen" asiakkaiden kanssa, luokittelun oikeellisuudesta on kiistaa. vastaavia järjestelmiä verkkosovelluksiin; vaihtoehtoinen termi "rikas Internet-sovellus" Rikkaat Internet-sovellukset).

Verkkosovelluslaite

Web-sovellus vastaanottaa pyynnön asiakkaalta ja suorittaa laskelmia, luo sitten web-sivun ja lähettää sen asiakkaalle verkon yli käyttämällä tietokantaprotokollaa tai toisella palvelimella sijaitsevaa verkkosovellusta. Hämmästyttävä esimerkki verkkosovelluksesta on Wikipedia-artikkelien sisällönhallintajärjestelmä: monet sen osallistujista voivat osallistua verkkotietosanakirjan luomiseen käyttämällä käyttöjärjestelmiensä selaimia (on se sitten Microsoft Windows, GNU/Linux tai mikä tahansa muu). käyttöjärjestelmä) ja lataamatta muita suoritettavia moduuleja artikkelitietokannan kanssa työskentelemiseen.

Tällä hetkellä suosiota uusi lähestymistapa web-sovelluskehitykseen, nimeltään Ajax. Ajaxia käytettäessä web-sovellussivut eivät lataudu kokonaan uudelleen, vaan ne vain lataavat tarvittavat tiedot palvelimelta, mikä tekee niistä interaktiivisempia ja tuottavampia.

Palvelinpuolen verkkosovellusten luomiseen käytetään erilaisia ​​teknologioita ja ohjelmointikieliä

Asiakaspuolella sitä käytetään:

• Salama
• ActiveX

Katso myös Linkit

• Kuinka Microsoft hävisi API-sodan - Keskustelu perinteisten Windows-sovellusten korvaamisesta verkkosovelluksilla
• Web Applications 1.0 dokumentoi verkkosovellusten toiminnan.
• The Other Road Ahead – Artikkeli, jossa todetaan, että tulevaisuus on palvelinpohjaisissa, ei asiakaspuolen sovelluksissa

Kirjallisuus

• Marco Bellignaso Web-sovellusten kehittäminen ASP.NET 2.0 -ympäristössä: ongelma - projekti - ratkaisu = ASP.NET 2.0 Web-sivuston ohjelmointi: Ongelma - Suunnittelu - Ratkaisu. - M.: "Dialektiikka", 2007. - S. 640. - ISBN 0-7645-8464-2
• Olištšuk Andrei Vladimirovitš Web-sovellusten kehittäminen PHP 5:ssä. Ammattimainen työ. - M.: "Williams", 2006. - S. 352. - ISBN 5-8459-0944-9

Wikimedia Foundation. 2010.

Katso, mitä "Web-oriented interface" tarkoittaa muissa sanakirjoissa:

Tämä artikkeli saattaa sisältää alkuperäistä tutkimusta. Lisää linkkejä lähteisiin, muuten se voidaan asettaa poistettavaksi. Lisätietoja voi olla keskustelusivulla. (25. toukokuuta 2011) ... Wikipedia

Käyttöliittymä (UI English user interface) on joukko keinoja, joilla käyttäjä kommunikoi eri laitteiden kanssa, useimmiten tietokoneen tai kodinkoneet tai muita monimutkaisia ​​työkaluja (järjestelmä). Käyttöliittymä... ... Wikipedia

Viime aikoina lähinnä käyttökokemuksen ja suorituskyvyn vuoksi.

Haluan esitellä 7 toimivaa periaatetta verkkosivustoille, jotka haluavat käyttää JavaScriptiä käyttöliittymän hallintaan. Nämä periaatteet ovat tulosta työstäni web-suunnittelijana, mutta myös WWW:n pitkäaikaisena käyttäjänä.

JavaScriptistä on kiistatta tullut välttämätön työkalu etupään kehittäjille. Nyt sen soveltamisala laajenee muille alueille, kuten palvelimiin ja mikro-ohjaimiin. Arvostetut yliopistot ovat valinneet tämän ohjelmointikielen opettamaan opiskelijoille tietojenkäsittelytieteen perusteita.

Samaan aikaan sen rooliin liittyy useita kysymyksiä erityiseen käyttöön, johon monien on vaikea vastata, mukaan lukien viitekehysten ja kirjastojen kirjoittajat.

• Pitäisikö JavaScriptiä käyttää selaimen toimintojen korvikkeena: historia, navigointi, renderöinti?
• Onko backend kuolemassa? Onko HTML:n hahmontaminen ylipäätään välttämätöntä?
• Onko totta, että yhden sivun sovellukset (SPA) ovat tulevaisuutta?
• Pitäisikö JS:n luoda sivuja verkkosivustolle ja hahmontaa sivuja verkkosovelluksissa?
• Pitäisikö minun käyttää tekniikoita, kuten PJAX tai TurboLinks?
• Mikä on tarkka ero verkkosivuston ja verkkosovelluksen välillä? Pitäisikö yksi asia jättää?

Seuraavassa on yritykseni vastata näihin kysymyksiin. Yritin tutkia JavaScriptin käyttöä käyttäjäkokemuksen (UX) näkökulmasta. Erityisesti kiinnitin huomiota ajatukseen minimoida aika, joka käyttäjältä kuluu häntä kiinnostavien tietojen hankkimiseen. Alkaen verkkoteknologioiden perusteista ja päättyen tulevan käyttäjien käyttäytymisen ennustamiseen.1. Sivujen renderöinti palvelimella;DR: Renderöinti palvelimella ei tehdä hakukoneoptimoinnin, vaan suorituskyvyn vuoksi. Ota se huomioon lisäpyynnöt vastaanottaa komentosarjoja, tyylejä ja myöhempiä API-pyyntöjä. Harkitse jatkossa HTTP 2.0 Push -menetelmän käyttöä.
Ensinnäkin minun on huomautettava yleisestä virheestä erottaa "palvelimella renderöidyt sovellukset" "yksisivuisista sovelluksista". Jos haluamme saavuttaa parhaan kokemuksen käyttäjän näkökulmasta, emme saa rajoittua sellaisiin rajoihin ja hylätä vaihtoehtoja toisen hyväksi.

Syyt ovat varsin ilmeiset. Sivut välitetään Internetin kautta, jolla on fyysisiä rajoituksia, kuten Stuart Cheshire ikimuistoisesti havainnollistaa kuuluisassa esseessä "It's latency, fool":

Stanfordin ja Bostonin välinen etäisyys on 4320 km.
Valon nopeus tyhjiössä on 300 x 10^6 m/s.
Valon nopeus optisessa kuidussa on noin 66 % valon nopeudesta tyhjiössä.
Valon nopeus optisessa kuidussa on 300 x 10^6 m/s * 0,66 = 200 x 10^6 m/s.
Yksisuuntainen viive lähetettäessä Bostoniin 4320 km / 200 x 10^6 m/s = 21,6 ms.
Meno-paluuviive 43,2 ms.
Ping Stanfordista Bostoniin nykyaikaisessa Internetissä on noin 85 ms (...)
Niin, nykyaikaiset laitteet Internet lähettää signaalin nopeudella, joka on 0,5 kertaa valon nopeus.
Ilmoitettua tulosta 85 ms voidaan parantaa (ja on jo hieman parempi), mutta on tärkeää ymmärtää, että viiveellä on fyysinen raja tiedonsiirrossa Internetin kautta riippumatta siitä, kuinka paljon kaistanleveyttä käyttäjien tietokoneilla kasvaa. .

Tämä on erityisen tärkeää JavaScript-sovellusten suosion lisääntyessä, sillä ne sisältävät yleensä vain merkinnät ja tyhjän kentän vieressä. Niin sanotut yhden sivun sovellukset (SPA) - palvelin palauttaa yhden sivun, ja kaikki muu kutsutaan koodilla asiakaspuolella.

Kuvittele tilanne, jossa käyttäjä siirtyy suoraan app.com/orders-sivustoon. Kun hakemuksesi vastaanottaa ja käsittelee tämän pyynnön, sillä on jo tärkeä tiedot siitä, mitä sivulla on näytettävä. Se voi esimerkiksi ladata tilauksen tietokannasta ja lisätä sen vastaukseen. Mutta useimmat SPA:t palauttavat tässä tilanteessa tyhjän sivun ja tunnisteen. Sitten sinun on vaihdettava pyyntöjä uudelleen saadaksesi käsikirjoituksen sisällön ja uudelleen saadaksesi sisällön.

Palvelimen lähettämän HTML-koodin jäsentäminen jokaiselle SPA-sivulle

Monet kehittäjät tekevät tietoisesti tällaisen uhrauksen. He yrittävät varmistaa, että lisäverkko humala tapahtuu vain kerran lähettäjälle oikeat otsikot vastausten välimuistiin tallentamiseen komentosarjoilla ja CSS:llä. Perinteinen viisaus on, että tämä on hyvä tarjous, koska kun kaikki tiedostot on ladattu tietokoneeseen, useimmat käyttäjän toimet (kuten siirtyminen muihin osiin) tapahtuvat ilman lisäsivuja tai komentosarjoja.

Kuitenkin, vaikka välimuisti otettaisiin huomioon, suorituskyky heikkenee, jos otamme huomioon jäsentämiseen ja komentosarjan suorittamiseen kuluvan ajan. Artikkelissa "Onko jQuery liian suuri mobiililaitteille?" kertoo, kuinka jQuery yksin voi hidastaa joitakin mobiiliselaimia sadoilla millisekunteilla.

Asiaa pahentaa se, että käyttäjä ei yleensä saa palautetta skriptien latautuessa. Tuloksena on tyhjä sivu näytöllä, joka sitten yhtäkkiä muuttuu täysin ladatuksi sivuksi.

Mikä tärkeintä, meillä on tapana unohtaa, että yleisin Internet-tiedonsiirto (TCP) käynnistyy hitaasti. Tämä takaa lähes varmasti, että useimpia skriptipaketteja ei siirretä kerralla, mikä pahentaa yllä olevaa tilannetta entisestään.

TCP-yhteys alkaa kättelypakettien vaihdolla. Jos käytät SSL:ää, joka on tärkeä suojatun komentosarjasiirron kannalta, on olemassa kaksi ylimääräistä pakettivaihtoa (yksi, jos asiakas palauttaa istunnon). Vasta tämän jälkeen palvelin voi aloittaa tiedon lähettämisen, mutta käytäntö osoittaa, että se tekee sen hitaasti ja erissä.

Ruuhkanhallintamekanismi nimeltä Slow Start on sisäänrakennettu TCP-protokolla lähettää tietoja lisäämällä määrää vähitellen segmenttejä. Tällä on kaksi vakavaa seurausta SPA:lle:

1. Suuret skriptit latautuvat paljon kauemmin kuin miltä ne näyttävät. Kuten Ilja Grigorikin kirjassa "High Performance Browser Networking" selitetään, "asiakkaan ja palvelimen välisen 64 kilotavun tiedonsiirron saavuttamiseen tarvitaan neljä paketinvaihtoa (...) ja satoja millisekunteja latenssia". Esimerkiksi siinä tapauksessa nopea internetyhteys Lontoon ja New Yorkin välillä kestää 225 ms ennen kuin TCP saavuttaa enimmäispakettikoon.

2. Koska tämä sääntö koskee myös sivun alkulatausta, on erittäin tärkeää, mikä sisältö ladataan hahmonnettavaksi sivulle ensin. Kuten Paul Irish päättelee esityksessään Delivering Goods, ensimmäiset 14 kilotavua ovat kriittisiä. Tämä on selvää, jos katsot kaaviota, joka osoittaa asiakkaan ja palvelimen väliset siirtomäärät yhteyden muodostamisen ensimmäisten vaiheiden aikana.

Kuinka monta kilotavua palvelin voi lähettää kussakin yhteysvaiheessa segmenteittain

Sivustot, jotka onnistuvat toimittamaan sisältöä (jopa perusmerkinnät ilman tietoja) tässä ikkunassa, näyttävät poikkeuksellisen reagoivilta. Itse asiassa monet kirjoittajat nopeasti palvelinsovelluksia kokea JavaScriptin tarpeettomana tai erittäin varovaisena käytettävänä. Tämä asenne vahvistuu entisestään, jos sovelluksella on nopea taustajärjestelmä ja tietokanta ja sen palvelimet sijaitsevat lähellä käyttäjiä (CDN).

Palvelimen rooli sisällön esittämisen nopeuttamisessa riippuu suoraan verkkosovelluksesta. Ratkaisu ei aina tiivisty "renderöimään kokonaisia ​​sivuja palvelimella".

Joissakin tapauksissa ei ole merkitystä Tämä hetki Käyttäjän kannalta on parempi jättää osa sivusta pois alkuperäisestä vastauksesta ja jättää se myöhempään käyttöön. Jotkut sovellukset esimerkiksi mieluummin renderöivät vain sivun "ytimen" varmistaakseen välittömän reagoinnin. Sitten he pyytävät sivun eri osia rinnakkain. Tämä tarjoaa paremman reagointikyvyn jopa tilanteissa, joissa on hidas, vanha taustajärjestelmä. Joillekin sivuille hyvä vaihtoehto Vain näkyvä osa sivusta hahmonnetaan.

Erittäin tärkeä laadullinen arviointi komentosarjat ja tyylit, ottaen huomioon tiedot, jotka palvelimella on istunnosta, asiakkaasta ja URL-osoitteesta. Järjestyksiä lajittelevat komentosarjat ovat ilmeisesti tärkeämpiä /ordersille kuin asetussivun logiikka. Ehkä ei niin ilmeinen, mutta "rakenne-CSS:n" ja "tyyli-CSS:n" lataamisessa on ero. Ensimmäinen saattaa olla tarpeen JavaScript-koodi, joten se on pakollinen esto, ja toinen ladataan asynkronisesti.

Hyvä esimerkki SPA:sta, joka ei aiheuta tarpeetonta pakettien vaihtoa, on 4096 tavun StackOverflow-konseptiklooni, joka voisi teoriassa latautua ensimmäisellä paketilla TCP-yhteyden kättelyn jälkeen! Kirjoittaja onnistui saavuttamaan tämän kieltäytymällä välimuistiin tallentamisesta käyttämällä palvelimen vastauksessa kaikkia resursseja. Käyttämällä SPDY- tai HTTP/2-palvelinpussia on teoriassa mahdollista siirtää kaikki välimuistissa oleva asiakaskoodi yhdellä hyppyllä. No, tällä hetkellä osien tai koko sivun renderöiminen palvelinpuolella on edelleen suosituin tapa päästä eroon tarpeettomista pakettien vaihtokierroksista.

Proof-of-concept SPA, joka käyttää sisäänrakennettua CSS- ja JS-palvelua tarpeettomien edestakaisten välttämiseksi

Melko joustava järjestelmä, joka jakaa renderöinnin selaimen ja palvelimen välillä ja tarjoaa työkaluja skriptien ja tyylien asteittaiseen lataamiseen, voisi hyvin hämärtää rajan verkkosivustoja Ja verkkosovelluksia. Molemmat käyttävät URL-osoitteita, navigointia ja esittelevät tietoja käyttäjälle. Jopa sovellus laskentataulukoita, joka perustuu perinteisesti asiakaspuolen toimivuuteen, on ensin näytettävä asiakkaalle tiedot, joita on muokattava. Ja tämän tekeminen vähiten edestakaisin matkoilla on ensiarvoisen tärkeää.

Minun näkökulmastani suurin suoritusvirhe monissa suosittuja järjestelmiä nykyaikana selittyy monimutkaisuuden asteittaisella kertymisellä pinoon. Ajan myötä tekniikoita, kuten JavaScript ja CSS, lisättiin. Myös niiden suosio kasvoi vähitellen. Vasta nyt voimme ymmärtää, kuinka niitä voidaan käyttää eri tavalla. Puhumme myös protokollien parantamisesta (tämän osoittaa SPDY:n ja QUIC:n nykyinen edistyminen), mutta suurin hyöty tulee sovellusten optimoinnista.

Saattaa olla hyödyllistä muistaa joitain suunnitteluun liittyviä historiallisia keskusteluja. aikaisemmat versiot HTML ja WWW. Esimerkiksi tämä postituslista vuodelta 1997 ehdottaa tunnisteen lisäämistä HTML:ssä. Marc Andreessen toistaa, että on tärkeää toimittaa tiedot nopeasti:

”Jos dokumentti on koottava lennossa, se voi olla niin monimutkainen kuin haluamme, ja vaikka monimutkaisuus olisi rajallista, meillä on silti suuria suorituskykyongelmia dokumenttien jäsentämisessä tällä tavalla. Ensinnäkin tämä rikkoo heti WWW:n yhden hypyn periaatteen (no, IMG rikkoo myös sen, mutta hyvin tietystä syystä ja hyvin rajoitetussa mielessä) - olemmeko varmoja, että haluamme tämän? 2. Välitön vastaus käyttäjän toimiintl;DR: JavaScriptin avulla voit piilottaa verkon latenssin kokonaan. Tätä suunnitteluperiaatteena käyttämällä voimme jopa poistaa sovelluksesta lähes kaikki latausilmaisimet ja "latausviestit". PJAX- tai TurboLinkeistä puuttuu mahdollisuuksia lisätä subjektiivista käyttöliittymän nopeutta.
Tavoitteemme on maksimoida käyttäjän toimiin reagointinopeus. Huolimatta siitä, kuinka paljon ponnistelemme vähentääksemme hyppyjen määrää työskennellessämme verkkosovelluksen kanssa, on asioita, jotka eivät ole meidän hallinnassamme. Tämä on valonnopeuden teoreettinen raja ja minimiping asiakkaan ja palvelimen välillä.

Tärkeä tekijä on asiakkaan ja palvelimen välisen viestinnän ennakoimaton laatu. Jos yhteyden laatu on huono, paketit lähetetään uudelleen. Jos sisältö on latauduttava muutaman edestakaisen matkan aikana, saatat tarvita paljon enemmän.

Tämä on pääasia JavaScriptin etu UX:n parantamiseksi. Jos käyttöliittymä on käsikirjoitettu asiakaspuolella, voimme piilottaa verkon latenssin. Voimme luoda vaikutelman suuri nopeus. Voimme saavuttaa keinotekoisesti nollaviiveen.

Oletetaan jälleen, että tämä on tavallinen HTML. Asiakirjat yhdistetään hyperlinkeillä tai tunnisteilla . Jos napsautat jotakin niistä, selain tekee verkkopyynnön, joka kestää arvaamattoman pitkän ajan, vastaanottaa ja käsittelee vastaanotetut tiedot ja siirtyy lopulta uuteen tilaan.

JavaScriptin avulla voit reagoida välittömästi ja optimistisesti käyttäjien toimiin. Linkin tai painikkeen napsauttaminen tuottaa välittömän vastauksen ilman Internetiin siirtymistä. Tunnettu esimerkki on Gmail (tai Google Inbox) -käyttöliittymä, jossa sähköpostiviestin arkistointi tapahtuu välittömästi, kun taas vastaava pyyntö palvelimelle lähetetään ja käsitellään asynkronisesti.

Lomakkeen tapauksessa sen sijaan, että odottaisimme HTML-koodia vastauksena sen täyttämiseen, voimme vastata välittömästi, kun käyttäjä painaa "Enter". Tai vielä parempaa, kuten Google-haku tekee, voimme reagoida vielä aikaisemmin valmistelemalla uuden sivun merkinnät etukäteen.

Tämä käytös on esimerkki siitä, mitä kutsun merkintöjen mukauttaminen. Perusideana on, että sivu "tietää" tulevan merkintänsä, joten se voi siirtyä siihen, kun siitä ei ole vielä tietoa. Tämä on "optimistista" käyttäytymistä, koska on silti olemassa riski, että tiedot eivät koskaan tule perille ja virheilmoitus on raportoitava, mutta tämä on ilmeisen harvinaista.

Googlen kotisivu on hyvä esimerkki, koska se osoittaa artikkelimme kaksi ensimmäistä periaatetta erittäin selvästi.

Vuoden 2004 lopussa Googlesta tuli edelläkävijä JavaScriptin avulla antaaksesi reaaliaikaisia ​​vihjeitä kirjoittaessasi hakulauseke(mielenkiintoista kyllä, työntekijä kehitti tämän toiminnon 20 % ajastaan ​​vapaana päätyöstään, aivan kuten Gmailin). Tästä tuli jopa perusta Ajaxin syntymiselle:

Katso Google Suggestia. Katso, kuinka hakutermit päivittyvät kirjoittaessasi, lähes välittömästi... sivun uudelleenlataamisen viivyttämättä. Google Suggest ja Google Kartat ovat kaksi esimerkkiä uudesta lähestymistavasta verkkosovellusten luomiseen, joita me Adaptive Pathissa kutsumme nimellä Ajax.
Ja vuonna 2010 he esittelivät Instant Searchin, jossa JS:llä on keskeinen rooli. Se poistaa manuaaliset sivujen päivitykset kokonaan ja siirtyy "hakutulosten" merkintään ensimmäisellä näppäimen painalluksella, kuten yllä olevasta kuvasta näkyy.

Toinen näkyvä esimerkki merkintöjen mukauttamisesta voi olla taskussasi. Ihan ensimmäisestä lähtien iPhone päivää Käyttöjärjestelmä vaati sovelluksen tekijöiden toimittamaan kuvan oletus.png, joka voidaan näyttää heti näytöllä, kun itse sovellus latautuu.

iPhone OS pakottaa default.png:n latautumaan ennen sovelluksen käynnistämistä

Toinen toimintotyyppi napsautusten ja lomakkeiden lähettämisen lisäksi, jota JavaScript parantaa huomattavasti, on tiedostojen lataaminen.

Voimme kirjata käyttäjän yrityksen ladata tiedosto eri tavoilla: vedä ja pudota, liitä leikepöydältä, valitse tiedosto. Sitten uusien HTML5-sovellusliittymien ansiosta voimme näyttää sisällön ikään kuin se olisi jo ladattu. Esimerkki tällaisesta käyttöliittymästä on työmme latausten parissa Cloudupissa. Huomaa, kuinka kuvan pikkukuva luodaan ja renderöidään välittömästi:

Kuva renderöidään ja näytetään, kunnes lataus on valmis

Kaikissa näissä tapauksissa parannamme nopeuden havaitseminen. Onneksi tämän lähestymistavan hyödyllisyydestä on olemassa paljon todisteita. Ota ainakin esimerkki siitä, miten lisääntyä etäisyydet Houstonin lentokentän matkatavaroiden kuljettimeen vähentynyt useita valituksia matkatavaroiden katoamisesta ilman tarvetta nopeuttaa matkatavaroiden käsittelyä.

Tämän idean pitäisi vaikuttaa vakavasti sovelluksiemme käyttöliittymään. Uskon, että latausindikaattoreista tulee harvinaisuus, varsinkin kun siirrytään reaaliaikaisiin tietosovelluksiin, joita kuvataan seuraavassa osiossa.

On tilanteita, joissa välittömän toiminnan illuusio vaikuttaa haitallisesti käyttökokemukseen. Tämä voi olla maksutapa tai istunnon lopettaminen sivustolla. Ottamalla tässä optimistisen lähestymistavan, de facto huijaamalla käyttäjää, saatamme ärsyttää häntä.

Mutta myös näissä tapauksissa pyörien näyttäminen tai latausilmaisimien näyttäminen näytöllä tulisi lopettaa. Ne tulisi näyttää vasta, kun käyttäjä katsoo, että vastaus ei ole välitön. Usein siteeratun Nielsenin tutkimuksen mukaan:

Perusvasteajan neuvot ovat pysyneet samana 30 vuoden ajan. Miller 1968; Card et ai. 1991:
* 0,1 sekuntia on raja, jonka aikana käyttäjä voi kokea vastauksen välittömänä, ei tarvitse näyttää muita lisätietoja kuin toimenpiteen tulos.
* 1,0 sekuntia on rajana käyttäjän ajattelun jatkuvuudelle, vaikka hän huomaa viiveen. Tyypillisesti yli 0,1 sekuntia mutta alle 1,0 sekuntia viiveistä ei tarvita lisäilmoitusta, mutta käyttäjä menettää tunteen työskennellä suoraan tietojen kanssa.
* 10 sekuntia on raja käyttäjän huomion pitämiseen dialogissa. Suuremmalla viiveellä käyttäjät haluavat suorittaa toisen tehtävän odottaessaan vastausta tietokoneelta.
PJAX:n tai TurboLinksin kaltaisista tekniikoista puuttuu valitettavasti suurin osa kohdassa kuvatuista ominaisuuksista Tämä alue. Asiakaspuolen koodi ei "tiedä" sivun tulevasta tilasta ennen kuin tiedonvaihto palvelimen kanssa tapahtuu.3. Vastaus tietojen muutokseenstl;DR: Kun tiedot päivitetään palvelimelle, asiakkaalle tulee ilmoittaa viipymättä. Tämä on eräs tuottavuuden parantamisen muoto, kun käyttäjä vapautetaan tarpeesta suorittaa lisätoimia (paina F5, päivitä sivu). Uudet asiat: (uudelleen)yhteydenhallinta, tilan palautus.
Kolmas periaate liittyy käyttöliittymän reaktioon tietojen muutoksiin lähteessä, tyypillisesti yhdessä tai useammassa tietokantapalvelimessa.

Voimansiirtomallista on tulossa menneisyyttä. HTML-tiedot, jotka pysyvät staattisina, kunnes käyttäjä päivittää sivun (perinteiset verkkosivustot) tai on vuorovaikutuksessa sen kanssa (Ajax).

Käyttöliittymäsi pitäisi päivittyä automaattisesti.

Tämä on kriittistä maailmassa, josta tuleva tietovirta lisääntyy eri lähteistä, mukaan lukien tulevaisuudessa tulevat kellot, puhelimet, tabletit ja puettavat laitteet.

Kuvittele Facebookin uutissyöte heti sen käyttöönoton jälkeen, jolloin tietoa julkaistiin ensisijaisesti käyttäjien henkilökohtaisista tietokoneista. Staattinen renderöinti ei ollut optimaalinen, mutta se oli järkevää ihmisille, jotka päivittävät syötteensä esimerkiksi kerran päivässä.

Elämme nyt maailmassa, jossa lataat kuvan ja saat lähes välittömästi tykkäyksiä ja kommentteja ystäviltä ja tuttavilta. Välittömän reagoinnin tarpeesta on tullut luonnollinen välttämättömyys muiden sovellusten kilpailuympäristössä.

Olisi kuitenkin väärin olettaa, että käyttöliittymän välittömien päivitysten edut rajoittuvat usean käyttäjän sovelluksiin. Siksi rakastan puhumista sovitut tietopisteet, sijaan käyttäjiä. Otetaan tyypillinen skenaario Synkronoi valokuvat puhelimen ja kannettavan tietokoneen välillä:

Myös yhden käyttäjän sovellus voi hyötyä reaktiivisuudesta.

Auttaa kuvitella kaikki tiedot, jotka lähetetään käyttäjälle "reaktiivisina". Istunnon ja valtuutustilan synkronointi on yksi esimerkki universaali lähestymistapa. Jos sovelluksesi käyttäjillä on useita välilehtiä auki samanaikaisesti, yhden niistä työistunnon lopettamisen pitäisi välittömästi deaktivoida valtuutus kaikilta muilta. Tämä johtaa väistämättä parempaan turvallisuuteen ja parempaan suojaukseen. luottamuksellista tietoa, erityisesti tilanteissa, joissa useat ihmiset voivat käyttää samaa laitetta.

Jokainen sivu reagoi istunnon tilaan ja valtuutustilaan

Kun olet määrittänyt säännön, jonka mukaan näytön tiedot päivittyvät automaattisesti, on tärkeää työskennellä uuden tehtävän parissa: tilan palauttaminen.

Kun lähetät pyyntöjä ja vastaanotat atomipäivityksiä, on helppo unohtaa, että sovelluksesi pitäisi päivittää normaalisti pitkänkin käyttämättömyyden jälkeen. Kuvittele, että suljet kannettavan tietokoneen kannen ja avaat sen muutaman päivän kuluttua. Miten sovellus käyttäytyy?

Esimerkki siitä, mitä tapahtuu, jos yhteyttä ei päivitetä oikein

Sovelluksen kyky muodostaa yhteys on normaalisti vuorovaikutuksessa periaatteen #1 kanssa. Jos päätät lähettää tietoja ensimmäisen sivun latauksen yhteydessä, sinun on otettava huomioon myös aika, joka kuluu ennen kuin komentosarjat ladataan. Tämä aika vastaa olennaisesti yhteyden katkeamisaikaa, joten skriptien ensimmäinen yhteys on istunnon jatkaminen.

4. Tiedonsiirron hallinta palvelimen kanssa tl;DR: Nyt voimme hienosäätää tiedonsiirtoa palvelimen kanssa. Varmista, että virheet käsitellään, pyynnöt toistetaan asiakkaan hyväksi, tiedot synkronoidaan tausta ja välimuistin tallentaminen offline-tilaan.
Kun verkko syntyi, viestintää asiakkaan ja palvelimen välillä rajoitettiin useilla tavoilla:

Linkin napsauttaminen lähettää GET-pyynnön uuden sivun hakemiseksi ja hahmontamiseksi.

Lomakkeen lähettäminen lähettää POST- tai GET-viestin, jota seuraa uusi sivu.

Kuvan tai objektin lisääminen lähettää asynkronisesti GET:n, jota seuraa renderöinti.

Tämän mallin yksinkertaisuus on erittäin houkutteleva, ja nyt asiat ovat varmasti muuttuneet monimutkaisemmiksi tiedon vastaanottamisen ja lähettämisen ymmärtämisessä.

Tärkeimmät rajoitukset liittyvät toiseen kohtaan. Kyvyttömyys lähettää tietoja ilman pakollinen lataus uusi sivu oli huono suorituskyvyn kannalta. Mutta tärkeintä on, että se rikkoi "Takaisin"-painikkeen kokonaan:

Todennäköisesti vanhan verkon ärsyttävin artefakti

Tästä syystä verkko sovellusalustana jäi epätäydelliseksi ilman JavaScriptiä. Ajax edusti valtavaa harppausta eteenpäin käyttäjien julkaisemisen helppoudessa.

Meillä on nyt monia sovellusliittymiä (XMLHttpRequest, WebSocket, EventSource, vain muutamia mainitakseni), jotka mahdollistavat täydellisen ja tarkan tietovirran hallinnan. Sen lisäksi, että voimme julkaista käyttäjätietoja lomakkeen kautta, meillä on uusia mahdollisuuksia parantaa käyttökokemusta.

Näyttö liittyy suoraan edelliseen periaatteeseen yhteyden tila. Jos odotamme tietojen päivittyvän automaattisesti, meidän on ilmoitettava käyttäjälle tosiasiat yhteyden katkeaminen Ja yrittää palauttaa sen.

Kun yhteys katkeaa, on hyödyllistä tallentaa tiedot muistiin (tai vielä paremmin localStorageen), jotta ne voidaan lähettää myöhemmin. Tämä on erityisen tärkeää ServiceWorkerin tulevan käytön valossa, mikä mahdollistaa JavaScript-sovellukset tehdä työtä taustalla. Jos sovelluksesi ei ole auki, voit silti jatkaa tietojen synkronointia palvelimen kanssa taustalla.

Harkitse mahdollisia aikakatkaisuja ja virheitä lähetettäessä tällaiset tilanteet asiakkaan eduksi. Jos yhteys palautuu, yritä lähettää tiedot uudelleen. Kun pysyvä virhe, ilmoita tästä käyttäjälle.

Jotkut virheet on käsiteltävä erityisen huolellisesti. Esimerkiksi odottamaton 403 voi tarkoittaa, että käyttäjän istunto on mitätöity. Tällaisissa tapauksissa on mahdollista palauttaa istunto näyttämällä käyttäjälle ikkuna kirjautumistunnuksen ja salasanan syöttämistä varten.

On myös tärkeää varmistaa, että käyttäjä ei vahingossa keskeytä tiedonkulkua. Tämä voi tapahtua kahdessa tilanteessa. Ensimmäinen ja ilmeisin tapaus on selaimen tai välilehden sulkeminen, minkä yritämme estää ennen purkamista käsittelevällä käsittelyllä.

Varoitus ennen purkamista

Toinen (ja vähemmän ilmeinen) tapaus on, kun yrität navigoida toiselle sivulle, kuten napsautat linkkiä. Tässä tapauksessa sovellus voi pysäyttää käyttäjän muilla tavoilla kehittäjän harkinnan mukaan.

5. Älä riko historiaa, vaan paranna sitä tl;DR: Jos selain ei hallitse URL-osoitteita ja historiaa, meillä on uusia ongelmia. Varmista, että täytät odotetun vierityskäyttäytymisen. Tallenna oma välimuisti nopeaa palautetta varten.
Lomakkeiden lähettämisen lisäksi pelkkien hyperlinkkien käyttäminen verkkosovelluksessa antaa meille täysin toimivan eteenpäin/takaisin navigoinnin selaimessa.

Esimerkiksi tyypillinen "loputon" sivu tehdään yleensä JavaScript-painikkeella, joka pyytää lisätietoja/HTML-koodia ja lisää sen. Valitettavasti harvat ihmiset muistavat kutsua historia.pushState tai replaceState pakollisena vaiheena.

Siksi käytän sanaa "tauko". Alkuperäisen verkon yksinkertaisella mallilla tämä tilanne ei ollut mahdollinen. Jokainen tilan muutos perustui URL-osoitteen muutokseen.

Mutta kolikolla on myös toinen puoli - mahdollisuus parantaa surffaushistoriaa, jota hallitsemme nyt JavaScriptin avulla.

Daniel Pipius kutsui yhden tällaisen mahdollisuuden Fast Back:

Takaisin-painikkeen pitäisi toimia nopeasti; käyttäjät eivät odota liikaa tietojen muutosta.
Se on kuin käsittelisi takaisin-painiketta verkkosovelluksen painikkeena ja soveltaisi siihen periaatetta 2: vastaa välittömästi käyttäjän toimiin. Tärkeintä on, että sinulla on mahdollisuus päättää, kuinka edellinen sivu tallennetaan välimuistiin ja näytetään se välittömästi näytöllä. Voit sitten soveltaa periaatetta 3 ja ilmoittaa käyttäjälle, kun tälle sivulle tulee uutta tietoa.

On edelleen muutamia tilanteita, joissa et voi hallita välimuistin toimintaa. Jos esimerkiksi renderöit sivun, menit sitten kolmannen osapuolen sivustolle ja käyttäjä napsautti Takaisin. Sovellukset, jotka renderöivät HTML:n palvelinpuolella ja sitten muokkaavat sitä asiakaspuolella, ovat erityisen herkkiä tälle pienelle bugille:

"Takaisin"-painikkeen virheellinen toiminta

Toinen tapa katkaista navigointi on ohittaa vieritystilan muisti. Jälleen kerran sivuilla, jotka eivät käytä JS:ää ja manuaalista historianhallintaa, ei todennäköisesti ole ongelmia täällä. Mutta tulee olemaan dynaamisia sivuja. Testasin kahta suosituinta Uutissyötteet JavaScript-pohjainen Internet: Twitter ja Facebook. Molemmilla oli scrolling amnesia.

Loputon sivujen kääntäminen on yleensä merkki rullaavasta muistinmenetyksestä

Loppujen lopuksi varo tilanmuutoksia, jotka ovat merkityksellisiä vain historiaa tarkasteltaessa. Esimerkiksi tässä tapauksessa alipuiden tilan muuttaminen kommenteilla.

Kommenttityypin muuttaminen on tallennettava historiaan

Jos sivu renderöitiin uudelleen sovelluksen sisällä olevan linkin napsautuksen jälkeen, käyttäjä saattaa odottaa, että kaikki kommentit laajenevat. Kun tila muuttuu, se on tallennettava historiaan.

6. Koodin päivitys push messagestl;DR:n kautta: Pelkän tiedon lähettäminen push-viesteillä ei riitä, vaan tarvitaan myös koodi. Vältä API-virheet ja paranna suorituskykyä. Käytä valtiotonta DOM:ia sovelluksesi kivuttomasti uudelleensuunnitteluun.
On erittäin tärkeää, että sovelluksesi reagoi koodin muutoksiin.

Ensinnäkin se vähentää mahdollisten virheiden määrää ja lisää luotettavuutta. Jos teit tärkeän muutoksen taustasovellusliittymään, niin on pakko päivittää asiakasohjelmien koodit. Muutoin asiakkaat eivät välttämättä hyväksy uusia tietoja tai voivat lähettää tietoja yhteensopimattomassa muodossa.

Yhtä tärkeä syy on noudattaa periaatetta nro 3. Jos käyttöliittymäsi päivittyy itsestään, käyttäjillä ei ole juurikaan syytä turvautua sivun manuaaliseen lataamiseen.

Muista, että tavallisella sivustolla sivun päivitys käynnistää kaksi asiaa: tietojen uudelleenlatauksen ja koodin uudelleenlatauksen. Järjestelmän järjestäminen push-datapäivityksillä ilman push-koodipäivityksiä on epätäydellinen, varsinkin maailmassa, jossa yksi välilehti (istunto) voi pysyä auki hyvin pitkään.

Jos palvelimen push-kanava toimii, niin käyttäjälle voidaan ilmoittaa uuden koodin saatavuudesta. Jos ei, versionumero voidaan lisätä lähtevien HTTP-pyyntöjen otsikkoon. Palvelin voi verrata sitä viimeisimpään tunnettuun versioon, suostua käsittelemään pyynnön vai ei ja antaa asiakkaalle työn.

Tämän jälkeen jotkut verkkosovellukset lataavat sivun uudelleen käyttäjän puolesta. Esimerkiksi, jos sivu ei ole näytön näkyvällä alueella eikä täytettyjä lomakkeita ole syötettäväksi.

Vielä parempi tapa on vaihtaa koodi kuumana. Tämä tarkoittaa, että sinun ei tarvitse ladata sivua kokonaan uudelleen. Sen sijaan varma moduulit vaihdetaan lennossa, ja niiden koodi lähetetään uudelleen suoritettaviksi.

Monessa olemassa olevia sovelluksia Koodin vaihtaminen kuumana on melko vaikeaa. Tätä varten sinun on aluksi noudatettava erottavaa arkkitehtuuria käyttäytymistä(koodi) alkaen tiedot(osavaltio). Tämä jako antaa meille mahdollisuuden julkaista monia erilaisia ​​korjaustiedostoja melko nopeasti.

Esimerkiksi verkkosovelluksessamme on moduuli, joka muodostaa väylän tapahtumien lähettämistä varten (kuten socket.io). Kun tapahtuma tapahtuu, tietyn komponentin tila muuttuu ja tämä näkyy DOM:ssa. Tämän jälkeen muutat kyseisen komponentin toimintaa esimerkiksi siten, että se luo eri DOM-merkinnät olemassa olevalle ja uudelle tilalle.

Ihannetapauksessa meidän pitäisi pystyä muuttamaan koodia modulaarisesti. Yhteyttä pistorasiaan ei tarvitse muodostaa uudelleen, jos esimerkiksi on mahdollista päivittää tarvittavan komponentin koodi. Ihanteellinen arkkitehtuuri push-koodipäivityksille on siksi modulaarinen.

Mutta heti syntyy ongelma, kuinka arvioida moduuleja ilman ei-toivottuja sivuvaikutuksia. Reactin kaltainen arkkitehtuuri sopii tähän parhaiten. Jos komponentin koodi päivitetään, sen logiikka voidaan yksinkertaisesti suorittaa uudelleen ja DOM päivitetään. Lue Dan Abramovin selitys tästä käsitteestä.

Pohjimmiltaan ajatuksena on, että päivität DOM: n (tai värität sen uudelleen), mikä auttaa suuresti koodin korvaamisessa. Jos tila on tallennettu DOM:iin tai sovellus asentaa tapahtumakäsittelijöitä, koodin päivittämisestä voi tulla paljon vaikeampi tehtävä.

7. Käyttäytymisennuste tl;DR: Negatiivinen viive.
Nykyaikaisessa JavaScript-sovelluksessa voi olla mekanismeja käyttäjien toimien ennustamiseen.

Tämän idean ilmeisin sovellus on tietojen esilataaminen palvelimelta ennen kuin käyttäjä pyytää niitä. Yksinkertainen esimerkki on web-sivun lataaminen hiiren kohdistimen ollessa sen päällä niin, että linkkien napsauttaminen näyttää sen välittömästi.

Hieman edistyneempi menetelmä hiiren seurannan seurantaan analysoi hiiren liikeradan tulevien "törmäysten" varalta interaktiivisten elementtien, kuten painikkeiden, kanssa. :

jQuery-laajennus ennustaa hiiren polun

Johtopäätös Verkko on edelleen monipuolisin tiedonsiirtoväline. Jatkamme dynamiikan lisäämistä sivuillemme ja meidän on varmistettava, että säilytämme sen tärkeitä periaatteita web, jonka olemme perineet.

Hyperlinkitetyt sivut ovat hyviä rakennuspalikoita kaikille sovelluksille. Koodin, tyylien ja merkintöjen lataaminen asteittain käyttäjän vuorovaikutuksessa varmistaa erinomaisen suorituskyvyn tinkimättä interaktiivisuudesta.

JavaScript tarjoaa uusia ainutlaatuisia ominaisuuksia. Jos näitä tekniikoita käytetään laajasti, ne tarjoavat paras kokemus työtä vapaaimman olemassa olevan alustan käyttäjille - WWW.

Tunnisteet: Lisää tunnisteita