Difference between revisions of "Low-Bandwidth Design"

From KM4Dev Wiki
Jump to: navigation, search
(→‎4) How to handle files)
m (1 revision: Old Wiki Backup 2012-2-18)
 
(No difference)

Latest revision as of 14:19, 18 February 2012

Introduction

This page covers tips to create a website that will be functional even for low-bandwidth (typically, ~20kbps) users. One key challenge for nowadays websites is the growing size and consquently its loading time. For example great open source solutions for web publishing such as Wordpress, Ning and hosted services such as Facebook have an increasing page size, which takes minutes to load with a dial-up connection. Dial-up or shared broadband connections are often the reality in many developing countries. It is possible to develop low-bandwidth website, which have a small page size, but unfortunately hardly any hosting solution exists. This article summarizies the most important aspects one has to take into consideration when designing a low-bandwidth website.

A good starting point for a better understanding is check of your own website. Website Analysis

If you check for example this Wiki page, the following results are shown:

Download Times

  • 14.4K 99.81 seconds
  • 28.8K 52.61 seconds
  • 33.6K 45.86 seconds
  • 56K 29.68 seconds
  • ISDN 128K 12.84 seconds
  • T1 1.44Mbps 6.05 seconds

So this page has alone a loading time of one minute with a 28kb modem, what many universities in Africa use to get access to the Internet.


The notes were compiled by Gabriele Sani (gabrielesani_AT_googlemail_DOT_com): I would be more than happy to receive your feedback and suggestion!

The starting point behind this wiki page is a discussion in April 2009 between Joitske Hulsebosch, Gabriele Sani, Christian Kreutz and Carl Jackson.

Keywords

Low-Bandwidth, Website, Design, Low-Connectivity, Drupal, CMS, Performance, Optimization, CSS, Javascript

DISCLAIMER

More than a guide, the following 5 points are a personal list of notes. A good deal of them come from:

Please contact me (gabrielesani@googlemail.com) if you feel you should be added to the above list.

1) Guidelines

If you are creating a website that will be usable also by people with low bandwidth connection, there are a 3 general rules to follow:

1. Keep the page size as small as possible Your pages should load within 10 seconds, which means 25kB should be the maximum page size if your website is aimed at areas with 20kbps connections.

  • Use compression
  • Minimise your CSS and JavaScript
  • Reduce the number and size of images, CSS files, JavaScript etc
  • Use as little video, audio and documents as possible. If needed, provide low quality versions of them
  • Allow the use of the browser’s cache. Browsers can store a local copy your pages. This means that the second time they need a file already in their storage (“cache”) they won’t need to download it, thus it won’t count against the size of the page.

2. Reduce the number of HTTP Requests Every image, CSS file, JavaScript file, HTML page etc. requires a separate HTTP request. Having more that 2 at a time slows down the page loading.

  • Use CSS sprites
  • Do not upload presentations, but convert them to S5 format

3. Optimize your site structure and design Provide easy navigation to reduce the number of page loads. This requires a user-driven approach ,and if possible, the inclusion of your audience in the testing.

  • Re-use cached content as much as possible, this will reduce the page size to be downloaded, and the number of HTTP requests
  • If possible, have a “navigation path” that will allow users to cache content in small chunks (eg: with first page cache the images. With the second page cache the CSS file. With the third page cache the JavaScript)
  • Put the useful items at the top of the HTML files, as they will be first to be loaded. If a page loads useful content in the initial seconds users are more likely to perceive the website as functional. If you have an incrementally loading website it is regarded as acceptable a total download time of 30s, that translates to a page size of 75KB for 20kbps connections.
  • Put the JavaScripts at the bottom of the page
  • Use CSS template sheets. Use tables with caution
  • Design an accessible website, possibly with a text-only version
  • Add important dates/user’s feedback/tags/link size/whatever is relevant for each page in its previews to allow users to ascertain how relevant that content will be for them


These 3 requirements are widely true, and can be applied in any different ways, but I am not discussing the whole range of them. The purpose of these notes is to show ONE way of creating a user-driven website for low bandwidth users. The platform of choice for this example is Drupal, an Open Source CMS system that has been developed mainly for social networking, and has a very wide community of developers that during the years have created thousands of modules that allow to expand enormously the core features of the system. Again, this is just ONE way of creating a website for low bandwidth users and it may not fit everyone’s needs. For example, if all you need is to broadcast some information, a static HTML/CSS website could be a better choice. However, for Knowledge Management you will probably need a system that can grow organically in time, thus it may make more sense to look for a flexible platform that can allow even non-technical staff to contribute new content, and possibly even simplify the development of new functions to keep it aligned with the changing needs of the users.... but this opens a whole new, long discussion, which goes beyond the purpose of these notes.


