I’m reminded of the value of layout each time I stumble upon my basket of remotes for all my electronics. Looking at my AV system remote, it’s everything you need on it and is totally unusable. It has over 100 words, buttons, and symbols on it and is totally unintelligible.
This is exactly what you get when you allow an engineer design your product. No offense intended to all of my engineer friends and coworkers, but user interface design isn’t everyone’s forte. From a delivery perspective it’s exactly what was asked and is coordinated perfectly for somebody who knows what those 100 items are supposed to do and why they are on the remote. And, the critical buttons light up when you press on them. (Once you press a button isn’t when you will need the light), however, the need to light up is fulfilled, albeit at the wrong sequence of operation.
See our products:
Contrast this with the new Google Chromecast with Google TV. It’s a total of 12 buttons. This simple design in combination with the voice technologies built in allows my largely blind father-in-law to play with his favourite films, change to the stations he would like to watch without help. He just has to get the button that’s a different colour than the rest and hold it down to talk his petition.
My day job, when I can tear myself away for venting about poorly designed remotes, is to evangelize the software that my company sells. I work for ElasticPath along with the product I work with is called Elastic Path Commerce Cloud. It’s designed for brands that will need to deploy trade in whatever manner their business needs, and it’s designed so the developers do not have to get an advanced degree in how the platform works. It’s designed simply but powerfully.
Elastic Path Commerce Cloud is designed from the ground up to support fast to market, fast to upgrade, speed to value. The APIs are so straightforward and intuitive, it usually only takes me about 15 minutes to demonstrate the technical teams how they operate and there’s often an audible”AAaahhh!” That’s the beautiful”Ah-Ha” moment. (Note: do not attempt to look up where Aha Moment originated. It’s a rabbit hole of absurd signature suits…)
Conversely, if you must spend 6 weeks to understand how and why the engineers set 100 things on the distant and what magical sequence makes the play button input D. Tuning and what D. Tuning even means, then the cost of owning this product just got a lot more expensive than it ought to be.
Back to eCommerce applications, scope creep and attribute growth can erode an otherwise good design. If you will need a products API to perform 47 unique things, just allow the service do them. In case you must code in each action that could be possible within a service, then you’re restricting what could be done within the API and forcing the developers to learn about and remember how to interact with your API. (47 additional buttons are not required )
By intentionally fending off sophistication, no small accomplishment for a group of engineers, Elastic Path Commerce Cloud is clean and simple to understand. After RESTful API HTTP criteria, there are just 4 ways to interact with any API inside the platform. Using POST, GET, PUT, DELETE for the CRUD operations (in that order). And, anyone familiar with REST would know that.
All APIs can be extended quickly through the API itself to accommodate your most complex of business requirements through simple configurations. That last piece is also deep. No code must make customized microservices or to extend each the present microservices. That means there is little to no specialized debt gathered for the customization. After the platform is updated to include new features and capabilities, they are available without need to replatform from version X to Y. Having been in the business for several decades, replatforming software jobs was a costly, time consuming part of life. No more.
Having been a client before I had been an employee of Elastic Course, I designed my prior company’s execution to take complete advantage of the API customization capabilities of Elastic Path Commerce Cloud. My integration between my product information management (PIM) tool took into account the fact that customizations of the products API could be made FROM the API. Therefore, when a merchant included a new product feature in the PIM, that area was automatically added to the Products API in Elastic Path Commerce Cloud when the information was syncing between the two systems. This little design element saved dozens, if not hundreds of small jobs that would normally had to have been made to add new areas to data stores, APIs on both ends and the transformation between.
The simplicity and power of this design makes it possible for programmers, marketers, and merchants to get their products to the sales channels that they need quickly. The delay between when an opportunity presents itself and the technical staff has implemented on the chance has been almost completely removed.
What’s the Difference Between MACH and Composable Commerce?
If you are in the trade space, whether you are evaluating vendors or simply staying current on the latest and greatest trends, then you have likely heard about Headless Commerce, Composable Commerce and MACH. So what exactly are they and how do they differ?
If you are in the trade space, whether you are evaluating vendors or simply staying current on the latest and greatest trends, then you have likely heard about Headless Commerce, Composable Commerce and MACH. What exactly are they and how do they differ?
Well, firstly, headless trade is more widely known, because it was instituted in 2011 by Elastic Path. Its strategy of decoupling front of presentation layer from the rear end trade engine enables companies to deliver constant customer travels across multiple touch points with no dependence on the rear end slowing you down.
See more :
Since that time, technology has developed more to make more flexibility across these trade journeys. And here in lies, MACH.
Now MACH simply a collection of technologies wrapped up in an acronym, which stands for:
- APIs Cloud
- Headless Commerce
So what exactly does MACH do? Well to understand you will have to comprehend each component separately.
Microservices are independently deployed packed business capabilities that empower flexible development to be set up quickly.
APIs, are applications intermediaries that allow a few applications to speak to each other. So this will be crucial for accelerated development of new stations and time to market for distinct trade experiences.
Cloud Native only means it is only a SaaS model trade service which enables elastic scalability and robust security. This means that you will simply need to deploy the abilities that you need on demand rather than your full full suite simultaneously.
So in conclusion, MACH is just a marketing term that brings all these flexible technology together.
Now Composable Commerce is the approach that brings it all together. This approach equips brands together with the core trade technology, like MACH, assets such as partner integrations and specialist written guides, in addition to complete support to compose and optimize your own distinctive commerce solution. Now, Composable Commerce is characterized by three important tenets.
Business centric solutions, including quick starts for building your solution. And business tools that provide marketing teams the management to make changes and stay competitive.
Modular architecture, which leverages flexible technology like JAMStack to your frontend, MACH to your backend and extensive developer tools.
An open ecosystem, which is made up of library of resources, integration frameworks in addition to complete support and advice for building your whole solution.