Cette page a démarré initialement comme une traduction du lien MediumAttributes. Elle liste de nombreux facteurs dont nous pouvons nous soucier quand nous étudions LeMédium pour la communication.
- Interruption – Est-ce que la communication nous interrompt ? La fenêtre de la messagerie instantanée surgit dans une nouvelle fenêtre. L'email est périodiquement relevé et téléchargé sur notre ordinateur. Nous avons véritablement à cliquer sur notre navigateur pour cibler un site web.
- Programme – Est-ce que les personnes sont facilement visibles ? Ou devez-vous préalablement planifier une rencontre ? Ou est-ce que la conversation est presque complètement détachée de l'espace-temps ?
- Temps Réel – (ou "Syncrhone" vs "Asynchrone") Est-ce que les gens interagissent en temps réel, ou envoyons-nous et recevons-nous des messages stockés ? Pouvez-vous décaler la réponse ? Le temps réel tend à accompagner la planification mais pas toujours. (Prenez pour exemple la présence sur la messagerie instantanée ou les listes d'abonnés IRC).
- Présence – Est-ce que les participants sont visibles ? Est-ce que leur présence est notée ? Peuvent-ils apparaître comme présent quand ils ne le sont pas, ou semble être loins quand ils sont bien présents ? Quels degrés de présence sont supportés ? Est-ce que la présence est explicite (une icône indiquant la présence, la disponibilité) ou implicite (une liste de personnes dans le canal, la plupart d'entre elles ne disant même rien) ?
- Formalité – Est-ce que le médium promeut la formalité ou l’informalité ? Est-ce qu'il canalise la formalité à certains endroits ?
- Concentration – Est-ce que le médium promeut la concentration ou le manque de concentration ? Est-il facile de créer la concentration, et quel est le niveau de facilité pour dissiper la concentration ?
- Mouvement du Corps – Quels types de mouvements physiques des participants peuvent être incorporés par le médium ?
- Taille du Groupe – Quelles tailles de groupes peuvent être supportées par le médium ?
- Concentration personnelle – Est-ce que le médium valorise l'individu (par ex. blog) ou le groupe (wiki). Est-ce que les personnes peuvent s'exprimer elles-mêmes et si oui, à quelle fréquence ?
- Canaux – Est-ce que le médium a aussi un canal pour la communication, ou offre t'il des canaux multiples pour communiquer ? Quel est le degré de facilité pour créer et détruire les canaux pour la communication ? (Voir aussi LeCanal)
- DocumentsContreMessages – Comment fonctionne le médium pour créer des documents ? Comment fonctionne le médium pour envoyer des messages ?
- Organisation – Comment le médium vous autorise à structurer l'information ?
- Référencement croisé – Est-il facile de pratiquer le référencement croisé entre les documents et les messages ?
- Directionnel – un sens (unidirectionnel), deux sens (bidirectionnel), one to one (point à point), one to many (broadcasting)
- Contrôles
- Contrôles accès - est-ce que tout le monde peut écrire, ou seulement certaines personnes ? Est-ce que tout le monde peut lire ou seulement certaines personnes ?
- Contrôle du contrôle administratif – quels types de contrôles administratifs offrent le medium ? Quels types de contrôle éditorial ont les administrateurs ?
- Adhésion – est-ce que chacun est administrateur – peut être est-ce démocratique ? Comment un individu peut joindre l’interaction ? Est-ce ouvert, semi-ouvert ou fermé ?
- Implémentation
- En-ligne ou hors-ligne – affecte généralement les qualités en rapport avec l'espace temps comme l'interruption (ne peut interrompre les personnes hors ligne si vous êtes restreints seulement au en-ligne → vous avez besoin d'une sirène ou quelque chose de similaire pour notifier les personnes hors ligne)
- Pratique –- Quel est la façon d'accéder au médium ? Devez-vousbooter (initialiser) un ordinateur pour y accéder ? Cela prend t'il du temps pour qu'il réponde ? Est t'il plus simple qu'un téléphone ?
Notez que ceci a plus à voir avec l'InterfaceUtilisateur que le protocole. (MédiaApproprié)
Vous pourriez théoriquement produire un IRC en dehors du transport de l'e-mail (?). Ou pourriez faire surgir des messages email sur l'écran, comme les messages instantanés tendent à le faire.
Voir aussi
PageTranslation MediumAttributes LangueFrançaise DossierCommunication
Discussion
Liens en rapport
Dans l'intention de fédérer, je vous propose quelques liens de référence :
Technologie et InterfaceUtilisateur
Ce que je propose est de trancher les caractéristiques en deux parties - d'abord les caractéristiques techniques d'un outil de communication (ceci est comme un ensemble d'axiomes), la seconde est la partie concernant le fait de faire correspondre un outil à un but spécifiqieu. Par exemple, l'interruption et le programme irait dans la partie techinque et la taille du groupe et la formalité iraient dans l'autre partie de la liste. Puis l'exercice consisterait à déduire l'usage des caractéristiques tirées des axiomes techniques. --ZbigniewLukasiak
Je ne suis pas sûr - parce que l'InterfaceUtilisateur, tout en étant contrainte par la technologie, peut vraiment la déformer.
Par exemple, le bit d'interruption peut être fait avec l'e-mail, ou quasiment toutes ces techologies. Interrompage instantanément - c'est un peu différent. Cela dépend alors si c'est une technologie push ou pull.
Vous pourriez produire un IRC extrait de l'email, si vous le vouliez, parce qu'ils sont tous deux des technologies de push.
Vous pourriez (ug !) produire une e-mail à partir d'IRC.
Mais l'InterfaceUtilisateur est technique et peut être même analysée même s'il est plus dur à réaliser que les protocoles de bas niveau. J'essaye de le faire sur ma page à propos de la communication syncrhone et asynchrone[1]. La différence est qu'il y a quasiment une unique interface, et l'e-mail de bas niveaux ne se distingue pars de la MessagerieInstantanée?.
Well, wait- The difference between "technical characteristics" and "fitting for a particular purpose" aren't so clear to me.
For instance, scheduling referred to- "Do you have to schedule to communicate?" So, like, in IRC, you sort of have to schedule. You sort of don't have to schedule.
E-mail, you never have to schedule.
Do we want to call this a "technical characteristic", or place it in the "fitting for particular purposes" bag?
I don't know; I'm trying to understand the distinction you are wanting to make.
Perhaps I should have started with stating the goal of this excercise. I see it in helping the IM programmers so that when they could concentrate on a lesser number of features because they would knew that the others can be deduced from those allready implemented. So when you don't know if some feature is reducible leave it as an axiom.
I've added "Presence," in response to reading some of DouglasGalbi's paper.
I'd also like to find a way to fit in some of the ideas that the CommBot suggests: Like, how in the future, we'll probably tell our programs, "I'm available for talking about X, or Y, but not Z, or anything else, unless it's an emergency."
Liens supplémentaires
Just a few links: JEP-01xx: Virtual Presence Protocol - a protocol for adding Jabber based IM to web (and in particular for wikis), LLuna an implementation, and Slasdot discussing LLuna. I think this can be a great project and my amateur analisis suggest that combination of IM and wiki can be the one of the most powerful communication tools.
Voir aussi ThoughtStorms:TomCoatesTwoDimensions