Ansuz

« Spywar | Home | The fourth help »

Visible ontologies

Web services expose their underlying data models throughout their interfaces, much more so than we might expect, and they're all different. Two services that seem to be direct competitors will have importantly different ontologies of the data, and this affects all aspects of how they feel to users.

I noticed this effect when I moved from Shopify to BigCommerce, and again when I moved from TradingView to Stockcharts dot com. These are pairs of what might be plug-in replacements for each other... but really, they're not.

In an online storefront like Shopify or BigCommerce, there's an important issue of what counts as a product and what counts as options to a product. Like a men's L and XL shirt, otherwise identical - are those one product with an option, or two products? Are the assembled and do-it-yourself versions of my Gracious Host module two really different products, or two options for how to buy one product?

From a business perspective I think I can say that the Gracious Host is one product with two options for buying it, because that is how customers treat it: they decide they want a Gracious Host, version unspecified, and then they set out to get it with as low a sticker price as possible, which turns out to be the do-it-yourself one because I don't offer a "PCB and panel" version. But from a database design perspective, that may not be the most advantageous way to code the data.

Both Shopify and BigCommerce let the shopkeeper decide where to draw this line, but they do it in different ways. Shopify has "products" which can have "variants." BigCommerce uses a separate concept of an "option"; "options" are grouped into "option sets" and then those can be applied to "products." The ER diagram ends up looking quite different, but there is no ER diagram in any of the documentation and these systems try hard to protect their users from needing to know what one of those is.

TradingView and Stockcharts dot com are both online services for viewing financial charts and they seem to serve basically the same market, interchangeably. I switched from TradingView to Stockcharts dot com because I was disgusted by TradingView's social media presence; I was still hoping to get basically the same service from Stockcharts dot com. But here again there's an important difference in data model.

In TradingView, you have a "chart layout" and a list of stocks you're interested in. You pick a chart layout and then you can choose to pour one stock or another into that layout. Changes to style settings are made on the layout and remain, whichever stock you look at. You can also make "annotations" which stay with the stock. The line on what's an annotation (stored with the stock) and what's a style change (stored with the layout) is unclear.

In Stockcharts dot com, the first-class entities are "charts." A chart carries all the style settings and annotations; it usually also includes data from one stock, though other possibilities exist. Changes to a chart are stored with that one chart. If you want to use the same style for a different chart to look at a different stock, there's a process for copying settings from one to another, but it's laborious; more so if you want to change all your charts. On the other hand, making an exceptional layout just for one stock is easy.

Again, we are dealing with a different ER diagram between the two services, but neither of them ever shows you the ER diagram, expects you to know how to read one, nor explains the model as such in any other way. I think on balance I like the Stockcharts dot com data model better; having the style settings, and especially details like how much time to cover, go with the "chart" and therefore the stock symbol instead of being a separate entity, seems to go better with how I want to use the service. I'm less pleased with "dot com"'s user interface - especially its tendency to change layout and re-center the display at odd times. But that's not really a matter of database model.

What I think is interesting here is that I'm sure neither service made careful design decisions on this point. Nobody sat down when they were first writing the code, wrote out both the "style goes with 'chart' and therefore with symbol" and "style is a free-floating entity into which a symbol can be poured" models, and thought about the advantages and disadvantages of each one. I'm sure that instead whoever was building the system had one model in their minds right from the start - a model so obviously correct (to them) that it never occurred to them they were even making a decision to use it as opposed to some other. They didn't perceive the data model as something that they had chosen, but rather as just the naturally-occurring shape of the problem. The one true model got baked into the entire system at a low level, and to this day it remains as a constant background to the entire service, even though they never actually state or describe it. It is expected to be as obvious to users as it was to that first designer. But someone else building basically the same service for a different company, thought it equally obvious that the problem had a very different shape.

Near the end of my time with BigCommerce they started talking about something that they called the "the V3 catalog experience." I never found out what that actually was. Maybe it was explained in a "webinar" I didn't watch - BigCommerce ran a lot of those. But from the offhand and indirect references to it that I did see, my guess is that it was an attempt to change the shopkeepers' "experience" of the product database to better reflect how most shopkeepers think about products and variants - essentially, to work more like Shopify. The longstanding BigCommerce data model of "option sets" as free-floating entities standing between options and products, wasn't working well and people didn't understand it. Someone in the dim past had thought that was the obviously correct way to organize options on products, but it was less obvious to shopkeepers, so they wanted to change it.

But they kept calling it an "experience" instead of a data model, and they never were explicit about what was really changing, and I think that was because they weren't really changing the underlying data model. They wanted to keep "option sets," or probably more correctly, they couldn't even imagine doing anything other than keeping "option sets," because they saw the data model as a given, part of the external universe in which they operated rather than something they had chosen. BigCommerce thought the issue was with shopkeepers' "experience" of not understanding an objective reality in which option sets were a thing.

0 comments