You would think with the money spent on e-commerce platforms today, that best coding practices, accessibility and SEO readiness would be at the forefront of developer's minds.
However, it transpires, for a number of platforms, getting the basics of Javascript has gone awry.
Last Friday I had a call from Chris Scott of Headscape, one of our usual weekly chats about current projects, but this week he brought something to my attention. Headscape recently pitched for some e-commerce work, and Adobe’s Business Catalyst was to be the platform of choice. However, one of the pre-requisites was that the site work when Javascript is disabled.
The reason for this being that that the company had many customers with disabilities, and for blind visitors using screen-reading software, Javascript support (specifically on AJAX content updates, where the user is informed that a “virtual refresh” has taken place) doesn’t always give the best experience.
Well, it transpired during their demonstration that Business Catalyst sites require javascript to be turned on, and, as you would expect, when Headscape mentioned this issue, they lost the pitch.
So, Chris was discussing this with me, and I was saying “No! Really? Well why didn’t you suggest they go with Magento or Demandware or something like that?” Upon which Chris tells me that Business Catalyst mentioned Magento when he contacted them about this, as one of the platforms that also requires Javascript to function.
To which I sit, aghast. “What? No, oh come on, what is this, 1999? They may as well have a Flash intro and an exploding logo” I joke. We then go on to test a bunch of Magento sites. Reiss, Jigsaw, Salter, even the great MyDeco. None of them worked. Some you can get further than others - Salter I could get to the checkout before hitting an obstacle, Reiss I couldn’t get past the homepage.
So OK, fine, I’m shocked, but fine, Magento’s out. Let’s try Demandware. We go onto a few Demandware sites, Crocs, Timberland, House of Fraser, none of them work without Javascript. The crucial add to basket button is disabled turn out not to be a button at all.
So Demandware’s out (utterly astonished here), what about ATG or Hybris? Well, looking at Speedo, Toys R Us and Long Tall Sally, they all have the same issue. B&Q’s DIY.com, running off of ATG, had some weird issues. In some sessions we could add products and check out, in others we couldn’t. 
In our investigations we only found a handful of platforms that didn’t require Javascript at all to place an order, including at the high-end, IBM’s Websphere Commerce and at the low end, good old Shopify.
So, what’s the big deal? Everyone has Javascript?
Well, you see, I come from a land where no development even gets past wireframing until we answer “OK, but what happens when Javascript is disabled?”
Why do we do this? I mean, javascript is pretty much in every browser. Why would Javascript be disabled? Am I saying we shouldn’t use Javascript at all?
No, I love all things type=”text/javascript”. You know that awful flash carousel on wiltshirefarmfoods.com - we’re totally about to replace it with a Javascript version.
What is deeply wrong is where Javascript is used to create the base functionality of the site, that’s just not how things should be done nowadays. Let me show you how things are meant to be:
Progressive Enhancement
Progressive enhancement was a term coined by Steven Champeon at SXSW, as a reverse practice to Graceful Degradation, which says to create an all singing-all dancing website first, then remove features as you go down the browser list in terms of what they can handle.
However, frankly, this is an arse-backwards way of doing things. Progressive enhancement is the way to go.
What progressive enhancement requires is that you first build your website in bog-standard semantic html first. That buttons are buttons and links are links. Your markup validates and all your website functions work in any browser that understands HTML4.
You then style everything us using CSS, and add unobtrusive Javascript functions to do all the cool Ajax/Jquery cool 2.0 stuff. If the browser being used doesn’t understand the particular bit of CSS or javascript, it doesn’t matter, because the “base experience” is still usable.
Well, that sounds terribly by-the-book, bet it’s expensive.
Well it’s not. It works out more cost effective, not only because you can pick and plan the implementation of bolt-ons to the base experience, but also, when you’re testing any new functionality, presentation (CSS), logic (Javascript) and data (HTML) are neatly separated, making any issues easy to track down and fix.
But that’s not all, apart from the accessibility issues that having unnecessarily escalated browser requirements can have (see the recent Econsultancy post with some scary numbers), and that you can be sued for discrimination, there’s plenty more reasons. Dave McDermid from Headscape explains:
Most people don’t turn Javascript off, but that is not the point. If Javascript breaks on a page in IE for *any reason* then often all scripts will be stopped. This means your page is now broken, and a user sees this as a broken site. They may not come back.
Another situation: if the Javascript takes some time to load on the page and the user is impatiently clicking on buttons, they’ll have a poor experience. If the page falls back to a good ol’ form post / non-js alternative then the user can carry on without worries.
Furthermore, you can’t guarantee at all that your visitors will be on a device that fully supports Javascript, especially with the push to mobile – remember not everyone has an iPhone. Even worse, your single most important visitor, Mr Googlebot, is using the worst browser ever.
If you don’t cater for Mr Googlebot (for example, loading navigation in using Javascript, I mean, who does that, really?) then you’re turning away a VIP. The same goes for any performance monitoring tools you’re using, they all use rubbish “browsers” that only understand the basics.
OK Matt, so what’s the solution?
I realize I’m doing a bit of pulpit thumping here, but come on now; this is nearly table-based layout levels of dumb.
Fortunately, since all this came to light, Business Catalyst have let us know that they're on the case
Certainly at the time of the initial development (three or so years back) we made an incorrect decision but we’re well aware of this and hope to have this fixed in the not too distant future. We’ve always focused on valid markup since we target web designers and accessibility is something we have also become religious about in the last couple of year
As website owners, we have to understand the technical aspects of how our sites actually work. We must have the knowledge and the will to enforce good architectural practices within our developer teams, which, from my delving into the code of some pretty big sites, seems to have utterly gone by the by. Gentle reader, in the last couple of days I’ve seen code that made me shiver.
Reader comments (60)
10:53AM on 1st March 2010
For most ecommerce businesses, the decision is (or should be) one of ROI.
Using Javascript judiciously can enhance the user experience, not just aesthetically, but in smoother checkout processes, better customer feedback, more immediate error handling and more.
If that raises revenues more than incorporating the minority who need javascript turned off, or if the cost of developing for a segment is higher then the expected revenues from it then these tools will prevail.
I fully appreciate the arguments about accessibility, particularly on large mass-market sites, but rather then vast tracts of the ecommerce industry having to redevelop their sites, would we not be better off investing in screen reader technology that can make use of these sites? That seems to be a solution that noone has proposed so far.
The mainstream browser industry has moved on to accomodate more users and devices. A movement towards more capable accessible browsers would surely be more cost effective and widely adopted than spreading the efforts amongst millions of site owners worldwide?
Until then it is unrealistic to expect that anyone other than sites serving this segment, or sites such as the BBC with statutory duties of accessibility will be likely to make the move.
An accessible checkout is rumoured to be on Varien's roadmap for Magento, but as it's over a year since it was raised I'm assuming that there's little real demand for it.
10:56AM on 1st March 2010
Great article, if accesibility is a must (anyway this should be always a must!) and you want ajax the best is to use unobtrusive Javascript and follow WAI-ARIA recommendations: http://www.w3.org/WAI/intro/aria
Head of Ecommerce at Lovehoney
11:03AM on 1st March 2010
yeah, it's a weird thing. It's not even an accessibility issue, more of a coding best-practise one. It seems like however many years ago, a bunch of platform providers decided to cut corners, and no-one's picked them up on it.
In terms of ROI, the overhead in development costs of having to cater for a site that intertwines javascript functions throughout rather than keep them seperate must be considerable.
The biggest problem I found wasn't that javascript made the checkout process smoother - it's that the add to basket and checkout processes didn't work at all. It's like the developers had forgotten how to post a form.
Head of Ecommerce at Lovehoney
12:03PM on 1st March 2010
Oh my lord, of course! Sorry Paul - had a fun old time playing "guess the platform". Had a bunch of sites where I just couldn't figure it out.
glad we're not going down the traditional nav2net route then (we're using the nav2net to do the translation, but building in api's to our own engine) - I kinda threw out that platform the moment I looked at the code it produced.
Chief Technical Officer (CTO) at Dennis Publishing
12:12PM on 1st March 2010
We kind of reached a similar conclusion about Nav2Net when building Jigsaw at Pod1. Unfortunately they'd already bought the platform so we couldn't change that, and they weren't keen on (the cost of) building on top of it with APIs. So we decided to beat the platform into submission and led K3 on pushing the boundaries. All in all they did a pretty good job, but it was a challenge.
We didn't like the code it output either, so we gave them the HTML/CSS/JS for them to plug into it. It turned out to be reasonably okay working like this.
Unfortunately there was a roadblock with the way Nav2Net handles links by default. /Everything/ was a Javascript call to POST stuff. Something to do with using .Net html code generation.
We managed to get rid of most of it, otherwise the whole thing wouldn't be listed in Google... However I think K3 was running out of budget towards the end of the integration so compromises had to be made, hence a few bits still requiring Javascript. :(
1:09PM on 1st March 2010
Very interesting article. I find it quite shocking that these various cms solutions are all javascript driven, I have to say I dont really understand how you can offer anything like that that relies on a switchable option. Your site should function based on your server-side settings, then any user setting should prove an enhansement. As this article explains beautifully.
3:37PM on 1st March 2010
Interesting article, Matt. I come at this as a dyed-in-the-wool PHP programmer who has recently discovered jQuery. The web application I'm developing is not ecommerce and there's absolutely no doubt in my mind that jQuery (and therefore javascript) is essential to the quality of experience of my application and it will insist on javascript being enabled.
For ecommerce, I guess it's a harder call. I run an ecommerce site that uses BigCommerce (www.MakingYourOwnCandles.co.uk) and this doesn't seem to require Javascript (although I didn't check this out before choosing it). It runs perfectly well both for users and managers and because it doesn't need javascript (and uses nice, semantic markup) it'll mean a few more customers will be able to complete their orders than otherwise so it's all good.
So, I guess it depends on the market you're looking at. I don't like statements that include the phrase "best practice" - to which my reply is "says who?". Best practice, beyond certain basic principles that everyone agrees to, essentially boils down to whatever works best for you (and your customers) in a particular circumstance.
Kev
5:37PM on 1st March 2010
My only comment is what about
RESTFul services.
Even IBM WebSphere Commerce is opening up more and more web services to the front end for use.
And the thing with RESTFul services is generally you need to feed that data in dynamically via Javascript.
A RESTFul services comes back with XML how are you going to parse that. (Usually with Javascript)
7:31PM on 1st March 2010
This article prompted a response from the guys at Snow Valley...
"The common criticism here is that the cost of “extra” effort involved [in applying proper progressive enhancement] is not realistic and offers little ROI. I would say that if a platform is built using traditional Get/Post forms and the like, the extra cost of bolting on a layer of Javascript fanciness is relatively small, and certainly much less than trying to retrofit a degraded solution once you’ve gone too far down the rabbit-hole of inaccessible Javascript development."
Here's the link if you're interested:
http://snowpatrol.snowvalley.com/2010/03/01/is-e-commerce-with-javascript-turned-off-too-hard/
8:48PM on 1st March 2010
Stephen Pratley: For most businesses, the decision does come down to ROI, and only ROI, which is how these sites get into this mess. Businesses look immediately at the number of potential sales they lose by not worrying about building their shop properly, and think 'Well, > 90% of visitors can use it - that's good, right?' - it is fine, I guess, except 6-12 months down the line, there's nearly always another effort to improve visitor numbers, order values, and conversions. There's that few percent of people who they're actively turning away, but now it's too late to fix it, 'cause the whole platform is the culprit.
I don't expect that it's businesses that should care the most, anyway - as a developer, I'm working with one of these JS dependent shops, and it's horrible. A proper, plain HTML/GET/POST foundation would increase OUR turnover and profit, never mind the clients. As developers, and integrators of these technologies, we should choose the right platforms to sell.
8:52PM on 1st March 2010
Fred Shady - your idea of REST isn't right: REST is the underlying architecture of HTTP, when it's built the way it's designed. No JS, no XML mentioned anywhere.
9:01PM on 1st March 2010
I pointed out the problem with JavaScript dependency early in the Magento beta process. They showed no interest in "fixing" this problem unfortunately. I believe their response was something along the lines of "this is only the default theme, you are welcome to change it".
Web Developer at Ross Kendall
9:30PM on 1st March 2010
The roadmap for Magento is (mostly) community driven, so Magento users (and prospective users) can have their say on the Uservoice page: http://magento.uservoice.com/forums/24441-magento-community-edition-roadmap/suggestions/277962-remove-the-javascript-requirements-for-the-front-e Also, Brandon is correct in saying that the javascript dependency is the behaviour of the default theme/interface - which a developer can change to meet client requirements if need be.
9:33PM on 1st March 2010
I'm finding this blog a bit buggy! posts going missing and strange formatting behaviour with the comments
2:44AM on 2nd March 2010
You are, at least in some cases, confusing the ecommerce platform with the way customers use that platform. I don't know about all of the specific systems you mention in the article, but I do know ATG. The ATG platform doesn't prescribe what the front end of the site looks like or how it's built. Application developers are free to use or not use JavaScript. Most sites these days do require JavaScript, but that's not the fault of the platform used to build them unless the platform requires a particular front end. ATG sites that don't require JavaScript include J Jill (www.jjill.com), American Eagle Outfitters (www.ae.com), AT&T Wireless (wireless.att.com), and many many others. I suspect the same is true of at least some of the other platforms you mention here.
7:25AM on 2nd March 2010
As well as some of the accessibility issues - another point to consider is how are you going to check its working? Very useful article, with great discussion.
In looking at the last set of findings / results on our retail benchmark, far to many of the retailers (and perhaps suppliers) are missing the basics for sites, e.g. do all the links work, are the product images there, do we have page titles and descriptions, we also continually find failing shopping basket and tracking cookies....
Later next week we are launching the JavaScript module, allowing site managers / owners to independent and 'live' monitoring of site JavaScript - no doubt some of the problems we find will be met with the all to common 'denial and complacency' by certain agencies / CMS vendors.
Retail findings are at (full access offer to e-consultancy readers) http://www.sitemorse.com/rt/630/d4f0c5de
9:21AM on 2nd March 2010
Ben, good point about the profit impact on the developer, but the checkout is only one consideration in that calculation.
We can build ecommerce sites from the ground up where necessary, but that means a lot of features that come 'out of the box' with a platform like Magento will break the budget.
E-commerce Content Manager at Supergroup Internet Ltd
9:46AM on 2nd March 2010
Surely there's a whole host of Disability Discrimination Act issues by having JavaScript as the base site. If you are effectively blocking a site to disabled users who cannot cope with JavaScript enabled transactional sites, you must be opening yourself up to a potential law suit.
I suppose it's a risk thing. What are the chances of being sued and having really bad publicity vs the chances of having a good, usable, accessible and crawlable (is that a word?) site that might take a little longer to build.
10:12AM on 2nd March 2010
Anyone who surfs with NOSCRIPT enabled is a retard.
2:07PM on 2nd March 2010
And I guess that ends that conversation.
Head of Ecommerce at Lovehoney
2:09PM on 2nd March 2010
yeah, it's like a Godwin variant.
2:57PM on 2nd March 2010
It's not Godwin's variant, it's just the law of common sense my friend. JavaScript is found in hundreds of commerical and open source libraries. Its functionality cannot be replaced in all instances. Graceful degredation is the preferrered method, but some applications cannot "degrade". One of my clients has real time stock control handled by AJAX. How can I do that without scripting? Er, a frame with a META refresh? DUH.
Chief Technical Officer (CTO) at Dennis Publishing
2:59PM on 2nd March 2010
Fred - yes, some of them may literally be 'retards' - that's why it's called the Disability Discrimination Act.
*sigh*
4:30PM on 2nd March 2010
Ah yes Paul, from the publisher who brought us "Fat Slags" and other such charmingly named "humour". The DDA is a pile of dung when used in context to the technical capabilities of websites.
4:38PM on 2nd March 2010
Fred, the idea of "graceful degradation" is now not the preferred method – "progressive enhancement" is. So it should be possible to simply design an experience for your client's non-javascript users that warns them about the stock limitations and allows them to purchase anyway. They may get an out of stock error, but at least the system has set their expectations. Everyone else gets a super-duper AJAX experience and all is well.
Chief Technical Officer (CTO) at Dennis Publishing
4:42PM on 2nd March 2010
We also publish The Week, but that's beside the point. I'm afraid I can't berate your employer due to your magical anonymity shield.
The DDA is not a "pile of dung" for those one million people in the UK alone who cannot use a website the same way as an able-bodied person, whether due to poor eye sight or motor skills.
I hope your client with the AJAX real-time stock control system doesn't have any disabled employees. When you stop them doing their jobs simply because it's too much hassle to accommodate their disability, you have a problem.
Chief Technical Officer (CTO) at Dennis Publishing
4:43PM on 2nd March 2010
Spot on Sam. Bake the cake first, then add the AJAX icing.
Head of Ecommerce at Lovehoney
4:46PM on 2nd March 2010
Yeah, I'd fall back to a manual refresh button. In fact, having a manual refresh button would be a good UX thing, going back to the old theory of page changes being "Requested Actions" rather than "Accidental/Incidental". For example, on our shopping basket, changing mouse focus anywhere after typing in a new quantity will update the basket, however we also have a "recalculate my basket" button for those without javascript/those who want something to press.
And calling my customers "retards" because they disable javascript so that their screenreaders call out the site procedurally isn't appreciated, ta.
4:55PM on 2nd March 2010
Bit OT, but...
Interestingly enough, in the process of a complex basket redesign going on for a client at the moment, we're making an explicit decision to force the user to "action" any updates to their quantities. These users often continue shopping after tweaking their basket, and we didn't want to risk their changes not saving within the persisted basket if they suddenly navigated away (and AJAX on a key change event seemed risky and unnecessary).
5:00PM on 2nd March 2010
Leaving aside Fred's lack of decency, my phone is around 18 months old but doesn't handle JS well - so any sites that rely on JS don't work well on it.
I don't choose to surf the web on it without JS turned on, I just don't have any other option. (That's not its only problem - although the econsultancy site works with JS off, the captcha won't load on my phone so I can't comment. Grrr.)
Head of Ecommerce at Lovehoney
5:03PM on 2nd March 2010
Yeah, it came out of user testing. you don't have to press anything, but customers wanted to mentally "confirm" that they've changed it.
We even toyed with just having a "refresh" graphic, that didn't actually do anything, but was just something to click on.
Chief Technical Officer (CTO) at Dennis Publishing
5:13PM on 2nd March 2010
Matty: I toyed with the idea of the 'update' / 'refresh button appearing when the quantity was changed to highlight the fact further action is required (with quantity changing via + and - buttons, no typing, but always small quantities) - but never got around to testing it...
Creative Director at Snow Valley
5:18PM on 2nd March 2010
Aha! Remembered to log in to my account.
Malcom raises an interesting side issue about progressive enhancement. As I research more into developing mobile commerce, it becomes very clear indeed that the only valid way in which this can work is through a combination of browser-detection and enhancing the experience through unobtrusive AJAX. While you want a generic lightweight mobile experience for most reasonable browsers (and personally, I would assume that this should be provided without JS), you want to create a wonderful, rich, appropriate experience for your iPhone users – they're much more likely to part with their cash. As a result, you detect the platform and provide a much enhanced JS layer to provide the richer, animated, AJAX-dependent experience they expect.
5:55PM on 2nd March 2010
Haha you lot are stuck in the old days. Lol - "recalculate my basket" buttons - that's really funny. I did laugh.
"graceful degradation" or "progressive enhancement" - mere semantics old boy. Don't try and impose your DDA nonsense on me, Paul. We're too busy building the systems of tomorrow whilst you wallow in what form button to use.
Its has been fun, bye.
Chief Technical Officer (CTO) at Dennis Publishing
6:02PM on 2nd March 2010
I wonder if the Whistles website is one of Fred's systems of tomorrow :-)
8:07PM on 2nd March 2010
Thank you for the very insightful and interesting article. I would like to echo Matt's comments from earlier where it is not that the platform requires the front-end to use JavaScript, at the end of the day the choice is made by the retailer. Technically Demandware can support a web site without JavaScript and our customers could built such a site.
Head of Ecommerce at Lovehoney
8:59PM on 2nd March 2010
Cheers Adam, apologies if the assumtion is incorrect. After testing the first 17 sites on http://www.demandware.com/Sampling-Brands/brands,default,pg.html - from Anne Klein to House of Fraser, and them all to fail with javascript off, I thought it was a safe assumption.
Funnily enough, the next site, Jewelery TV, works without javascript. Although out of the 40 listed, I did only find 6 sites that worked, Jewelery TV, Sally Beauty Supplies, Shop Taste At Home/Country Store Catalog (which look like they're the same site?) and PTADigital/YouNeek (which again appear to be the same site).
Head of Ecommerce at Lovehoney
9:06PM on 2nd March 2010
though, whilst I'm at it, whoever designed the user experience for Playmobil needs to be stood against a wall and shot
this is at the checkout, as I try to place an order. I'm then taken through a registration process that closely resembles a tax self-assessment form.
Head of Digital at VGroup
4:23PM on 3rd March 2010
Not to mention that you can't even look at any product in the Playmobil shop without first providing you name, email, billing address and inside leg measurement. It was like a trip back in time to 1999...you can almost hear the marketing manager demanding data capture as early as possible in the process.
2:00AM on 5th March 2010
Matt,
Thanks for taking the time to engage us all in such conversation. Just so its clear, with Demandware, we are a platform. It is our customers who define the front-end and business processes (see Playmobil for example) and we try to advise/steer/advocate but at the end of the day the decision is "theirs". As for the whole scripting issue, we are always searching for better ways to do things for our customers and learn from each experience. The challenges we face are in making complex business requirements (only show shipping methods that are relevant to the shipping address entered in combination with the items in the cart but without the user being required to press a "next" button first) possible and still provide a website that is representative of a specific brand-voice. Your article has solicited some interesting internal conversations but it would be great to get your POV as to how best to achieve such results.
Head of Ecommerce at Lovehoney
8:11AM on 5th March 2010
Hi Harvey,
thanks for taking the time to reply, and it's good that people are having these sorts of conversations.
As I see it, as platform vendor, Demandware and others provide modules that facilitate ecommerce, so product pages, shopping basket, registration, billing address, shipping address, shipping methods, gift wrap options, gift vouchers, all sorts, all ultimately linked to fields in databases.
Then me as a client, when doing the initial configuration, can string these modules together, almost as if I was making a flowchart (drag & drop checkout architecture design would be damn cool), to define the base experience of my shop - there is a Next button or continue or whatever, that procedurally takes the visitor to the next stage in the process. And this is great and it works, it's just pure HTML without any styling or js logic because I haven't got to that stage of configuration yet. I can go into the dev site in my browser and just try it out to make sure I'm happy.
As an aside (and this should be done during IA) we should work to separate out what is a valid business requirement and what isn't, so:
We want people to choose a shipping method that's dynamically filtered based on the state they've selected <--- valid business requirement
We want people to do this without pressing the Next button <--- some guys opinion, and again from a UX perspective, I'm a big fan of any page changes being "requested actions" with a cognitive step (from say a button press) rather than being "incidental actions" (like from entering content in a field)
I can then, as a client, enhance the experience using javascript. So if I want to use ajax to to scrap the content of any subsequent pages, such as shipping methods, within a page and present them as a dynamic content area or overlay, say when a state or country is chosen, then I can and the cookie or session variables that are holding my progress will be able to inform these dynamic areas. If I really wanted to I could even munge all the stages together to form one mega-checkout, using javascript to fiddle about with the DOM to override button actions, give them different names, and so on. I then go on to style the whole thing up in css.
But if I was going through the checkout without Javascript (or even without css for that matter), then thats OK, because the "base experience" I defined way back up there still exists, and is still useable and would work on any device.
To be honest I think this is why I sound so incredulous in this post, because I, and others who live in Accessibility & Usability land, just thought that this was how ecommerce platforms worked. We assume that platforms exist to provide the base experience and that the client progressively enhances & styles them, nicely fitting with the old 3-layer data>logic>presentation model.
Matt
Owner at Digital Juggler
3:12PM on 5th March 2010
Hi Matt
Awesome post that has kicked off a really informative discussion. I've not come across the term "progressive enhancement" before but it makes perfect sense.
So to get this straight, you are advocating building the front-end in plain html first, almost like a wireframe site, to ensure that all core functionality works regardless of an individual's browser settings? Then you build layers of sophistication using tools like js to try to provide a more engaging site for those visitors whose browser settings permit it.
Can I ask what tools you use to test sites? I know of a few free tools that do this but always keen to know what others use.
Can you also recommend the best website/blog to read to find out more about the technical implications of progressive enhancement?
Cheers
james
Head of Ecommerce at Lovehoney
9:51PM on 5th March 2010
Hi James, yeah you'd think so, but apparently not everyone sees it that way.
I do have to be clear, that progressive enhancement isn't always the solution. If you're building some web app/augmented reality/geo location/social 2.0 wonder, then it's just not gonna lend itself to the methodology, but for the moment, ecommerce is still pretty much a "stick stuff in form, post form" procedural affair.
Testing wise, I just use Firefox & Firebug. Turn JS off, come across what acts like an obstacle, then open Firebug and see if it actually is.
In terms of reading material, it'll be the usual developer haunts, A List Apart, ThinkVitamin, and of course the Great Mister Boag at boagworld.com (never tell him that I said that)
CEO at SciVisum.co.uk
10:57AM on 11th March 2010
Matthew great article, and I think your later proviso was spot on:
> I do have to be clear, that progressive enhancement isn't always the solution. If you're building some web app/augmented reality/geo location/social 2.0 wonder, then it's just not gonna lend itself to the methodology, but for the moment, ecommerce is still pretty much a "stick stuff in form, post form" procedural affair.
Other sectors like online learning and real time finance would also be tricky to use progressive enhancement.
I wonder if in the typical company, the MKtg team who are speccing up the kind of UI they want, are not being active enough with their tech teams on this front.
If we assume that 90% of sites are now bolting on AJAX stuff to an existing framework (10% buying new platforms) :
Then maybe it's enough hassle for Mktg to arrange wireframes for new feature Z under AJAX, without having to produce another set for the non-JS site... The tech team not the business team are thus left making the calls as to what works or doesn't without Ajax.
12:50AM on 13th March 2010
Think of all those web analytic tools (Site Catalyst, Google Analytics, Coremetrics) that rely on javascript to collect clickstream data. If it weren't for the javascript I'd imagine it would be very difficult to collect this data. Some of them offer options to collect the same data via web logs (Webtrends) but not many of the pure play SAS offerings which rely of page taging.
1:04PM on 13th March 2010
In addition to web analytic tools the following may not work
9:45AM on 16th August 2010
I'll answer in a full post. Too many ideas, in fact. I was thinking about this very thing yesterday as I walked past the display case at my employer and some of my childhood favorites were on display (the author was a major benefactor to us)--I always ask new employees whether they've read her books and sadly, the answer is no.
9:46AM on 16th August 2010
I think you’ve made some truly interesting points. Not too many people would actually think about this the way you just did. I am really impressed that there is so much information about this subject that have been uncovered and you did it so well, with so much class. Good one you, man!
4:42PM on 30th August 2010
Most important is the fact, that JavaScript makes the pages very slow. Your example with Magento is nice. The checkout is quick and sexy. But the pace is not quick in loading content. And some pages have JS-errors. This is the reason, why you can not place your order, because of one small error (for example PayPal). I have seen it on a visited Magento-Page.
10:21AM on 11th March 2011
I agree that most of the java scripts pages is very slow. while using a java scripts in ecommerce websites, some times the page get slow and its need to be loss of business. so use java script with correct.thanks for your post.
7:19AM on 27th April 2011
thank you!
8:12AM on 27th July 2011
it's all about the target audience.
3:25PM on 12th September 2011
lol..useful stuff..I think that becoz maybe developers do not know about this thing..The use of javascript in several techniques is still out of some banging head tech gurus ;)
5:15AM on 13th September 2011
I've been testing many e-commerce website to use. all have pro & con. can't say any is better than the other. I'm not a programmer only testing how to use them.
3:47AM on 17th September 2011
Great stuff dude
10:32AM on 12th October 2011
With all the 3rd party apps for ecommerce, why do a new one altogether? Why not just use what's already there instead?
10:57AM on 17th January 2012
Great article, you are right when you say that some ecommerce (and not only ecommerce) platforms get their javascript wrong... and not only the javascript sometimes!
11:25PM on 16th May 2012
I believe, sometimes even small mistakes create bigger problems. Once those mistakes are unnoticed it grows and grows and finally has something bigger, especially when the problem is with the code.
10:36AM on 1st June 2012
Think of all those web analytic tools (Site Catalyst, Google Analytics, Coremetrics) that rely on javascript to collect clickstream data. If it weren't for the javascript I'd imagine it would be very difficult to collect this data. Some of them offer options to collect the same data via web logs (Webtrends) but not many of the pure play SAS offerings which rely of page taging.
5:42AM on 28th December 2012
I can't agree with you that "As website owners, we have to understand the technical aspects of how our sites actually work. We must have the knowledge and the will to enforce good architectural practices within our developer teams, which, from my delving into the code of some pretty big sites, seems to have utterly gone by the by." And I also found that the biggest problem I found wasn't that javascript made the checkout process smoother - it's that the add to basket and checkout processes didn't work at all.
Log in to post a comment