The World Wide Web (www) is simply a network of computers (servers in this case) that hold the pages of information, more or less the Internet. Here’s an interesting article that explains how to identify a webpage or webapp, and I quote:
And now, a brief definition of the web:
To count as being part of the web, your app or page must:
The article is an interesting read about the web, how open web is beneficial and the need for net neutrality. I encourage you to read it.
Extending this definition to immersive technologies, an XR experience that’s linkable and allows any clients to access it (hardware and software agnosticity) is what we call World Wide WebXR. Okay, we made the name up, but the rest of it is true. WebXR is a standard that allows any client device to access XR as a webpage and today, it is supported (at various stages) by all major internet browsers. Here’s a previous note about XR and why you should care.
Over the last couple of years, there have been rapid strides made to mainstream adoption of XR onto standard client devices like:
However these hardware require unique filetypes:
While the end experience remains somewhat similar, the distinction between operating systems and the hardware running OSes are like night and day. It’s like building a house with bricks or wood or concrete or igloo (if you are an eskimo). The end use of a house is the same, but the building materials are different and you cannot use build half a house with bricks and the rest of the house with ice. Once you start with one type of material, you are committed to it. While this sounds trivial at the start, it gets pretty complicated really soon. Try adding a heater to your igloo.
Similarly, the world of technology is neatly divided into different buckets and running common applications across these operating systems is a challenge. And this is where the web steps in; definition mentioned above, but reiterated for effect — Be linkable, and allow any client to access it. In the early days of the internet, the web is where it all started (a brief history ). Early browsers like Mosaic (later Netscape) and Internet Explorer running on 32 kbps modems would take ages just to load simple text web pages. Over time however, internet bandwidth began to increase and these browsers became more capable of handling rich multimedia and soon enough became powerful general purpose software applications.
Ironically, that became their limitation and they were categorised as general purpose software not capable of tapping into the hardware’s powerful capabilities to deliver a superior quality experience to users. This became more pronounced as smartphone revolution took over with application (app) stores opened up to developer communities to solve specific challenges and do them well. The web never opened itself as well as Android or iOS SDKs (Software Development Kits) and got stuck becoming second fiddle to native apps. This went into a spiral where restrictions were imposed on browsers and the capabilities they could harness on the device. These restrictions are in place even today.
However, there is web resurgence today because of its inherent advantages; it is served from the cloud and runs on any device. Businesses and enterprises realise consistently delivering superior quality product experience through native apps is becoming harder and harder as one needs to maintain track of multiple app versions to ensure:
multiple manufacturers’ support,
multiple models’ support,
support various operating systems,
support multiple versions of these operating systems,
multiple client device form factor,
device orientation,
custom OS,
and the list goes on.
In addition, the application should be updated on the end user’s device to access the latest capabilities and features of the software. And this cycle repeats multiple times in a quarter for all apps/software that you have come across. To compensate for the silos, current companies allow you to export your work in different formats compatible with 60–70 operating system versions. That means, every single update/output you make must be exported in all formats, updated in the play/app stores and keep your fingers crossed that your customers have updated their apps. It’s just common sense to get out of this build, release and pray cycle.
The best way to achieve this is to remove the device compatibility on the end-user’s device and make your application device agnostic and running on the cloud to serve all devices and operating systems through a browser. By making your work compatible with any browser, you immediately get all the control necessary for version control without any expectation for the user to download anything on his/her gadget. I’m happy to report that all stakeholders in this ecosystem realise this and they are progressively making browsers more capable and powerful to tap into any hardware’s deeper capabilities. Infact 90% of my work happens on one of the browser’s tabs and the experience is phenomenal.
We don’t have to go through this cycle of native apps followed by cloud migration for XR applications. Stakeholders are cognisant of this fact and they have proactively made significant progress in web-based visualisation of extended reality. All browsers follow the same standard, based on the same set of rules and hence the outputs are consistent independent of the device. And that standard is called WebXR. With this information, the ability to control end-user experience on various client devices rests in the cloud rather than on the local device. Just like any website, extended reality experiences work with the user launching a website, and it loads the most relevant version to the device. The server is making a choice here and sharing consistent user experience. Extended reality applications running on Fabrik, gets access to the device capabilities that’s getting better and better to render complex environments.
There’s a tendency to feel web browsers (and the underlying technologies) maybe good enough for blogs or e-commerce but not to render 3D content (in the form of VR) or perform real-time computations (for AR). While most of these thoughts are unfounded, there’s a kernel of truth since portable devices(smartphones/tablets) have limited computational capabilities. However, XR can run extremely well even with these limited resources and some clever engineering. And with 5G and edge computing, the cloud increasingly does most of the heavy lifting when it comes to computing needs. And this directly implies better visual experiences even with less-powered experiential devices and more importantly, makes HMDs light and portable without any additional bulky gear.
For business owners and product managers, the key is ensuring their product is well received, adopted and used by customers. They are continually trying to delight customers through added features and benefits that reflect customer requirements. To constantly ask users to make upgrades to test out new features or force users to try a different device to maximise the utility of the software doesn’t work (this is relevant for individuals building an app out of their dorm room or large enterprises trying to innovate through digitisation). It is a well known fact that adding another layer of activity (something as simple as an additional click) that consumes cognitive resources for the customer to perform cuts down the adoption rate by a big percentage. Web helps quickly build out a capable app that users will be delighted with while keeping the cognitive load minimal. In closing, deliver over the web, period.