Tuesday, May 25, 2010
Criterion E - Evaluation
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
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
Monday, April 12, 2010
Chat room, forum and login options
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
-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
-
Measures to combat discrimination and social isolation of the disabled
-
Ensuring the right to food for all, without discrimination
-
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
Here is my tentative plan for the creation of WEBMUN:
(Click on it to see the larger version)
Tuesday, March 30, 2010
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
Tuesday, March 23, 2010
Creating your actual website
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">.
Tuesday, March 16, 2010
Bad website designs
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 <>
Monday, March 8, 2010
Creating websites - why?
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.
Monday, March 1, 2010
Criterion E: Evaluation
- Every sentence must have a citation.
- The text must be grammatically correct.
- One week after our upload, there should be no need for anyone to edit our text.
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
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.
Tuesday, February 23, 2010
Criterion B: Our edits
Here is our modified page which we have yet to upload. The text we removed is striked, what we added is in green and our explanations of why we did these changes are between parentheses in italics.
We also have a source for every piece of information, which we will footnote on the actual Wikipedia page. While changing this article, we came up with three design specifications which should show us that our edits really are making the article better. These are:
- Every sentence containing some sort of information should have a source.
- The edited section must be gramatically correct.
- One week after we upload our edits, our section must not have been majorly edited, as there shouldn't be a need for it if we did our job well.
Tuesday, February 16, 2010
Improving Wikipedia
Our method is detailed below:
1. Go to the "Contents" page from the main Wikipedia page
2. Choose a category, and then a sub-category. You should be looking at a section containing about 50 articles.
3. Look through each article for template messages such as "The accuracy of this article is disputed," "This article's point of view is disputed," "This article does not cite any references or sources."
4. Check each article or ideally, section, which is marked with a template message. Look up the information for that article/section on the Internet and in books. If you find an inaccuracy, rewrite the section. If you do not find any inaccuracies, simply add reliable sources to help improve the article.
Using our method, we decided to look up the "Environmental articles" section of Wikipedia. It was a controversial topic so was likely to contain lots of inaccurate facts, but the problem was that it was too big - over a thousand articles! These articles were however organized into letters, so we decided to check all of the articles starting with G, which was roughly 50 articles.
As we thought, many of these articles contained template messages, the most common being "This article does not cite enough sources." In many cases, sources were cited but in the wrong format, either linked or put between parentheses instead of footnotes. After some quick scanning, we eliminated all the articles which simply had one or two facts disputed or seemed too hard to research. This left us with about 5 articles, out of which we decided to follow the "Gaia hypothesis." It's a theory about the way living creatures on the planet interact, and the article seemed pretty biased. We decided to look at the Controversy section and try and improve it:
Controversial concepts
This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (May 2009) |
Lovelock, especially in his older texts, used language that has later caused fiery debate. For instance, many of his biological critics such as Stephen Jay Gould and Richard Dawkins attacked his statement in the first paragraph of his first Gaia book (1979), that "the quest for Gaia is an attempt to find the largest living creature on Earth." [19]
Lynn Margulis, the coauthor of Gaia hypotheses, is more careful to avoid controversial figures of speech than is Lovelock. In 1979 she wrote, in particular, that only homeorhetic and not homeostatic balances are involved: that is, the composition of Earth's atmosphere, hydrosphere, and lithosphere are regulated around "set points" as in homeostasis, but those set points change with time. Also she wrote that there is no special tendency of biospheres to preserve their current inhabitants, and certainly not to make them comfortable. Accordingly, the Earth is a kind of community of trust which can exist at many discrete levels of integration. This is true for all multicellular organisms which do not live or die all at once: not all cells in the body die instantaneously, nor are homeostatic "set points" constant through the life of an organism.[citation needed]
This part contained a lot of weasel words (unclear statements), seemed rather subjective and did not cite any sources so we thought it likely to find a factual inaccuracy in it.
Wikipedia contributors. "Gaia hypothesis." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 18 Feb. 2010. Web. 23 Feb. 2010.
Tuesday, February 9, 2010
Investigation - how does Wikipedia work?
Where does Wikipedia get its information?
Wikipedia gets its information from pretty much any internet user out there. Anyone can log on and add to the pages: where they get the information they add is very varied. Some get it from other websites, books, lectures, personal experience...the latter is obviously not considered as good as other sources, as Wikipedia tries to stay neutral and personal opinions tend to be biased. After every statement on a Wikipedia article, there should be a little number that links to a footnote at the bottom of the page.
Who is in charge of deciding what goes into an article and what gets removed from an article on Wikipedia?
Basically, anyone can add to an article or remove from it, so all users are in charge of this. However, this can easily lead to what Wikipedia calls edit warring: this is when two or more users disagree on what should be on a page, and repeatedly revert the page to the last version that they wrote in order to cancel the other users' changes. The rule is that if someone reverts the same page over three times in 24 hours, they must be reported on the "Notice Board." This is a page where anyone can add the names of people who they think are violating the rules of editing. The administrators of Wikipedia, users who actually work for the website and are payed for this, regularly check the Notice Board and the infractions listed there. They can choose to ban the users for a period of time, or simply issue them a warning.
If there is a debate about whether a particular bit of information should or should not be included in an article, what is the process for deciding?
Every page on Wikipedia contains a "talk page:" if people don't agree on what should be on a page, they should discuss it on this page until they reach a consensus. Usually, most problems get settled through simple discussion but sometimes the dispute escalates. In this case, anyone involved in the dispute can ask for a mediator on the Mediation Request page. Mediators are a group of users on Wikipedia who have been given this role because of their strong contributions and their desire to help make the website better. They are voted each year by the users of Wikipedia and form the Mediation Committee.
After someone makes a request for mediation over what should be on a particular page, a mediator will supervise a discussion with everyone on the talk page and decide what should be on the page after a few days. This discussion is final: if one of the users keep adding or removing content when the mediator decided he/she shouldn't, the user may be banned.
If there continues to be dispute over the article, which is often the case with controversial pages such as "Abortion" or political views, the administrators of Wikipedia will usually lock the page. This means no one can edit the page without it going through the administrators, so only helpful content will be added. Of course, the reverse side is that helpful edits take a long time to get online, as the administrators have to check every single one. This is why only really controversial topics are locked.
How reliable do you think Wikipedia actually is?
I already thought of Wikipedia as a rather reliable resource, but after completing this first part of my research I think so even more. It's not just a website where people "add" information that may not always be correct; there is actually a fully-fledged editing process, and people who are dedicated to removing the errors on the website. On the discussion pages I looked at, the discussion was polite and the users were really trying to agree on what they wanted to put on the page.
How would you know whether a particular article really is accurate?
It's really is a matter of personal judgment, in most cases: if the article is well-written, doesn't use "weasel words" that are intentionally vague such as "Some people say...", seems pretty neutral in tone and doesn't present any crazy information, you can usually trust it. Less qualitative factors that might help you decide if an article is reliable would be:
- Are there lots of works cited? Are these works reliable sources such as books, government publications, etc.?
- Have there been lots of edits? Trust the "wisdom of the crowd" - if many people visit this article, chances are that it's getting better by the day.
- If you check it up on the internet, do the facts seem to match up?
How would you go about discovering whether a particular article contains inaccurate information?
The most certain way would obviously be to look through the entire article and check up every fact against some trusted sources, such as books or encyclopedias. This would result in a very accurate encyclopedia, but more often than not you won't find too many errors, so it might be a waste of time. It's better to quickly look through the article, and only search statements that seem a little "off" - there's more chances that people will lie about the political views of an actor than his date of birth, for example. Wikipedia also has a built in manner of looking for errors called template messages. If you see a fact that doesn't have a source, for example, but don't have time to correct that, you could simply add [citation needed] next to it. This way, you indicate to other users trying to correct inaccuracies that they should probably look up this fact before other, less suspicious ones.
Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. 22 July 2004. Web. 17 Feb 2010.
Monday, February 8, 2010
Our own wikis on PBWorks
To create the wiki itself, I worked with Ha Young and Brooke. This was surprisingly easy: we just went to PB Works, entered my e-mail adress and a password. After that we were taken to another page which asked us how we wished to name our new wiki, and tadum - we had our own workspace. Of course, it was empty, but it was still surprising how little time it took to create one. Absolutely anyone can become the administrator of one, there's no identity check or moderation. In a way that is great because it allows anyone to enrich the web; on the other hand, there's something powerful about being anonymous on the internet.
After that, we copied the script of my fictional podcast on the wiki and let people change it, and put a little note at the top that asked if anyone could help us "improve the script"... to be honest, the edits weren't really aimed at making our script better but more at having fun. Here are a few of the not-so-helpful changes that were made (whatever is crossed was removed and whatever is in green was added):
Changes in reading
Name: Dorthella
Age:
Gender: Girl
Cultural background:
Education:
Hobbies,
Name: Dorthella
Age: 15
Gender: Girl
Cultural background: Dorthella lived in England from the time she was born to her twelfth birthday, after which she moved abroad to Mongolia. Culturally, she considers herself British, but she has travelled a lot and would like to believe she has an “international culture.” She is the second eldest in a family of three. Her little sister is turning nine and her older brother is in his sophomore year of university but she dropped out of high school because of a rare condition called "Uglymonia".
Education: Dorthella goes to ISU, but she has also been in a boarding school and a typical school back in Haiti. She isn’t sure about her career path yet, but is considering profesional boxing. She is somewhat of a good student, but has other interests like pole dancing.
Hobbies, interests: Dorthella loves reading and writing stories, as well as “hands and crafts” activities. I also llove shopping <3>
These edits actually did make me laugh at first, but I can see how in a more serious website such as Wikipedia people fooling around like this would be less than helpful. And even though most of the edits were negative, there were also some contributors that took it as their mission to rectify false information. I had people change SMS languages others had added to proper Englsih, others add indentation and such things. However, no one really helped improve the script's content or dialogue - they only changed the grammar.
I found out about all these different types of edits by going through the "Recent Activity" section, which provided a very helpful "Show Changes" function. Using it, you could see precisely which user changed what and when, and also revert back to any previous versions. That's what I did at the end of our unit, as n0ne of the changes were really helpful. I guess in this case the whole wiki side to our script ended up being pretty useless, and the idea of having everyone access the page was not beneficial to its quality.
However, we were also in a special context: we're all teenagers, and we knew we were editing the work of our classmates and friends. The people on Wikipedia are obviously more concerned about the quality of their work than we are. From this experiment, I would say wikis are a useful tool if there is someone behind to moderate the pages and make sure useless changes such as "PrincessGirl20391 was here! LOL!" are removed. But if the pages are simply left "out there" for anyone to edit, without another person behind supervising the information, there are more people who will be tempted to add silly edits than people who will actually improve the wiki. I think the main thing about a wiki is that it must be made of a community of motivated people. Teenagers would actually keep a page on a TV show or a book serious, for example.
Here are some applications for wikis our class thought of:
- Advertising
- Fan group
- Surveys
- Support groups
- Debates
- Writing a book together
- Keep a record of your conversations
Tuesday, February 2, 2010
Wikiality
Our new unit is about "wikiality", and this new form of websites wikis are. Wikis are websites that can be edited by anyone. They were created by an individual who might have put up some content, but mostly information is added by people using it. Anyone can click a page, on dinosaurs for example, and add information by simply clicking an "edit" link. They're a very convenient way of finding information as the text is usually clear and simple to read, and because of their nature they are regularly updated. As time goes, there are more and more wikis, usually FAQs for websites.
But the most famous out there is by far Wikipedia, the online encyclopedia. This huge website contains tons of information on the most various topics, and is written just like an encyclopedia. There's always a large debate on whether or not it is a reliable source that can be used for school work. Wikis can be edited by absolutely anyone, so people are often afraid that the information you find on them might be wrong. It's true that any internaut out there could write a new page on Wikipedia without having any knowledge of what they're writing about, and give you false information for your research. But a study demonstrated that the percentage of errors on Wikipedia was the same as that of the Encyclopedia Britannica, considered to be one of the most reliable encyclopedias out there! So...can it be used as a reliable source?
This is what we will be trying to decide throughout our new unit, by examining various Wikipedia pages looking for mistakes on them - and correcting those mistakes to make Wikipedia a better resource. All the while, we will be able to evaluate how many errors really are on Wikipedia and how often they are corrected, to make our own opinion on whether or not wikis are a reliable source. The way we view information is changing as fast as the Internet is changing, and Wikipedia is most likely going to be an important part of our future, so it is important we find out more about the way it works. We can then help build a better, more reliable internet, and a more convenient way of sharing information.
"Wikipedia Logo."NFJAW. Wordpress. 2007. 02 Feb 2009
Tuesday, January 26, 2010
Evaluation
Criterion A
Investigation was my favorite part of this project, as is often the case. I started off by interviewing many other teenagers to get a basic feel of how different people live adolescence. This reporter work was pretty interesting, but I’m afraid I did not get as much out of it as I could have. I tried to interview many different teenagers, but mostly ended up with girls my own age because I wasn’t comfortable asking vague acquaintances for their full feelings on life. I completed my survey over Facebook, so it was easier to keep a written record of their answers.
I think that the fact this interview wasn’t private made the people a little self-conscious about honestly answering what they thought of peer pressure, living abroad and what’s stressing about that, etc. It probably would have been easier for them to talk if I had made the interview anonymous, but I didn’t think of that at the time.
After completing these interviews, I actually listened to real podcasts to get a feel of what these sounded like. I had heard about podcasts before but had always thought they were just an online version of the radio, which I am not very fond of. I looked through iTunes and actually found a lot of interesting emissions on topics that interested me: photography, science, technology…I think I spent a little too much time on this part, though, than I really needed. After watching two or three podcasts, you already know pretty well what they are like – you don’t need to go through another four like I did. I probably should have spent more of this time researching teenage stereotypes or something like that.
Criterion B
Before starting design, I thought I had a pretty good idea of what I wanted to do for my podcast. Since I’ve lived abroad my whole life and I had asked my interviewees lots of questions about how that felt, I thought it would be interesting to do a podcast episode on that. Before I completely decided on that, I still asked other people for their opinions on the topics I had brainstormed.
None of the people I asked were interested in a podcast on the differences between living abroad and living in a mainland country. They all thought it was a little overdone – and well, I realized it was. The specific culture we live in is something we always talk about and it can be a bit of a boring topic. On the other hand, everyone thought that a podcast on teenage stereotypes would be interesting. I actually quite liked that idea myself, and I think teenagers can relate more easily to this day-to-day issue than another long presentation on living abroad.
Once I knew which topic I would do my podcast on, I started brainstorming designs I could work on. As soon as I wrote each of my designs, I thought it was the best one I could think of and didn’t think it was necessary to make another one, then I made another design and thought that one was great too. Finally, I decided on the simplest format – a script and interviews of various people representing each stereotype. That worked out well, but I think I should have made my script shorter as my podcast ended up being way too long. People tend to have a limited attention span, but I felt like I would forget so many things if it wasn’t at least seven minutes long. I should have asked for more opinions on the script at this point in time. The people I asked may have been too nice since they are good friends of mine, and it’s also hard to judge how long a page of writing will be once it is recorded.
Criterion C
My plan was pretty similar to the ones I usually do, and I think overall I followed it pretty well. The problem was that once again I planned too many things to do in each class. I know it’s better to push yourself rather than be completely unambitious in your plans, but it ended up being rather stressful as I hadn’t planned all the little gaps between what I planned to do – getting the microphones and setting them up takes time, even if “Interview three people” sounds like very little on the actual plan. I think my plans are more adapted to my speed of work every time, though, so this isn’t really much to worry about. Now that I know how these little details take up time, I won’t make the same mistake same time.
Criterion D
Since I had created my plan and my design, I actually started working on my project. The first step was to get people to interview, and Elise, Jiri and Kyu were happy to help. That was a good surprise because I was afraid not to get a single boy to interview, and I thought I really needed a little of their perspective since I had already interviewed so many girls for investigation. Their interviews were the first thing I did and they went well, but they were a little distracted by each other’s presence. It might have been easier just like in investigation to make this anonymous by not revealing their names in the podcast, or simply to interview them separately.
Once I was home, I recorded my own parts which took me less time than planned and turned out pretty well, as far as stuttering or bad pronunciation go. However, my sound quality was really bad. I can’t hear myself all that clearly at times, and there’s a lot of background noise. I should have bought an external microphone for this part of the project or come back to use the school’s microphones, because I think that really messes up the quality of my podcast.
After that, I assembled all of the recorded parts and created my final podcast, adding images. I really wasn’t happy with the images. Whereas my podcast sounded somewhat interesting, the pictures just made it look so amateur and not serious. I think it would’ve been better to use just one image for the whole thing, even if it seems like that’s less variety.
Finally, I think my podcast would’ve been better if I had actually uploaded it on Youtube as putting it on Blogger wasn’t the best quality I could have gotten. My sound was already not too great and this most definitely did not help with it.
Overall
As a whole, I think my podcast turned out alright but there are so many areas I could’ve improved in so many small ways, as I realize while I write this evaluation. First of all, I knew from the start that my sound quality was not too great from my fictional podcast, and I would’ve had time to buy an external microphone. The problem was that I kept forgetting about it until it was too late. I like my script and I think my podcast topic is really interesting to many teenagers, even if there were lots of things I could have improved. In my case, I think the content of my podcast was good but the actual format not so great. I could’ve improved it by using less pictures, better sound and a better uploading website, as I said just before.
To make sure that my judgment was completely fair, I asked other people for their opinion on my podcast following the test I had set myself at the beginning of the unit.
- Ask a number of people what they'd expect to see on a podcast about teenage stereotypes, and compare it with what is actually on my podcast
- Have 3 people listen to my podcast and rate it from 1 to 5 based on interest of the theme, interest of the script, sound quality, pronunciation and overall.
For the first test, I asked Elise, Suugii, Binderyia, Bilegt, Kyu and Brooke what they'd expect to see on a podcast about teenage stereotypes. Here were their answers, and whether or not these things actually are on my podcast:
Elise
- Specific stereotypes - Yes
- Interviews - Yes
- Pictures - Yes
- Background information - Yes
- Solutions - Half
Suugii
- Not too formal, funny - Half
- Entertaining information - Half
- Slang words - Yes
- Interviews - Yes
- How to deal with stereotypes - Half
Binderiya
- Pictures - Yes
- Stories of teenagers - Yes
- Background music - No
- Adults discussing teenager stereotypes - No
- How teenagers want to grow up - No
Bilegt
- Not too formal - Yes
- Stereotype yourself - No
- In your own high school - Yes
- In your country - No
- In other schools - No
Kyu
- Interviews - yes
- Personal anecdotes - no
- Background of interviewees - yes
- Social relationships due to stereotypes - yes
Brooke
- Interviews - yes
- Opinions - yes
- Statistics - no
- Background information - yes
- Pictures - yes
Overall, I think my podcast mostly matched expectations as it had interviews, background information and pictures (what most people seemed to be looking for.) However, people also had many other interesting suggestions I forgot to include in my podcast. I particularly liked the ideas of statistics (I could've realized a poll of some sort in my class), background music, comparisons between stereotypes in our school and other schools, and more "solutions" to stereotypes. I think most teenagers don't need that much background information on stereotypes - they know what they are. Perhaps having more solutions to the problem rather than exposing it could have improved my podcast.
For the second part of my test, I asked Sonya, Elise and Ha Young to listen to my podcast and give each criteria a rating out of 5.
Sonya
Interest of the theme: 4
Interest of the script: 5
Sound quality: 3
Pronunciation: 5
Overall: 4
Elise
Interest of the theme: 4
Interest of the script: 4
Sound quality: 3
Pronunciation: 5
Overall: 4
Ha Young
Interest of the theme: 5
Interest of the script: 5
Sound quality: 3
Pronunciation: 5
Overall: 4.5
From this final test, it seems like most people did agree with me on the general idea that the content was better than the format itself, as they all gave a rather low grade for the sound quality. I would even have given something lower for sound, but I suppose I may actually be a little biased as I keep thinking my sound is terrible whenever I listen to my podcast and I can’t focus on anything else.
It was great to see that other people enjoyed my podcast, and in many ways seemed to like it more than I liked it myself. My friends who listened to it said it made them think about stereotypes themselves, which is what I really wanted to achieve with this podcast. We teenagers often think we understand ourselves but I’m not sure how much that is really true. It’s impossible to make a podcast covering all aspects of adolescence, but by making and listening to podcasts each talking about one of these multiple sides to our teenage years, I think we can understand ourselves better. It helps to be able to make sense of this giant mess our thoughts are in this time of life, and it helps even more to see that we’re not the only ones feeling that way, as I realized when listening to the others’ podcasts. Everyone is confused about who they are; everyone has these same problems with stereotypes and other aspects of being a teenager. I’m glad I understand my own better, as well as the trouble other teenagers go through.
My final podcast
It took me over ten technology classes to simply make one podcast episode, and it wasn’t even all that long. I can’t imagine the amount of work that needs to be put in by those running Muggle Cast, for example (a nearly 2 hours long podcast published every week.) As with many things, listening to a podcast is a lot less time consuming than recording one! Overall, there are many things that could be improved in my podcast but I believe it turned out pretty fine. I'm glad to be finally done...
In case the video above is really of a terrible quality, I also uploaded the original file here.
Monday, January 25, 2010
Process - recording the podcast
The recording of the podcasts actually went well. The sound was not as bad as I expected, and I think my interviewees felt freer talking outside the classroom. However, their mutual presence was still a bit distracting, and sometimes I had to push them to develop their answers to the questions. Here is what I asked each interviewee:
• Have you ever been stereotyped? If so, as what?
• What did you experience because of these stereotypes?
• Do you think the stereotype does apply to you?
• Do you stereotype other teenagers? Do these impressions usually turn out to be right or wrong?
I was happy with the unscripted interviews because all three of my classmates gave very different, interesting answers. They were also quite honest in admitting they did stereotype other teenagers, and actually thought that often stereotypes turned out to be partly true. The only problem with the interviews was that recording them took much longer than planned. I didn’t have time to record my own parts or Sonya’s part, as I had planned.
I finished recording at home, but I think my own built-in microphone is of a lesser quality than Elise’s. My voice was a little hard to hear every now and then. I asked my sister to record the part I had planned for Sonya, and I hope her young voice is not too noticeable in the podcast.
Once I had all of the parts, I assembled my podcast into a small movie using pictures I had found on the internet for stereotypes. Some of the images were very striking. I particularly liked a series of photographs that went “I die my hair crazy colors so I must be an attention seeker,” “I’m Asian so I must like math,” “I am a person so I must be stereotyped. Overall, though, I felt as though the images added something very amateur, not serious, to my stereotype, and made listening to it less interesting.
"Recording sign on black background." Kompressor Studios. 2007. 26 Jan 2010
Process - writing the script
Once I had decided on how I would make my podcast, the next thing I needed to do was write the script for my podcast. I had already made a vague layout of the way I wanted the podcast to go, while I was designing it:
- 2 or 3 seconds video shots of various teens saying "Hello. I'm a jock. I'm a nerd. etc. etc. etc." (Scripted)
- Switchover to myself on video, explaining how many teenagers are categorized into groups, a fact that is accepted as "common knowledge" by most teens (Scripted).
- Quick interview of people defining themselves as belonging to a certain stereotype and how their daily life is affected by this characterization (Unscripted).
- Switchover to myself, explaining how many teenagers don't fit inside any of these groups which are often more of a fashion statement than a way of living (Scripted).
- Short scripted interview of someone who believes they don't belong to any stereotype, and who thinks many other people don't either (Scripted).
- Credits for all the people who were interviewed.
Writing the script was then rather easy, especially since I had a lot of ideas on the subject of teenage stereotypes. I used Word and simply wrote all of the scripted parts you can see above. I had planned to do this during one class period, but it took me a little longer so overall I used about two technology classes.
My next task was to find people to interview for the unscripted interviews, and one person to read out the scripted interview. I wanted to focus on how my age group experiences stereotypes, so I asked those of my classmates who I thought were most likely to be stereotyped. Not everyone accepted, but Elise, Jiri and Kyu agreed to being interviewed about their respective stereotyping experiences. I was happy about that, because as we are a majority of girls in the class I was afraid I wouldn’t get any opinions from boys, but that turned out fine. Sonya agreed to record the unscripted part for me.