I feel a multipage checkout option would be very nice and could be used to provide users with javascript disabled the ability to still checkout.

I'm finding it quite strange that users without JavaScript can't checkout. Surely customers who choose to disable JavaScript (I know they are in the decline) should also be able to checkout!

I've actually implemented multipage checkout, because it seems to be the way our designers prefer to do things (I'm just a code monkey

Basically as Ryan said it's just about building the order object as you go along. I implemented this as I was learning ubercart, so there are alot of things I would like to change.

My current solution is more of a complete rewrite of the "GUI" of ubercart, using small adaptor modules to adapt things like shipping to my checkout process, and basically using Ubercart as an API and backend solution.
One of the main things I would like to do would be to take ubercarts "panes" and maybe abstract them so that they could be "pages".
I think it would be cool to be able to string a series of panes together through an admin interface, at some point I'd like to go back over my code and investigate the possibility of doing this.

If you guys are going to set up a project to do this, please PM me, I'm keen to help but only check the ubercart forums every few weeks.

From an interface designer perspective I am quite torn. I really do think the "opening" panes as they are now are not working at all - they are confusing as hell to a user - they basically unite the worse of both worlds. As with single page checkout - yes that makes loading times less and make the user not think "oh there is so much more" but its a huge amount of info on one page - and I know for fact that when I showed that to people they where actually totally turned of to complete an order - in that regard I think a multi-page checkout is the way to go (and I though I had this going already for an early alpha version ??). It provides clean simple steps to proceed. What is important is that you show the user where they are currently and what more is expexted of them - like in a step by step breadcrumb or a list way. I see this more and more all over the net and I think this is the direction that makes most sense. Little information overflow - little unknown territory. (I studied communication design with interface design slapped on - not that this makes me an expert but I was taught what to look out for). As people are torn on this topic I would say it probably needs to be an option - but as said the current collapsing panes are really bad - they barely give you a glimpse on what is needed, they overfill the page with info, they move mouseclicktargets (the worst thing you can ever do to a user is move mouseclicktargets - it flat out frightens them) and they need javascript (brrrr).....
From a webdesigner standpoint I also would go for the single page one as they avoid scrolling the page, give you nice little information to style around and give you a clean way to work with...

just my 2 worthless pennys of course.....

I'm not really familiar enough with how panes are working in ubercart (I've kind of written my own checkout process over the top of ubercart in order to get the multipage thing going), but can we just render panes on multiple pages, take the submission data and put it into a "dummy" order object until submission of the last page, upon which a new order is created?
Or is everything tied up too much with Javascript currently?

The approach of having multiple pages could also bring up a few issues with concurrency of cart and order (at which point do the contents of the cart join the order?)

My feeling about single pane checkout from a customer point of view is that it is a lot of data to be getting right on a single screen. If a website is going to choke on my order, 95% of the time it's on the payment. The payment error may be caused by anything from my CC being temporarily blocked by the bank to a programming error to an unannounced ISP upgrade of PHP. Then either I get some ugly undecipherable error message on the screen, or get kicked back to the checkout page.
In the first case I lose all the data I entered. In the second case, after I get kicked back to the checkout page, often one or more of the fields that I filled in previously has blanked or mysteriously changed. So I have to go back and check everything, and I don't do that very well, because in my mind I had already checked the data I entered. After going through this a few times, I usually give up and go to Amazon.
If my address information and shopping cart were saved, I would be a lot likelier to complete the order once the payment problem was resolved. I think I saw an ubercart contrib for an ubercart address book. This might be really helpful.
One other thing that bugs me... I really don't like sites that say, after I press the "confirm order" button, only something like "Your order was received". I need to have notice if I'm about to miss the only chance of printing my order.

I really appreciate all the hard work that has gone into ubercart... it never ceases to amaze me what a good collaboration ccn accomplish!

Andrew

Do you guys see this multipage functionality as something that could be provided in a module, or something that needs to be incorporated into core?
As I've mentioned before I've written my own module to do multipage, but it's more customised to the checkout processes of our clients, and it's for the most part separate from the normal ubercart checkout, meaning all the administration pages for checkout don't really have any relevance on our sites.

