Retrofitting Mobile First Design, Responsive Design: Driving Factors, Approach, Best Practices and Design Considerations

For any business going online, mobile apps or websites are
mandatory. Excluding internet sites with large and complex...

surpassed that of desktop patrons. This is an important statistic; it shifts our focus to a mobile first approach, which is a paradigm shift toward designing and implementing an app for mobile gadgets first and progressively enhancing it for other devices. This research focuses on both transforming an existing UI into a RWD and also building long-term capabilities to produce such designs for all future projects as a practice. A live commercial application was researched, and the steps followed were documented to form a prototype for such future works. Design guidelines are very specific and actionable. The mobile-first approach is about starting the design from a mobile reference resolution and progressively enhancing it using media queries to adapt to other contexts. The older approach was defaulting to a desktop layout and then gracefully degrade to smaller devices since content must be filtered to match the real estate [5]. The following research data from Figures 1-6 show a steady increase in mobile consumers over the past decade, not only in the US but also worldwide [6]. A decade ago, the number of mobile users was very few; five years ago, it increased by many folds, and this year, mobile adoption has surpassed desktop utilization and is still growing steadily.

Design considerations
Designing mobile websites is different from desktops not only in terms of visuals, but also in terms of screen size, lack of pointing devices, restricted download and upload speeds, difference in user goals, etc. However, mobile sites should not be limited in scope and should include all the information of the full site. Regardless of the device, a responsive site should be simple, understandable and relevant [7][8][9][10].

1.
Simple-Users should not require considerable time to understand how to use the application.

Targeting mobile web kit
Features such as mobile web kit can be used to create web applications that look like native mobile applications [7,11]. The following are some of the components and design considerations while working on mobile web kit. Additional design guidelines 1. Minimize keyboard entry: As per reference [7] minimize keyboard entry and Create a list or picker wherever possible. Wherever data entry is inevitable, make it as simple as possible, remember user information (except for sensitive information such as password, SSN, etc.) that has already been entered.
2. Be succinct: Make the application content obvious, minimize mandatory input, minimize text.
3. Hidden fields and menus: Avoid popups, navigation bars, and hidden fields should only be visible only when hovered over. Drop-down menus with submenus that pop out on hover are bad for desktops and even worse for mobile devices. Users do not hover on touch devices, they touch. Move away from a drawn-down pull-out menu pattern in favor of click-based menus instead.

Performance considerations
The performance of a mobile site is important. However, sophisticated sites might be of less use if they cannot be rendered on the user's device quickly. The following are a few of the factors affecting mobile performance.
Battery life: CPU usage drains the battery. Some of the factors to be considered to ensure that the apps do not greedily occupy CPU cycles are as follows [12,13]:

1.
Defensive coding expects that the mobile device is not plugged-in for charging.

3.
Minifying both the size and activity of JS.
Here are some of the specific design choices that draw less power and thereby increase battery life [7,11].

2.
Reduce the size of requests: Minify text-based assets such as CSS, JS, and JSON using minifying assets (for ex: yui compressor for CSS and JS). Compress binary files and GZIP everything-once files are compressed GZIP ping them accelerates download speed, reduces image size and sends only the right size images using media queries. Minimize cookies and defer/avoid 3rd party scripts.

Performance antipattern:
The following design strategy might not go well with the best practices, but it certainly reduces latency, and hence, needs to be used with caution; • Embedding CSS and JS for the first page load.
• Extracting the above files in local Storage. 'local Storage' for web or mobile apps is a method for accessing storage in the browser.
• Setting cookies with the names of the extracted embedded files.
• On subsequent requests, checking the cookies server side.
• Only embedding new and missing scripts.
• Loading files from local Storage.

Memory:
The mobile browser will generally close or crash to free memory, and we need to manage the memory requirements of the application to ensure they do not use too much memory and slow or crash the browser. Use Chrome Developer Tools Timeline Panel to manage memory usage.

