Please review my business software web site

Yes yours is much better than forecast pro but yes vanguardsw has a cleaner look, the information is in bite sized chunks so what they are selling comes across clearer without being hit with too much text. Blocking helps to break up the content and you should direct the viewer where you want them to go. Think of your website like a sales rep I've only written one blog (hangs head in shame lol) and it was about how to make sure your website is working (http://dbyt.co.uk/website-working/) Your website should flow like your sales pitch and dont bombard them with too much into once they have bought the product you go into alot more detail then. Your titles and navigation are good, just your content and calls to action need work. You want the website to generate you sales while you sleep.

 

Thanks again for your response, which I do find helpful!

I know that the subpages do still need more work on getting the heading tags sorted and some of the layout etc.. It's a work in progress.

Overall, I think the majority of px usage, which you criticise, comes from Bootstrap. There is some inline css-ing which I know isn't good but I've used it for one-off elements only. I can live with that.

I'm afraid we will never agree on the use of frameworks. Whilst hand coded, bear-metal coding is always likely to be more efficient you have to accept (surely) that frameworks have a role to play. I'd liken it to the evolution of programming languages. Virtually no one needs to code in assembler any more because there is C, C++, VB, Java etc.. Modern programming languages use more cpu cycles than correctly-written, hand-coded assembler but hey, computers have got thousands of times faster since the assembler days and in the vast majority of cases productivity is more important than saving a few cycles. Ditto the internet - speed has increased vastly over the last few years, even on mobile. I'm not convinced that hand coding a site would make it meaningfully faster than a Bootstrap site. So, for me, I'll take the productivity.

You're wrong, by the way, on many of the animations and fades on my site. It is all css - see http://daneden.github.io/animate.css/.

The carousel graphics are quite large, I agree, but they have been compressed using https://tinypng.com.

If I haven't completely alienated you by now and you're still thinking of rewriting a couple of my pages as you offered in your post I'd be most interested to see what you come up with! It's a very generous offer, thank you. If I can get a template that doesn't use Bootstrap and looks great you may well have converted me!

All the best,

Pete

 

You're completely right and your blog post is good. I think I 'get' all the advice and indeed feel knew a lot of it already, but knowing it and executing it effectively are very different and my closeness to the product makes effective execution harder for me than it should be.

Thanks for the feedback.

 

Its a good site. i am not a techie so can not comment on technical aspect. but look wise, I have two suggestions

1) put the blue navigation bar above the screenshot image

2) and put the "News" somewhere in middle of page not at bottom of page

hope it helps

 

Looking deeper I saw a lot of PT in your own stylesheet, which is also flawed. PT is for print, not screen... but yeah, the steaming pile of bloated halfwit manure known as bootcrap (I'm such a fan) does piss all over the page; part of why I would never use it -- another part being that by itself gzip compressed it's roughly the upper limit I'd allow my entire CSS for an entire SITE to reach WITHOUT minification or compression.

Something I'd NEVER allow in my markup with all but the rarest of circumstances (width to convey meaning like a progress bar or graph... and, yeah, just that!). Reason being how does your SCREEN style make sense on anything else? STYLE attributes have no media targets, unless you use media queries and that breaks backwards compatibility AND makes it even more bloated.

100% of the time people use <style> they're doing something wrong. (even if google pagespeed is blowing smoke up people's asses telling them to do it. 99% of the time the same can be said of using STYLE as an attribute. It's just code bloat nonsense and indicative of bad CSS planning and/or lack of leveraging semantics.

Productivity? WHAT productivity? Writing more HTML than you need? Having to learn every style they set up just so you can override it to get it to do what you want? Making pages take three times longer to load? Sending you out to waste money on CDN's because you end up with hundreds of K of scripttardery and unused styles for NOTHING?

When people say "productivity" or "benefits" on things like HTML, CSS and JS frameworks, I can only assume they don't know enough about HTML, CSS or JavaScript to have an informed opinion on the subject. They make more code, not less. They make less accessible websites. They destroy graceful degradation and by their very nature piss on the markup from so on-high you'd think the almighty just got back from a kegger.

JQuery, Bootstrap, YUI, prototype, LESS, SASS, Blueprint, Grids -- developers are dumber for ANY of this crap even existing!!! That anyone sees a legitimate reason to use these steaming piles leaves me utterly and completely flabbergasted.

Which by itself uncompressed is the same size I'd allocate for the entire stylesheet for an entire site. It would be cute as a cheat sheet to copy the styles you're actually using from, but to blindly include all that crap all the time? Plow that type of thinking... particularly when it's just annoying crap that makes it harder to start using the page as you're stuck waiting for everything to "slide into place" after the ~15 seconds or so waiting on loading.

Admittedly for some reason from here cloudflare's CDN adds ridiculous overhead time -- but again if you need to resort to a CDN for ANYTHING on such a simple site... well, as I tell people all the time about a great many things "You need that, you're probably doing something wrong!"

Like relying on bloated frameworks and libraries for "gee ain't it neat" nonsense that doesn't belong on the site in the first place.

When most of them shouldn't even be png... tinypng has stripped the color depth which is why things like the gradient behind that guy looks like banded crap (they didn't even dither) and generally does as much damage to the image as using a jpeg would -- at which point use a JPEG. Your three slides total I'd be SHOCKED if "properly" encoded and set to a more practicable size (1500px as a SLIDE is something I'd NEVER put on a site -- particularly since 8 bit or lower color resizes like garbage in some engines) that they needed more than 192k total -- and really I'd be aiming for around 128k as the upper limit on those.

Don't worry about that, unlike SOME people around the various web design forums I have a remarkably tough skin -- and you are at least listening and reasoning, instead of sticking your fingers in both ears and going "la la la la" like SOME people around the various web design forums.

RIGHT after I posted yesterday I was given some info that let me continue on my own project, but I'm at another hurdle -- In Electron (formerly atom shell) <webview>.goForward and <webview>.goBack are slow as molassas, like two seconds of overhead! -- so I'm going to start in on that rewrite now.

First thing I usually do, well, check out my thread here:
https://forums.digitalpoint.com/threads/progressive-enhancement-design-from-the-inside-out.2759516/

I start out with the content of the page and then mark it up semantically -- this would mean tossing all your existing markup and just looking at your CONTENT and saying what things ARE, not what they are going to look like. That would go something like this:

<h1>
	<a href="/">
		Data Perceptions
		<small>&bull; Prophecy&trade; Sales Forecast Software</small>
	</a>
</h1>

