Maneno
RSS
l
write     admin
Subsaharska

Flash was not a risky horse to bet against

Available in: English
03 07 2010
Countries:
AFRICA
Tags:
apple, flash, loband

By now, the news that Steve Jobs has vehemently renounced Flash is not any kind of news. While I find it annoying that people will take the word of one person as gospel, it's really the case that it wasn't Jobs alone speaking at Flash's funeral. In web development circles, we've hated the technology for years.

As an accent, widget or some other non-critical piece of a website, Flash is fine. For video, it's even better. But, for a site to be completely built in Flash is inane. First there is the issue with Google in theory not being able to index it. Then there is also the issue that unless designed incredibly well, Flash site take a long time to load. In low bandwidth situations, they often never load.

Above and beyond serving information to the world, there is also the business side of things. I just finished launching a redesign of a site for a client who had had a previous site that was not even completely Flash, but just Flash heavy. Once that previous site had launched, online sales dropped by a whopping 50%. That's scary and it's the reason that the new site has not single lick of Flash in it, except for a flickr embed widget, which for some reason isn't compatible with IE8 or Opera and that's seriously weird.

So, like I said, while Jobs wasn't saying anything that any of us hadn't said before, he said it and acted in such a way that it woke up a great many people we geeks hadn't reached. Now for myself and everyone else I know in web development people tell us that they have no interest in supporting IE6 and are happy having no Flash. Ah the difference a keynote can make.

The new Twitter home page is a hater

Available in: English
05 04 2010
Countries:
AFRICA

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.

The new Twitter home page is a hater

Internet Explorer 6. You are dead to me.

Available in: English
07 12 2009
Countries:
AFRICA

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.

The Truth Comes Out

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.

Developing and Deploying in Low Bandwidth Part 4

Available in: English
18 11 2009
Countries:
AFRICA

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.

Working the WYSIWYG

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.

The Contenders

SimpleEditor

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.

WYMeditor

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.

jwysiwyg

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.

NicEdit

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.

Conclusions

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!

Picking your toolset accordingly

Available in: English
10 10 2009
Countries:
AFRICA

I was recently contacted by a former acquaintance who was working to deliver a digital outreach setup to an African company. At the core of this package there will be some kind of Facebook presence, a Twitter account, and a website built around WordPress.

This is a pretty solid setup, but is it the best for the circumstances of that particular company? Is it just that those who teach others to use these systems do so because they are familiar or because actually they function better than anything else, in every environment, in every corner of the world? For example, if language is an issue, how do you deal with that? Obviously when it comes to Facebook and Twitter, there aren't that many alternatives as they're both relatively new and emerging methods of communication. But what about blogging? It's a pretty mature medium (officially been with us for a decade now) with various free platforms such as: Blogger, Posterous, Tumblr, Typepad, and Textpattern as possible alternatives to WordPress to name a few.

I ask these questions because I see that it's often the case we recommend for people to use what it is that we're familiar and comfortable with rather than what best fits the situation. It's not to imply that someone should have a lesser product to use, but they should instead have the one that will best fit their needs and promote their online presence the best. We're so used to saying, "Oh yeah, use this, that, and the other thing" instead of really looking at the need case. We only see that someone may not have much activity online and immediately think that they need what we discern to be the best before maybe letting them play around with things. Because they maybe want to be advanced in what they do, typing up their own HTML, or maybe they want to keep things very simple and just sms or email in an article.

This is one good outgrowth of the "free model" in the web in that we can test out a lot of different systems before deciding which one is best and that decision needs to be a great deal more in the hands of the end user. Thoughts?

Developing and Deploying in Low Bandwidth Part 3

Available in: English
31 05 2009
Countries:
AFRICA

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?

Developing and Deploying in Low Bandwidth Part 3
Crude, but relatively effective.

Developing and Deploying in Low Bandwidth Part 2

Available in: English
14 03 2009
Countries:
AFRICA

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.

Developing and Deploying in Low Bandwidth Part 2
From a regular read of mine, cringely.com. Left is with AdBlock and right is without. The difference is 90kb vs. 225kb. That's huge!

Developing and Deploying in Low Bandwidth Part 1

Available in: English
27 02 2009
Countries:
AFRICA

This is the first article in my series on low bandwidth development.

One of the key things that I'm always keeping in mind when I've web makin' is how in the heck to make a website load faster. It's often the case that a lot of sites built in Europe or the US often ignore this component. While broadband in these areas is to the point of nearly being ubiquitous (even my mom out in the countryside can get it now), it's still a good idea to not go nuts and have a big fat pile of files and bytes for someone to pull down in order to see the site. This detracts from the user experience, even on fast connections because everything takes time to load, even if fast. A site that is less snappy is a site that is less user friendly and one that the user will bore of. Google get this with their sparse, yet highly functional interface. Yahoo! gets it decently well with their more full-featured, yet still rather lightweight interface. Facebook could obviously care less, which is why I'm assuming friends in African don't use it all that much. Or maybe they just don't like me anymore...

The other day I read in Aid Worker Daily (a new favorite of mine) about The Loband option. Loband is a nifty site that strips out all the images and the "what-what" to give you a very sparse, yet fully-informative website. All the content is there, just without most everything else. Sure, it's kind of ugly, but if you're on VSAT in Sub-Saharan Africa, it's a lot better than waiting a couple of minutes for each page load.

But all of this is from the group at Aptivate who I've just now become a big fan of. They're common sense web and IT folks, which are a group of folks I love as I tend to work in the same way. Being spoiled by resources makes for bad work. Having boundaries like slow machines and internet makes for much better work as you have to think and solve things within your boundaries. That being said, anyone who doesn't know of their web design guidelines should probably shut off their Photoshop and stop building sites. Some of it is extreme for conditions where your internet connection is just slightly faster than a slug, but even when you are sitting atop "fat pipes", these guidelines should be heeded. Yeah, I know that they might seem like common sense, but they are oh so often ignored in favor of using whatever slippy doo dah hoo hoo that's the latest thing in Web #.0 which the marketing folks might be crazy about at a particular moment.

Developing and Deploying in Low Bandwidth Part 1
Image from here as well as 1995.