Results 1 to 6 of 6
Sep 26, 2006, 02:48 #1
If it's out of date, I don't need to know it - A small point
I read a thread today, replied to it and it made me remember a thread I was going to post a few days ago but didn't. The thread I was going to post was inspired by a client with an almost familiar story and some of the things people here drum on about.
We all know it's bad to design your site using tables, that if the technology or a part of it is out of date by over a couple of years you don't need to know it. Well, I was around when CSS didn't exist and thus learn't both and therefore can do both.
But what about our younger generation of developers... can they do both?
From reading this forum on a regular basis, and others, I am willing to bet that a lot cannot use technologies and methods that were commonplace say 5 to 10 years ago.
I'll leave it up to you whether or not you think it's a bad thing to not know the older techniques and whether newer developers should know them. What I will do is share some recent experiences with you, all based on real clients.
Now, these are not mom and pop stores paying pennies, these are examples from clients that are worth a few bob and are desirable.
The short stories are all true but I am editing them for story telling, so the words may not be exactly what they used. So they aren't word for word, but the content is true. - if that makes sense.
Our New Design
This was a recent one, say last month. We had a company approach us wanting their company site to be revamped (just the look).
During our conversations they said "we don't want you to use css for anything more than text formatting". I paused for a moment and asked for them to explain.
They have a content management system, a big one that includes staff rotas, planning, reports and all sorts of other stuff. This cms is over 8 years old and written in perl.
I asked them what the problem would be, seeing as we would just use PHP to fetch data from their database. Then they informed me that the CMS added HTML to the data, it used tables and older methods in the content the CMS was saving. This turned out to be pretty stringent.
They had a redesign two years ago and the development company used the newest standards and it was very problematic and they ended up going back to the old standards as it just wasn't working.
I pointed out we might be able to get around it given we are aware of the potential problems. They simply didn't want that risk again.
We said ok and brought up the possibility of updating the CMS, rebuilding it. Seeing as it's really old and written in Perl.
Their response was an all to familiar one:
"It does the job, rebuilding it will cost a few thousand, for us thats just a waste of money even if it does cause us some problems they simply don't justify the cost of updating it."
Basically, the age old concept of "ROI" unless you can justify it a larger company won't go for it. This CMS was in fact really good and to make it better for them we would literally be converting it's platform and updating some smaller aspects of it (such as how data was stored).
Us updating it would not increase profits or make their job easier. Standards be damned basically. Standards do not = profit or... anything to this company and a lot of others.
For them and many others, quite literally "when the web browser cannot load the page, then it needs updating" :/
I know the basics
Heres another redesign one. A smaller company came to us and wanted a redesign. He explicity stated "use tables so I can understand things myself". Upon further investigation he knew some HTML and could code our design himself in old standard HTML if he wanted to.
I pointed out a basic CMS would allow him to update his site himself. He scorned and pointed out that it's a waste of money when we can just code it the old way and he can change whatever he likes whenever he likes.
Flat file DB
A decent sized company... they had an inventory management and stock control system. This system was online but private, basically those "on the floor" could view inventory and order stuff while those in the offices could view the orders and inventory and put them through to suppliers.
Basic stock control yeah?
This archaic system's front end looked like something from a ZX spectrum, was written in perl and used one of the biggest flat file databases I have ever had the misfortune to see.
What did this company want?
A new stock control system (yey) but the database is really big and other systems depend on it... it must stay as it is... don't touch the flat file DB just the stock control system. (eek).
Using PHP and a massive flat file DB reminded me of the UBB days... it was all very similar actually (functionally) but a pain in the *** to work with.
OK, my point:
There are still a lot of companies out there using old technology and have no intention of changing it... and they aren't wrong for it.
Take the stock control system, that was actually part of a bigger system. Changing that database would have involved rewritting or massively updating several other much bigger systems and the cost of that would have been huge. That huge cost simply wasn't quantifiable to them, no excuse would work, they knew full well an MS SQL, Orcale or equivelant database (which would have been the optimal route for them) would have cause 5 digit figure redevelopment costs, just not worth it.
To add to it, they simply weren't sure if there was "anything else using that data, there could be as it was all made by one company at once" This company no longer exists so they can't find out.
Then you get instances like the first company, a system that is spewing out bad standards that will probably clash with your new standards design. They aren't updating it as it's not justified. Are they wrong?
Not really, why fork out a few grand for something that isn't that important to you... especially when what you have works just fine?
Second company, ok he was stubborn mostly but same premise. He had his own needs or wants and didn't want to fork out money for the sakes of it when he can have the same result for half the price.
I encounter so many companies that haven't even heard of standards for web design... not from mom and pop companies but larger ones. Anything you say is falling onto deaf ears.
So, my point...
Learn both and be ready to do both. Unless you want to turn clients like these away (note - they were paying good).
Sep 26, 2006, 02:56 #2
- Join Date
- Jan 2006
- Yorkshire, UK
- 0 Post(s)
- 0 Thread(s)
I can do both and I'm what you'd probably call a "New coder", I agree though, although I find it wrong, clients are always right.
Sep 26, 2006, 03:03 #3
- Join Date
- Feb 2006
- Bedford, UK
- 0 Post(s)
- 0 Thread(s)
It depends what the client is looking for though. For instance, I don't believe in using tables for layout or frames - I just won't do it anymore.
If a client wants to insist on a table layout or frames (hasn't happened to me yet!) then I'd walk away because it's not the way I work and wouldn't be the site I'd want to produce and I wouldn't want it in my portfolio.
Sep 26, 2006, 03:12 #4
Thats fair enough, if you are prepared to turn these clients away. But a lot of us don't want to turn these client away.
Take the stock control system, that was just a snapshot of a much larger system which included sales, accounts and a load of other stuff. Changing the DB would have resulted in changing the systems for other departments.
They had already had a consultant inform them of the problems that their system was causing (mostly performance) but they also knew that updating the whole lot would cost in excess of 20 to 30k Maybe more.
Additionally, the scare mongering didn't work as they had already fell victim to it with the whole Y2K thing, they had the whole system updated to be fail safe for the post 2000 dates and had spent a huge amount of money.
The sad fact is, a lot of companies DID take advantage of peoples naivety and the fact they could scare people into spending way more than they had to.
When they learnt that Y2K wasn't as deadly as hyped they felt a bit ripped, rightly or wrongly they weren't falling for it again. I think it turned out that their system would have survived without modification.
Generally speaking I won't go tables and frames, avoid flat file DB's and such. If the client requests it I try and point out why the new standards are better, but there are a lot of well established companies out there who are willing to pay a LOT of money for new stuff but want it done the old way.
One of the big things I am hitting out at here is that bigger companies often have large integrated systems, while the user end software often gets updated, there are parts that fall behind. I don't want to knock a market area but I have found industrial is probably one of the worst for this.
Sep 26, 2006, 03:37 #5
- Join Date
- May 2006
- Aurora, Illinois
- 0 Post(s)
- 0 Thread(s)
I started designing Web pages/sites in 2002, while most designers were still practicing the trade using tables--CSS had just started taking off as a viable mainstream tool at this point (ok, so it was 2001, but still). The very first site I built used frames--and some ugly JScript (hey, I was just starting out, I had no resources to learn from aside from what was on the Web back then, so at least I had the excuse not to know better back then) to make the menu work the way I wanted to. Then I tried switching to tables, and found it just didn't work the way I wanted to. I was stuck, and didn't have the slightest clue as to what would be the best way to create a Web site was. I was about to give up (and I'm notorious for not giving up on something that I truely believe in or am involved with) until I saw a book on HTML and CSS at my local library. That book was HTML For the World Wide Web Visual Quickstart Guide, 5th Edition with XHTML and CSS by Elizabeth Castro. Needless to say, I never looked back.
While I do agree that knowing both the old and new ways is an advantage in this industry, I personally stick to the modern standard as much as possible. If I were ever to run across such a prospective client that wants things done the old way, I'd probably take the job, but bring in a person who knows how to code to the old (non) standard to review my work and make sure that I'm not screwing anything up until I bring myself up to speed.
Why? Because I see a possible long-term relationship with these prospects. They've been burned before, and are loathe to trust someone right away with such a "new and radical" idea as Web standards. If I can retain them for a year or two, I might be able to persuade them to upgrade their system. Afterall, at the end of the day, business is not about the size of your profit margin, but about the relationships you develop with other people and businesses. And once the client has gained my trust, by then their current system will either need the overhaul anyway, or they'll probably want something new and will be more than willing to come to me with the job offer because I already took the time (could be a year or two, could be more) to cultivate a healthy working relationship with them in the first place.
I know, it's a radical idea, but hey, it could happen .Save the Internet - Use Opera | May my mother rest in peace: 1943-2009
Dan Schulz - Design Team Advisor | Follow me on Twitter
WordPress SEO Checklist | What WordPress Plugins Do You Use?
Web Standards Curriculum | Image Free Equal Height Columns
Sep 26, 2006, 04:25 #6
Originally Posted by Dan Schulz
- Join Date
- Oct 2005
- Brisbane, QLD
- 0 Post(s)
- 0 Thread(s)