Re: vim.org reviewed and classified
- On Mon, Apr 01, 2002 at 05:58:44PM +0100, Thomas Hurst wrote:
> * Ricardo SIGNES (samael-vim@...) wrote:How about a Feature List and two Crash Courses? Beginner and Intermediate.
> > Working from this, I hope we can develop a proposed site tree for
> > vimonline and begin work on fleshing it out.
> > * answ.html - not quite a FAQ, not quite a brief guide
> > Something like this could be useful on the new site: a
> > feature-oriented FAQ. I don't think we have one, really.
> Yes; ultra-to-the-point docs are important to new users, and even long
> time users who never progressed far into the more advanced stuff.
> A terse quickstart explaining the basics of modal editing and the basic
> commands (a, A, i, I, [n]d[x], search and replace, :w and :q) will
> probably go a long way to helping new users get used to vim; after that
> a FAQ like that will be very useful.
The first feature list will be things like, "Why can't I type? It keeps
beeping! WTF IS GOING ON?!"
Intermediate can deal with things like buffers and registered very briefly.
(The Expert Crash Course is, presumably, the user's manual. I suppose
something more concise might be possible.)
> > * binaries.html - links to mirrors for binary distributionsThat would be sweet for the user side. ("Pick your mirror" on the prefs page.)
> > A page like this probably belongs under 'mirroring info' on
> > the downloads page.
> I'd say the mirrors would be best integrated into the download page,
> either with multiple links, a server side script redirecting (maybe
> based on a previously set preference), or something similar.
> > As has been mentioned, the downloads page is a littleYeah, I think we both want that. :)
> > overwhelming.
> It's conveying a lot of information; what the files are, the current
> name, the naming convention, and a description. A lot of that could be
> removed (naming conventions are explained on the ftp anyway) and
> regorganised. A table would probably be a suitable way to organise it.
> This is where nested tables might actually be used in a GOOD way.. :)Shudder! Maybe! :)
> > * chat.html - links to vim IRC channelsYes. Web IRC clients almost always stink. We can just say, "These should be
> > This is a good idea, and can probably go under 'support' as
> > one or two lines of 'where to find good vim irc channels'
> Agreed. I don't think a web IRC client's needed; it's just cruft.
accessible by any IRC client, including web based clients." ...and leave it up
to the user to find a client he likes.
> > * dist.html - a list of vim distribution mirrorsYeah. Again, hide the details unless needed.
> My eyes go funny on that page. Again, I'm sure it can be integrated
> into the download page, with the (mostly) pointless details linked on
> subpages if the user really cares about contact information etc.
> > * docs.html * doc/ * howto/ - an overview of vim documentationAgreed. Crash courses. The User's Guide is nice, but a little hard on the
> > Most of this is already covered by vimonline's documentation
> > pages (vimdoc.sf.net), but that page needs to be brought in
> > line with the look of vimonline. Also, more 'official' HOWTO
> > like documentation should be listed -- things that are longer
> > than tips.
> A documentation links page will probably be useful, but I want to
> emphesise the importance of some friendly documentation on the main
> site; stuff you wouldn't be afraid of pointing a total Vim newbie to.
> Long lists of John Doe's vim howto pages on GeoCities or whatever
> doesn't fit into that category :)
brain. Even some beautification when it's translated to html will help,
especially if its look can be matched (with CSS) to that of the rest of
> > * features.??.html - a brief description of vim in 6kBYeah.
> > The brief description in 6k is a nice running project, and
> > should be maintained as part of vimdoc, probably.
> An About Vim page, linked to from the front page with a 3-4 line
> description of Vim perhaps.
> A features list similar but more complete than the whyvim page on
> vim.sf would probably go well in there; I'd prefer we concentrate on
> demonstrating why vim is a good editor than "Why you should use vim, cos
> we're rabid zealots!!!!11111" which is what most people read into any
> "advocacy" pages :)
> > * hist.html - release dates of vimISO8601 dates are good, but not in that compressed form. Today is 2002-04-01.
> > This 'brief history of vim' is nice, and should be expanded, I
> > think, into more of a narrative history. Bram can write this
> > in his copious spare time. :)
> Yes, preferably without Sven's evil date format :)
> > I'm not sure where we'd put this. Possibly in an extendedMy bad. (And everyone said that phrase was dead.)
> > 'about vim' page that expands on the little "What is Vim?"
> > blurb on the front page.
> <looks up a few lines>
> Stop looking over my shoulder! ;)
> > * index.html - huge file; news; FAQ;And it is!
> It's the classic Too Big For It's Own Good page. The answer to the
> meaning of life could be on there and you'd never find it.
> > * lang.html - a list of syntax files and their maintainers/etcIf it doesn't (it doesn't), it should. It'd be neat-o if vim runtime
> > This page, too, is way out of date. This is rendered obsolete
> > by the scripts archive.
> The scripts archive includes all the syntax files?
distributions could be, at least in part, compiled from the script archive, so
that they were guaranteed to be up-to-date.
IE, put that burden on the maintainer, and let Bram/etc just stamp certain
scripts as "part of canon."
> A list of data like that ripped out of the latest distributions wouldYeah. In the FAQ.
> probably fit well somewhere, maybe under support ("Q: Where do I report a
> bug in highlighting <something>? A: Contact the
> > * macs.html - news for vim for macintoshYup, that's absolutely right.
> There's a lot of information on that page that won't fit in a news page.
> It can always be linked to from the main site anyway; who cares if we
> don't provide copious details about how the Mac stuff is progressing or
> how it's configured by default? If that info is included, it needs to
> be for all platforms.
> > * mail.html - vim mailing listsYeah, I think that the current support page has a decent amount of mailing list
> > This is covered by the 'support' page, although 'support' does
> > not list some of the more obscure lists. Maybe we should have
> > a 'more lists' link to find the non-English language lists,
> > etc.
> A seperate lists page with a way of subscribing easily won't go amiss.
info. A second page with more is needed, though. (Other lists, how to
> http://www.php.net/mailing-lists.php is a nice example; linked to fromOh, that is good! Should be linked from Support, imho.
> the "Getting Help" page.
> > * orga.html - information about the domain vim.org; maintainer, emailYes, and vim.sf does. We just don't need to say how all the email addresses
> > addies, etc
> > Redundant, especially if vim.org will point to vimonline.
> A site should always give some info on who owns and maintains it,Well, remember when CPAN wasn't insane? vimonline could be more like that. It
> whether vim.org points to vim.sf or becomes a site in it's own right.
> Personally I'd prefer it become a site in it's own right, if only
> because vim online is more concentrating on the script/tips database and
> vim.org more on the basics of how to get vim, how to use it, where to
> get support and more information. Keeping the third party script/tips
> stuff on a seperate page will help keep the main site uncluttered and
> less intimidating.
could be a comprehensive reference and resource for vim -- you hit it and it
presents itself as a resource on docs and downloads, but one step in is the
scripts/tips archive, etc. Unifying the site but maintaining an uncluttered
appearance can help create a greater feeling of community, imho.
I agree, though, that we can't let newbies drop into "NEW: VIMIDE 4.0" etc.
> > * pics.html * pics/ - banners, buttons, and screenshotsBram suggested this stay on Sven's page. I still think it might be better on
> > Banners and buttons should go under our 'About Vim' page, or
> > under an 'Advocacy' or 'Community' section. (Community could
> > also contain the IRC info.)
> Sounds reasonable. That will aid crosslinking from support without
> pushing stand-alone but potentially small snippets of information
> outside the main document hierachy.
vimonline, but either way!
> > * quotes.html - quotes about vi and vimYeah, this can easily be dropped from vimonline. (Well, not included.)
> > This is an amusing page, and belongs under 'Advocacy,'
> > 'Community,' or 'About Vim.' Maybe we should create a quotes
> > list, like tips and scripts, so that excellent / amusing
> > quotes can rise to the top.
> Again, sounds like a third party site thing; I do see potential for
> having a random quote picked like a tagline for each page, as a link to
> a list of them.
> > * search.html - search engine interfaceYeah.
> > We have this already; if we need a more extensive one, we can
> > link to google with site:vim.sf.net
> Text gadget in bottom left or top right. :)
> > * setup.html - Sven's minimal vimrcYes.
> > This can be a single tip, or several. It doesn't need its own
> > page on vimonline.
> Basics on customising vim would fit well under the beginner documents
> > * tree.html - a site mapHeh. Well, they're also a guide to building new content. We don't want them
> > This page is incredibly out of date. We don't really need
> > it, but once we decide how to lay out vimonline's expanded
> > content, we'll have one anyway.
> Pfft, site maps are a crutch to poor navigation structures ;)
to be used as a map, but as a blueprint.
> > * users.html - links to pages of other vim usersThis is already covered, anyway. Great sites can be linked.
> > This is covered by user info. Users can list their own links
> > to their pages there.
> Community -> User Sites
> > * press/ - vim in the press and in reviewsYeah, I don't care too much about this -- but presumably someone does.
> > This kind of content should be better organized, and on the
> > vim 'Advocacy' page, or as news items. Or both!
> Now now, let's not turn into Amiga users and wet ourselves whenever our
> favourite editor gets mentioned somewhere ;)
I'll address the map after lunch!
> It's all explained on the web site: http://a-a-p.orgOne thing I could not find there: What does the acronym (?) "A-A-P" mean?
> If you still don't get it, I will have to update the web pages...
It might be "Any Acronym Perceivable", "An A-A-P Project", or something
similar, like TTP="The TTP Project" from the Dilbert comic, but I'd still
like to know. ;-)
Google only brings tons of other AAPs.