<ul>
	<li><a href="/">Home</a></li>
	<li><a href="screenshots.php">Screenshots</a></li>
	<li><a href="spreadsheets.php">Using Excel?</a></li>
	<li><a href="prophecy.php">Features</a></li>
	<li><a href="demoOptions.php">Demo Options</a></li>
	<li><a href="faq.php">FAQ</a></li>
	<li><a href="caseStudy.php">Case Study</a></li>
	<li><a href="whitepapers.php">White Papers</a></li>
	<li><a href="contactDetails.php">Contact</a></li>
	<li><a href="aboutus.php">About</a></li>
</ul>

<h2 >
	Prophecy&trade; Sales Forecasting Software<br>
	<small>
		Produce <a href="overview.html" alt="Click here for a Prophecy overview!">better, more accurate sales forecasts</a>!
	</small>
</h2>

<hr>
<img
	src="images/slide2a.png"
	alt="Sales forecasting software demonstration - please check the software demos here!"
>
<a href="demooptions.html">View Demo</a>

<hr>
<img
	src="images/slide1.jpg"
	alt="Book a sales forecasting software presentation from Data Perceptions!"
>
<a href="contact-details.php">Book a Demo</a>
	
<hr>
<img
	src="images/slide3.jpg"
	alt="Sales forecasts provide vital input into your S&OP process.  Optimise the forecast accuracy using Prophecy!"
>
<a href="prophecymore.html">More information</a>

<hr>
<ul>
	<li>
		Prophecy&trade; is a sales forecasting software solution aimed at helping businesses develop better sales forecasts.  Achieve greater accuracy and superior productivity compared to
		<a href="spreadsheets.html">
			spreadsheet and non-purpose built solutions.
		</a>
	</li><li>
		Prophecy&trade; supports multi-user sales forecasting over hierarchies of products and customers though time.  Compare forecast with previous years and budgets.  Extend sales forecast quantities through to revenues, cost of goods and margins.
		<a href="screenshots.html">
			See these screenshots for a better picture
		</a>, or <a href="benefits.html">
			here for a full list of the benefits Prophecy will add
		</a> to your sales forecasting process...
	</li><li>
		Prophecy&trade; is currently used in companies world-wide to forecast products as diverse as cosmetics and toiletries, breakfast cereals, cleaning products, white goods, pet products and building materials.
	</li><li>
		Prophecy&trade; is a proven, cost-effective solution to multi-user sales forecasting.
		<a href="prophecymore.html">
			Click here for more information on our sales forecasting software
		</a>, follow the links below, or give Data Perceptions a call right now at 01494 785574 (UK) to speak to an expert.
	</li>
</ul>

<hr>
<ul>
	<li><a href="prophecymore.php">More Information</a></li>
	<li><a href="spreadsheets.php">Excel Sales Forecasting?</a></li>
	<li><a href="overview.html">Why Prophecy?</a></li>
	<li><a href="benefits.html">Benefits</a></li>
	<li><a href="testimonials.html">Customer Comments</a></li>
</ul>

<h2>News!</h2>

<h3>July 2015:</h3>
<p>
	Data Perceptions is proud to announce a full 64 bit version of the Prophecy sales forecasting software client.  It provides at least 15% faster performance and unlimited Prophecy report size.  Please
	<a href="newsletters/July2015/index.htm">
		read our Newsletter online here
	</a> for more information.
</p>

<hr>
<p>
	Telephone 01494 785574 (UK) to talk to a Prophecy expert now!
</p><p>
	Customers:
	<a href="prophecysupport.html">
		Click Here for Data Perceptions Live Support Service
	</a>
</p>

Code (markup):

The H1 is the heading underwhich all other headings on the page are subsections -- hence the site title being the best candidate for that. I've modified that title to be better informative. H2 indicate the start of subsections of the H1, H3 the start of subsections of the H2, and so forth. The HR indicate a change in topic where a heading is unwanted/unwarranted and does NOT actually mean "Draw a line across the screen". SEMANTICS!!! Of course since heading navigation should let you skip past "navigation" sections and get around the page quickly, and headings divide the page into sections -- well, there's a reason I consider HTML 5's HEADER, FOOTER, SECTION, ARTICLE, ASIDE and NAV tags to be halfwit code-bloat bull more meant for the people who until recently were still sleazing out presentation HTML 3.2 and the proprietary crap that followed, and slapping 4 tranny on it. Now they get to wrap 5 lip-service around the same outdated methodology then slap each-other on the back over how "modern" they are.

At this point DIV and SPAN are NOT added as they imply zero semantic meaning. Those are added during styling but only once one has expended what can be done to the semantic tags.

Oh, and what's with using KBD for phone numbers? There's no input field for them to be entering data, so much like SAMP that's really not what that tag is FOR.

How about even with the scripted slideshow I very much doubt that by the time I have the home page done the markup will be more than 5k, or that the CSS and Scripting would break more than 10k apiece? We're talking 25k as the upper limit by the time the home page is done, and I very much doubt that the CSS would break 24k for your entire SITE! Likewise the only other thing scripting-wise that seems the least bit useful would be the lightbox effect, and again if that takes more than a few K of scripting you're doing something wrong -- particularly given how barebones that existing one is.

Laughably, this post sat here all morning with me forgetting to hit "post reply" as I got waylaid again. Another post coming right on this one's heels. For now, have a look here:

http://www.cutcodedown.com/for_others/peteb99/semantic/template.txt

I put it there as a TXT so you don't have to hit view>source. That's just the semantic markup without layout, which renders thusly:

http://www.cutcodedown.com/for_others/peteb99/semantic/template.html

Which is what screen readers (devices that read the page to you), other non-visual UA's, and search engines get. Remember, search engines don't have eyeballs.

Once DIV, SPAN, classes and ID's are added, the markup ended up this:

http://www.cutcodedown.com/for_others/peteb99/static/template.txt

Which renders thusly:

http://www.cutcodedown.com/for_others/peteb99/static/template.html

As with ALL my examples the directory:
http://www.cutcodedown.com/for_others/peteb99/

