Joey asks;
I saw your admin contribution and went to your website. I am having an issue {&} if you can help that would be great.
I made a nice shop but I am new to php and can’t figure out how to merge {PWA and STS}…THANKS!
Where do I start? 😉
PWA (Purchase Without Account) is a totally un-necessary contribution that adds no value to the average osCommerce shop in any way, shape or form. What you need to do is think about how a customer perceives your site and move on from there. Within the official forum there is a very long thread started over 5 years ago by myself, which is ongoing – search for “Customer Login Routines”. My suggestions is as follows;
- Rename parts of the checkout procedure so that they are less “in your face”. Eg, chenge “create account” to “your details”.
- When starting the checkout, start on “your details” NOT “login”
- Remove the password input boxes from the “create account” page. Add a checkbox saying “remember my details” instead.
- Create a random password for EVERY customer.
- IF thy checked the “remember me” checkbox, then send an email with the password. If they did not, then don’t send that email.
- Sanitize the rest of the checkout procedure, by removing some of the unnecessary pages.
If I can find some time, I will make an optimised checkout that does exactly this.
Simple Template System – the ability to design an osCommerce store by amending one file, rather than 30 or 40. This is even more un-needed in the average osCommerce Store.
It’s a pointless contribution that serves only to make your learning of PHP and osCommerce almost NIL. You say that you are new to PHP, and yet you want to use STS to design your site – meaning that you’ll never get to experience the “joy” that working with core code brings to you. You can only learn by getting your hands dirty and you simply cannot do that with STS.
If you already have STS installed, you’ve already stumbled across another real problem that STS brings to you – it’s harder to add contributions – and as only “newbies” and “lazy designers” use STS, it’s almost impossible to find good help.
Also, it adds more layers of code to an already over-coded piece of software – it makes sites load slower – it’s an all round mistake to use it.
Suggestion: Remove STS. Go back to standard osCommerce. Take the time out to learn at least some of the code within osCommerce. You’ll then be able to add Contributions easily.
Did you realize that I don’t like STS ? 😉 It’s the WORST templating layer presently available.
In V3 of osCommerce will be included it’s own templating engine, could be worth waiting for, but who knows when v3 will arrive?
For anyone reading this who wants to properly learn a bit about how to lay out an osCommerce site WITHOUT using some flaky templating system, you could do a lot worse than have a read of “Designing for osCommerce” available from www.oscbooks.com.
Thank you for the reply and I just wasn’t aware that it was a bad idea to use STS. I learned about osCommerce just last week and definitely want to realize the best ways to work with it. Obviously I have much to learn. Your advice has been great!!!
I like your comments on how to implement a checkout system that does not require a password, however there is one flaw in the logic I see. By generating a random password you allow them to checkout yes, HOWEVER if they want to place another order it will be quite hard for them, if not impossible to place it using the same email address. (lets face it they will never remember the email you sent with a random password.) Can you suggest a work around for this issue?
Keith – the “forgotten password” link springs to mind…
Gary that would be an obvious choice… however I can tell you from experience that will not fly with over 50% of your customers, you’ll just lose the sale for two reasons. 1) They will become frustrated because they thought they did not create an account initially and leave. 2) Lets face it, most customers are lazy and impatient, they will leave when they find out they cannot login without a password. We have a standard oscommerce checkout and I’d say approximately 40%-50% leave and don’t come back when they cannot remember their password, they are too impatient to ask for a reset password, check their email (assuming it makes the inbox), come back, and login to checkout. I can only imagine a much higher percentage would leave and not come back if they thought they never created an account, I know I would if a site told me I had created an account and I had not.
Can you suggest a more easy solution from the customer’s perspective that will not cost you business? After all that’s the entire reason of going to purchasing without an account….
My experience differs to yours.
Over the last 9 years, across in excess of 300 stores, I’ve tried all sorts of ways to get clients not to bail out of the checkout process and to have a harmonious experience when returning to a store. That’s how my own checkout system came into existance – efficacy data gathered over years, from many stores.
Maybe we just have a more fickle customer. I’m just trying to cut down on the reasons for the customer NOT to complete their transaction… Your solution is elegant, easy, and almost perfect I must say that, but the part where return customers have to have their random password remailed to them to checkout a second time still leaves money at the door.
Trying to rethink this last part of the problem, what happens if you just remove the error checking in oscommerce checkout so it allows multiple accounts with the same email addresses? That way they could checkout again without having to request a new password if they are a repeat customer. Would think cause huge issues with oscommerce?
Keith
“the part where return customers have to have their random password remailed to them to checkout a second time still leaves money at the door”
I think you are misunderstanding – this doesn’t happen. The password is sent to them at the time they create their account. If they lose that email, then of course, they can use the reset pw link.
Anyway, besides that, I’m intrigued to know what you are basing your perception on. Do you have any data to support your view that a customer not manually creating a password at account_creation will lead to less repeat visitors?
My own -opinion- is that making a customer give too much information will turn them off.
Oh – I do webmaster a site in which we have the ability for customers to keep signing up again and again. It’s not great, as it ruins the admin area – of course with lots more work I could code up a solution to tie up all the same customers, but it’s simply not viable to do so.
I think you are thinking too much 😉
Good to know someone has tried that, I guess we’ll avoid the route allowing them to signup again and again, how does it ruin the admin area specifically? Does it cause any performance issues?
In regards to purchasing without an account it is a commonly held belief that it not requiring customers to create an account increases sales, it has been tested time and time again, every conference I go to including the Internet Retailer conference says to get rid of the registering. Here’s just one of the articles from Bryan Eisenberg’s company (Future Now or grokdotdom.com) about it, which I’m sure you know he is very knowledgeable in the optimization field, there are dozens more articles about the forced creating account causing lost sales on their too…. http://www.grokdotcom.com/2007/10/03/yes-or-no-why-must-i-choose/
You, I and Brian all agree. We just see things from different angles.
Well said.
I have created an add-on that now incorporates the ideas given here:
Sam’s Anti-hacker Account Mods V1.4
Features:
Provides a option to Remove password input requirement, if enabled visitors are redirected to checkout on completion and makes the personal details input a seamless part of the checkout.
A new option is added to require the user to input a ‘strong’ password, or ensure generated passwords are ‘strong’.
The date of birth field is now a drop down which automatically formats according to the store country, this ensures the format is correct, slashes (/) can still be sanitized and the visitor cannot transpose days & months.
The telephone field is checked its numeric (if entered) and contains only limited allowed chars.
The fax field is checked its numeric (if entered) and contains only limited allowed chars.
The post code field is checked for the correct format, but only for UK, USA, Canada, Australia & France addresses, valid inputs will be reformated to standard code format.
If strong password is enabled, password forgotten will generate strong passwords.
The State/Province/County: field is pre-filled with the zones for the store country, rather than a blank field that gets populated on submit!
The Country drop down is pre-selected to the store country.
Ajax code is used to auto update the county drop down on change of Country Selection, operation is as similar as possible with javascript off.
Name, Address, Suburb and City Fields are subject to additional validation, limiting word & character count.
Has new modules for name & address validation used by all account pages.
Has new ‘single’ address input module (again used by all account pages) that orders the input adddress fields according to the supplied country address format.
Contact Us is expanded with details based on ideas in Super Contact Us add-on, but orders id is taken from dBase & provided as drop down.
All input fields (post vars) are sanitized, any ‘latin’ characters are allowed
Add-on is at http://addons.oscommerce.com/info/7202