Procés d’ideació i evolució del projecte

El projecte Camina i fes UNLOCK! neix amb la voluntat de transformar una activitat quotidiana com caminar en una experiència lúdica i visualment significativa. A partir de la base desenvolupada a la PR1, l’objectiu de la PR2 ha estat ampliar aquesta proposta mantenint la mecànica principal, però afegint una nova capa de contingut mitjançant la integració d’una API externa. Enfocarem aquesta nova versió com una app específica amb contingut de Tarragona.

Des del punt de vista conceptual, s’ha considerat important no alterar la naturalesa “effort-free” de l’app. L’ usuari continua interactuant mínimament amb el dispositiu, mentre el progrés es produeix de manera natural a mesura que camina. La nova funcionalitat introduïda no substitueix el joc, sinó que l’enriqueix, aportant context cultural i informatiu a les imatges desbloquejades.

Integració d’una API externa

S’ha integrat una API externa pública: la MediaWiki API (Viquipèdia) en llengua catalana.

L’ elecció d’aquesta API respon a diversos criteris:

• és gratuïta i sense necessitat d’autenticació,
• permet consultes dinàmiques en format JSON,
• ofereix contingut rellevant i contextualitzat,
• i disposa de suport CORS, imprescindible per a la seva integració en una aplicació web híbrida amb Capacitor.

Cada imatge desbloquejada a l’ app està associada a un indret real de la ciutat de Tarragona. Quan l’usuari accedeix a la galeria i selecciona el botó Info, l’ aplicació realitza una crida dinàmica a l’API de la Viquipèdia per obtenir informació contextual sobre aquell indret: títol, resum descriptiu i enllaç per ampliar la informació.

Aquesta integració compleix el requisit de “petició personalitzada”, ja que la consulta depèn directament de la imatge seleccionada, i inclou control d’errors per gestionar possibles problemes de xarxa o respostes no disponibles.

Visualització de la informació

La informació retornada per l’API es mostra dins l’ aplicació mitjançant un modal dedicat, evitant així que l’usuari abandoni el flux principal del joc. Aquesta solució permet mantenir la coherència visual de l’app i reforça la idea que la informació forma part de l’ experiència de desbloqueig.

La presentació de les dades s’ha dissenyat de manera clara i jerarquitzada, prioritzant la llegibilitat i l’accessibilitat, i reforçant el valor afegit de l’API sense sobrecarregar la interfície.

Funcionalitats natives i feedback tècnic

L’aplicació continua fent ús de funcionalitats natives del dispositiu, principalment la geolocalització, que és l’eix central del funcionament del joc. El càlcul de la distància recorreguda permet determinar el progrés de desbloqueig de cada imatge.

Arran del feedback rebut a la PR1, es va analitzar la possibilitat d’implementar watchPosition per millorar la precisió del seguiment continu. Tot i reconèixer els avantatges d’aquesta aproximació, en aquesta iteració s’ha prioritzat l’estabilitat del MVP i la integració correcta de l’API externa. Com a solució tècnica per facilitar el desenvolupament i el testeig, es manté el Mode Demo, que permet simular l’avanç de metres sense necessitat de desplaçar-se físicament. Aquest plantejament ha permès continuar iterant sobre el projecte de manera eficient, deixant la millora del seguiment GPS com a possible evolució futura.

Galeria, navegació i estat del joc

Les imatges completades es poden consultar en qualsevol moment i s’obren en un visor amb opcions de zoom. La integració del botó Info dins la galeria reforça la connexió entre el contingut visual i la informació contextual obtinguda de l’API.

S’ha tingut especial cura a separar els estats de “desbloqueig en curs” i “visualització”, evitant animacions o efectes que poguessin generar confusió quan l’usuari navega per contingut ja completat.

Proves i entorn de test

