Responsive Design/Content Thought...

227 views
Skip to first unread message

Russ Winter

unread,
Sep 5, 2015, 6:22:35 PM9/5/15
to joomla-...@googlegroups.com
Hi there folks,

just thinking out loud here and asking for opinion...

We now have Responsive Web Design (RWD) with thanks to Twitter Bootstrap (and other frameworks), which is pretty cool and all, but in a way "Content" is still not really "Responsive", let me try and explain...

If I have a blog, managed with com_content articles, I can set the number and layout (columns) of the article display, which is nice and works very well, reacts responsively in the manner of image size and columns, but...

What if there were additional option for Tablet and Mobile that would allow us to reduce the number of articles to suit the device viewing at the category level?

So, on a desktop, we can offer a grid-view, say 3 columns wide containing 15 articles,  but on a tablet the columns auto-magically reduce to 2 columns and say 8 articles, and on phones the columns act as they do today with a single column, but also reduces the number of articles to say 3.  

Bandwidth might not be a huge concern for many these days, but especially on smaller devices, "important content", "screen real-estate" and "user engagement" still is...

I don't know of any other "product" or CMS that operates in this manner, without plugins of some sort, but none that I have seen are what I would say are "Content Responsive" depending on the device.

Thoughts? Comments?


--
Regards,
Russ Winter



wdburgdorf

unread,
Sep 7, 2015, 6:35:10 AM9/7/15
to Joomla! CMS Development
Does Joomla core in any way react to devices anywhere? I don't think so. I can also not think of any extension that does, except templates, of course. So it's all in the views, not models etc. Am I wrong?
Since mobiles have become so important, maybe it would be worth giving it a thought. For J!4, maybe?

Robert G Mears

unread,
Sep 29, 2015, 9:37:16 AM9/29/15
to Joomla! CMS Development
Peter van Westen's advanced module manager allows for specifying whether a module displays dependent on device or operating system, etc:
https://www.nonumber.nl/extensions/advancedmodulemanager

Webdongle Elgnodbew

unread,
Sep 29, 2015, 12:10:16 PM9/29/15
to Joomla! CMS Development
But blog view does that already ?

Leo Lammerink

unread,
Sep 29, 2015, 12:21:17 PM9/29/15
to joomla-...@googlegroups.com
No Kevin, what Russ (Russel Winter, a highly regarded and respected contributor to Joomla over the years)  is giving is an other approach I definitely would support if we could provide such initiative. Please read again what Russ stated and that is definitely not supported at present. Russ suggested and I quote


 "So, on a desktop, we can offer a grid-view, say 3 columns wide containing 15 articles,  but on a tablet the columns auto-magically reduce to 2 columns and say 8 articles, and on phones the columns act as they do today with a single column, but also reduces the number of articles to say 3"

Nice idea Russ! +100 for me though no idea how it could be implemented

Leo
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

Michael Babker

