Analyse intéressante – brosse une panorama large des vues de “types de connaissances/compétences” demandées au ingénieurs. Elle souligne l’importance croissante du collectif dans la résolution des problèmes.

Elle montre également que la créativité est façonnée par le contexte social qui doit encourager l’appropriation des connaissances par conversation au sens d’un processus cognitif et développer la conversion de connaissance, au sens explicitation “externalisation” puis incorporation dans le tissu social ou “internalisation”. Elle s’appuie sur le modèle de Nonaka et Takeuchi qui définit une boucle de conversion de la connaissanc. Cela ressemble un peu à du Kolb, mais avec une vue collective.

Elle justifie finalement les apports des projets pour développer les connaissances nécessaires pour un ingénieur de manière classique. Elle insiste néanmoins sur l’importance de l’attitude de l’enseignant, du tuteur pour encourager conversation et processus de conversion

Définition de ubiquitous dans cet article :

Ubiquitous learning research is about seamlessly enabling learning through the use of sensors that gather data from the learner surroundings and adapt learning content accordingly.

Étonnant : le capteur proposé coté étudiant est l’électroencéphalogramme (EEG). Ces données excessivement personnelles sont envoyées dans le cloud. J’aurai bien aimé avoir la justification d’utiliser un capteur aussi intrusif pour l’accompagnement d’un apprenant. Apprendre n’importe où, n’importe quand, mais avec un EEG … bon c’est vrai l’usage des écouteurs oreillettes est déjà largement admis, mais quand même.

L’utilisation d’Ubiquitous Learning System dans le titre n’est qu’un prétexte pour étudier une architecture cloud/MapReduce d’un classifier flou.

Si on considère ce type de capteur comme pertinent, les traitements afférents ont vocation à être fait ailleurs que dans un téléphone. La question du débit de données n’est par contre pas abordé, ce qui paraît pourtant être un goulot d’étranglement dans le système (à la lecture de l’article, on reste effectivement dans le raisonnable 7Mo pour 12 000 échantillons).

L’algorithme d’adaptation proposé pour exploiter ces données est basique, puisque le résultat se ramène à 3 niveaux de ressources (facile, moyen, supérieur), via un classifier flou.

L’auteur aborde l’introduction de l’algorithme Map reduce par une question de fiabilité. On est dans la justification d’une architecture pour supporter des ULS large échelle.

Il pourrait être intéressant de comparer différentes architectures (cloud ou traitement local entre autres) et de voir l’impact sur plusieurs critères annoncés mais non justifiés : consommation téléphone (l’envoi de données est un facteur important de consommation), consommation globale, débit réseau, délai (latency) …

Au final, on parle ici d’architecture cloud/mobile pour le traitement de données capteurs, peu de learning system. On ne voit pas non plus l’intérêt de passer par le cloud puisqu’il n’y a pas d’agrégation de données.

A noter sur les aspects modèle économique liés : site de funding de projets créatifs : kickstarter

Je regroupe ici des frameworks qui sont basés sur ces idées, avec une orientation plutôt Android :

• sur le développement sur téléphone :
  • AppInventor se veut simple d’usage (pas de réelle programmation) avec une approche brique qui permet de construire facilement une petite application (un écran) sur Android. À noter qu’un transfert vers l’environnement de développement SDK standard (Javabridge). Par contre, ce projet est reversé vers le mobile learning center du MIT, et ne sera donc plus directement un produit Google.
  • PhoneGap propose un framework permettant de développer en Javascript pour viser plusieurs plateformes. Le projet libre est en cours de transformation/rachat. Sur le même principe de framework multi plate forme HTML5, Sencha, et Titanium proposent des produits libres et/ou orientés applications payantes.
• sur le développement d’interfaces multitouch multi plateforme :
  • PyMT , développée en Python sous licence LGPL, et semble particulièrement adaptée à du prototypage rapide (issu du projet Kaleidoscope)
• sur le couplage serveur et téléphones
  • Thrift semble très orienté multi plateforme (coté serveur et coté terminal) – pas encore de page WP francophone. (merci à @_Stephane_ )
