When I first heard about the 2013 Google Code-in challenge, I was very interested, but worried that it would focus on programming languages like Java and C++. Although I have experience with those languages, I am more skilled in languages such as HTML and CSS. As I looked into the contest, however, I learned that web design and user interface tasks were available in a wide variety. I was extremely excited, because now I had a way to practice the areas in which I am most skilled. I noticed Wikimedia as a sponsoring organization. Like many others, I use Wikipedia for everything -- learning random information, settling bets, and more. However, I had never edited an article or gotten involved in the community. When the contest began, I went straight to Wikimedia for a task, and found one that caught my eye: "Convert two pictures of diagrams into wikitext." The objective of this task seemed relatively simple: examine two diagrams that had been drawn by Wikimedia employees on white boards, provide a transcript of them, and convert them into HTML and CSS diagrams. This seemed like a fun, but challenging task, so I requested to work on it. While waiting for my claim to be approved, I went to and read about the site.

From what I could tell, it appeared to be some sort of open-source collaborative project that uses PHP and wikitext and is affiliated with Wikipedia and other Wikimedia projects. I read the introductions, tutorials, and talk pages to give myself an idea of what I would be working with. By the time my claim on the task was approved, I felt that I was ready to take on the challenge. I began by planning out my diagram design on paper. Once I had my general ideas, I created the wiki page and began my diagrams. For the first one, I used an ASCII art picture to transform the original drawing into text. While I was working on it, I received a message on the task page from my mentor, Quim Gil. He asked me how it was going and informed me that communication was key to a good project. Heeding his advice, I showed him my work so far and asked him what he thought.

Quim told me that using ASCII art limited the editability of the diagram, so using a design that could be easily edited would work better for the next diagram. I reworked my idea and came up with an outline format design. Using <div> tags inside table cells, I was able to make a clean, aesthetically-appealing, and functional diagram. It was difficult to get the design right. Every time I tried to fix a minor mistake, something else (spacing, color, etc.) got messed up. My mentor's advice, however, helped to guide me through the process of perfecting my design.

In addition to Quim's help, I received a great deal of assistance from pages on MediaWiki. Tutorials showed me how to use the site's available tools to expedite the process. A color guide showed me what hues of colors to use to improve the aesthetics of the diagram. It taught me that yellow and purple are colors to be avoided on wiki pages because they are hard on the eyes and can easily be replaced by other colors. I also learned that it is best to use a greyscale pallette unless attempting to make a spot on the screen pop or elicit a certain reaction from the reader. Talk pages taught me more about MediaWiki and wikitext. Before I took on this task, I didn't even know how to properly link pages! Thanks to the great help available from Wikimedia sites, I now have mastered this: "[[Wikipedia:MediaWiki|MediaWiki]]" shows up on the reader's screen as MediaWiki. Without the help of these sources, my diagrams would never have been as good as they ended up being. I think that the ease and simplicity of MediaWiki's editing page greatly assisted me. With a few clicks, I could change my text to a paragraph or header without having to worry about complicating things with <p> and <h1> tags. I also liked the community aspect of the site. The "discussion" tab promotes sharing and collaboration, and the ability for anyone to edit pages allows everybody to combine their skills and efforts.

As I wrapped up my project, I began to worry about whether I would succeed. What if Quim did not like my project, or the deadline expired? What if all my hard work went to waste? At times, when I just couldn't get that last bit of spacing right or unravel that indecipherable piece of code, I lost heart, but the community pulled me through it. Eventually, I managed to piece together all of my newly acquired information and create my final product. When I was finally finished, I realized that I had done more than complete a task and learn some new code: I had broadened my horizons, been welcomed into a new, friendly community, and learned a new meaning of pride. As I admired my handiwork, a feeling washed over me that it was all worth it. All those hours of labor, endless code, and hundreds of searches had paid off. I submitted my work and anxiously awaited the verdict.

I suppose you already know the result: my work was approved! However, it was more than just a check on my task list. It was an experience that I will carry with me through the rest of the Google Code-in contest. This is why organizations like Wikimedia and contests like the GCI are so important. They reach out. They teach. They inspire.