Mon 20 Jan 2020
Branching out: REST, gRPC, and other gory details you can (mostly) ignore
Thu 16 Jan 2020
Branching out: A few terms
Wed 15 Jan 2020
The tree you are busy hugging has new branches
Tue 22 Mar 2005, 02:18 PMTweet
by Ben Langhinrichs
A popular idea these days is the concept of "degrading gracefully". No, this is not related to "aging with attitude" or other aphorisms we forty-somethings use to distract from the sagging and bulging of our approaching, but never arriving, middle age. This is the idea, popularized with web design in general (and CSS in particular), that when people do not have the same specifications, software version, browser type or what have you, that you, the designer, intended, their experience should be less like falling off a cliff and more like gliding down a slope. If I happen to have Internet Explorer, and the site was designed for Firefox, I may not have every bell and whistle, but my experience should still be smooth, and I should not necessarily be aware of the loss of function. A good description of this, and how it extends to other parts of the IT experience, is written up on Flashes of Panic under the title Degrading gracefully.
I have been dealing with this concept, if not the particular terminology, for years when dealing with Notes rich text, but in CoexEdit, it is of even more paramount importance. What happens when a client edits the rich text from Safari on a Mac? What happens when the database is replicated locally and edited by someone who does not have CoexEdit, then replicated back? What happens when the company decides to standardize on an ActiveX editor, and a user accesses with a browser on Linux?
But what if the rich text editor does not support Safari, or works with Internet Explorer but not with Firefox? Worse yet, what if most features of a rich text editor work with all three browsers, but optional plug-ins into an editor such as TinyMCE may vary, so some work in Internet Explorer, others work in Firefox, and still others work in Safari? In the former case, we may be best off denying access or putting up a browser page which warns the user that editing with that editor is not allowed, but that is hardly degrading nicely. In the latter case, we may need to hide certain browser buttons to ensure that the user is not hit over the head with the fact that they can't use a particular widget.
Now, most of this would not have to be my problem, since the application designer is really responsible for such issues, but I am enough of a realist to know that a fair number of people are just going to take whatever I put in my samples and slap it into their databases, so I would really like to do it right. I am starting to think that I should pick one good, easy, cross platform web editor to be the "fallback", so that if the company picks an ActiveX editor and then runs from a browser that doesn't support ActiveX, it will just "degrade gracefully" to the "fallback editor". That may be a case of doing what the customer wants rather than what they ask for, but since I am only talking about doing it with samples, I guess I have a bit of leeway.
Copyright © 2005 Genii Software Ltd.
What has been said: