Design for Add/Edit Product CPT

[InstinctBrett]

Sketchbook: http://imgur.com/a/bUN9F

Problem: Metabox overload

There are just too many metaboxes on this page. In the most common scenarios, most of them are ignored. Finding the right metabox needed for your desired task is a challenge.

Solution: Reduce to tabbed metaboxes We can break metaboxes into three distinct types: Product Details, Product Delivery, Other.

Product Details

• Additional / Short Description
• Metadata
• Images

  Product Delivery

• Shipping
• Downloads
• Personalisation
• External Link

  Other

• Pricing
• Stock
• Taxes
• Discussion / Reviews

Hopefully these are obvious in the photos of my sketchbook.

Opportunity: WP 3.6 Post Formats -> WPEC Product Types

Two are really obvious: Physical and Digital. Group could be another product type. Group/Package functionality -> #386

Variations

Variations doesn't really fit wholly as a product type.

What is really important about Variations is handled in the normal columns: SKU, Price, Sale Price, Stock, Taxable Amount.

Currently, you can also edit shipping settings for variations. I imagine the primary use case this would be prepackaged volume bundles (I think various sizes of Coca-Cola bottles you can buy: can, 600ml bottle, 6x Cans, 1.5L, 2.5L, etc.) -- all have different shipping sizes and weights.

If you want to charge extra for personalisation, you can't at the moment. If you want to charge extra for more bonus digital downloads, you can't.

Variations specifically should change something about the product's delivery. In this case, we have a Product Delivery metabox. If we tick the variations checkbox on this, the tabs all disappear and we get the Variations metabox contents instead. Inside each variation, instead of only shipping, we get the Product Delivery tabs, enabling a variation on shipping, downloads, personalisation, and other things (such as granting a new site permission).

That's a first stab. Hope you understand it all.

[benhuson]

Interesting issue:

As WP 3.8 supports media queries which increase the size of element when being viewed on smaller screens, at a certain browser size the variations panels which is loaded into an iframe displays larger (as it uses the mobile CSS) while the rest of the page display at normal size.

Any thoughts on a way round this? Do we mind for the moment?

[JustinSainton]

Hmm, interesting issue, for sure. We'd essentially have to write media queries for the variations iframe that overwrite the 3.8 media queries if we wanted to address this. Does it ever actually become unusable?

[benhuson]

Bit on an inconsistency between the product details tab panel and the variations tab panel.

I guess the variations panel should be in an inset box like the product details to keep in line with WordPress SEO and other implementations?

[JustinSainton]

Yeah, I'd agree with your assessment there, I do think it looks better.

[JustinSainton]

I'm super happy to be out-voted on this - and I recognize the potential conflict of interest, being American - but the native locale of WordPress is en_US. Might this ticket be a good time and place to consider standardizing on that throughout this screen (and perhaps another ticket to standardize throughout core).

The only reason I bring this up is that there has lately been a big push in translation efforts for the en_GB translation of WordPress - I would think that those who have enabled that translation might like this spelling, while a more standardized translation of WP e-Commerce would fit better within WordPress.

Thoughts?

[instinct]

Yup I think this is a good idea.

[leewillis77]

+1 for en_US as standard.

[benhuson]

Makes sense for en_US as standard. Let's do that.

[instinct]

Hey Ben I don't suppose you have the time to get the add product page to a happy place / ready for merging for by early next week?

Gary has informed me that he's going to push out a fix for the customer meta stuff and I'd love to include this work too if possible.

d

Sent from my iPhone

On 3/01/2014, at 5:24 am, Ben Huson notifications@github.com wrote:

Makes sense for en_US as standard. Let's do that.

— Reply to this email directly or view it on GitHub.

[benhuson]

@instinct Will rebase tonight - there's a few conflicts so I'll submit it as a new PR. Should take long to then address those last few points.

[benhuson]

@JustinSainton Can you check wether I've missed any en_US strings in this latest PR #774 Thanks

[instinct]

just curious - @benhuson @JustinSainton is this ready to ship?

[benhuson]

I think styling-wise it's in pretty good shape.

I've not been through and fully tested all the functionality since the original work by @iorivn so it could probably do with a good test of all functionality to test it works as expected.

[JustinSainton]

Closing as completed.