[Mailman-Developers] The Philosophy of Web Use.

[Brad Knowles]

Ethan quoted Bryan Carbonnell:

>> For me it's nothing specific. It's more philosophical. I am a very
>> minimalist when it comes to the 'net. Plain text e-mail and no
>> scripting or embeded audio/video on web pages.
>
> I can appreciate that philosophy, to some extent. So you always surf
> with JavaScript turned off? How do you turn off embedded media? Why is
> image embedding (I assume you don't turn off *all* images) acceptable
> within your philosophy while other media types are not?

When I browse, I don't turn off GIF, JPEG, or PNG images, although I do
wish I could turn off GIFs (they are/were encumbered by patents and I
don't support any kind of software patent, and are also a security risk). 
Since these things are rendered from within the browser itself, short of
turning off all images, I don't think I have a choice.

But I do browse with multimedia and flash turned off by default, except
for those few sites that I've decided to take a risk on.

> I agree that content should stand on its own legs. However, many
> websites- including mailman's interface - are applications where the
> *interaction* between the user and the content is at least as important
> as the content itself.

One thing that really concerns me is excessive complexity in the user
interface.  As a MacOS X/Safari user, I've found so damn bloody many web
sites that are totally hosed for me, regardless of whether I allow them to
use JavaScript or not.  Virtually every single web page designer I've ever
met has always had Windows/Internet Explorer on the brain, and they don't
care about anything else.  In fact, I honestly believe that many of them
actively work to break their websites on all other types of browsers and
platforms, just so that they can force you to use Windows and Internet
Explorer.

Being sensitive to this sort of thing in my own condition, I really don't
want to see us creating a similar situation for someone else.


Now, I know that you're not that kind of person, and you will actively
test your work with MacOS X/Safari, and as many other browser/OS platforms
you can.  But the more complexity that is built into the user interface,
the higher the likelihood is that something will accidentally happen
somewhere to seriously break something for someone else.

In fact, I think it's quite likely that you will even be put into a
situation where a bug in a given platform/browser combination causes you
to completely re-work a lot of your carefully written code, or even
completely abandon the idea of providing certain features that you had
once thought very important.


So, my vote is to set expectations a lot lower, prove to yourself (and us
;-) that you really can implement that restricted set of features on all
specified platform/browser combinations, and then hopefully you will have
produced a set of specifications and a design that is easily adaptable for
future work to expand on those options and provide more of the kinds of
advanced features that you were looking for.

In other words, I'd like to see that you really can walk in all the
different likely shoe and surface combinations, before we let you draft us
into supporting your plans to win the marathon -- especially if we're all
going to be giving you all our scissors, razors, knives, swords, and other
bladed instruments.

> You are, I assume, OK with the server doing whatever sort of dynamic
> foofaraw it likes to generate a given web page; what makes server side
> manipulations inherently superior to client-side manipulations?

Pretty much, yes.  So long as it comes across the wire to my browser as
pretty plain-jane HTML, I don't really care too much what you do on the
back-end.  At least there, you've got a much more restricted set of
platform/server combinations that you have to worry about, and hopefully
Python can help you hide a lot of those complexities.

>                                                                       No
in-page
form
> validation?

I'd rather not, no.  I have yet to see a single place on the Internet that
actually does it right, and across all platform/browser combinations.

More often than not, when typing in a phone number, I'll be unable to
enter the last four digits because they simply set a length limitation on
the field, and didn't bother to check for non-numeric characters.  Or,
when I was living in Belgium, my phone number had to be much longer than
anyone in the US is used to, because it had to include some sort of
indication that I was providing an international phone number, plus my
country code, and all the other local stuff.

>                                     No showing users a rendered preview
of text
> they enter?

I'd rather not, no.  Again, every single website I've ever seen that tries
to show me exactly what my comment is going to look like ends up not
working very well.  When it's not flat-out broken, it's slow and
distracting.

I'd rather focus on the words and not whether I've got the right fiddly
font or the right fiddly kerning, or whatever.

>                   No autocomplete in any text element?

No, my browser is annoying enough when it tries to do autocomplete, and it
almost always fails to autocomplete what I'm trying to type in the way I
would want it to.

>                                                                              No
reordering
a
list
> without a zillion little checkboxes/number boxes and ambiguous behaviour
> if the same number is entered twice?

Not really, no.  When I've seen that done in the past, it was almost
always dead-dog slow and far more of an annoyance than any help that it
could possibly have been.


Like that damn bloody stupid "find as you type" crap.  I've learned a few
things about torture over the years.  I'd like to test them all on the guy
who invented that idea, and then maybe see if I can come up with a few
more new concepts in that area that have never previously been explored.

And there's no way I'd let that guy pull a Ken Lay and up and die on me
before I'm done with my experiments.

> What do you do when you have a data structure not well suited to tabular
> display or a list/tree? Just give the user fragments of the content?

I'm not sure that I've got any answers for you, with regards to how you
should resolve this issue.  I'm just telling you the sorts of things I
have had experience with in the past, and which I would be very annoyed to
ever have to encounter again at any time in the future.

> That's the part that gets me; if Content is sacrosanct, shouldn't
> providing as complete a picture in a given page's content be a goal?

Yes, but it's not physically possible to test with all possible
platform/browser combinations that will exist throughout all of history
(at least, throughout the entire history of the program you're designing),
and it's not physically possible to know, a priori, everything that any
user might ever want to do under any and all possible circumstances.

Some things you can guess at, and provide reasonable failure modes should
you guess wrong.  Other things you can guess at, but the failure modes are
going to be quite a bit more nasty.  And then there are a lot of things
that you would never have guessed in a million years, and you've got to
wonder what complex code is going to do under those circumstances and what
the failure modes will be.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.