How to Make Any Responsive WordPress Site Mobile-First

Responsive websites and responsive themes are more than a passing fashion. With more and more people using a mobile device to access the internet, responsiveness is now an essential feature of any good website or WordPress theme.

If you check out the WordPress theme repository, you’ll find that the majority or recent themes are responsive. And our WPMU DEV themes are responsive too, meaning they look and work great on any device.

But responsive design has evolved in the seven (yes seven!) years since it was first developed by Ethan Marcotte. Now designing for a variety of screen sizes is about much more than identifying some breakpoints for popular devices and adding them to your stylesheet.

It’s about making your design work for any screen size, so that your breakpoints are based on your layout and not on anticipated screen size. It’s about performance, and ensuring your site is fast on all devices and all connections. And, importantly, it’s about content too – developing content that works on any device and designing around that content, so that the user experience is as good as possible when consuming that content.

Ethan Marcotte's groundbreaking article for A List Apart introduced the world to responsive design.
Ethan Marcotte’s groundbreaking article for A List Apart introduced the world to responsive design.

My favourite method for addressing these challenges is to adopt a mobile first approach, which turns traditional web design on its head. Instead of designing your content and layout for a large screen and then adjusting it to fit smaller screens, you design for small screens first, and then adjust for larger screens. This gives you a number of advantages when it comes to content planning, design and performance, as well as making coding more efficient.

In this post, I’ll outline some of the benefits of the mobile first approach and explain what it consists of in more detail. Then I’ll show you how to go about converting your responsive theme to a mobile first one. I’ll identify the main layout elements in your theme and what you’ll need to do with them to make your theme mobile first.

So let’s get started with an outline of just what the mobile first approach is.

What is Mobile First?

Mobile first is an approach to web design and development developed by Luke Wroblewski in his book Mobile First. It’s about two main things:

  • Rethinking the way you approach web design and development to consider mobile devices first.
  • Writing media queries that work from small screens upwards, not large screens downwards as in straightforward responsive design.


Luke Wroblewski's "Mobile First" is the definitive guide to this approach to web design and development.
Luke Wroblewski’s “Mobile First” is the definitive guide to this approach to web design and development.

So what does this mean in terms of the way you work? Well, rethinking your web design so it’s mobile first involves a few things:

  • Focusing on content and interactions not on details, images and elements that make your site look pretty and fill space.
  • Ditching on-screen elements that are just there because there’s space for them, not because they have a purpose.
  • Designing for user experience – so the design makes it easier for people to consume content rather than just being about looking good.
  • Considering the necessities in terms of content – now that you have a small screen to work with, what do you actually need to put on it?
  • Structuring your content so it’s easy to interact with on a small screen.
  • Being efficient – both the site and the code.

I’m not saying this means your site or theme shouldn’t look good – having an attractive, modern design is important for UX and for creating an impression. But I am saying that mobile first design isn’t just about looks – it’s about interactions, user interactions and efficient use of space too.

Mobile first development also has implications for the way you build themes. The main considerations are:

  • Styling your layout for small screens, assuming content blocks will be full width by default, and then adding media queries targeting larger screens so that the layout adjusts as the screen gets bigger.
  • Sending smaller images to a device by default and replacing these with larger images on larger screens rather than the other way around (WordPress does this for you automatically, yay!).
  • Sending visual elements that are nice to have but not essential to larger screens only – I often do this with sliders, for example.
  • Doing your development and testing on a small screen first and then working up to a larger screen, which may be contrary to what you’re familiar with and indeed most comfortable with.

At first, it’s a bit of a leap, as you have to change the way you think and the way you code. But once you get used to it you’ll find that you don’t have to write so much code and that you create more effective, user-focused designs which are quicker and easier to pull together. And that your themes perform better. What’s not to like?

Why Mobile First Makes Your Code more Efficient

As far as coding is concerned there’s one big benefit to mobile first:

You’ll write less code.

That’s got to be a bonus. But why is that?