Aptivate has some excellent ten rules for low-bandwidth design

  1. No Page Bigger Than 25kB
  2. Reduce Images
  3. Have Good Site Structure
  4. Use Style Sheets
  5. Minimise HTTP Requests
  6. Turn on Compression
  7. Be Cache-able
  8. Avoid PDFs
  9. Put Useful Items First
  10. Show Link Sizes

| Web Design Guidelines

2) Starting point

A test case with Drupal - an open source content management system

I installed a Drupal test website, added a single line of content, and left the Garland (default) theme. Then I tested the out-of the box performance with the free online Web Page Analyzer at: http://www.websiteoptimization.com/services/analyze/ 


Global Statistics
Total HTTP Requests:	49
Total Size:		101496 bytes

Object Size Totals
Object type	Size (bytes)	Download @ 56K (seconds)	Download @ T1 (seconds)
HTML:		6583		1.51				0.23
HTML Images:	7174		2.03				0.64
CSS Images:	34267 		14.83				8.18
Total Images:	41441		16.86				8.82
Javascript:	53472		11.66				1.28
CSS:		0		0.00				0.00
Multimedia:	0		0.00				0.00
Other:		0		0.00				0.00

External Objects 
External Object		QTY
Total HTML:		1
Total HTML Images:	3
Total CSS Images:	40
Total Images:		43
Total Scripts:		5
Total CSS imports:	0
Total Frames:		0
Total Iframes:		0
 
Download Times*
*Note that these download times are based on the full connection rate for ISDN and T1 connections. Modem connections (56Kbps or  less) are corrected by a packet loss factor of 0.7. All download times include delays due to round-trip latency with an average of 0.2 seconds per object. With 49 total objects for this page, that computes to a total lag time due to latency of 9.8 seconds.  Note also that this download time calculation does not take into account delays due to XHTML parsing and rendering.
Connection Rate	Download Time
14.4K		88.46 seconds
28.8K		49.13 seconds
33.6K		43.51 seconds
56K		30.03 seconds
128K (ISDN)	15.99 seconds
1.44Mbps (T1)	10.34 seconds


Since it is fundamental, I also checked the content caching at this free online resource: http://www.port80software.com/products/cacheright/ 


Cache Control Overview:
This page issued 24 requests for files totaling 119113 bytes in size. 
Of these 24 requests, 24 responses included cache expiration information.



The results so far: The first test shows that this theme is not suitable for a low bandwidth website, the second one is more reassuring, since every element is cached… but looking at the detailed report shows that the cache will expire in 2 weeks. Not nearly enough, you do not want users to re-download all content sos often! Luckily, setting the cache to expire far in teh future is easy enough, you just need a developer to edit one line in your .htaccess file to set all cached content to expire in 10 years. Once teh caching is ok, it is time to do the hard work to reduce the download time. Drupal has the ability to performa some basic performance optimizations, but I woudl recommend not to look at them for teh tiem being since turning them on will hamper the further developments, thus leave this step for last.

3) Design

The way your website looks IS important. In 2004, Skadberg, Y., and J. Kimmel showed that an optimal experience where users are fully engaged in an activity is determined by:

  • Speed (91%)­
  • Attractiveness (97%)
  • Ease of Use (19%)
  • Interactivity (21%)

