I am making a responsive page and need to move a section of content to a different place in the DOM on mobile vs desktop screens.
My current solution is to have the content duplicated in both places but tag one with a show-on-mobile-only media query and the other with a show-on-desktop-only media query.
This is simple and works but I am wondering if there are any potential pitfalls with having some of my content repeated on the page in terms of page load speed, accessibility or SEO. Alternatively, I could try using JS to move the element, but that has its own issues.
I see that this is a similar question, however it did not fully answer my particular concerns.
I'd appreciate your thoughts.
Thanks.
In terms of accessibility, some people have css turned off so then it would still appear twice.
Unless there's a really special reason why you need to have specfic content for different device views, it would be far easier—and much more maintainable—to employ responsive web design (RWD). If you do that, your layouts would be controlled via CSS, and JavaScript would only be needed for items such as responsively served images and mobile menus.
Another added advantage of using RWD is semantic HTML markup, and makes your content much more accessibility—and SEO—compliant. It's good to keep in mind that changing visibility on elements can wreak havoc on screen readers—which can be quite challenging for disabled users.
Related
I realize there’s no one answer to this question, and as always, ‘it depends’. All discussion is welcome, and professional, experience-based input it appreciated!
At what point do you break a component into two components — one for mobile ish sizes, and one for desktop ish sizes, VS having a lot of complex CSS and ‘conditional’ HTML in one component?
I was just making a navbar for a website (exciting!) and the desktop navbar is extremely simple. It can be a dumb functional component. The mobile navbar adds some HTML and child components, resizes, reformats, needs an open/closed state, etc.
For the sake of debugging and maintainability, it seems like mobile is adding too much complexity to the desktop version, and the desktop version doesn’t seem to make sense among the mobile code. It’s just a lot of CSS and HTML in the same file that becomes a little less straightforward with two very different behaviors distracting each other.
But for the sake of performance, components mounting, etc. it would be a sacrifice to break this up into a container header with the two children and add additional work for React.
I'm curious, in your experience, have you encountered this problem before? How have you decided to solve it? Why? At what point do you break it up? Do you prefer the clarity of granular components, or the clarity of having all the CSS and HTML in one spot? Thanks!
Well since you are using React you can easily check if it's mobile or larger then mobile and include either one you require and if you need to have multiple navigations it's better to mount just the one you need.
But again I wonder how come you are adding that many things/items to your navigation on mobile but on desktop you are keeping it so simple?
Isn't the point of navigation that you have everything accessible with one or two clicks?
If such a complex navigation is required on mobile it only makes sense that a bit more complex navigation could be required on desktop as well :)
Don't get me wrong I have been in the same place as you are right now but it all comes back to what do you want your customers to click on?
If the conversion happens on few links only there's no need for a huge complex mobile navigation, just make sure user can access everything they might require.
After all you can easily create a search form that would be able to help you with reducing data required in the navigation on mobile.
Not saying that I love huge navigations on desktop but if it's necessary on mobile I have a feeling it might be on desktop as well.
I am new at html and css and when I increase my browser size my entire layout gets messed up and elements start overlapping one another. Can anyone show me a way to make my layout become responsive? Thank you in advance!
It depends on what you wanna do.
1) If you're learning HTML5 and CSS than you've got to watch towards bootstrap media queries to code fully responsive. To go further you will also need Javascript. There are also paying technologies.
2) If you just wanna make a responsive website without caring about the coding side, you should choose a CMS like Wordpress, Joomla etc... It will be faster for you and with a good responsive template, a very decent solution.
There is a nice tutorial in w3schools that uses we3.css stylesheet framework, very easy to start and see the entire problem. It uses images of different size and adpat itself to pc, tablets, smarthpones. Try it, I mean read, it is a short one, and will help you a lot, can you implement without adding that file, but changing easily yours.
I know you can load in a different CSS sheet with Media Queries, but what if there is a bunch of content and dozens of divs you do not want to show at all on smaller devices. Is there a way just to load in an entirely different set of HTML for very simple mobile pages, when you have a very complex design for larger devices?
One idea will be making the page suitable for small devices, then load extra content with the help of javascript
Try to learn some of Responsible websites. Frameworks like Bootstrap already use what your looking for.
I have coded a very complex php game with around 40 pages. I am now in the process of designing it. Would responsive design be the right choice in this case? What other options are available? Maybe I should just make three layouts (3 different stylesheets - normal, tablets and mobiles)?
It just seems like a ridiculous amount of work moving all these elements since there are so many pages.
Creating a responsive site is not that difficult from the html/css point of view, although I'm not sure how your php will affect that. You actually always have the same classes/ids, and just apply styles to them using the media queries (inside the same sheet). It would mean a lot more effort to write 3 separate sheets, but then again: depends on your code. In general, the trick is just to have good semantic, clean code (use positions wisely, for example). It takes some time to get everything organised at first, but once you have the basics structured with responsiveness in mind it gets really easy. Those 40 pages should all have the same structure, right?
Another option would be a liquid design. Instead of changing the styles, you use percentages or dynamic measures. But I strongly recommend grids, and you only have to do it once and it won't be long until everyone does responsive sites.
But if the game is complex and need some serious tweaking, you should consider doing a completely separate thing for mobile (tablets should be easy enough to adapt, your choice). It really depends on the product design, things can look very different in 320px wide. Good luck with the game!
If the content will be the same on all the devices and you can't think of a good reason to fork the code to provide different content for different devices, responsive design is the way to go.
I'm working on a new web site that currently is configured as a full height (that is, 100% available browser window) application. In terms of layout, it is something like this - http://stevesanderson.github.com/fixed-height-layouts-demo/pane-transitions-tablet.html.
Our web site does nothing with the actual browser window size, like switch browser into full screen mode. It only uses the available space.
Operationally, this is going to be a semi-internal data entry application. Almost all pages are data entry forms or summary pages
Personally, I think makes a very nice looking app. However, some of the other developers are comparing this design with content in scrollable tags to be the same as iFrames. And as such should be avoided.
Is there any background / best practices information about designing a web site this way?
I personally love sites that choose to do this; I think that it's a great way to use up the available real-estate that you have. My one piece of advice would be to add a min-width and a min-height to your page so that you don't have to worry about your site breaking if the browser gets too small. This will not only improve the overall user experience, but will also prevent future headaches when trying to get your design to work in obscure dimensions.
It looks fine, and at first looks more like a 'real' app. The only weirdness with this sort of thing is that on OSX you get a bit of a bouncy effect when you hit the top and bottom because of the rubberbanding on the scroll. If you aren't sure what I mean, grab an iPhone/iPad/Mac and scroll up and down past the top or bottom of the content.
In reality it shouldn't be too hard to enable or disable this feature, so why not start with it, then revaluate once you have gotten going.
There aren't any good practices or background information that I know of on this subject. Just follow the normal rules of thumb, if it looks good, is light and loads well, and it is usable, why not?