Optimizing for mobile: it ain’t rocket science
- Jun 15th, 2013
- Add a comment
Responsive rockets. Would’t that be great? Well, let me tell you: they already are and always have been. The reason for that is simple: they adapt to their context, just as a responsive website responds to their context being the viewport’s size.
When ascending, the rocket’s context is the Earths’ atmosphere along with the gravitational forces. This is then the reason it needs huge boosters to accelerate to overcome these. When it reaches outer space, the propellant has been used and rocket will reject its boosters (Stage 1 separation) as these are then redundant and only are a drawback. The rocket then continues propelling itself using the smaller boosters of the next stage and so forth. This is all illustrated in the following figure:
The way the stages are separated is carefully designed and so should that be the case for responsive websites in my regard. I’m not alone in this and many resources can be found on ‘progressive enhancement’. To find out how to go about the workflow for such processes, we can again look towards to the aerospace industry; it ain’t rocket science, but lot’s can be learned from it.
To start off, let’s look at the definition of so-called ‘Engineering Design’, the equivalent of the workflow of a website’s design process in an engineering environment (notice the emphasis):
The process of devising a system, component, or process to meet desired needs. It is a decision-making process (often iterative) in which the basic science, mathematics and engineering sciences are applied to convert resources optimally to meet a stated objective
For a better way of structuring our process, we can learn lots from the aerospace industry. A general scheme is shown below:
In the following 5 subsections I will elaborate upon the different steps as shown in the previous figure. Hereby note that ‘designing’ is more than just sketching and Photoshop, but the entire thought process around it. The term ‘manufacturing’ is here coherent to building the actual website.
In this phase requirements are set for the project and used to iterate upon when designing the website. As this is the conceptual phase, sketches and wire-frames are the tools of use rather than in-dept designs. However, the most creative contributions to the design process are made in this phase through brainstorming and collaboration to then converge to feasible solutions that meet the requirements from a wide range of diverged mere ideas. All of these ideas – though – are based upon certain requirements and/or budgets that are set during the beginning of this phase and fine-tuned as time progresses.
Through experience and (perhaps) statistics, one will set reasonable requirements along with their corresponding magnitude. Questions such as: “What drives the design?”, “What or how will it look like?” and “Will it meet the requirements?” are ones that will reappear many times (and not only in this phase), especially as the process is extremely fluid. Regarding the requirements, one can think of the following (in no particular order):
Side note: Use realistic values with the thought in mind that requirements for e.g. costs or performance may not be met. However, multiplying the values with a certain ‘safety factor’ will not lead to better results as people will use these values as a guide-line and likely end up with even larger values.
Just as different materials are used for various components in engineering, there are multiple ways to achieve the same result in webdesign/-development. One can argue that a certain composite polymer such as CFRP (carbon-fibre) is the best performing material for a certain job, however it comes with a cost and its disadvantages. An outcome where an Aluminium-alloy is used instead, is then fairly possible provided it is rightly justified.
We are at a stage where the design and development phases are intertwined as the one has consequences for the other. When, for example, it has been brought up to use a carousel – yes, there is still a use case for them – it should automatically be linked to its impact in terms of performance. Consider yourself in Laura’s place and think if it’s worth the impact.
I might start devving all sites from a 3G dongle. It might cost a fortune, but boy does it make me performance-aware…
— Laura Kalbag (@laurakalbag) May 9, 2013
When doing such trade-offs for multiple aspects, creating trade-off matrices is one of the tools to compare different approaches and to justify choices. It could very well be that a great idea will not be implemented due to constraints set earlier.
As most decisions have been made regarding features et al. in the previous phase, this step basically is an elaboration on that. Development is likely to be started upon less detailed designs and updated through an iterative process.
There are many ways in order to optimize you website code-wise. There are more and more resources becoming available that explain best-practices and more in-dept analyses of various ways. I’d suggest reading Smashing Magazine’s ‘The Mobile Book’, follow blogs such as Web Performance Today and check out various resources.
Many know the below video of Ilya Grigorik, but if you are not common with it I’d highly recommend watching it for a better understanding of how (mobile) networks work, pagespeeds and more.
Keep the performance-focused practices in mind as you code the website, based upon choices in the previous steps. Performance should not be seen as an after-market feature, but treated as one that is at the core of the development process.
As a target audience with a range of devices is set in the conceptual phase, it is a necessity to test it as well. A more and more used concept are Open Device Labs (ODLs), but an in-house range of devices in the larger firms are not at all uncommon. Additionally there are services such as DeviceAnywhere, that allow you to – as the name suggests – remotely test various devices anywhere.
— Pixels & Paper (@Pixels_Paper) January 30, 2013
Not only does testing mean device testing, but also user testing. This can be done through real user testing i.e. setting up a lab and/or visiting (potential) users, or can be remotely done through services such as usertesting.com.
As this is, too, an iterative process, testing will intertwine with the ‘manufacturing’ and finalizing the website. This due to testing not only checking if the aesthetics are shown correctly on various devices, but also if it works in different contexts and testing for the devices’ hardware capabilities and their respective browsers. A great resource on the latter are the compatibility charts.
If you have ideas on web performance methods, want to share your process or have performance analyses, please do share those. The more people get aware of performance impacts, the better.