El servei BaaS permet la creació d'eines de networking dins l'entorn web de l'usuari del servei, adaptant-se a la imatge corporativa de la web.

La part central del networking dins del BaaS, és la base de contactes.

Contingut

• Objectiu
• Perfil
• Perfil d'empresa
• Relacions
• Habilitats
• Sector i especialitats
• Calendari
• Convocatòries
• Directori
• Tauler d'anuncis
• Darrera activitat
• Públic vs restringit

L'objectiu de l'espai de Networking és posar en contacte als usuaris d'un determinat perfil. Aquests poden editar les seves dades, definir les seves habilitats, indicar el sector on desenvolupen la seva activitat econòmica i quines són les seves especialitats.

Definició dels membres

Els membres de l'espai de networking són els socis i els formants de la junta.

Cal entendre socis i junta com la definició social del grup. Per explicar millor l'exemple, veiem dues definicions de soci en dos mòduls diferents de BrightSide.

El perfil d'usuari és l'espai on l'usuari autenticat gestiona les seves dades, Relacions i Habilitats .

Composició

El perfil està separat quatre seccions: Dades d'usuari, Experiència, Estudis i Habilitats. La secció d'usuari té un contingut fix, mentre que experiència, estudis i habilitats són col·leccions que poden contenir des de zero a múltiples elements.

Dades que es mostren, quan i com

Els perfils es poden veure en diferents llocs de l'espai web del servei BaaS. En algunes ocasions com a emergents, per exemple, en etiquetes o en els noms dels usuaris. En altres, en fitxes de perfil, habitualment en directoris.

En tots els casos, les dades mostrades tenen en compte l'usuari que visualitza i les opcions de privacitat de l'usuari del perfil.

Privacitat

Alguns dels apartats del perfil són controlats per les polítiques de privacitat. Aquestes es veuen com a icones al costat dels camps configurables. El significat de les icones és aquest:

El perfil d'empresa és l'espai on l'usuari autenticat gestiona les dades de la seva empresa. Per a poder editar l'empresa cal ser considerat Responsable tal com es defineix a Relacions .

Composició

Tant contactes com relacions tenen una tipificació interna que apunta a facilitar la creació de noves relacions per part dels usuaris.

La finalitat de les relacions és crear una base d'experiències i estudis mantinguda pels mateixos usuaris.

Contactes i els seus tipus

Els tipus de contactes afecten el perfil i les relacions establertes amb altres contactes, independentment dels permisos d'accés que aquests tinguin i el rol que juguin dins del conjunt de mòduls. Els contactes poden ser de quatre tipus diferents:

Les relacions

Quan parlem d'Experiència o d'Estudis dins del BaaS, parlem de relacions entre usuaris, empreses i/o centres. Aquestes relacions es composen de la següent informació:

Tipus per descobriment

Els tipus per descobriment són aquells que no s'assignen directament com a tals, sinó que es dedueixen a partir dels tipus definits. Aquests tipus per descobriment són bàsics pel Perfil i pels diferents tipus de Directori .

La següent imatge mostra els diferents tipus d'usuaris i les interseccions dels tipus per descobriment.

Vigència de les relacions

S'entén una relació com a vigent, quan es troba dins les dates d'inici i fi. Aquesta vigència es valida amb la data actual del sistema.

Alguns mòduls usen tant el contacte com la seva empresa o centre, per gestionar la participació. En aquests casos, la vigència es valida amb la data de la participació, no la de sistema. Això permet la traçabilitat en les participacions d'empresa o centre.

Procés de validació de la relació

Les relacions iniciades per usuaris autenticats queden pendents de validació. Per resoldre aquest estat, se segueixen unes regles predefinides:

1. Sí l'usuari té un correu amb el mateix domini que el connector web o connectors domini del contacte amb qui es vol relacionar, la relació es valida.
2. Si el contacte amb qui es vol relacionar té un responsable de validacions, se li proposa que sigui aquest qui ho validi.
3. S'afegeix l'opció que sigui un usuari administrador qui ho validi. S'envia avís als usuaris administradors i queda a la cua de pendents.
4. S'afegeix l'opció d'indicar un correu amb la persona que pot validar.

El resultat del procés, en cas de validar-se, generarà un avís pels usuaris administradors. Totes les validacions pendents es veuran en la cua d'avisos dels usuaris administradors.

Si l'usuari escull el cas 4, internament poden donar-se els següents casos:

1. El correu existeix a la base, és de la mateixa empresa/centre i és el mateix que el del responsable de validacions. S'executarà igual que si hagués escollit el cas 2.
2. El correu existeix a la base, és de la mateixa empresa/centre i aquesta no té responsable de validacions. S'enviarà un avís als usuaris administradors perquè avaluïn el cas.
3. El correu existeix a la base, és de la mateixa empresa/centre, però no correspon al responsable de validacions. S'enviarà un avís als usuaris administradors perquè avaluïn el cas.
4. El correu és d'un usuari administrador. S'executarà igual que si hagués escollit el cas 3.

Les habilitats permeten ampliar el perfil d'usuari i són usades internament per a la gestió d'homònims.

Les habilitats se separen en tres tipus:

Els usuaris poden afegir tantes habilitats al seu perfil com creguin oportunes.

Les empreses i centres poden ampliar el perfil afegint sectors i especialitats.