I'm keen to lend a hand in doing this, I just wanna know if I should take a shot at rewriting my module in a more generic way attempting to use the ubercart pane system, or if there should be an effort to get this into core?

I guess I'd say both. We were in agreement w/ Hone's statements about checkout, but hamstrung ourselves in regards to a non-JS checkout. I am a little concerned about how the current system will play with the new #ahah stuff in the D6 Forms API when JS is turned off, so having a multi-page checkout in core to fall back on would be ideal.

My goal would be for it to work with the checkout pane system, though this coincides with my desire to redo parts of that system to make such a thing easier. This would be part of my desires for optimization in D6 development.

The quickest way to move here would be for the work to start out as a contrib module, since as the roadmap indicates, I won't be approving any major API changes like this until Ubercart 2.0 (hereafter "Uber Tuber") for D6 is done. However, if we have a good, working contrib that provides an alternate checkout by splitting up the checkout panes and maybe just preserving data from the previous panes in hidden form fields... that would be excellent. It would be much faster to test and then integrate w/ core.

I'm looking for lean code that still maintains a level of flexibility. For example, a non-coder might need to be able to decide which checkout panes to put on which page. We might also need to get pane dependencies in core so users can't screw things up by putting the shipping quote page before the shipping address page. Things like that...

I'd love to hear any thoughts on this or the D6 development roadmap thread.

I am quite uncaring for "how" the functionality is put in place as long as its robust and solid - does not even have to have much featuritits - just splitting each pane as it is now (as selected) into its own page would just do great.
As for "just rolling this into a D6 only" release - I am very very unhappy about that I have no plans to upgrade my site to D6 in the foreseeable future (it took me a year to have a D5 site running now and about 60% of the modules I use do not even have started a D6 port). So if you plan Ubercart 2 or whatever make sure its backward compatible with D5.

I do like the suggestion to save user input before the the transaction is in place A LOT! I too as a customer have had situations where I did not make the purchase because all my entered data was lost and there was no way to go back to where I was.