Les proves s’han realitzat principalment amb Android Studio, utilitzant diferents perfils d’emulador per validar el comportament de l’aplicació en diverses resolucions i formats de dispositiu. Aquest procés ha permès detectar i solucionar problemes relacionats amb l’estat persistent, la configuració de l’entorn i la reconstrucció del projecte en entorns nets.

Com a millora respecte versions anteriors, l’aplicació arrenca des d’un estat inicial net en el primer llançament, evitant conflictes derivats de dades de proves prèvies guardades en emmagatzematge local.

Les proves finals s’han realitzat amb Android Studio amb els següents perfils:

• Tablet Pixel (API 35)
• Pixel 9 Pro XL (API 36)
• Medium Phone (API 36.1)

Dependències i avisos de seguretat

Durant la instal·lació del projecte mitjançant npm install, el gestor de paquets indica l’existència d’algunes vulnerabilitats en dependències de tercers (2 de nivell moderat i 2 de nivell alt).

Aquests avisos corresponen a llibreries utilitzades internament pel framework i no a codi propi del projecte. En tractar-se d’un MVP amb finalitats educatives i no d’una aplicació destinada a producció, s’ha prioritzat l’estabilitat del projecte i no s’han aplicat actualitzacions forçades (npm audit fix --force), ja que podrien introduir canvis trencadors o incompatibilitats amb Capacitor i Vite. Aquesta decisió reflecteix un criteri habitual en entorns reals, on la gestió de vulnerabilitats es fa de manera controlada i contextualitzada segons l’estat i l’objectiu del producte.

Resultat final i aprenentatges

El resultat final és una aplicació Android funcional, estable i coherent amb el concepte inicial. A nivell d’aprenentatge, la PR2 ha posat de manifest la importància de:

• integrar serveis externs de manera significativa,
• gestionar correctament els estats i errors,
• i prendre decisions tècniques equilibrades entre ambició i estabilitat.

El projecte consolida el potencial de Capacitor com a eina per portar aplicacions web a l’àmbit mòbil i estableix una base sòlida per futures ampliacions.

ENLLAÇ A GITHUB: https://josepmsole.github.io/CaminaifesUnlockTarragona/

Procés d’ideació i possible aplicació del projecte

El projecte Camina i fes UNLOCK! s’ha concebut com una aplicació que transforma l’acció quotidiana de caminar en una experiència de descobriment visual progressiu. La idea principal és que l’usuari desbloquegi contingut sense haver d’interactuar constantment amb el dispositiu, fent de l’app una experiència pràcticament effort-free.

Durant la fase d’ideació, un dels primers problemes va ser definir un concepte prou senzill però amb projecció futura. Inicialment es van considerar idees més complexes, però es va optar per una mecànica clara i escalable. Aquesta decisió va permetre mantenir la demo acotada i funcional, però alhora obrir la porta a un possible ús turístic, on ciutats o pobles podrien oferir conjunts d’imatges associades a recorreguts concrets, incloent informació històrica o cultural.

Funcionament de la demo actual

La demo implementa el comportament de l’app amb 5 imatges, suficients per entendre el funcionament general del sistema. Les imatges utilitzades són fotografies pròpies realitzades entre 2010 i 2013, fet que aporta coherència i control total sobre el contingut visual.

Un dels problemes detectats en aquesta fase va ser com representar visualment el progrés sense recórrer només a números o barres clàssiques. La solució va ser utilitzar el canvas per mostrar una imatge pixelada que es va revelant progressivament, convertint el progrés en una experiència visual clara i intuïtiva. Això va permetre reforçar la idea de “desbloqueig” i fer el procés més atractiu.

Canvas i representació del progrés

El canvas és l’element central de l’aplicació. Cada imatge comença mostrant-se pixelada i es va revelant mitjançant tiles segons el percentatge de progrés assolit. El càlcul es basa en una relació directa entre distància recorreguda i metres necessaris per completar la imatge:

const progress = distanceMeters / METERS_TO_UNLOCK;

const tilesToShow = Math.floor(progress * totalTiles);