El calendari és una eina associada a l'activitat dins els mòduls del servei BaaS. Això s'explica pel fet que moltes activitats tenen dates associades, siguin d'inici, modificació, finalització i d'altres. Els calendaris són capaços de mostrar l'activitat, lligant-la a l'entitat que l'ha produïda. Així, des d'una data, l'usuari pot arribar fins a l'activitat i acabar consultant els usuaris associats.

Com la resta de components, el calendari és sensible a la privacitat imposada per l'usuari en el seu perfil.

Les convocatòries formen part de l'anomenat Networking, donat que és l'eina per a reunir un grup d'usuaris en unes dates i hores determinades. Els usuaris convocats poden consultar les convocatòries públiques vigents o passades i les convocatòries privades on han estat convocats. En el visor complet de convocatòries hi ha llistat els assistents usant etiquetes de contacte que mostren el perfil emergent de l'usuari.

Convocatòries està explicat a Convocatòries .

El Directori és un llistat de perfils on els usuaris amb permisos poden consultar les dades dels perfils segons les polítiques de privacitat que cadascun dels usuaris del perfil hagin definit.

Els directoris poden ser totals o per tipus.

Es pot trobar informació dels diferents tipus a Relacions .

El tauler d'anuncis permet als usuaris penjar ofertes o demandes de diferents tipus. Aquests anuncis poden estar associats a l'empresa o directament a l'usuari, segons configuració. El tauler d'anuncis és una ampliació dels serveis de contacte.

El Serveis són reservats a les empreses donades d'alta a la base de contactes. La definició d'empresa és molt laxa i es refereix a contactes que tenen treballadors en el seu organigrama.

Els camps d'un servei

Àmbit i permisos necessaris

Els serveis són sempre editables pels treballadors de l'empresa que dóna el servei i pels usuaris administradors. L'aplicació permet enviar un correu de prova als treballadors de l'empresa.

Un servei es pot publicar. L'acció de publicar pot executar-se una sola vegada per part dels treballadors i tantes vegades com vulguin els usuaris administradors. L'àmbit de l'acció de publicar són els subscriptors de la cua Notificacions del lloc web. També pot haver-hi un context dins la web amb els serveis publicats.

Usant els serveis de contactes i les Macros del mòdul, és possible crear un context tipus marketplace.

En l'exemple que es mostra a continuació, el context que mostra el marketplace és /marketplace.

Exemple del contingut de la pàgina

{ @services:all:all:/marketplace:12:#preload}
<div class="ui basic padded segment">
  <div class="ui stackable grid">
    <div class="five wide column">
      <div class="ui segment">
        <h3>{ @res:VIEW_CALENDAR:2}</h3>
        { @marker:calendar:fullcalendar:sources=[servTypes=all;color=#880E0E]}
        <div class="ui hidden divider"></div>
        <h3>{ @res:VIEW_LASTENTRIES:2}</h3>
        { @lastservice-summary:all:all:/marketplace:10:item}
      </div>
    </div>
    <div class="eleven wide column">
      { @dao-search:/marketplace}
      { @services:all:all:/marketplace:12}
    </div>
  </div>
</div>

Com funciona?

La primera macro usa el template fals #preload, per indicar al iterador que carregui els valors previs. Aquests serviran per omplir les llistes de rols, tipus i temàtiques dels serveis, usades pel cercador estàndard per a serveis.

La resta afegiran, a la part esquerra, un calendari i un llistat de darreres entrades. I a la part dreta, el cercador i l'iterador de serveis amb pàgines de 12 serveis màxim.

Exemple de l'arxiu dao-search-marketplace

A Best Practices hi ha un exemple de com afegir un buscador. El template search és part de l'estàndard.

<?xml version="1.0" encoding="ISO-8859-1"?>

<elephant version="1.0">
  <dao-search class="services-search" root="service" template="search">
    <input name="search-value"/>
    <select name="role"/>
    <select name="type"/>
    <input name="actives"/>
    <input name="with-date"/>
  </dao-search>
</elephant>

Configuració específica

El marketplace té configuracions específiques dins l'arxiu service-context.properties que es troba a BaaS -> Eines -> Fitxers -> Configuració -> Propietats. El format de l'arxiu és clau=valor.

Mostrar la darrera activitat és una manera d'incentivar usuaris a ser més actius. Aprofitant LastActivity API i UserLastActivity API de la llibreria Elephant, l'apartat de Networking pot mostrar el moviment dins del servei BaaS.

L'activitat del conjunt

LastActivity API recull els darrers moviments de les entitats del sistema, hi associa el conjunt de participants usant una cerca profunda i, finalment, serialitza els resultats pel seu ús. Per a cada element d'activitat, l'API contrasta amb el controlador de l'entitat si el participant pot veure l'element. Com a resultat, els elements mostrats són específics per l'usuari a qui es mostren.

L'activitat pròpia

L'aproximació usada per UserLastActivity API és diferent. En ser un llistat orientat a l'usuari, la cerca es fa en les activitats específiques d'aquest. El resultat final és un conjunt d'elements restringits a l'usuari a qui es mostra.

Quan es pretén mostrar l'activitat de tercers, els elements mostrats es controlen usant Visual elements .

Tots els mòduls del servei BaaS donen la possibilitat de crear espais públics i espais restringits. La diferència és, en moltes ocasions, subtil. En ambdós casos, les dades a mostrar poden variar la privacitat segons el rol de la persona a qui es mostren. Una única entitat podria ser formada per parts amb privacitats ben diferents.

Característiques dels espais públics i els restringits