Criterion E - Evaluation

Yesterday we finished our IT websites, and mine is now available online at WebMun. This project ended up being a lot more work then planned and definitely our largest IT project of the year. Overall I'm quite happy with my website but there are many areas in which I could have improved throughout the process.

Criterion A - Investigation
My investigation and the creation of my actual website were nearly merged, in many aspects. I started off this unit by spending quite a long time looking at design 'principles' - what to do and what not do while creating websites. In the end, I think I spent too long on this considering I would later be limited by my own technological skills. Sure, it would in theory be great to have a custom 404 page, links that display properly in browsers for the blinds, clear headings and sub-headings that display perfectly across all web browsers. But when it came down to it many of these I simply did not have time for, or simply was not able to put in place. Most of people's knowledge about good web design comes in my opinion from themselves. I spend quite a lot of time on the internet and instead of spending a long time looking at what makes a good website, I could simply have thought about it. This would have given me more time to do the rest of my work.
After I looked at design, I started looking at coding languages themselves. I had done some programming before so I had a vague idea of the web languages I would need to investigate and get better at before actually starting my project: HTML I already knew, but I needed to practice CSS and particularly PHP, which allows for interactive websites. In many ways I think I spent too much time practicing these two languages by creating small pages that weren't directly useful to my final website, to just get myself going, than I really needed to. If I had started my website while practicing the languages, I would have managed to both get started on the website and practice.
The other thing that I did not spend enough time on during my investigation was looking up the actual topic of my website, MUN. I know quite a lot about MUN from personal experience but explaining it to other people was a completely different thing. Since I had a hard time with that, I ended up mostly linking to other websites explaining MUN in my final website. If I had read these articles beforehand, I might have been able to explain it in my own words, which would probably have been better for the wbesite as a whole.
My biggest issue during investigation was therefore time management. I knew we had a lot of time for this unit and I wanted to create a pretty ambitious website, that used technological skills I did not previously have. I ended up spending so much time "investigating" these languages that I did not have enough time left for the rest of my project.

Criterion B - Design
My main goal during the design stage was to keep the website simple and not do anything too groundbreaking. If there are going to be changes in web design, they'll occur slowly and it's not up to me to start a completely new trend. I think my website succeeded in that it was pretty simple and straightforward, but it would have been better to get it double-checked with others before starting to work on it. What really seemed obvious and simple to me might be impossible to understand for someone else, depending on what websites people are used to.
The part about my design that I was happy with, however, was that since I learned CSS before doing my design I knew what was possible and what was simply too hard. Having realistic expectations allowed me to make a design that was both possible to create and somewhat pleasant looking, and since I coded my own template I achieved pretty much my exact original design, instead of having to adapt to a ready-made template.
Knowing a little bit about programming languages from my investigation, I also wrote a to-do list of design specifications that was divided in priorities. This was really helpful for me while creating the website as it helped me manage my time better - instead of creating a handful of very pretty pages and then not having time for the rest of the website, I knew what had to be done before I could get into smaller details.
My design was pretty efficient but perhaps I should have thought more about the practicalities of creating such a design. It's very nice to only have to click two pages to get to the page you want, but practically with PHP this couldn't really be done...if I had done parts of my design after starting to create my website, I might have improved its feasibility.

Criterion C - Plan
My plan was pretty detailed in and out of itself and it sounded good on paper. As I moved forward, though, I realized it was completely unrealistic. Since I knew very little about PHP, it was impossible to plan how long creating each part of the website would take. I planned to create the login system in an hour - practically, it took me about 4 IT classes to get this done. It would have been hard to make a better plan, especially as few of the online tutorials tell you how long it will take to get this or this done. Programming can be very quick if everything goes according to plan, but it's hard to plan how long this or this will really take. I remember while creating one of the pages on my website I spent 30mn editing code and changing everything because it simply wasn't working. Eventually, I realized I had just forgotten a semi-colon. How can a plan prepare for this type of problems?
As I pretty quickly realized my plan was unrealistic, what I could have done is written a new one as I went along. Although you can't plan for every single problem, it's possible once you get coding to estimate about how much time each step will take. Instead I went without a compass and used my to-do list instead of an actual plan, which may not be the greatest idea time-management wise.

Criterion D - Create
Creating my website took much, much, much more time than I had planned. To be honest, I didn't really mind as it gave me the chance to learn PHP, a programming language I'd planned to learn for a long time but never gotten down to trying out. I learned a lot about programming and realized how little I really know about computers.

