generated from Seekra/repository-template
Mobile-first layout/design #128
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Seekra/frontend#128
Reference in New Issue
Block a user
Mobile-first
Introduction
Today, most of the users use mobile devices. We develop a search engine; so it is extra imporant that the application looks good on mobile devices.
Many people have questions and want a quick answer. They could start up their PC or notebook, enter a user password, open Seekra and type their question or search term. But they also can take their cell phone, easily unlock it with their face or fingerprint, open Seekra and type their question – and often they can even use their voice, which speeds up the process even further. What do most users find more convenient, easier to use, and faster? Mostly the way using the cell phone.
But there is a problem: Screens of mobile devices are always very small. The narrow width, in particular, is a problem for us.
Problem
On a desktop, it is no problem adding an image galery width many images in a row, a wide search bar or a complex layout with many cards, grids, tables etc. But, if you want to display such elements on a cell phone, you will run into some limits. Of course, you can do that – but doing it would result in a sharp drop in the number of users. Would yoe like using a search engine that lets you scroll horizontally?
So, a desktop layout on mobiles would drastically reduce the number of users as most of the devices websites are accessed on are cell phones. Therefore, if we want to reach people, we have to reach cell phones.
Why mobile-first?
To explain why we do not simply develop for desktops first and then adapt it on small screens like mobile devices, here is an example scenario:
Imagine we had a dashboard with a left sidebar with 20 menu items and a main content. The main content contains charts, tables and more, arranged in a grid. If the user focuses a dashboard component, on the right side an area with more detailed information is shown.
This would look perfectly on devices with large screens.
Then comes the hard pard: What do we leave out on smaller screens? How do we fit that onto a cell phone? That would be quite a challenge.
Now, imagine a second scenario: We are developing an application optimized for mobile devices that looks great on them. It would not look bad on desktop computers either. No one would ask, “Is that intentional?”. No one would have to scroll horizontally. Also on large screens, the user would not notice that the app was not optimized for them.
We would not ask what to omit or move on small screens to make the app usable because it would not be without. We would ask what optional elements to add on large screens to make the app more convenient to use on desktops, even if it is not unconvenient to use without. We would not have to do anything to make the app usable at all, but we would be doing something to make the app more convenient to use, since we would not then be faced with the problem of an unusable app.
Which scenario would be more pleasant?
This question is often answered with the first scenario—or is not even asked. This is a very common cause of poor mobile websites.
We should develop a mobile app with a desktop version, not a desktop app with a mobile version.
Despite the many advantages of mobile-first design, this does not, of course—as is so often the case—mean that it is always the right choice. There are applications—such as professional image-editing programs, CAD applications, or developer tools—that are very complex and require large screens; using those on cell phones would be absurd. Therefore, mobile-first design would make no sense.
Solution
Of course, we could develop the application for desktop computers first and then add a mobile design. We would create a complex design that looks optimal on desktops, check whether the device is a phone or a tablet (the corresponding media queries would contain fairly complicated conditions), hide certain elements on certain screen sizes, and so on and so on. Components would be rendered just to be hidden afterward? And on cell phones of all things—which, as we all know, are slow and used by most of the people, as mentioned above?
It is much better to develop the application primarily for cell phones. The optional designs should not be those for mobile devices, but rather those for tablet and desktop computers. We should not hide certain elements if they clutter up the user interface, but show them if they are needed. This is more efficient and natural.
Goals
Revise all layouts so that they primarily are optimized for small screens. Then, add media queries to adapt the layout on larger screens. At the end, the user should notice no difference.