Durant el desenvolupament d’aquesta part va aparèixer el problema de gestionar l’estat visual sense sobrecarregar l’emmagatzematge. Inicialment es va plantejar guardar l’estat de cada tile, però això complicava el sistema. Finalment, es va optar per recalcular el nombre de tiles visibles a partir del percentatge global, simplificant el codi i millorant el rendiment.

Controls, navegació i mode DEMO

L’aplicació inclou diversos controls: START per iniciar el repte, SEGÜENT per seleccionar quina imatge es vol desbloquejar i RESET per reiniciar completament la demo. També s’ha incorporat un mode DEMO que permet avançar manualment el progrés.

Un problema clau en aquesta fase va ser com provar correctament l’app sense disposar d’un dispositiu Android físic. La solució va ser implementar el mode DEMO, que permet simular l’avanç de metres dins l’emulador d’Android Studio. Aquest sistema ha estat essencial per validar animacions, lògica de progrés i navegació sense dependre del GPS real.

Dins dels settings, apart del mode DEMO, trobem també un “mode NIT”, un on/off per la vibració, i un selector per la mida dels TILES. Totes aquestes opcions són per a que l’usuari pugui adaptar l’app a les seves necessitats.

Galeria i visualització d’imatges desbloquejades

Les imatges completades es poden consultar des d’una galeria integrada. Quan una imatge està desbloquejada, s’obre en un visor net amb opcions de zoom per examinar-la amb més detall.

Durant el desenvolupament de la galeria va sorgir un problema important: les animacions de desbloqueig apareixien també quan s’obrien imatges ja desbloquejades. Això generava confusió visual. La solució va ser separar clarament l’estat de “desbloqueig en curs” de l’estat de “visualització”, assegurant que les animacions només apareguin durant el moment exacte del desbloqueig.

Proves i entorn de test

Atès que no s’ha disposat de cap smartphone o tablet Android físic, totes les proves s’han realitzat amb Android Studio mitjançant emuladors. Aquest procés ha permès testejar l’app diverses vegades i ajustar tant la interfície com el comportament intern.

Un problema recurrent en aquesta fase va ser la configuració inicial del projecte Android i la gestió de fitxers generats automàticament. Es van produir errors d’importació a Android Studio fins que es va entendre quins fitxers havien de formar part del codi font i quins no. La resolució va consistir a eliminar caches i fitxers locals (com .gradle, build o local.properties) i verificar que el projecte es pogués reconstruir correctament amb les comandes estàndard.

Les proves finals s’han realitzat amb Android Studio am bels següents perfils:

• Tablet Pixel (API 35)
• Pixel 9 Pro XL (API 36)
• Medium Phone (API 36.1)

Resultat final i aprenentatges

El resultat final és una aplicació Android funcional i estable, amb una experiència d’usuari clara i coherent amb el concepte inicial. Camina i fes UNLOCK! demostra com una idea senzilla pot convertir-se en una experiència rica mitjançant una bona representació visual i l’ús adequat de funcionalitats natives.

A nivell d’aprenentatge, el projecte ha posat en evidència la importància del testing iteratiu, la resolució progressiva de problemes i la necessitat de preparar correctament un projecte perquè sigui executable en entorns nets. També ha servit per entendre el potencial de Capacitor com a eina per portar aplicacions web a l’àmbit mòbil.

ENLLAÇ A GITHUB: https://github.com/JosepMSole/camina-i-fes-unlock

El projecte METEOQUARS s’ha desenvolupat per al Repte 3, que plantejava la creació d’una extensió per a Firefox basada en l’ús del temps, en la reutilització del Rellotge Creatiu del Repte 1 i en la incorporació d’una interfície construïda amb el DOM i amb persistència de dades.