Is wide open for easy access to the gooey bits and pieces. HTML+CSS+SCRIPTING is 23.5k TOTAL, only 5k of that is markup, 8.5k of scripting and 9.95k of CSS. Pretty close to my guesstimate. Switching some of the images of JPEG and getting a bit more zealous in the encoding brings the total page size down to 158k in 8 files -- the smaller slides may not look as good on retina displays, but really that's why goofy space wasting crap like slideshows doesn't usually go on sites I develop; a laugh when I even have my own scripts for doing it. (Just because I don't like it doesn't mean I don't know how -- knowing how is why I know where to stick that knife and twist!)

I threw in some "off the shelf" scripting I had handy to give it a similar slider. I cluster the controls for simplicity and easy of access -- putting the buttons for forward/back and each item all over the place is a PITA from a usability perspective -- it's usually best to put them all close together. It functions in legacy browsers though the appearance without CSS3 is "degraded" -- honestly, that's FINE as one shouldn't bend over backwards to make it perfect in IE8/earlier. If the page WORKS, that's good enough for people who refuse to join us in THIS century. If you REALLY cared things like the buttons on the slideshow could be replaced with PNG instead of being CSS generated.

The script also traps the .showMenu and .hideMenu links so that document.location.replace is called -- the show/hide menu functionality is entirely CSS driven and works scripting off, but it fills up the history. That scripting assist just enhances it by not registering the change in the document history -- again, as I often say GOOD scripting should enhance functionality, not supplant it.

I'm going to start in on breakdowns section by section of the how/what/why of each of the files -- then I might use this as an example to show my "poor man's template" approach that you might find more useful (particularly for site-wide layout changes) than the static files, without resorting to a full blown CMS. I was planning on making such a tutorial for a "will launch someday" website. (kill two birds with one quijada)

 

That's a VERY good suggestion, as that belongs farther up the page -- again why crap like that space-wasting slider garbage should probably get the Gimli treatment... and if you can't find Gimli, I'm sure Zoltan Chivay has an axe handy.

Though honestly, that's why I'd be going with a columnar layout to put certain things up top when there's room, but have them drop below the content when there isn't. Again, see the link in my previous post to the "responsive layout" post I made here on DP -- where you can make 2 columns, 3 columns, 1 top area with two columns below it, or one column from the same markup -- WITHOUT throwing endless meaningless vague asshattery like:

<div class="col-md-12">
                    <div class="row">
                        <div class="col-sm-6 col-md-4">

Code (markup):

... at it for no good reason other than code bloat and completely pissing on the concept of separating presentation from content. Say what things ARE, NOT what they are going to look like.

 

Alright, let's break down the semantic markup first without all the pesky (meaningless) DIV, SPAN, classes and ID's in the way.

follow along with:
http://www.cutcodedown.com/for_others/peteb99/semantic/template.txt

I condense the doctype, html, head and meta[charset] to a single line as a reminder that:

1) nothing other than whitespace should EVER go before the doctype or between it and the opening tags of those document elements.

To that same end you'll also notice I do the same with </head><body> and </body></html> -- again since no tags, comments or CDATA nodes should EVER exist between those elements (or after </html> for that matter!) putting zero whitespace between them makes it less likely for people to accidentally (or intentionally out of ignorance) put things there.

2) we should tell it what character encoding is used ASAP should the HTTP headers fail. Admittedly few if any browsers actually obey that META, but it's still a good idea.

Inside <head> I always follow the order META, LINK, TITLE. It's just easier to put things in that way.

I also no longer put <SCRIPT> inside the head -- who needs that ASYNC crap when you can get the same if not better functionality by just loading all scripts right before </body>? NOT that this applies here (yet)

The keywords meta is called keyWORDS. It's not keyphrases, it's NOT keysentences, but keyWORDS!!! It should be seven or eight SINGLE WORDS (exception being proper names) that exist between <body></body> as CDATA (plaintext), preferably totalling 127 characters or less (some people say 95 or less!) that you would like a slight uprank on. You go outside those parameters and you can guarantee that meta will be ignored -- in fact that's why most people think it doesn't work and is ignored by search as nobody has ever used it properly! When it came time to slap down abusers, everyone just thought it was broken instead of researching what it means, what it is for, or how to use it!

Your description meta was fine -- exactly what it should be; a brief natural language description of the page to be shown below the TITLE on the SERP.

I changed up the title to be a bit more accurate -- EVERY subpage should have it's own unique title so people can tell them apart if they open multiple tabs; something to keep in mind later.

Once we get past that we get into the BODY. Again a H1 is the heading under which everything on the page is a subsection -- the only logical candidate for that in most content is the site title/logo as displayed. Making it an anchor to the home page always makes sense, and the small tag does not MEAN the text "must be shown smaller" but that said text "would be shown smaller" in a professionally written document. SMALL, B and I are NOT presentational tags, if they were they'd have been deprecated. There ARE grammatical reasons for text to be smaller than it's accompanyment, and using small here means "would be" not "should be". A subtle distinction lost upon a great many. Certainly makes more sense than opening a H2 after the H1 would there -- which laughably a lot of people seem to do and how the idiotic (now removed from the specification) HGROUP tag seemed to work. It's not like we're starting a new subsection of the page (what an H2 ACTUALLY means).

The menu is a list, we just make it a list. YAWN.

The next part is the start of the content, so that's a H2 to say "starting a new section" -- once again I went with a small tag here since a P didn't quite seem accurate, though the slides kinda screw up the semantics here. (again, not a fan)

Before each slide I put a HR to say this is the start of a new subsection of the page. It gets the image, the anchor, and we move on.

Likewise the feature list is not part of those slides, but does not have a heading so it too gets a HR for the semantic break. Don't worry, we simply hide them from view when screen rendering takes place.

Oh, I switched all the utf-8 TM symbols for entities. Even though I always deploy as UTF-8 when editing manually or in the template I try to use entities so that if need be the encoding can be changed on the fly... Though honestly, I still say if you are working on an English language website and can't say it in ASCII characters 32..127, it probably has no business being content on the page.

Then there's a list of links, that too is it's own section without a header, so again another HR to say "starting a new section"

The news has a H2, so that's a start of a major subsection of the H1 and doesn't need much else in the way of help. I assumed you'd have multiple news items in the future, so I made the date of the news a H3 and the content a paragraph.

Then the footer, which also doesn't have a heading so again a HR. I took the more useful footer from the subpages and would try to use that same footer on every page.

... that's the semantics -- now we start adding our DIV and SPAN for layout - follow along with:
http://www.cutcodedown.com/for_others/peteb99/static/template.txt

We add a viewport meta to tell mobile that we know what the *** we are doing and not to second guess us. Those are currently the only values that should be set in that meta -- people right now are throwing all sorts of garbage like maximum-scale or other values that disable zooming at it because they're inept halfwits who don't take the time to understand usability. Makes me want to punch someone in the face 90% of the time I see the crap people are sleazing into that meta. What I have there? Use no more, and no less!

A <link> gets added to show the favicon, which I redrew to try and be clearer as I couldn't make out the original, but saw it in larger res in one of the other pictures. Still doesn't scale well, but it means well. do NOT say "type" on the favicon as that can actually break it in some browsers!

