• Deadline to submit an article
• Technical guidelines
• Technical guidelines (book reviews)
• Graphical guidelines
• Tips and tricks for writing an article
• Revision

1. An account is required to write for the magazine. You may click on CREATE YOUR ACCOUNT from the login area if you do not already have one.

2. Send an email to the publiser of the magazine to confirm your intention of submitting an article. Your email has to indicate the article title, a summary description, its level of expertise (beginner, intermediate or advanced), the topics that will be covered and when you think you would have it ready.

3. Write your article following this page technical guidelines.

4. In order to publish your article, a minimum set of information is required in your account. You may access your profile to enter your company name, your email, your Web site and your biography (English version required) as well as uploading your picture (big version required).

5. Once step 2 is completed, you will be able to submit your article by using your profile. You can also use the same procedure to update your article. This will remain possible for as long as your article is not published.

Each article should be received by the 10th of each month. An article received by that date is usually focused to appear in the next issue.

• Do not write your article using an HTML editor. The best editor for us, to allow a proper and clean editing, is simply Notepad. <s> The magazine is using its own stylesheet. Thus, the editing required to make it fit into our own format will be faster as oppose to removing all unnecessary tags an HTML editor would include.

• The following tags and styles can be used:

  Tag	Style	Explanation	Example
  P	ArticleSection	Represents an article section	...Evan Delay and Cindy Winegarden. We also include an interview with Ari Bixhorn about VB.Net. Our first Universal Thread members profile is about Eric Moreau. Eric is mostly involved in the Universal Thread Visual Basic forum since its debut. He'll tell us more about what he is doing, his involvment in the forum and his view at long term. VS Connections Our recent conference was the VS Connections one in Orlando where we were on site to cover the event for the Official Coverage. This has been our most interesting coverages so far. I am proud of all the persons who were involved in the reporting team who contributed...
  PRE		Used to list a program	Here is the program: Do While Not Eof() Skip EndDo
  TABLE	Detail	Display a table	NodeKey ParentKey NodeText root C:\ L001_001 Root C:\Windows
  P	Comment	Representation of a comment	So what do I mean by "not as flexible"? On the surface it seems pretty reasonable that a strongly-typed method only accepts specific types - how else would the compiler (and you) know that it's safe to access a specific method or property? It doesn't. It only can accept that specific type of class, or any subclass of that same type. Why is it OK to accept a subclass of the type? Well, the compiler can be sure that the subclass has the same exact properties & methods as its parent (it doesn't care if you add more of them or override the behavior). This is the rest of the article...
  P	Quote	Citation	Let's get the textbook definition out of the way, then take a look at what it really means (and why you should even care). From Wikipedia: "Interface generally refers to an abstraction that an entity provides of itself to the outside. This separates the methods of external communication from internal operation, and allows it to be internally modified without affecting the way outside entities interact with it, as well as provide multiple abstractions of itself. It may also provide a means of translation between entities which do not speak the same language, such as between a human and a computer." Hmm - OK. While technically correct that doesn't really help, does it? Did your eyes glaze over like mine did while reading that? Maybe if we back up a bit and look at what a class is we might be able to make some sense of this.

• If you have a portion of code which is long or which represents a program in itselves, have it zipped in a file and establish a link within your article.

• Don't put two spaces for line separators. This is useless in HTML. It also simplifies our editing when only one space is used for line separators.

• Don't force carriage returns in your article when those are not necessary. A paragraph should be written non wrapped so this provides a clear readability when verifying your article.

• When your code includes some HTML code or development code, this need to be within the PRE tag. This will assure your code will be displayed as is. Avoid including long lines of code. If you have long lines, make sure you wrap them on several lines. Try to not exceed 100 characters. The code will appear with the PRE tag. As the PRE tag is non wrapped, this is why you have to fix the length of your lines.

• When you include some code, indent any indentation with three spaces and not by the use of tabs.

• Each paragraph should be preceeded with a P tag after a blank line. When we verify your article, it is important that we are able to read it. If you write all paragraphs without any blank line as the separation, this is extremely difficult for us to understand its flow.

• There is no need to add a P tag before and after a PRE tag as the PRE tag already includes a paragraph delimiter.

• When in need to add a paragraph, always use the P tag and not <BR><BR>.

Here is the HTML view of what this HTML code would give:

Do While Not Eof()
   Skip
EndDo

• Include at the top of the review the book details. The following example is taking from "The Software Developer's Guide". Note that additional book details may be included. That may vary based on the book.

  Author: Whil Hentzen
  Publisher: Hentzenwerke Corporation
  ISBN: 193091900X
  Paperback: 548 pages
  Dimensions (in inches): 1.14 x 9.10 x 7.02
  3rd edition (July 2002)

• Send a picture of the book cover and align it from the top of your article on the upper right.

• If you include more than one review in your article, add a review header, by the use of the ArticleSection class, for the title of the book.

• If you make reference to the book name in your review, add in within quotes.

• Send your graphics in GIF format. Don't send them in JPG format. When this is the case, it doesn't give us any flexibility if we have to edit it. Please, save it in GIF format. Then, assuming we have to change the background color to make it transparent, we will be able to do it.

• Send us only the necessary window. Don't send us the entire screen. By entire screen, we mean the entire desktop of your monitor. It is only necessary to capture the related window as this allows us a better flexibility for the article layout and won't take as much space.

• You may use a tool such as SnagIt for your screen captures. That will give you greater flexibility for capturing the active window.

• If you capture your graphics using a region cut and that you do not apply the proper editing, this will force us to do so and that takes so time. If you do not have a proper tool to use, make sure you edit the cut image before sending it to us. By that, we need to have the graphic to have the window boundaries. When you send the graphics where one or two pixels are including outside of your captured window, this forces us to edit your graphics and may delay the release of your article.

• You may consider resizing your windows to the proper size before capturing it. Unnecessary area in your captured window takes some space for nothing. When doing your screen captures, it is only necessary to cut the proper sizing of the content which appear in your window.

• Save all your graphic files with your first and last name followed by the ordering in which they appear in your article. So, if your name is Michel Fournier and you have 2 graphics to send, they should be named MichelFournier1.gif and MichelFournier2.gif. This should match the URL of the reference in your article.

• Do not send pictures greather than 700 pixels.

Our recommended tool for editing is LViewPro. It allows any type of graphic conversionS, resizing, redimensioning and other necessary features to handle some editing on your graphics. It can be downloaded from http://www.lview.com.

Another excellent and free graphic editor that we recommend is Paint.net.

• Try to separate your article within sections. If you have a few paragraphs that deal with the same subject, make use of our P Class=ArticleSection style to add a header for those paragraphs.

• Include an introduction to your article. It is always a good idea to give the readers an idea of what your article will talk about.

• Include a conclusion to your article. You may include a short resume of what you talked about and any related information about any upcoming article, if you plan to add more topics to the existing one, etc.

• If your article is a follow up on a previous article, make sure to state it near the top of your article. Resume a little bit what was prior discussed in that article. So, this allows the readers to be up to date. Remember, not all readers may have read your prior article.

• Include pictures where appropriate. Sometimes, it is really necessary to include a picture to best describe a situation.

When time permits, we may send you an email to revise your article before we release the magazine.