I suppose that the results 5 years later would be quite different, since the number of web2.0 tools has grown enormously, making interactivity much more important. Also, I guess that the results where based on people with no real connection speed barriers. The interesting point, however, is how important is the look of a website to win the user attention. Most websites I have seen so far for low bandwidth areas look cheap and sad. I find it demeaning, thus I want a jazzy low bandwidth theme. This is possible if you keep in mind some design limits, and use wisely the power of CSS (see what it is http://en.wikipedia.org/wiki/CSS ). For these reasons, now almost nobody creates text-only websites.

Before getting into any details, let’s understand how the web works. In a highly simplified picture, a page that you read online has been created in three stages. Once by the server, once by your browser interpreting the HTML and CSS sent by the server, and lastly by your browser while executing the Javascrip of Flash files embedded in the page. A static HTML/CSS servere will be little more that a storage of static HTML files. In these HTML files there will be links to the necessary CSS files to properly format the content, and possibly to the Javascrip and Flash files to create animations and interactivity. Most modern websites, however, have a more complex setup, where a programming language dynamically generates the HTML files only when you browser requests them. This way different users can have customised content even when they visit the same location. For example, Drupal is made of a set of programs that run on your server to generate the HTML files. Since it runs entirely on the server, users can happily be oblivious to all this work done in the background, and if your server is good enough all this background work will not sensibly reduce performance. Using such a system allows you to modify, filter and adapt the data as you want BEFORE it is sent to the user's browser - a key feature, as you will see reading below.

As a starting point, I chose to use an old theme of mine. Any theme will do, as long as they do not relay on a large set of images (like Garland). Since my old theme was not developed for low bandwidth, it employs quite a few images. To convert it I will get rid of almost all of them. The few leftovers will be merged into a single image that will be used across the whole website using a technique called “CSS Sprite” (There is an excellent explanation of what it means at http://www.alistapart.com/articles/sprites/). After careful though, I chose an in-between strategy: I am using a small (1KB) image for the background body, and CSS definitions like 

background: rgba(0, 0, 0, 0.10);

to set a semitransparent black background behind titles and other areas that need to stand out (the first 3 values are RGB, the last one is the opacity; its value must be between 0-fully transparent- and 1 -no transparency- )

BEWARE: Using a background image is not the best choice in terms of bandwidth optimization... but I'm using a 1KB image that completely changes the look of the whole website, and the price of using it is a split second longer load time only the first time that a user opens a page (then it will be cached). I can live with that.

After a little work on the theme, I managed to remove all images, as none of them was truly necessary (some icons were replaced with an icon-looking white letter centred on an orange square). Unfortunately, there are still several CSS images from some system modules, but a quick patch of these "careless" files can take care of that. Another thing I have done, even if not strictly necessary, was to add a visual mark to links that point to areas outside of my website. This is not ideal, in terma of bandwidth usage, but the increase is truly minimal, and it’s a good practice to keep people aware of what is going to happen every time they click on a link, be it a download or an external link.

Now it is time to optimise the website.

Drupal offers in admin/settings/performance to automatically optimize external resources like CSS and JavaScript. CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed). These optional optimizations may reduce server load, bandwidth requirements, and page loading times. However, to squeeze ever more bites out of the systems, I installed two very useful modules: CSS Gzip and Javascript Aggregator. As you might guess fro their names, they will further reduce the size of the CSS and JavaScript files. There are several alternative modules that can do the same - choose the one that is teh best fit for your needs.

One additional step I took was to install HTMLpurifier: it will strip all unnecessary and/or potentially malicious tags. Thus, it will give me a leaner website while increasing the protection against a malicious use of my platform (this is VERY important if we are going to allow users to create content on their own.) Please remember that installing new modules will impose possibly more strain ONLY on your server, but not on the user’s resources.

The Web Analizer tool shows now that the download time is less than half of what it was. Not bad, but can do even better than that!

For example, we can leverage the fact that pages are dynamically generated and embed the Javascript files only for authenticated users. If anonymous user do not have access to any interactive feature that requires Javascript, this trick will have no impact at all on the site usability, while it will sensibly shorten the page download time for users in low bandwidth environments. Thsi clearly requires you to plan carfully how your website will work, and design it accordingly.

Now the Web Analyzer tools gives us some rewarding results: 

Global Statistics
Total HTTP Requests:	5
Total Size:		7044 bytes

Object Size Totals
Object type	Size (bytes)	Download @ 56K (seconds)	Download @ T1 (seconds)
HTML:		3124		0.82				0.22
HTML Images:	0		0.00				0.00
CSS Images:	3920 		1.58				0.82
Total Images:	3920		1.58				0.82
Javascript:	0		0.00				0.00
CSS:		0		0.00				0.00
Multimedia:	0		0.00				0.00
Other:		0		0.00				0.00

External Objects
External Object		QTY
Total HTML:		1
Total HTML Images:	0
Total CSS Images:	4
Total Images:		4
Total Scripts:		0
Total CSS imports:	0
Total Frames:		0
Total Iframes:		0

Download Times
Connection Rate		Download Time
14.4K			6.46 seconds
28.8K			3.73 seconds
33.6K			3.34 seconds
56K			2.40 seconds
128K (ISDN)		1.43 seconds
1.44Mbps (T1)		1.04 seconds

Not bad at all, and it should have taken you (or your developer) a fairly short time to apply all these changes! Remember that there is also an additional "hidden" advantage: once a user has reached ONCE any page of your website his/her browser will store the CSS file and the image in its cache, thus browsing the site will now be even faster.

In my opinion, EVERY website should at least discuss the value of the above changes - faster is better, no matter what kind of connection your users have, thus you may want to use some of the above techniques for any website.

4) How to handle files

Provide alternatives, and a range of formats to fit the users’ needs

Favour content in this order:

  1. Plain Text
  2. Documents
  3. Vectorial images
  4. Images
  5. Low bitrate audio
  6. Audio
  7. Low bitrate video
  8. Video

Also, if possible:

  • Let people know the size of a file before downloading/showing it.
  • Provide a plain text description of each file before it is downloaded.
  • Enable download resuming on the Web Server.
  • Split files into logical sections of 40Kb or less, if possible
  • Provide a good description of the content, and why they provide information that a plain text cannot convey.