So a "this is your shopping cart at XXubercart store" email with login information and the current shopping cart and all information the user has put in would be a heaven send! (along with a customizable note like "if you do not recieve a order confirmation please click >here< to go to the payment page" or something along those lines...

Again thanks for the awesome work so far!

fALk wrote:

As for "just rolling this into a D6 only" release - I am very very unhappy about that I have no plans to upgrade my site to D6 in the foreseeable future (it took me a year to have a D5 site running now and about 60% of the modules I use do not even have started a D6 port). So if you plan Ubercart 2 or whatever make sure its backward compatible with D5.

Well, we'll be developing Ubercart the "Drupal way", which means backwards compatibility in versions will not be preserved to spur innovation and continued improvement of the core code.

However, my comments were that a multi-page checkout form can be achieved in a contributed module now w/ the Drupal 5 version that could be rolled into core during Drupal 6. The idea here is that code should be tested and stable and examined for optimization before it gets committed to the actual core code where we'll have to maintain it indefinitely.

@insurrectus: sweet customization... your site always looks great. Perhaps you should add the >> to the Review Order button, too? It was a little lost on my screen.

What is the basis for your belief?

When it comes to conversions, and thus revenues from an e-commerce site, testing has the final say. Everything else is speculation.

And as I said earlier a lot of really large e-commerce sites have multi-page checkout. I would think that someone looking at revenue streams in the hundreds and thousands of million dollars have done their homework and did not leave anything up to speculation.
Which tests are you referring too?

Very cool! I'll try to check it out today and post up some feedback.

As said before I have actually studied interface design there was an interaction lab in our school - kinda sophisticated stuff that tracks eyemovement and time to click etc. and then you have test persons and they fill out sheets of their experience explaining what works and what not from their totally unbiased view (in a certain target group). One thing has been clear with every single "webexperience" test that the lab has done - put too much information on one screen and the people using that leave in horror, or have a very bad experience elevated stress levels etc (something you don´t want to do to your customers in any way). This was portals, shops, information sites - the results where the same across all age groups and target groups - the simpler the interface the less information it had on one page the more people enjoyed using it. At one point there was a discussion going so far that scrolling webpages themselves are very bad interface design in regards of usability, brand recognition and simplicity to use - put a form on a scrolling page and especially computer illiterate people will have a hard time completing that form. This might sound strange to us geeks but you can witness that in real life a lot too if you look beyond the geek target group. I would say some shops might do better with a pseudo single page checkout because they might cater to the fast paste geek crowd but beyond that I would highly doubt - from what I have seen in the lab and on the street - that a page packed with formfields is faring better then a clear obvious step by step nonscrolling checkout system.

But I think we already agreed that to have both is probably the way to the future.

Just wanted to post a quick thought here regarding the POST vars to keep track of where you are in the form. Is there an issue with utilizing Drupal's Forms API, and using a Multistep form? I believe there is an example of how to do this in uc_file.module...

fwiw, I'm not actually a developer of this module. I was just brainstorming.

I actually implemented those checkout links today. And the only ways I could think of doing it without hacking ubercart was with submitting forms and changing the session values or using AJAX.
I tried the forms, and wierd stuff was happening.
So in the end I used ajax. You click a page in the list, a callback goes off and changes the session variable, the page is refreshed and you end up on the page you chose.
far from a nice solution, but it seems to work.

You probably noticed, but "one-page checkout" is a little inaccurate for what Ubercart does. There is a Review Order page between the page where all of the information is entered and the Checkout Complete page. Since the button on the Checkout page is clearly marked "Review", I would hope that more people would be less hesitant to click on it.

Ah thats sad - but oh well what can you do. As I am stuck with D5 for the time beeing I greatefull that there is any solution at all. (I would just love to avoid javascript wherever possible).

Thanks Brick for all your work so far. I have already implemented a working version with v5 of your plugin which works better then I first thought (so there are small inconsistencies when going back and forth the forms a lot)

And for the semantically correct or incorrect - I think ubercart is inherently inconsistent in proposing a one page checkout - which in the end is multiple pages anyways - just not with the nice organisation of a multipage
(two pages full of crammed information and users desperately trying to figure out what where how while their senses are swamped - I would close the window before ordering if that is a product I do not absolutely need - it would take the impulse buying impulse out and I consider myself an experienced computer user) but I guess we covered that discussion above. I still do not get why it is so hard to do multipage forms correctly - there are lot of modules out that make use of d5 forms api for multiple page forms - gosh I wish I would be more programmer brain then designer brain and be able help out.

That is the favored approach

Just one more thing to add. I have said it before - I know that computer guys always want to be ahead of the curve and force people to go along the way - but I am very frustrated with the pace of how drupal went from 5 to 6. I got into drupal around the time when version 5 stable enough to use. It has taken us over a year to develop one site and another 7 month to develop another (side by side). To now switch these sites from D5 to D6 will likely take another 3 month at least (we are a very small team here). Also there are tons and tons of modules that have barely made an alpha version (read: not production ready) and still a lot who have not even started to move to D6. Hey I am all for fast paced innovation in general but never to the expense of a product that is merely a year old where 75% of the user base is still on the old version. Abondening D5 (leaving a half finished product behind that is) at this point I don´t see as a good way for drupal or the module.
Please understand that is not a rant per se - I can sympathize with drupal developer - the bit I am lurking into the underlaying foundations of drupal 5 show massive amounts of problem in almost any area that make developing a constant workaround but it is as it is and I would really be interested in how many people actually are making the switch to D6 in the next 6 month from their running D5 site. The revamps for our site are so severe that is would need reprogramming lots and lots of code throughout the site - some fundamentals have completely changed (menus) - its a massive amount of time invested to get - to the end user - very little benefit. (I see D6 a developer update). Heck I would love to skip D6 and wait for D7 - if it werent that some modules just starting to stop maintaining their D5 version - which is very uncool - especially when their D5 versions are not a finished product (so I donßt consider ubercart an unfinished product - in my opinion it could go to 1.8 before you move to D6 there are still rough edges - multipage the most prominent for me as it actually hold up people from making a sale).

So to get back to the original topic - anyway there could be any backporting happen of the new checkout api for d5 - or at least make it easier to make an addon module to support multipage until that point? Something we can use now rather then wait or D6 to mature enough to even consider a switch?!