Whups.

For some reason, it also seems that when I replied, the reply didn't
get sent to the list.  Anyway:


----- Forwarded message from Richard Rauch <rkr@olib.org> -----

Date: Sun, 11 May 2003 17:16:24 -0500
From: Richard Rauch <rkr@olib.org>
To: Jonathan Cline <jcline@d2tech.com>
Subject: Re: NetBSD Forum
In-Reply-To: <DGEBJBKAODPNGOKKADPCIEMJCAAA.jcline@d2tech.com>
User-Agent: Mutt/1.4.1i

On Sun, May 11, 2003 at 01:40:48PM -0700, Jonathan Cline wrote:
> > Re.
> > http://mail-index.netbsd.org/netbsd-advocacy/2003/05/03/0003.html
> >
> > Re. write access from the web: A first-step cheesey way
> > to deal with this
> > is to add a mailto: link.  (Personally, I loathe the
> > editor and mail
> > system in the browsers that I've seen.  But, to each their own.)
> > Certainly there's nothing inherant in the lists to make
> > this not work.
> 
> Using a mailto: link opens up another application.  There's

No it doesn't.  It sends mail to the target.  If you don't care
for how your web-browser implements this standard HTML feature,
you should complain to the author of your web-browser.  This is
the best route, not least because there is only one web-browser
to fix, but an unknown number of web-pages.


> no reason why the entire interface can't be handled in-browser
> (in a form's text area, *not* within the brower's "email app").

Form text areas are a royal pain.  I always hate dealing with those.
Whenever forced to deal with those, I always ask myself, "Why can't
the moron who designed this page understand *existing* tools that
do *exactly* the same thing?  Where's the email address?"  I don't
know the answer to that, so I can't answer it.

You can't use standard things like ispell, or pipes, or your
favorite editing features (be it EMACS or vi or ed).  You're
instead using something that's about on the level of Notepad
or PICO without the menus.  Ghastly for more than 2 lines of
prose.


> There is plenty of technology which has been developed in the
> past 5 years which excells at this.  If you loathe this method,
> then stick to the mailing list.  There's no reason the system
> can't support both interfaces.

Supporting both was what I was suggesting.


> > I'm skeptical that there are that many users who are
> > geeky enough to
> > want their own UNIX (and don't just grab GNU/LINUX
> > because "everyone"
> > is talking about it), yet who are so ungeeky that they don't know
> > how to use email.
> 
> Not "they don't know how" as you state, but "they don't want to",
> or "they prefer a unified interface".  I am one of them.

"They don't want to" -=> Let them do the work of implementing it, then.
No one is stopping them from putting up a web front-end to the list on
their own site.  If it works well, they might be able to get it put on
the official NetBSD site.  After all, you don't need any special tools
oer permission to archive the lists, grab messages from the extant web
interface, or post new messages to the lists.

"Prefer a unified interface" -=> That's easily accomplished without any
work.  Subscribe to the list and use a mail app to read/respond.


> The existence of several other web sites which _duplicate_ the
> effort
> of netbsd.org with the intent of offering a better interface is
> further evidence.  Please see my previous email, point 4.

Hard to do since I had a security advisory recently that resulted in
Mozilla being rebuilt.  The new Mozilla (1.3) won't talk to the NetBSD
web-site.  (I heard other people complain about this a few days before
I got mine rebuilt as collateral damage.  I'll re-CVS and re-built Mozilla
in a couple of days to see if it goes away.)

(The advisory was re. some tool, and rebuilding it got the typical
avalanche of pkgsrc stuff rebuilt, which eventually brought down Mozilla.
I'm only glad that the rebuild didn't stall haflway through.)


> I do *not* have a single workstation or operating system;
> access to the 'net with a browser is the only thing in common.

You could serve the email via POP or IMAP, or maybe even as a shared
filesystem mount.  Or just ssh to your mail server and run
mutt/pine/whatever.  There ARE options beyond the web browser.

Even if you're stuck on using browsers, you can go back to my previous
suggestion: Instead of telling the NetBSD project to doit your way,
YOU do it your way.  You don't need central access to the archives
or any special authority to set up your own browser-based standard.
SHOW everyone how it can actually work, and DO the work, and if it's
good it might just make it in.

If you can't be bothered to do the work when you are the primary
person who wants it, why do you expect someone else to be bothered
to do it?


> There is a very valid movement with "blogging" on the web.
> It's because _people like the ease of use_.

"Blogging" is a very different thing, as far as I've seen.
It's just one person keeping a running journal.  That's one person,
more or less writing one thread.  *Hugely* different than a forum.

I don't know how people prefer to maintain their blogs in general.
I know one person who writes his more or less by hand.  Others use
special programs (whether they are in Java or native code is immaterial).
Perhaps some, perhaps even a majority, use HTML forms to compose their
blogs, but that may speak as much to the infancy of the practice as
to any preferences.  One needs more information to even begin to
treat blogging as evidence, much less before one can decide if the
"evidence" is relavent outside of blogging.


> > Linking: You still have the problem of inobviousness for the email
> > subscriber.  Assuming that *most* (though presumably not
> > all) NetBSD
> > users are a bit geeky, how many are using a web-browser
> > to read mail?
> > Some, maybe.  Others may be using mutt, etc.  And I know
> > that mutt, for
> > one, does not handle HTML.
> 
> Reading and entering text messages within a browser has nothing
> to do with html.  There is no reason a forum should require

Oh, I thought that you were complaining that it was presently inobvious
how to handle hyperlinks.  I'm sorry; never mind.


> I think you miss the mark by assuming your customers are like
> yourself.  Just because you're "geeky" (there's better things

I think you misunderstand me totally.  I have no customers, other than
two highschool girls who I tutor in mathematics, on the side.


> to call it, really) and want to use a text terminal interface
> does not mean your customers do, and their expectations change
> as new technology evolves.
> 
> This "geeky" argument is very similar to all prior arguments
> against adopting with new technology, and I suggest that you
> learn to recognize it for what it is.  Remember emacs vs. Xemacs
> flames?  Or keyboard vs. mouse?  Or how about ed vs. vi?  Or
> how about punch cards vs. teletype?  If you're so "geeky" that
> you prefer legacy interfaces, perhaps you'd like to go back to
> punching chads.

