Safari va finalement adopter les Service Workers
Les développeurs web du monde entier sont en liesse depuis hier. Apple a officiellement commencé le travail pour prendre en charge les Service Workers dans Webkit, et donc dans Safari.
Les Service Workers permettent aux sites web d’exécuter du code en JavaScript même s’ils ne sont pas au premier plan, voire si aucune page n’est actuellement ouverte dans le navigateur. Cette fonction est l’équivalent des mises à jour à l’arrière-plan des apps natives, mais appliqué au web. L’exécution est interrompue quand une tâche est terminée, mais elle peut ensuite se relancer si c’est nécessaire.
Cette fonction peut servir à mettre à jour régulièrement les données d’un site et ainsi afficher directement les données à jour quand l’utilisateur l’affiche. Les Service Workers peuvent aussi servir pendant le développement, par exemple pour compiler des ressources et convertir des fichiers. Ou bien aussi améliorer les performances en chargeant à l’avance non seulement des ressources statiques, mais aussi des pages complètes.
En bref, les Service Workers rapprochent le web des apps natives. Jusque-là, Apple ne semblait pas intéressée par cette fonction, ce qui lui a valu bien des critiques ces dernières années de la part de la communauté des développeurs web (lire : Safari est-il le nouvel Internet Explorer ?). Son arrivée est une bonne nouvelle pour les webapps les plus complexes, même si le navigateur de macOS et iOS reste toujours à la traîne dans le domaine.
Dernier exemple en date, les Progressive Web Apps poussées par Google ne sont pas encore prises en charge. Par rapport aux webapps traditionnelles, elles permettent notamment de stocker l’interface d’un site et des données en local. Les PWA peuvent ainsi fonctionner même sans connexion à internet, comme une vraie app native… en tout cas sur Android, plate-forme logiquement la plus avancée sur ce point.
Apple privilégie comme toujours l’App Store, mais cela ne veut pas dire que Safari est à l’abandon. Bien au contraire, son navigateur évolue régulièrement et encore cette année, mais le constructeur privilégie souvent les fonctions dédiées aux utilisateurs, plutôt que celles qui arrangent les développeurs.
un utilisateur macOS qui croit encore qu'en fermant la dernière fenêtre l'application s'arrête forcément à gravement besoin d'une remise en cause de ses connaissances.
la barre de menu partagée n'a effectivement pas que des avantages, c'est un choix ergonomique qui me semble dépassé, mais bon, les conservatismes font que ses inconvénients, ici l'absence visuelle (hors Dock) d'une fenêtre d'une application en tâche de fond n'aide pas à voir qu'elle tourne pourtant toujours, sont toujours tolérés.
@byte_order
"un utilisateur macOS qui croit encore qu'en fermant la dernière fenêtre l'application s'arrête forcément à gravement besoin d'une remise en cause de ses connaissances."
Pense un peu aux switchers qui ont acquis des réflexes pendant des années sur Windows. Moi même quand j'y retourne je rage parce que la petite croix ferme l'application au lieu de fermer juste la fenêtre comme sur Mac. Et pourtant j'ai été utilisateur exclusif de Windows pendant 15 ans et utilisateur de macOS pendant 9 ans.
"la barre de menu partagée n'a effectivement pas que des avantages"
Quel rapport avec la barre de menu partagée ? C'est le dock qui t'indique quelles applications sont ouvertes, pas le barre de menu. Le menu indique l'application active et ça reste bien plus clair à comprendre que le changement de couleur ou d'opacité de la fenêtre...
"c'est un choix ergonomique qui me semble dépassé, mais bon, les conservatismes font que ses inconvénients"
Sur un écran 16/9 c'est l'inverse qui me semble dépassé. Je n'arrive pas à comprendre qu'on puisse encore privilégier ces épaisses barre d'outils (le bandeau dans MS Office ou AutoCAD PC est une totale hérésie sur un écran de ce format)
" ici l'absence visuelle (hors Dock) d'une fenêtre d'une application en tâche de fond n'aide pas à voir qu'elle tourne pourtant toujours, sont toujours tolérés."
Je connais rien de plus efficace que le dock de macOS pour savoir quelle app continue de tourner. Soit tu utilises l'indicateur (sous l'icône, on peut pas plus limpide) soit tu utilises le dock comme une barre de tâches (en supprimant les raccourcis des apps qui ne tournent pas) et tu utilises le LaunchPad comme lanceur.
> Quel rapport avec la barre de menu partagée ?
> C'est le dock qui t'indique quelles applications sont ouvertes, pas le barre de menu
Pas juste après avoir fermé la dernière fenêtre d'une application.
A ce moment là il y a 2 zones à l'écran qui indique que l'application tourne encore :
1) l'indicateur dans le Dock, habituellement tout en bas de l'écran, et si c'est l'une des applications mise en raccourçi dedans, l'indicateur est très (trop, selon moi) discret.
2) la barre de menu de l'application désormais sans fenêtre, qui est elle à l'exact opposée, tout en haut.
Hors cette dernière occupe un espace nettement plus grand (et donc repérable) que l’indicateur d'applications ouvertes dans le Dock. Mais est très inefficace pour que l'utilisateur non averti remarque que la fermeture de la dernière fenêtre n'a pas clos l'application dans la foulée, qui tourne donc encore.
Par ailleurs :
> Le menu indique l'application active
Non. Dans un OS multitâche préemptif, toutes les applications sont "actives" en même temps. Il ne s'agit pas d'activité, mais de focus clavier : quelle application est celle qui recevra les raccourcis claviers, en gros.
Parce que pour le reste, la position de la souris (ou autre périphérique de pointage) désigne nettement plus clairement sur quel élément visuel l'utilisateur veut intervenir, ce qui donnera le focus à l'application concernée automatiquement, l'utilisateur ayant franchement autre chose à faire que de micromanager quelle application doit réagir à ces sollicitations.
> et ça reste bien plus clair à comprendre que le changement de couleur
> ou d'opacité de la fenêtre..
Les gouts et les couleurs. Le focus automatique et le cloisonnement visuel clair me semble moi nettement plus intuitif, la preuve étant qu'il arrive rarement d'etre surpris que tel raccourçi clavier a été pris en compte par une autre application que celle qu'on attendait sous les OS ayant intégrés le menu dans les fenêtres, alors que je vois régulièrement ce cas sous macOS, moi inclus (bon, après, je zappe régulièrement de plateforme, cela aide pas peut-être).
Sans parler des modes side-to-side de 2 applications distinctives... Pourquoi pensez-vous que le mode SplitView ne fonctionne qu'avec des applications en mode full screen ? L'usage d'une barre de menu partagée est agronomiquement impossible dans ce cas...
Enfin, la barre de menu tend a être un élement ergonomique qui disparait de plus en plus, remplacer par des commandes plus claires intégrées dans l'interface de la fenêtre, menu contextuel ou gesture.
Le tactile est passé par là, et la barre de menu est probablement l'un des éléments du fameux WIMP qui résiste le moins bien au passage au tactile...
> Je n'arrive pas à comprendre qu'on puisse encore privilégier ces épaisses barre
> d'outils (le bandeau dans MS Office ou AutoCAD PC est une totale hérésie sur
> un écran de ce format)
Ils se replient automatiquement ces bandeaux, mais oui, le format 16/9 rend plus pratique des menus coulissant latéralement plutot que des bandeaux horizontaux.
Une grosse part de leur présence persistente est probablement plus lié à l'inertie pour faire changer d'habitude les uitlisateurs en entreprise (et les couts engendrés) qu'autres choses.
@ byte_order : « un utilisateur macOS qui croit encore qu'en fermant la dernière fenêtre l'application s'arrête forcément à gravement besoin d'une remise en cause de ses connaissances. »
Des utilisateurs qui ont besoin d'une remise en cause de leurs connaissances, on en trouve à la pelle, sur toutes les plateformes. Y compris sur Mac OS, où on trouve pas mal d'utilisateurs arrivés d'autres plateformes et convaincus que leur Mac s'utilise exactement comme Windows.
« la barre de menu partagée n'a effectivement pas que des avantages, c'est un choix ergonomique qui me semble dépassé, mais bon, les conservatismes font que ses inconvénients, ici l'absence visuelle (hors Dock) d'une fenêtre d'une application en tâche de fond n'aide pas à voir qu'elle tourne pourtant toujours, sont toujours tolérés. »
Évidemment que c'est « toléré », vu l'avantage que ça procure en contrepartie ! (Le lecteur comprendra sûrement, en voyant cette remarque, que je ne trouve pas du tout cette barre de menus dépassée. ;-) 0
Notons au passage qu'il n'y a pas que le Dock qui permet de voir qu'une application tourne toujours : si l'application est active au moment où l'on ferme sa dernière fenêtre, on peut aussi s'en rendre compte en regardant tout bêtement la barre de menus, qui affiche toujours le nom de l'application.
Mais, comme dit plus haut, certains utilisateurs ne prêtent attention à rien de tout ça (et ne savent même pas forcément ce que signifie quitter une application).
@ byte_order : « J'adore le "sur mac".
Comme si sous Windows ou Linux ou BSD ou tout autres OS multitâches préemtif les applications ne continuaient pas de s'exécuter tant que :
1) l'utilisateur ne les arrête explicitement
2) l'utilisateur arrête l'ordinateur. »
Notons qu'il n'y a pas de lien direct avec le multitâche préemptif. ;-)
Avec un multitâche coopératif comme dans le Système 7, une application continue aussi de s'exécuter si on ne la quitte pas. Certes, elle peut être interrompue plus longtemps si une application au premier plan traîne à rendre la main (voire être interrompue indéfiniment, mais là on rejoint vite le cas où l'utilisateur arrête l'ordinateur), mais c'est tout.
Mais bon, ce à quoi fousfous faisait référence, c'est le fait qu'avec Mac OS, contrairement aux interfaces graphiques pleinement orientées fenêtres (Windows, notamment), fermer toutes les fenêtres d'une application n'est pas forcément synonyme de quitter cette application, ce qui peut mener des utilisateurs distraits à laisser Safari tourner en permanence.
Okay, va pour le préemptif de trop. Mais multitâche, assurément.
Et concernant les applications en tâche de fond qui deviennent invisibles sans fenêtre à cause de la barre de menu partagée, c'est une conséquence de choix d'Apple et des développeurs de Safari.
On va quand même pas supprimer toutes les techos web qui permettent de faire des trucs en tâches de fond à cause de ça. A Apple d'éventuellement revoir sa position sur l'intérêt de maintenir Safari ouvert quand on ferme la dernière fenêtre...
@ byte_order : « Okay, va pour le préemptif de trop. Mais multitâche, assurément. »
Ben en fait… :-)
Ta remarque sur les applications qui ne s'arrêtent pas tant que l'utilisateur ne les quitte pas ou n'éteint pas la machine s'applique tout aussi bien à un système monotâche tel qu'un Mac OS pre-MultiFinder (et sans Switcher). ;-)
Certes, mais aucune n'est alors en arrière plan - vu qu'il n'y a pas d'arrière plan, et donc c'est difficile pour l'utilisateur de l'oublier vu qu'elle est en permanence sur le le seul et unique plan : l'application en cours.
Ça va être trop bien pour les hackers (XSRF par exemple) ou pour les tracker!
Mais pour nous, pauvres utilisateurs, où est l'intérêt?
Aucun.
C'est une api web. clairement cela n'intéresse que les développeurs.
En fonction de ce qu'ils en ferront, soit cela sera également globalement bénéfique pour les utilisateurs, ou pas.
Mais pour ça faut-il encore que les utilisateurs soient capable de savoir quand cette api est employée dans leur quotidien. Ce qui ne sera jamais le cas, en pratique.
Donc, les utilisateurs, eux, ignoreront que c'est grace ou à cause des services workers dans Safari qu'ils ont tel fonctionnalité ou tel désagrément désormais.
Il n'y à qu'à faire un safari store qui liste les applis/sites installés, les droits accordés (micro/vidéo/géolocalisation/notifications/service worker...) et l'espace disque consommé
Pages