Friday, June 19. 2009
Checking the viewport's width and height...
I've never been a fan of using JavaScript to fix up an interface. That is the purpose of using CSS. However, with that being said, I developed a very elegant website login page with a resolution of 1024x768 in mind. All of the CSS had been meticulously measured using quite a few pixel-based measurements (over EMs, because I was sure it would be fine for the two horizontal elements taking up the page width). Unfortunately, I had confused our public facing site with our backend staff site's statistics. 32% of our backend site is viewed with a resolution of 800x600. Uh oh!
Times are changing, and computers get upgraded. Although the staff members with an 800x600 resolution might be used to scrolling on some pages to view content, it really wasn't good for the staff site's login to require a scroll (the main site is not yet redesigned, and I designed that for an 800x600 display). I didn't want to have to start from scratch, and even resize images to make them fit. As time progressed, I expected the percentage of 800x600 site views to drop, so this is more of a temporary band-aid that's needed anyway... JavaScript to the rescue.
Screen resolution is easy.
Many people state that each of the major browsers use a different approach to determining the viewport, and this is true. But most people also create a function or IF/ELSE case for each possible outcome. I found some code that mixes all three in one line quite intuitively. Below is the actual JavaScript I used (jQuery methods found in there) to solve my issue (I pre-determined the width/height numbers manually for this specific layout).
Quite easy, quite nice, and the most important thing is that the login box is now clearly visible without any unnecessary scrolling (caused by CSS issues) at specific resolutions (tested at 600px width, minimum). If it's any less than that, I can assume it's a mobile browser and we don't (yet) support that; but when we do it'll be a completely different layout that's used.
I hope this might be helpful to someone else, but for the right reasons! (Credit to About.com for the viewport functions.)
Times are changing, and computers get upgraded. Although the staff members with an 800x600 resolution might be used to scrolling on some pages to view content, it really wasn't good for the staff site's login to require a scroll (the main site is not yet redesigned, and I designed that for an 800x600 display). I didn't want to have to start from scratch, and even resize images to make them fit. As time progressed, I expected the percentage of 800x600 site views to drop, so this is more of a temporary band-aid that's needed anyway... JavaScript to the rescue.
Screen resolution is easy.
screen.width and screen.height, respectively, will tell you about a visitor's monitor's current resolution, but in this case I needed to know the viewport.Many people state that each of the major browsers use a different approach to determining the viewport, and this is true. But most people also create a function or IF/ELSE case for each possible outcome. I found some code that mixes all three in one line quite intuitively. Below is the actual JavaScript I used (jQuery methods found in there) to solve my issue (I pre-determined the width/height numbers manually for this specific layout).
Quite easy, quite nice, and the most important thing is that the login box is now clearly visible without any unnecessary scrolling (caused by CSS issues) at specific resolutions (tested at 600px width, minimum). If it's any less than that, I can assume it's a mobile browser and we don't (yet) support that; but when we do it'll be a completely different layout that's used.
I hope this might be helpful to someone else, but for the right reasons! (Credit to About.com for the viewport functions.)
Thursday, June 11. 2009
Server2Go - Apache, MySQL, SQLite, PHP and Perl all on a CD-ROM
The title's a bit misleading, Server2Go also works on a USB drive as well (and like most portable webservers, runs better on a USB drive). However, that's not why I'm all excited about this.
Recently, our web host's newsletter stated that users with Wordpress-MU installed would no longer be able to run it on a shared webhosting plan, it was just too resource intensive. If it was desirable to continue running it, a private server plan would be required. We were using Wordpress-MU, only had 5 blogs, and it hadn't been touched in about 5 months. BYE BYE MU! However, there was a lot of useful information on 2 of the blogs, and I wanted to give the users an opportunity to save their work.
I had two choices:
1. Use a spider, like HTTrack to copy all of the rendered HTML viewable by random visitors, or...
2. Try to find a solution that would let the author log in, view any unpublished pages/posts, and still get some educational benefit out of using a well-known web-based product. (Note: I was only looking for something that works on Windows.)
There were a couple (2) hits from Google explaining how to do it all manually, and a few products that claimed they could do it (if you bought their product; the free version only worked for USB drives, not CD). Server2Go came up as my last opened tab from my search, and it was what I needed. It was free (I wasn't going to pay if I could do it myself manually - though I may donate), and even looked really slick, and was configurable.
It took me two tries to get Wordpress installed and working with Server2Go. I needed to change "localmirror" to 0 while installing it and change it when done, but I didn't do that...so I had to reinstall it all. Wordpress' export/import feature saved the hassle of moving from Wordpress-MU to a single, standalone install of Wordpress, and after that, it only took maybe 3 minutes to set everything up.
If you need to have a product presented on CD to a client, I'd highly recommend Server2Go. USB drives will always work, but run the risk of accidental editing/deletion. A backup plan is always good! ...this is just yet another tool for the arsenal.
Recently, our web host's newsletter stated that users with Wordpress-MU installed would no longer be able to run it on a shared webhosting plan, it was just too resource intensive. If it was desirable to continue running it, a private server plan would be required. We were using Wordpress-MU, only had 5 blogs, and it hadn't been touched in about 5 months. BYE BYE MU! However, there was a lot of useful information on 2 of the blogs, and I wanted to give the users an opportunity to save their work.
I had two choices:
1. Use a spider, like HTTrack to copy all of the rendered HTML viewable by random visitors, or...
2. Try to find a solution that would let the author log in, view any unpublished pages/posts, and still get some educational benefit out of using a well-known web-based product. (Note: I was only looking for something that works on Windows.)
There were a couple (2) hits from Google explaining how to do it all manually, and a few products that claimed they could do it (if you bought their product; the free version only worked for USB drives, not CD). Server2Go came up as my last opened tab from my search, and it was what I needed. It was free (I wasn't going to pay if I could do it myself manually - though I may donate), and even looked really slick, and was configurable.
It took me two tries to get Wordpress installed and working with Server2Go. I needed to change "localmirror" to 0 while installing it and change it when done, but I didn't do that...so I had to reinstall it all. Wordpress' export/import feature saved the hassle of moving from Wordpress-MU to a single, standalone install of Wordpress, and after that, it only took maybe 3 minutes to set everything up.
If you need to have a product presented on CD to a client, I'd highly recommend Server2Go. USB drives will always work, but run the risk of accidental editing/deletion. A backup plan is always good! ...this is just yet another tool for the arsenal.