Talk:Web design for low connectivity

See the original thread of this E-Discussion on D-Groups

Carl Jackson, 2009/03/04

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.

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.

Joitske Hulsebosch, 2009/3/4

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

Would that be of any help to you?

W.J. Pels Jaap, 2009/03/04

Hi Carl and others,

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.

So, who want that website? That portfolio of access oriented social media?

Carl Jackson, 2009/03/06

Joitske, thanks for the links to Aptivate.

The guidelines look very useful and Aptivate also consult so potentially a solution for me

Gabriele Sani, 2009/03/06

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)

Carl Jackson, 2009/03/07

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?

Gabriele Sani, 2009/03/07

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.

Christian Kreutz, 2009/03/08

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:

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.

Carl Jackson, 2009/03/08

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

Gabriele Sani, 2009/03/08

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.

Gabriele Sani, 2009/03/08

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.

Peter J. Bury, 2009/03/09

Interesting stuff all this. Something I want to know more about for a long time.

Just as I still wonder how many people in 'developing countries' can REALLY use Twitter on cell or web!?

Does someone have the time to document all this on the KM4Dev wiki? Would be really useful reference material.