Website Team

Hey Chief Delphi,

So I graduated from my team as the only website person. As a result of that I am now the mentor for my team’s website Team. I have a few students interested, so I will start training them soon, but I need advice from other mentors/Website team leaders.

I want it to be fun for them so how can I make building a website fun?

What are some tips you would say that would contribute to a successful, award winning website? (Yes I know of the criteria on the first website)

How do you or your students run the meetings and do you have a group hierarchy?

Any help is appreciated!
-Kevin M
Team 675

I work on Team 1124’s Website and we won Best Website at the CT Regional. I’ll try to help as best I can.

It would seem to me, that the idea of “fun” usually arises when the student is either really interested in a certain part of the design/building process or if there is some really cool aspect of the website. For example, I like the experience of writing code and seeing my code do something cool/productive. Having that coupled with the idea of building our own custom written CMS really kept me interested in the project, so much that we’re probably going to open-source it sometime soon. Also, remember to keep the various students interested as much as possible, as someone without any work to do will most likely not be having fun.

Of course, like you said, to win an award, you need to follow the award criteria and do well on that rubric. As for general advice for making a good website, just make sure to keep it simple and try to keep the website-itself as out of the way as possible. By that I mean to make it feel natural to use, and to not have anything outwardly “annoying” the user and detracts or distracts from the main experience.
As for things you should definitely have, I would make sure you have an event calendar (Google Calendar is good, if you don’t want to custom code one), plenty of information about your team and FIRST (see examples here, here, and here), a photo gallery (example), some news about what the team has been up to (example), and some resources for other FIRST teams and your own (i.e. files and documents, programming tutorials, other how-tos, etc). Also, W3’s HTML Validator can be a useful tool, as well as the CSS Validator. If you need resources for learning PHP (my recommended scripting language), check out this thread.
Now, from a webmaster’s point of view, you can either use a CMS (like Wordpress, Joomla!, Drupal, a custom built one, or some other one) or you can hard code your own HTML. I’d recommend doing a little research into the difference between them, starting with this thread and this thread. Personally, I like our custom written CMS, but that’s not for everybody. You should choose what works best for your situation.

I’m probably a little less help here, since our Website Team is a small group (3 people without a knowledgeable mentor), and there’s less of a hierarchy to it. We just went off on our own and divided up the work among us and got it done. However, I would suggest that the head mentor (you) and whoever becomes the webmaster (student head) work to divide up responsibilities and come up with goals and responsibilities for the different people involved. Remember to keep it fun and make sure people have something to work on.

Best of luck to you, hope you design a great website. If you need any help or have any other questions, feel free to ask me and I’ll do my best to help.

As a fellow programmer, I agree with Plnyyanks statement of that it is fun to see ones code come to life on a page or on the robot. You probably create the website using HTML or PHP, and those are both great ways to learn how to program in the robot languages (C++ and Java) and people who want to learn how to code will be interested in helping. To make the coding fun, you could create a challenge of who can make the best page, the competition will help them advance in their skills. When I first learned HTML and worked on the team website, I found it fun to learn how to do new things (make a fancy media page, float pictures to one side or the other, etc.) and just to make the website the best that it can be.

Hope this helps, and good luck organizing your Website Team.

I can’t say for sure this would win any awards, but here’s where I might start. Look at a website that specifically tries to appeal to everyone, and understand why they make the design decisions that they do. Unfortunately, for a lot of typical sites, the design is driven by the desire to sell something (advertising perhaps). That’s why I’d say Wikipedia is the best for this purpose. They’ve even got guides on how and why they format articles in particular ways—and a lot of their policies are guided by compatibility and accessibility.

So, for example: the site must fail gracefully. Go ahead and use fancy features, as long as there’s an alternative. For the most part, don’t even prompt the user—when something goes wrong, just switch to the alternative and give them the content.

Support old browsers and mobile browsers. A tasteful notice about degraded content is fine, but certainly don’t interrupt the user with a modal dialogue box.

