Editing order UI

Have a look at invoicemachine.com and how they approached the invoice (order) editing

I do like bringing the products / line items front and center like you have. Makes perfect sense.

I don't get from this how you conceive of someone setting or changing the customer on the order. What you're showing here only seems useful for viewing.

Also, it's been discussed elsewhere (does anyone remember the Ubercart issue by any chance?) and I think people have said that selecting the country first in address selections is the most helpful. This will allow us to swap out all the name / address fields as necessary before data has been entered, like including the "Greeting" for Japanese addresses.

I'm also wondering if we shouldn't just scrap the Payment edit pane altogether. The idea was it could be used for storing details of the current payment, but it falls short on orders that have multiple forms of payment, recurring payment, complex payment systems, etc. I think we'd do better to make a more robust payment terminal for data entry (i.e. a two step form where you choose the payment method and then enter the data : ?) and figure out how to list payment receipts on the order view screen in a better way.

I also don't understand your comments section here. Can you explain a little?

Great work bojhan, some suggestions :
1 - Wouldn't it be better to put the paymant box (if you keep it) on the Payments tab ?
2 - For the billing and shipping address, having the address book as a simple dropdown (if it only lists the current customer's addresses) would be simpler. Also, the shipping box could have that "same as billing" checkbox.
3 - don't know exactly how but i think Vertical tabs can be usefull here...
4 - Lessening the number og objects in the page : We should thing if there is some items that are not necessary in the edit order page and that can be removed. For example, do we need to show the customer's email address ?
5 - Last "and may be least" . I don't think that the order's table should be wrapped in the box titled Products, as this is the main part of the form, the order content. And that could spare some white space :)

PS : This is not directly related to this issue but while we are at it, ryan, it would be great to have the order columns swappable (using weight maybe ?). Not all countries use the order title/SKU/qty/unit price/total.

"I don't get from this how you conceive of someone setting or changing the customer on the order. What you're showing here only seems useful for viewing."

Hmm, yeah, I probably wasn't clear enough. What I meant to question was how would someone change the user on the order? It should be possible to change the user, although you're right, it's not necessary to be able to change the e-mail address and not the uid (well, unless we allow truly anonymous orders, which I think we should... so for anonymous orders there would be an e-mail field with no uid).

In other words, would someone have to click on the uid (I see you have it as a link) to be able to change it? Or would that link redirect them to the user profile? That would be unfortunate if they had unsaved changes. : D

Hmm, I don't think it's possible to remove entirely. The reason it should be changeable isn't so much for changing the uid of an existing order, but for when you're creating new orders manually and need to specify which user it is for.

Hmm, well, the way it works now, there's a simple step where you specify the user for the order and then click "Create order." From then on out, it's the same as the edit order form. I think that's fine and dandy, but we'd have to think through the workflow of what to do when creating an order and a user does not already exist (i.e. would we want the admin to just be able to put in an e-mail address and automatically match that to an existing account or create a new one on the fly?). Even still, I don't see any reason to not make the customer user reference editable on the order... mistakes can be made or accounts might need to be consolidated where switching the user from the edit screen would be justifiable.

Hmm, I just realized we might need an additional fieldset that lets you edit the creation date / user of the order, like the "Authoring information" fieldset on nodes. Presently with Ubercart we don't have creator uids but have specified adding them in for DC, and there was also never anyone to change the date on an order if you needed to.

I'm loving seeing the progress of the UI designs. Here is some input I hope will be helpful:

* the check box to specify that the shipping address is the same as the billing address might be better placed above the address rather than below
* The order status seems to be missing. The best implementation of this that I can think of off the top of my head is including a small table summarising the history of all order statuses which have occurred. You could probably incorporate any order comments into this as well. Any items in this small table could link to the appropriate detailed record elsewhere.

Quick question - is the x on the far left of line items for draggability or for deleting?

Here's the latest version of the line item UI as available from my GitHub (click for full version):

I've done a little styling to make sure the table's caption appears to the left and over the table like a fieldset label. I also moved the "Add line item" button beside the type selector, although there wasn't actually a selector present in Bojhan's mock-up. Perhaps what can happen is we can default it to be a link that when clicked will swap it out with this form... but then it's just one more click to add something to an order. : ? Maybe we have it appear this way on new orders but for existing orders hide the form behind a link...

Also, I don't currently have a two-step process for adding a product line item to an order. It's simply a 1) click the "Add line item" button, 2) select the product, and 3) click the "Add product" button. This interface will need to change... most likely some sort of autocomplete would be sufficient. I don't think we need to have a product type filter, but that could be addressed.

I'll most likely need someone else to do further styling, like on the colors and borders of the table and to change buttons to look like links (i.e. for the Cancel button on the form that shows when you click "Add line item").