• Sur la collaboration synchrone et autres visios
  • UC-Engine : framework pour collaboration synchrone. sur github : site des sources, site de doc, une noria de projets connexes en remontant dans github sur AF83. En termes d’architecture,implémente un publish suscribe persistant, développé en Erlang coté serveur. Utilisable sous forme de widgets javascript. Le format d’échange est basé sur REST/JSON
  • OpenTok issu de Tokbox, gratuit mais pasl ibre et qui assurer l’hébergement ;

Si on voulait les classer, on pourrait se poser les questions suivantes : quel niveau nécessaire pour les prendre en main ? Quelle facilité de prise en main ? Quelle puissance d’expression ? … (mais je n’ai pas encore tout en main pour l’instant)

Principe issu du web, le principe du mashup permet d’organiser une url en fonction de plusieurs sources de services et ainsi de produire des pages web riches rapidement. Nous avions fait un petit exposé là dessus : Practice Mashups à Mlearning2009, dans laquelle nous recommandions la vidéo « Practice Mashups »

Sur les manières plus classiques de programmation, le site d’Android rest incontournable

• Android Developers (voir également les slides du cours de Virginia Tech)
• comme API de Réalité Augmentée Mixare paraît un bon choix (dépôt gitHub)

Qui a d’autres suggestions ?

PS : ce billet fait partie d’un ensemble de notes prises dans le cadre de la préparation d’un cours pour des élèves ingénieurs dernière année Ingénierie des applications mobiles (et ubiquitaires), début 2012. Toute suggestion sera la bienvenue !

Sur quelques applications emblématiques :

• Le téléphone qui n’existe pas encore, mais est-ce-pour-longtemps : Promaganate ou le smartphone « rêvé »
• Des nouvelles interfaces sur les smartphones :
  • Wikitude pionnier de la Réalité Augmentée
  • Goggles ou la reconnaissance d’images
  • Reconnaissance faciale et infos dans des lunettes (recherche en laboratoire) et l’impact vu par Numérama
  • AR Drone tirant partie des gestes du joueur ;
  • Sans oublier la reconnaissance vocale qui est en train de percer ;
• des usages des capteurs
  • InstantHeart Rate
  • Smart Alarm qui vous réveille en fonction de vos cycles de sommeil (i.e en fonction de mouvements détectés pas l’accéléromètre)
• agrégation de données
  • le niveau sonore du monde entier : WideNoise
  • Le smartphone sert aussi à prévoir les feux rouges, article de l’atelier montrant l’intérêt de pouvoir agréger les données d’une masse de smartphones
• Le jeu
  • la course contre des droids en Réalité Augmentée (en fait une pub de Samsung Galaxy, enfin pour l’instant Zombie Run est en cours de développement )
• Géopolitique
• Spimes
• Ville

Sur quelques technos à venir :

• NFC ou le paiement avec son téléphone
• Technologie 3D et mobile, article court prospectif marché
• Sixth sense : pour relier réel et virtuel → le dépôt est créé sur google code mais pas encore rempli : quand ce sera fait (si c’est fait), ce sera un objet de choix pour les fablabs ;

Quelques articles de fond pouvant servir de travail bibliographique :

• The State of the Internet Operating System par Tim O’Reilly
• Omnitouch: Wearable Multitouch Interaction Everywhere (paper)

Aspects développements :

• Comparing the iPhone and Android Development Environments

Des présentations ? Sur slideshare !

• Une approche design : « Designing for the Ubicomp Era »

• Designing Mobile Experience en CC-by-nc
• Voir aussi Mobile Abilities Map sur ce qu’on peut faire avec des mobiles. Excellent.
• une vue marketing : Mobile Marketing Trends in 2020
• une vue large : Mobile Trends in 2020

PS : ce billet fait partie d’un ensemble de notes prises dans le cadre de la préparation d’un cours pour des élèves ingénieurs dernière année Ingénierie des applications mobiles (et ubiquitaires), début 2012. Toute suggestion sera la bienvenue !