Structure it in a way that allows alternative access like screen readers. Wikipedia has an interesting take on formatting for blind users—they prefer accurate metadata in their images, so that screen readers can say something useful about pictures, rather than reading HTML tags aloud.

Make it fast, and keep it available. Nobody wants to wait for content. This means picking a good web host who will devote the appropriate resources to keeping the site up.

And don’t require Flash. Especially not for a splash page. Just forget about that. (With mobile platforms being quite popular, and as ever, a significant minority unable to use it for technical reasons, and plenty of alternatives available, why bother with something like that?) It’s alright to use Flash for video, but failing gracefully is the key. Maybe offer a link to the audio as well, so that the content is still accessible without video.

Content is king. If the site is nice, but empty, your chances will be reduced. Make the site useful, and something people naturally want to visit, and the website judges will naturally appreciate this.

Finally, plan for contingencies. Sooner or later, you’ll move on. Make sure it’s obvious to the next webmaster how the site operates. Keep records and document your conventions, databases, passwords, etc… Also, keep occasional backups. It’s boring, but necessary. (You’ll look like an idiot if you have to tell the team, “sorry, we lost everything…I’m going to go try the Wayback Machine”.) Your webhosting provider may be able to arrange something for you.

(By the way, I can claim a familial connection to a whole slew of website awards, including the big one, because my brother designed and webmastered 188’s website for a number of years. Some of this draws upon what worked for him.)

I’ll be going into my fifth year on the team and I have been the student lead on our website since I’ve been on the team. We’ve been fortunate enough to win a couple of the Best Website Awards, including at the Championship this year. I also work for Envato, as a marketplace author on their site, ThemeForest and I am also starting a media company, Propel Forward Media, to provide a range of services including website development.

Do your best to find students that actually want to learn about website development. I’ve had the most success with kids that were already interested in the Adobe suite or already use the computer heavily.

And, be a fun group. Be somewhat laid back, friendly, and fun to work with. Get things done, but don’t be pushy.

I found that having an award-winning website isn’t always looking at the rubric and checking off each item as you complete it. Sure, that’s what you should to do, but, to set yourself apart, you should be unique. Here are some ideas that judges really liked on our website this year:

We don’t have much of a hierarchy other than student sub-team leaders, sub-team mentors, and the sub-team students (see here).

I think the changes we made this year, though, were key to our success versus previous years. Before, our website team was pretty exclusive and off on our own (it was primarily me).

This year, I really benefited from the help of others:

  • Our video team created the “What is FIRST to Us?” video which really helped a lot!
  • I created the site this year using Wordpress, and a lot of students helped with editing and creating all the student and mentor biography pages. Our team manager also expanded our team history page and timeline.
  • We had several brainstorming sessions on how we can improve the website and a lot of good ideas came from people that don’t necessarily work on the website (ex - Alumni spotlight, “What is FIRST to Us?” video, ect).
  • Other guys helped scan old pictures and upload them.

Why do you need to “make” it fun?

In my view, a mentor’s job is (when possible) not to make a program or a plan for the students, but instead to facilitate the students, let them drive themselves, and give them access to the tools and the knowledge they need in order to learn and create.

If coding isn’t fun, there are ways to build a site without coding; if design isn’t fun, there are ways to build a site without designing (not that I would endorse that path myself).

I would like to agree with Dan. The students will have fun - if they don’t, then they shouldn’t be building a website. I honestly think PHP is a really fun thing to write.

Here’s how I run my web meetings (with myself, seeing as I’m my team’s only webmaster): I sit down at the computer. I open up a file named “update.txt” that has a big list of everything that I still have left to do. I pick whichever one I feel in the mood for. I do it.

Of course, that approach definitely will not work if there’s more than one person.

My recommendation to you as a mentor would be to sit back and let the students do everything. When they start pulling their hair out because their php if statement evaluates to true every single time, even when obviously false (somebody used “=” instead of “==”, probably), you step in and point it out. Offer friendly suggestions about how to make code better, how to design well, or just completely new ideas - but let them do all the work.