vim.org website redesign/update

[Leonard Ehrenfried]

Dear list,

I really hope I don't hurt anyones's feeling by saying that the current vim.org website looks a little bit dated. I also happen to think that it doesn't do a very good job of explaining what vim is and how to install it. Lastly, it doesn't give you any hints on how to effectively manage your plugins with tools like pathogen and/or vundle.

I would like to change this and I was wondering if there is any sort of appetite for updating the website? I would volunteer to implement/lead this effort.

In terms of inspiration I would look at the Linux kernel's website[0]. In my opinion it scores nicely in the areas of simplicity and usability.

How can you know if I'm competent and trustworthy?

I have been a web developer for the last 5 years and I have quite an active Github profile[1] I blog at http://leonard.io. I'm also maintaining a vim syntax file[2]. Maybe this will give you an indication of the quality of my work.

Before I get ahead of myself in terms of planning I would like to gauge the community's feelings towards an undertaking like this.

Thanks a lot for listening,
Leonard

[0] https://kernel.org
[1] https://github.com/lenniboy
[2] https://code.google.com/p/vim/source/browse/runtime/syntax/sshdconfig.vim

[tux.]

Leonard Ehrenfried schrob am Mittwoch, 6. November 2013 um 22:54 Zeit:

> I also happen to
> think that it doesn't do a very good job of explaining what vim is
> and how to install it.

Sorry, but that's wrong IMO. :)

[Josh]

On Nov 6, 2013, at 3:54 PM, Leonard Ehrenfried <leonard.e...@gmail.com> wrote:

Dear list,

I really hope I don't hurt anyones's feeling by saying that the current vim.org website looks a little bit dated. I also happen to think that it doesn't do a very good job of explaining what vim is and how to install it. Lastly, it doesn't give you any hints on how to effectively manage your plugins with tools like pathogen and/or bundle.

Sounds good. Note that there’s a lot of info on vim in other places, like the vim wiki: http://vim.wikia.com/wiki/Vim_Tips_Wiki , or vim’s documentation on source forge: http://vimdoc.sourceforge.net/ , or questions on stackoverflow: http://stackoverflow.com/questions/tagged/vim .

