Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Keith Donnell 82 posts 187 karma points
    May 04, 2015 @ 17:16
    Keith Donnell
    0

    Suggestions for future Merchello releases

    I'm not sure what's planned for future releases, but these are the biggest wishlist items.

    1. Cleaner sales/invoice dashboard.  The invoice page looks sloppy, style-wise (at least with the Stripe provider - not sure if this is provider-dependent?)
    2. Product "extended data".  In the spirit of umbraco, it would be ideal if each product could have a "doc type", and we could assign additional descriptions, etc to each product.  Currently, descriptions are stored on the Umbraco page, so if we have another page displaying product description (for example), we need to seek out the appropriate umbraco page (instead of just being able to pull the data from the product).  This would definitely help keep things DRY.
    3. API cleanup.  There are a lot of cases, especially in the checkout process, where things aren't quite as intuitive as they should be.  For example, it took me a while to figure out how to get the shipping address from an IBasket, so I can display it back to the user on a "review your order" page.  The whole Basket/Cart vs Invoice vs Order is still tough to wrap my head around.
    4. API performance.  Bulk inserts/updates, especially when dealing with large amounts of variants, takes a LONG time.  Feel free to check my fork for some examples of how I was able to drastically improve performance.
    5. Product Variants.  Currently, when you create product option choices, a variant is created for each combination.  This is probably fine for most people, however my first Merchello project is a perfect example of an exception to the rule.  The products come in different materials, and each material is available in different colors (with only a small amount of overlap).  This can generate well over 100 variants for us, when only 15 of them are actually available for purchase, which means a LOT of noise data.  A possibility would be to have some sort of flag "AutoGenerateVariants" that defaults to true, but that I would be able to set to false and manually create my variants.
    6. Samples.  The hardest thing for me getting this project up and running was finding accurate, up-to-date code samples, especially when it came to the checkout process.   I'm sorry if there's been work done in this area, but when I started working on this, samples were severely lacking.  Even the samples I did find were using the default "Cash" provider (which I can only assume nobody at all uses for eCommerce).

     

  • DFBerry 53 posts 130 karma points
    May 04, 2015 @ 17:23
    DFBerry
    0

    Hi Keith,

    Thank you for taking the time to write out the issues in detail. This is a huge help.

    -Dina

     

  • Keith Donnell 82 posts 187 karma points
    May 05, 2015 @ 22:17
    Keith Donnell
    0

    Another big one:

    7.  Invoice noise.  I'm sure there's a reason for storing multiple invoices per order (or per basket), but the system keeps a lot of "junk" invoices, most notably on payment failures.  I'm not sure of the best solution to remedy this, but I think this goes along with Basket/Order/Invoice confusion.  I am currently using InvoiceNumber when sending customers their "order number", as that's what the dashboard uses as an entrypoint, which seems backwards to me.

  • Biagio Paruolo 1618 posts 1910 karma points c-trib
    May 18, 2015 @ 23:15
    Biagio Paruolo
    0

    +1

Please Sign in or register to post replies

Write your reply to:

Draft