Ce qu'il s'est passé grâce aux standards du web, c'est que pour chaque segment de la population qui a des besoins similaires, il y a au moins une application qui fait les 10% dont elle a besoin et dont elle le fait bien.
Erreur numéro un:
La "population" n'est pas juste un ensemble de cas utilisateurs bien séparés. Chaque utilisateur a un ou plus cas d'utilisation.
Ce n'est pas parce que tu tiens un petit blog que tu n'écris pas de roman, ou ne rédige pas de rapports volumineux avec pleins de figures.
Du coup, les 10% même ne sont pas clairement défini par utilisateur, mais par cas d'utilisation.
Erreur numéro deux:
Personne n'aime apprendre N outils pour faire N choses à part les geeks purs et durs. La majorité de la population veut juste pouvoir produire quand elle a besoin de produire. Dès lors, une standardisation de l'outil de production est vu comme une bonne chose. Du coup, on se rapprocherait plus d'un cœur commun à toutes les applis, puis des modules qui viendraient s'y attacher pour atteindre les fonctionnalités nécessaires.
La logique des applis web actuelles ne respecte aucune norme ni aucun standard.
Ah, et c'est sans compter la visibilité de tout ce fatras: tu as sorti des noms d'applis que je ne connais même pas ou seulement très vaguement!
Pour certains qui viennent de Word, Google docs fera l'affaire ; pour ceux qui lancent leur petit blog, ce sera wordpress ; pour d'autres qui ont des besoins plus évolués, on peut penser à Drupal ; pour les écrivains un truc comme ByWord ; pour ceux qui veulent mettre leurs idées en place, un truc comme Gingko ; pour moi qui rédige ce commentaire en markdown ce sera stackedit
Erreur numéro trois:
Aucune entreprise un peu sérieuse n'acceptera jamais de maintenir 32 outils là où une seule suite bureautique, si lourde soit-elle, pourra convenir à tout le monde en même temps.
Et que ferons donc ces utilisateurs en rentrant chez eux? Apprendre un logiciel qui leur permettra de faire une toute petite partie de ce qu'ils veulent faire (mais "bien"), ou dégainer la suite qu'ils connaissent déjà et maîtrisent avec la pratique au boulot, même si c'est un bazooka pour abattre une mouche?
et enfin ceux qui ont des besoins très avancés se feront leur propre application en Ruby on Rails.
Erreur numéro quatre:
Supposer que n'importe quel lambda va apprendre à programmer, qui plus est en RoR, alors que son but est de produire du contenu.
Là on nage en plein délire geekesque!
Commence par m'enlever moi de la liste. Si j'ai des besoins avancés, je prends un outil avancé, je ne reprogramme certainement pas une suite bureautique en RoR, même si c'est seulement 10% de la suite!
[^] # Re: Bof
Posté par Maclag . En réponse au journal Microsoft libère son SDK pour OOXML. Évalué à 5.
Erreur numéro un:
La "population" n'est pas juste un ensemble de cas utilisateurs bien séparés. Chaque utilisateur a un ou plus cas d'utilisation.
Ce n'est pas parce que tu tiens un petit blog que tu n'écris pas de roman, ou ne rédige pas de rapports volumineux avec pleins de figures.
Du coup, les 10% même ne sont pas clairement défini par utilisateur, mais par cas d'utilisation.
Erreur numéro deux:
Personne n'aime apprendre N outils pour faire N choses à part les geeks purs et durs. La majorité de la population veut juste pouvoir produire quand elle a besoin de produire. Dès lors, une standardisation de l'outil de production est vu comme une bonne chose. Du coup, on se rapprocherait plus d'un cœur commun à toutes les applis, puis des modules qui viendraient s'y attacher pour atteindre les fonctionnalités nécessaires.
La logique des applis web actuelles ne respecte aucune norme ni aucun standard.
Ah, et c'est sans compter la visibilité de tout ce fatras: tu as sorti des noms d'applis que je ne connais même pas ou seulement très vaguement!
Erreur numéro trois:
Aucune entreprise un peu sérieuse n'acceptera jamais de maintenir 32 outils là où une seule suite bureautique, si lourde soit-elle, pourra convenir à tout le monde en même temps.
Et que ferons donc ces utilisateurs en rentrant chez eux? Apprendre un logiciel qui leur permettra de faire une toute petite partie de ce qu'ils veulent faire (mais "bien"), ou dégainer la suite qu'ils connaissent déjà et maîtrisent avec la pratique au boulot, même si c'est un bazooka pour abattre une mouche?
Erreur numéro quatre:
Supposer que n'importe quel lambda va apprendre à programmer, qui plus est en RoR, alors que son but est de produire du contenu.
Là on nage en plein délire geekesque!
Commence par m'enlever moi de la liste. Si j'ai des besoins avancés, je prends un outil avancé, je ne reprogramme certainement pas une suite bureautique en RoR, même si c'est seulement 10% de la suite!