Concrètement, la résolution de cette problématique à précédé pour nous les applicatifs: nous avons passé des mois à conceptualiser le modèle des données avant d’avoir la moindre interface (c’était en… 2003!). Et la gageure était de concillier le (ultra)générique et le spécifique.

La réponse à été la suivante: des objets “verticaux” natifs (le spécifique) et dérivés (le générique) ayant chacun des propriétés intrinsèques, et des macro-propriété horizontale pour lier le tout. La combinaison de ces trois vecteurs offre des possibilités énormes de telle manière qu’il suffi parfois de simplement configurer pour créer la fonctionnalité.

Le Framework Sushee est la résultante de ce travail, et Officity une partie visible de l’Iceberg.

Il ne suffi donc pas de saupoudrer de sucre, il faut offrir le cadre du saupoudrage, à savoir une bonne gaufre de liège bien structurée

Le marketer (mercaticien.. arf) trouvera dans tout cette abondance entre les différents applis une confusion peu propice à la lisibilté des offres.

Qui l’emporte? Ou sinon, comment concilier les deux: multiplicité ET génération de lisibilté pour les prospects?

Je ne pense pas que l’humain cantonné dans son rôle d’utilisateur soit plus déterminant que le processus général dans lequel il se place (qui est aussi un autre rôle) ou l’activité qu’il génère.

Un exemple classique: Photoshop. Pour certain un monstre de complexité inaccessible, pour d’autres un bête marteau avec lequel ils font strictement se qu’ils veulent. Le besoin créé la fonction mais aussi l’utilisation: l’interface la plus simple du monde n’est pas un objectif en soi, mais produire la plus belle image à placer dans une affiche oui.

A l’opposé, les cours d’informatique les plus prisés ne sont pas sur la programmation orienté objet ou sur le design pattern, mais bien sur comment utiliser Outlook!

Et l’entre-deux, la masse la plus importante, fonctionne comme tout un chacun: par habitude. Et c’est normal et naturel, il ne faut pas aller contre cela. Et c’est un leurre de dire que les applications les plus utilisées sont les plus utilisables: j’ai testé des Facebook, Blogger, etc autres, et je devait chercher 5 minutes pour trouver chaque actions que je voulais réaliser…

Et c’est un soucis réel pour nous éditeurs: quelque chose n’est pas clair? ne fonctionne carrément pas? c’est normal, on fait avec (merci “fenêtres”…). Très peu d’utilisateurs nous contactent pour nous soumettre des choses peut claires, des bugs, etc.

A nos yeux, la compréhension du contexte est plus importante que l’application elle-même. Même si l’humain peut s’habituer à tout et n’importe quoi, sans compréhension il ne pourra pas dompter son environnement, il s’adaptera à lui. Et comme il y a des milliers de manière de faire les même choses, autant comprendre le fond, pour la forme, ça coulera!

Les standards sont là pour faciliter les choses et permettent enfin de pouvoir au mieux s’adapter aux besoins: une grosse application agrégative? plusieurs applications spécialisées? Une seule application développée sur mesure? Toutes ces options se valent, tout dépend du contexte. Et il est bien sûr possible d’arriver à du brol ! C’est pour cela que nous conseillons de préférence de développer sur base d’un Framework, et si cela ne se justifie pas d’un point de vue économique ou pratique d’agréger des applications spécialisées comme si il s’agissait de processeurs (entrée-sortie).

C’est ce qui commence à caractériser la situation actuelle.

Par ailleurs, tous ces standards portent sur la structuration des données en vues de leur échange… mais de nombreuses données n’ont pas forcément besoin d’être échangées.
Ils suffit parfois juste d’arriver à les “faire voir”. Par exemple un plan de chantier d’un architecte, lequel communiquerait à distance avec son client: un simple outil de déport d’écran est bien suffisant, pas besoinq ue le client possède la même appli que l’architecte, ni même la visionneuse associée à l’appli…
C’est la grande promesse des outils de desktop sharing.

Mais ils ne sont pas suffisants en eux-mêmes: il leur manque la dimension “groupware” (comme celle que vous offrez) et celle de la gestion “asynchrone”.

Alors quoi: aggréger tout cela dans une seule et même appli? Auquel cas al chance est aux solutions “mono-fonction” qui se laissent intégrer facilement?

