This means that you??™ll build the plain HTML
and CSS nondynamic version of the feature and ensure that it works before enhancing the UI
with the help sidebar using document object model (DOM) scripting. This way you can ensure
that users can get access to help if their browser doesn??™t support JavaScript or their firewall
blocks JavaScript, albeit in a more basic fashion. The bottom line is that the help content
should be accessible in as many cases as possible, instead of not being available unless you
have a modern JavaScript-capable browser.
There??™s a certain amount of forward planning required in providing good progressive
enhancement. Take a leaf from Jeremy Keith??™s book: plan for progressive enhancement from
the start; implement at the end. Although you??™ll build the basic application first and then layer
on the help sidebar as an enhancement, it pays to plan for this right from the start. After you
write progressive enhancements once or twice it becomes habit, but for now outline your plan
of how to implement the feature.
The Master Plan
Planning a progressively enhanced feature is all about setting out the flow of the basic version
of the feature and then identifying at what points your progressive enhancement diverges
from it (see Figure 9-1).
As you can see, the basic and enhanced versions of the feature differ very little in terms
of application flow. Perfect. When you work with progressive enhancement, this is a sign that
your design is good.
Pages:
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268