5.
Optimize images: Some of the tools for image optimization are Image Alpha (http://pngmini.com) and Imageoptim (http://imageoptim.com). Reference [14] suggests resizing images to match the display size; the Sencha.io (http:// www.sencha.com/learn/how-to-use-src-sencha-io/) proxy determines what size image the user's device requires and will shrink (not grow) images before sending. Use GPU memory for images rather than CPU memory

Native Responsive Web
Requires maintaining different codebases, one for IOS, one for Android, one for web etc. This causes redundancy and consistency problems.
One codebase serves all devices. This reduces development time and decreases maintenance costs.
These run on the device similar to any other in-built standard application maximizing viewing area and controls.
Though web apps run on the browser, some (for ex: iOS WebKit) allow web applications to display and work similar to a standard native application.
Native applications are mostly sold on the iPhone app store, Android market app, Google Play store etc. The opportunity of having an app noticed among the thousands of apps is slim.
These stores are bypassed with their · Approval processes.
· Directly marketed using websites and marketing channels.
On average, there is an approval process of 3+ weeks. Once the app is pushed to production, we have to wait for users to install/sync/ update. Any misspellings or corrections can require considerable time.
It is easier to build and iterate. Changes can be made whenever needed, multiple times a day if required. Changes are live immediately.
All the screen components need to be built from scratch, and people with the desired skills to develop/maintain the app are hard to find.
These are basically built in HTML and CSS which are the same technologies the existing applications are built in, not a new language, not a new technology and not a new framework. Required skills are already being practiced.
Existing platform server-side components will have to be refactored to accommodate calls from native apps. Server-side components of the existing platform need not be changed.
The iPhone, iPod and iPad do not support flash.
With HTML5 video elements, videos can be made truly cross-platform.
No dependency on browser support.
Earlier versions of HTML and CSS were unpopular due to their lack of support for older (For ex; IE8 or earlier) browsers. This has changed because · Mobile devices do not run on older browsers. · HTML5 has support for handling older incompatible browsers differently. Table 1 presents a comparative analysis of native mobile apps and a web application [1,2,7,15]. Native apps are applications that are downloaded on the device and operate similar to a standalone program. Internally, they make network calls and work on data. Hybrid apps are a combination of native and web apps that provide platform-specific functionalities such as native apps and network interactions such as web applications. Hybrid apps are not considered for this comparison because they are an assortment of both approaches. If the UX architecture is planned well, hybrid apps have the advantages of both native and web applications [15].

Becoming Responsive
It is possible to transform any existing HTML or other server-side frameworks, such as Spring, JSF, and strut-based UI, to be responsive. For the purpose of this research, an existing non-responsive application was considered and re-engineered successfully. It was built on a spring framework with HTML, CSS, JSP, and composite view design patterns to optimize fragmentation and reuse. This was a common pattern a decade ago, and this will also be the hardest pattern to retrofit. An expectation here is that such a project frequently faces this predicament of 'refactor' vs 'build from the ground up'. Sections and tables in the images below are specific to the application researched. These are only indicative, similar applications will still work while analyzing any kind of composite view fragmentation. These can be used as a sample tabulation for research. Transformation is carried out in 2 phases: 1. An optional refactoring phase -a set of activities that can be carried out by a single team in isolation for most parts. This is applicable only to refactoring applications.

2.
Design and development phase -Designing or redesigning involves working with all (product, design and UX, etc.) the teams; here we also build capabilities for future responsive designs such as having a standard set of breakpoints across applications etc.

Phase 1 -Refactoring
In this phase, the existing implementation is refactored into a responsive site. Of course, building new solves problems, but there are many unique scenarios that are solved better by refactoring.

b.
Changing the doc type: The first step is to add the document type in HTML, as shown in line 1 below. [language=HTML] <!doctype html> c. Adding a 'viewport': This is a metatag as shown in line 2 below, which is normally added to the head of an HTML page. It controls the page's dimensions and scaling. [language=HTML] <meta name="viewport" content="width=device-width, initial-

f. Amend HTML5 changes: Amend HTML5 changes in CSS
and other relevant files, this also helps in making grids flexible.

Usage of boilerplate and normalize.css is allowed if needed.
Amend RWD Changes: Amend the following RWD changes in all the HTML and CSS code: Enforce CSS styling: To apply responsive web design changes, it is important that the styling information comes from the CSS files and is not incorporated inside the HTML. If styling information is directly embedded, such files should be refactored to move styling changes to the CSS files. The following is an inline code that needs refactoring; <div class="some Example Class" style="width:120px;"> can serve well here for redesigning grids [11,[16][17][18][19].
Tile analysis -Usage of Spring, JSF, Struts, etc. frameworks enforces composite view pattern fragmenting the page into layouts and tiles. Commonly reusable elements such as header and footer are grouped into respective layouts or tiles. Amending these are not as simple as amending HTML, and hence, additional steps need to be followed to migrate them. Table 2 shows all the layouts, number of tiles making up those layouts and number of pages (multiple JSPs are combined to form a page) implementing them. This is specific to the application being researched. These layouts are not very different from one another. Analysis done on 'parent Layout' will be mostly applicable to the other layouts as well.
Block analysis(div)-Blocks shown in the above diagram are not the complete list; they are only the main blocks. There are many small blocks that cannot be shown here. The diagram indicates the approach and process to be adopted while migrating from fixed elements to fluid responsive elements, which should be used as a guide and not a blueprint. A similar analysis should be carried out on other layouts and pages while incorporating the changes to the whole application. Figure 7 shows the composition of the header and the body section. Pages differ mostly in the body section; other tiles (except the title and sometimes the header) are constant and do not change with the page. Figure 8 shows the composition of a typical body section and how to amend its responsive components.

Media queries:
A media query is a module from the CSS3 specification that adds flexibility by providing means to handle display features for each display setting (size and layout) separately [2,7,11]. Flexible layout and flexible media should be implemented and fine-tuned after reviewing inputs from the 'mobile-first approach' and 'resolution breakpoints' analysis in phase 2 because the implementation of media queries will be greatly influenced by this. Since fonts are inflexible, we have to use media queries while sizing them in phase-1.
• Font size: By default, this research uses 100% font size, which is suitable for viewing in 1024 px display (this is an existing site, and hence, is not a mobile-first design). Font sizes should be adjusted appropriately (for example, a 768 px display might use font size of only 90%) to the display size using a media query.

Event listeners:
All existing even listeners specific to select, click, etc. need to be modified to be more generic. They need to handle touch events as well. Hover-and other computer-specific events are not available for mobile devices.

Phase 2 -design and development phase
To add device-specific responsiveness, requirements and UX need to be redone using the 'mobile-first design' and 'resolution breakpoints' as described in the later sections. This entails designing bespoke user interfaces for every breakpoint. This might sound like a lot but it is most crucial. In this example application scenario, the UI is gradually degraded to lower resolution displays since it is an existing web application.

Amend RWD changes: Amend the RWD changes from previous
sections in all the HTML, JSPs and CSSs. Follow the previous sections while ignoring all the sections that discuss refactoring an existing implementation and completing the changes. All the concepts from phase 1 hold here too.

HTML and CSS Frameworks:
It is preferable to use an HTML/ CSS boilerplate framework such as Bootstrap and Flexbox instead of attempting to build grids manually. There are many such alternatives. Flexbox offers many advanced and sophisticated features that can make even an old site look reasonably fancy [11,[16][17][18][19]. It can seamlessly handle dynamic settings such as box alignment, ordering, direction of flow, space between them, growth and shrinking, wrapping, and left or right justification with minimal coding; a sample Flexbox code looks something like this: .container {justify-content: flex-provided for all of them. These are the widths, depths, images, font, etc. that the design needs to be detailed. It does not mean that the widths below or above the spectrum will not be accommodated, but building a list like this helps standardize a scope for the efforts, al-lowing identification of devices most commonly used, and how best to test against their respective resolution. There should be a default handling mechanism for screen resolutions beyond this spectrum. Table 3 is a small suggestive list of resolution breakpoints.

Overhauling
If the existing user interface is replaced with a new UI while keeping the server-side component such as a restful API as it is, then the following needs to be addressed before embarking on this plan;

1.
Reusability-Identify reusable components and have a game plan.

2.
Estimation or Sprint Plan-Reusability needs to be factored while planning sprint planning or estimation.

3.
Awareness-Document, share and spread awareness about reusable components (for ex: if address validation is reused, this needs to be documented and all the engineers need to be aware of its existence and usage).

4.
Review-There needs to be a stringent review process to ensure reusable components are efficiently reused to avoid reimplementing algorithms already coded.

5.
All click event operations need to be refactored to accommodate 'touch' events.

6.
Heavy refactoring of JavaScript and CSS merges these files to reduce server round-trips.

7.
Clarity of images -Remove unclear, uneditable, obscure and very large images that do not add significant value to the content.

8.
If a large un editable image needs to be used, use it in the background or in line with the text.

9.
Use the 'image plus text element' pattern where every cell is a combination of an image and a text related to it.
Web-services invocation or any server-side component is an easy and obvious reuse candidate. It also depends on how it has been invoked. If it is a JSON-based interaction, then there will not be any migration needed. However, if it is a server-side frameworkbased integration such as Spring MVC, it might have to be refactored too, just for the contract.

Testing
All the pages in the application should be thoroughly tested.
Simulators can be used temporarily for simulating different resolution breakpoints. Ideally, it is best to run the tests on actual devices, but it might not be possible to do so because there are thousands of devices. It is therefore suggested that the tests be performed on a representative group of actual devices, covering different configurations, browsers, operating systems, device capabilities, etc., in addition to tests on actual devices with Wi-Fi turned off and with many uncontrolled apps running in the background. Table 4 shows some of the most widely used emulators and simulators.

Conclusion
For any business going online, mobile apps or mobile sites are currently a mandate. Many studies have shown that mobile usage is skyrocketing and will continue to do so. For organizations already running sites in production, they either need to refactor their sites to be responsive or rebuild them based on their architecture. It is possible to convert an existing rigid site into a responsive site, and this research offers all the details for the same. This research also offers specific design guidelines for building RWD as a design and as a continuous practice. There are, however, different flavors for providing responsive design, such as native apps, responsive design or hybrid apps.