diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki
index bac01549..46a7ca2b 100644
--- a/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki
+++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki
@@ -1,4 +1,39 @@
-[[Property:uuid|D1DDF411-5387-4A81-9A85-3EF8A2A4220D]]
-[[Property:weight|0]]
-[[Property:title|How to build a concurrent graphical application: EiffelVision with SCOOP]]
-This page will be updated shortly with a short tutorial on how to use EiffelVision to provide a graphical user interface for a SCOOP-based concurrent application. 
\ No newline at end of file
+[[Property:uuid|D1DDF411-5387-4A81-9A85-3EF8A2A4220D]]
+[[Property:weight|0]]
+[[Property:title|How to build a concurrent graphical application: EiffelVision with SCOOP]]
+How can I build a concurrent graphical in application in Eiffel?
+
+Eiffel has a great library for producing graphical applications: EiffelVision. Eiffel also has a powerful concurrency mechanism: SCOOP.
+
+How do you make the two work together? This note gives you simple guidelines to ensure that the EiffelVision-SCOOP marriage is a harmonious and productive one. 
+
+The first question: why does the problem even exist? Let's go back to the pre-SCOOP days. Any graphical application has an "event loop", which keeps watching for graphical user events, such as a mouse click, and triggering the corresponding application responses, such as saving a file (if the user clicked "OK" on a File Save dialog). If you were using multithreading, the event loop would run in the main thread, also called the GUI (Graphical User Interface) thread.
+
+Enter SCOOP. The old technique cannot work because a processor stuck in a loop cannot process any logged call! If you perform calls on a graphical widget, say the OK button, they will be logged right away, but they can only execute once the processor has exited its event loop. Not what you want.
+
+So here is what you should do:
+
+Since your application uses SCOOP, somewhere it creates a separate object. Let the creation instruction be
+      create s.make
+where s is of a separate type (e.g. separate T).
+
+In the "make" creation procedure, create an EV_APPLICATION object, using an instruction such as
+      create my_app
+with my_app of type EV_APPLICATION.
+
+Still in "make", create all the GUI elements. They will all be in the same processor that created the EV_APPLICATION object.
+
+Also in "make", start the application, using 
+      my_app.launch
+In the pre-SCOOP world, launch would start the event loop. Here it only creates a separate object (of type EV_APPLICATION_HANDLER), which will run the event loop, forwarding  events to the EV_APPLICATION object.
+
+This is all the make procedure should do. Make sure it terminates with the preceding step. Otherwise,  the event loop will never run!
+
+Now you can start using EiffelVision as you are used to, by sending GUI requests to the EV_APPLICATION object:
+
+* For requests coming from the same processor as s, just use the EV_APPLICATION object directly.
+* For requests coming from another processor, you need access to that object; you can get it for example by through the feature ev_separate_application  of class EV_SHARED_APPLICATION}.
+
+
+That's all! Happy concurrent Eiffeling. 
+