{% block content %}
{% block devices %}

Devices

We intend to document the list of devices our users use based on Google Analytics statistics.

UX for Phones consists of:

  • Feature phones
  • Slow-end phones
  • Smart phones
Device type Screen resolution Device example Browser type
Feature phone 128 x 128 pixels (e.g. Nokia 105)
Feature phone 128x 160 pixels (e.g. Nokia 110)
Feature phone 240 x 320 pixels (e.g. Nokia 5130 Xpress Music)
Feature phone 360 x 640 pixels (e.g. Nokia 5800 Xpress Music)
Smartphone 240 x 320 pixels (e.g Samsung Pocket)
Smartphone 480 x 360 pixels (e.g. Blackberry 9720)
Smartphone 720 x 1280 pixels (e.g. Samsung J3)
Smartphone 1440 x 2560 pixels (e.g. Samsung S6)
{% endblock %} {% block principles %}

Principles

Molo design system is a code guide and documentation for our mobile-websites code patterns, in-order to keep designs and code base inline for reuse and consistency across multiple devices.

This site provides a range of resources for designers and developers, these includes:

  • Responsive component HTML mark-up
  • Show Usage: shows the component HTML layout and futher documentation
  • Colors: a range of color variables with hex values examples stocked from across our Molo mobi-sites

How will we use Molo Design System - Pattern Library?

  • We will set our team’s workflow
  • Establish common vocabulary between disciplines
  • Establish browser, device, performance, and accessibility testing
  • Encourage design and functionality familiarity withing the teams to speed up team production and QA
  • Using a combination of BEM & SMACSS Methodology
{% endblock %} {% block feature_phones %}

Designing for Feature Phones

Feature phones have limited capability compared to smartphones. This principle discusses how these limitations affect the services we provide, as well as guidelines on how to make the best of our services despite these limitations.

Feature phones either won't understand or will incorrectly implement the fancy CSS and design, especially the low-end feature phones. The best approach is to send feature phone users a very simple design, using typography, vertical spacing, and a little colouring.

We shouldn’t design with widths bigger than ~320 pixels

  • Feature phone screens start at about 128 x 160 and only go up to about 240 x 320.

We should use a simple one column layout.

  • Feature phones have tiny screens that would make your columns too small, even if they understood the code to make the grid layout in the first place. Floating text and images often results in a broken layout.

We should use as few images as we can.

  • Each image we add costs the user time (to download the image) and money (for data). On top of that, some browsers have an image quota or a page size quota: when they reach it they either stop loading the page immediately, or reject the whole page and load nothing.
  • Images should be small, and displayed inline, or on a row of their own, for example, should be always above or below the texts. No fancy positioning or floating is possible. 72dpi resolution ideally.

We shouldn’t use background colours and try to use less colour in the feature phone design.

  • Feature phone support for applying background colours is widely variable and can't be trusted. You might end up with text and background colours being the same, rendering the text invisible.
  • Low-end feature phones don’t show the colours and texts will appear black. Over-riding link colours in specific sections aren’t always supported on feature phones, and they often add underlines to all links.

We shouldn’t make links as buttons

  • On low-end feature phones they won’t show the background colour and borders so it’s better to keep the link as a text link. Also, links should have a specific URL.
  • For example, we shouldn’t have a back link that doesn’t have a specific URL because this requires some code that either won’t work on feature phones or even if it works, sometimes it directs the user to the wrong page.
  • Hence it should be back to article or back to homepage so that we can give it a URL.

Buttons should have short one word text.

  • The feature phone screens are small, and buttons will be smaller than the smartphone templates; if the text is long it will go under the buttons.

Plus other points

  • Feature phone friendly font e.g. Arial
  • Left align everything - including buttons
  • Form fields with text above the field (not inline)
  • Use the word Menu instead of a hamburger icon
{% endblock %} {% block accessibility %}

Accessibility

The Molo Design System enables accessible development by providing a set of semantically correct components, each with appropriate ARIA markup so they can be identified correctly.

This means properly identifying all form fields and buttons, providing text based alternatives for all images, videos, icons and SVGs, as well as building components that properly convey their identity.
{% endblock %} {% block workflow %}

Proposed Workflow

To really experience the full benefits of the design system we want to propose a new workflow that is not about designing pages but rather designing components.

When a new feature that is not part of the Design System is requested 2 things can happen:

  • If it’s a simple feature the service designer might be able to take the component library and build the feature
  • If it’s more complicated the developer and designer might have to be pulled into the discussion earlier on in order to design the new feature

BUT VERY IMPORTANT: Before a new feature is created it’s important to make sure that it’s not just a tweak to a current feature. In that case the feature can rather be altered to accommodate the adjustment and added to the Design System - remember to mark patterns that have been updated in the system so teammates can see.

Workflow
{% endblock %} {% block markup_styleguide %}

Markup and Style Guide

The Pattern library will be actively developed to enable developers to uniform applications while adhering to CSS best practices and conventions

Why design a Pattern Library Markup?

Design Systems entail that your prototype is built from functioning HTML, CSS and JavaScript code, which means QA iteration and vetting has taken place, this minimises bugs and time taken to do bug fixes as parties get familiar with the product

This increases FED and the rest of the engineering productivity

Streamline and automate the project project setup to maximum and enforce standards and minimised errors

In order to achieve this, we have chosen to use very specific naming techniques

  • BEM Naming
    BEM is a known method of naming components — block, element, modifier. For those unfamiliar, let’s briefly look at how BEM works below.
  • Block
    A block represents the main component name. e.g. call-to-action
  • Element
    An element represents a part of a component and is separated by two underscores. e.g. call-to-action__green
  • Modifier
    A modifier is a component or element variation and is separated by two dashes. The variation can apply to the overall component or it can be applied to an element within the component. e.g. call-to-action--main

Standards Compliant Markup:

The semantic markup in our components are based on W3C standards and industry best practices.

Appropriate use of color:

We provide the basic combinations of text and their background colors for slow end feature phones and build our way up to smart-phones



Appropriate use of color:

  • We provide the basic combinations of text and their background colors for slow end feature phones and build our way up to smart-phones
{% endblock %}
{% endblock %}