Author
Topic: Maybe in our world there lives a happy little responsive Curve2 over there (Read 97682 times)

Hello,I am going to explain what is coming up with SMF 2.1 and Curve2 the new default theme.

What Is Responsive Design?Responsive design allows users to navigate the site more easily with their mobile devices. The site adapts itself base on device’s resolution and uses defined CSS rules.

Why Responsive?The main reason is responsive design uses CSS and it doesn't require in-depth template changes, This makes it easier to adapt to mods and custom edits. Since our user base likes (as well as us) customizing their forums, responsive design will not make it harder for them. Even mobile themes are more flexible but they brings support / modification issues with them. That was the reason why we chose responsive design over mobile theme.

This design is in its very early stages and many more adjustment will be made. Please see the screenshots for further information.

The main reason is responsive design uses CSS and it doesn't require in-depth template changes. This makes it easier to adapt to mods and custom edits. Since our user base likes (as well as us) customizing their forums, responsive design will not make it harder for them.

Well, I can't necessarily agree with that. It depends on what they want to do. If they only want to do very basic customisation then sure, it probably wont make it harder.

The more customisation they want to do, the harder it will get, simply because responsive means more CSS and more complex CSS that requires a lot more testing to get it to work consistently (as I'm sure you're already finding out ).

However, if people want something that will work on all devices, they're pretty much stuck with dealing with more complex coding. You don't get something for nothing.

Quote

Even mobile themes are more flexible but they brings support / modification issues with them. That was the reason why we chose responsive design over mobile theme.

I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

In some ways, pure CSS responsive is the least efficient way of dealing with the problem. A lot of people probably don't realise this, because they just see the latest buzz word and think it must be awesome. Like anything else, it's a trade-off. Rather than thinking of responsive as the best way of handlng things, it's probably more accurate to think of it as the least bad way.

If there was simple and reliable detection available, not via media queries (which are limited in application) but by another method, then it would make sense to use this to drop unwanted content via PHP conditionals. This would reduce the amount of CSS required, and reduce the amount of unwanted HTML and javascript that mobiles had to process.

The problem is that due to the piecemeal way in which every manufacturer does their own thing, there is no simple and reliable way of automatically detecting all devices and using that to apply PHP conditionals. IOW, we're still stuck with the age-old problem of coding for the web: lack of consistent and useful standards support. Hey ho.

I don't have anything to say all valid and unfortunately we have to accept some of the facts if we (and yea we did ) are going to use responsive design, Mobile themes are FASTER indeed because you detect the device via PHP and you can tell theme/source what to output, not just a display:none tricks...

