Do we have any site statistics on the current site of what pages are most frequently viewed? That could feed into a perhaps better discussion on what type of information to focus on.
One thing that makes me a bit uneasy in the discussion so far is the fact that both Daniel and Gus seems to glance over the "Documentation" part as just being a category and not that there are many important things behind that category. To me one of the "selling points" of choosing Jenkins way back in the day was the meaning behind "Highly Extensible". It doesn't only mean that there are 1095 different plugins I can install, but that there is a possibility that I can make Jenkins do whatever *I* want. Something that today is very front and center on the home page. By clicking the link "Extend Jenkins" I can learn how to do that (we can perhaps argue about the quality of the docs behind that link) but the fact that it's front and center on the page is an important notion to me and a very important feature of Jenkins itself and possible the biggest reason for us having such a wonderful and vibrant dev community could be attributed to the fact that users can "upgrade" themselves with just a click on the home page instead of diving into the depths of the documentation pages. And I think that's nothing to be glanced over and just put into the "Documentation" category. Yes in the theme of 2.0 it is important to focus on new visitors/users, but I would argue that it's equally important to cater to the users that are coming back to the site after the initial experience, and make them want to come back for more in depth knowledge. /B On Thu, Oct 8, 2015 at 9:44 AM, Daniel Beck <[email protected]> wrote: > On 08.10.2015, at 06:39, Gus Reiber <[email protected]> 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 [email protected]. > 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. > -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS3-H97zW8O%3DM2Y6r5BgYeuz7iFG1PFbKVDzWjzp%3De%3DX5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
