UPDATE: added screenshots of name lookups and traceroutes
Content Delivery Networks (CDNs) are designed in such a way that content retrieval is routed to the closest server to you. This, in general, should make for faster downloads. How does the CDN know which server to present for content retrieval? This is usually done during the name lookup phase of the request.
Say you wanted to retrieve content from
d1u2s20mo6at4b.cloudfront.net; your browser will ask the network for the IP of that address. Depending on how your name resolution is setup, you can have varied results. For most people who use the default name servers that their ISPs give them, you should be fine. For me, it was more interesting. You see, I don't normally use the default name server settings; I use dnscrypt.eu for my name resolutions; so you can imagine the surprise I had when I noticed downloads from the CloudFront's CDN were quite slow; after further investigations, I noticed that for some reason, CloudFront was giving me a server located in Singapore to retrieve content from.
Now I live in Lagos, Nigeria and so it made no sense that I would be downloading content from a server in Singapore when Europe is closer to me and would get better download speeds. After close inspection, the culprit ended up being my name resolution service provider - dnscrypt.eu. Although having servers in Europe, for some odd reason, CloudFront thinks the closest servers are in Singapore. By simply switching to a public DNS like Google's (or even using the default provided by my ISP), I was able to download faster from a server in Frankfurt and then later in London.
I'm one of those people who would rather do everything with a keyboard than
have to switch from using the keyboard to the mouse even momentarily, and the
reason? It's just a plain waste of time. Everytime you have to switch from
using the keyboard to using the mouse, you context switch and this can cost
you valueable time and attention. Unfortunately, user interface elements like
message dialogs are here to stay and they are useful.
How do you interact with a message dialog like the one pictured above with
the keyboard? Until now, I had to cycle through the buttons by repeatedly
pressing the ⇥ (TAB) key until the button I wanted to activate was
I found a post
that documents other, albeit better approaches.
- Pressing space (SPACE) selects the active button (blue outline)
- Pressing esc (ESC) will choose the cancel button
- Pressing ↩ (RETURN) selects the default button (blue, pulsing, filled)
- On some other dialogs, pressing ⌘+firstletter will select
the button whose text starts with firstletter
I've noticed a particular trend with a lot of startup companies in Nigeria - they start out by buying or obtaining an email list and then subscribe them automatically to their blasted email lists - all that talk about growth hacking and shit. Not that I'm faulting trying to obtain an email list but here's one approach that I reckon is more polite. Start by asking for permission to be included in your mailing list and respect people's decision not to subscribe. Here's one example of how an email like that could look.
Men often have a difficult time dress properly for all sorts of occasions; "What colour of tie do I wear to that function." "What pair of socks go with these pants." You get the idea. My mission is to help them by providing information about what to wear and for what occasion, how to combine pieces of clothing so they match and are pleasing and other fashion-related tips.
Because I got your email from a paid email list, I'm going to ask that you take an additional step to sign up for my newsletter. Don't worry if you're not interested, you will not hear from me again (I respect you that much). If on the other hand, you're not interested because you do not relate, why not do your clueless male (and female) friends a favour by sharing this email with them?
Thanks for your time and have a lovely day.
Now how's that for an introductory email?
I just read Chris Zacharias' blog post on Page Weight Matters, where he described his attempts of creating a Youtube Lite version (called Feather) and what his results were like. Just in case you don't have enough time to read it (even though I really suggest you do), he aimed at reading a video watch page to under 100kb and the biggest boost in traffic came from places like Southeast Asia, South America and Africa.
His post summarizes my thoughts on how web applications should be built for Africa, more especially the mobile web. In most parts of Nigeria, you would be very lucky to get a 3G connection and in my experience, surfing the web when you're out of 3G coverage can be a real pain in the butt. Why's this so? Besides the very high latencies you start to experience when you're dropped to 2.5G or 2G connections, bandwidth is highly limited. With some mobile web pages measuring up to 1MB in size, you cannot begin to imagine how long it will take for that page to be loaded. It takes an extremely large amount of patience to wait almost indefinitely for a web page to load and except the user has almost nothing to do and is just waiting for the bus to reach their destination, we would lose our users very fast. When we complain about low web usage on the continent, this is one of the reasons.
Here are a couple of tips on things you could do to keep your web pages as lean and fast as possible:
If the browser supports it, use server-side compression - This cannot be overstated. Even if you're unable to implement any of the other tips listed here, at the very least use this one.
Allow for proper caching of assets - The proper use of the Expires and Last-Modified headers give information to the browser on how long they are allowed to cache certain assets and encourage reuse. You should at least cache your js and css files since those ones change infrequently.
Try and keep your web pages as small as possible - If you're designing for mobile, recognize that it's better to have 10 smaller pages that load quickly than 1 page that takes a really long time to load. The ability for your user to move quickly through your web app or site will provide more user satisfaction than if they had one really large page providing every bit of information.
Recognize that size isn't everything - You can have a web page that is 1KB in size but takes 30s to generate; a 30KB web page that loads in 1s is way better. Speed matters and you should aim for 100ms or less. If your site is experiencing a lot of hits, the performance will degrade and you don't want your site slowing to a crawl.
There are many more tips to making your web pages load as quickly as possible, one of the best guides out there is the Best Practices for Speeding Up Your Web Site.
Dipo just hinted me about GTB's Mobile Money service. Initially I thought: "Isn't it the same thing as the MTN Mobile Money service?" It turned out that this is an entirely different service. I'm not going to even go in the direction of wondering why they were creating a parallel mobile money service.
I was pleased to see this wasn't a USSD or SMS-based service and grabbed the app for Android as published on the same service description page.
My first thoughts, "nice looking app". The registration process was quick and painless. I was activated and was using the app in no time. Until things started going south. First, I started wondering, how do I get money onto this service? There are no instructions on how to do that. I even remembered seeing GTB Mobile Money on Quickteller and tried using that option and I kept getting the error:
: Unrecognised customer information supplied: Service: GTMobileMoney, Wallet number (080XXX): 080********
For me that's a catastrophic fail! How do you release a product to the market that doesn't work? That's not the end of it. Then I tried some of the options on the screen. Airtime doesn't work, Bills Payment doesn't work, Mobile Banking doesn't work; why are they even on that screen? All you need to put there are the features that work. It's totally unprofessional for a user to click on a feature and get: "Feature not yet available. Will be available soon." What does that mean? I'll rather that I know that all I can do is Send Money and pay merchants. This isn't the way you build a mobile app.