We had a growing set of attractive pages and working tools. The awkward part was what happened between them. A homepage could advertise CRM, show a polished screenshot and then send a visitor into an older interface without the right account context.
We spent a great deal of time on this because the design problem and the application problem were becoming the same problem.
The page and the application should agree §
A business owner wants to open relationships, find a customer and continue the work. They shouldn't need to know which repository built the page or which framework generated the next screen.
We explored shared page and surface compilers so mature interface patterns could appear across profiles, application directories, account workspaces and public sites. A pattern includes more than CSS: the right data, actions, navigation and account identity have to arrive together.
Independent sites use shared services §
A retailer may have a custom domain and branded site. A publisher may have a personal subdomain. An organization may have different experiences for customers and staff. Matrix and web-address systems connect those places to the appropriate identity and application records.
The application gallery remains useful for exploring standalone tools. The larger Aurekai work is making them available from the account and public pages where people need them.
The finished experience should feel like one thoughtful product, even if several native systems serve it.
Sources and further reading
References point to original material linked in the essay, not independently invented citations.
There are no separately linked external references in the body of this editorial essay. See the retained publication lineage below.
Related reading
More articles that explore this subject from another angle.