The Joomla!^® User Experience Portal

.

I don't think the idea is to force developers to do anything, especially when it comes to the front-end appearance..

I am 100% an administration that has unity in how it looks and feels though.. without question! it's always tricky jumping from extension to extension on the back-end when you install any that do their own thing and don't stick with the UI conventions you're familiar with.. extreme colors, strange layouts, loud graphics ...The administration should flow and look unified for sure.. that is where I see the power of the new JUI framework.

Front-end design is something that obviously varies from site to site.. so I don't think the idea is to force you into a canned look on your site front-end but rather provide a convention that makes it easy to set up the style sheet and know what to expect when you install a new component..

As it stands now, when we design a Joomla template where we work ( which is always a custom job, we don't resell templates ) .. we always build in time for styling extensions we didn't write.. We know we're going to have to tweak things that are third party mostly because they often don't stick to a convention... it would be GREAT if people used a common set of tools so that it would be easy to snap in a css file and know that things are going to play nice visually without having to hunt them down and add in a bunch of otherwise un-necessary css because they decided to use a class name that makes no obvious sense =)

Unfortunately though - having the toolset won't force it to be used .. one can hope I just hope this doesn't scare front-end designers into thinking this is going to force them to have a UI that looks like every other Joomla site .. I'm confident that's not the idea.

I hope we never regret jumping into bed with Twitter...instead of doing the work and developing our own.
What's the worst that could happen?

articles.chicagotribune.com/2012-08-20/b...-party-apps-tweetbot

@jwbrett Is this change related to Twitter (the service), or Twitter Bootstrap (the responsive framework), or both? If it's Bootstrap, it smells like incentive to do it in-house, just in case it proves restrictive. At least Bootstrap has served as a sweet pioneering model to follow. If I were a big corporation using Twitter Bootstrap, I'd be putting my lawyers on this, to see what the potential and real risks are regarding their change in policy.

.

Apache License, Version 2.0 - How can you compare Twitter API which is one of leg that Twitter stand on, to side small project that HELP itself Twitter to better UX?

Goal to sharing Bootstrap is to get FREE feedback and bugfixes.
There is no reason to stop this well oiled machine that collects good dive for them.

Even if they stop it. Devs can fork it and go own way. Paraphrasing Johan Janssens, you can't make it something open source today and grab it for yourself tomorrow. It doesn't work. Ask Mambo.

Bootstrap is super powerful. We all get it. What I don't understand is why would anyone change the core bootstrap files? It's not even bootstrap anymore, it is a mashup. Compare the actual bootstrap files to the JUI ones. If overrides were that important, why wouldn't there be an *optional* overrides? How do you plan on updating the CSS when Bootstrap does, it would be a lot easier just replacing the actual bootstrap files and keeping the overrides.

Also, the JS files aren't the same. Again, it isn't truly bootstrap. If the core JS files had to be modified in order for anything to work properly in the first place, that is a sign of the environment being bad for bootstrap. So the answer is to change bootstrap? Again, what if Bootstrap modifies it's code -- updating will be more of a pain.

Core JUI media files are way too buggy. (not working on touch screens, responsive nav bugs, popover bugs, etc etc etc) I will emphasize if I had the know how, I would squash those bugs in a second for the J! community. So, I have got sites to work properly by stripping out the media bootstrap files and using the actual bootstrap files. What do you know... they work!

I can not recommend using core media files at all until at least they are the actual Bootstrap files, not some modified version. Obviously, I recommend getting the actual bootstrap files in there, if necessary, creating optional overrides. Otherwise, it is headache city.

I welcome any feedback or insight and look forward to a fruitful discussion so we as a community can have the best platform for our websites!

Bootstrap is meant to be modified, but honestly we've barely modified it at all to ensure Bootstrap upgrades are as easy as possible in the core, so not really sure what you're referring to here. For any extra UI elements we needed that didn't exist in Bootstrap we added them in bootstrap-extended.less in the same standards that Bootstrap is written, and we had to touch the .modal class so it didn't fight legacy Joomla modals, but that's the only core style we touched. The only Bootstrap javascript we touched was the dropdown for the navbar so it stays open after clicked once, which was a huge request/discussion in this forum.