IMAGES


Provide a textual description for all of your Images

Choose the most suitable format between .gif .jpg .png (.bmp .tif tend to be much larger, thus unsuitable) .svg and .xcf are interesting alternatives, if your users have access to Inkscape and Gimp, respectively (they are both high quality Open Source programs for image creation/manipulation)

Reduce the quality settings and colour palette to the lowest acceptable level. Strip the metadata, and use image optimization tools (PNGgauntlet is an excellent free software for PNG optimization)

Explicitly setting the correct width and height attributes for each image, the browser will allocate placeholders of the correct size such that the layout of the page will be the same while the images are loading.

With Drupal you can install the ImageCache module, and configure it to resize the images to a common standard. For example, you can choose to automatically convert and resize all the pictures uploaded to jpg at 50% quality with a max size of 100x100px. This will make for a very consistent look, and it will keep in check the size of the user-generated content. Also, remember that if possible it is a great idea to re-use the same images across the whole website since they will be cached by the user's browser.


PDF

Minimise bandwidth-wasting embedded fonts, use only the standard ones:

  • Courier
  • Courier-Bold
  • Courier-BoldOblique
  • Courier-Oblique
  • Helvetica
  • Helvetica-Bold
  • Helvetica-BoldOblique
  • Helvetica-Oblique
  • Symbol
  • Times-Bold
  • Times-BoldItalic
  • Times-Italic
  • Times-Roman
  • ZapfDingbats

However, these base fonts do not support languages with non-Latin characters. For non-Latin characters embed only the actual characters that you are using rather than the entire character set.

If possible, use vectorial images in PDF documents.

Test different PDF printers, as the size of the produced document may vary.

Create linearised PDF (a PDF whose pages can be displayed before the entire document is loaded.)

File Framework, a Drupal module, allows you to easily convert PDFs to DOCs (and viceversa) or to TXT files without needed any software on your computer. Allow multiple versions of documents


Presentations

Embedding files can be troublesome, in terms of bandwidth, technical expertise and software availability. However, you can enable your users to easily create simple slideshows using S5, a very interesting technique described in full details at http://meyerweb.com/eric/tools/s5/ It requires a very simple markup, and a 15kb JavaScript. Thus, it is suitable for low bandwidth users.

If you want to grant your users a simple way to create slideshow, with Drupal you can add a new kind of posting, and add the S5 JavaScript and markup using a two modules, CCK and Contemplate. This way, users will be able to create and share presentations without even needing a software to generate one. It will be all done by your server. The only price your users will have to pay is the time for a one-time download of an additional JavaScript.


Audio & Video

  • Create a low and a high quality version and let the user choose.
  • If you wish to embed audio or video content from third party providers (eg: YouTube), consider having a unique page that only holds the embedded content.
  • Allow downloading the multimedia. Also, you might want to enable:
  1. Progressive download is what YouTube does: a download straight into a player so that it can start to play before it is fully downloaded. This has the advantage that you can start viewing the content quickly, but if the multimedia bitrate is higher than the available bandwidth the user will have to wait for the content to buffer sufficiently.
  2. Streaming is similar to progressive download, but it you just consume the bandwidth for what is listened/watched. However, if the user's available bandwidth is below that required to deliver the media, they won't be able to experience the content via streaming.

Drupal offers SWF Tools, that supports the use of a number of flv players for video and audio. Also, the FFmpeg Wrapper and FFmpeg Converter modules allow users to encode and resize audio and video quite easily.


Audio

MP3 are widely supported, but they were made to compress music, thus they are not very efficient if all you need is a voice recording. For that, there are some good alternative encodings, like AMR. This is fundamental, as a 4 min long Mp3 recorded at 160kbps (high quality) is about 5MB. The same file recorded as an AMR at 4.25 kbps takes just 160KB. (To convert an mp3/wav file into AMR you can use Mobile AMR converter, a free software with an installer of just 650KB.)


Video

During production you should use two-pass encoding as it gives a better compression. Choose your format wisely. Flash is a good choice, as it now a worldwide standard and it offers a good compression. Avoid using videos with embedded players (ie: SWF files). Offer FLV files AND a player. The latter will be stored in the cache and once it is downloaded it will load the FLV files automatically. Also, do not use auto-load. Let people choose if the want to see the video.

5) Scripting

Focus on:

  • When and why to use it
  • How to use it

6) User Interaction

Navigation to any area of the site should be both intuitive and achievable and take only a few steps so that downloading time is minimised. Make your website accessible is a good way to catch two birds with a single stone.

The navigation of your site should still work without third-party plugins, like JavaScript or Adobe Flash Player.

Having an intuitive navigation is fundamental. On top of that, a site map and a good search program, will make it easier to jump to the relevant content. In Drupal, Faceted Search (or SOLR) offer a very intuitive way to filter your results very efficiently. Views can be used for that purpose, too.

