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">.

Bad website designs

For our second week, we started by looking at various websites and design principles in order to learn what makes a good website, design and content wise. Some of these design principles are quite straightforward - don't use too many flashy images, don't use too many frames, make sure your font color is readable...It seems that more often than not, web designers have a problem with using too much rather than not enough. Readers actually prefer a completely blank, plain page to a flashy one giving you epileptic seizures!

What seemed to be a little more hard to control was navigation. I read about a term called "Mystery Meat Navigation," which basically describes a website which looks like it has really great design but is really nearly impossible to walk through. One example of this was the Leo Burnett website, which was made all in flash and seemed really edgy and creative. However, half of the time when I clicked a link it brought me back to the homepage, or to a very small page I wasn't able to resize.

I really liked one of the statements I read: Remember that the people looking at your website spend most of their time on other websites. If you try to come up with a brand-new, snappy navigation that is a unique experience compared to the rest of the web - your visitors won't like it. Somewhat creative designs are good, but not if they modify every single rule of navigation people are used to. That's why it's generally a good idea to stick to elements such as headers, sidebars, etc. Most of the design principles I read recommended not to create entirely Flash-based websites, as these are all eye candy, are hard to read and impossible to access to users with low bandwidth. I read the rule that you have 5 seconds to show some content on the page before the user gets bored and closes your website. I think this is a good number, though it might be a little longer for people with low bandwidth who are expecting it to take a while.

Another section I read about was making your site accessible to the blind, color-blind, deaf, paralyzed...many of the tips were small things that I hadn't thought about but which can make all the difference to these people. If you set your font-size, for example, it's impossible for the user to resize it and read it. It's better to use relative font measures such as ems. If you set your font to be size 0.9 ems, for example, it'll be a little smaller than the rest but you can still resize it. Another thing that is important for the blind is to make sure your links are descriptive, as often a special program will generate a list of all the links on the page and read them out loud, so the blind person can select one. But that's only useful if your links are descriptive: how do you know where the link "here" is going to take you if you can't read the text surrounding it?

I also went to another website with advice about web design, which was itself very well designed - Ungarbage. I learnt about a screen reading software called JAWS, which is the reference browser for the blind. Another of its functions is to read the names of all the tabs so that the blind person can switch. Once again, however, this is useless if your pages do not have specific, informative titles. Since JAWS is a free program, I think it would be a good idea to open my finished website with it in order to judge whether or not my website really is accessible to everyone.

Finally, I checked a website called listing faulty website designs, called Web Pages That Suck. While some of the examples were too obviously horrible to really teach you anything - for example, this Christian website with a moving background or this reference website on something quite obscure. However, I think that what I saw from all these website is that it's always better to follow simplicity over effects. If your page is a little too simple, no one will complain, but if it's full of effects, visitors will run away from it at the speed of light!

One last pet peeve of mine which wasn't listed on these websites but annoys me on a regular basis is member-only content. I hate having to join a website, which can take 5-10mn, without even knowing what is on it. I think most registration processes take too long - what really is the point of filling in your address, your zip code, and then confirming through two e-mails? I would like to keep the process as simple as possible on my website, if I have registrations.

Flanders, Vincent. Websites That Suck. 1996. 16 March 2010 <>

Kyrnin, Jennifer. "What Design Scares You? Reader Responses." About.com. 16 March 2010 <>

Shannon, Ross. Accessibility: Make Your Website Easy To Use For Everybody. 16 March 2010 <>

Lynch and Harton. "Sidebar: A List of Reminders." Web Guide. Pair Networks. 17 March 2010 <>

Marreiros, Mourylise. Ungarbage. 2007. 20 March 2010 <>

"Web Content Accessibility Guidelines. " 2009. W3C. W3C Networks. 21 March 2010

W3 Schools. 1999. Refnes Data. 21 March 2010 <>

Creating websites - why?

Today we started our new IT unit, creating websites. Mrs. Wilson had originally planned to create websites in groups and enter the annual Think Quest competition, but it turned out that we are not allowed to do summative group projects in Grade 10...we're still making these websites, but we'll be having our own contest. We will each be creating our own website from start to finish, on any topic of our choosing.

The internet is slowly taking over our entire lives. When I was younger, browsing the internet was just a hobby that I took up after school. Nowadays, I do nearly all of my research assignments online, I keep a blog for my IT grade and I was even internet-schooled due to the swine flu! As we saw in our last unit, more and more people are going from passive internet users to active content creators. It has become a lot easier to upload your own point of view on the internet, and this new trend is nicknamed "Web 2.0". More than adding a little to a Wikipedia article, however, it is good for teenagers like us to actually take initiative. Creating an entirely new website develops our risk-taking, writing, critical analysis skills: all competences that we could really use in our daily lives. Designing a website is not only an initiative project, it can also help people express themselves. When chatting to friends online, or participating in web boards, I'm usually more outgoing than I am in real life. For shy people, creating a website can really be a way of passing on information that may be useful to others but that they were not eager to share. Finally, websites make us understand we are part of a global community. Anyone will be able to access our finished sites, whether they are in the classroom or in Brazil! The internet breaks distance limitations and gives us a chance to inform not only the people we know, but the entire planet.

Criterion E: Evaluation

