Finally, it's come time for DueDates 2.0, the final battle in our quest for programming glory. It was a tough beast indeed, requiring us to conquer both XML parsing and Wicket webapp coding. Though we suffered some bruises, in the end we dominated the monumental challenge put ahead of us!
Putting fantasy aside, our final project for ICS 413 was to turn our console-based DueDates application into a full-blown web application using Wicket. Aside from converting everything DueDates 1.2 could do into a webapp, we also had to add in XML parsing using JAXB in order to get user information without relying on a database backend. In order to help us accomplish this significant upgrade to the system, our professor divided us up into groups of 4 instead of 2. This made the logistics of meeting up with each other harder, but had the benefit of more man hours being put into the project. My partners were Arthur Shum, Daniel Arakaki, and Jeho Jung. We decided to start with DueDates-Blue as the base to work off of since Arthur started working on DueDates 2.0 before it was officially assigned and already finished 2 of the 7 requirements by himself on the first day the project was officially assigned.
It's not your fault, CSS, it's Internet Explorer's
My role was to write the CSS code to format the HTML pages, and it definitely took some work to get a design that not only looked nice but would work properly across the three browsers I used: Mozilla Firefox 3, Internet Explorer 7, and Safari 3.2. I originally started off using Eclipse but it soon became obvious that it was inadequate because it lacked syntax coloring and brace matching. I even tried a CSS plugin for Eclipse, but it paled in comparison to my favorite text editor, Notepad++, so I ended up using that for the majority of the time that I was coding. As a result though, this time was not sent to the Hackystat server, so it looks like I barely put any time into the project. I found that this was one of the disadvantages of the Hackystat system, where you're forced to use only the IDE's that the Hackystat sensors support, even though you might be better at using another unsupported IDE/editor.
In order to get to the current design of the webapp, I had to go through several redesigns and color scheme changes. Originally I wanted a fixed-width design with a dark gray color scheme, but when I created the mock-up in Photoshop, it looked boring and too dreary. Then I tried several different color schemes and layouts in CSS to get a better feel for how it would look in an actual browser. At one point I even tried a pink color scheme since akala means pink in Hawaiian, but having your project page look like the Barbie Fun House is not exactly the idea I had in mind.
Eventually, after several failed designs, I settled on a red scheme that made the page look professional and lively. This is where I ran into my next problem with CSS. Although most, if not all browsers support the CSS standard, the way they render it to the screen is completely different. In particular, Internet Explorer 7 has a drastically different way of rendering CSS elements than Firefox and Safari do. For example, when specifying a fixed width, Firefox and Safari do not count the borders with the width, but Internet Explorer does. This means that if you create a box with a 300-pixel width and a 1-pixel border, Firefox will create a 300-pixel wide box and tack on the 1-pixel border to it, whereas Internet Explorer will create a 298-pixel wide box with a 1-pixel border on either side to add up to 300 pixels. There are other differences too, such as how IE interprets padding and margins, but I won't go into detail about them. Needless to say, I spent a great deal of time just making sure the CSS was compatible across all three browsers I tested the webapp with. In the end, after scouring the web, I found a very helpful CSS tip:
* { padding: 0; margin: 0; }
Boy, you are outta time!
Unfortunately, I was only able to meet with my group members once throughout the entire project, but we figured out how to read the values parsed from the XML file by JAXB, which was a huge step forward. Strangely, although Daniel Arakaki said that Arthur and he met up 6 times throughout the project, they did not inform me about these meetings and I had no idea they were getting together. To be honest, I feel as if they were purposely excluding me. I also sent out an e-mail asking them to give me feedback on one of the CSS layouts I made but received no responses. Regrettably, Arthur did ask me to implement certain features into the CSS at one point but I became very busy around that time and was unable to get to it, and by the time I did take a look at it, someone else had already implemented it. I had another project for another ICS class that I had to work on so I couldn't put in as much time as I wanted to, but I'm surprised Arthur had enough free time to work on it for an average of 5 hours per day. I didn't have the luxury of time on my side, but it's still very impressive that he was able to stay motivated and work on it for so long every day.
No comments:
Post a Comment