Thanks as always for working on bootstrap, its an invaluable tool.
Couple thoughts:
Maybe its just me but I think the docs site a huge step backwards in usability. The dark blue <-> red graphics offset by the blue of their primary buttons is a little...gross. I am also not at all a fan of the left hand navigation panel, I get that they are trying to show off the affix component but I'd rather have the content be full width as its all I am really there for. I found the sliding top sub navbar far less obtrusive and easier to navigate. Also: so white is the default for the navbar but the demo site is still using black?
This is just a speculation, but I think bootstrap-affix.js is their new baby. If there is one thing that the new navigation does well, it's promoting the affix js feature (scrollspy stuff).
Fair criticism, but the subnav we had before, like the navbar, just doesn't scale. Let's less obtrusive, but hinders us in a big way. It's tough doing nav that works for everyone everywhere, but hopefully this pans out for us and folks using Bootstrap.
Edit: Also, the side nav came first, then the affix plugin. Originally I was proposing a fixed, independently-scrolling left sidebar, which we may still get to, but it felt decidedly un-Bootstrap-like for the time being.
I really, really loved the subnav, precisely because I use smallish width windows (routinely half of 1980px, thanks to window snapping) and at that size the left nav block feels like a complete waste of space (especially the huge blank area just below, given a height of 1080px).
It's a lot harder for me to navigate the doc pages too because I'm scrolling a lot, lot more and the "sub-topic" nav-bar is gone (e.g. "Base CSS" page had "Typography", "Code", "Tables", etc.)
Like you, I still appreciate the new functionality and continued development.
EDIT: Went back and the styling of the docs changed again (was I hitting a cached page?). The subtopic navigation is back and on the left now. Still takes a while to scroll but it's an improvement.
I like the new navigation and layout better because I can find everything in one large column. Before I had to scan both up/down and right/left because of the multi-column layout.
Yup, that was what we wanted to avoid for this round of updates. Cmd+F is your best friend in docs, no matter the format. Either way, we'll strive to improve as much as we can with future updates.
I have the exact same opinion, the new doc page is a step backwards...
It make me close it in 10s and I use TB in 2 of my projects and I love it, but that layout is simple terrible for people with smaller than 20" screens... please provide us another site with more reading area and minus menu.
Anyway thanks a lot for this, I love TB it's great and you guys are my heroes :D
Unfortunately, it seems like submenu implementation has the classic mistake: it requires mouse cursor to travel strictly along the menu item to get to the submenu.
and close immediately when not inside the triangle.
Also, if in the parent there's another menu item with submenu somewhere on the path of mouse inside this triangle, ignore this item.
For best results, if mouse was inside the submenu for a moment, keep the submenu open until clicking away from it or moving over a different item in the parent menu. So many details!
Yes! Absolutely. We wanted to add some javascript love to the dropdowns, but ultimately didn't have the time to get it in there for launch. The beautiful part of it is we can always improve :). Much love for the diagram as well—I'll see if I can get Jacob to cook this up.
Not difficult at all. For a simple fix, one just needs to add a timeout between receiving the mouseOut event and hiding the menu. OS X appears to do something slightly more complicated; it hides the menu immediately if you mouse out away from the submenu, but keeps the menu open for about one second if you mouse out towards it.
Thank you for calling this out. We'll fix it up as best as we can with the next release. Knew it going into this release it wasn't enough, so hopefully we can iterate on it to get the right behavior.
I love bootstrap. Yeah, i hate the fact that all the mvp's out there basically look & feel the same by using it as the go-to css framework, but at the same time it's helping people iterate a lot faster and that's rarely a bad thing.
In addition, given how Twitter's bootstrap's look & feel is starting to influence web design at large, I wonder if there is a case for other large web-players to make their own css framework to impact the look and feel of sites to their favor. Think of it as disguised propaganda.
Fixed headers also break the pagedown behaviour: when you press the page down key, you miss some lines that are hidden below the fixed headers. (If we mean the same thing by fixed headers)
Nearly all desktop applications use a fixed header, it has fine usability there. For a web app, as opposed to a primarily informational site, I think there are definite cases where a fixed header is preferred. Gmail for example, it makes sense to have control butons for your message always visible.
tl;dr on your average blog I agree, but in a web app I don't.
Since lukifer wrote "in most cases" you're only disagreeing if you think there are more web apps out there than blogs or informational sites. He didn't say a fixed element is never desirable. I think you're agreeing.
How about taking the approach of the browser on android 4+? The top bar disappears as you scroll down, but pops into view when you scroll up. It is then aligned with the user's intention, a scroll up being a signal that they wish to go up to the menu. Combine with a reasonably speedy fade-out for cases where a user is simply scrolling up to re-read something, and I think it puts most of the usability issues to rest.
They were an anti-pattern for my site so I CSSed them away. But with 2.1 there's .navbar-static-top which does the same thing as my custom CSS. I think they should place it ahead of .navbar-fixed-top in the docs since it's better in most cases.
I think it's a matter of personal taste. Since all the examples used to display the bar, people probably had a tendency to include the black-bar without thinking too much about it. However, nothing prevents you from building a very functional site without it (I know i have).
Either way, huge prop for the awesome work! The new doc is simply excellent and the whole framework is just remarkable, particularly if one considers how far you guys have pushed it in less than a year.
Yes, I use a custom class on my header that removes the rounded corners that appear on the navbar when you don't use the fixed class (don't know if it's still the same on 2.1).
It's not always a bad thing; for something like API docs, a fixed header can make sense. But for blogs and brochure-ware, and even some web apps, it breaks the focus on the content and steals precious screen real estate.
If the most common use case involves many quick jumps across the page hierarchy, fixed header can be a good fit (though an affixed side-nav might be better for wide screens). But if the most common case is drilling down to a specific page and spending a little time there, then fixed headers just create noise and get in the way.
I would argue that they've done a good job of pulling together a lot of the look and feel of their peers into one library. While it can be obnoxious that a lot of MVPs all look the same because of it I don't think it actually looks that bad.
(For those who don't know there was a standoff between the bootstrap guys and the maker of a popular js minifier tool [Douglas Crockford I think?] over the pragmatism of ending lines in js with semicolons. Bootstrap claims that semi-colons are optional and verbose, while the minifier folks espouse semi-colons as a best practice, and have chosen to consider it "not a bug" that their minifier breaks working code with no semi colons in some cases.)
For that release we had an upgrade guide. It wasn't the most complete, but I think it helped a lot. For this one, as is the case for every other release, just browse the tags and download the docs. Just as it's not terribly difficult for us to host them, it's not asking much for you to download a ZIP file that will always be available :).
It does "stay online". Why must it also be hosted for you? When you download Bootstrap, you get all the docs in a folder. Open the index in your browser. All the old versions are tagged on GitHub and can be downloaded forever.
So when bootstrap releases a new version suddenly everyone must switch to self-hosting their docs? Because leaving the friggin' docs online costs so much?
It's inconceivable we are having this discussion on HN.
> Because leaving the friggin' docs online costs so much?
It's not so much about cost but about polluting the Google index with obsolete information. For example, look up a Java API and it's very likely that the first link you will get will point to Java 5. Google is not wrong, that API link is most likely the most linked to, but it's very often not the one you are looking for and certainly not the one that the author of the API wants you to find first.
I really don't see the problem. You have to download the release to use it and the documentation is included, what's the huge deal about keeping a tiny HTML file around? It's not like you suddenly need to start renting a VPS to read it..
It's inconceivable that projects are expected to host old docs forever. Jesus, it's in the zip that you get if you download the Github snapshot anyway. It's literally 20 seconds of your time to have your own local copy.
There is a big difference between forever and switching it off as soon as you change versions. Most people were still using 1.4 when 2 came out so leaving the documentation up for a year or something would not have been difficult.
python & django both host old docs for all in-use versions seemingly forever. Nobody's complaining that they're polluting google, or campaigning for them to be taken down. So why are people reflexively resisting a reasonable request for bootstrap 2.0 docs to stay up? status quo bias!
All of the documentation for old Haskell packages on Hackage are hosted online and it does pollute Google's results. Google often links to outdated versions and you have to take a couple steps to find the current version.
Have you actually tried to do that? BS 2.0.4 pops up with "framing not allowed!" and redirects to a missing page on the internet.
Probably relatedly, some/much of the docs rely on javascript, so they won't run unless you're running through a server. Instead of forcing everyone who wants or needs to see an older version of bootstrap docs to wrangle this non-working stuff in to a server and configure that, massive amounts of time would saved by simply having versioned docs online.
EDIT: the short answers is not to open the index.html file but any of the other .html files (examples, etc) and you should be able to at least navigate around some.
EDIT2: At least some of the javascript stuff is working without loading from a server - not sure why yet, but it's working. The index page still needs to be fixed.
Yes, I did actually try to do it. The popup is only on the index page, from one of those dynamic Github watcher-count widgets, and can be ignored by either opening the page of documentation you need instead or holding down escape, or deleting the offending widget.
I'm not sure what you're talking about with the JavaScript. JavaScript runs on the client, not the server. Twitter hosts these docs on Github Pages already... static files, no server-side code.
An error on the index sends off alarm bells, and I bet others never bother to try the other pages - just thinking "this is broken".
I know where JS runs. I was conflating embedded javascript references as <script src="http....> style javascript. Typically when I am doing JS, the JS is marked up as being served from a domain - an initial assumption would be that it would be trying to pull the js from a server, but it's not (or not caring, or my stuff is cached).
I still side with the others who want/expect hosted and versioned docs from a project of this size/influence.
Python, Django, Ruby, Rails, Node.js, jQuery all have multi-version docs online. I'm sure there are plenty more examples. Yes, I do feel entitled to having support for outdated but still relevant software. This is standard.
The latest version of bootstrap only just got released. I think a majority of users will still find the old docs relevant, even weeks later.
Yes, I realise I can still download the docs. But it's more convenient for some people to have it hosted online.
While the attitude is a little entitled, there may still be a valid point for other users as well. Couldn't se properly crafted URLs on the homepage solve this problem? Like /tags/2.0/documentation/index.html [1]. And run it right off of bootstrap?
Edit: the point being that we can point links at pages from previous commits, branches, and tags
Shouldn't this help?
[1] that URL was slightly bastardized but I'm sure someone could very quickly whip this up
Boy I was half asleep when I wrote that comment, all I was saying was that since github lets you reference previous versions of files by crafting the URL properly to include a tag/branch/hash, it should be possible to link to previous versions of the documentation straight from the latest version, eliminating the need for someone to clone the repo to access them.
Not cool guys. I can't actually open the docs that I downloaded because I get a popup that says "Framing is not allowed!" and redirects me to a non-existent Github URL.
You can clone the repo, check out that branch, and open the docs in your browser locally. That's even better, since now you don't even need a network connection to access it.
Having a copy that you can access locally is great, but there are advantages to having it online.
First, it means you can navigate to it by googling "bootstrap 2.0 documentation". If you are using five JavaScript libraries, it can be annoying to have to find the folder for documentation for each library.
Also, you might not even have the documentation locally. Another developer might have set things up and they might not have checked the documentation into version control.
Not to mention that any old tutorials, blog posts, wiki pages etc -- now link to 404 land.
While it would be great if everyone could just magically upgrade, if you've spent a lot of time wrangling some content management system to the "old" bootstrap, you're more likely better off fixing bugs in that site, than upgrading and hoping nothing breaks.
If it's supposed to be used as a framework, I'd say it's common courtesy to provide the old documentation for at least a short period. It's not that hard, see eg:
Bootstrap has restored the joy I used to have in building websites. I can think more about design and what I want to stay instead of cross site compatibility, pixel dimensions, and building responsive designs. Thanks so much to the team at Twitter for putting this out there.
BTW, I found almost all Bootstrap-powered websites I visited uses sticky top navigation, which wastes considerable amount of my precious vertical screen estate.
Another wide-screen wasting example is the new Gmail and Google Groups - and what's even worse is that they force you to use the new UI.
I find sticky top navigation is annoying and nothing else, I just don't get it, aren't many people using width screens nowadays? Or is it just me?
Maybe Bootstrap's nav should be non-sticky by default?
Bootstrap has been an invaluable asset for building our MVP. I'm glad we got rid of the top bar, and very few people actually think we use bootstrap. But it affords us wonderful defaults for tables, buttons, menus, modals etc.
If the team making it reads this, thank you. I owe you many beers for what you've given us.
I've been using Zurb Foundation (http://foundation.zurb.com/). It doesn't have as many feauture-rich components, but found the responsive grid easy to use and I really appreciate the fact that my site doesn't look like everyone else's...
I really do not like this new boostrap page. There's too much back and forth (left and right) hopping going on with my eyes. It doesnt feel very natural. It's like driving and then looking at the passenger over and over. I don't like it. Keep everything above the content and keep it full width like it was, but that's just my opinion.
I've already started a 2.04 site. As a web design newbie, how hard is it to update to the latest version? Just copy over the js and css? (I realise I'd need to re-write my html to use the new features).
One of my main beefs with Bootstrap was that it felt cramped. The switch to 14px body text with 20px line height addresses that. Personally, I'd increase the default line height a bit more.
Q: I run "less ./less/bootstrap.less > bootstrap.css" – but the bootstrap.css just contains links to all the less-files, and not one full css-file. What command do I need to do?
The customize area is really helpful and chops off time lost going through the source trying to customize it by hand. Great addition. Thanks for all the hard work.
Have you checked out the LESS code (instead of the compiled CSS)? The file variables.less has the same settings (with comments!) as the online customizer. It's much faster to tweak that file and recompile than it is to use the compiler.
I'm not very colorblind, but the "warning" color used for the progress bars is far too similar to the "success" color. Please consider a brighter yellow.
Couple thoughts:
Maybe its just me but I think the docs site a huge step backwards in usability. The dark blue <-> red graphics offset by the blue of their primary buttons is a little...gross. I am also not at all a fan of the left hand navigation panel, I get that they are trying to show off the affix component but I'd rather have the content be full width as its all I am really there for. I found the sliding top sub navbar far less obtrusive and easier to navigate. Also: so white is the default for the navbar but the demo site is still using black?