unread,
Sep 29, 2015, 12:59:50 PM9/29/15
to joomla-...@googlegroups.com
For starters we'd need core to be built on a platform that had a more extensible grid system.  Bootstrap 2.3 doesn't have a grid system that you can adapt for different viewports that easily (I really love being able to use "col-sm-10 col-md-8" with Bootstrap 3, you just can't do it in 2.3).

For templates that are Bootstrap 3 based, or using some other framework, one could write plugins adding parameters to the right places with the same style options that already exist in the UI for different viewports based on those frameworks.

Personally, I'm not a fan of having framework specific features so tied into the core component options (this is really where plugins start to shine if we used them effectively), but this is what we have for now.

Robert G Mears

unread,
Sep 29, 2015, 4:59:58 PM9/29/15
to Joomla! CMS Development
Rearranging the layout can be done with CSS and @media (max- or min-width) as shown here: various layouts. (requires registration to view the various pages)

Reducing the number of articles is another matter, although it could be done with modules and using advanced module manager set different modules to display different content dependent on device.

Webdongle Elgnodbew

unread,
Sep 29, 2015, 5:10:31 PM9/29/15
to Joomla! CMS Development
blog.php could have several layouts the one that exists now and one for the phone, tablet etc.  The phone and tablet layouts could ignore the menu item settings and be coded for the number of columns and total Articles etc.  The display of the correct layout to the correct medium (desktop, tablet, phone) controlled by using the hidden-phone, hidden tablet and hidden desktop classes in the correct combination.


On Saturday, 5 September 2015 23:22:35 UTC+1, RussW wrote:

Michael Babker

unread,
Sep 29, 2015, 5:33:41 PM9/29/15
to joomla-...@googlegroups.com
Knowing full well I'm about to get told to STFU because I'm responding as a developer...

Moving forward, we need to decouple style decisions such as number of columns in a layout from the component.  Those need to be template options.  How you do this without alienating that part of the target audience that can barely write "<?php echo 'Hello World!';" means making more efficient use of our plugin system and the layers of overrides that exist throughout the application.  Yes, this means template shops will need to get stronger on their PHP skills and their understanding of some of Joomla's cool features, like extending forms with plugin events or the override API of JHtml, but IMO if we try to move this direction in the end it only improves the ecosystem for everyone.

Picking on those grid options for a moment, they right now only map directly to Bootstrap 2.3 spanX classes.  Which makes sense, Bootstrap 2.3 is the core CSS framework.  What about those folks who are building Bootstrap 3 templates or using another CSS framework altogether?  Those options don't translate over as well.  Enter the plugin approach.  My Bootstrap 3 template framework ships a plugin(s) that enables my framework's design options, to include number of columns to use for the different viewports (I'm gonna get technical and map my options to the extra small, small, medium, and large viewports that Bootstrap offers versus trying to call them mobile, tablet, or desktop; to me that makes more sense and aligns with Bootstrap's documentation or implementation of the grid, as examples).  So I use that plugin to add the options specific to my framework, the user is able to customize these aspects of their layouts still via the backend UI, and we take some options out of places in the system that they don't really belong.  We get better data and responsibility separation without compromising usability, how can we go wrong here?

Jumping to the blog.php example specifically, Kevin you can already do this without changing a line of core code using the layout override system and the API that we have for detecting the active device and you can use that to decide which sub-layout to serve from there.  That alone doesn't address the column issue because like I said the one option that we have now is only really compatible with Bootstrap 2.3, and you see me arguing for not adding more of those types of options directly into the component but rather in a way that they can be altered based on the CSS and template framework in use.

I honestly think we're barely scraping the tip of the iceberg with what can be done with the existing code.  Yes, right now doing some advanced things needs those big bad developers, but once those types of structures start getting released by developers and we have efficient examples in the ecosystem on how you can leverage our existing infrastructure to do some powerful things, we can start to change the game in the frontend department.  The core CMS in itself doesn't need to be able to do everything under the sun, but if we provide the APIs to do these advanced tricks, we give the template developers, the site integrators, and the code purists the power to accomplish a lot of things.

I've made one example of how to use the JHtml override system and shared it - https://github.com/mbabker/bs3-demo - template developers I encourage you to take a look at it, you can improve a lot of things with that approach.  As for the plugin adding more fields, there's an example of that in core already by way of the user profile plugin.  Anyone can use it as an example to build a plugin adding additional fields to any form, the trick is writing code referring to that data later.

--

Troy

unread,
Sep 30, 2015, 12:06:15 PM9/30/15
to joomla-...@googlegroups.com


On 9/29/2015 16:33, Michael Babker wrote:
> Knowing full well I'm about to get told to STFU because I'm responding
> as a developer...
>
ohhhh... the temptation :P

> Moving forward, we need to decouple style decisions such as number of
> columns in a layout from the component. Those need to be template
> options. How you do this without alienating that part of the target
> audience that can barely write "<?php echo 'Hello World!';" means
> making more efficient use of our plugin system and the layers of
> overrides that exist throughout the application. Yes, this means
> template shops will need to get stronger on their PHP skills and their
> understanding of some of Joomla's cool features, like extending forms
> with plugin events or the override API of JHtml, but IMO if we try to
> move this direction in the end it only improves the ecosystem for
> everyone.
>
I would love to sit and hear you lecture in intimate detail about that
someday.

> Picking on those grid options for a moment, they right now only map
> directly to Bootstrap 2.3 spanX classes. Which makes sense, Bootstrap
> 2.3 is the core CSS framework. What about those folks who are
> building Bootstrap 3 templates or using another CSS framework
> altogether? Those options don't translate over as well. Enter the
> plugin approach. My Bootstrap 3 template framework ships a plugin(s)
> that enables my framework's design options, to include number of
> columns to use for the different viewports (I'm gonna get technical
> and map my options to the extra small, small, medium, and large
> viewports that Bootstrap offers versus trying to call them mobile,
> tablet, or desktop; to me that makes more sense and aligns with
> Bootstrap's documentation or implementation of the grid, as
> examples). So I use that plugin to add the options specific to my
> framework, the user is able to customize these aspects of their
> layouts still via the backend UI, and we take some options out of
> places in the system that they don't really belong. We get better
> data and responsibility separation without compromising usability, how
> can we go wrong here?
>
And with BS4 just around the corner all the rules change. It's going to
be an exciting and evolutionary stepping stone I think.

> Jumping to the blog.php example specifically, Kevin you can already do
> this without changing a line of core code using the layout override
> system and the API that we have for detecting the active device and
> you can use that to decide which sub-layout to serve from there. That
> alone doesn't address the column issue because like I said the one
> option that we have now is only really compatible with Bootstrap 2.3,
> and you see me arguing for not adding more of those types of options
> directly into the component but rather in a way that they can be
> altered based on the CSS and template framework in use.

Especially with the PLT(?) decision to make everything a smorgasbord of
parts to make up a single cms install

> I honestly think we're barely scraping the tip of the iceberg with
> what can be done with the existing code. Yes, right now doing some
> advanced things needs those big bad developers, but once those types
> of structures start getting released by developers and we have
> efficient examples in the ecosystem on how you can leverage our
> existing infrastructure to do some powerful things, we can start to
> change the game in the frontend department. The core CMS in itself
> doesn't need to be able to do everything under the sun, but if we
> provide the APIs to do these advanced tricks, we give the template
> developers, the site integrators, and the code purists the power to
> accomplish a lot of things.
>
core needs to have a solid , flexible , generic layout that , for
example, will look good for any blog / simple site layout. Nothing More
Nothing less. Just a great "default" layout. Everything else should
come from the magic of the template dev's minds.

Bear

Michael Babker

unread,
Sep 30, 2015, 12:49:21 PM9/30/15
to joomla-...@googlegroups.com
A component doesn't necessarily *HAVE* to provide layouts.  All layouts are doing is displaying the data retrieved based on the requested URI in the specified format.  Sometimes I think having the default layouts for a component gets us in trouble with mixing template and component decisions in the wrong places.  At the end of the day, those default layouts should ultimately be considered assets of the template (when you write extensions for mass distribution, i.e. JED, do you not design your default layouts around the default core templates for site/admin?).

The CMS has always been a smorgasbord of parts, the thing is we've always treated it as a single entity, which has its pros and cons.  When you look at it as the ~130 individual extensions that it is composed of and try to manage each of those extensions as small pieces in the overall large puzzle, it makes you think of structures much differently, in ways I personally think can only go to improve the overall structure of the application stack and hopefully improves non-code aspects of the product too.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Webdongle Elgnodbew

unread,
Sep 30, 2015, 1:04:17 PM9/30/15
to Joomla! CMS Development
You want to take the default component layouts out of the core files ?  With that logic you might as well take bootstrap 2 out of the core as well.  And while you are at it take the module layouts out as well.  And then what are we left with ?

Michael Babker

unread,
Sep 30, 2015, 1:10:42 PM9/30/15
to joomla-...@googlegroups.com
When did I suggest that?  My comment exactly as written says that a component on its own doesn't have to provide a default layout for its HTML pages.  If someone actually did that, it would cause a lot of errors and annoyance for end users, so it should not be done.  But my approach to extensions right now is that my default layouts are written to implement the core default templates and are not guaranteed to work with any other template.  So I consider /components/com_content/views/article/tmpl/default.php to live at /templates/protostar/html/com_content/article/default.php and that the default layout is "owned" by the Protostar template.  I do not consider the default layout to be a fully agnostic snippet of HTML that can be used by everyone for everything; that is actually what the JView(Legacy) classes are designed to do (fetch a set of data and give it to a layout to convert into output for whatever format).

To post to this group, send email to joomla-...@googlegroups.com.

Russ Winter

unread,
Oct 2, 2015, 5:28:05 PM10/2/15
to joomla-...@googlegroups.com
totally agree with Michael Babker that BS3 (&coming BS4) represents a much better flexible "grid", as for now, I either use BS3 based template design or override a bunch of stuff with calculations/JS to determine screen size and dynamically change the span. In some case, it's also easy enough to do something similar with overrides and some math to change the number of items being displayed to better suit the viewing device, and as for modules, when need I tend to have two of the same module configured for different content item number that display on different viewports.  I just thought specifically for components that make use of the "grid" (ie: com_content) the addition of multiple "grid parameters" for different viewports might not be a bad idea and I wouldn't have thought would have added too much code or changes to existing core. 

Anyhow, was just a thought based on what I do already, manually...


--
Regards,
Russ Winter




Reply all
Reply to author
Forward
0 new messages