Web in 2024

From W3C Wiki

[This document is a work in progress]

Introduction

This document, written in 2014, takes a look into the future. It analysis how the Web may look like in 10 years from now: in 2024. The focus is not the Web in general, but mostly focusses on user-facing technologies such as browsers, and how people interact with the Web (from a W3C perspective, roughly the things that fall under the W3C Interaction domain).

The document starts with a 10.000 feet view on the future of Web technologies. This includes the relation to the broader Web area, new usage scenarios and new business opportunities. The rest of the document dives into specific aspects of interaction technology, from the protocol layer to the use of all human languages on the Web.

Predictions into the future can try to describe groundbreaking breakthroughs, like "In 10 years the Web will allow us to travel through wormholes". This document does not contain such predictions. It rather focuses on the evolution of current technologies, taking existing tendencies into account.

10.000 feet view

In this section we take a look into technology trends from three high-level perspectives: technology tendencies in various areas, new usage scenarios, and new business opportunities.

Technology tendencies in relation to interaction: technologies that shape the Web's user interface

The below list of technologies are not interaction technologies. Nevertheless we discuss them here since a general trend is convergence of technologies. As an example, 10 years ago, for creating multimedia content, one needed several technologies. Now this works natively in the browser. This trend will continue in the future and will enable more and more applications, using the Open Web Platform.

  • Internet of Things and Web of Things. We will see interfaces to access all kinds of physical devices from the Web, retrieve information about their state and interact with them.
  • Web and TV. Browser technologies will become an integral part of every screen. The difference between a TV and tablet will be just size. This has an influence on requirements for some interaction technologies, e.g. adaptation of styling.
  • Devices. More and more types of devices will evolve. Some of these will need new interfaces for interaction and to retrieve information. With the development related to Web of things, the difference between a device and a physical object will dissapear.
  • Privacy/security. Users will be able to take their privacy and security settings with them, no matter which device are using in which settings.
  • Social media. A growing need to port social identifies on the Web will lead to interfaces for retrieving and setting social media information.
  • Digital Publishing. The growing interest in high quality layout will influence the development of styling, taking requirements from many layout communities around the world into account. More and more users will be able to interact with content, e.g. editing in the browser, annotating, sharing across devices and between users.
  • Automotive. Cars will be just another device, closely connected to other physical objects, humans and other devices. Interfaces will provide information about the state of a car and allow new interactions, e.g. ask the car via the browser on how much fuel is available.
  • Web Applications versus operation systems versus Web pages. The difference between Web content creation and Web application creation will blur. The Open Web Platform will be the underlying operating system for both tasks.
  • Web of Data. More and more users will want to combine (text) content creation and data analysis. For this purpose they need interfaces to deal with data sources without the need to become an expert in data analysis programming.
  • New APIs for new interactions. The trends described above will lead to new interactions between data, devices, physical objects and human beings. Hence, besides the forehand mentioned convergence, another high level trend is robustness and hiding of technologies. Many details of the Open Web Platform will be hidden in the tunnels of disney land. The end user will just enjoy the magic.

New usage scenarios and users

20 years ago content creation meant: people write HTML pages. 15 years ago it meant: people use CMS, later blogs. Today it means to create content on the social Web: you don’t need to know details about technologies but you can create more and more complex experiences, including multimedia, interaction with others etc.

In 10 years, creating content will mean to work with interfaces to data and physical objects. As an example, already now some people say: publication means Provide a Good API for Books.

The value of putting content on the Web will not be the content itself, but the way users are able to interact with the content, using external information sources both from data and physical object. The role of interaction technologies will be to hide complexity in such interactions. A Web content creator also in 10 years will not want to know details about data or services to interact with it. For example, she will want to be able to say "integrate the information about the current population of Berlin into my content, update it each time a reader consumes it".

New business and job opportunities

The forehand described new usage scenarios will mean: making money with Web content will highly rely on knowing how to use interaction technologies.

The amount of the content itself is growing rapidly. So its value is decreasing. The money is made by providing the content in high quality layout and in an interactive, dynamic manner.

Today there is Web content creators and Web site developers. The content creators will learn how to work with content as an API, how to use high quality styling etc. Their knowledge will turn them into data and content specialist. The Web site developer will learn how to set the mechanics for content creators, depending no the project needs. The job profile will change to be a data/content integrator.

Specific technology areas

Protocol and network layer

Web addresses will have become truely multilingual. This is due to wide deployment of IDN (Internationalized Domain Names) and URLs that allow for using nearly arbitrary Unicode characters.

IPv6 and HTTP2 will be deployed widely. IPv6 will especially help to foster the Web of Things.

The HTTP2 feature of stream ids will have an impact on connection performance and on Web technologies. Header compression will have an impact on network performance but will not influence Web technologies.

Markup vocabularies

The core markup vocabularies of today are HTML, and SVG. It is likely that no new vocabulary will emerge. It will become much easier to mix the vocabularies freely. CSS will continue to play an essential role to turn bare markup into useable Web pages and Web applications; JavaScript will likewise continue to play an essential role to provide responsiveness, to genersate markup, and to prototype new features or add polyfil support for features not yet filly implemented.