En el marc d’aquest enunciat, es va adaptar el rellotge original programat amb p5.js a un format més reduït i coherent amb l’espai disponible a la barra superior del navegador, i es va sincronitzar automàticament amb l’hora real del sistema (a diferencia del Repte 1, que es podía programar manualment), assegurant que continués representant el pas del temps tal com s’exigia en l’activitat. Aquesta adaptació es va integrar al fitxer clock.js, carregat des del content-script.

Es van realizar alguns petits esboixos per decidir-ne l’aspecte, ja que el rellotge creatiu tenia una forma més aviat rectangular. Així doncs, es va decidir que l’extensió ocuparia l’ample de la pàgina, mantenint l’alçada de 150px.

També es va treballar en la creació de l’extensió amb Manifest V3. El manifest.json inclou els permisos necessaris, com storage, i els host_permissions per poder connectar amb l’API d’Open-Meteo. A més, s’hi defineixen tots els recursos externs de l’extensió —p5.js, icones GIF, scripts principals— que estructuren la base del projecte i en garanteixen el funcionament dins del navegador Firefox.

La construcció de la interfície amb el DOM es va fer completament des del content-script.js. Aquesta interfície incorpora elements de UI com el cercador de localització, els botons de desament i previsió, les etiquetes informatives i els contenidors visuals per a la icona meteorològica i el rellotge. Es van distribuir en tres blocs principals (esquerra, centre i dreta) per aconseguir una presentació clara i organitzada. Els estils visuals, es van aplicar amb CSS, injectat des del mateix script, però adaptable a un fitxer style.css extern si cal.

Quant a la persistència de dades, un altre punt clau del repte, es va optar per utilitzar localStorage, que funciona com a equivalent als mètodes storeItem() i getItem() de p5.js. En aquest espai s’hi desa la localització escrita per l’usuari i les seves coordenades corresponents. Quan l’extensió es torna a activar, el content-script recupera automàticament aquesta informació i actualitza la meteorologia, garantint que l’usuari mantingui el seu estat sense necessitat de repetir cap acció.

Amb l’objectiu d’“anar més enllà”, es van integrar fonts externes i funcionalitats ampliades. Concretament, es va utilitzar l’API pública d’Open-Meteo per obtenir temperatura, precipitació i codis meteorològics sense necessitat de clau d’accés. A partir d’aquestes dades, es va implementar una previsió de 48 hores analitzant la variació de precipitació, l’estat del cel i les temperatures.

L’ experiència visual es va reforçar amb cinc icones meteorològiques animades (amb After Effects) en format GIF, creades especialment per representar els 5 estats posibles d’aquesta primera versió: sol, sol i núvol, núvol, pluja i tempesta. També es va incorporar un sistema de color de fons dinàmic que canvia automàticament segons l’estat meteorològic detectat, aportant una lectura immediata i enriquint la percepció final de la interfície.

Com a possibles millores futures es podria incloure una webcam en directe mostrant una camera meteo del lloc buscat, però després d’investigar una mica, no hi ha cap servei que permeti mostrar qualsevol webcam de qualsevol lloc del mon, així que es varia la idea, i per tal d’aprofitar aquell espai, la següent iteració podria incloure una imatge omplint aquell espai (amb un degradat al final de l’esquerra) relacionada amb el resultat del temps de la ubicació cercada.

En el següent exemple es mostra la opció de “Ennuvolat”:

També es podria generar una versió “Mini” de la barra, i readaptar els elements per a un display més reduït.

CONCLUSIÓ

En conjunt, METEOQUARS (que podem variar el nom a METEOQUARTS, tot i què per algun motiu sonava millor sense la T) es presenta com una extensió que integra l’ús del temps, p5.js i una interfície construïda amb el DOM. Manté les dades entre sessions, mostra informació meteorològica actual i incorpora elements visuals i funcionals que en milloren l’experiència. El resultat és una eina clara i pràctica que et permetrà dir: “Abans de dos quarts de 6 estava plovent a Quito”.

————————————-

ENLLAÇ A GITHUB