Also, it’d be cool to integrate with github and bitbucket for plugins, instead of hosting them ourselves. We could still track releases (even in the same way github does: https://github.com/blog/1547-release-your-software ).  Also we could track votes/github stars/whatever bitbucket does on the site.  Most if not all of this (plugin) stuff could be done through APIs.

I would like to change this and I was wondering if there is any sort of appetite for updating the website? I would volunteer to implement/lead this effort.

In terms of inspiration I would look at the Linux kernel's website[0]. In my opinion it scores nicely in the areas of simplicity and usability.

How can you know if I'm competent and trustworthy?

I have been a web developer for the last 5 years and I have quite an active Github profile[1] I blog at http://leonard.io. I'm also maintaining a vim syntax file[2]. Maybe this will give you an indication of the quality of my work.

Before I get ahead of myself in terms of planning I would like to gauge the community's feelings towards an undertaking like this.

I’m 100% with you on this. I’d say we need to:

- Get buy in, are the original developers on board/ok with this? How about Bram?

- Decide on tech. I don’t care too much what we use, but I’d suggest persona (https://login.persona.org/) for accounts/login.  http://asciinema.org/ Already does this to great effect, here’s the pull request where that was done (for reference): https://github.com/sickill/asciinema.org/pull/141 .

- Design it: the GNOME developers kept their Gnome Shell design in a GitHub repo (https://github.com/GNOME/gnome-shell-design), but anything that allows us to discuss/iterate on designs would probably work.

- Implement it. Again discussion out in the open would be best for this, GitHub and I think Bitbucket have pull requests that we can use to comment on code inline.

So who’s in!?

Thanks a lot for listening,
Leonard

[0] https://kernel.org
[1] https://github.com/lenniboy
[2] https://code.google.com/p/vim/source/browse/runtime/syntax/sshdconfig.vim

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Christian Brabandt]

On Wed, November 6, 2013 22:54, Leonard Ehrenfried wrote:
> I really hope I don't hurt anyones's feeling by saying that the current
> vim.org website looks a little bit dated. I also happen to think that it
> doesn't do a very good job of explaining what vim is and how to install
> it. Lastly, it doesn't give you any hints on how to effectively manage
> your plugins with tools like pathogen and/or vundle.
>
> I would like to change this and I was wondering if there is any sort of
> appetite for updating the website? I would volunteer to implement/lead
> this effort.

Personally, I'd really prefer an update to the design of that
website. And others have expressed a similar wish [1], [2] and
it could possibly include a new logo, if we settle on a new one [3]

But the problem seems to be on the infrastructure side, e.g.
who get's access to the page source and can make changes. IIRC,
Bram wasn't willing to have the webpage source available to the public.


[1] https://groups.google.com/forum/#!topic/vim_use/lLp9EUVfbus
[2] http://vim.wikia.com/wiki/Vim.org_relaunch
[3] https://groups.google.com/forum/#!topic/vim_use/61DSyLWFeak

regards,
Christian

[Justin M. Keyes]

On Wed, Nov 6, 2013 at 4:54 PM, Leonard Ehrenfried
<leonard.e...@gmail.com> wrote:
> Before I get ahead of myself in terms of planning I would like to gauge the community's feelings towards an undertaking like this.

For what it's worth, I am very much in favor of this. I am really glad
to see this and the logo[1] getting some discussion. Branding and
image are important, even for open source projects, because humans
have limited time to evaluate every possibility in the world, so they
often take shortcuts by making inferences from limited superficial
information. And that's just a fact made necessary by the finiteness
of time. And the value of paying some attention to "marketing" can
have a disproportionately positive impact on the health of the
project. New users benefit existing Vim users indirectly.

Git did this about a year ago. Vim could do it and hopefully get a ton
of mileage out of it. I certainly don't suggest having these
discussions more than once per decade :)

From my armchair position, I would also like to suggest that whatever
technology or resources are used to update the website should be very
low-maintenance and perhaps unsexy. Throw up some bootstrap template
and it's going to be out of style in 6 months. I agree kernel.org is
the right direction, although perhaps a tad austere. CGI for the
backend is probably not a good idea, but I would also be wary of
kitchen sinks like rails and django.

If the website renders ok in w3m you will likely earn some extra good will :)

I think it's good to outsource things like source hosting to services
like github. Maybe vim.org shouldn't be concerned with that hosting
burden. I would even suggest punting on the idea of user logins.

vim.org should primarily provide:

- the user manual (why does vimdoc.sourceforge.net/htmldoc/ dominate
search results for vim docs?)