Also note that the "Remove" checkbox will be themed into an icon as specified and altered via JS to submit the form so items can be removed on a single click. I'll be doing something similar on the shopping cart form... which can probably reuse this field. Nice!

Looks great!

Just a quick comment on the "same as billing address" checkbox:
Would it make more sense to have that above the other fields? It would seem that this would be the first thing you'd want the user to notice before they started filling out any fields :)

Just a quick suggestion : Shouldn't "delete" button (actions in general) be on the right side. It seems like in general (and specifically in drupal) actions go on the right and status messages (icons) on the left.

Being an ordinary buyer myself I would prefer it on the right, at the end of a line. Its a kind of Cancel...
But its a matter of habbit. When I came to Hong Kong I was shocked that all the cars where driving the wrong side of a road :)
Amazon places it on the left, for example.
Probably, functionality now is more important than UI, and later everyone will position it according to personal tastes.

Subscribing...

Regarding #7, I've started to style the "Billing information" address fieldset using only css. I tested it in the last Firefox 3.6 and Webkit engine to date.

Problems :
- the drupal_add_css may not be at the right place, so the css file may be loaded in un-necessary places
- it's css-only changes, deeper changes may need html markup changes, which may need patches in addressfield module (not sure, couldn't find the proper place to edit addressfield fieldset in code)
- the sizes are wrong, in small width screen the labels overlap
- didn't test in IE

Code found here : https://github.com/DjebbZ/drupalcommerce/commit/d3e47beef123540a639dd807...

Tagging.

Here's the documentation for the #attached property I mentioned for adding a CSS file to a form:

http://api.drupal.org/api/drupal/developer--topics--forms_api_reference....

The problem here is how to make it work across multiple themes. We can't have a nice UI that only works in Seven theme.

Also having form field labels on the left of form fields is good for lowering the vertical space, but it creates another problems like when you resize the screen, the labels can wrap the line and mess the entire form. This also can happen with a translated text, that's bigger than the one it was designed for. There's no way to make this work consistently.

To improve the page we can do two things:

1. Make the Billing address half of width, so to create space for the Shipping address
2. Improve the line items table to make it consistent with others (having Product (with SKU in parenthesis), Price, Quantity and Total, for the columns/headers), this can either happen by making this table a view (#842036: Convert the line item manager widget table to a View and #1029996: Make order editing form a view), or just changing that in the code for now.

If that's ok for now, I'm going to work on that.

Untagging. recidive raises good points in #31 that deserve further discussion, and though I would've loved the interfaces to be nicer for the release, a beta is about function not form. This is obviously still a priority item. : )

That was my hunch (and I think I talked w/ recidive about it in IRC) - we'll still need a solution for viewing that works on Seven for administrators viewing / editing orders but that is a little more bland for viewing orders on the front end. (Although this is the edit issue, so that comment may not be as pertinent in here. : )

Here is how it looks with Djebbz patch plus some more work I did in it (removing fieldsets backgrounds and making css rules target classes instead of ids).

In 1024 x 768 resolution it looks ok:

https://skitch.com/recidive/rtuim/order-1-drupal-commerce-1

In 768 x 1024 (iPad in portrait mode):

https://skitch.com/recidive/rtui2/order-1-drupal-commerce-3

It's not that bad.

But look when I change admin theme to Bartik:

https://skitch.com/recidive/rtusx/order-1-drupal-commerce

I think the forms should be at least usable across all themes, which means messing around less with CSS, not more. We can't rely on some theme positioning, floats, etc. Also Seven fieldsets are already themed this way, if we add more styles to it relying on Seven CSS rules, this can display even bad in other themes.

Would this also be the appropriate area to note we currently dont have a way to use existing customer profiles when creating or editing an order via the admin interface.

Should this be a separate issue or can it reside here?

Let's make that a separate issue - I can't recall if it already has one or not, but look for an issue in the "Contributed modules" component regarding address books. I think that's where the discussion's been thus far.

I do think as part of that I mentioned to Bojhan we need mock-ups for addressbook inclusion, though. So maybe this isn't a horrible place for it to be.

Is there a sandbox or something where we could follow up this work (like the Inline Entity Form) ? Or this will be directly in core ?

There's nothing to follow, no work was done on this.
Kickstart v2 should have some work done on the order workflow, once there's something to share, the issue will be updated.

this sounds more like a Commerce backoffice issue/task.

here is patch that put the profile form elements in 2 columns.

This is a historical issue at this point, so let's open a new backoffice issue for the patch.

Commerce Backoffice issue opened, including the #41 patch:
#2064201: Order edit UI

Fixing input format.