UI Improvement

Option #1 sounds great, google maps dependency would be nice but not needed.

+1 to postal code lookup.

Completed:
- Included hook_theme()
- Inlcuded preprocess elements
- Created base tpl.php file for form
- Updatd form style based on design mockup
NOTE: 'State / Province' and 'Estimate shipping' button still to be removed. See below images for more.

Items still to complete:
- Remove 'State/Province' dropdown option and 'Estimate shipping' button.
- Add 'Location Here' functionality (auto selected based on user browser or postal code information) (Location Here is placeholder only until functionality exists).
- Shipping options always displayed based on available information.
- Add radio selectors for shipping options.
- Add shipping total functionality to display selected shipping option price ($XX.XX is placeholder only until functionality exists).
- Complete styling to match design mockup (see note about styling below)

Not currently possible (based on current module and design mockup):
- Can't insert block between cart items and order total. Can only place it below or above.
- Can't style 'Shipping Option' output (eg. Express shipping and price). Each option is its own field and outputs as a string, therefor can't target individual parts.

EDIT: Ignore this comment... accidentally made a duplicate.

Fixed patch. New files weren't showing up when applying the last patch. This one is good.

Going to kick back to Needs Review for Hubbs #10!

FYI mglaman, TimRutherford has been doing some work on this and I expect a new patch will be posted from him tomorrow sometime.

I updated Hubbs patch and to add the above changes to the UI but in doing so I had to change a fair amount of the code/code layout.

I moved away from the block structure that was being used (If this is an issue let me know and Ill change it back) to just altering the cart form. This allowed me to stick the elements nicely after the line items but before the order total. With this change I moved the admin configuration to admin/commerce/config/commerce_cart_estimate (also linked from the module page). It also makes for an easier installation as the user just have to download/enable the module and set up the configuration options (no more moving blocks around).

With the removal of the state/province selection I introduced a new dependency 'Postal Code Validation'. The module takes a postal/zip code and returns country and province/state info. The form now updates whenever the user clicks off the postal code box or when the select a shipment option.

Currently the total order price does not update based on the shipment total. I tried updating it via ajax and css selectors but that turned out to be too buggy/hacky. The callback function that does this still exists in the patch but isnt used atm.

Finally, with all the structure changes (no more template file from previous patch) and css class/id changes the css will have to be changed accordingly to get it to look nice again. amberbam said she would update the patch again to include the css changes.

I changed the IDs and classes in the CSS files to match up with the changes that @TimRutherford made to the HTML.

One issue I see is when you put your postal code in, I think the natural next step is to click Enter on your keyboard since there is no submit button or anything like that. When you press enter, you actually remove your cart contents. What you actually need to do is click outside of the postal code input for your location and the shipping options to appear, which isn't very intuitive. The best solution would be if it auto-updated the location and options as you type in your postal code, if possible.

Updated the patch using @amberbam's suggestions. The enter/submit functionality for the postal code textfield now only updates the Cart Estimate and does not submit the cart form. I also changed some of the CSS to better match the given style.

Hey guys, thanks a lot for all the work in this issue! Just tested it out in a local install of Kickstart 1.x (as most users of Commerce aren't using the Kickstart 2.x theme) and it comes out like this:

I like the direction this has gone, but there are a few points I'd like to consider for further development here:

1. I don't mind the dependency on Postal Code Validation, but I just need to learn more about that module before committing to it (for example, how does it treat whitespace?). I suppose it's no worse than the current implementation, which was a very simple US / CA select list, but if we're going to add such a dependency I'd look to use our addressing library if possible. Typically you'd make a change like this in a separate issue, though.
2. I'm not sure this is going to work as part of the shopping cart form as opposed to a block. Especially since it doesn't play into the order total components list at all, I'm not sure it's appropriate to sandwich the shipping estimate in between the line item table and its footer / the form update buttons. What was the drawback in keeping this in the block? Was it just placement? (There's another issue in that this ties the module to a specific form ID and at least elsewhere in the patch tied it to the /cart URL.)
3. Removing the button makes sense, especially since we have Ajaxy submission of the element, but I wonder if we shouldn't keep the button and just hide it via CSS. (The custom JavaScript issue addressing cart form submission would go away if this were still a separate form as well.)
4. I don't really get the use of an options list for the estimated shipping rates (or the use of a separate column to repeat the estimated rate, given the amount is right there in the item). I'd probably just look to go back to the unordered list and remove the addition of the selected estimate, especially since it has no bearing on the actual cart order and is purely for display purposes.

Any feedback on these observations? The tricky part here is that UI improvements are intermixed with functionality changes. These can be hard to separate, but we can always split the issue up to address individual items as we're able.

@rszrama

1. Im using the library referenced from here: https://www.drupal.org/project/addressfield. Under 'Compatibility notes' it mentions the 'Field Validation' module supporting validating address field postal codes on a per-country basis using the 'Postal Code Validation' module.
2. Yes it was just an issue with the placement. I tried to follow the image given in the description of the issue as much as possible. It could be moved back to a block, although the base style would probably have to change to match it. I still think it would look a bit out of place at the bottom of the cart.
3. From what I understand that would work well it we go back to the block format, but if its part of the other form it cant be another nested form.
4. I agree with you here. Originally it was planned to have the estimate total be added to the order total, but this was pretty complex and kinda unnecessary (as its just an estimate). Now that it doesn't effect the price it should go.

I updated my previous patch to account for #4 on our list. There are no more radio buttons or total estimates displayed. I also updated the CSS accordingly.

Still not sure on what our final decision is for #1-3, so ill wait on that.

Reviewed and tested changes in Kickstart 2 and Kickstart 1. I can confirm everything at this point works as expected.

As a frequent online shopper, updating the carts 'order total' to include the shipping estimate is the better interface. Especially if the tax estimate feature is ever implemented and if a coupon/discount feature is ever included. It would be easier on customers to simply see the total after all the estimated line items are added/subtracted.

patch works for me. looks good. But we might want to split this issue into a few different issues as Tim's patch had too many functionality changes methinks

This is great patch in many ways - which, as @rszrama and @thejacer87 point out, is kinda the problem: multiple features blurred together.
As per his list:
2) I'm also unsure about the move away from the block approach (or as per @mengi's comment, if the estimate is going to be under the line items and above the total, it should affect the total and probably remain an option list which pre-selects for the customer). My preference would be to have the estimate stay away from the line items and pre-shipping total. This would also open up a clearer path to prepending or appending the estimate with another block for any other messaging we need to show the user before they proceed to check out (with this patch, if I want to append or prepend the estimate block, I've got to hack the module, play with javascript or do a complex hook_form_alter module).
3) I disagree with the removal of an actionable 'estimate' button. Some users will be stumped, not realizing they have to do something after they type their last key in the postal code field. A button gives the user a clear action. From a programming point-of-view, (one option) it doesn't need to be a 'real' form, the button can simply be an element that triggers the javascript.

For my use case, I'm not sure I like the move away from the block or losing the actionable button, but I love that we've lost the administrative-area select and provide the user with a starting estimate.