{% 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.
{% 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 %}