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?
Some of these are easy, such as the issue of using Safari on a Mac. If the web editor chosen supports Safari, which many of the Java or JavaScript editors do, and CoexEdit is configured to run on the server, it will work as expected with no degradation. If the database is replicated locally and documents are modified, they will be converted appropriately upon opening from the web later, so again, there will be no degradation, except perhaps from a resource which is not available.
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.