For those who don't know, sexiest-dot-com-in-the-world-at-the-moment, Twitter has relaunched their homepage.
This builds on a series of changes starting last year when we redesigned the homepage to make search and trending topics more visible and easily accessible to everyone. With that version, we brought the power of search.twitter.com to the homepage and let people explore the value of Twitter without an account.
This is all fine and good as it marks what seems to be either the third or fourth iteration of their home page, but I'm curious if perhaps it goes a bit far towards the "die Explorer die" camp? I mean, for some time now, I've noticed that for Explorer 7 & 8, Twitter works alright, but it's not nearly as good as in Firefox, Chrome, Safari, or Opera. And when it comes to Explorer 6, it's a real disaster. To a degree, I support this direction, especially as Explorer 6 is a dead horse, but at the same time, Explorer still makes up just under half of the browser market and when viewing Twitter in Explorer 8, it tosses a compatibility error mode. It's not the most amazing thing in the world and I was rather surprised to see it. I'm curious as to whether it's just a temporary bug or if Twitter thinks that somehow all these Explorer users are going to vanish in the coming months? Or maybe it's more that they seem they market divesting to the tablet/mobile side of things and they don't really care about the desktop/notebook era?
My other issue is heaviness of the home page. What I've really liked about Twitter in the relatively sans-FailWhale epoch is that it's been simple, light, and quick. This home page changes a great deal of that and depending on the time of the day I access it, it is very difficult to load. Seeing as how I am indeed a member of the site, I don't really need this home page and thus, I tend to just go straight to twitter.com/login to get to a slimmer, faster way to access my account. That works quite well to bypass all the craziness of the home page and get to the Twitter I know and love.
Ultimately, it would be nice to see a couple of things come about:
- Just a bit more attention paid to at least Explorer 8.
- Streamline the home page information as now it's almost too much.
- Lighten up the bandwidth requirements of the home page as it's running about half a meg currently.
For those unfamiliar with it, The Daily WTF is a collection of ridiculous stories from technology. It has a decidedly geeky focus though, and at times, they mention a joke in some programming language that even leaves me scratching my head. But, there is an overarching theme to a great many of the articles that come through in that some geek recounts how he was hired to rehash some system, somewhere that someone cobbled together with something that somewhat worked.
While good for a laugh, it belies the fact that a lot of organizations simply do not have the budget to hire a tech or web person (at least prior to this global economic crisis anyways.) This in turn means that someone who is probably happier taking photographs or coordinating reports becomes the de facto in-house tech person and is forced to make a great number of decisions that aren't necessarily beneficial to the organization short of helping some goal limp to its finish. Then, somewhere down the line, someone stands back, shakes their head, and says, "Holy hell, this needs some advising from someone with the word 'technology' in their title."
I'm assuming that there is something of a similar backstory to this and is the reason that Tobias at Kabissa posted an open discussion about web solutions in Africa. It's a good thread, which most likely due to the tragedy in Haiti hasn't been seen by a lot of folks due to the work going on amidst the destruction there and the work that needs doing.
I just wanted to point it out as there have been a great variety of items submitted to the discussion. I wrote a lengthy chunk that I actually want to work over a bit and post here as I left out Google Sites as an option and a number of things could be refined.
Overall though, people were suggesting a great many of the CMS solutions that exist for free and for an organization with a limited budget present fantastic opportunities to leave behind whatever set of static HTML pages 27 people had added to over the last 10 years. More input is needed though and as Tobias pointed out after a number of posts had come through, there should be more of a focus on finding whatever most approximates a silver bullet insofar as a solution goes. Naturally this varies a great deal given the environment and focus of the organization, but still there are a number of different options that are all good, but most of us showed up to the discussion ready to ride our favorite bicycle, which probably hasn't helped the organization in deciding on what they should go with. I suppose it's because ultimately there is no perfect solution and so, the discussion needs more discussing.
Over at Le petit nègre (his title, not mine) it has been proposed to have the #afroflop awards for the worst-designed African websites on the web.
The starting point of these awards is the recognition that the majority of sites WAF [Web Africain Francophone] are supposed to lead by example but are absolutely poor in terms of design, usability and accessibility. And nothing and no one seems to do anything about it. I generalize, of course, some players try to remedy this picture, but their voices are either ignored or misunderstood.
He has initially proposed all of this in French, but I think a great deal of it carries to any other site in any other language as well. Naturally, your choices in foul design should be guided by these principles:
Is the loading time lengthy? Does the site does crash your browser?Does the presence of Flash, Silverlight, Java, make the site more or less usable?
Is the content easily accessible and enhanced by the look of the site?
To participate in this, all you need to do is reply to @lepetitnegre on Twitter with the link and the hash #afroflop. Ah yes, you also need to specify as to which category of failure:
#load - the worst / long time to load a site#design
#animation
#public - worst site for a public/government institution
#private - worst private company, NGO, or other site
#biz - worst e-commerce site (including social networks)
#people - worst personal site (artists, politicians, famous character, personal blog, etc. ...)
#waf - worst site overall
As he mentioned, a site can belong to more than one of these categories and a great many probably do. Also, while #waf is specific to his competition in French, I think it could easily be called the Worst AfroFlop as well, so it still works.
Anyways, just something fun that Twiga pointed out to me as it dealt with web design. And again, let me emphasize that this is not my idea, I'm just translating it. So if you're in to it and quote me on it, quote Le petit nègre as well, since he came up with it.
Hundreds if not tens of hundreds of my fellow web developers the world over have been wanting to burn Microsoft's Internet Explorer version 6 off the face of the earth for nearly a decade now. And honestly, I've been there along the way as well, pitchfork in hand, setting up a site with a widget called, End6! (multilingual of course) to vent my frustrations. Suffice to say, all of us developers hate it because it's broken and it won't go away. For all of you who aren't developers, it works decently well overall, although is showing its age these days and naturally leaves your system open to any number of nasty viruses; upgrade whenever possible. Please. I beg of you.
It wasn't the fact that it doesn't display Bambara or Fula characters properly that put me over the top. It wasn't this article that talks about the fact that even Microsoft who deployed this hellish concoction of code upon the world are now saying, "Uh yeah, that thing is no good. Upgrade to the latest and greatest." It was deploying the new features last week that did me in. All of that looks smashingly great in every single browser in current use except IE6. So, for about 90% of the internet, it's perfect. After wrestling with it for about a half hour I finally said, "You know what, screw it." It's a dying browser and we need to look towards the future. I'm not going to compromise my code for a system that just doesn't work. Yeah, I'll monkey around to get it functional, but I'm done with trying to get to look exactly like the other browsers out there.
This comes at a time where we have indeed seen IE6 usage drop by 50% over the last year. I'm assuming that by the end of January, we'll see even more of it drop off as a lot of people will actually decide to upgrade from Windows XP and will get a bright, shiny copy of Explorer 8 with Windows 7. Or maybe they'll go Mac, in which they'll be using Safari, Firefox, or Chrome. Whatever the case, despite the fact that there was a slight uptick, or that IE6 usage stayed nearly the same from last month, it is definitely going away and now all those web developers who were begging people to upgrade need to take the next big step and just stop supporting it altogether. Yeah, I know, possibly losing 10% of your traffic could be detrimental, but as the article on downloadsquad.com points out above, it's not home users who are the problem.
All this time people pointed some incredibly ignorant fingers at other parts of the world in regards to IE6 usage; specifically Africa. The assumption was that people there weren't upgrading because their computers were too old, or because they didn't have the technical capacity, or any other number of ill-reasoned ideas.
Now, it is true that you'll still run in to IE6 in internet cafes here and there. Those cafe owners rarely seem to want to bother to upgrade. But for anyone who has their own computer, I've always found them to be using whatever the newest browser is that they can get. Often, they're even on some beta version. In other words, the problem is not Africa. I mean, think about it. Africa currently makes up less than 3% of all the internet traffic in the world. How could they account for the 10-12% of users on IE6 still? These numbers don't and have never added up.
It's only now that people see where the real culprit is, which are corporations who, for some reason, bet the house on building applications to run on a single web browser--forever. One big offender is the insurance company, AllState who are indeed using IE6 in all their offices. Yet another tremendous offender is the UN. Yes, that international body deploys systems in the field with IE6, still. I've seen it firsthand and heard from friends working in various capacities that they are cursed with this thing.
This gets back to a previous article which was about what screen size one should design a website for if deploying it in Africa. That same logic in the past would say that yes, you absolutely must support IE6 if targeting a site towards Africa. I say that while you can't ignore it altogether like you can IE5.5 or Netscape 4, at the same time, you need to just make sure it will function okay in IE6 without crashing the computer. But, if making sure that your website works perfectly because some IT guy at a US insurance company won't upgrade the system, then in brutal honestly, screw them.
As a side note to all of this, if you want to just block IE6 users on your site altogether, don't rely on JavaScript. Use browscap.ini to sniff out and block accordingly. Fire up IE6 or download IETester and take a look at my personal site, www.hudin.com to see how I'm dealing with it there.
This is a continuation in my series on low bandwidth development.
The almighty WYSIWYG. It's a tool that makes life on the net a great deal easier for most everyone. Those of us who are web developers rain scorn down upon these systems, but it's awfully arrogant of my coding brethren to do that as we live and eat code all day long. For those that don't, it is a massive pain and even a obstacle to working on the web if one has to type in all the direct HTML code.
Don't get me wrong, I'm completely against a WYSIWYG for overall web development. What DreamWeaver does when it creates code for a site is criminal. But, when it's the case that someone needs to write something in a text field on a website (like an article or a comment), there is a definite need for this tool as the web thrives on links. If people don't link, then there isn't much of a web, and I think that many people don't link because of the need to use HTML code.
About four years ago, I was an IT Manager for a publishing company and one of my direct reports was working on setting up a WYSIWYG for an internal website to edit articles for online publication. He came back to me a week later and said, "Well, I've got one in place. It's pretty decent, although it only works in Firefox, not Explorer, and completely heaves on itself in Safari..." I shook my head sadly as we had to deploy it like that because those were ugly times, but they have since changed a great deal. These days the WYSIWYG of choice is TinyMCE. Wickedly powerful and full of every option in the world to obfuscate direct HTML coding from the end user, it is by and large, the choice of many.
There are two glaring issues with TinyMCE. One is that you might very well not need all the power that it packs (think of driving a Ferrari in rush hour traffic.) The second and much larger issue is that in its full state, it's a whopping 320kb! Minified, it drops to 175kb and if you have the ability to compress it, you can get it to about 60kb. And this is before adding in images and styles, which will add another 10-20kb depending on how you want it to look.
So, for the purposes of creating a light, quick to download site, TinyMCE is simply not going to work. This has been noted by a great many people who have set out to create alternatives that, while having less options, are most likely easier to implement and considerably lighter to download. As I've been working to improve the WYSIWYG editing abilities on Maneno, I've been working through a number of these and following are my thoughts on how some of them implement.
For those using the MooTools JavaScript library (which I like a great deal), as the name implies, this is a very simple editor that works to complement the library and provide a simpler method to writing code without having to know code. The filesize is 15kb when minified and 5kb once compressed. Can't beat that really which is why I've been using it for some time.
The only downside is that it is indeed a very basic editor and it doesn't hide the HTML code, it just inserts it automatically. It's mainly for these reasons that I'm shifting away from it as while this system works nicely for me, it isn't so great for the intended audience, who are those folks that would much rather not deal with code.
Also, for the MooTools library, there is MooRTE, but I haven't really spent enough time with it to give feedback other than to say it's there and give it a go if you've got the time.
I tried this editor out briefly. It has promise and is a good deal smaller than TinyMCE, but the problem is that it's still 76kb when minified. It's just too big to be used on a low bandwidth site. It also requires jQuery, which while a very nice library, will increase your download footprint by 20kb by having it around.
I've been moving a lot of things I work on over to use jQuery. The reasons behind this are the topic of a much larger and much geekier article than I think most people would want to read right now. But in doing this, I was looking around for an editor that would take advantage of the library. I thought that jwysiwyg would be just the thing. It's quite light, simple, and seems like a good tool despite only being at version 0.5.
Turns out, there are many problems with this system. If you just want to plunk it in to whatever you're using, it should be somewhat okay. But the code hasn't had an update in almost a year and requires a number of hacks to work with Explorer 8. Also, modifying it has problems and functions such as ordered and unordered lists just don't work well.
I'm not sure what's going on with this project, but it doesn't seem to be in a good state at the moment. This is a shame as the intentions behind it are quite solid and something I would like to encourage the developers to continue to work on if they have the time.
At the moment, this is my choice. You can squeeze out a very lean version of it if the download page works well for you. Unfortunately to get it to work well, you need to customize your download, get it in the full (not the compressed version) and then use something like a YUI compressor to get it smaller. I have no idea as to what's up with this and that's one unfortunate side in system that the developer doesn't appear to be able to offer any support currently, which I can't fault him for as he gives away the product for free.
I have needed to customize the download a good deal for my needs and amazingly, it's taken well to this, which was refreshing. It doesn't rely on any outside JS libraries, so you don't have to worry about breaking an dependencies. It's all self contained and happily working with itself.
The only big issue beyond the source downloading problem is that if it appears the system is built mainly around AJAX form submissions, which is very cool for those only doing that. For those who are doing a more traditional posting of form submissions, you'll need to shift the content of the WYSWYIG in to a form data item to actually get it. Not a terribly hard thing to do, but it will drive you insane until you realize that that isn't happening.
This is my take on a number of editors. If you have other suggestions, please feel free to contribute below. I'm actually going to be rolling out some work with the NicEdit system in the next few days, so you'll be able to see that in action. It will be in a limited fashion though, so if you show me something that's better, I'll gladly give it a try!
I'm currently based in Spain. There is good connectivity here. In fact calling it "broadband" is a fair term. But for some reason, I am constantly getting errors like the one you see above on Facebook. I don't know what's causing it, but contrary to the message in the window, I am indeed very much connected to the internet.
AJAX is a cool system as it offers one the ability to grab a snippet of a site and in theory, incur much less bandwidth in making that request, thus speeding up website interactions for those on slower connections. There's just the problem of latency as well as a great many other issues when it comes to how you actually implement AJAX. Personally, I know how easy it is to think, "Sure, that request is fine. No problems. I never have to worry about it failing." But in reality you do. Modern web design is sloppy this way and if you don't chain AJAX events to be dependent on one another, you get results like this. We talked about this a good deal at the AfricaCodeCamp as it isn't just a good design strategy for African websites, but also a good one for any website.
In Facebook's defense, at least there actually are error messages, but still, they could do more. I have to hand it to Twitter, as I have far fewer problems with their site from where I am and they know how to make the site degrade properly. For instance, if you try to click on the Sign In link on the main page before all the JavaScript and widgets are loaded, you'll go to the more basic, non-fancy login page. It's a small detail, but it improves the user experience. With how much Facebook is copying what Twitter is doing, you'd think they would copy some of these things as well.
While it may date me to a certain extent, I remember the short-lived days of having to design a site with a maximum width of 600 pixels. Man, those were ugly days. But, what could you do if someone's monitor was only 640 pixels wide and you wanted to make sure that with scroll bars and everything else, your site would fit on their screen? You designed for 600 wide, that's what you did.
In 2000, things quickly changed and 750 became the standard width as you designed for an 800 pixel minimum width screen. Then in 2005, we started to really go nuts and make things 950 wide as the thinking was that most people had a screen that was at least 1024 pixels wide. This day and age, folks are generally pushing 1000 width and sometimes more depending on the market. The trends are quite excellently illustrated in the table below, which you can see in their entirety at the always excellent w3schools.com.
| Date | Higher | 1024x768 | 800x600 | 640x480 | Unknown |
|---|---|---|---|---|---|
| January 2009 | 57% | 36% | 4% | 0% | 3% |
| January 2008 | 38% | 48% | 8% | 0% | 6% |
| January 2007 | 26% | 54% | 14% | 0% | 6% |
| January 2006 | 17% | 57% | 20% | 0% | 6% |
| January 2005 | 12% | 53% | 30% | 0% | 5% |
| January 2004 | 10% | 47% | 37% | 1% | 5% |
| January 2003 | 6% | 40% | 47% | 2% | 5% |
| January 2002 | 6% | 34% | 52% | 3% | 5% |
| January 2001 | 5% | 29% | 55% | 6% | 5% |
| January 2000 | 4% | 25% | 56% | 11% | 4% |
Naturally one might ask, "Why not just build a site of flexible width instead of fixed to solve the problem altogether?" I have yet to see any site that expands well. While they may look good at smaller widths, once expanded, they always funk out in my opinion. If anyone has an example that works well, let me know.
But I bring this up as a day or two ago, a fellow contacted me asking about the proper screen width for a website that would be focused most entirely on African users. Essentially his organization wanted to try and figure out the ideal width for a site so that it wouldn't be too wide for users to see on the screens they're using. It's a naturally question given that screen widths on a per country basis, not only in Africa, but around the world, are very hard to come by.
It is true that a number of the old website width rules come in to play as a great deal of hardware from North America and Europe ends up in Africa, whether to use or be dangerously recycled and dumped.
Of course the big question to ask, is where in Africa are you talking about? If it's countries like Kenya, South Africa, Ghana, Cote d'Ivoire, Senegal, or others with a burgeoning online community, you can most probably design for 1000px as from what I've seen personally, those who are online are using either brand new or relatively new hardware that is not only at least 1024 in width, but often 1200 or more. If you need to take in to account all of Africa, then okay, you probably need to think about things a bit more as undoubtedly there are a number of 800x600 screens still floating around. There might even be some 640x480 tucked away, but I doubt they'd still be functional at this point and there are a lot of newer, wide CRT monitors coming in for those who can't afford to upgrade due to so many individuals and companies in North America and Europe switching to LCD screens.
This is the width of this site and the target width of all sites on Maneno. In fact, for most sites I contract to build, I typically aim for 900 in general as it allows the site to show up perfectly fine on anything from the newest monitor down to a 1024 width screen. I mean, for the purposes of this site, over the last month, there were less than 2% of the visitors who had an 800 width screen, none with a 640, 18% with 1024, and the rest (about 78%) with a screen of 1200 pixels or more. Yes, you read that right in that nearly 80% of the users have a width of 1200 pixels or more.
So, while that 2% will have to scroll some of the content, the other 96% will see the site perfectly fine and even have room for it to expand. And that's the thing as I know a variety of website entities out there have mandates to serve the absolute maximum number of users. For instance the BBC still supports Mac OS 8&9 and Windows 95&98 (their testing lab must have some ugly, dusty boxes in it.) But in trying to slim down your site to reach every single person, you are limiting the possibilities of the website. As an example, you probably will avoid a lot of JavaScript if you have to support old Netscape or Explorer versions. This in turn creates a second-rate product. And why should Africans get a second-rate product?
I'm of the opinion to build websites with the same line of thinking no matter who is the user in that you build for the masses and try to maintain accessibility for those outside what the masses are using. From everything I'm seeing that means that if you're targeting African users as a whole and not just specific countries, build for 900 and within two years, 1050. The next two years are going to see some massive ICT growth on the continent. I'm going to laugh heartily if some developer in Nairobi is building a site in 2011 and grumbles about having to keep it to 1200 maximum width instead of 1400 in order to support all the users in the US still using old machines.
It seems that we at Maneno weren't the only ones to take advantage of summer doldrums to do something of a look refresh. Our friends at Kabissa did a complete rebuild of their system in Drupal which gave them a new look as well as more refined functionality. MobileActive.org also launched a new site based on Drupal. The blog Jackfruity got a new look as well as 27 months and Chris Blattman. Obviously redesigns are a dime a dozen in the every changing webscape, but I brought up these examples as they generally focus on African issues.
Making things prettier is always good, but having been a web developer for over a decade now, it's interesting to see how design cycles work. We started out with static web pages, moved in to dynamic web pages, then moved in to mashups pages, then CMS pages, and now it's something of a mix of all these, but hosted in the ever-fluffed up Cloud. Don't get me wrong, The Cloud is here to stay, but in lieu of actual news due to the depressed world economy, it seems that anything 'Cloud' and anything 'Twitter' are pretty much all there is to report on in the technology scene.
Probably the most interesting thing about these rehashes of the web is how they touch the non-profit or NGO sphere in the last phase. At the start of this year I remember watching a talk where one of the speakers said, "Yeah and this system lets you create a Google Maps mashup which was totally cool in 2005." He was right when he said that because it was part of a software package targeted at non-profits in the US. I'm guessing that they had run their course in selling it to corporate customers some time earlier.
But now, what seems to be the big buzz in non-profit communities is all around Drupal. Everyone wants to have their site based in Drupal to impress I don't know who, because a properly set up Drupal site doesn't let on that it's in Drupal. But, Drupal does do what it is built to do well. It allows people to set up a content management system reasonably quickly. The real advantage though is in the case of a group like Kabissa where they wanted to have an initial CMS (Content Management System) but at the same time were able to add a great many things to the core of it. In their case it's to flesh out their directory system. I assume that it's a similar case for MobileActive, although they seem to have a greater focus on their blog, so I don't know why they went with Drupal as I've not been tremendously impressed by the blogging setups in any of the CMSs out there including Drupal.
The problem with any CMS whether it be Drupal, Joomla, Plone or many others is that they are not a one size fits all, one stop shop solution. Groups seem to run in to these things blindly that way and it's often done because they think it's going to be cheap, they have limited funds, and it's going to be fast.
I've worked with Drupal and Joomla before and let me tell you that there is nothing fast about getting a site going with them. Tossing up a site is indeed, easy, but tossing up a site that looks like your organization's site is not. Everyone thinks that they can avoid having to hire some guy like me to get a site going, but unfortunately for them and fortunately for me, it's still the case they need to get a geek on board and generally at quite a cost. This is one of the reasons that in the for-profit world the CMS is in decline in popularity.
A word to the wise out there for any group getting ready to rebuild their site in a CMS: consider everything. There are many free hosted solutions out there these days and even though they will have their limits, your kilometerage will probably be a great deal more if you take a look at them. Google Sites and Yola are two that spring to mind. We're also working to build a hosted site function in to Maneno which the BarCamp Africa site is the first, very beta, version of.
But people need to site back and look at how much they have to spend on a site redo and how important the website is to their organization. If your organization is working in Africa, then the website is crucial to your operations and should be considered as important an expense as office space. Trying to cut corners will not only show, but it will hamper your activities a great deal.
To close, a number of people initially asked us why we didn't build Maneno on Drupal or even Wordpress since we're focused on blogging. The simple answer to both of these is that Drupal and Wordpress have paltry multilingual abilities. Yes, you can create a single site in just about any language you want quite well, but having them in multiple languages within the same domain is onerous. On top of that, while Drupal can be slimmed down a good deal depending on your bandwidth needs, Wordpress, is one heavy mutha on the administrative side of things. This is why we have created Maneno anew and to honest, if we weren't doing that, what value would be really be bringing to net?
This is a continuation in my series on low bandwidth development.
When it comes to the low bandwidth market of web development, you're bound to encounter old browsers, or more to the point, "non-modern" browsers. Typically, "modern" browsers are Firefox, Chrome, Opera, and Safari. You may be asking, "What about Internet Explorer?" That one gets tricky. While version 6 is often lumped in to the group, most people don't consider Explorer a modern browser until version 7 or even 8. Some don't even consider 8 to be "modern" either as its HTML 5 support is sketchy. Of course, the newest browsers aren't the truly impossible issue for those of us developing in the low bandwidth environs.
What is difficult is supporting older browsers. There is a lot of Explorer 6 running around still (about 25% of the browsers out there actually). There is even some Explorer 5.5, Explorer for Mac OS 9 (the infamous 5.23), as well as Mozilla, and Netscape. Most of these browsers have been discontinued. It's hard to even get copies of the old versions let alone an actual system to run them on. Most of the time, you can usually just let this be, but sometimes it's more of a worry.
One day, when testing out Maneno with IETester (one of the finest things a web developer could ever download), I found that in Explorer 5.5, part of the site would keep refreshing out of control. It was unusable and pretty much unstable. While the site was also ugly to view in 5.5 (because 5.5 is a heap of junk for CSS support), this posed more of a problem and there was definitely no way I was going to bother hunting down the issue for the tiny bit of traffic that arrived on that browser. I realized that this browser would have to be blocked somehow.
A pet project of mine is End6. It's a simple JavaScript widget that appears only if someone is using Explorer 6 (also a heap of junk for those who don't know). It's a simple prompt to get people to upgrade. A bit more than passive and a bit less than aggressive. I'd suggest taking a look if you want to try to get people off Explorer 6, which benefits all of us from end user to developer. Unfortunately this widget isn't enough. People can still access the site once they click through the warning. No, completely blocking some of these troublesome browsers that could cause the user problems is the only real way to go, as it is for many websites.
So enters browscap.ini. This is a browser definitions system that generally stays up to date with whatever browsers come out. The current version doesn't yet recognize Firefox 3.5 beta 4, but I wrote that in. It's available in PHP, ASP, and can be downloaded in a raw form as well to meld to your specific needs. All told, it's mighty cool.
Maneno is built in PHP, so it's rather easy to implement. You just edit your php.ini file to point at this ini file and then program as you want for implementation. I check to first make sure that $_SERVER['HTTP_USER_AGENT'] isn't empty as it will often be for search engine spiders or others. Then I call get_browser() and it gives you a lovely, associative array of such things as "browser" and "version". Run some simple logic to check against them and then kick out users to a warning page (see below) if they have too old of a browser. Post some links to more "modern browsers" so there is a call to upgrade as well. We're currently blocking anything older than Explorer 6, Firefox 2, all of Mozilla, and all of Netscape. I would have loved to block Explorer 6 as well, but given the high percentage of deployment in our user base, it's just not possible currently.
All told, these blocked browsers make up about less than 0.75% of Maneno's traffic. Why care about such a small amount? Well, for starters, upgrading is good for these folks if they do it, since these browsers aren't generally supported, and in the case of old Explorer version, extremely insecure to use. For another reason, it's to make sure that people are using browsers that I can test. Otherwise, I don't want something unforeseen to happen to their system because I couldn't anticipate it.
But what about if they can't download a new browser due to super low bandwidth issues? For this, I am currently working on sending small flash drives to selected folks that have Firefox on them in French and English, so that they can install them anywhere that is needed. I encourage others to do the same or bring a burned installation CD with them to do the same thing. And why is there no problem torrent for Firefox? That would make all this a lot easier as it could be downloaded gradually! Maybe Maneno should host this?
This is a continuation in my series on low bandwidth development.
When thinking about development, one absolutely has to think about deployment and when you think about that, you have to think about the issues surrounding the end user actually viewing the site that you put forth.
The first thing that's key in all of this is Firefox. It's a secure, solid browser that beats the stuffing out of Internet Explorer in any head to head test of the two. The browser can be had in a great number of languages, including all of the Colonial languages of Africa. There is, in theory, a Swahili version floating around as well, but it doesn't get official support from Firefox, which is a shame. Hopefully some folks can get on board to change that as well as bring out Yoruba, Akan, Lingala, Zulu, and a few others as well. The current version of Firefox does have some issues in tying up bandwidth though, which I wrote about how to get around in a previous article.
But probably the best thing about this browser from the user side are the Addons. Various elements can be plugged in to the browser to help out the user. The one I like the best when dealing with a slow connection is AdBlock. This slams the door on externally loaded ads from appearing on a website. Sometimes it can have unfortunate effects, such as photos not displaying in Facebook. It is also controversial as people make money from displaying ads on their sites and if you're shutting that off, aren't you stealing from them? According to one person who got a lot of press, yes you are, but that campaign is now thankfully dead in the water. What people don't realize is that if you're blocking ads, you're probably not going to be clicking on them anyway.
What is most important to remember in using AdBlock is that it's going to save a user endless amounts of bandwidth. Even when bandwidth is precious, ad servers don't care. If you take all of those out of the equation, you can quickly get to the website and the information that you wanted in the first place as you see in the example below. If you're not using it already, I recommend checking it out.
I'll come back to Firefox again in future articles as there are a great many of these Addons that I use in web development.
