1. Troutnut Forum
›
2. Photography
›
3. Pics for web

Hey, Jason (and others, I suppose) -

I was wondering how you format the pictures you use in the header of your webpages. I know many of us really like them, and I'm thinking of incorporating some of my own into a website I'm now constructing. I've been told by my computer guru (my cousin) to stay away from using photos as backgrounds and such because they don't resize well with the rest of the window when the page is opened on computer screens of different sizes.

I know the specifics of this sort of thing might be unique to a certain type of web-building program, but I was hoping you might give me some general hints regarding filetypes, sizing, etc.

I doubt it will help, but I'm trying to build my site using Plone.

Thanks,
Shawn

Photos are good for use in a fixed-width layout. This site's layout doesn't change width regardless of the size of the window, so it fits well with a fixed header. If you do this, just make sure you use a small width (about 770 pixels is good) so that your site fits in the smallest commonly used screen size.

Some computer gurus, especially web "usability" buzzword fans, are strongly opposed to fixed-width layouts and prefer the flexible style you'll find on sites like sitepoint.com. That works for presenting some types of information, but it's not great for what I'm doing.

I thought the slight "feel" of being on the stream while on my website would be be an important feature, so I made the stream pic header a higher priority than abstract usability considerations. People seem to like it so I'm glad I stuck with that choice, and I think it's a good idea for many fishing sites.

Thanks, Jason. I wondered if it was a fixed width - that makes sense, and I'll have to consider whether that's a good idea or not for my site (and find out if it's even possible in Plone). Another possibility I'm considering is using only abstract macro shots for backgrounds and headers because they might not look as overtly terrible as subject shots would when stretched or shrunk. Any thoughts on that?

-Shawn

Yeah, if you want to have background images that stretch or shrink to fit the page, abstract is the way to go. I would use abstract images sparingly on a fishing site, though.

For a quick solution:
Place the image in a div, use css to make that div scroll... problem solved image doesnt need to resize.

Now for the long winded answer


I have a degree in computer science (background) so here we go...

Background images in the traditional sense of web design were used by placing the items inside of tables or table cells. There are many Unix based programs that offer the ability to resize an image on the fly via the command line.

Using a web language such as Perl which many people are scared of will give you possibilty you never imagined. When you combine Perl with javascript and CSS you can render virtually anything.

The company I work for's websites do some amazing things! Have you ever been on a webpage that submits forms without ever seing the browser refresh? Other then our sites Ive never seen it.

I cant possibly break this all down for you but dont think that you cant have sites with images as backgrounds and manipulate data in unconventional ways, I do it every day. Of course, thats my job, and for most people with sites like these, its a hobby, or someone else does the programming, not the owner.

If you really wanna design a site to blow the socks off of people learn these languages and combine them all. In order will help!

JavaScript
CSS - and the corrisponding css in javascript
Perl
XML
AJAX


You master those, you can make any site, and completely blow people away. One of these days, I plan to build a site. When I can get away from the tying bench. Plus 8hours a day at work doing it, doesnt leave me with a desire to do it at home.


Good Luck.

I'm pretty sure Shawn's not looking to get into advanced programming languages, but I can't resist the temptation to weigh in on Jeremy's comments anyway.



I only wrote a little Perl a long time ago, so I don't know it very well, but I know it has a reputation for being more difficult than the alternatives.

I would recommend PHP for most relatively simple standalone server-side scripting. It works for more complex stuff, too (I wrote this whole site in PHP) but I think there's a better way to do that now -- the Rails framework for the Ruby language, aka Ruby on Rails. It's an incredibly powerful structure for developing complex web applications quickly, and in a forward-thinking way that'll be easy to maintain in the future.



That's called AJAX (Asynchronous Javascript And XML) and it's becoming fairly mainstream. Ruby on Rails makes it as easy as possible, although it seems there are decent AJAX frameworks for most languages.



AJAX isn't really a language. It's a set of technologies. You don't really sit down to learn it... you just learn how to do various AJAX tasks in whatever framework you work with.

I'm not sure how necessary XML is to typical application development. I've actually built some pages using XML and XSLT and it's a huge pain in the ass -- the browsers just have too many bugs to work out. It's handy to know XML to generate RSS feeds but it's not really necessary for most things.

I would break down the essentials like this:

HTML and CSS: Really all you need to build simple webpages and make them look almost any way you like.

PHP: A little knowledge of PHP goes a long way if you want to do really basic server-side stuff without much application logic or database usage.

Ruby: The Ruby on Rails framework is certainly the most hyped technology for developing complex web applications now. After playing around with it for a couple weeks, I think the hype is well-deserved. Its application design philosophy (the Model-View-Controller pattern and "Convention over Configuration" mantra) is top-notch and the syntax is crisp and more like natural speech than any other mainstream web programming language.

MySQL: Complex applications require some database usage. Some modern frameworks like Ruby on Rails have a wrapper to abstract common database tasks, but it's still important to understand what's being done behind the scenes. Also, complex database tasks can't be handled by the framework's simple wrapper, so manual knowledge of the database is important there.

Disclaimer: For anyone thinking of building a webpage who's intimidated by this techno-babble, don't worry. There are very easy ways to build most types of webpages, so you probably won't need to learn any of this stuff unless you really get into it.

And I thought learning the latin names of bugs was daunting.

Just to piggy back on what Jason said about AJAX - yep, the term describes an "approach" rather than a language, and its pretty popular right now - but the idea has been around since the days of "remote scripting" in the late 90's. This latest implementation was coined "AJAX" by Jesse James Garret (Adaptive Path) a few years ago, and google's GoogleMaps kind of fueled the resurgence of the technique.

But its really nothing new. Just becoming easier to implement with the various ajax libraries out there now that do a lot of the work for you.

It is a cool technique - i do asp.net development as my day job, and we use it here and there. Can really improve the user experience!

I guess I kinda misled on the AJAX, sorry. But XML knowledge really helps if you wanna be complient with standards and ensure your code will work uniformily on most browsers. Thats one of the major downfalls with javascript. I hate MICROSOFT.. HATE THEM! They dont allow half of the available CSS and I hate the fact that it wants you to refer to objects directly via a form.

Ex: document.getElementById(fish_div).value
VS
document.forms[0].fish_div.value

Its actually easier way to do it then using AJAX but the W3C took that away with the new doctype. You can use a hidden iframe and submit to it in the background. I used to be a MySQL fan but they dont support postGIS and thats a big no no for me. I also find the command line to suck for it. postgreSQL is much more to my liking.


Why am I talking about programming, im not at work :)