Le problème me semble essentiellement humain, lié à l’usage, plus que techno. Votre point de vue d’éditeur m’intéresserait diablement sur ce point précis..

L’utilisation des différents applicatifs intégré n’est encore représentatif que de la version expert dont la solution est issue, à savoir pour 75% le quatuor Shaper (gestion de contenu) - Files (gestion des fichiers) - Spray (e-marketing) - Contacts.

Les nouvelles applications de bureau virtuel récemment lancées ont été adoptées rapidement par les petites structures pour les mails et l’agenda, mais je ne pense pas que nos autres clients plus important y passeront pour autant: leur besoin d’origine était des applications taylor-made, pas du bureau virtuel.

Je suis d’accord qu’il n’existe pas de killer-app’. Je dirais même plus qu’il ne peut en exister: à chaque métier ses besoins! C’est bien pourquoi nous avons articulé Officity avec Sushee, pour avoir cette ouverture qui permet de créer les applications par besoin (bon, cela demande une intervention d’un développeur bien sûr, mais comme Sushee est en GPL (http://sourceforge.net/projects/sushee/), nous espérons que des applicatifs puissent être mis à disposition de la communauté). Pour info, il y a déjà des agences qui développent leur propre appli sur base de Sushee sans passer par Officity, donc en restant à 100% dans le modèle opensource.

Sinon, pour ce qui est des standards, cela ne nous inqiuète vraiment pas… l’xml est en soit un standard suffisemment universel et complètement inter-opérable grâce à l’xsl. Nous avons inclus l’xliff (standard oasis pour traducteur) car c’est très proche de la problématique de gestion de contenu, mais pour le reste, des feuilles de styles xsl de convertion sont amplement suffisantes pour réconcilier les formats (merci Mic…oft de nous avoir imposé un deuxième format xml de bureautique… cela aurait été trop simple avec un seul dont toutes la communauté informatique était déjà satisfaite ).

Le problème du “collaboratif” c’est qu’il n’existe pas de killer-app’, qui permette d’englober la totalité du marché. Et qu’il ne peut en exister, à moins que plus aucune nouveauté ne sorte…
Le développement de standards (XMPP, etc.) n’en sont encore qu’au bablbutiements.. et rien ne dit que tous els éditeurs produiront du XML “standard”..

Donc la segmentation ne peut se faire que par usage, comme vous le décrivez très bien.

Il faut bien se placer dans le contexte des besoins de tout un chacun: l’avantage d’un bureau virtuel comme celui n’a de sens que par la centralisation naturelle des données, l’architecture des données (il n’y a pas d’architecure logique des données dans Office…), l’indépendance par rapport à du hardware et/ou un lieu, etc.

Un indépendant qui travaille chez lui et qui ne se déplace qu’une fois par mois n’en aura sans doute aucune utilité contrairement à un freelance qui travaille dans plusieurs agences, ou une TPE et PME qui à des commerciaux sur la route ou qui pratique le télé-travail.

A propos de déplacement, Officity Mobile pour iPhone est en Beta et accessible dans chaque Officity (même la version d’essai)

Quelques petites précisions sur ce billet:

> bien que je n’arrive pas à déterminer
> sa date exacte de lancement

La solution à été commercialisée début 2005 sous la forme d’une solution expert (Framework gestion de contenu + plate-forme e-Marketing) et sous le nom de Nectil.

Nous avons finalisé la version Bureau Virtuel en 2007 sous le nouveau nom d’Officity, et ce n’est qu’après une période de test chez nos utilisateurs que nous avons lancé ce produit sous sa nouvelle forme en ce beau mois de mai 2008.

L’environnement est donc éprouvé depuis plus de 3 ans maintenant et propose un OS robuste loin des aspects gadget de certains bureaux virtuels (je dis bien certains, pas tous!).

Sinon, nous ne nous positionnons pas versus le trio doc-xls-ppt mais bien comme une suite collaborative (donc plutôt Outlook/Exchange/Messenger) et de gestion d’activité grâce à Sushee, un Office Management Framework, XML et open source. Sushee permet de créer tout type d’applicatifs web qui utilisent les mêmes données que Officity (et vice versa).