> WDYT? That could work, but I'm personally not fond of drop down menus as it tends to be a suboptimal experience on touch devices.
/B On Fri, Oct 9, 2015 at 12:36 PM, Daniel Beck <[email protected]> wrote: > > On 09.10.2015, at 12:18, Robert Sandell <[email protected]> wrote: > > > If we go for a static site generation with a PR model I believe we need > to have the individual plugin pages distributed somehow, because if > everything is centralized to one repo with a PR model then we could risk > loosing the wonderful silo model we currently have with plugins. I think we > would need some way for plugin devs to handle their documentation pages > independantly of waiting for someone to approve and merge their PR. > > In my proposal, the wiki pages would continue to live in the wiki for now. > I realize that's not quite optimal, but as I wrote before, we don't need to > define the 100% end state now, just the general direction. The initial > release would definitely not have migrated any of the plugin content from > the wiki, basically just replaced the flat list by categories we have today > with a microsite that allowed better searching and filtering. > > > On Fri, Oct 9, 2015 at 11:49 AM, Robert Sandell <[email protected]> > wrote: > > I'm saying YES to showcase the plugins, but NO to hiding the > extensibility way down the plugin list. > > IMHO the extensibility documentation is equally important as the plugins > themselves and the user and installation guides, i.e. it should not be more > than one click (and no scrolling) from the main page to get to the > "introduction to extending Jenkins" documentation with further links to > everything else like the list of extension points, tutorials, javadoc etc. > > > > I just wanted to highlight that so it doesn't disappear behind the > "Documentation link" while discussing site content. > > For many of the menu items I'm thinking a drop-down (like on the current > site, or centos.org) that provides access to the various sub-pages would > be best. This seems a fair balance between not overloading the menu but > still allowing quick access to sub-sections from the initial page. So > having two sections "Use" and "Extend" in "Documentation" should be fine, > moving the developer content out from "Contribute" in my current proposal. > > We could also model the short introduction blurb about Jenkins on the home > page after git-scm.com, where parts of the description link to certain > sections of the site. Of course we'd mention "extensible" and that could > link to the developer documentation. > > WDYT? > > -- > 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/332F496F-AC0B-4848-8613-9619901A77C2%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/CALzHZS202meejJku8gYT%3DWi28g2iiWzcMLMOM0%2Bi967zSxfC5w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