https://github.com/JosepMSole/-R3-_METEOQUARS

1. Introducció

L’encàrrec de HealthySmile tenia com a objectiu crear una aplicació interactiva que animés els infants a mantenir la boca oberta mentre s’observen les dents, utilitzant la càmera i una temàtica de Halloween. L’aplicació havia d’emprar p5.js per a la part visual i una llibreria externa de visió artificial per detectar l’ obertura de la boca en temps real.

2. FaceMesh

S’ha desenvolupat tot amb p5.js i ml5.js (FaceMesh), ja que ml5 s’integra fàcilment amb p5 i disposa de models preentrenats de reconeixement facial. Inicialment es van detectar errors com ml5.facemesh is not a function, resolts actualitzant la versió de la llibreria a ml5@0.12.2. També es van corregir problemes amb la càmera i la sincronització del model, assegurant que el vídeo es carregués abans de crear el FaceMesh.

3. Detecció de la boca

Per comprovar si la boca està oberta, s’ha calculat un MAR (Mouth Aspect Ratio) a partir de punts facials concrets del model (13, 14, 61 i 291). L’usuari pot ajustar el llindar de detecció (MAR) mitjançant un slider DOM. Aquesta detecció és la base de totes les accions visuals i sonores del joc.

4. Interfície i flux del joc

Abans d’activar la càmera, l’usuari ha de validar els permisos i prémer el botó “Començar”, tal com recomana l’enunciat per motius de permisos i usabilitat. El flux és el següent:

1. Es mostra una pantalla de càrrega amb el logo de l’app.
2. Quan s’ha carregat tot, l’ usuari prem “Començar”.
3. Quan s’obre la boca, s’activen les partícules animades i el so de raspallat.
4. Cada 5 segons de boca oberta apareix un ratpenat com a premi.
5. En aconseguir l’últim ratpenat, es mostra el missatge d’enhorabona i sona el so d’èxit.

També s’ha afegit un botó per reiniciar la partida i un altre per activar o desactivar la música de fons.

5. Partícules i aspecte visual

S’ha implementat un sistema de partícules amb forma de carabasses que apareixen a prop de la boca quan aquesta és oberta. Inicialment les partícules es generaven al costat equivocat del rostre; aquest error s’ha resolt aplicant un mirall horitzontal sobre la posició detectada. S’ha ajustat la mida, la dispersió i el moviment per aconseguir un efecte més suau i coherent amb la temàtica. Cal esmentar que a les primeres versions es van intentar afegir ratpenats, per mantenir coherència amb el logotip, però quedava més fluid i vistós amb les carabasses.

6. So i multimèdia

L’aplicació inclou diversos elements sonors, prèviament fabricats amb “text-to-speech” i una mica d’edició bàsica amb efectes de so:

• RASPALLAT.mp3: s’activa quan la boca és oberta.
• BGMUSICA.mp3: música de fons amb control ON/OFF i volum.
• NOVAICON.mp3: sona cada cop que apareix un nou ratpenat.
• EXIT.mp3: s’activa al final del joc.

El volum del raspallat i de la música de fons és ajustable des d’un slider comú.

7. Problemes i solucions

Durant el desenvolupament s’han trobat alguns inconvenients:

• Desfassament entre vídeo i punts del model: solucionat amb el càlcul mirallat de coordenades.
• Sons que no s’aturaven en tancar la boca: corregit amb control explícit de pause() i currentTime = 0.
• Elements de la interfície fora de lloc: reorganitzats dins de la mateixa caixa visual.
• El degradat inicial (vinyeta) tapava el vídeo: eliminat després d’algunes probes per mantenir claredat visual.

8. Resultat final i valoració

El resultat final és una aplicació funcional que compleix amb els requisits de:

• Detecció real d’obertura de boca amb FaceMesh.
• Interfície amb controls DOM (botons, sliders).
• Partícules animades i sons temàtics de Halloween.
• Missatge final d’èxit i reinici del joc.