The CSS <link> has a complete media stack. Laughably HTML 5's alleged validation (which is effectively meaningless) claims that you shouldn't say "projection" or "tv" anymore -- tell that to all the people still using devices like the Wii that will override the screen.css with it's own rules if you don't say "TV" or how many browsers will report themselves as "projection" instead of (or in addition to) screen when in "Kiosk" operation. It was stupid of them to remove these values just because SOME browser makers never bothered using them properly in the first place. NOT that a HTML validator should be saying what the valid values for MEDIA even are. That's CSS and/or browser vendor's job -- hell, it's WHY it exists!!!

For a screen layout, "screen,projection,tv" should be used for all the reasons I just stated. You should NEVER use "all" as that rarely makes sense, nor should you EVER omit a MEDIA target from a stylesheet LINK. You see code that omits media or uses "all" as it's value, you can pretty much assume whoever wrote it doesn't know what they are doing! (just like the <style> tag and style="" attribute)

DIV#TOP -- Inside body the first DIV got a meaningful ID so that if later on you wanted to add a "back to top" link at the bottom, it would just be <a href="top">back to top</a>. This DIV exists so that we can make that dark grey bar area for the logo and menu.

Inside the H1 some span were added to let us target the various bits and pieces for media queries. NO extra classes needed since a page should only ever have one H1 and we have sufficient nesting to handle it.

DIV#MainMenu -- this wrapping DIV has an ID for hash targeting, and two empty anchors (which we'll plug generated content into for small displays) to either go to #mainMenu or remove it. Using :target in the CSS we can leverage that to show/hide the menu without using scripting -- the only scripting assist we would consider is to make these two anchors not fill the history just becuase you opened and closed the menu. That script should hook onto the markup instead of having it IN the markup.

I also added the 'current' class to the anchor as we'll be styling the anchors, NOT the LI.

Now, for a moment look at my closing comments on the DIV. I like to see what's being closed, and since I use VERBOSE id's and classes it's not like I need opening comments. I laugh every time I see dipshit nonsense like this:

<!-- begin content -->
<div id="content">

Code (markup):

REALLY? Opening a DIV called #content is the start of the content?!? Whoddathunkit?!?

Likewise I don't say "end" in the comment, that's what </div> means and if you're too stupid to know what </div> means comments, well... What's it that Ron White always says? "You can't fix stupid"?

I put the comment BEFORE the closing tag because 1) It stands out more to me that way, and 2) more importantly comments between sibling-level tags can trip rendering bug in IE and some versions of FF if positioning or floats are involved. I've seen people waste endless hacks on trying to get around that when all they needed to do was either delete the markup comments or move the comment before the close instead of after. Which is why garbage like Dreamweaver's "templating system" can actually cause websites to render improperly!

DIV#content -- the outer wrapper for our content area. This MAY get a name change if the content layout gets more complex, but it will do for now. This is used to make the white background (the dark we'll do on body as a fallback for if flex fails) and to flex to push the footer to the bottom if the content height is smaller than the display.

DIV.widthWrapper -- I always use this className for width constraints. Sometimes it will be nested, sometimes it will be on it's own. It's just handy to be consistent. In this case all it will be doing is setting a max-width so long paragraphs aren't hard to follow. Since you don't have columns, that width is going to be a LOT smaller than what you were using as those paragraphs and LI were REALLY painful to try and read.

h2.homePageProphecy -- this one gets a class as it's likely different from all the other H2 you'd have. I would actually consider from a content standpoint axing this heading entirely and putting ACTUAL content in instead of some goofy pointless image and redundant text... but we'll leave it for now.

DIV.slideShow.delay_3 -- the slideshow script I use leverages the markup in a more meaningful manner so you need less markup. It also allows for multiple slideshows on the page if desired. The .slideShow class if present tells the script this DIV is a slideshow wrapper. the delay_3 tells it that we want a 3 second delay between updating to the next page.

The DIV inside it are all siblings and so are slides. NO CLASSES NEEDED unless you want to start adding DIV inside them. I avoided this for your example by using SPAN instead.

All controls and other elements will be added by the script.

ul.features -- apart from adding a class so we can style it, there are zero changes here.

ul.innerMenu -- same, no real changes apart from giving it a class.

div#news -- this div was added just to wrap the news area for easy styling without slapping classes on every child element.

We close out .widthWrapper and #content, and we have...

div#footer -- I added the wrapper as a styling hook, and pulled the second paragraph as that anchor isn't quite a complete thought/paragraph and stands fine on it's own.

<script src="library.js"> -- whenever possible I try to use one and ONLY one script file for the template, only adding extra separate scripts for things like social media plugins (which are enough of a bloated wreck we have zero control over without making things worse by bloating our own crap). HTML 5 now says the TYPE attribute defaults on SCRIPT to text/javascript, which it pretty much always has in ever browser it was just not stated in the spec. One of the FEW things in HTML 5 I actually approve of.

Though honestly, I still write as HTML 4.01 STRICT then just deploy as HTML 5... We actually need a better spec than the mess the WHATWG sleazed out and called 5... we really do!

... and that's the markup. I'll start writing up an explanation of the CSS next... then try and explain the scripting.

 

Hi there,