• Stanford (Developping apps for iOS par Paul Hegartyet iPhone Application Development par Alan Canistraro et Josh Shaffer disponibles sur iTunes )
• Harvard (Mobile Software Engineering orienté iPhone)
• Virginia Tech (Jules White et al.) : sur Android en mode projet
• Vanderbilt V-MAT group avec une page projet sur google code
• Columbia University Mobile computing with iPhone and Android en 2009
• MIT (Hal Abelson) Building mobile applications with android – MIT en 2008 (a monté un centre pour le mobile learning avec Google)
• Columbia University
• University of Maryland (Adam Porter)
• Carnegie Mellon – Silicon Valley( Tony Wasserman) - (Tony gave recently a really neat talk at FSE FOSER )
• Harding University (Frank McCown)
• University of Alabama (Jeff Gray)
• Glasgow (Mobile Software Engineering pour Undergraduate)
• University of South California (Trends in Mobile and Cloud Computing, Spring 2010 par Ramesh Govindan mais peu de détails)

Connexe :

• Le cours de JY Tigli sur l’informatique ambiante. De mon point de vue, il y a bien une continuité entre mobile, ambiant, ubiquitaire. J’aime à penser que la réalité augmentée des mobiles est un premier point d’entrée pour lier réel et virtuel, l’informatique ambiante un second. Dans les 2 cas, on part d’un équipement léger et on remonte vers l’infrastructure et le web.

L’effort à Télécom Bretagne sur le mobile est important :

• un cours d’intersemestre (i.e. cours d’ouverture pour élèves de 1ère ou éème année) appelé codecamp, ouvert en 2010, reconduit en 2011. Voir CodeCamp : un non-cours pour apprendre à programmer sur un mobile
• Un cours en 3ème année prévu début 2012 pour les élèves ingénieurs en apprentissage
• Un cours en 3ème année prévu début 2012 pour les élèves ingénieurs : Ingénierie des
  applications mobiles et ubiquitaires

D’où la série de billets autour des aspects techniques à venir sur ce blog…

Pour justifier l’intérêt de se former dans le domaine du mobile :

• Cloud + Mobilité + Social: l’ère post-PC a commencé. Ne ratez pas le départ! : article ZD Net
• Where the Jobs Are in 2011: Software Engineering / Mobile applications and cloud computing are driving demand for new engineering grads : article IEEE-spectrum
• Sur un marché en devenir : Why Schools Should Stop Banning Cell Phones, and Use Them for Learning

PS : ce billet est susceptible d’évoluer pour suivre la collecte en cours. Les éventuels lecteurs sont invités à suggérer des compléments

PS2 : PS : notes dans le cadre de préparation de cours pour des élèves ingénieurs dernière année Ingénierie des applications mobiles (et ubiquitaires), début 2012. Toute suggestion sera la bienvenue !

K Scott, R. Benlamri – IEEE Transactions on Learning Technologies, 2010 – computer.org

objectif de la recherche : proposer des opportunités variées d’apprentissage collaboratif. 

Basé sur l’idée que l’usage des technologies dans l’espace d’apprentissage (learning space) reste peu développé

• proposer un environnement qui améliore l’apprentissage collaboratif et les interactions dans les face à face
• nouveaux schémas (patterns) d’interactions sociales et intellectuelles
• découverte de ressources selon les activités et mécanismes de récupération pour faciliter le passage de connaissances

Idée : proposer une infrastructure dans les locaux de la fac : peu chère, compatible avec l’existant, tirant parti des équipements à la convergence de : mobile/ubiquitous computing, communications sans fil, semantic web, se voulant ouvert sur les modalités pédagogiques.

La navigation, interaction, récupération, partage de ressources est basée sur une gestion de contextes, permettant de relier : localisation, agenda, équipement, personne et ses voisins. (fin de 3)

