1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Responsive websites testing

Discussion in 'HTML & Website Design' started by albemala, May 5, 2020.

  1. #1
    Hi everyone ,

    I'm a web developer, and I've often found myself wasting too much time checking if a responsive website displays properly on all screen sizes.

    I feel we have lots of powerful and advanced applications to design and code websites, but there are very few tools to test and debug the behavior of responsive web pages.
    I guess many of you have found themselves in my shoes before.

    To overcome this problem and make our work easier, I've created slashB, an application that provides a workspace where you can instantly preview a website across multiple screen sizes.
    It also features built-in developer tools, extensions, live reloading, full-page screenshots, and more.

    (If you'd like to read more about it, check this article on my blog)

    I'd love to have your feedback on my new app.

    You can download slashB on its website.

    I am also interested in knowing: what is your N.1 problem when testing or developing websites?
    albemala, May 5, 2020 IP
  2. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    Honestly, I don't have these types of problems due to my process for building and testing websites. It's called progressive enhancement and it's about MORE than just what things look like on any screen at a specific size.

    1) Start out with your content or a reasonable facsimile of future content as if HTML doesn't even exist, and arrange it in a logical structural order in a plain text editor.

    2) Mark up that content with HTML tags to say WHAT THINGS ARE and NOT what you want them to look like. If you choose any of your tags, ID's, or classes based on desired visual appearance, you have utterly and completely missed the POINT of HTML. This is why 99.99% of HTML/CSS frameworks are ignorant, incompetent, inept bullshit made by people unqualified to write a single damned line of markup!

    Since that's the SEMANTIC stage neutral tags like DIV and SPAN do not get added at this point.

    3) Create the desktop screen media layout in an external stylesheet <link>ed into the page with media="screen". This layout should be elastic -- aka built with EM and NOT PX -- and semi-fluid -- having a max-width so that long paragraphs are not hard to follow. If you use fixed widths in your overall design, /FAIL/ at web development. This is the layout stage so things like making it pretty with colouration should wait. Make it work, THEN make it pretty.

    4) narrow the window until it breaks, figure out at how many EM it broke, and use that as your media query breakpoint to re-arrange the layout. Lather, rinse, repeat until you're down to 16em. (256px at small fonts/96dpi/vga/whatever, 384px at large/120dpi/8514/pickADamnedNameAlready)

    5) Now paint your colours, gradients, text-shadows, and so forth onto the layout, and then test them at each of your media query breakpoints.

    6) (optional) make a print stylesheet if needed/desired

    7) Enhance the ALREADY WORKING PAGE with scripting as wanted/desired. If you cannot get past step 5 without JavaScript, you are likely doing something wrong and telling large swaths of users to go screw themselves. Good scripting should enhance the page, not supplant the only means of accessible functionality. This is why when people piss megabytes of scripttardery onto a page, they're shooting their accessibility in the foot. See 99.99% of the garbage people vomit into pages using jQuery, React, Vue.js, etc, etc).

    You follow the above process, you automatically have on-page SEO, and full accessibility across not just the wide variety of desktop and mobile screens, but also for non-visual users! If anything, search engines ARE non-visual users. They could give a flying purple fish about your bloody layouts and presentational graphics!

    Hence the most common mistakes people make in "design" remain:

    1) Illegible Colour Contrasts.

    2) Designing in pixels not EM. If you declare PX in all but a few small corner cases, you've already screwed up.

    3) mixing and matching EM with PX, particularly when it comes to media queries.

    4) Not designing fluid or semi-fluid so that 99%+ of your mobile is already in place.

    5) Failing to leverage semantics so as to not piss all over the place with presentational classes -- defeating the entire point of HTML and why CSS is separate from it. This is where the derpy "frameworks" always end up breaking or making people work harder, not smarter. No matter how many know-nothings parrot the propaganda and make wild unfounded claims about how much "easier" they make things!

    6) Trying to use percentage widths for narrower sub-columns. This is almost ALWAYS a complete /FAIL/. Elastic widths on side-columns with a fluid content column is most always the most versatile and reliable approach.

    7) Designing to specific widths instead of using fluid layout with breakpoints.

    8) Using JavaScript to do things that HTML and CSS can do just fine on their own.

    As a rule of thumb, if you have the problems you outlined, it's the methodology that's at fault.

    Now, as to "slashB" (You're too new to post links) assuming you mean the derpy "let's show a bunch of fixed sizes" browser, that's EXACTLY the type of /fail/ at web development I'm talking about. That's number 7 above. The idea "stop resizing your browser" and instead using specific sizes? Again, /FAIL/ hard.

    It reeks of the type of reliance on a tool to make up for broken, incompetent, nonsensical approaches to design. Something more useful to artists under the DELUSION they are designers, than anyone working in ACTUAL design. Remember, art is not design unto itself. Design is engineering that incorporates art, giving as much care to usability, accessibility, and specifications as it does "ooh, pretty".

    Hence the horrifying train wreck of garbage markup in the GIF on its medium page... or the goofy poorly rendering webfonts and illegible colour contrasts on the .app website.

    In fact, slashb.app is a poster child for what I mean by BAD design and an ignorance of how to build a website properly. If that's your idea of how to design, it's hardly a shock you think you need some stupid "tool" to help you with layout. Again, bootcrap. You really should find a stick to scrape that off with before you go tracking it across the web's carpets.

    Hence such bloated trash as (formatting added):

    <body class="h-full bg-gray-900 font-body text-gray-400 text-base leading-normal tracking-normal">
        <div id="__next">
            <div class="min-h-full flex flex-col">
                <nav class="w-full">
                    <div class="container max-w-screen-lg mx-auto p-4 flex items-center justify-between">
                        <a class="flex items-center" href="/">
                            <div class="mr-2"><img src="/images/logo.svg" alt="App logo" class="border-2 border-gray-700 rounded-full" /></div>
                            <div class="font-heading text-2xl text-white"><em>slashB</em></div>
                        <div class="hidden lg:block">
                            <div class="flex flex-col items-center lg:flex-row"><a class="mb-4 lg:mb-0 lg:mr-8 font-heading text-white hover:underline focus:opacity-60 transition ease-in-out duration-200" href="/#features">Features</a><a class="mb-4 lg:mb-0 lg:mr-8 font-heading text-white hover:underline focus:opacity-60 transition ease-in-out duration-200" href="/#pricing">Pricing</a><a class="mb-4 lg:mb-0 lg:mr-8 font-heading text-white hover:underline focus:opacity-60 transition ease-in-out duration-200" href="/#footer">Support</a><a class="inline-block py-1 px-3 font-heading text-primary border border-primary hover:opacity-80 focus:opacity-60 rounded transition ease-in-out duration-200" href="/#download">Download</a></div>
                        <div class="block lg:hidden">
                                <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" class="fill-current w-6 h-6 text-white">
                                            <rect height="3" width="23" rx="1" ry="1" x=".5" y="2.5"></rect>
                                            <rect height="3" width="23" rx="1" ry="1" x=".5" y="10.5"></rect>
                                            <rect height="3" width="23" rx="1" ry="1" x=".5" y="18.5"></rect>
                <div class="">
                        <section class="mt-16 container max-w-screen-lg mx-auto">
                            <div class="mx-4 px-8 py-6 bg-white rounded-lg">
                                <h3 class="font-heading text-2xl leading-none text-white leading-normal text-gray-600">Subscribe to our newsletter <span class="font-bold text-gray-900">before the <!-- -->20th of May</span><br/>to get a <span class="font-bold text-gray-900">20<!-- -->% off discount</span> coupon</h3>
                                <div class="mt-4">
                                    <p class="text-gray-600">We&#x27;ll also inform you about
                                        <!-- -->slashB
                                        <!-- -->news, tips and tricks. No spam, promise.</p>
                                <div class="mt-4"><a class="inline-block py-2 px-4 font-heading text-white bg-gray-900 hover:opacity-80 focus:opacity-60 rounded transition ease-in-out duration-200" href="http://eepurl.com/gZWNI5" target="_blank">Subscribe and Get <!-- -->20<!-- -->% off</a></div>
    Code (markup):
    Doing the job of:

    	<h1><a href="/">slashB</a></h1>
    	<input type="checkbox" id="toggle_mainMenu" class="toggle" hidden>
    	<label for="toggle_mainMenu"></label>
    		<ul id="mainMenu">
    			<li><a href="/#features">Features</a></li>
    			<li><a href="/#pricing">Pricing</a></li>
    			<li><a href="/#footer">Support</a></li>
    			<li><a href="/#download" class="action">Download</a></li>
    	<section id="subscribe">
    			Subscribe to our newsletter <strong>before the 20th of May</strong> to get a <strong>20% off discount</strong> coupon.
    			We'll also inform you about slashB news, tips and tricks. No spam, promise.
    		>Subscribe and Get 20% off</a>
    	<!-- #subscribe --></section>
    Code (markup):
    What with the gibberish in the original of nonsensical use of a H3, lack of semantic list around a list of choices, lack of a proper page heading on the obvious heading element, presentational graphics in the markup, static style in the markup, and all the other complete failings to utterly understand what HTML is for or how to use it properly. Again, par for the course if you learned to write HTML/CSS using the train wreck laundry list of how NOT to build websites that is bootcrap. Much less if you bought into the bald-faced lies the dirtbag predators who promote its use continue to peddle to rubes and nubes alike.

    Wheretofor the page for this browser is a broken, bloated, inaccessible mess, wasting 40k of minified markup on 2.25k of plaintext and not even a half dozen content images; barely 8k of formatted HTML's flipping job. This goes hand in hand with the blocking scripts in the HEAD, static style in the head, inlined script execution hanging the render, etc, etc... hardly a shock it's wasting around 700k of its own scripting in 14 files (aka not counting GA) and an equally absurd megabyte of CSS in two files on a site that doesn't warrant more than 64k of Scripting and 48k of CSS in one file apiece.

    If that's how you're building sites, OF COURSE you're having difficulties with mobile. You're flipping the bird at accessibility before you even plug content into it.

    See, I don't have these problems building new sites for myself or clients. Where I have problems is when as an accessibility and efficiency consultant I'm called in to fix messes of ignorance, incompetence, and ineptitude like that found on the site for your 'app'.

    No offense, but that's one of those harsh truths you might need to be aware of. If you use 5 times the markup and 50 to 100 times the CSS+JS needed, it should hardly be a shock you're struggling at the most basic of tasks. More so when derpy trash like bootcrap has packed you full of it.
    deathshadow, May 5, 2020 IP
    malky66 likes this.
  3. Web_Dev_Chris

    Web_Dev_Chris Active Member

    Likes Received:
    Best Answers:
    Trophy Points:
    I used a service called browser stack only when required. I suppose it should be designed responsive to start with and you can test on real devices through browser stack. The actual device is deployed and launched in the cloud for you to do your testing. If a client said something like, this doesn't look right on mobile then I would use browser stack.
    Web_Dev_Chris, May 9, 2020 IP