This is just a quick holding reply as I really need to spend time carefully going through all of your posts. (It is Sunday here and I try to stay OFF work things over the weekend... don't always succeed!)

Thank you VERY much for the time you've spent on this - you put your money where your mouth is by creating that template and I really appreciate it a lot.

Although I'm still less concerned about shaving bytes than you are, fact is, in my opinion, your template looks nicer than mine! My only small disagreements are that, ideally, I think the buttons above the 'News' bar should have consistent size. My button text makes that hard so perhaps I'd make the 'News' bar less emphasised and make the buttons into a button bar, like they are on my 'live' version. However, that apart, I do have to take my hat off to your design!

Now, that means I'm converted to your design skills, for sure. But I have to confess I'm still not totally convinced that your war against Bootstrap etc. is quite fair. It's not for you, I get that, and if you can generate a great looking site with 'to the metal' html/css like you clearly can then it would be silly to use it. However, web design isn't my core business (and OK, it shows!), I have loads of other stuff to do to be a 1-man ISV (I think that's what I am!) so I still feel Bootstrap etc. gives me a great speedup versus attempting to hand-code my website, as well as getting a decent default 'look'. I don't think potential customers of my software are the types of people who are going to view my website source and make judgements from it - they (I) want a professional looking site and compelling / interesting copy. (By the way, I'm using Pinegrow to author these pages and it's Pinegrow, plus my clumsy manual stuff, that's creating the html/css. If I have some unnecessary 'row' within 'row' within 'column' bootcrap then that's probably me and not Pinegrow (which I think is an excellent tool, but doubt that you will! ).

I guess you will say it's because of the silly carousel that you have retained, but when I speed-test the load times both versions load quickly but, actually, the Boostrap (i.e. live) version actually loads faster:

http://tools.pingdom.com/fpt/#!/bhkohK/http://www.cutcodedown.com/for_others/peteb99/static/template.html --> 965ms

http://tools.pingdom.com/fpt/#!/bNzwct/www.dataperceptions.co.uk --> 749ms

I don't see the difference as particularly significant but do you think it shows that, despite the crap in my 'live' version, the page load time is actually not as punished as some would think it should be? And not particularly an issue?

I will read your posts again and try to extract the full value that you've put in them in the week. It's not that I don't want to learn / improve! However, given I've said I like your design more than mine, I wonder whether you would you mind if I actually used it to replace my design? I'd be happy to add credit etc. to you on my site. I could then put Boostrap into cold storage...

Many thanks again!

All the best,

Pete

P.S. FWIW, this is the previous design for the website. It WAS hand-coded but I felt it looked a bit amateurish. I hope that puts the current design into context! )

 

First off, got waylaid yesterday doing the CSS breakdown... I'll get on that when I can to explain the thinking behind it; sadly this is going to be a crazy week for me. (moving two different friends, three projects up in the air...)

A lot of that is the consistency of spacing rules I used and it being EM based. It's easier to remember "just use 1em or 1.5em padding" -- more so when EM is NOT a fixed size and could mean almost anything in it's relationship to pixels.

Not compatible with responsive layout. That's a cutesy artsy design concept that falls squarely into the category I label "not viable for web deployment" -- at least if you care at ALL about usability. Really I wouldn't even have those links there as they're redundant to the menu and just feel like "fluff and filler".

It's one of those things where if you are qualified to write HTML and CSS, and understand what HTML and CSS are for, bootcrap does NOT provide any speedup -- AND it's just something else to learn that to be frank, you shouldn't learn until AFTER you have good enough a grasp of HTML and CSS to build without it.

It's fat, it's slow, it takes MORE time to develop anything useful with it, and the way it makes you think about building a website is as flawed as the dicking around in photoshop and calling it "Design". It's screwing around with what it looks like before you've said what things are -- and it's putting all the emphasis on screen and saying "screw you" to anyone not on that magical combination of resolution and screen size it was designed for. They are MORE work, not less, result in MORE code, not less, and typically result in sites that are accessibility disasters. The advantages to using them lie WHERE exactly?!?

There are simple concepts a professional site for a business with actual products should REALLY care about more than flashy animated artsy-fartsy bullshit; like:

1) CONTENT -- you know, the stuff people came to the site for!

2) ACCESSIBILITY -- not everyone is perfectly sighted, not everyone visiting your page will even be using a screen to show the site. There are accessibility norms in various guidelines (like the Web Content Accessibility Guidelines) that should at least be given SOME attention if you care at all about people actually using the site.

3) SEARCH -- search engines don't have eyeballs so they could give a flying purple fish about your layout or graphics... and without search you're not gonna have a lot of traffic unless you really get people interested and linking via social media or other distribution.

Which is why:

Is an entirely accurate statement, BUT doesn't paint the entire picture. Bootcrap based sites -- and most framework or "designer" sites -- typically are accessibility disasters. They are useless to large font/120 dpi users like myself, they are useless on media center devices, and for all the claims of being mobile friendly they are pretty much broken EVERYWHERE. Their design concepts repeatedly break (just look at your screenshots page) because they are NOT "viable" in concept much less execution. They often encourage design concepts not compatible with the above three "must have" for a website. Of course you get some of these marketing dipshits or "designer" fools who know **** about **** but talk a good game, and you'll end up hearing all the typical lame excuses to explain away what's actually important in favor of their flashy but ultimately useless rubbish.

Article I usually suggest as a "must read" on that topic:
http://www.456bereastreet.com/archive/200704/lame_excuses_for_not_being_a_web_professional/

Sadly more true today than it was eight years ago, and I know why it's increasingly true -- the marketing scammers and artsy fartsy designers are in the same boat as advertisers! While not exactly a reputable source, Cracked of all places really hit that on the head. (comedians often come right out and say the truth because they're one of the few groups who can get away with it!)

Never heard of it... but given the broken, illegible inaccessible "WCAG, what's that" train wreck that their website is, much less the disaster that the software's UI seems to be (what is it with this illegible dark colors on dark grey skin that seems to be taking over editors -- just TRYING to make it harder to use?!?) I can't say I'd trust it with anything -- but for me anything more complex than SCITE just gets in my damned way. (there's a reason my primary editor is flo's notepad 2).

Pretty much if it's showing you in the editor what the page looks like, you've already screwed the pooch. You CANNOT trust "preview panes" much less editing inside them. That type of wysiwyg crap just pisses on accessibility AND functionality from on-high. Much like other halfwit garbage like Dreamweaver, all it does is delude people into THINKING they can make websites.

I think that does an EXCELLENT job of showing what absolute BULLSHIT pingdom's "tools" are for website speeds -- lately it's like ALL the blasted tools are giving artificial boosts to CDN's that I'm just not seeing "real world" from anyplace. Certainly hosting would/should/could play a part -- but really when these are typical of my local numbers:

Your original:
http://www.cutcodedown.com/for_others/peteb99/comparisons/originalPage.jpg

Laughably that's over twenty times faster than it was yesterday as both CDN's (cdnjs.cloudflare.com and netdna.bootstrapcdn.com) were taking almost five seconds apiece for the handshaking and files from both were refusing to cache either.

My rewrite:
http://www.cutcodedown.com/for_others/peteb99/comparisons/rewrite.png

Shows exactly what it should be showing, taking half as long. I really have started to wonder how tools like pingdom and google pagespeed can be delivering such absolute bullshit reports while people continue to yum them up. The past two years both have begun reporting absolute noodle-doodle numbers that seem to unfairly favor anything using a CDN over sites that don't; even when anything remotely resembling sanity should be making you scream out loud "BULLSHIT". Google PageSpeed Insights being far worse on that to the point you'd almost think they were using it as a front to sell their "pagespeed service" SCAM (that in testing actually makes well written sites SLOWER and pisses all over functionality and accessibility in the process).

Like most of these online "tools" that were borderline useful five or six years ago, they've become such total scam artist marketing rubbish that I can't see how anyone could trust them (or their creators) for anything anymore.

