• 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.

    #epub #ebook #magazines #presse #mobile

    • tout comme on lit un bouquin avec un seul mouvement (tourner les pages), il propose de faire un bouquin avec un seul mouvement (scroll) ; comme ça pas besoin de mode d’emploi, on lit et c’est tout : l’interface ne vient pas se mettre en travers, elle se fait oublier

    • 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é.

    • 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…).

    • tu peux peut-être scroller par unités discrètes et non pas continues, ou alors rythmer le contenu avec des bidules (intertitres par exemple)

    • 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é.

    • l’article contient une sorte de réponse (insuffisante) à ta critique en disant qu’il leur suggère de mettre les articles en question en accès libre sur leur site, & que ça n’aurait pas nécessairement d’impact négatif sur leur business model

    • @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.

    • par exemple dans un moteur de recherche, plutôt qu’une pagination sur 1000 résultats, je préfère donner les 50 meilleurs et des suggestions pour « affiner la recherche », lesquelles iront chercher éventuellement d’autres résultats

    • 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.

    • @Fil : oui, carrément. En pratique, on sait bien que seuls servent les 10 ou 20 premiers résultats. Inutile donc d’en servir plus par defaut, mais pourquoi pas à la demande.

      @Baroug : oui pour réfléchir à une « meilleure interface et l’accès préservé à tout le contenu » pour chaque cas :)

    • @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.

    • 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.