Page 3 - The future of forums.ds?

The fact that there are already so very many mods in place means that an upgrade will already be an extremely major job. As I presume the HTML outputted is controlled merely by vB's HTML templates, this should be a relatively minor change to re-implement during an upgrade, compared to all the mods to the PHP codebase itself.


It's not for kicks. It's for speed, cash, accessibility, and the happy extra of practicing what you preach.

The speed and cash aspects, as I've already explained, are both improved by having less markup to send out. In fact, these are essentially the same reasons that they implemented the stuff described on the link pabloj posted. And clean code would make a hell of a lot more difference than removing spaces from your HTML.

The added 'bonus' of accessibility is important these days. Site owners should be concerned about alienating disabled users now that there is solid technology in place and standards that will make your site usable in screenreaders if you just follow them. The legal issues over disability discrimination should serve merely as confirmation that it's time to do something.

Devshed has the additional reason that it is actually a site teaching web development techniques. Many articles detail standards compliance and why it's a good idea. How much credibility do you think it gives the site when someone reads such an article, understands why standards should be followed, and then validates the article they read, just to try it out? How does it look when a page of Dev Articles' XHTML Explained fails to validate as HTML transitional, with 376 errors?


I still don't feel that modifying the site templates to output valid markup would be as horrendous a task as has been suggested, given that the site's markup apparently comes from templates. It shouldn't be an enormous job. It's something that would improve load speeds and save money. That's not just 'nice', that's the sort of improvement you should care about if you're running a web site.


Another point that occurs to me is that Wikipedia may not be making profit, but they're still balancing their funds. What they waste on development or excess bandwidth they can't invest in better hardware. They have just as much reason to be financially sensible as a business, and there's no reason to suggest they're blowing cash by using compliant code. Quite the opposite.

Also, while pmam suggested XHTML, strict compliant HTML is arguably just as sensible at this stage. Even if the code doesn't end up entirely compliant anything, just cleaning it up a lot could make a serious difference to file sizes.

/warning beers on board

you've too much time on your hands ...
I'm not being too smug, but from a business vs nfp view, and even as a business vs nfp view, if it aint broke, don't break it


this has more to do with what government is obliged to deliver, the rest is up to site owners, it's a good idea but NOT a pre requisite for webdom

As to credibility for web standards ... it's easier starting out, but an established business, there's a significant cost attached.

The notion that bandwidth is pay per use as petrol cracks me up!! Where do you guys buy bandwidth, you need to have relationships in place with upstream providers that will fit your business model, and grow when required, and you pay in hindsight ... suffice to say in the real world it's a little different ... but not a lot

I agree with the notions put forth, but realistically ...

I'm going to spend much of today doing paid development work and completing coursework, rather than on beer. Congrats on your 4217th post, by the way. I think I'll just go ahead and make my own analysis on how well I'm doing with my time. If I spend a few minutes trying to improve an online community I've spent a lot of time at, I probably won't lose sleep over that.


It's about improving the site. Like how an insanely popular shop that only has one store might make a lot of money and be 'not broke', but could make a huge amount more money if they just opened a second outlet. If nobody improved anything that worked, there wouldn't be a Devshed. There wouldn't be anything much, actually.

The Devshed folks have implemented tons of changes which were 'fixing what's not broke'. That's because they were done to draw traffic, improve speed, or make cash. This suggestion would do the same.


The cost is well worth it for the improvements in speed and the cash saved long term. It's even more worth it when people are offering to make the changes for you for free, meaning that there is effectively no cost attached. Any SEO issues from altered code would be more than recovered from very quickly, because search engines also favour clean code.


I suppose I meant 'transfer'. And even with a large 'unmetred' package from a data centre, you're going to pay more overall if you end up needing more throughput. Bandwidth does cost money.

The speed improvement will also not only 'be nice', but will increase the number of people who stay rather than being put off by load times. That's more people clicking ads.

And then there's the search engine placement I just mentioned. DS could end up even stronger in this respect long term, which again means more ad revenue.


I still don't see how this is bad business sense.

the Toyota philosophy eh burning snowman..? always improve..

BurningSnowman, with a project that you're suggesting people are willing to undertake for free, there is a significant risk. That was my reference to too much time on your hands.

And I thank you for congratulating me on my 4217th post, and I am in deference to your holier than thou position...

What we have here is a difference of opinion, you are suggesting a non trivial rewrite, and are oblivious of the risks involved, and thus far are unaware of the scope of the project in that the requirements for such are unknown - now that's admirable, the old hail mary ...

I guess I'm just too old, but I can't see the difference being all that great. XHTML is the new manna, will you call all my clients and suggest they pay me, or you for that matter to make their sites compliant, and what do you expect their answer to be ...

I know where you're coming from, Ax. but compliance with standards is very important.

If you were to tell them it would get them better google rankings and therefore more money then they might change their mind.

Given a while to do it, I would have the time to do this myself. I have some time on my hands to do useful work, but certainly not too much. Other people have also expressed an interest in something collaborative in this thread, but I would be prepared to rewrite the templates myself. I'd have an impressive sounding job behind me for the ol' portfolio, and Devshed would have the numerous benefits I've already listed.

I don't see what you mean by risk. I presume a new template would be analysed and tested carefully before use on the live site. My markup does not have tendencies towards spontaneous combustion. How is clean code a 'risk'?

As I mentioned, XHTML might not be that advantageous, we're just talking clean HTML here. Clean HTML is not a new fangled concept: the W3 specs go back more than a decade. Exactly what disadvantage would there be that nullifies all the reasons I've given to use good markup?

...in response to LP.

better google rankings != more money automatically, good product is essential, and value for money sells more IMHO.

I'm not a total ogre, I agree with your position on standards, and also Burning Snowman's (believe it or not) I'm just saying revisiting a site for a refit is not a task to be taken lightly, and that without some form of feasibility study to determine returns on investment would be pure folly

...I'll respond to Meltydood after a coffee

Risk #1:
Persons undertake to do work for free might not properly motivated to complete the task, Sourceforge is littered with similar ...
Risk #2:
Dates for completion may become part of a bigger project timeline, and a seemingly inconsequential cosmetic refit, might end up on the critical path for paid developers, and have financial consequences
Risk#3:
No plan in place for testing, no budget for test rig, you'd need a battery of testers as well to ensure that the templates work as specified,
Risk#4:
No team structure in place can give rise to political ambition, which can lead to fall out between volunteers
Risk#5:
A misunderstanding, or informal specification might have repurcussions in the -ve on the SEO - I'm not saying it will, but it might.

They're just off the top of my head, I'd suggest that #1 shouldn't be an issue with yourself, because of your ardent defence of your point, but a realistic timescale would need to be in place, and some committment would be required from all project members to be in a position to offer X hours a week, and this should not jeopardise full time work committments (another risk inherent when working for $0 is losing your job because it's possible to become fixated on the project)

Yours
--Ax

All these risks apply to "clean" product offerings