But as I've discovered the past two or three years, I have a much more sensitive scammy sense than others. Gah, there's so much scam artist nonsense out there being pimped as good practice, you'd think Tony Robbins or Kevin Trudeau had thrown their hat into the web development arena.

If I put up example code, I do so as public domain. I'm generally not one of these people who gets their knickers in a twist over "I put something online and someone else ran with it" nonsense... on the basic notion that if you don't want people to take from it or use it, why did you put it online?

From strictly a layout perspective in terms of what's on the page and where it's placed, I like that BETTER. It certainly has issues like inconsistent paddings, line-heights that are too short causing legibility issues, oddball empty gaps like above the menu, the over-saturated colors... I'd maybe throw one or two plate images (likely trailing plates) but apart from that it's a more sane and rational design. That LAYOUT would be a decent starting point if it were made semi-fluid and elastic, and lost a few of the oddball spacing issues and fixed the accessibility problems, and axed the inconsistent use of color. (blue or orange, PICK ONE).

Simple things like having the contact info top right -- that's actually good design. Columnar layout is good design for screen so long as the menu is "code first" for smaller displays/responsiveness. NOT wild about that call button or the oddball image placements below the menu, but the general "section with heading" approach is sound.

Probably the only "major" worry of said site design is that it has a bit of a "wall of text" problem that will give the illiterate twitter generation dipshits the pox... of course given how poorly that copy is written (no offense, It It It IT It It ... who wrote this Thomas Jefferson? "he has, he has, he has"?) they might like it for that alone.

Images are a balancing act for business websites. You use massive pointless ones the result looks like fluff and filler to make up for a lack of actual content. You use too many the page slows down and gets annoying to even TRY and use. You use none on the other hand, and the "wall of text" instantly alienates Joe Sixpack, Susie Sunshine and the Revivalist Faith Band. Despite the art faygelah's dicking around in Photoshop claim of "engaging user experience" (typically made by people who know jack *** about UI design) NOTHING screams "marketing scam" like off the shelf stock graphics filling up a page... your actual screenshots of the PRODUCT and it's output would be FAR more effective than the graphics you are trying to use.

That said, I personally prefer that older design to what you've been working on, it just needs some tweaks for consistency and accessibility... and a few minor flourishes.

Alright, damn... got a repair job in the garage (repacking two bicycle wheel bearings since my neighbor's dumbass boyfriend thought WD-40 is a lubricant -- thankfully caught it before the bearings turned into dust -- aren't weekends FUN?) but after that I'll get back to documenting the CSS of what I did.

I may also do a second skin loosely based on that older design just to show what I mean. I was also planning on plugging the design into a "poor man's" PHP setup just to show how to simplify sub-page creation.

 

Hi,

Many thanks again for your continued enthusiasm and also your patience with me. (Er.. I'm not normally this humble, what's going on?)

Oh yes, I can see that now messing about with my original page. A shame.

I accept what you're saying but not everyone has the time to devote to knowledge acquisition, especially when there are 'reasonable' tools around. With Front Page onwards any idiot with a PC can author web pages. (Maybe early Front Page is a bad example but there are better ones...) You can see from my previous site version that I've started with a self-created template and then filled it with text (see later). Your way is better, I can see that now - i.e. write the copy first using basic html tags and then style it as a separate exercise.

It would seem that some of your criticism is justified on Bootstrap. However, for people like me with limited time to devote to web site design and limited marketing funds to pay 'professionals' I still feel it provides a decent 'leg up' into a modern looking design without needing too much design skill, or css etc. skill. I fully conceded that non-Bootstrap loads faster but disagree that the speed difference is meaningful. Yes, Bootstrap may have mobile rendering issues but as it was (allegedly) designed with a 'mobile first' philosophy I would guess these issues will be addressed eventually. For my need I still feel it's a worthwhile compromise - productivity and a reasonable default 'look' versus load time, some rendering issues. (Bear in mind my site is attempting to sell a business software application - I doubt I'll be getting many Wii visitors.)

To the best of my knowledge, Pinegrow uses the Chrome rendering engine, as do many browsers. I've previewed many websites in it, direct from the web, including the template you've created for Data Perceptions and 99% have previewed correctly, including running javascripts etc.. If you assume that it's previewing OK for Chome it also lets you launch the page into any other browser too.

It breaks the DOM structure of the page down nicely and is helpful in understanding the css against each element or DOM node.

It doesn't force you to use Bootstrap. You can just use 'vanilla' html elements and create linked css files.

It lets you directly edit the html of a DOM element picked from the preview or the DOM tree without having to navigate all the html to find it.

If that's not for you then fine. But (a) your criticism on its rendering is unfair (I was going to say "incorrect" but I'm sure there will be the odd page that it doesn't render correctly) and (b) given that you can just use it to be more productive on html/css text editing I think there is a danger one can be too prescriptive on tools. (I know you will disagree! )

Fair enough. On your stats, your version loads twice as fast as mine. However, is ~2 secs versus ~1 secs really that important? If the speedup is free or cheap then fine. For you it would be cheap and for me it would be expensive - different skillsets.

