Bootstrap 3

[ruelluna]

Will it be quick?

[lonnieezell]

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. :)

[frnco]

And what about moving the entire Bonfire to Bootstrap 3? Any plans to do that?

Perhaps for 0.8?

[ruelluna]

@lonnieezell , @ellahn got my point.. sorry for the short description..

[mwhitneysdsu]

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.

[AusQB]

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.

[lonnieezell]

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.

[ragingdave]

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.

[lonnieezell]

@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.

[ragingdave]

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.

[mwhitneysdsu]

It would probably be best to add them if possible. They weren't in 2 originally, either.

[frnco]

Or perhaps we should not have multi-level menus, to keep things simpler...?

[mwhitneysdsu]

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.

[ragingdave]

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.

[mwhitneysdsu]

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.

[lonnieezell]

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...

[mwhitneysdsu]

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.

[lonnieezell]

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.

[frnco]

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)

[mwhitneysdsu]

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.

[frnco]

@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.

[lonnieezell]

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.

[mwhitneysdsu]

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.

[frnco]

@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...?

[mwhitneysdsu]

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.

[frnco]

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.

[mwhitneysdsu]

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.

[frnco]

@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.

[ragingdave]

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?

[mwhitneysdsu]

@DaveMC08 That's pretty much what I was thinking, I just haven't had a chance to actually attempt it, yet.

[ragingdave]

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

[mwhitneysdsu]

That fiddle isn't working at all for me, perhaps because the included bootstrap files are 2.3.2?

[ragingdave]

sorry jsfiddle had been acting up a bit for me. This should work....http://jsfiddle.net/PK9au/ UPDATE: http://jsfiddle.net/PK9au/5/ This one seems to actually work FINAL: http://jsfiddle.net/PK9au/6/

[mwhitneysdsu]

Final looks very good. We might be able to improve the animation a little and work on keeping it from using scroll bars until the menu reaches the end of the screen, but overall I think it's a great result for something that probably wasn't intended in Bootstrap.

[lonnieezell]

Looks nice. Pretty good solution.

One thought, though, should we close any open accordions when opening a new one? Otherwise it's up the user to manage things if the menu would get big enough to flow off of a small screen.

Thoughts?

[frnco]

Usually you open only one dropdown at a time. I think Accordions should work the same. Not only when it gets too big too, as it leaves out unnecessary or distraction options.

If a user clicks on "another" option it means they didn't find what they were looking for yet. On the off-chance they were comparing, it's still a more largely used metaphor to close the previous options, so I believe it tends to be more well-accepted.

[lonnieezell]

Here's something completely random, but if we're looking at a site-wide upgrade for the admin area anyway, what do people think about Semantic-UI? I've recently discovered it and it looks very, very nice, with a great looking roadmap.

Anyone interested in us making a switch or do you think we should stick with Bootstrap?

[frnco]

Seems interesting, but there are a few points we should consider...

1 - It's pretty easy to replace the default Bootstrap styles using a Theme file. If many people do that, it can be a pain to move to Semantic, especially if said website uses Bootstrap for the front and Semantic for the Admin, and the theme has to look the same (Or very similar at least). 2 - I heavily edit the views for the Modules, and I guess that's the idea. File inputs, html editors etc. Will Semantic make this easier, harder, or no change? 3 - Performance. Do you guys think this change will be good, bad or no big deal performance-wise?

I think there are many other things, but this already gives us a few things to consider, and a starting point to understand what we're changing and see if it's worth it.

[mwhitneysdsu]

I think the option of Semantic-UI would be good (though I think they completely mis-named their project). I think this goes back to the idea of making a framework-independent library/driver for forms, though. It would be nice to be able to switch between Bootstrap 2 & 3 or Semantic-UI or some other framework without rewriting the views for all of the core modules as well as all of my own modules (sure, I would have to do so initially to take advantage of the library, but hopefully never again).

Additionally, using themes for the admin views for any module (core or otherwise) can be difficult given that the system tends to look in the same place for every module (i.e. /{theme}/{context}/index rather than /{theme}/{context}/{module}/index or /{theme}/{module}/{context}/index).

I've added a simple driver implementation for the Form library and modified the BF_form_helper to hook into it at https://github.com/mwhitneysdsu/Bonfire-Form-Driver As noted there, the actual use of the form library in Bonfire is pretty limited. Additionally, though I used the files from the current dev version of Bonfire, I have only tested this with a slightly updated version of the 0.7 release.

[lonnieezell]

@DaveMC08 did you ever submit a PR for the Bootstrap 3 changes?

[ragingdave]

I'm sorry no I actually got pulled into a rather large project instead. I can try and work on some but I would say nothing would come of it anytime soon.