Bonfire
Bonfire copied to clipboard
lonnieezell
Bootstrap 3
Do you mean will moving the entire system to Bootstrap 3 be quick an painless? probably not. They changed quite a bit of syntax. Depending on the size of your application you could probably do it 3-4 hours, maybe less? Completely wild guess here. :)
And what about moving the entire Bonfire to Bootstrap 3? Any plans to do that?
Perhaps for 0.8?
The list of changes that would have to be made to upgrade a site from Bootstrap 2 to 3 can be found at: http://twbs.github.io/bootstrap/getting-started/#migration
I'd actually like to attempt to setup something that would allow us to use themes or a driver for each framework, but I'm not sure when I'll have time for something like that. I may try setting up a Bootstrap 3 theme on my test site to at least see where the issues would be in maintaining both for the Bonfire core.
Is there any reason why the Bootstrap files are contained separately within each theme? Surely since they're unmodified vendor files they should just reside in a single location in the assets folder. Then each theme would have its own CSS file for custom styles.
I would also very much appreciate a complete overhaul to Bootstrap 3.0.2+. I started doing some simple find and replaces for the changed class names, but then realized I would have to dig a lot deeper as some components are rendered by Bonfire rather than just being hardcoded in a view, for example the Contexts::render_menu() function. I've only scratched the surface of Bonfire, so it would take me quite a while to find all the variables related to Bootstrap.
The problem with using a single set of Bootstrap files is that we need to keep the Admin side consistent. If a developer upgrades the version of Bootstrap, say from 2 to 3, then the entire admin area breaks. Similarly if they choose to use Foundation or a custom CSS framework and delete Bootstrap, we're screwed again. So, we keep them separate for safety sake.
As for a Boostrap overhaul. I'd love to see it too. :) I don't have the several hours it will take at the moment to go through and do that, but it is on the near term roadmap. Any help in those areas would be welcome.
I actually started doing this upgrade a bit simply for my own work so I would definitely be game to continue that work in a pull request.
@DaveMC08 That would be awesome. I've started some work on the docs area and theme and decided to move that to Bootstrap 3 also, so if you want to work on the main area that would be excellent.
Started to do so, however there is a small problem with the menu system. As of twbs 3, multilevel menus are not supported. I can add them, but should we add them I guess is the question.
It would probably be best to add them if possible. They weren't in 2 originally, either.
Oops. Anyway, the multilevel menus are one of those issues that I may agree with the designers of bootstrap on, but in the end the demand for the feature will bring it back.
At least in the mean time we could use drop down headers and dividers. This way we can adhere to currently supported implementations. And in the future if it does come back we can add it back in accordance with their syntax.
I'm not sure if the above will be helpful or not. I started pulling the markup out of the Contexts class' methods a while back, but never got around to trying to replace the markup with something new. The templates and what can be replaced in them may still be too specific to Bootstrap 2, but I thought there might be a chance that this would be a better starting point.
IIRC we added the code for the third level of the menu system to BS 2 also, so we'd have to do that here, unless we come to a redesign. At the moment, I think they kind of have to be, though, I can see a layout that would achieve the same affect using something like option groups in a select field. The name of the Module (like Email Queue) would become a simple header that wasn't clickable with the "child" options listed below. Then, of course, you run into issue with menu length...
Yeah, we originally had some work-around in place for BS2, then updated the code when they added the functionality (there's still some code in the contexts library to 'fix' markup written for the work-around, should someone pass in a sub-menu that hasn't been updated).
I recently added sub-menus to my Content menu because I simply have too many modules. While I could condense many of them according to the way I grouped them in the menu and create nearly the same result, it would also make for a few rather large modules. Additionally, we have 2 or 3 sub-menus in the core modules.
Even if we don't implement sub-menus, I still think we're going to need something that allows us to create that hierarchy in the menu system. I don't think most people have the luxury of the bootstrap developers in just ignoring their users, common practice, and interoperability in favor of purity of design, especially when they're hired as consultants/contractors.
I agree that most people probably don't have the luxury and we'll have to add a third teir there. If for only the reasons you mentioned.
I try to create more Contexts.
If a User has access to only one context I think it feels very cluttered, so I tend to create at least two or three for bigger websites. Has worked well for me.
But really, sometimes the third tier may be almost unavoidable, and giving the option is interesting.
I'm just not sure if Bonfire should use it, or if Bonfire would be cleaner without it. (Thinking of the core Modules)
I agree that Bonfire itself would likely be fine (and maybe better off) without using a sub-menu. I still think it needs to support it, though, and it would certainly be easier to implement and test support for sub-menus by leaving the existing sub-menus in place.
I tend to think that backwards compatibility and flexibility are strong points for any development framework. I would prefer that users be able to take an existing site and migrate it through from one version to the next without having to rewrite much (or any) of their own code, lose data, or perform odd hacks (I would still like to resolve the issue of migrating users from 0.6 to 0.7, but don't know if I'll have the time to spend figuring it out before it becomes ancient history).
If we choose not to add support for them into Bootstrap 3, then we should still support existing sub-menus in some other way within the confines provided by the framework. As @DaveMC08 mentioned, we could add a header and dividers to the menu to indicate that we in-lined what was previously a sub-menu. I don't think most people would be happy with the result, but they wouldn't lose functionality in the time between updating Bonfire and getting around to changing the menu for the module(s) that previously used sub-menus.
Personally, I would prefer more of a 'dropdown-within-a-dropdown' approach, leaving the sub-menu initially collapsed and clickable, then expanding the sub-menu within the parent menu, but I haven't had the time to experiment with that possibility.
@mwhitneysdsu I believe we think exactly the same. So, re-thinking the third tier for Bonfire is something interesting to do, but when? For 0.8?
Also, it would be prudent to decide in which version Bootstrap 3 should be integrated.
The 'dropdown-within-a-dropdown' approach seems to be the best, really, I'm just not sure if we should show it on click or on hover.
I'm inclined to believe hover is best for usability, but I'm not sure of it.
I like the dropdown-within-a-dropdown approach, at least in theory. Would have to try it in actuality first, I believe. :)
I just wrapped up most of my work on the new docs system and my plan was to move onto integrating and completing the new menu system so now would be the perfect time to finish the integration of BS 3 (which the docs system is currently using so it would be nice to update to a consistent version).
Hover works best on the desktop, but for mobile and tablets, I believe click still works best. I know iOS has made big strides over the years to successfully turn hovers into clicks, but I'm not 100% sure of Android or Windows devices. Not my area of expertise, unfortunately.
Actually, it's more like everyone updated their frameworks to stop using hovers. I could pull up a few sites that I haven't had a chance to move over to Bonfire, yet, which are nearly impossible to use on a touchscreen device.
@mwhitneysdsu Ohhh, I forgot the touchscreen issue. It has to respond to click, of course. But shouldn't we (maybe) use both, to improve usability on all devices...?
If it can be done so that it actually works and is accessible, I won't argue with it.
I think that people like the idea of hover, but when they're faced with it actually being tied to functionality, they tend to find it frustrating.
Maybe it's just Brazil that's way behind on those things. Around here, all dropdowns are on Hover. It's been like that for a pretty long time, clients usually want it to stay like that.
But if you perchance notice a trend on the other direction, especially if it's tied to mobile usability, I believe Bonfire should follow that.
Well, the easiest thing to do is simply look at what's supported out of the box. Most items that have click behaviors will change color on hover to help indicate they are clickable, but actions require a click event.
The 2.x sub-menus apparently do activate on hover, but now that I've realized they do so and tried to use it on my phone, I'm going to have to go in and remove the sub-menus from my site next week... The sub-menu will show up (for a moment), but you can't activate anything in the menu (at least in Chrome on a Samsung Galaxy S3). Of course, it's possible I broke that on my end, but it certainly explains why 3.x doesn't support it.
@mwhitneysdsu We could simply use a caret to identify a submenu, and require the click to activate it. I believe this would solve the issue on Mobile.
I believe what might work, potentially out of the box would be an accordian in a dropdown. @mwhitneysdsu @ellahn I think this is kind of what you are saying?
@DaveMC08 That's pretty much what I was thinking, I just haven't had a chance to actually attempt it, yet.
I'm thinking something like this.....http://jsfiddle.net/67QVD/7/ However I can't seem to get the dropdown to not close on collapse click