localisation et mobilité (3.1) Le système doit comporter un réseau donnant localisation, mobilité, et connection aisée, “seamless”. La résolution proposée est au niveau de la zone. 3 technologies proposées : triangulation par RF, GPS et IR (par ajout d’un récepteur IR/USB. (3.1) : c’est donc un élément central du système

Infrastructure (3.2) : plutôt basé sur une approche pair à pair pour éviter blocages. Propose une approche agent type JADE  et d’utiliser RDF pour les formats d’échange. je passe sur les choix pour la création de services, la publication et découverte de servies (basé sur Zeronconf), l’approche d’adaptation de réseau décentralisée grâce aux fonctionnalités P2P et qui permet ainsi d’adapter les modes réseaux en fonction du type de session (au sens regroupement de personnes : cours,travail de groupe …). En fait, leur implémentation ramène toujours l’organisation à un super nœud qui contrôle la session. La collaboration est organisée autour d’un document hybride partagé.

La communication temps réel est basé web/AJAX en mode push (Comet)

La connectivité et l’intégration concerne les équipements existants (PC fixes, projection …) qui peuvent se connecter au super noeud de la session : la prise de contrôle de ces équipements est possible pour les intégrer dans la session collaborative. LA connexion avec des équipements spécifiques de laboratoire se fait de la même manière. L’équipement peut alors délivrer de l’information. Les mobiles peuvent également se connecter, et même devenir super noeuds

Penser les espaces en tant qu’espace d’apprentissage : i.e. fonctionnalités applicatives : partage de ressources (support de cours slides et notes), prise de notes personnelles synchronisée avec slides, par le biais de metadatas. Mais aussi possbilité de poser des questions et d’interagir, d’échanger entre pairs

à un niveau supérieur, l’enseignant peut suggérer des lectures en fonction de l’avancement dans ses cours. construit sur un modèle d’ontologie simpliste.

Conclusion : L’hypothèse centrale est que cela se passe sur le campus, donc basé sur une infrastructure minimale de localisation spécifique

Quelques questions à explorer pour aller plus loin :

• quid de positionnement  de services entre couches réseau, infrastructure, services
• et de l’adaptation de ce positionnement dans une approche de chgt de réseau seamless
• quid de l’utilisation max de services externes
• clarifier la notion de “learning space” livre Educause ? autre ?
• quid de modes dégradés : collaboration dans une chambre d’étudiants, dans un bus …
• quid d’un tel environnement dans un fablab
• et donc quid d’un couplage de tels espaces ?

• un projet d’élèves de l’INSA Toulouse : MagnitudeHQ. Résultat impressionnant qui montre bien que le développement d’application mobiles est atteignable par des élèves (ce dont nous nous doutions un peu après notre codecamp)
• un projet à consonnance tyrolienne : Mixare, dont le code est sur un git, la vue globale sur un blog et qui semble tourner également sur iPhone.

crédit photo : augmented reality game bibliotheek deventer par nilsmengedoht

L’introduction est particulièrement intéressante.

1. Sur le degré d’automatisation souhaitable, et sur la capacité d’action sur son environnement d’apprentissage pour permettre l’acquisition de compétences.
   De mon point de vue, il est clair que pour une découverte, l’environnement doit faciliter l’approche d’une connaissance, d’un phénomène, mais qu’à un niveau plus avancé, il doit être possible de construire son environnement. Un parallèle peut être fait avec les procédés d’expérimentation : on démontre un phénomène, on propose de refaire la manipulation, le montage, et dans une étape ultérieure, on demande de construire la démarche expérimentale et de définir les expérimentations nécessaires. Un fil à creuser pour l’appropriation d’un PLE?
2. Sur le positionnement PLE vs ALS : « le PLE vise à remplacer (NDT: étendre ? )l’environnement d’apprentissage physique. L’ALS se concentre sur le remplacement de l’instructeur (NdT : est ce qu’une définition d’aide à l’instructeur ne pourrait pas être plus féconde ?) »

Leur approche générique vise à automatiser les interactions inter services (widgets) par des liens/ flux sémantiques. Cela fait sens mais ne résout pas leur construction et la place de l’utilisation dans celle-ci.

mais la nouvelle notion de WebApp (d’après WebAppAgendy), qui permet d’avoir une interface web dédiée sur un smartphone, plus agréable qu’un site wap, sans avoir à passer par les différents stores et donc permettant la mise à jour au chargement de l’équivalent de la première page ressemble furieusement aux fonctionnalités que l’on souhaite d’un widget.

Basée sur les technologies CSS et Javascript, on se retrouve dans le même environnement qu’un widget.

Le site Android Developper propose maintenant une documentation complète pour développer des WebApps. Ne reste donc plus qu’à reprendre un code de widget existant et voir comment il peut s’embarquer dans une webapp. Ce serait intéressant de voir comment factoriser les développements à ce niveau pour essayer d’avoir un bloc métier et différents containers pour différentes cibles.

Indispensable pour notre prototype.