|
|
|
•One way to look at the markup used to deliver
today’s web application functionality is as a black box.
|
|
•We have existing technologies like HTML, CSS,
JS that web app authors use to deliver functionality on the client-side, and
control over the generation and delivery of that markup rests with the web
app author’s servlet, portlet, etc.
|
|
•But let’s think for a bit about the growth of
requirements over the last 15 or so years.
|
|
•More complex layout and higher precision
rendition of text, images, and user interaction controls. But not just requirements on static content
have increased.
|
|
•Users expect more dynamic behaviors like the
ability to calculate the total cost of that insurance policy I’m trying to
buy ore renew online, and to adjust values as I select and change types and
amounts of coverage.
|
|
•Users expect to be told when they’ve made a
datatype error, such as a wrong date, a non-numeric value or a missed credit
card digit.
|
|
•They also expect the user experience to be
unencumbered by non-applicable steps of the overall process flow, like not
having to step through the ‘senior citizen’ or ‘Minor’ sections of the web
app if the given birthdate suggests that the user is not in those categories.
|
|
•We further expect to be able to seamlessly
integrate data available from the web into the user experience, such as
selecting from a list of doctors provided by a query made after some data has
been provided by the user, such as desired appointment date/time, region,
required specialization, etc.
|
|
•Ad despite all the dynamism, we need all this
content to be accessible to persons with disabilities. It’s philosophically interesting that this
particular issue so sharpens our focus on being able to determine the intent
of markup.
|
|
•So when you take this growth of requirements
into account and you look inside the box based on the current state of
the art…
|
