In a conventional LMS, you get all of these:

– a learning management platform. Who takes what learning, when, and why.
– a learning UI. This is how your learning is delivered to the user.

But wait, why are these two functions bundled together? This part makes sense from a software construction perspective [we are only writing one piece of software], but for learners, it makes no sense at all. Why would we connect to the system where the learning is managed to receive the learning?

With Bright, we’ve striven from day 1 to decouple management from delivery. Why? Well….

User interaction is a pretty personal thing. Beauty is in the eye of the beholder, and one man’s UI Taj Mahal is another man’s garbage dump.

The problem with typical monolithic LMS software is that it foists its UI conception [or its designer’s conception] onto the learners. If that fits your model, great, if not, too bad.

Even though not everyone gets it, we will always be dedicated to these fundamental notions:

– management and delivery need not happen in the same place.
– UI is a matter of personal taste, and we will always focus on allowing our customers’ complete customizability of their user experience.

Since the world already has 400+ shrink-wrapped ‘all in one’ LMS systems; what would the point be of building #401? Instead, we try to provide something different.

I found this in an email I sent to a prospect, it sums up the philosophy fairly well:

Based on your requirements I thought you could do pretty well with a shrink-wrapped LMS if your requirements don’t change or change much. I think this is where a lot of companies become disenchanted with their LMS platforms, they don’t or can’t be changed as quickly as the encompassing organization is changing.

From my side, at this point I’m not competing on features, I compete on flexibility. I feel like you can always bolt on one missing feature, but you can’t take a fundamentally monolithic or inflexible architecture and fix that in a day, a week, or probably ever.