Well, think about a responsive theme, with a desktop layout a bit like this graphic:

Desktop layout

I’ve highlighted the elements that have 100% width in blue and the others in white. On a small screen the layout will probably adjust to something like this:

Responsive layout

So the content and sidebar are both getting 100% width.

Now, in order to achieve that you have to write two blocks of code:

  1. The code defining the layout for the content and sidebar in the larger screen, including floats.
  2. A media query adjusting this for smaller screens – setting the width to 100% and removing floats.

Now think about a mobile first approach. You’re starting with a smaller screen, where the width of each element will be 100% by default and it won’t be floated. So you don’t have to write any code defining the width of your content and sidebar as 100% or removing floats. This means that for the layout of those two elements you’ll have to write just much less code:

  1. A small amount of styling for small screens.
  2. A media query adding width and floats for larger screens.

Now, of course, it isn’t quite as simple as that. You’ll have other styling to factor in, such as margins, padding, font sizes and more. But when it comes to the simple layout styling, using a mobile first approach means writing half as much code. And as you’ll see shortly, this also applies to wider elements on the page (the header, navigation and footer for example) which might have max-width applied to them.

So let’s explore how to do it in more detail.

How to Make Your Theme Mobile First

The best way to approach mobile first design and development is from a blank slate. With a new project, you’ll get the full benefits of mobile first, including the fresh approach to design as well as the coding benefits.

But sometimes you’ll have a responsive theme that you want to update and convert to mobile first. How do you go about doing that?

Let’s take an imaginary theme and consider the layout styling it might have already. Here’s our desktop layout again:

Desktop layout

The main elements of this layout will be something like this:

  • header
  • nav.main
  • section.main
    • section.content
    • aside.sidebar
  • footer

The layout styling for this is likely to be something like this:

As the theme is responsive, you’ll also need some media queries for the smaller screen version. There could be a few of these but let’s focus on the one for the smallest screens. This is likely to be something like:

You might choose to structure your CSS differently (or use a pre-processor) but essentially this is what you’ll have. Two blocks of code: one for desktop and one for mobile.

Now let’s take a look at how you convert this to a mobile first layout. Firstly, delete both blocks of code.

Now at the top of your spreadsheet, you can define layout for small screen sizes:

You’ll notice that it’s shorter than the original styling for small screens. This is because you don’t have to undo anything you’ve already created for larger screens.

Now create the media query, this time using min-width instead of max-width:

Look familiar? It should: this is the same styling that you used as the default in your responsive stylesheet. So there isn’t any gain here in terms of the amount of code but there is one in terms of performance: devices with smaller screens will ignore this instead of having to work through it and then override it with elements you added in your responsive media query. Which will give a small performance improvement on mobile devices.

You may have noticed that the max-width value is much higher for the full width elements than the min-width value for the media query, making this line of code redundant for screens sizes of less than 1000px wide. Here’s a challenge for you: try removing that part of the code and adding it to a second media query that targets larger screens.

So that’s how you convert your responsive layout to a mobile first one. There are two steps:

  1. Write the default styling for small screens, which takes a very small amount of code.
  2. Add in a media query using min-width instead of max-width and copy the default styling from your responsive theme to this.

Chances are you’ll have to make some tweaks to get it working perfectly with your layout, and you’ll need to make adjustments for other elements such as navigation, but this is essentially how you do it.

Switching to Mobile First Is Easier Than You Think

The thought of converting your responsive themes to mobile first sounds like a real headache. You’ll have to completely rewrite your stylesheets and start all over again, right?

Wrong. Unless you’re taking advantage of the opportunity to rethink your design as well as your code, then it’s pretty straightforward. If all you want to do is change the same design and layout to a mobile first approach, then you just switch your layout styling around and take out some code you don’t need.

Try this on one of your existing responsive themes now, and it will stand you in good stead for developing mobile first themes from scratch in the future.

Rachel McCollin
Do you code mobile first? Tell us what you think of it in the comments below!