Thank you. That's most kind. It works the other way too - you are welcome to use the material that's come out of our conversations (i.e. including my commercial content collateral that's left after all my html, bootstrap and css is bombed) on any commercial or other type of site you publish. (Er.. OK, that's pretty silly of me as it's all on the digitalpoint public site already but you hopefully know what I'm trying to say - which is, if it helps you please use what you like from all of this, including my text, images etc.. Providing it doesn't impact my search engine ranking. ;-))

I definitely, 100%, totally agree with you. The last design had way too much text. That was totally the thinking that led to ditching that design and creating the current version.

I have a problem writing concisely about Prophecy. I am too close to it. I'm hoping that the new site text is a bit more impactful, whilst hopefully retaining sufficient content to score on Google.

Well, if you do decide to apply your magic dust to it I'll be most interested. FWIW, that design used php and includes for the top and bottom bits. I expect you'll say the new site has gone backwards in this respect and you'll be right!

Thanks again for your posts. They are educational, lively and very entertaining. (Providing I can retain my thick skin....)

Pete

 

I could agree with that if it weren't for the fact that bootstrap itself is something to learn -- something that you STILL have to at least learn some HTML and CSS to do anything meaningful with, at which point it takes no more effort to just learn to use HTML and CSS properly.

The accessibility failings, that such frameworks directly fly in the face of good practices like separation of presentation from content, and result in writing more HTML just to avoid writing the same amount of CSS?

Maybe I've been writing software for too long (rapidly closing on four decades at this point) but I fail to see how writing more code, using more code, and ignoring good practices gives anyone a "leg up"... though I have watched over the past 30 or so years of professional coding WAY too many people sink themselves by thinking such shortcuts are legitimate.

MOST of the reason people seem to believe such tools offer legitimate benefits seems to be what Joseph Goebbels called "The Big Lie" -- you tell a lie so many times and so many people blindly repeat it that magically it becomes the truth in people's minds, no matter what absolute gibberish delusional nonsense it is. See how "faith" somehow continues to even exist...

Just be sure you don't trust it and STILL test in actual browsers; just because it uses blink doesn't mean that represents what trident, gecko, presto or any other rendering engine's behavior... much less is it webkit or blink? Since Google forked off from webkit (absconding with all the talented developers in the process) Safari is aging like milk so you can't trust that what works in Chrome is going to work anywhere else.

"Preview panes" and worse, editing inside them as a WYSIWYG for example is outright nonsense. You cannot trust them and editors that shove it in your face just help you develop sloppy practices, like blindly coding an entire site before you test in OTHER browsers.

That's something I glossed over -- as I go I test in EVERY browser I can lay my hands on. When I say "as I go" I mean every time I create a new layout section from the top down. It is WAY too easy to blindly create an entire layout testing in only one place, to only find out later that how you did something is broken in some other browser requiring major changes, or is simply not a viable design concept.

Sadly this means sometime this coming week I need to go back to having a VM install of OSuX so I can test Safari properly again... Well that or I drag out the Apple IIe Platinum case I stuffed a Atom board into for use as a Hackintosh. (about the only way to make a legal one); hmm... I do have a spare Core 2 E6400 and mainboard now, upgrade time?

There are a LOT of design concepts that only work at certain sizes -- we thankfully have media queries to make it so you can still use some of them whilst using a different layout where it fails -- but there are even more than just aren't viable. It's part of why screwing around in Photoshop is NOT web design no matter how many ignorant artists with the giant pair of donkey brass to call themselves "designers" (whilst not knowing the first damned thing about UI design or user interaction) -- there are WAY too many things you can do in a paint program (like fixed dimension backgrounds) that have no blasted business on websites.

Most browsers have document inspectors that do the same thing, but really if you 'need' that for work on your own code, there's something wrong with your own code or you're not leveraging selectors properly.

... admittedly watching how some of these frameworks and the developers who use them just blindly throw classes and ID's at EVERYTHING, failing to leverage selectors properly seems to be todays norm; as evidenced by the bullshit being spewed by ignorant halfwits and "tools" like google pagespeed about how using more code and throwing more DOM elements and classes into a document will make it faster... while at the same time Google Search penalizes you for the same?!? I swear Google "webmaster" has been taken over by their marketing / advertising scam artists! Sure as hell isn't about helping people make successful well written websites anymore!!!

If you have enough HMTL that you're needing to do that, you're doing something wrong with your HTML.

The thing to remember and weigh against that is it's not just a single pageload -- think about your server load when/if you have real traffic. At low/nonexistent traffic numbers you could make it a meg and "who cares" -- you suddenly have a content change that goes viral, you'd kill for that 50% reduction in bandwidth. It can be the difference between choking a quad core Xeon to death, and hosting comfortably on an Atom 330.

Admittedly, when I was doing this stuff full time the past decade, my bread and butter was saving businesses who were unable to afford long term the hosting upgrades their existing sites required for their traffic levels -- so I'm more aware of these issues than most people starting out or worse, the "designers" and their "Billy Joe and Bobby Sue" attitude towards clients.

Was made worse by the redundant text -- it just kept repeating the same thing; again, fluff and filler factor.

It's like the "keywords stuffing" thing so called SEO experts do, that runs contrary to pretty much every professional writing rule about not repeating yourself -- well, unless doing so for emphasis or prose. One of the big things I learned about writing when I was doing so professionally (bar code scanner documentation) is that you are supposed to avoid using the same nouns, verbs and most importantly adjectives for at least every 500 words... The search guys will go and intentionally stuff their "magic phrase" in a dozen times per paragraph.

It's also why a decent vocabulary (or failing that mastery in the use of a thesaurus) is so important if you are making content.

"So avoid using the word 'very' because it is lazy. A man is not very tired, he is exhausted. Don't use very sad, use morose. Language was invented for one reason, boys - to woo women - and, in that endeavor, laziness will not do." -- N.H. Kleinbaum

I feel you on that one, I have the same issues with my own projects. It's often easier to work on other people's stuff because you don't have that close personal tie to the topic. Again though, that's where more eyeballs on target never hurts and why forums like these are so invaluable. Even if you don't take all the advice or ideas offered it can at the very least ground your perspective a little.

It's also why some people react hostile despite "asking" for advice; they don't want actual advice, they want to have the rose coloured glasses slapped on their head and a nice pat on the back for their efforts.

There's this whole culture now built around this "don't you dare offend anyone" mindset.... The gutless, spineless, lifeless, yellow, thin-skinned, weak-willed, lily-livered, tofu-eating, Prius-driving, purple-pissing, timorous, pigeon-hearted, pusillanimous, recreant poltroons and camel-mannered tunic-wearing mollycoddles that have resulted are why so many projects are doomed to failure before they even start.

You mix in the absurd number of perfidious, double-dealing, ferret-faced snake oil doctors -- much less the primped, preening, white-collar, rat-fink, craven, dandy criminals that basically rule the industry at this point -- and I'm shocked any legitimate businessman has anything more than two fingers for the entire web at this point; One for the developers, one for the source they code in on!

Much like a lot of other long term perpetuated scams, I can only assume ignorance on the part of the typical 'client' is still being how all these sleazy shortcuts and sleazier practices continue to lumber onward like a second rate Jabberwocky. "It seems very pretty, but it is very hard to understand..."

YMMV. Let's just say my morality and business mentality is in direct conflict with todays sleazy practices and "race to the bottom" mentality; that or by "modern" standards I'm just too blue collar for this ****.

Well, just remember you don't HAVE to agree with me, none of us have to agree on anything. You know how BORING the world would be otherwise?

 

Well, possibly I would agree with you there. However, I tend to do web page authoring in bursts followed by long periods of inactivity. (As in, I take a look at the design I thought was outstanding 6 months previously and decide it looks s*** and decide to have another go.) I confess to finding the its and bits of css / positioning etc. somewhat difficult to retain when working this way. This time, rather than re-educating myself in detail on this I decided to give Bootstrap a go because the default Bootstrap design looked like a better 'look' than my limited design skills would be able to devise.

I think you underestimate the amount of knowledge required to knock up the mock up you (generously) created for me. I could get there, sure, but not in the same time as it took me to create my Bootstrap abortion.

Your response may be that I'm too thick to learn / too lazy but naturally I would have to disagree. If that's the charge then maybe take a look at the software I've written, which the site we're discussing endeavours to promote. It took nothing if not a massive amount of perseverance, time and self-education over an extended period. It's C++ and in the past I would have criticised VB developers using similar arguments, in general, to the ones you've been making. At the time I would have been right because VB apps ran slow (on computers that were slow) and often created by people with limited programming skills. Now the first argument is irrelevant because computers have got thousands of times faster and, over time, I've discovered the odd VB application that is actually very robust and well written and I rely on it everyday. (XYplorer - but I expect you use a command prompt ;-))

I've saved my full rant about web development till the end. Well, it's my turn for one, I feel...

For me, creating an effective website is one of many competing priorities in my business, and I would argue that how I get there is mainly personal preference, providing it meets certain pre-requisites, those being:

• It promotes a professional impression of Data Perceptions to relevant visitors
• It communicates a compelling case for Prophecy Sales Forecasting Software
• It loads acceptably fast
• I feel confident about being able to develop / maintain it quickly in whatever tool I choose to use. (N.b. that may be different to your preference but I'm certain no one in my target market really cares about how things are made as long as they work. I'm rather proud of my application being written in C++ but when I mention that to potential customers it's usually of profound disinterest.)

Sorry, I don't think that's me. And couldn't I use the same argument against your position - i.e. MOST of the reason people seem to believe such tools offer no benefits is...(because it's said so many times)?

I really do appreciate all of your posts and all of your opinions. Some I accept and some I don't - that's OK, isn't it? I'm not as happy as I was about having used Bootstrap as a result of what you've written but I am where I am and I don't think there is a strong enough case to chuck it all away and start again without Bootstrap (although I may yet use the stuff you kindly did to do just that. You see, it would have taken me a huge amount of time to have done what you did. Whereas Bootstrap got me there relatively quickly.)

No fear. The Pinegrow visual editor renders the page far, far better than any other wysiwyg editor I've ever seen but it also supports full browser preview in any browser, which I do use extensively during page development. (Well, Opera and IE at least.)

I think your argument should be less focussed on whether it previews accurately (I do believe it does) but rather on what you've posted previously about the case for separating design from content - i.e. starting with content and basic html entities and then imposing design using css etc.. Wywiwyg muddles the two disciplines and will never enforce the separation you require.

And some DOM inspectors are better than others, I would guess. Please let me use the one(s) I like best!

That would be my wet dream but unfortunately it hasn't happened yet. If it does happen then totally you will be right and I will need to comply 100% with your way.

You are hammering me for something I have already hammered myself for and attempted to address!

Hopefully that is not me you're talking about. Criticism is much more helpful than praise because it enables improvement.

I'll be honest though. The main reason I requested a critique of http://www.dataperceptions.co.uk was to get feedback on the effectiveness of the design / message. That's not to say the technical content of the responses has not been hugely helpful - it has been and I hope I've expressed my genuine gratitude appropriately.

Thanks! I know!

Rant time! The trouble with web development is that it requires layer upon layer of different technologies, standards and fashion items to be used in appropriate combination and which must work correctly on devices from mobile phones to 36" screens and bigger and across multiple browsers, each of which seems to contain minor or major differences in how the same html etc. is rendered. The average Joe (i.e. not a full time web developer) is bound to struggle with this ever-changing complexity. And therefore latch on to what appear to be easier solutions - i.e. where some kind souls (e.g. the Bootstrap people or yourself) have encapsulated the complex mess into something we can use, passably well, to make a website.

Contrast this with what I do in my 'day-job' - i.e. writing C++ for Windows applications. Generally (and the past is the past) Windows provides a stable programming api where the old stuff still works and you aren't railroaded into using the new stuff if you don't want to. (Same for C++, which continues to develop as a language.) So, there's one horse you need to learn to ride and you just do more and more with that horse.

It seems to me that we are still in the early days of web development and maybe one day it, too, will be similar. But for me at least it's about a million miles away today.

Rant ends. That wasn't so bad, was it?

Cheers!

Pete

 

Technically you aren't railroaded into doing anything "new" to web development either - most pages from a decade ago, or older, still works without problems - simply because back then things were simpler. If you were smart enough back then to actually follow some logic when it comes to the code (not using tables for layout, laying off the animated gifs and such), it might not even look too bad - dated, of course, but workable. The problem with web-development is more of an opposite one - the newest, shiniest tech isn't available for everyone (depending on browser version and type), and yet some overuse all the fancy new stuff without knowing anything about it (like the use of tables back in the day).

There's plenty of safe, non-complicated web-tech out there, but trying to at least follow modern standards is a good starting point.

 

Granted. But do they look modern / impressive to today's site visitors? I greatly doubt it, purely because design 'fashions' change. In reality, you do have to modernise designs or look dated. There's only so far you can go in creating a modernised design without also using (the assortment of) today's web technology options.

I guess the developers and many thousands of Bootstrap out there would describe it as following modern standards. But as the conversation in this thread amply demonstrates, one man's modern standard is another man's curse of the devil.

Anyway, obviously I agree with your point about following modern web standards. My rant was meant to explain my feeling that occasional web developers like myself can find the complexities of standards, technologies, frameworks and browser oddities unnecessarily difficult to deal with. Hence using Bootstrap, where hopefully (but it seems heavily disputed) many of these complexities have been encapsulated.

I feel a rant coming on! Why is it that I keep having to defend Bootstrap etc.? Apart from putting myself up to be shot down in this thread (so I deserve the stick in one sense) I'm only one of many thousands of sites that are using it (see http://trends.builtwith.com/docinfo/Twitter-Bootstrap). Tells me there is no single right answer. Horses for courses etc..

 

I do agree with you, but it boils down to something like this:
There's no reason to use for instance Bootstrap - you can do everything Bootstrap does, much simpler, if you just create the page correctly (purely HTML) in the first place. Then you'll of course have to learn CSS properly, but you'll still have fairly clean code, which is easy to redesign (simply remove the CSS and create a new one). Of course, that makes it out to be a bit simpler than it is, but you get the point, I believe.

Bootstrap, jQuery and several other solutions have definitely become the "industry standard" more or less everywhere. Personally, I don't really see it as a major problem, although I stick with jQuery (I don't use CSS-tools except for SASS, which I compile to regular CSS anyway before deployment). The code I'm using I try to keep as clean as possible, but then I mostly code online applications, not websites per se.