Allow text-only interaction. This may entail

  • creating and use of a text-only theme (and the ability for user to choose the one they prefer),
  • publishing of a number of RSS feeds, so that user can receive a text-only version of the new content on your website
  • subscribing to receive plain text emails whenever new content of interest is created on the website
  • granting to the user the possibility to post new content using emails.

All the above capabilities can be enabled in Drupal using RoleThemeSwitcher, Flag, Views, Notification, Messaging, Rules, and Mailhandler modules.

Reduce the number of page loads using scripts, like form validation or DHTML menu (there is a Drupal module for doing that).

Allow people to tag content using predefined vocabularies of free tagging, then use those tags to filter the data shown to the users. In Drupal you may want to use the taxonomy module, plus the above mentioned Views and Flag.

In short, try to allow you users to stay in touch using plain text delivered also through tools that go well beyond the limits of a website (programming a Firefox Toolbar may be a way to do it, too, and it is not half as hard as it may sound).

For a KM project, Drupal truly shines since it offers a wide range of out-of-the-box tools that allow to enable a large number of functionalities without having to write a single line of code. Thanks to this, a communication hub centered around a website can be ready in a few days, and can be tweaked according to the users’ needs almost in real time. Also, Drupal allows to “multisite” ie: have multiple websites share the same configuration and modules, easing the task to update and maintain several websites at once.