The first step of creating the website was to implement my design using CSS and HTML, two languages that are actually quite simple. Designing is quite forgiving: if you forget to put a sign here or there, chances are your website will still display correctly. With help from various websites, I was able to get my website's design up and running in about two evenings. It was a very fructuating part of the creation as you instantly get to see your designs and it doesn't get too long to put them up.

After designing my website started the hard part - getting it to "work". WebMUN was designed to be an interactive website, which I was abotu to find out just how hard it is to create. You can't simply type a page of information if you are going to let users contribute to your website. You need to create a page with a form in which the user can submit something, then a PHP script on another page to analyze that information, then another script to put it into a database (you first need to have that database set up, of course), then ANOTHER script to retrieve it from the database, another one to display the information and finally something to tell the user after they've submitted the first form.

I learned this as I went along and in the beginning, creating this code was very complicated as I did not remember the exact syntax of PHP. It's a pretty strict language - forget one character, write a double quote " instead of a single one ' and your whole page will not show. Troubleshooting was a very stressful process. It's annoying not to know why it's not working, and even more annoying when you find out it was just a small syntax error. On the bright side, it really helped me develop problem-solving skills. If a page wasn't working, I removed a chunk of code and saw if the website was still working - if it was, I removed an even smaller chuk until I had figured out exactly where the error came from. This idea of breaking a big problem into a smaller one is very present in programming but I think it can really help you think logically in other aspects of life.

As I got various parts of my website running, I think I developed many other good habits. The first that I told myself from the beginning was to never copy and paste codes from examples and tutorials, and instead type everything up myself. This seemed very redundant in the beginning and I nearly gave up on this resolution a few times. I was so happy to have written everything myself, though, when I came to the more complicated parts of my website. I was familiar with PHP and really understood it since I had always typed all the code myself, and it made it possible to go outside the boundaries of tutorials. It was easy to find explanations on "How to create a login system in PHP" but not quite so easy to find out "How to create an MUN-type debate system in PHP"....I was able to create that without a tutorial because I had learned PHP before.

The second good habit I took up during this project was never giving up on creating any type of web component. Sometimes it looked like the debating system or the voting system would never work, but once you start giving up on functions it all goes downhill- you start to give up on anything remotely complicated. It's better to have a website with a few fully-working functions than with stubs of many that you never get around to finishing.

The biggest issue with my website was probably navigation. My website ended up being very complex and navigation therefore also got much more complicated. I was spending so much time on getting things to work that I didn't have time to make sure it was clear to others how it worked. When I was nearly done with my website, I asked my friend what she would do when she got to the homepage. To me it was obvious I would click on the big "Join Now!" picture. Surprisingly, she said she would try clicking around the navigation bar, which was exactly what I DIDN'T want users doing as they were first supposed to register and login. Figuring out all the things users can do "wrong" was the hardest part of the website and the one I didn't spend enough time on as it's really what makes up navigation. I have a new found respect for programmers when I see all the work it takes to create just one small debate system. There are so many unknowns when users can click on just about any link! It probably would have helped if I had looked at more websites in the design stage.

Overall
In a contradictory way, I think my website would have been better if it had been smaller. I had limited time and making a smaller webpage would have allowed me to focus more on navigation and other issues, in order to have a perfectly working small website rather than a large, prototype one. I was a little overambitious, which is something I'm afraid I do quite often - I do not really take into account my time limitations and end up creating a large but imperfect product. This really is something I should think of in the future as a half-done job is not something I want to be doing in my DP years or college work.

Compared to my original design specifications, my website did not achieve all it was supposed to. Considering they were as I previously mentioned a little over-ambitious, that is not necessarily a bad thing but it does show me that I need to set myself realistic goals in the future. If from quite early on in the project you know you will most likely not achieve all of your goals, they become useless as you have no measure of how much you really plan to get done.

Design specifications

1. Information on MUN in general (debate procedures, researching tips, helpful links...) --- Yes. I wrote some of that information myself, but a lot of it was also linked from other websites.

2. Sign-up and login function --- Yes. This is something I spent quite a long time on adn it completely works.

3. A number of separate committees with sign-up functions for countries and chair positions --- Partly. Debate is enabled but there are no chairs and only the Security Council is fully working.

4. Real-time private chatrooms for each committee --- No. I realized this was not necessarily a needed function as the chances of there being enough delegates online at the same time to host a debate are quite slim.

5. Private chatroom and inboxing for the drafting of resolutions --- drafting of resolutions is enabled, but no private inboxing function.

