Re: Projects

["Aaron D. Turner" <aturner@best.com>]

-----BEGIN PGP SIGNED MESSAGE-----



On Wed, 4 Nov 1998, Micah Yoder wrote:

> I may have missed the orginal message, but anyway...
> 
> Lenz Grimmer wrote:
> > 
> > Hi,
> > 
> > On Tue, 3 Nov 1998, Aaron D. Turner wrote:
> > 
> > > I was beginning to think the same thing.  I think we should list what
> > > projects we are thinking of doing, prioritize them, and start
> > > assigning actual jobs to people to code.
> > 
> > I'd also welcome this idea. Right now, I am pretty clueless, where to
> > start.
> 
> Me too!  I just know we need a DB and a  search engine.

Well then lets work on it. 

First: *WHY* do we need a DB?  What is it's purpose?  What is the goal?
What problems does it solve?  How does it make our lives easier or the
site better?  What can it do for us and the end user?

Just to clarify, I'm not saying we don't need one.  But I do know we can't
design it without knowing what it is for! :-)  When you can answer those
questions you'll be well on your way designing the DB.
 
> > > Some ideas from my head:
> > >
> > > Linux Business Finder (If we get enough companies to list in this, it
> > >       would make VERY compelling content.  This point was especially
> > >       interesting to NaviSite and VAR.)
> > 
> > Do you intend to charge for listing in there? Or will it be a free
> > service? I could contact some vendors here in Germany, when things are
> > rolling.

Free at least initally.  If we end up needing to find some $$$ for the
site we can setup a non-profit org and start charging a yearly fee.

> I think we were planning to not charge, unless we really need money for
> something.  But I bet VAR and/or NaviSite would have some gripes about
> us making money on this, after they're donating so much.  So we probably
> better not think about it for now.  Not to mention tax issues...

As long as we're not profiting from it, I doubt they'd care.  Later on
maybe we'll want a 2nd server or more RAM or something.
 
> > > SQL DB for index of site
> > >       Rating of entries by visitors
> > >       Sorting of indexes (by catagory and then by rating)
> > >       ????
> > 
> > This would require a database layout, including tables and relationships.
> 
> Yep.  I already proposed a schema, but I think it was before you joined
> the list.  Today or tomorrow I'll revise it a bit and re-post it.

Good.  What else can the DB do besides what I have listed?  How would you
impliment it?

> > > User Contribution Forms:
> > >       Add a FAQ (Q&A)
> > >       Ask a question (other visitors will answer)
> > >       Feedback
> > 
> > Maybe we could use part ot the "ask slashdot" code for this?
> 
> I was kind of thinking that.  I'm not sure how complicated it would be
> to integrate.

I don't think that will work.  The basic structure of the Ask Slashdot
format is more like a message board than single entry FAQ's... not to
mention the question submission is via an email address to a human.

I've already written some CGI's that do this for the RHLUFAQ.  Currently
they have the following features:

1) Form with specific fields & checking for "required" fields
2) HTML'zation of http, ftp, and file links
3) Authenticated users can have their entries added to the index
immediately and without admin intervention.  Even supports replacing a
FAQ.
4) Support for multiple mailboxes which can then be used to generate FAQ's
(people can forward from mail lists and newsgroups).
5) "Smart" temp files.  Submissions from users that need to be added to
the index by an admin are correctly formatted, and have the next available
filename pre-assigned.
6) All updates generate an email to the admin.

The features I haven't had time to do yet are:
1) Support deleting of email from mailboxes
2) Web based administrative accept/deny form to add proposed entries to
the FAQ.
3) Support for asking of questions
4) Better authentication method

Right now what I have is pretty solid (ie it works and doesn't seem to
have any bugs), and could pretty easily be adpated to the KB I think.

> > Even though PHP has matured a lot, I'd vote for Perl in combination with
> 
> PHP is cool, but so is Perl.  Either is fine with me.

Perl is fine with me since I don't know PHP. :-)
 
> > DBD/DBI and mod_perl. Did we already decide about the RDBMS? I'd recommend
> > mySQL - it's free for use as a WWW-Backend.
> 
> Question:  Does mySQL support SQL joins?  I think that feature will be
> necessary.  If it does, we're probably set.  If not, it will probably be
> Postgres.

Don't forget the performance hit related to a join.  If we can avoid it,
it would be nice.

> > >       Frames or No Frames?  If Frames, do we bother with a non-frames
> > >               version?
> > 
> > I'd like to recommend not to use frames. It adds additional complexity and
> > is harder to maintain. The most popular sites do not use frames (anymore).
> 
> Absolutely.  Frames bite.  :-)  Aaron disagrees, and they can be good in
> some cases, but I believe ease of use, even on Lynx, is key, and frames
> can be confusing.  If Aaron or anyone else really wants a framed
> version, that can be a separate option from the main screen I guess.
> 
> I've seen several sites switch from framed to non-framed (including
> Netscape's own, and they invented frames!) and they had good reason.

Obviously this is a very subjective preference.  We also have to consider
the advantages of frames and non-frames technically:

1) Frames allow you to "keep" a top level menu for easy site navigation

2) Frames don't force you to re-load common parts of pages (like menus)
over and over again, which is good for slow connections.

2) Frames are poorly supported in Lynx

3) Frames allow you to open a page on another site, but keep the user on
your site.  This allows people to avoid the "back" button and prevents
problems with HTTP redirects which prevent people using the back button.

4) Many people don't like frames (I think this is becuase so many sites
did them in a confusing manner).

5) For the Red Hat Linux User's FAQ, people chose the frames version over
the non-frames by 4:1.  (Probably because the non-frames version sucks in
graphic browsers.)  People also prefered the JavaScript pages over the
non-JavaScript pages by the same margin (I guess people like mouse-overs
:-)

6) ????

What I'm trying to point out is that there are good and bad reasons to do
frames.  Let's just choose the best format for *our* site-- who cares what
everyone else does.

> > >       Optimized for 800x600 screens?
> > 
> > I've no strong opinion about this, but we should keep it simple enough to
> > be viewed even with Lynx.
> 
> HTML is *supposed* to be platform and resolution independent.  Just let
> the browser do the work - don't "optimize" for anything!
>
> I really hate sites (mostly news sites) that assume you have a certain
> resolution.  When I view them at 640X480 (rare now) I usually have to
> scroll to the right to see the whole article.  When I view them at
> 1024X768 everything is crammed into the left side of my screen.  BAD! 
> BAD, ZDNet, BAD!!!!

The problem is that there isn't a good way to do what ZDNet is trying to
do for all resolutions.  Hence they made a compromise, which looks less
than ideal at high-res.  Often, you end up making some kind of a
compromise when you choose the size, quality, and number of colors for
your graphics.  HTML just isn't powerful enough to meet all the hype of
"it looks the same on all platforms/resolutions".

- -ADT


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNkFGrDM3jpXy1kJtAQGBTAQAuj3K9WZ6SHRPJECn5JWWcEa08fRvUnyQ
QriGO6yImI8SB5jHLV5v/05nA1hEsihg84DBQt9wNLrTAlhOBV8bSEOv9qD914AW
CPB2t8eWBeoclSlH9wx9HsRmNpEtejCgTq53s1Q84WtkF1+1YIKLFDq55V8tDfEU
4GC5jIwG3CM=
=GuFR
-----END PGP SIGNATURE-----