• Pour un développement pour le boulot, je viens de recevoir un petit player BrightSign HD1024 :
    https://www.brightsign.biz/digital-signage-products/HD-product-line/HD1024

    C’est un tout petit boîtier spécialisé dans la diffusion de vidéos et de séquences « interactives ». Comme les nouvelles versions de ces boîtiers interprètent nativement le HTML5, je suis en train de tester pour lui faire jouer mes présentations interactives, réalisées avec #SPIP, qu’on installe d’habitude sur des PC dans des musées.

    Note : dans la gamme, il faut toujours prendre un modèle « Expanded », tel que celui-ci, doté d’un port USB pour pouvoir brancher le « touch » d’un écran tactile.

    Et donc, avec, j’ai commandé un écran tactile Iiyama T2252MSC-B1 :
    https://iiyama.com/gl_en/products/prolite-t2252msc-b1
    Ça gère le tactile 10 points (c’était un de mes critères).

    Au niveau de la configuration de base, branche l’écran tactile sur le boîtier se fait sans souffrance, la résolution et le tactile sont détectés automatiquement (c’est juste que j’avais oublié de branche le port USB de l’écran sur le boîtier au début, alors forcément…).

    En revanche, pour la documentation, c’est pas super-évident, les trucs sont un peu planqués, et généralement ce qui est mis en avant, c’est la programmation maison avec l’outil d’authoring Brightsign qui, en pratique, ne me sert à rien et ne tourne que sous Windows. Alors que puisque je fais tout en HTML5, je n’en ai finalement pas besoin.

    – Faire tourner du HTML5 sans passer par le logiciel maison :
    https://docs.brightsign.biz/display/DOC/Displaying+HTML+without+BrightAuthor

    – Les options de configuration de l’objet HTML :
    https://docs.brightsign.biz/display/DOC/roHtmlWidget

    – Ma config :

    config = {
    url: "file:///mto/rubrique1.html",
    mouse_enabled: true,
    inspector_server: { port: 2999 },
    }

    Important : mouse_enabled indispensable pour que l’écran tactile (ou une souris) fonctionne (rhaaa, ils pouvaient pas le mettre directement dans leur unique exemple, c’est tout de même le b-a-ba…). L’« inspector » pour activer l’inspecteur Web de Chrome. (Note : j’ai la dernière version de Chrome sur mon Mac, et contrairement à ce que suggère la doc, je n’ai pas besoin d’installer une vieille version de Chromium pour que ma table soit reconnue.)

    En revanche, pour l’inspecteur sur mon Mac, il faut aller chercher l’URL :
    chrome ://inspect/devices#devices

    Pour l’accès à l’inspecteur, évidemment, il faut que le boîtier soit connecté au réseau. Pour ça il suffit de le brancher par Ethernet, ensuite ça se monte tout seul et il suffit de récupérer son IP (du genre 168.192.1.101) pour travailler.

    – Et enfin, taper l’IP du boîtier dans son navigateur local pour pouvoir gérer le truc par l’interface Web. Dans ce cas, l’identifiant c’est admin et le mot de passe c’est le numéro de série du boîtier.

    – Doc intéressante : faire passer la balise <video> sur le player natif du boîtier (dont c’est la spécialité). D’après la doc ça améliore la qualité. Difficulté : il faut jouer sur les « z-index » par une méthode native, parce qu’on n’est plus directement dans la gestion native du DOM HTML :
    https://docs.brightsign.biz/display/DOC/HTML+Video

    • Grosso modo ça fonctionne pas mal. Là où j’atteins les limites par contre, ce sont les panoramiques 360° affichés en WebGL : j’ai des alertes mémoires, et du coup des bugs d’affichage (graves, genre l’app n’est plus présentable au public).

      Et impossible de trouver la mémoire de ces machines (Brightsign). En faisant

      performance.memory.jsHeapSizeLimit

      dans la console de Chromium, j’obtiens :
      521000000

      ce qui me laisse supposer que je dispose de 500Mo, mais je n’en suis pas certain. En tout cas : je n’arrive pas à trouver la quantité de RAM dans les documentations en ligne.

  • Ré-évaluer l’approche responsive sur desktop
    http://www.24joursdeweb.fr/2012/re-evaluer-approche-responsive-sur-desktop

    On lit beaucoup (trop) d’articles et de commentaires sur les blogs qui chantent les louanges du responsive web design à chaque occasion d’aborder le sujet de la stratégie mobile. Il plane même une chape de dédain envers ceux qui n’ont pas « responsifié » leur site web. Cette attitude immature est profondément désolante …

    Source : 24 jours de web : Le calendrier de l’avent des gens qui font le web d’après.

    #reponsive_design #web #mobile #devices

  • There’s no such thing as Android, only Android-compatible
    http://arstechnica.com/gadgets/news/2011/12/theres-no-such-thing-as-android-only-android-compatible.ars

    Right at this moment, we have brand-new, state-of-the-art, highly evolved mobile and portable devices in a range of form factors that are based on at least three different major releases of #Android. Support for updating existing #devices to the newest version of Android is all over the map, even for devices made by the same manufacturer, like Samsung’s Galaxy series of smartphones and tablets.

    Tablets with fully skinned, proprietary operating systems like Amazon’s Kindle Fire or Barnes & Noble’s Nook Color/Nook Tablet only amplify the diversity that was already present in the smartphone market.

    ZDNet’s Ed Bott argues that for manufacturers and carriers, supporting indefinite at-will updates to the latest version of Android just doesn’t make economic sense:

    The problem with Android is all that #freedom, which allows hardware makers to take the OS and do whatever they want with it. It is inevitable that that freedom will produce a plethora of devices. Some of them will be incapable of running a new Android update. In other cases that #upgrade will require significant engineering investments—time and money—on the part of the handset maker and the carrier. They might decide to spend the money and deliver the update, six months later. Or they might decide that the investment isn’t worth it.