6. Discussion pages for each forum with options such as "Speak for this resolution", "Speak against this resolution", "Submit an amendment", "Motion to..." to allow for delayed debating --- Yes. Delayed debating is nearly fully implemented.

7. Informal discussion forum for delegates to get to know each other --- A forum is present, but it is not really a "discussion space" so far.

8. Voting tool on each resolution --- Yes. This part is linked to an external website and consistenly works.

Overall, I'm still happy that I challenged myself as I learnt a lot throughout this unit. This was my favorite project of the year in IT and I think it's a nice conclusion to three years of technology as I really put together many elements we learnt throughout our units - how the web is changing (Web 2.0), internet ethics, how others are different from you, how to best pass along information...It followed on the Wikipedia unit where we started becoming active creators of the Web instead of passive observers. For me, this also gave me a different approach to websites I daily visit. Thinking of just how much work is behind Facebook or YouTube makes me dizzy. I also think it is important for teenagers to realize that there are limits to what is possible. We are at an age where we have dreams that are sometimes too big, and just seeing how much work an everyday product can be puts many things back into perspective.

In any case, the work of the webmaster is a never ending one and I think this unit really reminded me of the ever-changing nature of websites. When users are adding content, a website is constantly growing and interconnected to other websites. I hope I have time to improve WebMUN in the future as it is a project I am interested in and spent a lot of time on.

Sources

Below are the MLA sources used throughout the creation of my website.

Priest, Dana and DeYoung, Karen. "Cyber-Warfare: Challenges of the Unknown." CBS News. 19 March 2010. 01 May 2010


Wikipedia contributors. "United States embargo against Cuba." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 23 May. 2010. Web. 02 May. 2010.

"Web 2.0 Icons & Buttons." Axialis. 2009. Web image

Leler, William. "Cuba Embargo." Main Cuba. 2002. 02 May 2010

Voss, Michael. "Obama renews Cuba trade embargo." BBC News. 15 Sep 2009. 02 May 2010

"Nuclear Weapons Program." Global security. 2010. 02 May 2010

Wikipedia contributors. "Nuclear Non-Proliferation Treaty." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 20 May. 2010. Web. 25 May. 2010.

Wikipedia contributors. "North Korea and weapons of mass destruction." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 24 May. 2010. Web. 25 May. 2010.

"Iran's nuclear program." The New York Times. 03 May 2010. 03 May 2010

'klickitmedia' (pseudonym). "How to create use $_SESSION in PHP". eHow. 10 May 2010

jatar_k (pseudonym). "PHP Server Side Scripting." Webmaster World. 2006. 15 May 2010

Bradley, Angela. "MySQL Tutorial: Managing MySQL data." About. 16 Sep 2009. 18 May 2010

Franklin, John. Tizag. Erack Networks. 2009. May 2010 .

"Free Country Flags Pack." Free Country Flags. 2008. May 2010

W3 Schools. Refsnes Data. 1999. April-May 2010
"The HTML Form Submit button." JavaScript Coder. 2009. 21 April 2010
"UN Security Council meets on the topic of Gaza." UPI. 2010. Web image. 15 May 2010

Chat room, forum and login options

I'm a firm believer that if there is a technology out there that allows you to do something, there is no point in rewriting code to do the same thing. With my current PHP skills, I don't think creating a chat room or a forum would be very successful, for example. Instead I will use alternate systems that can be implemented with the rest of my website.

Chat room
Besides the typical delayed debate option, where one delegate posts something and another replies in a few hours or days, I also want to have a chat room system available. A small number of delegates (10 at most) would enter a private chat room at a set time and have a regular debate for maybe 30mn.
I decided to use a system called PHPOpenChat. This free chat system was developed by a group of programmers and you can basically add the code to your page to have a simple chatroom that you can customize. There were many systems available but PHPOpenChat was the most developed and it had the most documentation available.


Facebook Connect
Registration is a long and painful process, and it's also a little hard to set up. I have been on a few websites, however, that allow you to create an account on their site using your regular Facebook account. I looked this up and found out Facebook developed an API called Facebook Connect, that lets websites other than Facebook use your facebook account for various things - simply logging in, commenting, sharing pictures...
I want to give my visitors the option of connecting to my website using Facebook, as my target group is the kind that will most likely have a social network account. This way, if the registration process I code for my website myself doesn't work, visitors can still log in using Facebook Connect. It will also make registration much faster for people who just want to have a look.