Enllaç al repositori GitHub:

https://josepmsole.github.io/R2_Healthysmile_Halloween-Edition/

NOTA: Aquesta versió és una DEMO que es pot completar amb 3 ratpenats (15 segons), per tal de comprovar-ne la operativa. La versió final del joc hauria de tenir una durada d’entre 1-2 minuts (2 minuts és el que es recomana per la higiene infantil, però no es té la boca oberta durant tota l’estona, així que ho podríem ajustar a 1 minut: 12 ratpenats). Cal acabar d’aclarir amb el client.

Abans de començar a fer esbossos i provatures, primer calia idear la manera en que es presentaria aquest “rellotge creatiu”. A l’enunciat se’ns animava a fugir de mostrar l’hora de forma convencional, i poc a poc anava prenent forma un concepte:

Què tal un rellotge que NO ensenya l’hora exacta a primer cop d’ull?

Amb aquesta idea al cap es va començar a muntar la base de “QUARTS”, que a mesura que s’anava polint, pensava en que la gent, quan ho miri, no ha de llegir números: ha de percebre ràpid si encara és abans del primer quart, si ja ha passat la mitja, o si s’acosta el canvi d’hora.

Però l’esboix inicial va ser aquest, més similar a un histograma:

Els primers esbossos apuntaven cap a una gran taula, on representaríem cada hora com una columna formada per 60 petites tires que simbolitzarien els minuts, i que parpellejarien a cada segon fins completar-se. Això acabava formant una taula bastant gran, que incloent la divisió dels quarts, quedava prou vistós (i inclús recordava vagament les cordes d’una guitarra), però calia simplificar més la idea, fer-ho una mica més abstracte.

Es va optar per utilitzar una única barra i agitada, seguint la mateixa estructura dels minuts. A la part superior tenia un numero indicant l’hora, i dalt a l’esquerra un indicador de AM/PM, però després de mirar-ho durant un parell de dies, es va decidir prescindir d’aquests texts, i convertir el valor de l’hora en petites esferes que s’anirien engegant a mesura que es completin les hores.

Amb aquestes últimes modificacions, es complia amb l’objectiu de fer un rellotge que no indiqui a primer cop d’ull l’hora exacta, i que, a més, fomenta l’ús de “dos quarts de deu” o “un quart i mig de tres”.

Així doncs, ja podia fer un llistat final dels elements:

FORMA: Una sola fila horitzontal amb 60 barres (1 per minut), tres línies verticals als quarts (15/30/45) i 12 esferes blanques alineades a dalt que indiquen l’hora sense números ni lletres.

COLOR: Paleta senzilla i contrastada: fons fosc, verd per a barres actives, gris fosc per a futures i blanc per a esferes/contorns. La idea era recrear la sensació d’un gran rellotge digital, però per molt “digital” que sigui, no mostra l’hora exactament a la primera (sempre s’haurà de comptar per esbrinar-ho exactament), així que un verd sobre negre contrasta molt bé per facilitar la correcta visió, sense més distraccions.

Per la TIPOGRAFIA escollida, es van provar algunes opcions mitjançant Photoshop, i la “Emblem” quedava ben integrada, per la semblança de la Q amb les esferes de les hores, i per donar un punt diferencial a aquest petit text i que no semblés la típica font de sistema.

Com a última anotació, caldria quadrar amb el client el tema de l’hora exacta: hem d’implementar que el rellotge llegeix l’hora del sistema? O bé volen fer algun acte de posada en marxa de l’estil “prémer un botó per arrancar-lo”? Amb això, acabaríem de modificar l’script. De moment, a l’inici es pot posar l’hora desitjada (HH:MM:SS) de forma manual.

Enllaç al Projecte en Pantalla Completa:

https://editor.p5js.org/jsolebarg/full/8LRPs-Iaa

Ja ens veurem cap a quarts de cinc!