Information page URLs

1. Management information
2. Working out loud
3. Collaboration opportunities
4. Activity feeds
5. Activity feed design
6. Information pages
7. Information page URLs ←

Aaron Burden

In an online retail business, operations teams work with business data. To resolve a customer support request, for example, the team typically starts from information about the relevant customer and order, and related products and deliveries. Similarly, other businesses have other operational information to look up, in their own data models.

Information pages provide a company’s internal single source of truth for operational data. The of each of these business objects having an intranet web page comes from it becoming more findable.

Intranet web resources

Despite their previous popularity, worldwide web-like company intranets went out of fashion. This mirrors how walled gardens, such as the big social media platforms, have swallowed much of the public web we use.

In replacing our intranets with business software suites, we have forgotten the architecture of the web, and its design principles. This matters because business information’s document-nature aligns well with the web concept of an information resource, and its identifier:

The most fundamental specification of Web architecture, while one of the simpler, is that of the Universal Resource Identifier, or URI. The principle that anything, absolutely anything, ‘on the Web’ should identified distinctly by an otherwise opaque string of characters (a URI and possibly a fragment identifier) is core to the universality.

You can apply this to business information on an intranet. You just need a stable URL for each resource.

Business object canonical URLs

When you start designing an information page, don’t with its contents; start with how you get there. Give each business object’s information page a canonical URL, such as:

• https://internal.example.com/customer/14159265
• https://internal.example.com/product/BFG9000

In these examples, the URL path ends with an well-known existing identifier. Typically, 14159265 would be a customer number in an existing database or CRM. Similarly, BFG9000 would be a product’s SKU code, or maybe an EAN code.

On the web, you can link to any web page without needing to know who published it, or how. In the examples above, you can link to a customer or product only by knowing the URL. When you can’t simply link to a web page, you probably have a single-page application, a software architecture that breaks the web’s most useful feature: hyperlinks.

Linkable information pages make valuable use cases trivial. When working out loud, team members can unambiguously refer to business objects with links. When you automate those messages, activity feed messages can link a single source of truth, and limit notifications to one line, because they don’t have to duplicate linked information.

Frameworks and app builders

In theory, you shouldn’t have to write any custom code to publish information pages from an existing database or API. Indeed, many products make exactly this possible. Unfortunately, they typically implement bad URL design for you.

In one particularly bad example of implementation details leaking into a public interface, Appsmith adds a UUID to each URL, so instead of:

https://internal.example.com/product/BFG9000

you get something like:

https://internal.example.com/product-318511f658966f4066a159bf?sku=BFG9000

Dealing this requires inconvenient-if-not-unfeasible workarounds, and understanding how and when the generated UUID changes, so you can update your workarounds. Apparently, Appsmith doesn’t support the avant garde use case of knowing a product’s SKU code and wanting to link to its web page. I hope your tooling does better.