This was a very short project, but as usual we followed the design cycle. At the beginning of the unit we decided on three design specifications for our unit:

1. Every sentence must have a citation.
2. The text must be grammatically correct.
3. One week after our upload, there should be no need for anyone to edit our text.

We looked through our article and checked that every sentence had a citation for a valid source, which was the case. As for the grammar of the text, we asked Kyu and Sonya to look through the section we edited and none of them found any grammatical errors. We can't check our last section as one week as not passed yet, but so far no changes have been made and since none of the people we asked found any edits, it is likely there is no need for changes. Wikipedia is mainly used by students or people who don't know much about the subject, so the fact people who didn't know about the Gaia hypothesis at all were able to understand what we wrote is an indicator our project was adapted to its audience.


Criterion A
Suugii and me split up the six questions of investigation and each set out to research three. She was sick on the day we were supposed to do this, though, so we decided to reschedule and separately answer all six questions. Looking up how Wikipedia worked was interesting and I spent a lot on this - the organization of it all was quite impressive. The problem was that I had a lot of time to work on my three initial questions and quickly rushed through the other three that I wasn't planning to answer. I think my understanding of Wikipedia could have been better if I had spent more time on it. This didn't really affect the rest of our work on this project, but I think it might have had an effect on my general perspective of wikis.

Since she was one class behind me, Suugii was still completing her original six questions while I started work on the the next part of investigation, designing a method to find inaccuracies. While answering the questions, I had learned about something called template messages. Anyone browsing Wikipedia can add little indicators to sections, such as "This section does not cite any sources." This seemed just the perfect solution for finding inaccuracies, so that's what I suggested we use. I think it was indeed a good idea but we didn't really take into account the massive size of Wikipedia.

We thought we'd just look at one sub-section of the site, go through all the pages, find one with template messages and edit it. Except that a sub-section was about...5000 pages. We finally ended up browsing a sub-sub-sub section, which had a more reasonable amount of 50 articles. Our technique for finding inaccuracies was also problematic in that we were really looking for inaccuracies others had already spotted. How do people find the pages to put template messages on in the first place? We also ended up editing a page that was somewhat interesting, but not something which we would be considered experts in. That gave us much more work than planned, and maybe our project was a little over-ambitious. Most groups simply changed one fact, while we went for a whole section which turned to be full of subjective errors, harder to verify than a number. It might have been a better idea to think more about our method for finding inaccuracies, as this really affected the rest of our project.

Criterion B
Once we had researched our topic in some detail, it was time to actually edit the page itself. Many of the words in that section of the article seemed to be somewhat biased, so giving the article a more neutral tone was the first thing that I did. I then changed some of the numbers, words, and overall I think I came up with a good Wikipedia edit. However, I think I sometimes thought too much about grammar and the exactitude of my statements and neglected the actual writing style. My edits made the text somewhat dull to read - very short sentences, only containing true facts presented in a neutral manner, but still not very interesting. Finding a balance between the cold hard facts and the flow, the creative side of writing, is something I often have trouble with. For this project, I leaned too much towards facts and thinking a little bit about the actual reading value of what I wrote would have improved our edits.

Criterion D
Creation was an incredibly short part of this project. It was basically just about putting our work on Wikipedia, and editing it to follow the general layout of the website. Suugii and me didn't know much about how to use wiki code, but it wasn't very hard to get. I wish that we had spent a little more time learning about it, though, so maybe we could have included more advanced formatting such as pictures, italics, links outside of Wikipedia...but then, we were only editing a small section of a page. Something we did that was good in my opinion was writing about the edits we had made in detail, so that other contributors to the page know what's going on. Not much to say on this part of the project, except that it went pretty well.

Overall
This was a small unit but it got us to grips with Wikipedia in general. I would say that in general, our project was a little over-ambitious - changing just one sentence would've been fine, and would've given us more time to learn about Wikipedia itself instead of doing research on an obscure scientific theory. On the other hand, I did learn a lot from the research itself, which showed me that Wikipedia's uses go beyond compiling information for everyone to learn: those who edit the articles are also learning a lot themselves. This encyclopedia is the kind that is useful to the entire society, as both contributors and users (who are very often the same person) can gain general knowledge from it.
As for my own part in the project, I think I did pretty well but didn't do enough teamwork. Because of one missed class at the beginning of the unit, Suugii was constantly just a little behind me and I didn't feel like waiting a class for us two to be at the same level. Instead, I ended up doing a lot of work individually when it would've been more interesting to work on it as a pair. Waiting just one class would've made a large difference, and that's something I need to think about in case this situation ever presents itself to me again.

Uploading our changes

After finishing our design stage, Suugii and me were ready to put it up on Wikipedia. We logged on under the ISU account, and for the first time clicked the "edit" link. I was expecting the code of the Wikipedia article to be very neat, but it was quite hard to understand at first. There were messages, comments and tags all over the place. After quickly reading through the article, we figured out how most of the code worked:

Section titles were written like this: ==Section Title==
Links to other articles like this: [[Other article]]
References like this: Reference information
Template messages like this: {{Template message}}

We removed the template messages and added references as well as links. Once we were done, we uploaded our changes which were instantly put on the web for everyone to see. Even though I've been using Wikipedia for years, this was the first time I added something to it! You can see our changes to the Controversial Concepts section here.