Presentation Settings #516
Comments
ghost
assigned 
|
|
Thanks @benhuson :
Is there any way to move an issue ticket along with all the comments to another repo? I feel this should be posted in the theme engine repo as it is more relevant there. A lot of things in the old theme engine are now outdated and not used in the new theme engine anymore. That's why we're trying to get developers' input about what options users should be given to customize the presentation of their site. I believe we should get rid of as many presentation settings as we can and give more control to theme developers, not users. Imagine this: if we give end-users 5 binary settings (yes/no settings), that means theme developers will have to account for 2^5 = 32 different combinations of settings. There will be a lot of "if then else" in templates, which make them hard to maintain. Options such as "Show stock availability", "Disable Link in Title", "Show Breadcrumbs" etc. should not be made available by the core theme engine. There should be a consistent default state, and theme developers should have a choice whether to offer these options to their users. WPEC core is not the proper place for these settings. Plugins such as bbpress, buddypress (or any other plugins by automattic) do not provide presentational settings like this to the extent that we are currently doing (most provide none). My opinion is, these settings should be removed from the settings UI:
The only settings I'd like to keep are:
The reason why I'm being extreme with this, is I think a lot of presentational options have been accumulated over the years, and a lot of them are not relevant anymore. This time we have a new theme engine, and I'd like to start from a clean slate, do user studies, and keep core settings minimal. |
|
I tend to agree @garyc40 but we have to be careful not to make WPEC too hard to use for your average WordPress user - we can't assume the majority of WordPress users are Theme creators and Plugin developers. I think this illustrates another great reason to merge / make sure the Add-Ons page @JustinSainton has made for us is available with WPEC yesterday - that way we can make sure that any Plugins we make are obviously available and featured accordingly to our less savvy users. Actually perhaps a lot of these settings already exist in the Plugin Jack Mahoney did for us? I'm not sure it still works but it'd be amazing if it does!!! Because its awesome. I'm happy to have the conversation here because there are more community members reading this thread then anywhere else, either way may the robost discussions and community consultation continue :) |
|
I said "great reason" to merge the add-ons page. I think I meant to say of "critical importance" ;P |
|
While we're discussing Settings and really, the onboarding process in general for users settings up their store - take a look at iThemes Exchange. The onboarding process isn't perfect, but it's world's apart from ours and we could likely learn a few things. |
|
Product ratings could go in a plugin. |
|
I tend to entirely agree with you. My thoughts;
|
|
There's a couple of reasons I wouldn't recommend putting thumbnail options in the customizer. One is that I think of the customizer as theme territory and WPEC as a plugin. The other is keeping things together and not making the user search different places in the dashboard is key for useability. I love infinite scroll, but I definitely think you should keep it in plugin territory. I assume you're going to make these plugins premium and I support you making money from this project. |
|
Yeah I agree with you about the WP customizer. So thats pretty good because @garyc40 already wants to keep thumbnail settings. We just need a few more thumbs up for fancy notifications and pagination :) And thanks David for your words of support. |
|
I'm for keeping notifications and pagination. |
|
+1 for keeping fancy notifications. Could these be on by default? Do we even need a UI option for it - would people want to turn them off? Pagination also seems pretty critical. |
|
@leewillis77 Yep, I always have fancy notifications on. |
|
We're about to start work on this issue too. Any more thoughts / feedback would be welcome :) |
|
@leewillis77 @benhuson since we're working on this now... what are the negatives around NOT having a fancy notification option on this page? Its true I very rarely don't use it but some non advanced users might feel it over kill if there is only one or two products in their catalogue? |
|
Pagination is probably ok to keep, but I'm not sure about fancy notification. In the new theme engine, when adding an item to cart, the customer is redirected to the cart page. This is the standard behavior of an vanilla e-commerce site. There is not yet any plan to add AJAX interactivity back into the mix, as we're still trying to nail the "business logic" layer of the engine. "Interaction" and "presentation" layers can wait. Adding back AJAX has to be done very carefully, otherwise we'll also end up with a front-end JS mess that we currently have. Having notification on by default is also probably less user friendly than we would think. I'd say we should start with a conventional checkout flow (view product -> add to cart -> review cart, then either checkout, or go back to shopping). Then if the use wants something advanced, we make sure there's always a switch (or an add-on) that lets it happen. Even if we do add back the notification feature to the new theme engine, it has to be done differently. It shouldn't only display a message saying the item is added to cart. That's pretty unhelpful. At least it should let user reviews the current cart before dismissing it or proceed directly to checkout (without having to review the cart again). |
|
Whatever the case may be we can't launch 3.9 without an answer to fancy notifications. Ikea have a nice fancy notification type solution: Whereas Amazon dont: Although they do have a 1 click to buy option. Whats important is the insights from our community which represent the users we know about. So based on what @garyc40 has had to say what do we want to do @benhuson @leewillis77 @JustinSainton @visser guys? I know Edward likes ikea :) |
|
I have a feeling not have a fancy notification replacement would be frowned upon by our community. So figuring out the best most WordPress way of doing this is probably important. |
|
I agree with Gary about the fancy notification, we should not keep it in the new release. The notification doesn't provide much information. After adding a product to cart, it costs user at least 1 click to go back to category browsing to continue shopping anyway. Furthermore, according to my observation, users usually do shopping using multi-tab browser, they simply close the tab and go to other tabs after adding product. If we are going to keep fancy notification, we should make it more informative. But it is quite messy as Gary explained though. |
|
I`ve seen users asking that while adding to cart to go to checkout directly and some are using it as we have it now. Maybe we can do it as a separate plugin that gives users 2 options for setup:
I like how opencart does it, after adding the cart it shows a notification under the navigation menu and scrolls the window up so you can notice it. With link to the cart, product and an X to close the notification. |
|
It's hard to say whether it's going to be frowned upon by our community. Sure it might be missed, but that doesn't mean the new checkout flow where the customer gets to review their cart is bad. There's not any plan yet to add back AJAX, but that doesn't mean there won't be. I just want to focus on nailing the "business logic" layer of the theme engine. The "interaction" layer has to wait for now. What we currently have in the active development branch is a process that adheres as closely to the Baymard's institute checkout UX guideline as possible. They've done their homework so I'm using that as a foundation. Anything that we add on top of that, we need to re-evaluate carefully. I'm not calling for the total abolishment of this feature, I'm just challenging the assumption that it's something that actually essential to all of our users. So in a way I'm playing devil's advocate. We're doing things from scratch, so I'd rather we do it properly and make decisions based on hard data. It's probably not a good idea guessing what the users need, but rather it's probably proper time for us to actually do some user studies and get some hard data to answer these questions:
WPEC should also try to impose as little as possible on the way an e-commerce site behaves and interacts with their customers, and let the admin decides what feature to use, and what not. That's why I tried to start with a good foundation with as little deviation as possible, which is the Baymard UX guideline I mentioned above. Also, they have a great ranking of top 100 UX e-commerce sites: If we indeed do want fancy notification back, IKEA is probably not as good an example as Crate & Barrel (which is number 1 in that ranking): |
|
@garyc40 - devil's advocate ;) I think doing doing a great job building a solid foundation. Wether or not notifications or redirection is better for conversion will largely depending on the type of products the store is selling. For example, I imagine that if purchasing software or a single type of product where you want to convert that sale as quickly as possible I can see that redirection to the cart straight away will provide the best opportunity for converting that sale. However, most of our clients are fashion or homeware brands so I can only talk knowledgeably from that perspective. All our clients who use WP e-Commerce currently use notifications in some form rather than redirection to cart when purchasing a product. For them, many orders they receive are for multiple products which is achieved mainly through cross promotion of products on product pages - ie this jumper goes well with these trousers, or these cups are part of the same collection as these plates. These customers seem to prefer the browsing experience, like in a physical shop. For these sites conversion often appears to be improved by keeping the user on the product page when adding a product so they can easily browse further related products before checking out without being interrupted. Redirecting straight to the basket lowers the likelihood of people purchasing multiple items. I had a look though some of those top 100 UX e-commerce sites in the link above. 6 of the top 10 all either stay on the product page showing an inline notification on the page, or popup a fancy notification like IKEA or mini basket summary overlay that can be closed, rather than redirecting, which seems to suggest that is it a 50/50 choice that is appropriate for some stores and not others. I'm all for A/B testing and getting the right answer, but if the results are 50/50 what is the decision? For me this is an essential choice when setting up a store that can have a direct impact on sales performance and would consider it is an important part of an commerce system. I'm on the fence with this at the moment. I'd like WPEC core to stay as lean as possible, however this is one of those bits of functionality which feels like we should give all users the option to decide rather than make it available as an add-on. Saying that, maybe it's a good opportunity to try the plugin development route WordPress is taking at the moment, then that leaves us open to combine into core later, or not. Even if developed as a plugin, I feel that if would be nice for WPEC core to include the necessary functions for submitting an add to cart request via AJAX so that developers could easily created add-ons that could implement different notifications without having to duplicate functionality. We probably already have this but maybe some sort of notification class or framework would be more accessible, and could deal with handling the button click event and AJAX etc - not sure how this would best be implemented? PS. Can we rename "Fancy Notifications" to something more information like "Add to basket notifications"? |
|
@garyc40 I need to echo some of @benhuson's comments. The checkout flow is sometimes necessitated by the merchandise being sold. In the case of both clothing and gifts it is often the case that more than half of the checkout are multiple orders for similar items. Some examples can be taken from our sites ... people will buy three different shirts of the same style and size, but with different colors. People will order identical designs and colors with different sizes and personalization. It's not an exaggeration to say that if we force a shopper to go back and forth between the product page and the checkout page 24 times when ordering items for a team we will likely lose a sale. Also, AJAX as part of the shopping and checkout process for us is an important tool to get the performance we need when serving moderate volumes of pages. We are trying to get pages loaded on client browsers in under 2 seconds. We allocate about 1 second for page generation and about 1 second for payload. When generating a full page, WPEC on it's own takes about 300ms to load, leaving the remainder for all of the rest of the work. It's not enough time simply because WPEC is doing a lot work, and it takes time. Below is a typical timing pattern we see for the WPEC product page, a product with only a single variation dimension, on an unloaded( CPU < 10%, MEMORY 75% available) host with a fully populated memcached. Timing for URI: /store/prod-bags/got-yarn-sparkle-gear-microfiber-tote/ Our solution is to cache the generated pages, avoiding the expensive processing on shopper page requests. The dynamic part of the pages, like inventory, shopper information, cart contents, etc, are filled in using AJAX requests. When the user adds to cart the AJAX request checks inventory again and displays a success/failure notice (fancy notification), all without leaving the current page. The AJAX requests can be serviced in much less time than a full page request because they don't need all of the code loaded to run, and in many cases are served out of cache. Because we are serving the bulk of the content out of the html cache, the pages are often usable by the shopper in less than 1 second, and hopefully they are "digesting" the content while the situation specific content is filled in in the background. As you noted, the js needs to be cleaned up, Getting much of the business logic out of the js and into the application appears to be a big gain. Much of the gain is made possible by the new customer meta infrastructure that makes it possible to have a simple AJAX call that gets a customer meta value, including the cart and shipping information. As you make decisions on whether or not AJAX needs to be part of the architecture please consider these performance and scalability issues in the determination. p.s. This is a timing for one of the AJAX transactions that fills in the situational data. Timing for AJAX action: pbci_get_cart |
|
Eeek, possibly if I have time - what's the rough milestone date for this release (if there is one)? @garyc40 Which branch should I be working with when developing this? |
|
Completely agree that it would make sense not to remove anything in a release until there is an existing alternative as a plugin. There is such a big user base that could be using presentational settings in a multitude of different configurations, many of whom may not be developers, so removing something without filling the gap would probably not be a good idea. |
|
Yes. That said I don't accept its not possible to replace a chunk of these with Plugins pretty quick. What would you say are urgent plugins Be? I'm pretty sure there are related products and reviews plugins. The smart thing to do is create a plugin or plugins that cover us for what we can deduce as the really obvious ones. Sent from my iPhone
|
|
I've started playing with splitting out Fancy Notifications as a component so that it could then be split off as a plugin and made compatible with the new Theme engine. I basically added some JS events 'wpscAddToBasket' and 'wpscAddedToBasket' which are triggered when the Add to Basket button is clicked and when a successful response is returned, enabling anything (such as Fancy Notifications) so be triggered. I'll push up something for you to see when I have tidied it up a little - probably as a separate issue. PS. Just occurred to me, terminology-wise should we be using 'cart' or 'basket'? |
|
Hmmm I think cart is probably a more recognized / ubiquitous term. I think we should use that. Any other thoughts? Sent from my iPhone
|
|
@benhuson @danmilward 👍 on using Cart, instead of Basket. |
|
Moving this back to 4.0. I think there seems to be some consensus that we need AJAX and Cart Notifications for 4.0. So let's take our time (we're in no rush) and do it right. |
|
High five! Totally agree with this. Sent from my iPhone
|
|
Also, FWIW - I'm not entirely convinced that we should go the plugin route for these things. If we're going to provide a canonical way of doing these things, it may as well be in core. If plugins/themes want to override these things, we should make that easy. |
|
@JustinSainton I think it makes sense to keep most existing functionality within hook but make it easily unhookable. I think it makes sense to try to modularise some of this functionality though. Here's my first stab at moving all Fancy Notification functionality into a standalone component that could be easily split out if desired: (note, I haven't changed the "basket"/"cart" terminology yet) |
|
Rebased version of Fancy Notification module is submitted as PR #2020 |
|
thanks @benhuson! will review shortly |
|
So i'm weighing in super late in the game, but as I'd classify myself currently more in the end user role than with my developer brain on I think we shouldn't be too hasty to push things into their own plugins. I consider myself to be pretty internet savvy but I hate and often forget to look up a bunch of other plugins that would pair nicely with what I'm doing. Since the world has become infinite options having more plugins for people to try and choose from is almost similar to the fancy notification debate before, going back and forth between the cart and products is in the same annoyance for needing a bunch of plugins/having settings all over the place, you might lose people on WPEC in general. I get the developer side of keeping things lean and separated and only providing limited options versus overload. There is a lot of wisdom and truth to that. At the same time, I think a lot of users want 95% of their ecommerce stuff to be handled by one ecommerce solution out of the box. To me, if we've identified certain functionality and features as really important to our current user base, pushing that out into a separate plugin would not be taken favorably unless we have a nearly painless almost automatic onboarding process for those now separate plugins. |
|
@lizkaraffa I tend to agree. WordPress core hasn't solved plugin dependencies yet - and existing solutions (TGMPA) are clunky. If we can avoid external dependencies, we should. |
|
This is what will be placed in customizer per @JustinSainton
Also on settings page add a button to do these settings in customizer |
|
Nice work @lizkaraffa ... I've been agreeing with you re leaving what people still like about WPEC the hell alone since 2014. Nope make that 2013 ;) |
|
Note: to effectively implement most of the customizer changes we're wanting to implement, we'll want to integrate with the new Selective Refresh functionality. https://make.wordpress.org/core/2016/02/16/selective-refresh-in-the-customizer/ |
…gs for dequeueing CSS. These settings have a bit of an unweildy UI, and as it stands, they can easily be overriden by a theme adding the files to their stack, or by a one-line filter to remove them without overriding them. will do the trick for those that want it. We have also added a filter flag, for those that only want to remove inline styles. In addition, we've changed the wording a bit in the settings now that there are barely any. See #516, #1983.
|
Marking this as done! I expect we'll iterate on this, but closing the books on this now nearly 3 year old ticket feels quite nice :)
|
|
I'm glad we waited three years because this is awesome :) Sent from my iPhone
|
Here is an over view of the old / existing presentation settings.
What do you guys think should be included in WPEC 3.9 and what do you guys think should be taken out and put into a separate Plugin?
@garyc40 and I both feel that if WordPress itself offers a comparable setting for pages or posts we should offer something similar for products. So for instance we should keep the number or products to show per page setting - whereas something like IntenseDebate should be made into a Plugin.
On the flip side there are certain e-Commerce settings that our users love that are very specific to e-Commerce that doing have any corresponding WordPress comparison i.e. product thumbnail settings.
However I've been to WordCamps where people have praised us about our ability to customise the product grid and thumbnail image size - I like this because I might want to use a non e-Commerce themes that doesn't specify these options and I don't want to have to learn CSS in order to use WPEC with my favorite theme...
Im playing devils advocate. Tell us what you think should stay and go into a free customizer Plugin.
I've attached an image showing what it looks like now for reference:
And here is the link to the new theme engine plugin: https://github.com/wp-e-commerce/wpec-theme-engine-v2
It got a whole lot of update love yesterday. Let us know what you think :)
The text was updated successfully, but these errors were encountered: