CSc 498/499
Capstone Design Project

Goals from last week:

• Begin designing prototypes
• Email Linux guru regarding embedded window
• Categorize commands for first module and begin some content

I have begun to tackle the first prototype design. This has turned out to be harder then I thought. So far it looks really bland, and I have no idea what to do with it. I've told myself to keep it simple, but at the same time, I need to make it interesting enough to keep a user's attention. For now, a Cascading Style Sheet will have to do.

I'll need to brainstorm some non-obtrusive graphics later on. From what I have gleamed from the paper on making tutorials, I need to chop up my lessons into 15-minute chunks for easy consumption by the user. Each chunk needs to be summarized in the beginning and again at the end. The beginning summary is meant to prepare the user for what's coming and to let him decide whether or not he wants to continue on with the section. The closing summary is to let the user review what he has learned one last time before either quitting for a time or moving onto the next section. There should be button that will bring the user back to the beginning of that lesson if he doesn't feel confident with the information presented in the lesson. A "Save Progress" button would also be a good idea so the user has the option to save the location where he left off and later recall that location.

The email sent to www.linuxsurvival.com was replied to. Here is what was said in a nutshell:

• He doesn't believe it to be worth the time to reprogram Linux into an applet, so he started a company that provides a Linux account for IT training companies
• If I still want to try to write the Linux embedded window, he can't think of anything other then Java to write it in
• He created the "modules" in separate windows so to have more control over each one. Apparently, opening an applet in a new window gives more accessibility to how the applet functions.

The way I read this email is that I should start brainstorming other ways of going about this, because it's going to be really hard to program Linux in Java.

Brainstorm: What if, instead of an active Linux window, after a user entered the correct information, a screenshot of what should be displayed appeared onscreen and the user continues on with the next question referring to that screenshot, and another screenshot replaces it after the next question is answered correctly. This eliminates any security hazards and any need for a working Linux window. (This is a big change in the project and will need to be discussed with Chris. But it is a good graphical + feasible way to interact with the user.) End Brainstorm.

Goals for next week:

1. Brainstorm some non-obtrusive graphical work
2. Add "ls command" tutorial section to the interface
3. Discuss with Chris the feasibility of the Linux window, and introduction of the screenshot idea
4. Abstract for the poster fair

• Goals that student tried to reach this week and are going to attempt next week are clearly articulated

• This is the right amount of detail. Enough detail is included in the 2nd paragraph to show how the prototype design progressed. But it doesn't go overboard. For example, the email referred to in the 3rd paragraph is summarized down to the key points. I don't want or need to see the whole email transcript.

• Justifications (reasons) are included regarding why certain design choices or changes were made. Having these written down helps tremendously (1) when you need to explain to someone why you did what you did and (2) when you need to prepare your final report and presentation. When designing your project, note that you might end up making some big changes, such as the one mentioned in this student's Brainstorm. That's perfectly fine and expected as long as you have well-thought-out reasons behind it.

• Your reports shouldn't flinch when it comes to acknowledging that certain goals weren't met this week. Welcome to the real world. Just be honest about it.

• This report has a "stream of consciousness" style of writing to it. That's fine. But so are many other styles: complete prose, bulletted "executive summary" lists, and lab-report styles are fine too. As long as it contains all the necessary info, I'm happy.