These considerations are not supposed to be an input to the work flow management research component of the project nor are intended to be applied in the research process. They are meant for the communication and information exchanges via Internet (e-mail, listserv, FTP, WWW, etc.).
The document will tackle the following issues:
We all use e-mail and the rest of the Internet in our daily professional life. Whether we have been using it for a long time or discovered it a few months ago only, we all need to remember a few things to communicate better among us. Here are some useful tips, mainly for e-mail. Many of those are just common sense... but high technology does not exclude it. This chapter is mainly based on the Internet training course which was offered before M3 in Santo Domingo. Everything has already been said, but it is sometimes good to refresh one's memory and update one's way of thinking.
A communication cannot be efficiently ensured without feedback. Let's take a communication between X and Y. If X sends a message to Y, a feedback from Y allows X to check that X has been read, heard, and understood. Differently enough from other communication media (face to face or telephone), e-mail has no implicit feedback (such as gestures or sounds) and it is essentially asynchronous (the two parties are not communicating within the same time frame): this stresses the need for explicit and asynchronous feed-back. The fact that feedback and follow-up are necessary a-synchronous, does not mean they should be delayed.
People using heavily e-mail and listservs tend to multiply their exchanges in factor of ten or more. The increased number of communications arises obvious problem of context and memory at the time the receiver read a new message. There are two methods to help reduce the inconvenient at both end:
If X sends a message to Y and does not receive a message back from Y, this is very bothering for good communication, especially if the mail asks questions. The communication may even finish in a dead end. Is it a technical problem which has delayed the message? If not, is it that Y does not know the answer? That (s)he is investigating and will answer later? That (s)he has other priorities and/or does not respect X enough to take two minutes to write a message back to him/her?
In any case, it is better to answer "I have received your message but I cannot reply right now" than to transfer the message in a folder without any reply, and it is better to say only "Thanks for the information" than to wait for two weeks and another message to send a twenty-line thank-letter.
Never forget that feedback is only what you write, the strict content of it, whereas it is much broader "in real life" (meeting or talk on the phone). Be explicit in your writing. You cannot expect from somebody who needs to process dozen of messages per day to take time to decipher what you have not been able to express.
Broadly speaking, there are four types of professional exchanges:
Clearly enough, there are many opportunities to feel frustrated in written communication: e.g., if X asks three questions, and receives only two answers from Y. Is it that Y forgot, that (s)he does not know, that (s)he needs time to gather the information? X is even more bothered in his/her task by not receiving anything than by a bad answer: (s)he would have preferred to know from the beginning that Y was not able to answer, because in this case (s)he would have been able to initiate the next step in his/her job (maybe modified by the fact Y does not know, but quick and efficient anyway).
So, when you write a message, please be short, precise, accurate, insert separators between the various types of information. Feel free to number a list of questions, also. And when you answer, take each question one by one, and be as short, precise, accurate as the sender of the first message.
After the theory, let us take some examples of good answers:
(fiction, since GA and CV may speak Dutch in private)
GA: Have you received the document ReqAn.zip?
CV: Yes, I have it. I read it, I think:
- this
- and this
- and that.
Do you want me to put the wp2 list in copy of this message?
X: BTW, could you please help me with the document?
Y: I have not understood your question:
- what document?
- what do you expect from me?
X: Did you give Z his/her CD-ROM back?
Y: Z was here in the office one month ago, but (s)he did not tell me anything then. What CD is it? Would you like me to contact him/her directly?
(pure fiction also: DP and MC do communicate in French)
DP: 1) Could you please investigate on the possibility to develop an application which should do this and this and that on the CARIBCAD site?
2) Could you please update the page folder/file.html? The e-mail address of this person is not valid any longer, and should be replaced by <new address>.
MC: 1) I'm sorry, I cannot do this before early next month. Can you wait or would you like me to forward your message to Gustavo? (in this very case, they are in a big trouble, since Gustavo does not speak French, then they have to provide a translation :-)...)
2) OK it will be done by tomorrow.
Please pay attention to the headers. When you are the sender:
There are basically two cases when a reply is needed:
In both cases, it is strongly recommended to quote the part of the message you are answering to (most of the mailers allow to do this automatically, and make each line begin with a >). Let us add some more tips, which would allow you to understand a reply four weeks after it has been sent, without being obliged to search all your archives.
Here are some examples of good answers:
Original message
Dear X, I would need your opinion on the document I have attached to the document. Do you think I should edit the first part? What are the persons I should send the doc. to (for revision purpose)? I cannot remember: by what date is the final version due? What do you think of the general tone? Isn't it too critical? Thanks for telling me franckly. Y.
Reply
Dear Y, >I would need your opinion on the document I have attached to the >document. No problem to give you my opinion. You know you are always welcome. >Do you think I should edit the first part? Not necessarily. In my opinion, the details you put are very useful, and I like the choice of your examples. You could make it a bit shorter paying attention to the style. >What are the persons I should send the doc. to (for revision purpose)? I'm sorry, but I have no idea: Z is on holidays, and, apart from him, I don't know anybody who could help you with the very content. Now, if you need to a proofread and spelling corrections, W would probably be glad to give you a hand. >I cannot remember: by what date is the final version due? I don't know the eact date, but around the 30 of next month: between the 25 and the 31, for sure. I may check. >What do you think of the general tone? Isn't it too critical? It is definitely too much polemical for a public paper. I suggest the following changes: blah blah blah...
First message (X to Y):
Could you please check the train schedule on the Minitel? I cannot get it through the Web: I need to go from Paris to Delft in order to get there at 2:00pm the latest on Thursday 13 next month. I would like to come back on Sat. night or on Sunday. Of course, the cheapest would be the best. :-)
Answer (Y to X):
>Could you please check the train schedule on the Minitel? etc. I have the info. Note that you need to go from Paris to Rotterdam, then to make a transfert to Delft: here are info for Paris-Rotterdam, but it is then a 10 or 20 mn connection. Thur. 13: 6:20 - 10:30 7:15 - 11:32 9:00 - 12:57 9:55 - 13:50 Sat.: latest one leaves Rotterdam at 17:00. Interested? Sun.: on a regular basis (every other hour, more or less) from 7:00. It is a 4 hour trip. $$: depends on what you are eligible: if you make the reservation one month ahead, if you travel with another person, if you are over 60, etc. Also, it would be cheaper to stay three full days. Please tell me if there is anything you know that can help. Would you like me to make a reservation?
Second turn (X to Y):
Thanks for the info. >Would you like me to make a reservation? Right now, I'd better think of the possible options. I tell you later on, if you don't mind.
The communication in the lists follow about the same rules as one-to-one communication, as described above. Be aware of the difference between responding to one person (e.g.: CD asking everybody data to build a directory; it is better to answer only to her, who will gather all the information and make the directory) and to the list (general issue that may be interest for all the members of the list).
http://funredes.org/caribcad/private/communication/lists.html
A reminder about listservs: there are now seven mailing lists, each of them being designed for different purposes.
As this time, everybody is member of all the lists. You do not need to give the same priority to the lists you are not directly related to, but this global subscription allows you to follow the general progress as well as the daily work of all the partners. The inscription is "closed": your request must be approved first by the owner of the list, but it is possible to unsubscribe at any time.
Warning: beware the size of the attached documents you may want to send through the listserv. There is a limitation. It is often better to put the document on the FTP and send a message to mention where the document can be found.
Computer use may quickly raise problems of rights and of ethics. Please keep in mind that we are not nicely exchanging mails and tips in a private framework, but we are working in an official project funded by the EU. That means we need to be very careful with copyrights. Here are a few recommendations:
Other recommendations for a good behavior on the Net:
A problem may arise when several people work at the same time on the same document. Indeed, what if EGM and TecAm want to add their comments on a Pilot 1 document at the same moment, and make it public on the FTP or on the Web? It is a possibly real situation: when it is 10:00am in the DR, it is 3:00pm in the Netherlands, a time when both countries work. In this case, in the present situation, the latest one who upload his/her document erases the previous version, installed ten minutes before by his/her partner. On the best hypothesis, two partners do exactly the same job. This is not a situation we want to face.
In order to solve this problem, we have decided that the first person who puts a document on the FTP or on the Web is, by this sole action, designed as the "owner" of this document, and then is responsible for it and its updates. How can we do so? By giving a distinct login and password to each institution. From now on, you are not going to get connected to the uploading part of FUNREDES site by the login CARIBCAD and the password TUDELFT (all in capital letters), but you will be assigned a specific login and password. In a near future, these logins and passwords are going to be different for each institutional partners (e.g.: one for the whole FUNREDES team, and not one for CD, another one for MC, a third one for DP). With your new login, you will be able to "read" (download to your machine) every documents, and "write" (upload updated versions) on yours, i.e. the ones you were the first one to have uploaded. Messages to inform you about your new login and password are going to be sent directly to you early February. Then, if X wants to work on a document which was created by Y, (s)he can download the document to his/her machine, work on it, and if (s)he needs it on the server, (s)he sends it to Y (or put it on the FTP server under another name). Y is the only one who can replace the old version of the document by the new one. Tip to avoid too many transfers: Y uploads his/her document on the FTP server, X removes the first version, and then Y renames the latest version that (s)he has installed on the server and gives it the name of the original version.
NB: it becomes extremely important to mention in each version what institution is responsible for the document.
Here comes a crucial point in CARIBCAD: we need to define "standards" for our exchanges (exchanges of documents, data, and images). What is meant here by "standard" is not necessarily a "real" official standard, but a format on which everybody can easily work. First of all, each partner has to be aware of the fact that the equipment and the maintenance are not exactly the same in the North as in the South. We are not looking here for the State of the art in such and such field, but we are trying to define a common set of tools which allow a good communication between people and institutions. This chapter is a very open one: nobody can forecast for sure what will happen within the next two years in terms of software, market, new products, usage, etc. At this time, it is only a quick review of the obvious solutions experience has brought.
There are no standards here. Some of us use Macintosh (various system versions), some others Windows (no Linux?), and Windows users are divided into Windows 95 and Windows 97 (no 3.1 or older?). We have to accept and to face this situation, and to make our documents accessible to everybody.
At the present time, the standard de facto is Microsoft Word. But, if everybody uses it, there are differences in the versions and the systems. The first solution is to save all the documents as RTF files. Now, there are new compatibility problems with Windows 97. A patch has been installed on the FTP server (now in the directory called WordConverter) to make the conversion from Windows 97 to other systems and Word versions. Please use it before complaining that you cannot open and read a document :-)
The second solution, which may be good in case of documents containing text and graphics, is to use HTML. We are indeed part of an Internet project, and HTML is the standard for Web pages. Let's use it as soon as possible. And do not use tags and commands that cannot be read by *any* browser: remember that "real" HTML is the best language to write Web document.
There is a difference here between simple graphics and images, and vectorized files, CAD documents, etc. We are talking here simple images only. The most convenient format seems to be GIF. If you do not have an application specially dedicated to images, you can read GIF files with your Web browser.
This part needs to be investigated.
There are two standards here: ZIP is the most widely used format for Windows, but not in the Macintosh world, where .cpt and .sea formats are more common. There exist software which allow Mac users to use ZIP format (to read and create ZIP documents). For instance, ZipIt costs US$15 and it works rather well (note: when downloading a ZIP file from the FTP server with a Macintosh, use "binary" and not "automatic" detection to be able to open and read the file with ZipIt). It is certainly not the only one. This is also an open point which needs further investigation.
In private communication, you may of course choose the format you like best. But in large communication (mailing lists, etc.), please use the standards.
Without being really part of the standards themselves, it is a standard attitude not to send documents which are obviously too big (some megas) without warning your party(ies) before sending them, and get his/her/their agreement. Or, you may like better to put the documents on the FTP site.
Also, if you do know your partner is likely to encounter problems to read the document you wish to give him, you may want to make a test (with a small document) beforehand.
First of all, we have a Web site (it has been opened since late December 1997). It is divided into two parts: a public part, that anybody can read, and a private part. As a member of the CARIBCAD project, you can have access to the private part. You simply need to enter a login and a password when asked.
login: caribmember
password: tudelft
(all in small letters).
Since we (all the partners) own the Web site, we need to maintain it, i.e. take care of the documents which are installed on it. Who does what when? That is about the question(s) with this site. Each user can read and download any document on the Web server. As far as uploading is concerned, FUNREDES has decided to have an open site, i.e., as a CARIBCAD user, you are allowed to install documents on the Web site. But, in order to maintain internal unity, everybody needs to follow the same rules:
The FTP should not be a large directory with everybody putting everything in a chaotic way. It has grown a lot since we opened it, and then it will be organized (early February) in directories (each directory corresponding to a specific theme):
Creation: Jan. 30, 1998
Latest modification: June 17, 1998
Author: CD-DP (FUNREDES)
© 1997-98