Beyond Context-Aware: From Screen Size to Visitor Tasks

The idea in one sentence: fitting a page to a phone and fitting its next step to a person's task are different design problems—and both matter.

This paper explains the difference without requiring a background in web development. The later sections cover implementation and testing for readers planning a build.

What “context-aware” means

Context is relevant information about a situation. A website might use the available screen width to arrange its layout, a selected language to display the right text, or business hours to explain when someone can answer a call.

Responsive design usually refers to a layout that works across screen sizes. It helps the same information remain usable on a phone, tablet or desktop.

Context can also include a task. The boundary between “context-aware” and “visitor-aware” is not a universally agreed dividing line. Our purpose is to focus attention on the person's need—not to claim that earlier design ignored it.

Accessibility should be part of the ordinary site. Do not wait to detect a disability or assistive technology before making content accessible. Likewise, location and device information do not establish a language preference or a person's identity.

What a task-aware response adds

Imagine a visitor on a training website. A responsive layout makes the course cards fit their phone. A task choice—“For myself” or “For a team”—can make the relevant course information appear first.

The two changes answer different questions:

The second question does not require the site to know who the person is. It can use the answer they supplied for the current task.

By contrast, inference is an interpretation: a system might guess that opening several pricing pages means someone is comparing options. The observation may be correct while the interpretation is wrong. Treat that uncertainty as a design constraint, not a reason to collect everything.

Memory is another separate question. A current-page choice does not need a record across visits. If remembering a task would help, explain what will be kept and let the person choose whether to use it.

Does this require a new website architecture?

Not always. Architecture means how the parts of a system fit together. A small choice-and-order rule may fit into your existing website. A larger service that remembers tasks and shares approved summaries with staff may need additional components and controls.

A CMS, or content management system, is the software a team uses to edit and publish content. A plugin adds a capability to existing software. Neither label tells you whether an implementation will serve a particular task well.

Before replacing tools, ask whether the current system can support:

• Clear, consistently maintained content.
• The specific input and change you want.
• An explanation and a way to undo the change.
• A complete experience when the enhancement is unavailable.
• Appropriate controls over any data involved.

More plugins do not automatically create a coherent experience. But a complete rebuild is not automatically better either. Choose based on what the task needs and what your team can maintain.

The useful test is not whether the website collapses when its “intelligence” disappears. The test is whether the ordinary page remains useful and the proposed change improves a real task.

Questions to ask about your own site

You can answer these without knowing which framework the site uses:

1. Can a first-time visitor tell what the site offers and who it is for?
2. Can someone with a specific task reach it without reading unrelated material?
3. If we ask a question, do we explain why and what the answer changes?
4. Can a person correct a choice or ignore the suggestion?
5. Does every path remain usable on a phone and with a keyboard?
6. Can we show evidence that the proposed change helps—not just that it moves content?

If the first two answers are no, improve the ordinary content and navigation before adding adaptation. This is a design review, not a score or certification.

A small implementation, explained

A developer might build the training example using these parts:

• Input: the option the visitor selected.
• Rule: a decision such as “team selected → team card first.”
• Component: a reusable piece of interface, such as the course card.
• Composition: the selection or order of those components.
• Fallback: the complete ordinary order when the input is missing or invalid.

The builder guide shows that sequence and the equivalent code. It does not store a visitor profile or call a language model.

Progressive enhancement means delivering the useful basic experience first, then adding capabilities when they are available. In this example, the course information is readable before the script adds the choice control. A script failure must not turn the page into an empty shell or leave buttons that cannot work.

Optional detail: test the rules and the resulting pages

Reusable components make testing more manageable, but correct components do not guarantee a good assembled page. A heading can be valid by itself and still appear in the wrong place when a rule changes the order.

Use a small set of checks tied to actual risks:

1. Default: with no choice, all essential facts and actions are available.
2. Each allowed choice: the rule produces the intended result without changing prices or other facts unexpectedly.
3. Correction: changing or clearing the choice works immediately.
4. Interaction: focus, entered text and the visitor's place are preserved.
5. Failure: missing data, an unknown value or an unavailable enhancement has a useful outcome.
6. Comprehension: a reader can explain what changed and why it helps.

For a larger system, limit the combinations it can produce and record which rule produced a state. A decision trace is a concise explanation of that decision—not a license to retain a complete personal history. Log only what is necessary and appropriate.

Have content, design and development owners review the actual states together. Automated checks support this review; they do not replace it.

Common implementation concerns

Will the page become slower?

It can, if you add unnecessary scripts, requests or processing. One option is to generate the ordinary HTML before a visit and deliver it as static files. A content delivery network (CDN) stores copies near visitors. Neither technique guarantees a fast page; measure the actual build, including the enhancement.

What happens on the first visit?

Show the ordinary page. There is no minimum number of clicks after which the site suddenly knows someone's intentions. Ask an understandable question if the answer would improve the task.

What happens when something fails?

Keep the basic information and actions working. Test the real failure path rather than assuming that having a static version somewhere is sufficient.

Can people and search engines still find the content?

Keep important information at stable, reachable URLs with clear headings and links. Do not make essential content depend on a personal profile or a hidden interaction. SEO, or search engine optimization, concerns how content can be found and understood by search services; adaptation is not an automatic ranking advantage.

What will it cost?

A small local rule and a model-backed assistant have different costs. Include implementation, content maintenance, testing, hosting and ongoing review. If a model is involved, set usage limits and an ordinary alternative before enabling it. Cost does not automatically track business value.

What to do next

Check whether a small change fits your website. If it does, write a first-build brief. Start with a task you can describe and a result you can observe.