reCAPTCHA
Captchas are the little registration confirmation codes that require you to read two words that are strangely twisted to make sure you're not a computer. I want to prevent my website from being attacked by any type of hackers, so I chose to use captchas. reCAPTCHAS are very easy to implement - you can simply add a few lines of code to your registration page. I also chose them because they have options such as an audible captcha for blind people and are therefore accessible to everyone.

phpBB
phpBB is a technology used to create discussion forums. I want a discussion forum for my users to discuss matters outside MUN. phpBB allows you to create very complex, customizable forums that are afterwards easily managed, and it's free, so it's by far my first choice. Many phpBB forums can be found throughout the internet as it is the leading technology for creating simple discussion forums.

Meebo bar
As an added functionality, I want my users to be able to chat with their other messaging accounts (Google Mail, Facebook, MSN, Yahoo...) while they are on WEBMUN. I think this will keep people connected longer. For this I found a very simple solution called the Meebo Bar - a simple bar at the bottom of the page from which you can connect to all your other clients. This is once again very simple to implement.

Links
http://www.phpopenchat.org/
http://www.facebook.com/connectnews?v=app_7146470109
http://www.tutorialized.com/tutorials/PHP/Chat-Systems/1
http://bar.meebo.com/

Committees and countries to include

As part of my WEBMUN website, I need to decide on a number of committees I want people to be part of online. I would like to stick to the more typical MUN committees, as I don't have time to create various debating layouts to accommodate different types of debate. Here are therefore the committees I cannot include:
-Youth Assembly
-International Court of Justice

I looked up a number of conferences throughout the world such as THIMUN in The Hague, and BEIMUN in Beijing, to get an idea of the issues and committees present in MUN. I decided that WEBMUN should include 3 committees to start with - the General Assembly, the Human Rights Commission and the Security Council. The General Assembly allows many members to join as it can have up to 290 countries, and the other two provide smaller and varied committees.

I decided for WEBMUN to debate the same issues inside the committees as were discussed in The Hague in 2010. These issues are therefore very recent and since they were used during this conference, they are most likely good debate sparkers. Here are my issues for each committee:

General Assembly

• Creating a legal framework for the issue of cyber warfare.

• Ending the economic, commercial and financial embargo imposed by the United States of America against Cuba

Human Rights Commission

• Measures to combat discrimination and social isolation of the disabled

• Ensuring the right to food for all, without discrimination

Security Council

• Nuclear disarmament of Iran and North Korea
  

I am only including a few issues in each committee because debate online is bound to be somewhat slow. If there are too many issues available, there will be little debate over each. I would rather have 30 people arguing over one thing a little bit every week than the members losing interest because none of their points have been answered.

Every country is included in the General Assembly, the full list of which may be found here. I wanted to use the countries of the Security Council in 2011 for my own Security Council, but they have not been voted yet. Instead I used the list of members in 2010:
-China
-France
-Russia
-England
-USA
-Austria
-Japan
-Turkey
-Bosnia
-Lebanon
-Uganda
-Brazil
-Mexico
-Uganda
-Nigeria

There are 47 members of the Human Rights council whose list can be found here.

Wikipedia contributors. "United Nations Human Rights Council." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 12 Apr. 2010. Web. 13 Apr. 2010.

"Membership of the Security Council." United Nations. Security Council. 13 Apr. 2010

Wikipedia contributors. "List of United Nations member states." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 14 Mar. 2010. Web. 13 Apr. 2010.

THIMUN. The Hague International Model United Nations. 2010. 13 Apr. 2010 <"http://www.thimun.org/">

Criterion C - Plan

I thought we had until the end of the year so I planned to create a website that may be a little overambitious to create in a month. However, it's always good to challenge myself and since computer programming is something I enjoy, I think I should be able to finish my website on time if I work once or twice over the week-ends.

Here is my tentative plan for the creation of WEBMUN:

(Click on it to see the larger version)

Design stage

From my three original ideas for a website, I realized I liked the second best (a debate website online). However, quick research on Google found that there are already websites like this. Since I don't want to simply be re-creating a website concept, I had to come up with something new. That's when I remembered that I had been looking for an MUN website online a while ago, and didn't find one.

MUN stands for Model United Nations and we hold a "conference" every year at our school. I also recently went to BEIMUN in Beijing and realized that though many of the delegates there love to debate, they don't always get the chance because conference travel fees are high. If I could set up an MUN experience online, this would give teenagers who like MUN a chance to exercise their skills more often. This could also be used as part of our ISU community to help students who have never done MUN before to get a first taste of it. Finally, some people like debating about real-world issues but lack the confidence to talk in front of a crowd. An online MUN could help with that.

