Being the starting week, I'm spending it mostly getting things set up. Steve (the grad student I'm working with) has helped me get a local account on my computer (... named stimpy...), as well as on the lab general computer. Having had my department account for over a year now, getting it set up is actually easy... the hard part is cleaning out my inbox, which has still received tons of messages, and hasn't been cleaned out since last year August. In fact, I had to spend a half an hour on Tuesday cleaning it out and saving large attachments sent to me, after getting an "Over Quota" e-mail. Embarassing. :)

Steve and I have set up a short term game plan in terms of things for me to do. Currently I'm working with (and playing with) Phidgets, and attempting to get them working properly with Java. Phidgets are, or will be, what the Creature is going to be made with, in terms of physical functionality. The most recent Java library to use for interacting with the Phidgets requires some tweaking of the basic examples they have on their website, and they have very little formal documentation on it, so it's been an interesting item to work with. At the moment, I've managed to get the basic examples working with the accelerometer, the rfid reader, and the servo (one motor attached), since that's all I have access to at the moment. I am also doing some Java review; Java Swing is what I'll be using for the summer, to create GUI applications that can be used to interact with the various software components of the Creature.

The week as a whole seems like it's been extremely busy. Yesterday we did a lab room move, and I'm now happily situated in the corner (albeit behind the door, so there's a very slight danger of getting whacked) instead of on display in the middle of the room. Later in the afternoon there was a MUX lab social, and I got to meet some of the other grad students who are part of the lab, if not actually in the room. Plus, I got some tasty junk food.

Apart from doing this, I am also starting up a part-time position, under my mentor, Karon, and also under another faculty member, Joanna McGrenere. There's a lab/studio on the third floor of the building (I'm on the fifth) that needs to be filled out with equipment before the summer's end so that it can be used as a lab room in September, and I've been recruited to assist as an "undergraduate consultant", or so the budget sheet says. As I'm starting with that as well, I'm likely to get very busy very soon.

Even more so, I'm also volunteering with the Jade Project's GIRLsmarts workshops. I'm one of the coordinators for the cryptography activity, and there are lesson and project plans to make, paper crafts to cut out and glue, and worksheets to written. The workshops are two Saturdays (a third if there's enough enrollment) in early June, and are meant for grade 6 and grade 7 girls, to introduce to them the wonders of computer science. My activity is for grade 6 girls only, but at 8 girls per group and 5 groups per day, that's 40 girls we'll be teaching between 10am and 3:30pm. Last year was fun (I was creating the Lego Mindstorms activity), hopefully this year will be just as good.

Top

