Staring down colliders — Craig Mod
▻https://medium.com/message/8690cba05e58
It’s hard to visit CERN and not be roused. Hard to not have your brain peeled back and eyes flung open. Their scientific oeuvre is built upon a litany of superlatives: fastest, biggest, longest, coldest, heaviest. The whole production composed of equal parts polish, performance art, brute force, genius, and sheer miracle.
Singularities | STET
▻http://stet.editorially.com/articles/singularities
Writer, designer, and publisher Craig Mod pairs a travelogue with a product story in this piece about Hi, a new tool for storytelling.
Du livre au web : de l’édition électronique à la « web édition »
▻http://lafeuille.blog.lemonde.fr/2013/07/26/du-livre-au-web-de-ledition-electronique-a-la-web-edition/#xtor=RSS-32280322
Voilà longtemps que le développeur et designer Craig Mod réfléchit au basculement de l’édition à l’édition web. Dans un essai publié en 2010, Les livres à l’âge de l’iPad, il expliquait déjà que “Dans les livres imprimés, la propagation de la double page du livre a été notre toile. Il est facile de penser de même à propos de l’iPad. Il ne faut pas. La toile de l’iPad doit être considérée d’une manière qui reconnaisse les limites physiques de l’appareil, tout en embrassant l’illimité efficacité d…
À priori assez évident, mais très intéressant. À lire !
#Twitter for minimalists — Craig Mod
▻http://craigmod.com/satellite/twitter_for_minimalists
For years, my go-to solution for daily-use web applications has been Fluid. I have #Fluid instances of #gmail, Google Calendar, Workflowy and a host of other web-only applications.
et bientôt une #seenthis_app sur le même modèle ?
Subcompact Publishing — by Craig Mod
►http://craigmod.com/journal/subcompact_publishing
encore une fois une excellente analyse de #design de Craig Mod ; il évoque cette fois “The Magazine”, un… magazine… publié sur l’iPad avec une idée simple : faire simple, compact. Une capsule de lecture. (►http://the-magazine.org)
A Subcompact Manifesto
Subcompact Publishing tools are first and foremost straightforward.
They require few to no instructions.
They are easily understood on first blush.
The editorial and design decisions around them react to digital as a distribution and consumption space.
They are the result of dumping our publishing related technology on a table and asking ourselves — what are the core tools we can build with all this stuff?
(...) qualities:
Small issue sizes (3-7 articles / issue)
Small file sizes
Digital-aware subscription prices
Fluid publishing schedule
Scroll (don’t paginate)
Clear navigation
HTML(ish) based
Touching the open web
Many of these qualities play off one another.
Oui, très intéressant ! Depuis le temps que je dis qu’il faut abolir la pagination :)
Qu’est-ce que ça veut dire « abolir la pagination » ?
The Manual fait déjà ça, un peu.
►http://www.alwaysreadthemanual.com
Addendum du gars qui lit en diagonale : ils le font sous forme papier mais sur le principe (compacité, thématique) c’est pas loin.
l’interface ne vient pas se mettre en travers, elle se fait oublier
Autrement dit, la pagination n’est pas abolie, elle est juste réinventée.
Ah oui, pardon, « aboli » était un peu fort : la pagination, telle qu’elle est pratiquée (une liste de numéros de page, à zone cliquable généralement trop minuscule pour être aisément utilisés) est rarement pertinente. Pourquoi fractionner ? Pourquoi cacher le contenu dans d’autres pages ? Pourquoi ne pas lister in extenso ? Pourquoi ne pas mieux catégoriser l’info, pour éviter les listes à rallonge ?
C’est pertinent sur une liste de résultats de recherche… encore que… ça peut être discuté.
C’est pertinent pour la publicité, ça fait plus d’affichage différent. Cela dit, ceux qui vivent de ça pourraient innover en imaginant de la publicité tout le long du scroll. :)
Il me semble que l’absence ponctuelle de limites est un problème : souvent on « finit sa page », ou on « lit encore 10 pages » non pas parce que c’est une unité pertinente mais parce que c’est une unité matérielle ; or s’il n’y en a plus, il me semble que ça manquera (mais on peut probablement trouver autre chose…).
Les unités à recréer oui ; les intertitres c’est bien mais différent dans chaque truc or il faudrait une ou des normes.
Son exposé sur les problématiques d’interface et d’expérience utilisateur est plus que brillant : qu’est que sont la lecture numérique (contextes, usages), l’édition numérique, les rapports contenus / périphériques de lecture / dispositifs de navigation. C’est un manifeste.
Ce qui me « dérange » le plus dans cet excellent article (enfin surtout dans le produit étudié ) : le fait d’être (encore) attaché à un écosystème lié à un fabricant (Apple, ici, via « Newsstand », qui permet le téléchargement de contenu en arrière plan et le paiement en ligne via Apple ).
Pourtant, « Newsstand » est complètement nécessaire :
RSS may be fine for a backend protocol and packet structure, but from a ‘normal’ consumer facing point of view, RSS has never made sense. (It’s sort of like git without github.) In effect, creating a better kind of consumer facing RSS is to solve the above problem.
« Newsstand » et l’écosystème Apple permettent aussi le paiement (imaginez entrer votre num de CB à chaque fois que vous voulez une édition de votre magazine).
Le téléchargement en arrière plan et le paiement fluide sont nécessaires pour que « ça marche ».
Ok, ►http://the-magazine.org peut toujours développer une version Android de leur truc, et une version Kindle, et une version... etc...
Pour caricaturer : dans le futur, si tu voudras lire du contenu de qualité, tu aura intérêt à avoir acheté le bon périphérique, le bon téléphone, la bonne tablette. Celle des riches, pas des pauvres. C’est quand même dingue cette intégration verticale totale : matériel - logiciel - écosystème - contenu.
Dans une optique de préservation du contenu de qualité (et donc payer de bons journalistes, essayistes, écrivains, illustrateurs, photographes), se rapprocher du public cible est très bien, compter sur beaucoup de micro-paiements plutôt que sur un ticket d’entrée cher, aussi.
Au delà des problématiques de liberté de l’utilisateur et du contenu, ce modèle ne marchera pas (les auteurs ne pourront pas manger à leur faim) si justement les contenus restent liés à une plate-forme matérielle. Seuls les gros groupes medias pourront faire du multi-canal ; et on sait que ce n’est pas là où l’on trouve le plus de contenu de qualité.
@tetue :
Pourquoi fractionner ? Pourquoi ne pas lister in extenso ?
Pour un contenu de type ’article’, j’ai jamais apprécié le découpage en page d’un article sur le web : J’ai compris pourquoi j’aimais pas quand Anne-Sophie Fradier a fait l’analogie qui me manquait lors de sa conférence « La macrotypographie de la page Web » (<►http://www.dailymotion.com/video/xfpf08_la-macrotypographie-de-la-page-web-anne-sophie-fradier_tech>) à Pariweb en 2010 : Le #Volumen vs le #Codex...
Quand il s’agit de listes, on fractionne le plus souvent pour des questions de performances. Derrière l’affichage d’une liste d’items, il y a généralement un accès à une base de données : Lister in extenso, c’est remonter un nombre qui peut être très volumineux d’entrées. une liste de 2000 items, associés chacun à une photo, ça peut être très lourd, par exemple. Je ne vois que cet argument en plus de l’atavisme ("On a toujours fait comme ça, les utilisateurs ne s’en plaignent pas") Cependant, j’ai rien contre le fait que des gens cherchent à améliorer l’interface, du moment que ça reste accessible... :)
@baroug Pour le scroll par unités discrètes, on peut penser à des choses comme sausage.js (il y en a d’autres du même genre) : ►http://christophercliff.com/sausage/examples/couchdb.html ou ►http://christophercliff.com/sausage/examples/basic.html (scroll infini). Le mieux serait d’arriver à se brancher (et d’augmenter) sur le composant natif d’interface de « scroll » du périphérique (pas possible pour l’instant).
@tetue & @james : J’adore la pagination, surtout quand « le client » exige ensuite une possibilité de tri sur le contenu paginé... :)
@james : quand tu dis
du moment que ça reste accessible
c’est « accessibilité » au sens « a11y » ? Tu penses aux soucis d’accessibilité du « lazy loading » (scroll infini) ?
@fil : Oui, mais si j’ai envie de payer :) ? Et financer une publication sur les utilisateurs d’une certaine marque de périphériques, ça me semble un peu bancal et court-termiste. Désolé pour la tirade plus haut, d’autres l’ont déjà dit, et mieux.
@james : oui :) mais… pourquoi remonter une liste de « 2000 items » ? c’est pas humain !
Si, au lieu de l’en extraire brut, on organise (en catégorisant) le contenu de la base de données pour le présenter à des internautes (dans un site avec des rubriques), la pagination est souvent inutile, voire dommageable (combien de fois on ne percute pas qu’il y avait une seconde page, loupant du contenu ? pourquoi ne pas tout présenter à l’écran au lieu de cacher les choses et faire chercher l’internaute ?).
La pagination répond à un besoin spécifique (nombreux résultats de recherche, flux des tweets, etc.). Encore que, ça s’interface mieux autrement, par exemple en scroll infini, mais à la demande (commandé volontairement par l’utilisateur via clic), surtout automatique.
Ouais, mais dans le cas de grosses bases de données, tu peux jamais être sur, en dépit de la meilleure organisation du monde, et des critères les plus pertinents, que ce que cherche l’internaute n’est pas le 2000e résultat ; auquel cas le scroll infini serait atroce et un choix limité… limité. Il faut une solution qui permette simultanément une meilleure interface et l’accès préservé à tout le contenu.
Euh ben c’est un peu le principe d’une pagination dans des résultats quoi : on en sert que 20 par défaut, et si on en veut plus on affiche la page suivante.
@tetue :
pourquoi remonter une liste de « 2000 items » ? c’est pas humain !
La catégorisation dont tu parles n’est pas toujours faite ni souhaitée par le lecteur. Ce serait un peu rapide de dire que « tout dépend de l’usage », mais j’ai pas mieux pour le moment. De plus, quand elle est faite, c’est à un instant donné et si le site est vivant, la volumétrie des contenus croît et la taille des listes catégorisées augmente. On peut se retrouver avec le même problème et sans avoir prévu de système de pagination : CQFD.
D’où le besoin de paginer :)
L’alternative serait de réviser la catégorisation en permanence, en fonction des volumes et des besoins des lecteurs : ça nécessite la mise en place d’un algorithme sémantique assez costaud, mais il faudrait peut-être disposer des moyens de google pour cela, ou bien d’avoir un documentaliste à disposition pour faire ce travail. Et là, « tout dépend des ressources dont on dispose »... :p
Peu importe comment c’est présenté à l’écran (série de liens visibles, dynamisme de la page, ajax, « scrolling machin », tout ce qu’on peut imaginer est bon à prendre) et quel moyen on offre au lecteur pour éventuellement voir la suite du moment que c’est prévu et utilisable.
Ma conclusion, c’est que le mécanisme de pagination reste essentiel mais que c’est très intéressant de chercher à en réinventer l’interface.
@0gust1 : par accessible, j’entends simplement que le contenu d’un document doit être accompagné d’un moyen d’accéder au reste de l’information si elle n’est que partiellement affichée. Je n’y connais rien en terminologie (et ça ne m’intéresse pas trop d’entrer dans une discussion jargonneuse). Ce moyen d’accès peut être multiple et de n’importe quel type, comme dit plus haut.
Deux compléments intéressants :
discussion autour de l’article
►http://branch.com/b/thoughts-on-craig-mod-s-subcompact-publishing
estimation des coûts et revenus de “The Magazine”
►http://pandodaily.com/2012/11/07/marco-arment-makes-zines-cool-again-and-potentially-profitable
voir aussi l’initiative ►http://theperiodical.co évoquée dans ►http://seenthis.net/messages/101960
et Craig Mod rassemble les commentaires dans un nouveau petit article où il explique aussi la chute de « The Daily », qui avait pour « modèle » de faire gros pour peu de monde
►http://craigmod.com/satellite/subcompact_round_up
même commentaire sur “The Daily” chez Benoît Raphael
Les vraies raisons de la mort de "The Daily" - La social NewsRoom
►http://www.benoitraphael.com/les-vraies-raisons-de-la-mort-de-the-daily
la plus grosse erreur de The Daily, ce n’est pas tant sa publication sur iPad que son budget. C’est d’ailleurs le principal handicap des publications à l’ancienne qui peinent à trouver un modèle sur le digital : leur structure de coûts, c’est à dire leur organisation et leurs process, ne sont pas adaptés à ce nouvel écosystème.
Publishing startups and the great fuzziness — Craig Mod
►http://craigmod.com/satellite/publishing_startups
Craig Mod s’emballe pour une startup qui fait de la #publication_électronique… exclusivement sur #Facebook. Et qui maintenant qu’elle a 4 millions de « fans », se décide à faire un #site. Quel est le bon ordre à suivre ?
Platforming #Books — by Craig Mod
►http://craigmod.com/journal/platforming_books
The future of books is built upon networked platforms, not islands. More than any surface advancement — interface, navigational, typographic, or similar — platforms define how we read going forward. Platforms shape systems — those of production, consumption, distribution — and all critical changes happening in digital books and publishing happen within systems. Post-artifact books and publishing2 is not just about text on screens.
digital books benefit from public endpoints [websites]. [Readers] have formed expectations about sharing text, and if you obstruct their ability to share — to touch — digital text, then your content is as good as non-existent. (...)
we will sell more digital and physical copies by having all of the content available online
#epub
Hack the Cover — by Craig Mod
►http://craigmod.com/journal/hack_the_cover
Hack the Cover — by Craig Mod
►http://craigmod.com/journal/hack_the_cover
Post-Artifact Booking
►http://www.kk.org/thetechnium/archives/2011/06/post-artifact_b.php
bonne réflexion sur les #ebooks ; ce ne doit pas juste être un livre numérisé, mais un processus différent
Imagine a future where instead of lending someone a book, you lend them your bookmarks. Where your notes, annotations and references are synchronized across platforms and applications. Where your bookmarks belong to you, and a record of every book you read is saved and stored securely, no matter how or where you read it.
l’essai d’origine ►http://craigmod.com/journal/post_artifact est signé Craig Mod, auteur également de #bibliotype et de #flipboard ; il a publié récemment un magnifique livre sur le #Japon, financé par #crowdsourcing via kickstarter, et le raconte ici ►http://craigmod.com/journal/kickstartup (son site est vraiment très réussi : joli, varié, agréable à lire : #design )
Bibliotype pour Spip
►http://www.spip-contrib.net/Bibliotype
Bibliotype est un gabarit de document optimisé pour la lecture sur un écran de type tablette (comme l’iPad d’Apple).
Proposé par Craig Mod sur le site A List Apart (lire l’article), il est ici porté sous SPIP pour permettre la production rapide de livres numériques. Charge à chacun de l’adapter pour passer du prototype au produit fini.
The potential of web typography
►http://hacks.mozilla.org/2009/06/web-typography
Ian Lynam and Craig Mod have put together a page that is an excellent example of typography in action, but also offer some suggestions on what the next steps for typography on the web might look like. The page itself takes advantage of a number of typefaces that Craig and Ian got permission to use and uses a pleasing multi-column layout. Please click through to the complete article to get the full effect.