Since most conferences are named as an acronym (ISUMUN, BEIMUN, AISMUN...), I decided to call mine one too - WEBMUN. I want the website to offer delegates the opportunity to debate both real-time and delayed times. In no particular order, here are the features I absolutely want in my website:

1. Information on MUN in general (debate procedures, researching tips, helpful links...)
2. Sign-up and login function
3. A number of separate committees with sign-up functions for countries and chair positions
4. Real-time private chatrooms for each committee
5. Private chatroom and inboxing for the drafting of resolutions
6. Discussion pages for each forum with options such as "Speak for this resolution", "Speak against this resolution", "Submit an amendment", "Motion to..." to allow for delayed debating
7. Informal discussion forum for delegates to get to know each other
8. Voting tool on each resolution

Here are the functions that I would like to implement but are not as fundamental, as some of them may be beyond my means:

1. Video chat options
2. Online resolution editor
3. Live newsfeed from the various forums
4. Regularly updated calendar with real MUN conferences

Creating your actual website

After looking at some bad websites, I looked at other lists highlighting websites which were both pleasing to the eye and easy to navigate. Many of these are what you would call "Photoshop" websites: a stylized background image and more borders are designed in Photoshop, before being integrated into the page using CSS code. It's a lot easier to create an image and just link to it, rather than try to create complex effects using code.

Talking about codes - it's good to know what makes a good website, but how do you create that website itself? The basic internet code is HTML, Hyper Text Mark-up Language. This code is rather simple and is interpreted by the browser, which returns the content with the basic formatting added by HTML. However, HTML is the earliest internet language and was consequently not adapted to formatting the page. It's possible to create complex layouts like that of this very nice website I found, Feed Stitch, by using HTML - but it's very hard, and might not look the same in all browsers. The other problem with using HTML to format your pages arises in bigger websites. If you want a 100 pages to follow the same layout, you are going to have to copy the same formatting code into every single one of these pages. This will make your code very messy and make it much harder to find errors in it.

For this reason, the World Wide Web Consortium (W3C) created a new language specifically designed to formatting text, called Cascading Style Sheets (CSS). CSS is recognized by all browsers. You don't even need to write in your HTML code a special code tag to indicate you are writing in CSS, as the browser will automatically understand. However, CSS is not usually written inside the HTML code but in an external page that is then linked to the HTML file. This makes your code a lot neater, as content and formatting are stored inside separate files. You only need to write one stylesheet and then link to it from all your other HTML pages.

A few years after HTML was developed, the W3C created a "new" version of HTML called XHTML which is overall very similar to the original. It simply is a slightly stricter version of HTML: all the tags must be properly closed, and written in lowercase. This is what good websites should be designed as anyway, so pretty much any neat HTML code is XHTML.

XHTML and CSS are content languages. This means that they display information for the user, give the user links to click on, change colors when you click these links - but that's about as far as interactivity goes. XHTML pages are basically text put on a computer screen. If you want your users to be able to change something, ask questions, fill in forms, etc. you will need other programming languages to help you.

Javascript is the most basic of these interactive web languages. Javascript can be integrated into an HTML page, or linked separately, just like CSS. While you wouldn't really be able to form an entire game or interactive page in JavaScript, there are many "under the scenes" functions it can perform: for example, send you the information sent in a form, store information about the user's computer in the form of cookies, show different versions of your webpage depending on which browser is being used...In the past, JavaScript was also used to make somewhat cheap effects like a trail of hearts following the user's cursor, but these practices have fallen out of use. The advantage of Javascript is that it requires very little bandwith, so it is often preferred to Flash when both are an option. Javascript is made up of functions, which can be called by any HTML element. For example, the click of a "Submit" button may call the JavaScript Submit function which will send it to some other web address.

The next step is PHP pages. PHP is a server-based web language, which means the code is translated from the server, not from the user's website. This makes testing (and therefore learning) PHP a lot harder, but not impossible. Since it is server-based, PHP allows for more interactivity: you can store names, logins, passwords, etc. in MySQL databases and then use these to provide the user with really personalized content such as an online game, or a discussion forum. PHP also operates with functions, but it is strongly linked to databases. It is much harder to learn than HTML. Hopefully I will be able to master the basics of it in order to create my own interactive website!

W3 Schools. 2010. Refnes Schools. 26 March 2010 <"http://www.w3schools.com/php/php_string.asp">.