Am working on getting the Phidgets to display their values for me, using Java and the Web Service. I've managed to get all of the examples working with the new libraries, more or less, for the RFID reader and the accelerometer. Until recently, I haven't been able to fiddle with the other sensors, such as the sliders and the ministick (mini joystick), since the two interface boards are in use -- one is being used as a temperature monitor in the lab (apparently they called this lab the "CS Sauna" last summer... eep! I don't want to get boiled), and the other is in the Creature. However, I now have the Creature on my desk, and attached to it are two siders, one rotation sensor, and the ministick. The wires coming out of the little metal shell make it look rather menacing.

Through tweaking the examples, I've managed to get a GUI display of the values of the sensors. The interface kit (IFK) took a lot of thinking on my part, and then I discovered that the IFK keeps track of each sensor through an index, which can be used to figure out which sensor is reading which value. On Monday, I got a GUI to read from the RFID different tags, and keep track of the IDs to change the GUI's font colour according to the tag being shown. I actually based this on one of the older Visual Basic examples, which changed the background (I couldn't replicate it exactly in Java). As of Tuesday, I've managed to get the IFK displaying values as they change, through a GUI, and currently I'm working on trying to get the GUI to display both the IFK values and the RFID tag events. I can sort of get it working if I create buttons that have to be clicked to start the IFK and the RFID. Steve has told me in our last meeting that he's sort of having the same issue.

On Wednesday morning, I took some time out to be an experimental subject for one of the other people in the lab. Colin sits directly to my left, and asked me if I would mind (I said yes on the condition that it wouldn't hurt). It's an interesting wheel rotation experiment; I don't know if I'd be able to explain it properly. I've put his link in my happy box to the left, but I don't think he has a description up there either. However, the photo on his front page is adorable. (:P)

Now that I have a GUI working and reading (apart from having to create and click buttons to start the devices), Steve has suggested that I start tailoring it to be less specific, and more usable for the Creature display. We still haven't worked out how it should look once I'm done, but there are some ideas, i.e. for the skin sensors, have a bunch of colour patches that change as the value of the sensor changes. To start, however, I have to fake the data and pretend that one skin sensor (none of which are yet attached) is actually something else, such as the slider on the IFK. I'm also trying to figure out how to get the text boxes on the GUI updating as the value changes, instead of setting the display manually in the code. That is where I am now, still searching. The only thing I've managed to find so far is to implement the Java Document class, which requires many more functions than I actually need. I'm also looking at JavaBeans documentation, since Beans will be used eventually I think. I've never explicitly used Beans before, so this is something new. :)

Top

Somehow, probably because of the immense preparation for the first Girlsmarts workshop on June 3rd (out of three girls planning the activity, one has disappeared, another is in school full time and can't spare much time otherwise because of homework, so it feels like I'm working yet another job), I've neglected to update my journal for the week previous. However, as things have been rather slow, I would say it's safe to group last week and this together. The odd thing is, I thought I remembered writing an update on here.

I met with Karon last week to discuss the gameplan for the next little while. I've taken a step back from looking at and working on GUIs directly. Steve has gone away for a couple of weeks to visit his family, and for his sister's wedding, but before he left, we went over the specifications for the application I need to create. The hardest part for me is knowing exactly where to start. I've already made a little progress with respect to remembering how to make a GUI, but very few academic courses that I've taken so far require open-ended project work. I've been spending a lot of time, and intend on spending more next week, on checking out user interface coursework. It was Steve's suggestion, and I'm not against it since I intend on taking the course come September. Karon has pointed me to a few resources that I can check out, and specific areas of the notes (obviously I don't have time to cram in the entire course curriculum).

I've created a list of task examples that will help define specifically what the application needs to do, and then from there, I can figure out what it should look like, and how best to implement it. Currently I am waiting on Steve to give me long-distance feedback on the examples I've already created, and to add to it. Karon has also suggested looking at software that can have a sort of "oscilloscope" function, which is more or less what the visualization aspect of this application will have, to see how others have implemented their own work. Matlab was one of her examples, and I am attempting to see if I can make it work.

Apart from the Haptic Creature project, I am also keeping busy with the HCI Studio management for Karon and Joanna. Things are starting to move a little faster, and there is much to do still. As well, as I said before, the Girlsmarts workshop is looming ahead. Basically all of the preparations are done; we had a test run with a couple of students, earlier this week. It's always hard to tell if something is going to be difficult or easy for kids, and it's been nearly 10 years since I was at their age (we'll be working with grade 6's), so I don't really know how they think. Even more, the first workshop is really when all the actual run-time kinks get worked out; the second week should go more smoothly. I'm definitely looking forward to... a long Saturday.

Top

It's been quite quiet this week in the lab, though I've still managed to keep busy. I found a tutorial on Matlab that I've been playing with, and I did a few searches online for applications which might be even remotely similar to the functions that I need to work with. I have a sheet with mini-doodles, and a few screenshots that I can use as examples. I've spent a lot of time over the past week keeping up to date with the HCI Studio project. Managing something like this isn't like anything I've ever done before, but I'm picking up some things.

The Girlsmarts workshop went fairly well. It took a lot of energy, but tomorrow's workshop should go a little more smoothly, I hope. The last workshop will be the 17th, a half day for us since there will be only two groups as opposed to four. We got feedback from last week's girls, and everything except for a few were positive. Even the negative scores came from girls who for whatever reason didn't like any of the activities, which was too bad.

Yesterday was the June MUX (my lab) social, where there was a sushi fest. However, it appears that nobody took the leftovers home, or put them in the fridge, or at least threw them away... I came in this morning to find the lab smelling an awful lot like sushi.

Top

Steve is back, and the project is starting to move forward again. We're continuously working on adding to the task examples, for the application's functionality, and after finding some interface examples we started getting a couple of ideas as to how the application should look and function. Being used to getting a predefined problem with no need to extensively figure out how the end result should look, it seems odd to me to be going through this lengthy process. All of the projects I've done so far have been in classes, where there is little or no chance of what I make being used later on, or being customized later for somebody else, as may happen while Steve develops the creature.

My mini doodles now have more of a purpose, as I use them to keep track (or attempt to keep track) of the ideas that come up when poking around other applications. At the moment, I tend to be looking at menu options, and how the application can show as much data as wanted, in different, customizable ways. The idea is to be able to have everything necessary without taking too much screen space. I suggested to Steve that we request a four-monitor hookup, but I don't know if that would get approval from anybody except the users (and monitor enthusiasts).

Plans are underway for a lab group retreat; we're going to be heading up to Whistler for two days and an night. Two nights for most, actually, but my Tu/Th night time class starts next week and since we're going mid-week, I have to go up late and come down with enough time to be on campus by 7pm. My last Girlsmarts workshop will be tomorrow... We've got the feedback from last week's activities, and everybody seems to be doing progressively better. Hopefully this Saturday will run as smoothly as the last.

Top

Steve and I have gone through all the mini drawings I've made, and figured out which would work the best, at least for now, given the circumstances. The purpose of this application is to operate as a visualizer/editor of the happenings within the Haptic Creature. As there are five main 'parts', more or less, it's difficult to find the right layout for displaying everything cleanly.

I suggested to Steve that we ought to go for a layout which involves several modular windows, rather than having all the sensors, actuators, and software components be displayed in a single window that could possibly be tabbed. While tabbed windows work wonderfully in an internet browser, using a tabbed window to view various components will not work, especially if one wants to look at more than one area (say, the sensors and the actuators) at any particular point in time. Thus, the flipping between tabs that is bearable for applications such as Firefox is not quite practical for this purpose. In addition, the tabbed model would be much more finicky to create, and just as difficult to dismantle, should the decision be made later on to change the layout.

So, the reasons of choosing the multi-window model were as follows:

• modular design allows for freedom of window placement, so multiple components can be viewed at the same time
• separated panel design allows for ease of layout change in the future
• open design allows for easy component addition or subtraction once the parts are put together, without having to do a complete overhaul on the application

There is the concern, of course, that with the windowed model, the screen will then become too cluttered. The advantage of a tabbed or enclosed interface is that there is only one window to deal with, and the focus is always in that single window. Another issue is one that I have not looked at quite yet: if the window manager recognizes each window as separate, or as part of the single program. As an example, does alt+tab cycle through the windows of the program, or the application and other programs? My guess is that it will treat it all as one, but I could be wrong. It's possible to restrict the movement of the windows when open, but I think that would negate the positive effect of being able to size/place each window as the user chooses.

Other ideas include user restriction: access to certain windows is prohibited depending on the roles that the current user has (demonstrator, experimenter, developer, etc.), a master control: a single, main window that can hold commands that affect all components (start, stop), made like an iconic palette that is easy and intuitive to use.

These are just a bunch of the basic thoughts going through this week, which I wanted to keep here for future use in my end-of-summer report.

Top

I met with Karon early on in the week, to give her an update on what was happening. She suggested that I do a UML diagram of what the framework should be like, so that I have a pictorial idea of what the application will have. While I think this is a fantastic idea, because it will give me some organization, I haven't actually had a reason to use UML methods since the very beginning of second year, when we learned them. All of the other class projects since then have been extremely small, such as debugging prewritten code, or requiring only one class. The only large project I've done wasn't focussing on classes, so we didn't diagram anything of the sort. In hindsight actually, it might have helped.

On Wednesday and Thursday there was a bit of a work hiatus, as the seven lab students (including myself) and Karon headed up to Whistler for a SPIN lab retreat. We spent two days in a small cabin right at the edge of Lake Alta, with the intent of brainstorming ideas for a lab-wide project, as well as discussions about musical improvisation (for Ricardo's project) and professional development. The latter was partially led by me, with the basis being my graduating in a couple of years and wanting to glean information and ideas about what to do next from the others. Much of my time was also spent doing my homework assignment which was due for my Thursday class. I've linked to some of the pictures on the right, taken by Mario. I am the one sitting at the table getting frustrated at papers and textbooks. (It's fairly obvious, actually.)

I am also working on a schedule for the next two months, and once I get input from Steve on what the particular milestones will be, I'll be able to set that up. The editor is finally really getting into motion; it took a while to get here since Steve was gone for several weeks. Now there isn't much to do but keep on going. Once I get a sizable number of sheets to scan in, I will do that and use them for my report as well. I think better when I write on paper, so everything has been on sheets.

Top

I've put up a new page here, and although it's labelled as a schedule page, I sort of have the intention of keeping on there other information which might be useful for me when I get my reports done. This being all of a co-op work term, a CDMP research work term, and SPIN lab work term, I technically need to make three reports -- a technical report for future reference, a technical report for the co-op term, and a report for the CDMP. The first can technically count also for the second, and the third can use a lot of information from the first, so it shouldn't be too bad. There's also a lot in these pages which will probably come in handy for the CDMP report. It's not really easy to come up with a research paper worthy document, since there isn't any sort of explicit research going on at the moment with the Haptic Creature. The way I see it, it's more like what we're doing now is necessary prepartion for what feels like typical research: conducting strange experiments on the unsuspecting.

All joking aside however, the very basic schedule that I proposed to Steve passed his inspection; the only problem now is being able to stick to it. While the concept of creating a framework and the classes (going from the bottom to the top) is fairly simple, writing it all in code is still time consuming. This isn't because it's particularly difficult, although it can definitely be frustrating. What I've found, and Steve also mentioned this, is that GUI programming is irritating when you know exactly what you want to do, but don't know how to do it simply because you don't know the exact words or commands that will do the trick. Once I can get through that, however, then I can start building on that to fill it in a little more.

One thing I have to keep in mind is to remember to finish off everything that I start before I move on to the next task. So that means, before I start any of the classes, I have to be sure that no serious modifications need to be made to the framework -- it needs to be solid and working. Also, when I work on one class, it's best to finish it completely (or as completely as possible, as the framework for the Creature, which Steve is making, may or may not be entirely ready by August) before I move on to the next one. While this is good for not having to go back and fix things, it's also doubly important since I plan to take a short vacation during the August long weekend (first weekend in August) and it would take up too much time to come back and try to figure out everything that I'd done before I left, in a particular class.

Top

I now have an application that will run, and "bring up" a new window when requested, in Java. The way it's currently working is, when the application is started, the main frame shows up, and a second is also created, but hidden, and does not become visible until its related button is pressed. This means that I only have one instance of the window, whereas if I were to create a new one each time the button is pressed, I would have multiple. Both versions have pros and cons, the pro being that having only one window would cause no confusion as to which one to look at, as well as avoid clutter. However, having only one window means it can only be on one desktop space, whereas if we had multiple windows, you could have one per desktop (imagine running on Linux as Steve does, where the option for multiple desktops is obvious), and be able to view what you need in different environments. I tend to think that that option is going to be a little less generally useful; having one button bring up multiple windows is awkward to me. At the same time, having all the windows open when the application starts (eventually there will be at least five or six fully populated panels) makes the application feel bulky to me.

I had a midterm this week, which slowed me down again. I'm taking one night class, two times week, until the end of July. Under normal circumstances, a job plus a class would be no biggie, and the truth is, now is the best time for me to take this particular class, since my intended schedules for my last three academic terms are maxed out already, for me to graduate on time. Combined with my being on campus all day, it ought to make for a convenient solution. However. (:P) On the first day of classes back in June, we discovered that the textbook supplied in the bookstore was not the one our instructor intended on using, and ended up changing the entire course curriculum. As an added plus (note: sarcasm), I learned last week that the year after I took the prerequisite for this course, what was taught in those classes changed drastically, so I often feel like I'm going through this class blindly. I can't be the only one however; I know of three people who have already dropped the course, and are sticking around just to audit.

As a final note, in regards to the application, I am thinking that taking a step back and just writing down the interactions between classes (I do have a basic class listing/UML diagram, but while it shows relationships it doesn't show interaction) may help, just to give me a reminder as I work. I basically know, more or less, how I want them to work anyways, but a concrete piece would probably be good to have on hand anyways.

Top

This week has been spent working on the base for the creature application.

To get a frame to pop up when a button was pressed, originally a frame would get created when the application was first run, and then rrought to view when the button was pressed. However, with larger and more complicated panels, this would greatly reduce start-up time. The way it is set up now, however, is that each button, when it is pressed, will check to see if its corresponding frame is null, and if so, will create it. In either case, it will set the visibility of the frame to true, and give the frame focus. Alt+Tab works for cycling through the frames, and closing the main application window closes the entire application, so no frames are left behind afterwards.

To factor out the similarities in functions, the frames, buttons, and labels (there is one for each division: sensors, gesture recognizer, emotion modeler, emotion renderer, actuators) were put into arrays. There is one method to set up the buttons, but in order to associate the button with the proper frame, a getButtonIndex method was added. This is not the most eloquent of ways, and will require specific pre and post conditions, but the likelyhood of those being incorrectly sent is small. (Hopefully.)

I've cleaned up the code as much as I can, and as I tend to be a stickler for commenting, I've put in some Javadoc code as well, and have had Eclipse create some documents. I am hoping that this will help keep track of what each method and each class does, in case Steve or I want to make major modifications later, and can't remember exactly what (and why) something does what. Additionally, I think that for own self it makes for a good habit to have, for future projects.

I still have to add functionality for switching focus, in terms of knowing which window has focus (possibly), sending focus to a window and bringing it up if it's underneath another window or if it's minimized (I am not sure how to do either, and not entirely sure if the latter is doable in java), and setting the labels to indicate what the status of each frame is. For the last one, there is currently some functionality -- when the master panel is created, no frames are active, and each frame is labelled as being off. When the button is pressed, and the appropriate frame shows up, the label changes from saying "OFF" to "ON". I somehow doubt this is the best terminology, but that is very easily changed later.

Javadocs can be linked to on the right, but they will not always be up to date. I will also add these to my schedule page, which seems to be collecting not only my schedule, but my project specifications. :)

Top

Hurray! After two days of searching around, flipping through books and endless tutorial and tip pages, I've finally figured out how to get a window to restore after being minimized! Originally I thought that it would be necessary to add a FocusListener with appropriate methods, in order for the window to act appropriately. The problem was, this is such a small idea that it's hard to find the right text on it, plus the language is so word-specific that searching for the wrong word can completely lead you astray. Eventually I found some tips on bringing a window to front (not quite as useful but a good start) and minimizing a window. Searching for "restore" in terms of windows and frames returns little, however, because the Java word is "normal" (vs. "iconified").

Thus all of my confusion and lack of answers culminates in one line, added to the ActionPerformed on the respective button:

displayFrame[buttonIndex].setState(Frame.NORMAL);
Gee... Putting it into the focusGained method did nothing. It will minimize when it loses focus but will not restore when it gains focus; I guess having it still minimized doesn't count as gaining keyboard focus after all... which I guess really does make sense, now. However, now I have no focus events at all, since they aren't actually useful at the moment.

That probably just about does it for the framework... I'm fairly sure all of the windows and frames come up as necessary. The only changes I can see having to do later have to do with size and position, once the panels are filled in. Also, the proper code will have to go in to bring up the right panel each time (it's there, but commented out). Right now it makes multiple windows that show the same panel, just so that I could get the application working.

Steve has suggested working on one panel first, such as the sensor panel, and making multiple interfaces to choose from (very simple text boxes, colour chips, etc.) and hooking it up to one or two of the Phidget pieces, just to have some real input to work with.

And that is probably it for this week... Now that I've finally conquered this frame minimizing problem, I can move on to studying for my final on Saturday. My last class for July is tonight, and after this week the class will be all over! Removal of one stress in progress...

Top

I've set up a class that could eventually take values, which is very basic, and has only text boxes. Because of the way I wanted to set it up, I encountered an interesting snag: using the GridLayout for the sensors, apparently if one specifies the number of preferred rows, it doesn't matter how many columns are specified, the order of preference that Java will obey is: Number of specified cells >> Number of specified rows >> Anything else important >> Number of specified columns. >> being "dominates". That is, to get three columns in my layout, if I specify two rows, then I have to put in six items to get them arranged in three columns.

Like so:
* * *
* * *

Putting in two or three items will give you one or two columns, respectively -- just to maintain having two rows.

Two items:
*
*

Three items:
* *
*

But having three items like this
* * *

would violate the necessity of having 2 rows.

This is absolutely crazy to me, but with the help of a little bit of basic math ("Uh... four goes into thirty... 7 times?") I've managed to get a workable layout.

At this point, the framework for the Creature editor (called CreatureApp) is as done as can be, and is ready to plug into Steve's creature framework -- the parts that actually interact with the haptic creature. From there, some tweaking would be necessary for the two to interact properly. The only problem is, the creature framework isn't completed, and I can't do any tweaking at all. I could continue to create basic panels for each of the five sections, but that code would undoubtedly prove to be useless in the end, so there really isn't a whole lot of point in doing that now.

I met with Steve and Karon on Thursday, and the idea now is for me to return to the brainstorming stage, and come up with different mockups for the panel layouts. For a while we were considering doing a Flash mockup, but that would require me to learn how to use Flash, which could take up the rest of my time here anyhow. I usually do all my creative work away from the computer, and on paper anyhow, so that's how it will probably go.

I will be away from the 3rd 4th to the 7th, for a mini-vacation! (I need it, too.)

Top

This week! Looking at different ways to present the information for sensors and actuators, coming up with different drawings and ideas. I spent most of Tuesday starting to do my final report, so there is some information on the report page. It's mostly taken from sources that have already been written up for the project, but a very rough section outline is there. Karon suggested adding the more technical report as an appendix. This would be more of a how-to sort of start up guide detailing the technical specifics of what I've done as a reference for Steve or anybody else after me who is wanting to utilize the application.

(7th is a stat holiday: BC Day.)

Top

A large part of week 15 was spent trying to figure out just what was going on with my computer. Early in the week, the internet connection on my computer (and my computer alone, apparently) seemed to be a little off, and I could neither get to the internet nor to my networked drive or e-mail. This persisted for nearly two days, during which I spent much of my time trying to figure out just what was blocking my connection.

This last week has been mostly spent on wrapping things up. I've been taking paragraphs from notes created by myself or Steve since I started to make up my CDMP report. As Steve's project is just in the beginning, there aren't any experiments or conclusions to report, so it seems a lot more like a summary than a paper. I've finished a document I can use as my Co-op workterm report, which encompasses a summary of the code that I've written, as a requirement for Steve and Karon.

I'm also working on finishing my report, tar-ing my website files, and... cleaning up my desk. It seems odd to me to be finishing up; the project as it is, isn't one that I can come back and pick up again to assist Steve, so I'm just going back to school in September.

It's certainly been interesting, and I will definitely miss everybody here at the lab. Fortunately, this is my home department (sort of; my degree is a joint program, but I do tend to spend a lot of time in the CS building), so I can drop by and say hi any time.

Top