36 Responses

  • The Incredible Code Injector

    Great article! I was so glad when designers began switching to “mobile first” over from “mobile too”. One thing I’d like to note is that it’s helpful to include a method for viewing the “full site”, even on a mobile device. It is very common for websites to force users to view the mobile design from a mobile device, but this is not always desired by the end user. Sometimes you really want the full site. The world of web development is full of these double-edged swords. It’s kind of like how some sites use an endless scroll which keeps loading more articles on a page – this is great unless/until you try to get down to the footer to find the developer section, the design credit, or an API link. I’m just glad there’s no push toward “scrollable first”… ;)

    • New Recruit

      I view the desktop view on mobile for my bank a lot which seems counterintuitive. This is not because the desktop view is easier to use or styled better for mobile at all. The fact is many mobile first sites hide much of the content that users are used to accessing on desktop. This is annoying because I can’t accomplish key tasks I came to the website to accomplish or view information I wanted to see.

      Everything available on desktop should be available on mobile as well. If that’s always the case I can’t see any need for a desktop view on mobile.

      • The Incredible Code Injector

        …many mobile first sites hide much of the content that users are used to accessing on desktop. This is annoying…

        Agree. This is really annoying!

        Everything available on desktop should be available on mobile as well. If that’s always the case I can’t see any need for a desktop view on mobile.

        It would actually be counter-intuitive to have all the desktop content on a mobile version of the site – for one thing, the menus would be too long and deep except on sites with very little content. Also, mobile versions often don’t allow the user to zoom in and out. Both of these things can be detrimental to usability.

  • Flash Drive

    One thing not mentioned in this dialogue is how one the site is responsive to the differences which come about from landscape v portrait orientation.

    Ipads with their high resolution are most frequently used in landscape but also portrait and the same goes with other mobiles. I see far too many mobile sites which do not handle orientation very well.


    • Staff

      Hi David.

      I think orientation is important. How the website appears depends entirely upon the designer. Responsive design is what helps a website adapt to different screens and etc. The orientation of the screen depends on if you have enabled auto rotation on your phone. Again, I must point out that the designer must do proper testing when designing a website.


    • Agreed. This is why it’s important to design for screen width and not for the device – responsive design used to target common devices, while it should be based on how the layout works at different widths. Start with the narrowest then test at wider screen widths and make tweaks as the design starts to look wrong and could do with being in more than one column. This means it doesn’t matter what device someone is using or what orientation they have it in.

      • Site Builder, Child of Zeus

        How exactly does this ‘width’ principle work with a small device screen-width but it has a very high dpi “retina” resolution?

        I get confused with this thought as I’m sure I see tablets and phones pretty much use the ‘mobile’ and ‘tablet’ views by default even though in theory their resolutions (pixel screen width) can in some cases be in excess of a ‘desktop’ screen.

        There must be some sort of screen-size:dpi ratio-scaling happening within the device with such small but hi-dpi displays? Otherwise we’d all be seeing desktop views all the time and the device’s GUI interface font scaling would be tiny in menus/dialogues (e.g. in something like a Windows 10 phone/tablet)

        Ultimately, can we ever really know what width we are designing for?

        • Support Gorilla

          Hello MrArtist!

          Width is always “what it is”. If e.g. smartphone uses 1280×768 pixels screen, it would use that view. The “mobile”, “tablet” is just a “naming convention” but the “width” is what really counts. With “retina” and other high resolution displays you got “a lot of pixels” not because the width is higher but because of a density of matrix. A “small but hi-dpi display” will still be a…. small display :)

          Best regards,

          • Site Builder, Child of Zeus

            I haven’t got a small device with a display larger than a 1920 x 1080 phone so I can’t fully test. Having just checked the breakpoints I see one is at around 1080, so I guess that’s why I always see the single-column view (regardless of orientation) – I just assumed (perhaps too hastily) that something else was making the layout change decision.

            So on a small device with a wider portrait view (e.g an iPad with over approx 1080 pix width), Upfront would always show the desktop view?

  • Site Builder, Child of Zeus

    Any thoughts or comment on how this relates to how Upfront works?

    In Upfront the concept of designing starts with desktop view, altering fields of view (and being able to remove stuff) for tablet and mobile.

    How is Upfront’s CSS structured for that? I assume it’s the other way around than proposed in this article?

    And as mentioned by David above, landscape versus portrait mode is not always well-catered for. I’m sure I’ve seen sites that go wrong when shifted between the two, or, more that I would like to see full desktop view on tablet that has ample resolution in landscape view (or any device that has hi-res).

    Can Upfront deal with any of this? (I haven’t experimented enough to know).

    • Support Star

      Hey there MrArtist,

      hope you’re doing good today! :)

      Upfront supports three different viewports (mobile, tablet and desktop) which can be set separately as you can see in UF docs here:

      You can use different presets for your different elements in these viewports, presets which also cascade, if mobile is not defined tablet will be used for mobile, if tablet is not defined desktop will be used for tablet.

      There are some feedback about UF responsiveness and we should be able to edit the width of any viewport in the future, as for adding additional widths like for mobile landscape or mobile portrait views, that’s also under thought. :)

      Have a good one,

      • Site Builder, Child of Zeus

        Hi Dimitris, thanks for the quick response.

        I appreciate the way Upfront already works, and it’s good to hear of being able to edit widths and orientation of the viewport is under consideration.

        My thought though is that Upfront works against what the principles of what this article is suggesting. Upfront is strictly Desktop-first, and then taking away/adjusting from that in the tablet and mobile views.

        I suppose ultimately it makes little difference but it does make me wonder if designing from the mobile-first point of view initially (in Upfront or other ways) and then adding content for other formats would yield better or more interesting results?

        I can’t quite get my mind around it – designing at first with just mobile in mind (as a first stage) would potentially leave out lots of things/content that one would then have to revisit/redesign for again and again both for tablet or desktop mode?

        It seems easier to design for desktop-first and then take things away for tablet/phones rather than add later? Or am I missing the point with mobile-first?

        As John A. said/suggests in the first comment, even on small devices it’s nice to get the full view at times so that one can get one’s bearings, an overview and context, thus avoiding all this long-single column view that sometimes has to be scrolled forever.

        Is there a way (in Upfront or whatever) one could design for all views on all devices and allow users to switch between them at will? So, I might be reading this article on my phone in mobile-view but would occasionally like to switch to desktop-view to give me an overview for which I could pinch-zoom in/out on at any desired position?

        I’m thinking this should be the next evolutionary stage for responsive design? – I the user/viewer have a flexible choice about how to see and use any given site – I can choose between compact view with simplified content/features hidden or hiding under obscure gesture-moves or icons, or get a full overview context with everything obvious and accessible like Terri says for the bank website/app example.

        I wonder what the web/app world will look like in 10 years?

        • Support Gorilla

          Hi MrArtist!

          Upfront is a tool designed for both pro users and “casual bloggers” and that, in my opinion, forces some solutions. Most people manage/design their sites using desktop/laptop rather then mobile devices even if they use mobile for browsing the web. That means that it’s more “natural” for them to follow “desktop first” approach rather than “mobile first”. If you are a professional designer/developer, then it’s up to you which way you prefer and what you are capable of. However, you are certainly more used to various ways, trends and standards of creating sites. I think in this case we had to go for some “compromise” then. Please take it as my personal opinion though :)

          “It seems easier to design for desktop-first and then take things away…(…) or am I missing the point with mobile-first?”

          I think it is easier to design for desktop and then “take away” some elements (or rather hide them). With mobile first approach the development process is a bit different but the benefit – if done right – is that there might be a huge “resources saving/performance boost”. With desktop-first browser loads and processes “everything” and then hides some parts. With mobile-first, it only renders what should be rendered on a given screen and then adds elements if necessary.

          “Is there a way (in Upfront or whatever) one could design for all views on all devices and allow users to switch between them at will? ”

          There’s no “view switch” implemented but that sounds like a very handy feature. I think you may want to post a feature idea on our “Features and Feedback” forum then. If other members of our community will find that useful, I’m sure we can think of adding it to one of the future releases :)

          “I wonder what the web/app world will look like in 10 years?”

          I’m wondering about that too, quite often. For sure, it will be very different to what we got today but what direction would it go? I guess we can only wait and see… :)

          Have a great day!

          • Site Builder, Child of Zeus

            Thanks Adam :-)

            I’ll try and get around to suggesting a “View-switch” on ‘Features & Feedback’ soon. Or maybe to evolve the idea further as a “View-slider” or “View-Xpandr” !

            An interesting point you made about the resources usage savings for mobile-first. While I was vaguely aware there would be some savings in script download size (e.g. html, css, etc), I didn’t think it would make much difference but are you saying also that any mobile/tablet hidden larger resources (e.g. images) also get called and processed even if set not to show on that phone/tablet?

            And then again, I assume only small/lo-res “mobile” images are called rather than the desktop size ones? I think and hope WP itself already does this but would hate to think of all hidden images and hi-res ones being processed on small devices.

            I’m looking forward to where the next ten years of web future will take us. Having observed, used and participated in how it’s been created for about 25 years, we are nearly there with DTP style WYSIWYG precision designing for Web, but somehow still with a few niggles. For a long time, we have been reinventing the wheel – from leaflet/page/TV experiences to the truly digital versions of each.


          • Support Gorilla

            Hi MrArtist!

            “While I was vaguely aware there would be some savings in script download size (e.g. html, css, etc), I didn’t think it would make much difference but are you saying also that any mobile/tablet hidden larger resources (e.g. images) also get called and processed even if set not to show on that phone/tablet?”

            With “desktop-first” approach you design and develop site for desktop and then add media queries that hide and/or re-position and resize some selected elements. The general “flow’ is that browser is fetching all resources that make the site, then renders them (though invisibly for you, usually) the way it would render on desktop and then additionally hides/resizes/moves selected elements for mobile screens.

            With “mobile-first” approach (again: if done right) browser also fetches everything it’s served but then renders and positions elements that are within defined “view port” – it’s mostly the matter of carefully “crafted” media queries.

            There are also ways to affect that process even more by a) using browser side scripts that detect device and fetch some specific resources b) using server-side solution that serve only selected resources based on e.g. user-agent string (or, broadly understood, browser/OS identification). That’s a whole different story though :)

            Best regards,

          • Site Builder, Child of Zeus

            So, in Upfront (or any other WP ‘desktop-first’ page builder) where a tablet/mobile view is subtractively created, when a site is viewed on a phone, does the phone’s browser call the resources for the desktop version of EVERYTHING (including “hidden” items and hi-res-versions of images), then recollect the smaller image/resource versions and then disregard hidden items?

            I hope not.

            It would seem daft to pointlessly download what’s not needed on a mobile device, hence perhaps why mobile-first design is such a good idea (but otherwise, using Upfront or similar desktop-first design solutions would have to be considered as a necessary compromise)?

            I’d forgotten about, but now recall “user-agent strings”. Hopefully we don’t have to go down that road. From what I think I know about them, their correct detection can be open to (changeable) inconsistencies which can reported as anything so cannot be relied on to be useful? (I may have that wrong)

          • Support Gorilla

            Hey MrArtist!

            “So, in Upfront (or any other WP ‘desktop-first’ page builder) where a tablet/mobile view is subtractively created, when a site is viewed on a phone, does the phone’s browser call the resources for the desktop version of EVERYTHING (including “hidden” items and hi-res-versions of images), then recollect the smaller image/resource versions and then disregard hidden items?”

            No, I should be more specific :) By “everything” I mean only “everything that is used on site” – in a sense that e.g. image is present in HTML markup. It doesn’t however mean that if you put a WP thumbnail-sized image in your post, all other sizes of that image will be fetched. If they are not included in HTML/CSS markup, they won’t be.


          • Site Builder, Child of Zeus

            Okay Adam – I think I get the point but I think we are slightly talking at crossed purposes.

            So, in essence, what actually happens is that Upfront will first load the full desktop HTML/CSS markup (because of its desktop-first construction), then if on a phone’s browser it will see/realise it needs (additionally or only) the markup for that viewport and only then call the required (scaled) resources as dished out by WP’s default ability.

            So the only extra downloading required on a mobile device is maybe only a few more lines of code rather than anything we really need to worry about. Therefore no big deal about mobile or desktop first?

          • Support Gorilla

            Hello MrArtist!

            I was talking more of a “general principle” rather than Upfront so I’m sorry if it got you confused.

            Upfront actually is a “different animal” as the site content is build dynamically so it’s fetching resources “on the go” – those that it needs. It’s a complex code and I’m not that familiar with the “code side” of Upfront to be able to give you more details on it but I would agree with what you say that “the only extra downloading required on a mobile device is maybe only a few more lines of code rather than anything we really need to worry about” in that case :)

            And we are also constantly developing it (including performance-related factors) so it gets better and better :)

            Have a nice day!

  • Flash Drive

    As I see it the approach needs to be not mobile or desktop first but a design that follows this sequence:
    of determinations:
    Current Window size Vertical & Horizontal
    Maximum window size
    Available resolution
    Orientation capabilities
    Touch available/unavailable
    Multiple Monitor availability
    The page can then configured to respond accordingly including giving the user an awareness of the benefits available by presenting a choice of viewing opportunities.

    I think focusing on desktop versus mobile is a poor starting point for meeting an increasingly complex set of choices. It is necessary to remember that screen sharing is an increasing common place. This means auto control of presentation without end user control of presentation preferences is not going to be a preferred route for much longer.

    In consequence I now believe we will soon need an additional protocol to communicate client presentation preferences to a responsive server!

    My 2 pennorth

    • Site Builder, Child of Zeus

      “….we will soon need an additional protocol to communicate client presentation preferences…”

      I think you’re right. Or at least this whole mobile or desktop-first concept needs a rethink. We need an easy way to choose, adjust or adapt what we see as an end result no matter what device we are viewing on.

      I get a bit fed up with the whole way we have to use, view or design with a ‘lowest common denominator’ approach in mind which sometimes creates a web that is like trying to ride the super-highway in a flashy super fast car on a small country road in a traffic jam with all options, turnings and road signs hidden under obscure functions and diversions.

      My (desktop) browser window is usually open on a large hi-res 30″ monitor but most of the time much of my screen real estate is wasted. Looking at this WPMUdev page where if I was working in DTP, a word-processor doc or PDF, I could at least use a two or multi-page view to see and do more.

      The current way of predefining a set of CSS layout breakpoints is in some ways very arbitrary and doesn’t seem to bear any relation to the abilities of ‘retina’ resolutions on small devices, let alone the whole portrait/landscape issue.

      The web and web-layout/design has come a long way, but there are these few types of niggles to still resolve. Personally, I don’t mind seeing a whole miniature “desktop” page on my phone/tablet and zooming/panning all around to read/view/consume/use content in my own chosen viewport window. It provides a way much like a newspaper or magazine to scan around, get context, and choose what I want to selectively read or view in more detail.

      Do we really need all our content streamed and dished out in simplified, large, app-style, long, vertically scrollable and linear lists? Maybe the web should be mobile-last?

  • Flash Drive

    MrArtist said:
    “Or at least this whole mobile or desktop-first concept needs a rethink. We need an easy way to choose, adjust or adapt what we see as an end result no matter what device we are viewing on.”

    It seems we are of one mind on this – the future of the web is IMO a dramatic switch from designer/server determined mapping of end-user perceptions to an end-user/client architecture with open ended interaction tools managed within a client presentation preference system. Such an approach would enable end-users to correlate multi-sourced data gathering and correlation.

    Such an approach would IMHO facilitate the development of a highly interactive model for future web development. This means focusing on providing end-users with the tools necessary to make use of the web. The existing model is designed to deliver data in a form which we, as data providers and designers, may mistakenly believe is in our own best interests. Web sites needs, again IMHO, to become a distinctive part of social media rather than a medium imbued with a approach which in so many ways appears to stem from an outdated marketing/advertising model where the media owner determines the message and keeps a fierce control over its presentation.

    Maybe am am a bit radical — but that is my two pennorth

  • Flash Drive

    Some here has just said I should illustrate the approach in a little more detail.

    I am envisaging a protocol that for starters:

    1. Recognises end-user ownership of end-user monitor(s) space
    2. That defines a web page as a collection of containers each of which may be undocked and dragged to any location by the end-user within end-user monitor(s) space.
    3. That enables each container’s presentation to be managed in accordance with end-user presentation preference protocol.
    4. That enables end-user to close any combination of web pages & containers whilst still retaining undocked elements within end-user monitor space.
    5. That enables end-user monitor space to be populated with containers from multiple websites “the Collection”).
    6. That facilitates Collection sharing, redistribution and interactive responses the all stake-holders.
    7. That enables all stakeholders to select Container elements and review the original web source.

    Hopefully this will put some practical flesh on the bones of my previous comments


    • Site Builder, Child of Zeus

      I’m not sure I completely follow your eight-point list in relation to how we can evolve or forget mobile/desktop-first arguments – it sounds impressive but also like you’re describing Win8/10’s Metro/Modern interface with draggable iconic representations of different web-spaces within a Start screen/menu? A bit like Star Trek NG control panel representations perhaps? – Arm phaser banks in the plasma conduit anyone? – Make it so!

      When I saw the initial modular MS Metro ideas initially being discussed I was keen to see how it would evolve but my experiences of the implementations of that modular ‘cloud’ approach since have not encouraged me to ‘downgrade’ to it from Win7. I don’t feel the need to be part of that MS cloud-cuckoo-land.

      However, as you say, no bad thing if we can (easily) adapt the web/app-world to our own viewing perspective/needs but is what you’re saying requiring a lot of user/client thought just to configure/adjust ‘our’ view in an ever changing content world?

      I’m thinking we need something more like Google Maps/Earth where one can almost seamlessly transition between various types of view, whether it be map, photo or 3D fly-by close-up views, by zooming in/out, rotating, etc., by changing an option or two – the display magically transitioning from one type of view to another according to what the user does/wants.

      Give me that for any website/app and then we’ll have something that works for all of the people all of the time on all of the devices.

  • Flash Drive

    I have real sympathy for what you say but IMHO it does not address the social media deficit of the traditional approach to website design. Maybe I should try harder to convince you of end-user viability???

    Users are, after all, quite accustomed to undocking and moving elements. Why should not web site elements be undockable. They are also accustomed to scaling by corner /edge dragging techniques. There is no reason why that facility could not be attached to undocked elements. Once undocked elements have been assembled on screen and moved/scaled to meet need a slection tool could be used to create the final collection and identify the collection with a url for sharing.

    As I see it such an approach dramatically changes the web from a rather static old school set of unmanageable (from the user`s perspective) to a dynamic social media orientated tool.


    • Site Builder, Child of Zeus

      You don’t need to convince me about what you are suggesting, I like the idea of what you propose, but on a site by site specific level, for an individual designer of a site, it sounds off track to be contemplating a wider modular approach that binds the multiple parts of the web into one thing.

      As you say, perhaps as a browser feature/addon or a new protocol to web/browser standards so that we as users and designers can, on a modular site-level, do something as simple as make columns of text and pictures responsively scale and reflow without transitioning to a set of arbitrarily defined viewports designed to simplify (dumbed-down/obscure/hidden) app-style narrow views of the web-world.

Comments are closed.