- an aggregator for plugins from all kinds of sources (github,
bitbucket, sourceforge, vim_use threads, stackoverflow

That's my three pennies.

[1] I don't favor the new logo proposed in the other thread, but at
least the notion has been raised.

[Justin M. Keyes]

> doesn't do a very good job of explaining what vim is and how to install it

That reminds of one more rather important function of vim.org: provide
updated builds. Currently for Windows users, this is provided by
random blogs, for which I am thankful, but didn't find for a very long
time.
Justin M. Keyes

[Benjamin Klein]

On Nov 7, 2013, at 1:20 AM, Christian Brabandt <cbl...@256bit.org> wrote:

> But the problem seems to be on the infrastructure side, e.g.
> who get's access to the page source and can make changes. IIRC,
> Bram wasn't willing to have the webpage source available to the public.

Even if the site’s source were not to be made open source, a mere redesign of the existing site could (I think) help matters tremendously.

--
b

[Marc Weber]

A new vim webseite should support:

- password reset (requires email sending, sourceforge did not allow this
in the past)

- integrates a wiki. I'd personally like to see a git based one.
A very simple draft can be found at http://vim-wiki.mawercer.de/wiki/index.html

- fixes the "author of plugins must care about 3 files" issue:
github's README(.md/txt/..), install/info section on www.vim.org and
doc/* documentation.

Thus it should be able to display REDAME.txt / README.md like files

- allows browsing plugin files online

- allows searching in vim files (also plugin files), eg using github api

- integrates vim-addon-manager-known-repository like fatures

- allows registering plugins by "git(hub)/hg/..." like urls and be done,
then generates zip/.. whatsoever from that info
master branches are very stabel more often than not.

- should still care about everything which was important on the old
site, such as wishes about extensions, who spent how much, Uganda,
....

- be very explicit about which operating systems are supported
officially, and who is testing features on those. Eg I think that
some features can only be "fixed" by introducing threading or similar
and I don't have OS2 for testing.

- should consider talking about the future of Vim (if known), roadmap
- even if its vague and uncertain.

- do whatever is necessary to improve collaboration. There are multiple
projects such as snipmate, vim-snippets, vim-addon-manager which are
maintained by multiple commnunity members. By updating from a github
url this "membership" work could be outsourced to external partise
such as github or similar.

I'm pretty sure that Bram remebers quite a lot of "discussions". The
last unanswered very important question by him is whether he would allow
a differenting hosting if its guaranteed to be payed for a couple of
years so that cloning repositories, caching source files, sending
emails and similar features can be implemented.

Of course - as always - this is only my limited view about what I think
would be good for the Vim project and community.

IMHO the first step is to find out what Vim and its community should be
tomorrow, then documend and move forward. People will join and help
probably.

Marc Weber

[Leonard Ehrenfried]

Hi Mark,

sorry it has taken me a few days to reply.

I wholeheartedly agree with most points you've made and think a better integration with Github is quite important as most plugin development (or at least the sort of development we want to encourage) happens there. Most of the time I skip vim.org completely when searching for plugins and go directly to Github.

I wonder though if Bram can be convinced to let this happen though. 

I like your idea about the future direction of vim - that's exactly the sort of thinking we need.

Regarding the hosting situation, where is currently hosted and who pays for it? I don't think it should be too hard to find a company who would be willing to sponsor the hosting of vim.org. I think lots of companies who want to attract developers would jump at this opportunity considering that the cost would be below 100 € per month.

I'm not sure if convincing Bram outright is the way forward. Maybe it would be easier to "fork" the website and have something like vim-plugins.org first which simply pulls in information from github and vim.org. It this already works Bram would maybe see the benefits.

Thanks for listening,

Leonard

PS: Ich glaube wir können auch deutsch sprechen, oder?

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---

You received this message because you are subscribed to a topic in the Google Groups "vim_dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/gnacQjDXSQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_dev+u...@googlegroups.com.

[Leonard Ehrenfried]

Even though I don't really want to start a discussion about technologies, I agree with Justin that most of vim.org's content is static and doesn't need a server-side framework. FWIW, kernel.org is made with a static site generator.

The plugins section is obviously different and would need quite a bit of server-side code. It think this part is more sensitive in terms of security and spam-prevention.

My question is how to move this forward? Is it at all realistic to get buy-in by the core developers outright or is it more sensible to build some form of proof of concept first to show how things could work?

Leonard

[Marc Weber]

Hi Leonard Ehrenfried,

> I like your idea about the future direction of vim - that's exactly the
> sort of thinking we need.

I/You need. Open source is about being able to adjust software to your
own selfish needs. Its not about altruism. And it looks like its me
needing a wiki only, because its me contributing to mine only.
Vim wikia has had a similar experience.

> Regarding the hosting situation, where is currently hosted

sourceforge, sourceforge

> it? I don't think it should be too hard to find a company who would be
> willing to sponsor the hosting of vim.org. I think lots of companies who
> want to attract developers would jump at this opportunity considering that
> the cost would be below 100 € per month.

If there a couple of companies who want to spend 100€ per month on Vim related
topics let me know. That would fund some work on the core :)

> I'm not sure if convincing Bram outright is the way forward. Maybe it would

It must be him deciding whether he'd accept different (self managed)
hosting. There are quite many options. Currently we have:
- vim wikia
- vim-scripts
- vim.sf.net = vim.org
- vam.mawercer.de (packages and sources connected to github, view of
vim-addon-manager-known-repositories)
- my vim wiki (based on git)

It would be nicer if this all would be integrated in a central place.

> PS: Ich glaube wir können auch deutsch sprechen, oder?

Not when sending to vim_dev

Marc Weber
Im Tannhoernle 4/1
D-78052 Villingen-Schwenningen
Germany

Mobil: 017660032282

Steuernummer: 22483/ 29259
Finanzamt Villingen-Schwenningen