Those two definitely don't go together!

I've concluded, like many webmasters, that standards compliance is a monumental waste of time. I believe in what-works-compliance. Most of the browsers don't fully support any standards anyway, and the most-used browser (IE) is horrible with it, so I really don't buy into the idea of building according to current W3C standards in hopes that one day all browsers will happily play along with them.

I've heard nothing but good things about PostgreSQL, but I've always used MySQL. It's got all the features I really need, AND it's free. With version 5 it catches up with PostgreSQL on a lot of features, but maybe not the one you're looking for. This site runs on MySQL 4.3.

It is winter and we're still months away from pleasant breezes and heavy hatches... so a little programming talk can be forgiven. ;)

I don't have any problem with it at all, and have enjoyed reading over this thread just to see what kind of things are out there. Not that I'd ever dig into this stuff. Caddisflies are next on my list. But I agree with Jason.

Sorry, guys, I've been away from this discussion for awhile. Thank you for not treating me like an idiot... but you probably should have. While some of the acronyms you are using sound vaguely familiar, I haven't programmed anything since I took a Pascal programming class in high school about 15 years ago. And while programming is interesting to me, I don't know that I have the time or desire to learn a new language. Maybe I'll just ascribe to the "simpler is better" philosophy. I appreciate the simpler suggestions and I'll see if I can get any of them to work.

Thanks, guys.

-Shawn

No worries Shawn. There are now a bunch of ways to create good websites without knowing a thing about coding (using pre-built Content Management Systems, such as the ones used for the gazillion blogs on the net). You can also code a page by yourself using HTML pretty easily. In fact, you can learn enough HTML from scratch in less time than it takes to tie a medium-fancy fly.