It this is not enough, try looking at mobile communications. There are some outstanding case studies (eg: http://medic.frontlinesms.com/ ) and FrontlineSMS (or its "competitor" RapidSMS) can be run in parallel with a web server. Also, crowdsourcing platforms like Ushahidi can be used to gather data through SMS, Twitter, or the Web, and the gathered data can be be easily imported in a Drupal website using the Aggregator module (and FeedAPI, if you desire a better control).

Low bandwith areas require creative solutions, and there are a many already available. Please, now share YOUR insights!

Initial Requirements

Carl posted a rather old pro-access technical profile from IDS to the KM4Dev list with a request for comments to help inform the commission of a Web2.0 site that would work as well in low-bandwidth situations as in others.

Technical Spec for Web Build Circa 2006 “The design of the site must take into account variable levels of internet connectivity, hardware and desktop applications. It is important to ensure that the site is accessible by users based in the UK, overseas, in the office or at home. It is also important that the site is accessible to disabled users. The designs should be produced as xhtml-compliant templates and CSS. These and any graphics must be designed for fast download with minimum file sizes. The logic of the site structure, the designs and the xhtml should allow all pages to be built programmatically as dynamic pages, quickly and efficiently, from content data, meta data and navigation data held in a content management system database. Technical specifications for the site must therefore take into account the following factors:

  • Pages should be provided as xhtml-compliant and CSS
  • Xhtml should be designed for "standards compliant" browsers but should "degrade gracefully" to older browsers (version 4 and below), so pages are still usable
  • Pages should be usable in popular but minority browsers such as Opera and Firefox
  • The logic of the site structure, the designs and the xhtml should allow all pages to be built as dynamic pages, programmatically from different possible page components held in a database. They should be such as to ensure good performance, easy maintenance, and affordable programming costs. This is especially important for the navigation and other standard elements - for example the number and complexity of the different templates which are needed to be held by the system for these elements should be minimized.
  • Style classes should be standardized across the site so that any variations in different sections of the site or changes across the whole site, can be easily managed
  • The number of stylesheets to be used should be kept to a minimum.
  • Navigation and standard display graphics should be in gif or jpeg format
  • Pages should conform at least to the W3C Priority level 2 for accessibility.
  • Where javascript is used, pages should work for the user without it - all content and sections of the site should be accessible for non-javascript users
  • Pages should be designed for a screen resolution of 800x600 but taking into account larger resolutions
  • Flash should not be used
  • Frames should not be used
  • Animated graphics or other animations should not be used
  • Graphics files should be small (except for content in areas which require large files, e.g. pictures illustrating research)
  • Java applets should not be used.”

KM4Dev Discussions

In the initial response Joitske Hulsebosch (joitske@gmail.com) very helpfully shared a link to the Aptivate website and its extensive guidelines for low bandwidth: http://www.aptivate.org/webguidelines/Guidelines.html

Contributions from Gabrielle Sani Gabriele Sani (gabrielesani@googlemail.com) and Christian Kreutz (ckreutz@gmail.com)then commented on and extended the Aptivate guidelines. Carl has synthesised these as follows:

  • The guide by Aptivate is a bit outdated (the general ideas are all good - low bandwidth=reduce page size)
  • Javascript & Ajax can reduce the number of HTTP requests, if used wisely (eg: form validation, image caching)
  • Also, if you can influence the users of your website you could suggest them to use Firefox/Opera/Safari (basically, any standards-complying browser... so far, IE doesn't fall in this category. IE8 maybe will). This would allow you to use SVG images, with a much better definition and compression rate than anything else. If not, try using image-optimization tools like PNG-Gauntlet (it reduces the file-size by 10-60%)
  • The original IDS low-connectivity guidelines still apply, you just need to add some more:
    • avoid tables with loads of content
    • put the javascripts at the bottom of the page
    • compress the pages
    • minimize the javascripts
    • minimize the number of css stylesheets
    • have an alternative css style for mobile devices
    • create RSS feed(s) and/or allow users subscriptions. (Receiving text-only updates on your topics of interest is an effective way of staying connected)
    • Invest in a well developed web design, which is purely CSS (specific style format) driven
    • Work with a minimum of photos and rather colors (from CSS) and compress photos as best as possible
    • Avoid as much as possible javascript features (for example widgets)
    • Offer different channels to access information such as email and RSS. (e.g. for mobile use)
    • Implement back-channels, so users can contribute also through email
    • Use server side compression through GZIP (can reduce the website size up to 60%) Only possible for Apache Server.
      • In Drupal GZIP page compression is on by default.
  • Have an accessible website, thus have a css stylesheet for page-readers, one for high contrast, etc. It's easy to do if planned since the start of the project, while it could be tricky if done later on.
  • If are planning to deliver an online, demand-driven KM platform (this would explain why you are so unsure on what to do) then a good choice would be to use an easily expandable platform (avoid custom-coded websites, unless you want to hire an army of coders). The three top choices at the moment are Drupal, Joomla, and Wordpress. (Drupal is probably the best fit for an online, demand-driven KM platform)
  • Drupal, Joomla and Wordpress can be used for low bandwidth websites. Bear in mind that they are Content Management Systems, thus their focus is on handling content. In a nutshell, their job is to dynamically create webpages using the server resources. For example, you can tell it to automatically create a frontpage with the latest news, or carousel of the most popular forum topics, or... whatever. On top of these core functionalities you add a "theme". A theme is a set of instructions that will tell the server how to create the HTML/CSS files that will be shown to the browsers. Since all this is work is done on the server, to design a website for low bandwidth all you need is to choose a suitable theme that will generate an accessible, standards-compliant XHTML/CSS website.
  • The great advantage of Drupal, Joomla and Wordpress is that they are modular, thus if the need rises you can easily add new functionalities, and they will seamlessly integrate with the rest of the website. Also, they are very popular, thus there is a large community of developers, and many, many modules to choose from. This is ideal for a demand-driven project, because if in the future you want to add, eg, a GoogleMap mesh-up to show all the user and content locations, and allow to search/filter data using the distance, all you will need to do is download and install a module. On Drupal, it will take you about half an hour (plus the time to enter the locations for all the users/content, but you can do it simply clicking on a map). Besides, since the theme is just like a module, you can switch to a new one in the future, or even use more than one at the same time. A pretty useful application of this feature would be to show a completely different website to different user roles, targeting information according to their needs.
  • Drupal, Joomla and Wordpress all need to be considerable changed for such an objective. All three CMS have in their normal installation a lot of unnecessary code and features:
    • The editor in Wordpress is not developed for low bandwidth use
    • Wordpress and Joomla user interface is not meant to be for low-bandwidth access
    • Joomla and Drupal have a lot of unnecessary javascript code
    • Javascript code in Drupal can be disabled simply removing the line "print $scripts" from the themes... and in some cases having some javascript is actually helpful for low bandwidth connection (eg, form validation reduces the number of HTML requests). Removing the Javascript does not reduce Drupal's core functionalities, only some contributed modules do depend on that. By default, Drupal removes any duplicate Javascript.
    • Joomla and Drupal have particular with each module a lot of unnecessary extra code such as CSS
      • In Drupal there is one page "admin/settings/performance" with some checkboxes to enable CSS optimization (and Javascript optimization). They are often overlooked because they are disabled in out-of-the-box installations as they would make the website development close to impossible. Also, if you install the excellent HTML purifier module will trim mall the useless tags/code from the whole website (removing potentially malicious code, too. Thus, you are reducing risks associated with user-generated content. This is a BIG plus).
    • The only feature that is missing by default is an automatic CSS sprite generator, but that can be fixed by the web developer.
  • Maneno tries to offer low-bandwidth blogging in Africa: http://www.maneno.org/eng/faq/
  • Offer a text version for your website, or partner with the Lo-Band service from Aptivate: http://www.loband.org

Examples in Application

[One or a few practical examples and references that illustrate the topic or show how it is done in practice]

Related FAQs

[Insert links to related FAQs]

Further Information

Original Author and Subsequent Contributors of this FAQ

Carl Jackson with Joitske Hulsebosch, Gabrielle Sani, Christian Kreutz


Dates of First Creation and Further Revisions

First created 23 April 2009

FAQ KM4Dev Source Materials

2009/4/3 Carl Jackson Dear Friends, I am putting a toe back into the world of commissioning a website design after many years out of the loop. The last time I was involved in this process we specified access orientated technical criteria so the site would work just as well in low connectivity situations. I imagine this is now hopelessly out of date (but pasted below for historians of Web 1.0). I am not even sure is a website should be the focus anymore, maybe it should be a technical specification for a portfolio of access oriented social media and mobile phone interventions. If you have recently written a technical specification for low connectivity access and could share I would be most grateful. Or if you know a good technical designer with experience in this area please share details. Best, Carl +++++++++++++++++ Technical Spec for Web Build Circa 2006 The design of the site must take into account variable levels of internet connectivity, hardware and desktop applications. It is important to ensure that the site is accessible by users based in the UK, overseas, in the office or at home. It is also important that the site is accessible to disabled users. The designs should be produced as xhtml-compliant templates and CSS. These and any graphics must be designed for fast download with minimum file sizes. The logic of the site structure, the designs and the xhtml should allow all pages to be built programmatically as dynamic pages, quickly and efficiently, from content data, meta data and navigation data held in a content management system database. Technical specifications for the site must therefore take into account the following factors: • Pages should be provided as xhtml-compliant and CSS • Xhtml should be designed for "standards compliant" browsers but should "degrade gracefully" to older browsers (version 4 and below), so pages are still usable • Pages should be usable in popular but minority browsers such as Opera and Firefox • The logic of the site structure, the designs and the xhtml should allow all pages to be built as dynamic pages, programmatically from different possible page components held in a database. They should be such as to ensure good performance, easy maintenance, and affordable programming costs. This is especially important for the navigation and other standard elements - for example the number and complexity of the different templates which are needed to be held by the system for these elements should be minimized. • Style classes should be standardized across the site so that any variations in different sections of the site or changes across the whole site, can be easily managed • The number of stylesheets to be used should be kept to a minimum. • Navigation and standard display graphics should be in gif or jpeg format • Pages should conform at least to the W3C Priority level 2 for accessibility. • Where javascript is used, pages should work for the user without it - all content and sections of the site should be accessible for non-javascript users • Pages should be designed for a screen resolution of 800x600 but taking into account larger resolutions • Flash should not be used • Frames should not be used • Animated graphics or other animations should not be used • Graphics files should be small (except for content in areas which require large files, e.g. pictures illustrating research) • Java applets should not be used.

From: Joitske Hulsebosch Sent: Saturday, April 04, 2009 12:19 PM To: KM4Dev Subject: [km4dev-l] Web Design for Low Connectivity

Hi Carl, I have not written any technical specification, but I have this resource in my bookmarks: webdesign guide for low bandwidth:

http://www.aptivate.org/webguidelines/Home.html Would that be of any help to you? Joitske


Carl,

The data on the guide by Aptivate is a bit outdated. The general ideas are all good (low bandwidth=reduce page size), but there are a few things that you could do on topm of what they suggest. Javascript & Ajax can reduce the number of HTTP requests, if used wisely (eg: form validation, image caching) Also, if you can influence the users of your website you could suggest them to use Firefox/Opera/Safari (basically, any standards-complying browser... so far, IE doesn't fall in this category. IE8 maybe will). This would allow you to use SVG images, with a much better definition and compression rate than anything else. If not, try using image-optimization tools like PNG-Gauntlet (it reduces the file-size by 10-60%) You old requirements still apply, you just need to add some more, like • avoid tables with loads on content • put the javascripts at the bottom of the page • compress the pages • minimize the javascrips • minimize the number of css stylesheet • have an alternative css style for mobile devices • create RSS feed(s) and/or allow users subscriptions. (Receiving text-only updates on your topics of interest is an effective way of staying connected)

I would strongly suggest you have an accessible website, thus have a css stylesheet for page-readers, one for high contrast, etc. It's easy to do if planned since the start of the project, while it could be tricky if done later on.

If are planning to deliver an online, demand-driven KM platform (this would explain why you are so unsure on what to do) then a good choice would be to use an easily expandable platform (avoid custom-coded websites, unless you want to hire an army of coders). The three top choices at the moment are Drupal, Joomla, and Wordpress. (IMHO, Drupal is the best fit for an online, demand-driven KM platform)

Best, Gabriele

Carl Jackson wrote: Wow, thanks Gabriele. This is all really new to me and so useful. Just as a follow on question, do you think that Drupal, Joomla and Wordpress can respond to the low bandwidth tips you mention? Carl

Carl, you are welcome!

Yes, Drupal, Joomla and Wordpress can be used for low bandwidth websites. Bear in mind that they are Content Management Systems, thus their focus is on handling content. In a nutshell, their job is to dynamically create webpages using the server resources. For example, you can tell it to automatically create a frontpage with the latest news, or carousel of the most popular forum topics, or... whatever. On top of these core functionalities you add a "theme". A theme is a set of instructions that will tell the server how to create the HTML/CSS files that will be shown to the browsers. Since all this is work is done on the server, to design a website for low bandwidth all you need is to choose a suitable theme that will generate an accessible, standards-compliant XHTML/CSS website.

The great advantage of those 3 CMS systems is that they are modular, thus if the need rises you can easily add new functionalities, and they will seamlessly integrate with the rest of the website. Also, they are very popular, thus there is a large community of developers, and many, many modules to choose from. This is ideal for a demand-driven project, because if in the future you want to add, eg, a GoogleMap mesh-up to show all the user and content locations, and allow to search/filter data using the distance, all you will need to do is download and install a module. On Drupal, it will take you about half an hour (plus the time to enter the locations for all the users/content, but you can do it simply clicking on a map). Besides, since the theme is just like a module, you can switch to a new one in the future, or even use more than one at the same time. A pretty useful application of this feature would be to show a completely different website to different user roles, targeting information according to their needs.

Best, Gabriele, wordy as usual


Carl Jackson wrote: Much appreciate the exchange Christian and Gabriele I feel I am getting a good list of wishes for my low bandwidth design Must admit I am getting a bit out of my depth on the technical side so will take your word for it. I will aim to pull these tips together and post to the our wiki. Shall check out www.maneno.org Thanks again. Carl

Christian Kreutz wrote: Hi Gabriele and Carl,

yes I agree that these content management systems (CMS) can be used for low bandwidth access, but they all need to be considerable changed for such an objective. All three CMS have in their normal installation a lot of unnecessary code and features: - The editor in Wordpress is not developed for low bandwidth use - Wordpress and Joomla user interface is not meant to be for low-bandwidth access - Joomla and Drupal have a lot of unnecessary javascript code - Joomla and Drupal have particular with each module a lot of unnecessary extra code such as CSS

But surely all three systems allow the flexibility to change them in core and make them accessible. Unfortunately the great open source community has little focus on that topic. I do not know of a good low-bandwidth solution on the market, but Maneno tries to offer low-bandwidth blogging in Africa: http://www.maneno.org/eng/faq/

Some important points to offer a a low-bandwidth website: - Invest in a well developed web design, which is purely CSS (specific style format) driven - Work with a minimum of photos and rather colors (from CSS) and compress photos as best as possible - Avoid as much as possible javascript features (for example widgets) - Offer different channels to access information such as email and RSS. (e.g. for mobile use) . Implement back-channels, so users can contribute also through email - Use server side compression through GZIP (can reduce the website size up to 60%) Only possible for Apache Server.

You can considerable reduce your website with these above steps. Of course you can also offer a text version for your website, but I am not sure your target group will like that.

Best regards

Christian

Hi Christian,

All your points are well posed, but at least on Drupal (the platform I am more familiar with), they can be easily overcome. - Javascript code in Drupal can be disabled simply removing the line "print $scripts" from the themes... and in some cases having some javascript is actually helpful for low bandwidth connection (eg, form validation reduces the number of HTML requests). Removing the Javascript does not reduce Drupal's core functionalities, only some contributed modules do depend on that. By default, Drupal removes any duplicate Javascript. - There is one page "admin/settings/performance" with some checkboxes to enable CSS optimization (and Javascript optimization). They are often overlooked because they are disabled in out-of-the-box installations as they would make the website development close to impossible. Also, if you install the excellent HTMLpurifier module will trim mall the useless tags/code from the whole website (removing potentially malicious code, too. Thus, you are reducing risks associated with user-generated content. This is a BIG plus). - It's surely true that not many themes are built to be accessible and "lean", but some are, and you easily create a new one to meet your needs. - GZIP page compression is on by default. The only feature that is missing by default is an automatic CSS sprite generator... but that can be fixed by the web developer.

Very best, Gabriele

Hi Carl,

I just took a look at maneno.org, and it's not optimized for low bandwidth. :( The code is bloated with many items that could be in a CSS stylesheet, every background uses a different image, and there is javascript (in <head>!) for purely visual effects. Also, it looks like it embeds a WYSIWYG editor...and as Christian pointed out that is a bandwidth hog. At the moment, maneno is still in beta version, thus maybe in the future it will get better.

Gabriele

Retrieved from "http://wiki.km4dev.org/index.php?title=Low-Bandwidth_Design&oldid=2737"