Category Archives: Technology

FIRST Robotics Retrospect

Posted on by
Reply

I don’t think I have mentioned on here that I have been participating in the FIRST Robotics Competition this year. We had talked about doing it last year when we finished InvenTeams and I was asked to join drafted. I had no intention of participating at the beginning of the year because I would be busy with college applications, scholarships, and other senior stuff I need to get done in order to go to graduate and go to college. In retrospect though, I think the last eight weeks have been pretty damn fun.

To be honest, I didn’t think we would be able to make a robot in six weeks. We knew nothing about robotics, didn’t have the proper tools, and the team as a whole seemed like a ragtag group of freshmen and sophomores who were just looking for some free food. Many people left after the first few meetings and didn’t come back. All I have to say to those people is that I understand why they left. We weren’t doing much in the beginning, but I feel the need to say that they missed out on what I truly believe is one of the most unique experiences you can have in high school. Every school has football, basketball, swimming, mock trial, band, etc. but not every school has a FIRST Robotics team. Not everyone has the opportunity to build a robot in six weeks and pit it against other robots in a competition.

Team 2542 Go4bots

Team 2542 Go4bots

To the people who stuck with the team through all six weeks, I couldn’t be more proud of you guys. I didn’t think we could do it, but we pulled through. We had a working robot by the end of the competition. That’s not to say there weren’t problems though. There were a lot of things the team could have done better, myself included, but for a rookie team, I think we did a phenomenal job.

Our robot wasn’t quite finished when we shipped it off to the Memorial Coliseum. Fortunately they give you an entire day before the competition to get your robot into working condition and do a few practice matches. We didn’t get our robot ready in time to compete properly because we were all racing to get our robot to pass safety inspection. We didn’t actually pass until the morning of the competition and we did not get to test for problems. All day Friday, our robot suffered problems ranging from power issues to drive train failure. What impressed me while I was working on the robot was that no one gave up despite the robot having failed five times in a row while in competition—sometimes the robot didn’t move at all. The team’s resilience and determination and clever improvising impressed me more than anything else. Also impressive was everyone’s willingness to help. Despite being in competition, all the teams were more than willing to help other teams get their robots into working condition. Special thanks to the Team 1359 Scalawags for giving us a tremendous amount of help.

I was the driver for our team, so I didn’t get to watch much of the semifinals and I was too focused on driving the robot to notice the crowd. During the finals though, I can say with confidence that the crowd had enough energy to rival anything I have seen at a high school basketball or football game if not surpass it. Some team actually started a mosh pit that I might have joined during a six minute timeout…

It actually kind of saddens me that I won’t get to be part of next year’s Robotics team since they have a lot more experience and knowledge now. I suppose there will be other interesting things to do in college, but I still wish I had another year to do FIRST just to show what Gresham is capable of. Maybe I’ll comeback to mentor next year’s team. If not, I have faith that it will do well in FIRST, InvenTeams, or whatever program they decide to do next year. Rock on.

I Hate Misleading Progress Bars

Posted on by
2

I was installing Autodesk Inventor the other day. It went pretty smoothly, though it took an ungodly amount of time as CAD programs like Inventor do—I think SolidWorks took even longer. But one of the things that annoyed me was the misleading progress bar. Like most program installations, Inventor has a little bar that fills up as the installation progresses. Except this one filled up more than once.

The entire point of a progress bar is to let the user know how much longer he or she has to sit around waiting. Having the bar fill up and then restart and fill up again defeats the entire purpose. There was no way for me to know how long I had to wait before I could use my computer again besides the broken progress bar that served absolutely no purpose other than to give me some sort false hope of going back to work soon.

Inventor is not the only program I’ve used that does this either. This has been a long time peeve of mine that drives me up the wall sometimes during really long tasks. If a progress bar doesn’t accurately show how far a process has gone, than it’s just a useless progress bar that should be replaced with a more useful indicator.

You could argue that the progress bar is there to show the user that the process is working and hasn’t frozen and died. But there’s a reason why it’s called a progress bar. When a user sees a bar filling up, he expects it to be an indicator of how far a long a process is and how much it has left to go. A good example of this is the WinRAR‘s progress bar when it’s creating an archive. The top progress bar does in fact fill up several times, but that’s because it shows the progress for each file being archived and it tells the user this—no deception there. The bottom bar fills up once, and only once, to show the progress of the archive as a whole.

WinRAR Progress Bar

If you want to let the user know something is simply working, make an animation. For example, when you’re burning a disc in Nero it shows a little animation of a file flying into a disc. It also has a progress bar, but it actually works. Some programs are really stuck on bars though and that’s okay if you do it right. Take the Flock splash screen for example.

Flock splash screen

These are called indeterminate progress bars, but I like to call them busy indicators or animations. It has a bar, but it’s not filling up. It’s more like a worm racing across a bar. Windows XP does the same thing on its boot screen. What does this accomplish? It tells the user that the task is busy working through the use of motion, while not deceiving her into thinking that there are x minutes left to go.

I’m no usability expert but I’m pretty sure one of the goals is not to confuse the user. If there’s going to be a progress bar, make sure it works. If it doesn’t, then either don’t put one, or clearly make it a busy animation. A progress bar and a busy indicator are two very different animals and deserve to be clearly distinguished.