Simplifying the Curve2 is other thing we are trying now like merging some parts into one (#1471 & #1477).

I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

RWD does not mean to hide or show content in relation of the devices viewport. It means to present always the complete stuff in a different way on different viewports. Realizing this makes your statements effectively meaningless.

I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

RWD does not mean to hide or show content in relation of the devices viewport. It means to present always the complete stuff in a different way on different viewports. Realizing this makes your statements effectively meaningless.

When you've coded an entire forum interface yourself, then you can start lecturing people on what it entails. You seem to have missed that the OP agrees with me. There's a reason for that.

I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

RWD does not mean to hide or show content in relation of the devices viewport. It means to present always the complete stuff in a different way on different viewports. Realizing this makes your statements effectively meaningless.

That has to be the point, but the thing is forum software showing lots of lots of data to their users beside all that customizations adds extra data to users, as for core people we need to think all sides of it. For example I hide the user info part (where shows avatar/user-title/custom profile fields etc...), surely i can hide things one by one or show some of them but with some customization or adding some extra custom fields to your site, makes it look broken which we don't want to see it.

@Alex@ it would be better if you open a new topic about it Seems good, but the problem here we don't want to load another jQ Library to system. We may/not (its up to our development team) include new library(ies) to SMF in next versions (soon to talk about it).

That has to be the point, but the thing is forum software showing lots of lots of data to their users beside all that customizations adds extra data to users, as for core people we need to think all sides of it.

I know about the complexity of transforming SMFs Curve theme into RWD. Really! I tried it by myself. But at some point I realized that the SMF 2.0 Curve theme is not very easy to convert and so I lost the motivation to complete it.

For example I hide the user info part (where shows avatar/user-title/custom profile fields etc...), surely i can hide things one by one or show some of them but with some customization or adding some extra custom fields to your site, makes it look broken which we don't want to see it.

Do you hide the data completly or do you make it displayable by hover/click?

For example I hide the user info part (where shows avatar/user-title/custom profile fields etc...), surely i can hide things one by one or show some of them but with some customization or adding some extra custom fields to your site, makes it look broken which we don't want to see it.

Do you hide the data completly or do you make it displayable by hover/click?

At this point I'm hiding it completely, but its very early stages, I'm trying to make the main content visible clearly, i probably add some more jQuery-Toggle to some places so users can tap to see extra info, but still I think I'll hide some data from users completely. Because without complete rewrite of the theme its impossible to show everything, Curve and/or Curve2 didn't design for responsiveness. I think i can say this, you can't expect a complete responsiveness from Curve2 at this point.

It takes more than that to offend me. I was just amused at what I saw as your idealistic but impractical views.

The thing is that on desktop people expect a lot of stuff filling up the interface. Most of this is arguably useless even on desktop, but people have come to expect it and want it. You could add stacks of toggles and the js to run them and all sorts of other crud, just to make all the useless stuff usable on a phone, but really people on phones don't want it anyway. This means simply hiding it becomes the best option (IMO, feel free to argue).

And (again IMO) the problem with frameworks is that they invariably introduce yet more bloat. This can lead to problems too.

It takes more than that to offend me. I was just amused at what I saw as your idealistic but impractical views.

It's not idealistic. It's reality. I mean it for sure. Hiding content of one and the same system only because of uisng a different displaydevice is simply bad. Maybe you got me wrong in what I mean about content. It is not the fancy coloured theme or a toggleable header. It's about informations and the ways to get them.

The thing is that on desktop people expect a lot of stuff filling up the interface. Most of this is arguably useless even on desktop, but people have come to expect it and want it. You could add stacks of toggles and the js to run them and all sorts of other crud, just to make all the useless stuff usable on a phone, but really people on phones don't want it anyway. This means simply hiding it becomes the best option (IMO, feel free to argue).

@Alex@ it would be better if you open a new topic about itSeems good, but the problem here we don't want to load another jQ Library to system. We may/not (its up to our development team) include new library(ies) to SMF in next versions (soon to talk about it).

You only have to load what's nessescary to the theme itself. No big deal, really.

It's not idealistic. It's reality. I mean it for sure. Hiding content of one and the same system only because of uisng a different displaydevice is simply bad. Maybe you got me wrong in what I mean about content. It is not the fancy coloured theme or a toggleable header. It's about informations and the ways to get them.

I knew what you meant. My point is that a lot of the information on the desktop interface is useless, IMO. It's not worth the code to run it, and I often ditch or hide a fair amount of it on custom themes, even for desktop. There's such a thing as feeding people too much information. However, people tend to expect to see things just because they've always been there, regardless of whether they're useless or not. My 2c is these things are even less likely to be worth the code on a phone, so why make the code twice as complicated?

Quote

What is the conclusion of this? Tapatalk.

Well, some people seem to love Tapatalk. Takes all sorts. But no, the logical conclusion is to give people enough tools to do the job they want to do, and no more than that.

Quote

Bloat, bloat, bloat. Did you ever try the customizer for BS? And what problems do you mean?

Nope, have no idea what the customiser for BS is. Bloat is a problem in itself, because it makes things more complicated to code and is slower to run. I like clean code.

It takes more than that to offend me. I was just amused at what I saw as your idealistic but impractical views.

The thing is that on desktop people expect a lot of stuff filling up the interface. Most of this is arguably useless even on desktop, but people have come to expect it and want it. You could add stacks of toggles and the js to run them and all sorts of other crud, just to make all the useless stuff usable on a phone, but really people on phones don't want it anyway. This means simply hiding it becomes the best option (IMO, feel free to argue).

And (again IMO) the problem with frameworks is that they invariably introduce yet more bloat. This can lead to problems too.

Heh ^^, I want to keep the view on mobile simple as well but feedbacks on beta shapes it and I'll change things based on user request at this time.

It's not idealistic. It's reality. I mean it for sure. Hiding content of one and the same system only because of uisng a different displaydevice is simply bad. Maybe you got me wrong in what I mean about content. It is not the fancy coloured theme or a toggleable header. It's about informations and the ways to get them.

I knew what you meant. My point is that a lot of the information on the desktop interface is useless, IMO. It's not worth the code to run it, and I often ditch or hide a fair amount of it on custom themes, even for desktop. There's such a thing as feeding people too much information. However, people tend to expect to see things just because they've always been there, regardless of whether they're useless or not. My 2c is these things are even less likely to be worth the code on a phone, so why make the code twice as complicated?

Lets say different approaches here, @Tekkla I'm not sure if you were around or tested the earlier builds of SMF2.1, it had the user-drop menu (hover the nickname) & we were hiding lots of data on desktop view as well. That raised concern some and we revert back to our normal systematic (surely that also upset some people).

However, people tend to expect to see things just because they've always been there, regardless of whether they're useless or not. My 2c is these things are even less likely to be worth the code on a phone, so why make the code twice as complicated?

Bloat is a problem in itself, because it makes things more complicated to code and is slower to run. I like clean code.

Clean isn't only small code. It's also should be readable and reusable within and outside of the scope it was created for. I know that this can and does not fit for each line of code you create. After many years of "unbloated" and "individual" coding and styling I startet to use different frameworks for my work. And what can I say? All my work, my "professional" approach in keeping things simple and clean, was pretty much work someone else already did better and in a way which is much more reusable than anything else I created. So I asked myself: Why reinvent the wheel again and again?

No, I didn't consider using grid system, we want to keep it simple - I don't want to turn SMF's CSS into Bootstrap like framework. That can only be happening if we decide to build a core (like smCore) for our eco-system.

Clean isn't only small code. It's also should be readable and reusable within and outside of the scope it was created for.

Where did I say it shouldn't be? Why would I want code to be clean, if not to make it readable and useable? I'm all in favour of heavily commenting CSS, and minifying it before it's sent to the browser.