Design for the lower end of the spectrum: Part 3
Ideas for client-side #
So how do we address some problems of the web? There are aspects that go beyond PWAs and contribute to the bloat of the web and, I would imagine, the large size of apps.
For each of the problems listed in the Developer Facing Problems there is a solution that will work whether we use a build system or not. I avoided build system-based solutions as I don't want to give the impression that a build system is required, just the extra effort of running the apps either locally or in the cloud.
Image sizes and download times #
A solution for image sizes passes through responsive images (either picture or srcset) and image compression with tools like
We don't need to send the same high DPI retina image to all browser; we can choose what type of image to send and browsers are smart enough to know which one to use for each browser and screen size (if we set them up correctly).
This is what a responsive image looks like:
srcset=" large.jpg 1024w,
alt="A rad wolf">
Both srcset, nd sizes (a related specification) are part of the HTML specification and is supported in all major browsers so there should be no problem in using it across devices. If a browser doesn't understand the
srcset attribute it will just use
src like any browser did until we got responsive images... they will get something, not just the optimized version of the image we wanted to give them.
Cloudinary has made available a Responsive Image Generator that allows you to create responsive images and their corresponding CSS styles in the cloud and then download it to use it on your project during development.
If we send large bundles down to the users, it'll take a while to parse the code we send. This will not hurt our high-end devices but it will be much longer for mid and lower-end phones we're likely to see in rural areas or for people who can't afford the latest and greatest.
Mid and Lower level devices in other countries may be different and have different specs, usually less powerful than what we normally see.
Meeting users where they are: using their language #
We can also provide content in the users' target language and take advantage of technologies that have been on the web for a while. Web fonts used responsibly and with proper fallbacks, give you a device independent way to give users content in the language they use every day without major changes to the structure of your CSS.
First declare the language in the root element of your page, usually
<!-* provides a default language -->
<html lang="en-US" dir="ltr">
and later in the document, we add content in traditional Chinese, like this:
<!-* Later in the document -->
We can use the following CSS to indicate what fonts we want to use for each case. We can go further and indicate multiple language fonts for different versions or dialects of the language. In this case, we've indicated different fonts for traditional and simplified Chinese characters.
font-family: "Times New Roman", serif;
font-family: Kai, KaiTi, serif;
font-family: DFKai-SB, BiauKai, serif;
You can also use attribute selectors that exactly match the value of a language attribute (
[lang = "..."]) or one that only matches the beginning of the value of a language attribute (
lang |= "..."]).
<p lang="en-uk">Content written in British English</p>
<p lang="en-au">G'Day Mate</a>
<p lang="es">Buenos días</a>
Finally, you can always create classes for the languages that you want to use and add them to the elements using that language.
There's another aspect of working with non-latin, non-western languages: writing direction.
If you've seen Hebrew or Arabic text you'll notice that is written in the opposite direction than English: right to left, top to bottom.
There are other languages that write top to bottom, and either left to right or right to left.
There is CSS that will make vertical languages is not hard but it's not something that we're used to seeing in most western content.
You can see an example combining Latin and Japanese text in this demo page
Depending on your target audiences and the languages they use, this may be all you need to do. But there are other languages that use different directions and vertical alignments.
The first step, always, is to localize your UI but the localizing the content is not too far away.
Conclusion: Where do we go from here? #
Perhaps the hardest part is to move away from a one size fits all model and ask ourselves the question: "Does the web work well for what I'm trying to do?"
Think about it... the web has no app store and no install friction. All that your users need is visit the URL in a browser that supports the PWA technologies, and voila, they are using a PWA and using the technologies without having to do anything else but use their web browser. When they have engaged with the app enough times they can install it to the device (desktop or mobile) without having to follow the app store procedure and update the app with a large download every time the developer makes changes.
Once they are there the APIs that make up a PWA give you features that look like native but work on the browser and make the experience better for all your users, not just those on mobile connections.
And you're not required to use all the APIs that make a PWA. For example, in my Layout experiments I chose to implement a service worker to make sure that users get a consistent experience after their first visit without using a manifest or any other PWA API or technology.
I'm not saying not to implement native applications but to evaluate your target audience and requirements before deciding if web or native is better for your application and your objectives.
And, whether you decide the web is best for your project or not, you owe it to your users to optimize your content as much as possible.
Links, References, Tools #
- Mobile connectivity, devices, and chipsets
- Social aspects
- Beyond Desktop Research: The Immersion Trip
- Global UX Speaker Series Youtube playlist
- Why mobile page speed is a Visual Designer's problem
- Making websites that work well on Opera Mini
- Better together: Displaying Japanese and English text on the web
- W3C Internationalization (I18n) Activity
- So what do we do?