Carleton Weather

Made a good chunk of progress on the background php scripts for the now consolidated almanac/summary page. I ran into a time-suck snag in the middle of the day involving updating the split() function to preg_split() (split is deprecated in the current version of PHP). The regular expression syntax was not carrying directly over, so I had to do a lot of debugging and reading on how to do what I wanted, which took 2 hours but I learned a bunch and finally figured it out! It was actually a pretty simple fix, I’m a little bummed I didn’t find it sooner, but oh well. I also added the ability to pass in the user’s almanac/summary choice to a “switch” script which loads the appropriate data-retrieval script. To do this, I had to tack on some stuff to an array that gets used all throughout the scripts, so I am going to have to go through and adjust a bunch places where the index being called will be off because of my addition. It shouldnt take too long, I just have to bump each one by 2.

-Will

I have continued to read about creating mobile-optimal stylesheets with CSS and slowly experiment with different changes for the homepage. Originally I was making changes to a copy of the computer screen version stylesheet, but today I decided to start building a new stylesheet from scratch, since I think very few of the styling elements used on the screen are practical for the phone. I have also been looking at various weather sites’ forecast information, and most do seem to come from the National Digital Forecast Database; I’m still trying to figure out exactly which of the database’s resources they use. One option is definitely to pull text off the XML of NWS’s forecast page for Northfield, though I’m thinking there’s probably an easier/more reliable way to get the information. At this point I can find next to nothing online regarding how daylight savings time affects weather record-keeping. I’m not sure that there is a standard. We might need to make our own decision about what we’re going to consider a day, note it somewhere on the website, and just be consistent about it. From what I’ve read about DST, I don’t know whether it makes much sense to account for it in historical records since it wasn’t adopted in the US until 1918 and it effective dates have changed numerous times since then. Changing our definition of when a day is at various points in our records seems like it could add a lot of complications. Thoughts?

-Katherine

Almanac/Summary page is getting there. I sketched out different ways that the menus and content will interact. I currently am working on a tabbed interface (2 layers) that controls the type of summary and then the time range which will both decide which menu will be displayed so that the user can select the day/month/year they want. I think that by default, it will display the most recent data, but I haven’t gotten that far. A lot of the current code is repetative, so this might not be as bad as I forecasted.

-Will

Okay, so I had no idea how complicated the Almanac and Summary pages were. After looking at them on the current site, I had the idea to combine the two into the same page since they essentially accomplish the same end result, but for different time ranges (which I separate using tabs). However, this is going to be a really complicated undertaking. Hopefully by the end of it I can better organize the user interface and clean up the code to make it more readable (the almanac page alone has over 2200 lines in it). This is going to be fun…

-Will

After revisiting some of the tutorial elements that I watched, I managed to get the plotting page looking how I wanted! It still doesnt actually plot yet; I’m waiting until I have all the pages CSS-ified before I get to the functionality part. Made some edits to the home page, but I am having some trouble with some layout elements that I will address in the morning along with starting the big-bad almanac page. Lot of stuff to modify on that one!

-Will

Started out doing some final styling on the features page. Right as I was about to start tackling the ever annoying plot page CSS I got my lynda account set up and BAM, its now the end of the day. I worked through a great CSS tutorial which showcased how to organize code and really weild CSS as a tool, and then got half way through a JQuery tutorial which I will probably finish over the weekend because it is just getting to the cool part!

-Will

I still have not been able to make the website show up differently on a phone than on the computer screen. I have tried a number of different methods in both the php files and the css files, but my iPhone still displays what I specify for the computer screen, not a handheld device. I’m not sure whether there’s some other code that I need to use to manually check whether a handheld device is accessing the site; I haven’t come across anything to that effect in my reading. In the meantime I’ve been reading about principles of mobile website design (which I can hopefully implement soon!) and playing around with making webpages. Also, the administrative password must be different on the PC than it is on the Macs, so I’ve downloaded RealTerm but couldn’t install it yet.

-Katherine

After a brief delay where I realized that I deleted the contents of plotform.php in the collab folder, I got the tabs up and working! I have some basic styling applied, but it doesn’t look that good yet. I also got the features page up and running! Hooray! I’m going to spend some more time playing with the plotform styling and the like tomorrow and also add the recent conditions section to the homepage, which I left out when I did it initially.

-Will

Edit: Heres the Northern Lights video that I was talking about!

http://vimeo.com/25811412

I’ve been playing around in CSS tutorials and using CSS to format simple things the past couple of days. Today I tried to figure out how a website might tell when it’s being viewed from a mobile device. I came across a tutorial on a way to specify different formats for different media types in CSS, and I had Will send me his code so I could test it out on his version of the website, but I couldn’t get it to work. When I try to change things specifically for the “screen” medium or the “handheld” medium, the site shows up both on the computer screen and my mobile phone as I specified for “screen”. I’m not sure why this is the case, but if I can’t get this to work I’ll research other solutions. On a brighter note, a parallel port/serial port converter has been ordered and the RealTerm program looks like it will be very helpful in capturing whatever data we can send the PC. Tomorrow I can try and download the program on that computer.

-Katherine

Today was not as productive as I had hoped. I started with the goal of moving the plotting capability into my version of the site, but did not get very far. The process of creating working tabs to control the display of the different plotting modes proved to be trickier than I expected. After becoming frusturated with straight Javascript and then talking to my dad over lunch, he suggested that I explore JQuery (which I had already researched two weeks ago) as another way of doing tabs in Javascript but in a way that was better compatable across browsers. I started down this path, and got a bit farther. I reached a point where the tabs were “working”, but they would all initially display instead of just the first one. About 30 minutes ago, i tried a new block of JQuery/JS code that finally fixed that problem! Tomorrow, I’m going to start out moving the form aspects of the tabs in and then playing around with the CSS to make it look pretty. After all that is done, I am going to move into actually having it work with MySQL. Quite the mentally draining day.

-Will