Most of those I do not remember.  The mouse vs. keyboard was one
that I do remember.  I don't think that it is a relavent comparison,
however:

The arguments that raged about such things were always about "what's
best".  "You should do it MY way!"  "I shouldn't have to convert to
YOUR way."  I'm not sure that that's particularly relavent here, though.
As noted above, you are completely free to put your proverbial money
where your mouth is and develop a web-interface that you like.  Your
insistance that others do work to make it work your way is, if anything,
the thing that reminds me of those old religious wars.


> I'll restate my previous point: if the interface increases
> accessibility while allowing backwards compatibility then
> it is a gain.

How is this anything but a tautology?  No one argues against
gain without loss.  Nor, I think, has anyone done so in this
thread.


> > Threading: I think that it's a mixed call there.  I find
> > most threading
> > in forums/discussions on web-messages to be cumbersome,
> > and occasionally
> > incorrect when a thread breaks.  Maybe there's a
> > web-board out there
> > *somewhere* that implements message threading in a way
> > that doesn't suck.
 [...]
> 
> Yes, you're right, theading is difficult, and usually
> is partially linked.  Though even allowing a sort-by-subject
> would be superior to nothing at all.

I think that the worst thing about the existing web archives for
NetBSD lists is that they are sorted OUT of order.  Or, rather,
in the (date) order that the sender claims they were sent.  Systems
with skewed clocks can deliver messages months in the future (this
has happened---probably also into the past though I've never seen
those because I use the web-interface).  And it is *quite* common
for a reply to appear on the previous day from the message that it
is replying to.  I think that this is due to time-zone issues,
more or less.


If you really want threading done right, the best thing is probably
to NOT reinvent the wheel.  I seem to recall that there were
some good threading rules in news readers; so gate the list to a
news spool and read with nn or whatever.  I think that the desire to
re-invent everything is bad, not good.


> In a way, I find it surprising that those developing the
> one of most advanced operating systems on the planet would
> have a web interface which has the functionality of those
> from 1995.  Naturally I'd prefer good developers to work
> on the software which is shipping, instead of creating a
> wiz-bang web site.  I'm only mentioning that appearance of
> any number of netbsd-related services, such as the wiki's,
> the blogger "here's my diary of installing netbsd"-types,
> the latest mention of a netbsd forum site (not the first),
> to point to the need for the management of these services at

Could point to that.  Could point to a "me too" syndrome.  Could
be a NIHS problem.

(Diaries and blogs certainly aren't in the same class.  Those
are personal records of one's thoughts, etc.  They would be
there with or without any given forum.  Those are *about* someone
recording their experiences.  A forum is not a monologue, but is
rather a discussion.)


----- End forwarded message -----

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/