On 08.10.2015, at 06:39, Gus Reiber <grei...@cloudbees.com> wrote: > I understand the urge to keep the scope manageable, but I am not sure I see > in Daniel's list where the improvement is likely to come. It is a little > concern of mine that we are emphasizing ease of authorship for a reasonably > small subset of Jenkins users (those who write code) over the general > usability of the site. ...but if we don't get content authored, it won't be > much of site, so... pick your poison, I guess.
Think about the kind of software Jenkins is. The least technical person to use Jenkins is probably an engineering manager, and I doubt they're going to contribute to the site. The vast majority of serious users are admins, developers, testers, or similar roles. All of them write code, at least scripts. All of them can handle text editors and don't think of Word when they hear that term. > • I would have ordered your list of content areas by importance and placed > plugins at or near the top. I think we are doing a bit of a hand wave there. > It can and should be A LOT better than it is today, with browsing, searching, > ratings and reviews. If we did that alone, we will have greatly advanced this > site. Not doing so, I think, would be a big opportunity missed. Absolutely agree. Plugins are important and we need something better than a flat list. Not sure about ratings/reviews (may be too high a bar for the initial release), but as I wrote, the plugins microsite can always be extended to cover more. One of the things that would make sense would be including popularity, both absolutely install count and recent growth. Regarding ordering, it's essentially the one I'd use on the menu, in (mostly) increasing levels of involvement, rather than the weight placed on each section. > • Search seems to be missing from both the doc and the blog. I wouldn't say > the blog is good today. You can't browse it and you cannot search it. > Basically, if an article is more than a week old, good luck finding it. It > might be that we just want to punt and port the blog to flat files and call > that good. ...but if we want to make it better, the blog should be browsable > by author, category and rating, as well as searchable. Any number of > free-ware blog sites and tools offer these basics out of the box. > • Doc needs to be searchable. Ideally it would also be integrated with > technical blog posts and javadoc, If our website cannot offer search features > at least equal to a free WordPress site, we should ask what we are doing and > why we are doing it. I don't think I've ever used site search and been happy with the result. There's always something that isn't indexed, or it's stupidly broken in some way. If you want to look for something, you go to Google and search for "something jenkins". This has the added advantage of not caring whether something is on the site, the wiki (which will continue to exist for quite a while even if we decide to get rid of it), the mailing lists, or even Stack Overflow. Or does your free WordPress site index those? That said, there appear to be solutions for site search when using Jekyll, so we may still be able to do something here. Or just do the custom Google search thing. It looks like it's 100 USD per year if we want it to look nice as well. A few years ago I used Google/Bing via API, I assume this still exists? That would make it integrate seamlessly into the site. > • Events need to be handled somehow in the new site. They are handled poorly > in the current site. I am a little concerned they will be handled even worse > in the new site. Again, I think a reasonable, and now surprisingly high bar > should be event handling of equal quality to that which you might expect to > get with a free WordPress site with an event widget added. So what specifically is missing? They are featured on the home/front page, and get their own page(s) to display them however makes sense. > If you look at any number of the 'instant website' hosting services (almost > all of which have a free version), they have effectively set the bar so far > above where Jenkins-ci.org is today, that I feel like we have the wrong > benchmark. If we are going to take on the effort of making a custom site, > rather than just grabbing a commodity site, I think what we build ourselves > needs to be in some way better or at least equal to the commodity version. > > ...if we can't do better than a stock WordPress site, why wouldn't we just > use a stock WordPress site? The bar has really come up a long way in the last > 5 to 10 years. The good news is that a lot of these "fancy" features are now > old-hat. I wrote what sites I looked at to build the proposal. They seem to be doing their job quite well. One of the requirements repeatedly mentioned in the discussion is that this is the Jenkins site, and needs to offer documentation and downloads, so that's what I described. I don't think anyone but you and me even bothered mentioning the blog, events etc. -- so I'm already going beyond what appear to be the general requirements. Therefore I don't see where your need to somehow do more are coming from. It's certainly not result of the current discussion (or I _really_ missed something when I built the summary). FWIW I kept the basic list of things we seem to move towards in this discussion and my proposal deliberately separate. One is the basic description of where the discussion seems to be going, the other is my "implementation" of that. While you addressed my proposal, most of what you wrote appears to fundamental that you should probably specifically address my summary of the discussion instead? -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/DA032009-5DED-458C-80E9-634F89151A92%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
