Site de universitate
un singur site public, multe facultăți, o singură sesiune de admitere
Fiecare facultate își publică propriile pagini, biroul de admitere își publică propria sesiune și nimeni nu așteaptă după echipa web. Un singur site public pentru toată universitatea — instituția, fiecare facultate, fiecare centru de cercetare, senatul, comunitatea alumni și campania de admitere — în care oamenii care răspund de conținut își întrețin singuri partea lor, fără să treacă prin IT, și în care un viitor student poate găsi un program de studiu, poate citi regulile de admitere pentru el și își poate lăsa datele în aceeași vizită.
Sesiunea de admitere este partea cu termen. Site-ul este construit astfel încât o sesiune nouă, locurile scoase la concurs, regulile și, mai târziu, rezultatele să poată fi pregătite, previzualizate și publicate de biroul de admitere însuși, în ziua în care decide să publice.
- Potrivit pentru
- Educație
- Domeniu
- Experiența clientului
Problema
Site-ul unei universități nu este un site. Sunt treizeci, ale unor oameni care nu se subordonează unul altuia: fiecare facultate are anunțurile ei, programele ei de studiu, orarele și documentele de examen; fiecare centru de cercetare are proiecte și apeluri; senatul publică hotărâri; biroul de admitere ține o campanie care se schimbă în fiecare an și care trebuie să fie exactă. Când toate acestea trec printr-o singură echipă web, urmează două lucruri — conținutul e mereu în întârziere, iar echipa web își petrece anul copiind PDF-uri în pagini.
Simptomele recognoscibile într-o discuție comercială: documente trimise pe e-mail unui webmaster ca să fie urcate; pagini de facultate actualizate ultima dată acum doi ani; o ofertă de admitere care există ca fișier de calcul și se retastează în site; viitori studenți care sună pentru că nu găsesc regulile programului care îi interesează; și nicio listă a celor care și-au manifestat interesul, pentru că interesul sosește ca e-mail nestructurat.
Pentru cine e
Pentru o instituție publică cu multe entități interne semi-autonome și cu o problemă de conținut, nu de tranzacții: o universitate, un institut, un grup de spitale, o administrație județeană. Se potrivește când instituția are o echipă de comunicare capabilă să structureze conținut, dar fără capacitatea de a fi gâtuitura pentru fiecare facultate și departament, și când campania anuală de admitere sau de înscriere este un angajament ferm, cu calendar publicat.
Se potrivește când editorii nu sunt tehnici: tot ce afișează site-ul se editează într-o interfață de administrare cu acces delimitat pe entitate, nu în fișiere.
Nu este pentru:
- o organizație cu o singură entitate și câteva pagini — mecanica permisiunilor delegate este tot rostul soluției și ar fi pur cost în plus;
- o instituție care are nevoie de un sistem complet de candidatură și înmatriculare — aici se captează manifestări de interes și se publică rezultate, nu se punctează candidați, nu se ierarhizează, nu se repartizează locuri și nu se gestionează taxe (vezi Ce NU e inclus);
- un montaj multi-site sau multi-brand din care s-ar administra mai multe instituții dintr-o singură instalare — implementarea e făcută pentru o instituție pe deployment;
- un site public complet bilingv în care ambele limbi stau în același deployment: astăzi a doua limbă este un site separat.
Capabilități
Conținut și editare
| Capabilitate | Ce face |
|---|---|
| Structura de secțiuni și navigația pe entitate | Toată suprafața publică a instituției într-un singur loc — nivelul universității, facultăți, centre de cercetare, structuri administrative, senat, alumni și admitere — fiecare montată ca secțiune proprie, cu navigație proprie |
| Constructor de pagini cu secțiuni afișabile/ascunse și previzualizare | O pagină este o listă ordonată de secțiuni, fiecare putând fi afișată sau ascunsă fără a fi ștearsă: text, media, galerii, portofoliu, contoare, casete cu pictograme, documente, întrebări frecvente, taburi, acordeon, testimoniale, calendar, contact, newsletter și blocuri de îndemn la acțiune; paginile, sesiunile de admitere și rezultatele au un URL de previzualizare care randează starea nepublicată |
| Acces editorial delegat, delimitat pe entitate | Un editor de facultate vede și modifică doar conținutul facultății lui și nimic altceva, impus la nivel de obiect în administrare, nu prin convenție |
| Bibliotecă de documente comună, cu limite de încărcare | Fiecare tip de document din sistem moștenește un obiect-document unic, cu titlu, descriere, etichetă de buton de descărcare și un plafon de dimensiune la încărcare configurat pe mediu |
| Anunțuri, evenimente și categorii, pe entitate | Știri, anunțuri și evenimente cu aceleași obiecte refolosite pentru universitate, senat, facultăți, centre, structuri și alumni, plus un flux iCal pentru evenimente |
| Căutare în tot site-ul, cu filtre | Căutare în tot ce e publicat, cu filtre pe categorie, pe interval de date și pe sortare, actualizată la salvarea conținutului |
| Registre de persoane, conducere, comisii și contacte | Registre de persoane, conducere, comisii și contacte, pe entitate |
| Registre de rapoarte, legislație și metodologii | Registre de rapoarte, legislație și metodologii, publicate ca documente |
| Setări de site modificabile de editori | Logo-uri, favicon, îndemnuri la acțiune, notificarea de cookies, textele paginilor de eroare, lungimile listelor, imaginile implicite și variantele de afișare, toate editabile în administrare fără deployment |
| Metadate SEO, sitemap și administrarea legăturilor interne | Metadate de pagină, un sitemap și legături interne administrate |
| A doua limbă publică în același deployment | O a doua limbă publică servită din același site, cu un comutator de limbă |
Admitere
| Capabilitate | Ce face |
|---|---|
| Catalogul programelor de studiu | Programe pe facultate, cu nivel, formă de frecvență, limbă de predare, durată, credite, statut de acreditare, criterii și două comutatoare independente de vizibilitate: vizibil pe site și vizibil în panoul admiterii |
| Sesiuni de admitere, tabele de ofertă și criterii | Sesiuni pe nivel (licență, master, doctorat), fiecare cu categoriile ei de ofertă, un tabel de ofertă configurabil, criterii de admitere, probe de aptitudini și documentele lor; activarea unei sesiuni dezactivează automat precedenta de același nivel |
| Publicarea rezultatelor și arhiva | Rezultate pe categorie de facultate, admiși și respinși ca text sau document atașat, eliberate printr-un comutator de publicare pe categorie, cu arhiva sesiunilor anterioare |
| Captarea preînscrierilor și export în fișier de calcul | Un viitor student alege unul sau mai multe programe de studiu și își lasă datele de contact, parcursul școlar și consimțămintele explicite; biroul citește lista în administrare și o exportă în fișier de calcul; o cerere depusă nu poate fi modificată sau ștearsă din interfață |
Formulare și comunicare
| Capabilitate | Ce face |
|---|---|
| Captarea adreselor pentru newsletter | Un formular de abonare la newsletter ale cărui adrese biroul le exportă |
| Notificare prin e-mail către exterior | Biroul, sau candidatul, notificat prin e-mail când se depune un formular |
| Protecție anti-bot pe formularele publice | Verificare invizibilă la depunere, plus o verificare cu imagine disponibilă |
| Export în fișier de calcul pe orice registru | Export administrativ pentru registre, dincolo de preînscrieri |
| Flux social pe prima pagină | Un flux preluat live din contul de Instagram al instituției |
| Tur virtual | Un tur virtual încorporat în site |
Operare
| Capabilitate | Ce face |
|---|---|
| Analiză de produs | Un serviciu de analiză auto-găzduit, proxy-at de pe același domeniu |
| Monitorizare de erori | Raportarea excepțiilor către un serviciu găzduit |
| Operarea administrată a site-ului livrat | Vezi Găzduire administrată |
Dependențe de știut: fluxul social și analiza de produs au nevoie fiecare de un cont pe care îl deține instituția, iar credențiala lui trebuie ținută acolo unde editorii obișnuiți nu o pot citi. Protecția anti-bot acoperă formularul de preînscriere și se extinde la alte formulare prin configurare. Exportul în fișier de calcul se activează per registru.
Ce e inclus într-o livrare anume și cum se livrează: configurare vs. custom · abordarea de livrare.
Ce NU e inclus
- Un sistem de candidatură și selecție. Punctarea, ierarhizarea, repartizarea locurilor, contractele și taxele se întâmplă în afară. Aici se publică oferta, se captează interesul și se publică rezultatul.
- Orice legătură cu un sistem de gestiune a studenților. Lista celor interesați pleacă ca fișier de calcul, manual.
- Plăți. Nici taxe de studiu, nici taxă de înscriere, nici procesator.
- Conturi de candidat. Un viitor student nu se autentifică niciodată; nu există unde să își vadă propria depunere, să o corecteze sau să o retragă.
- Ștergerea și corecția datelor personale din interfață. Registrul de candidați e prin construcție doar de citit, deci o cerere de corecție sau de ștergere este momentan o operațiune în baza de date.
- Un lanț de aprobare editorială. Un editor cu acces pe o entitate publică; nu există pas în patru ochi, nici publicare programată, nici stare de ciornă/revizie dincolo de comutatorul de afișare și URL-ul de previzualizare.
- Orare, note, livrarea cursurilor, sisteme de bibliotecă. Site-ul publică documente despre ele.
Fluxul de referință
Citește pașii
Fluxul de referință este o sesiune de admitere, fiind cel cu termen și cel care atinge toate celelalte module.
- Declanșator — instituția aprobă oferta pentru sesiunea care vine: ce programe se scot, în ce condiții, după ce metodologie.
- Catalogul se aduce la zi. Editorii de facultate revizuiesc programele de studiu și poziționează cele două comutatoare de vizibilitate: pe site-ul public și în panoul admiterii. Un program poate fi publicat pe site și, în același timp, ascuns din campanie.
- Biroul de admitere creează sesiunea pentru un nivel (licență, master, doctorat), atașează documentele de metodologie, definește categoriile de ofertă, configurează ce coloane afișează tabelul de ofertă și consemnează criteriile de admitere și eventualele probe de aptitudini.
- Previzualizare. Biroul deschide URL-ul de previzualizare al sesiunii și o citește cum ar face-o un candidat, cât timp e încă inactivă.
- Activare. Marcarea sesiunii ca activă o publică și retrage automat sesiunea activă anterioară de același nivel — site-ul nu arată niciodată două sesiuni curente pentru un nivel.
- Sosesc candidații. Un viitor student parcurge catalogul, deschide un program, urmează îndemnul de preînscriere, selectează unul sau mai multe programe, completează datele, bifează consimțămintele cu care e de acord și trimite. Depunerea e validată împotriva programelor efectiv deschise campaniei, apoi se stochează.
- Biroul lucrează lista. Cererile de preînscriere se citesc în administrare, se filtrează și se caută, apoi se exportă în fișier de calcul pentru ce urmează în biroul respectiv.
- Rezultate. După ce selecția se face în afara sistemului, biroul atașează listele de admiși și respinși pe categorie de facultate, le previzualizează și comută publicarea pe categoria respectivă.
- Rezultatul — sesiunea și rezultatele ei rămân accesibile ca arhivă atunci când se deschide sesiunea următoare.
Unde nu se ține fluxul:
- Un candidat depune pentru un program retras din campanie. Depunerea e respinsă, nu stocată pe jumătate: serverul reverifică fiecare program selectat împotriva setului vizibil și refuză cererea întreagă dacă vreunul nu trece.
- Un candidat nu trece verificarea anti-bot sau lasă un câmp obligatoriu gol. Formularul se întoarce respins; nu se creează nicio înregistrare parțială.
- Biroul publică din greșeală mai devreme. Publicarea e pe categorie de ofertă, deci expunerea e o categorie, iar comutatorul e reversibil — dar nu există pas de aprobare între intenția unui editor și site-ul public, iar singura urmă a schimbării este jurnalul de administrare.
- Se activează două sesiuni pe același nivel. Nu poate persista: activarea retrogradează precedenta la salvare.
- O depunere trebuie corectată sau retrasă. Nu se poate, din interfață — registrul de preînscrieri e intenționat doar de citit, așa că corecțiile și cererile de ștergere sunt operațiuni în bază de date, nu un ecran (vezi Ce NU e inclus).
Arhitectura de referință
Mai întâi neutru tehnologic — acesta este blueprintul:
Patru lucruri sunt portante în imaginea de mai sus și sunt exact cele pe care le-ar păstra a doua implementare: un singur obiect-document folosit de toate modulele; acces editorial delimitat pe entitate; un index de căutare care urmează depozitul de conținut fără ca editorul să se gândească la el; și o preluare de formulare publice ale cărei înregistrări nu se mai modifică.
Stiva tehnică a site-ului livrat: Django pe Python cu PostgreSQL; Solr pentru căutare; permisiuni la nivel de obiect și setări de runtime în interiorul administrării Django, care este spațiul editorial; servit nativ în spatele nginx, cu administrarea accesibilă doar din adrese de rețea agreate. Configurația containerizată e doar pentru dezvoltare.
Integrări
| Sistem | Direcție | Ce circulă |
|---|---|---|
| Index de căutare | out | Continuu — conținutul indexat al tot ce e publicat |
| Serviciu anti-bot | out | La fiecare depunere — verificarea provocării pentru formularul de preînscriere |
| Export în fișier de calcul | out | La cerere — cereri de preînscriere și adrese de newsletter |
| Flux social | in | La cerere — postările recente ale contului propriu al instituției |
| E-mail către exterior | out | Notificări de la formularul de contact și de la formularele alumni |
| Serviciu de hărți | in | La pagină — cheia de hartă pentru afișarea locațiilor |
| Analiză de produs | out | Evenimente de utilizare |
| Monitorizare de erori | out | Excepții |
| Metrici de runtime | out | Metrici de cereri din aplicație |
Nu există integrare cu un sistem de gestiune a studenților, nu există integrare de plăți și nu există furnizor de identitate. Fiecare schimb cu un candidat se termină într-un fișier de calcul predat biroului.
Securitate și proprietate
Baza: securitate de bază. Specific acestui blueprint:
- Accesul editorial e la nivel de obiect, nu de rol. O facultate, un centru, o structură, un program sau o comisie este un obiect la care un utilizator primește acces; conținutul-copil moștenește acordarea prin lanțul de chei străine. Acesta e mecanismul care permite instituției să descentralizeze editarea fără a da treizeci de oameni control asupra întregului site.
- O instituție pe deployment. Nu există graniță de tenant în modelul de date — separarea între instituții este separarea instalărilor.
- Interfața de administrare e accesibilă doar din rețelele agreate. Unde se trasează granița și cine o poate schimba se stabilesc la implementare.
- Întărirea autentificării există: încercările repetate eșuate blochează contul, parolele se păstrează sub formă de hash și se verifică față de reguli de complexitate.
- Datele personale colectate sunt minime și cu consimțământ consemnat. O cerere de preînscriere conține nume, date de contact, vârstă, localitatea de domiciliu, anul promovării bacalaureatului, programele alese și trei bife separate de consimțământ — prelucrare, transmitere către parteneri și a fi contactat — fiecare consemnată ca dată sau nu.
- Registrul de candidați e prin construcție doar de adăugat. Adăugarea, modificarea și ștergerea sunt dezactivate în interfață; rămân vizualizarea și exportul. E o proprietate bună pentru audit și una proastă pentru ștergere: o cerere de corecție sau de ștergere se tratează ca operațiune administrată pe date, nu dintr-un ecran (vezi Ce NU e inclus).
- Nimic nu se șterge automat. Înregistrările de candidați, adresele de newsletter și mesajele consemnate se păstrează pe termen nelimitat până când se agreează o regulă de retenție și se pune în funcțiune o ștergere programată; ambele se decid la implementare și se documentează pentru ea.
- Auditul acoperă cine a modificat ce obiect și când, prin jurnalul de administrare. Deciziile de publicare în sine nu sunt auditate separat.
- Proprietatea. Instituția deține codul, conținutul, fișierele încărcate și baza de date. Copiile de siguranță, monitorizarea și verificarea lor sunt o responsabilitate de operare: se atribuie explicit sau se contractează prin Managed Hosting.
Seamănă vreuna cu operațiunea ta?
Începe cu diagnosticul. Cartografiem cum circulă munca de fapt, apoi adaptăm blueprintul la ea.