We hope that support for MathML will improve, as scientific, engineering, educational and general technical publishing will otherwise continue to use proprietary formats.

HTML will continue to be the foundational layer. New work for HTML will start only in selected areas like frames, to support scenarios in digital marketing, editing, responsive design and performance.

In editing environments, ideally users will not be interested in the distinction between markup vocabularies or JavaScript, CSS etc. All of these technology bits will, we hope, just appear as one seamless web framework to them.

(Document?) Object model

The DOM will be extended to support JQuery-like features natively. The DOM will still be called Document object model, but its role will be fundamentally different for representing documents versus being the backbone of applications.

Applications will have a uniform interface to data streams, on top of fine-grained access to specific data sources. Documents will have a better declarative expressivity for document designers, relying on progress in styling (see below).

For the application related view on the DOM, the tendency of encapsulation will continue. This can be seen already today looking at discussions around Web Components.

JavaScript in general

JavaScript engines will continue to gain in performance. It will become possible to build a pure JavaScript browser from scratch. Obtaining good multithreaded performance will either be achieved by 2024, or will become a tiresome bottleneck.

Relying on the application centric view of the DOM (see above), single-page apps (SPAs) will emerge.

As an important technical aspect of single-page apps, service workers will have become loadable prior to any content. This will ease the creation of tailored but interoperable packaging solutions. This change may in turn produce a move away from the document as a manifest of all other linked resources.

Masses of JSON data will become available. The data can be processed via dedicated APIs. Some of these are available natively, see the section on devices, small data and big data below.

Styling

Styling will continue to evolve as it did in the past 10 years. More properties will get added to address the increasing set of use cases, e.g. screen rotation animation. A lot of requirements will come from local user communities, see the section on use of all languages below.

High quality layout will be required on all devices. Hence, CSS pagination will also get tailored towards and deployed for automotive and tablet use cases.

To help the user dealing with the growing possibilities in CSS, work on CSS user interfaces will pick up significantly within 3 years, for wide deployment within 10 years. This is closely related to the finalization of Web components.

Application support

Installation and offline support are key elements in competing with the Native platform and we expect significant steps forward in the upcoming years.

Service Workers introduces a significant step forward and changing game in this area since it provides several capabilities:

  • Background execution of JS, ran independently of the main application
  • Caching API, which runs on top of the HTTP cache itself
  • Filtering of each fetch request coming from the Web application
  • Define the application lifecycle (install, activate, reload, update, etc.)

Installation requires some extra information, such as icon, browser mode, etc. The work on the manifest specification is a starting point in this direction but we expect many open issues to continue to get addressed in future versions, such as easy an permission model.

Interfaces to work with devices, small data and big data

A growing amount of data will be available on the Web. Many users will not care whether the syntax is based on a certain technology stack (XML, RDF, Microdata, ...). They will just want to interact with the data in a common way. Annotation of arbitrary content types (text, multimedia, various sources) will be one common operation.

This tendency of convergence will also be seen with regards to data producers: Web server, devices, physical objects, abstract representations of things on the Web. Common HTTP-based operations will be available for all these data producers (who may also be consumers). The user agent provides interfaces to connect to all of these.

The interfaces will not only hide the complexity of data formats and data producers / consumers. One can also embed interface calls for interaction with data into content. In this way, the difference between content and data will blur. The call to data in some cases can be language agnostic. E.g. when statistics or other highly structured data sources are dynamically embedded in content, the API call will allow to create a description in the language of the user.

Multilingual Data Analytics

Dealing with big, multilingual (un)structured data sources will be made easier for the Web developer by hiding the complexitiy of big data anlytics in interface calls. But there is no free beer: high quality analytics or machine translation (to cross the language barrier) will always cost money. Nevertheless, common interfaces will ease the use of these technologies without the need to become a big multilingual data technologists.

Off-the-shelf APIs for dealing with big, heterogenous and multilingual data sources will also help the wide spread adoption of the linked data cloud. The common interfaces will help both data and application interoperabilty.

Use of all languages on the Web

The creation of high quality layout, taking local layout traditions into account, will have beomce a common requirement. Everybody now understands that responding to this requirement is a prerequisite for moving the publishing industry to the Web.

Knowledge about local layout requirements will still not be sufficent. For some layout traditions like Japan, detailed knowledge is already available now and layout engines on the Web will implement many aspects. For other traditions, the situation will be better than today but not perfect. A continous callenge will be proper typographic support for users of Arabic script based languages, ranging from North Africa to South Asia to Western China.

Role of testing

Making the Web interoperable requires 3 pillars: developing the software, develop the specifications, and testing the software with regards to the specifications. The Test the Web Forward effort is aimed at addressing the third pillar and provide a test suite for all user agents to use in order to help compliance with the specifications. We expect that all implementations will effectively run the test suite on a regular basis within the upcoming years, thus making writing tests as important as writing specifications.

Conclusion (tbd)

to be written after the rest is finalized.

  • What tasks are needed from the Web community?
  • What kind of work?
  • General: Interaction technologies becoming invisible