Content-first concept of mobile products design

Well-known Web designer Andy Clarke recently released 320 and up, a branch of the open-source rapid development template Mobile Boilerplate. This is in contrast to his earlier media queries, which started with the development of small screen styles and layers of collections under larger-width styles, rather than beginning with the ability to crop large-width styles for smaller screens.

This is definitely the best way to take advantage of a particular width style, combined with media queries or JavaScript. But when I see the pixel values ​​for the width of a particular device, I'm a bit nervous: 320 * 480, and so on. This is certainly an improvement over relying on a hypothetical width, such as 960 pixels. But what I'm worried about is that this is still just a matter of matching the now popular display window and simply piling up the display. This is what Mark calls the "canvas in" approach:

"I believe that in order to cater to the needs of homepage layout (regardless of device), we have to start with the layout and then think about our content ideas, and what we really need is actually the content layout in turn.

Nowadays, it's possible that your content is pixel-based (images or video) and their dimensions fit exactly the size of the display window for a particular device. However, in my experience, most of the content to be processed still belongs to the literal class. But the pixel is not the best unit to handle the text. This is one of the reasons I prefer to use em-based media queries.

My basic point is that media queries should serve content. Some sites may be suitable for applying a linear layout to a small screen, while a pillar layout is applied to the screen of a larger device, such as a tablet. For other sites, even a tablet-sized screen, the linear layout is more suitable. It all depends on the content.

One of my favorite examples of content priority is Dan's article type-inspired interfaces. I think web designers have a common understanding that design should be content first, but we are now overly dependent on canvas-like tools, such as certain predefined grids. Similarly, in the area of ​​frameworks and information architecture, when we need to focus on content, we often unconsciously design menus and navigation interfaces first.

Here is a recent remark by Luke to Jared, the author of "Mobile Priorities," which mentions his design principle of "content first, navigation second."

Luke was once widely known as a way to promote mobile first to Internet developers. This method is really useful when it comes to discovering what's important to push to users. But not too absolute, sometimes this method is also equivalent to print-stylesheet first, or some sort of "non-desktop environment first" strategy. The key to proper application is whether you're thinking about the content first and foremost:

"When screen space is occupied 80% of the time, you are forced to notice that the screen that stays on the screen should be the most important set of features for your users or your business, not a bunch of interface shards, or unwanted You should be clear what is most important. "

But that's not to say that you can not put something that is less relevant but pretty good on the screen. But this should be added to the part that may need some kind of delay to load, rather than brainstorm information like kitchen sinks into the start interface.

Mobile page design, there have been a series of very good model design. However, the traditional desktop web design has become synonymous with lifeless and smug. This resulted in a bunch of sites filled with obsolete boring content, as exemplified by Merlin's Flickr album Noise to Noise Ratio:
Of course, there are some very good original content, though hidden in a bunch of ads, self-service links and additional news. "

Right, then look in the picture. Responsible to say that there is "really" useful content, is not it?

There is a little consensus that mobile users can not fool. It should be as fast as possible to those users who are always in a hurry. But its corollary may not be true. Why do we think desktop users are more able to endure so much unwanted content?

Unnecessary page redundancy is generally seen as the destruction of the page, users can use Readability, Safari's Reader and Instapaper and other tools to bypass them. These tools exist, on the one hand, to free up content from having a single endpoint and, on the other hand, to liberate useful content from abusive page containers. This is not a new phenomenon, of course, before the advent of RSS we are browsing information. However, these reading aids should also serve as a warning or challenge to us. How can we host the content so annoyingly that a user has to resort to Readability or Instapaper.

Designers of bloated pages (often fragmented designs) have an additional mobile version of the site (usually the new site) when designing the site, usually the naming of "m. Subdomains." In this version, the content is not presented in a dull, redundant, paged manner in the desktop version. I noticed that when sharing links with tools such as Twitter or email, users usually share this concise version of m. The widening impact of these sites, simply because they are more readable, is true on any platform.

We've read it before, just as I said Paul in the comment Paul's misguided post on mobile design:

"In the past, it was not unusual for users of screen-reading habits to design standalone, text-only sites that were used to reading screens, which did subdivide users, but obviously this is just the trickery." Now that we know the habit Users of screen readers should also enjoy the same content services as the other, provided that the site should be built in the right way (interestingly, some sites noticed that "traditional" non-screen readers also tended to be faster and more concise site versions , This should be a good lesson for designers who still think desktops and mobile sites are totally different.) "

There is no doubt that I totally disagree with the proclamation from Jakob Nielsen:

"The desktop computer and the mobile device are completely different, and the only one that gives users a good experience is to design two separate versions of a product, which, of course, will generally be less mobile."

I was confused and wondered why the site was so challenged by the simplicity of usability that designers wanted to design a separate version that would make it almost unbearable for everyone without this version. Note that I do not imply that every user gets the same experience, which is far from the case. But thanks to progressive enhancement design, which is a perfect application for a progressive approach to responsive design, we can provide what users need and display it on the best of any device.
So this is the key to something different: content is priority, not device.

This is an exciting time for web design. The growing variety of devices directly reveals how self-righteous and diametrically opposed our otherwise traditional, fixed-size, and content-centric desktop design. Like any change in the face of the same, there will always be a bit nervous and nervous. Developers are hurrying to discover the changes and benefits that mobile devices bring to us:

"Should I learn Objective-C?"

"Should I have HTML5?"

"Should I learn to move the App architecture?"

You may be doing such a thing. However, keep in mind the content strategy.

Author: Jeremy Keith. The author is a well-known web developer, author, working life in Brighton, UK. Written on April 27, 2011.

Source: Web App Trend