When set this way, that width of 600 appears to become the maximum width, instead. Now it scales down perfectly!
Note: As of writing, this whole Google+ comments thing is an unofficial feature (it was lifted from Blogger, the only place that officially has it), so it could break practically any time — and this tweak may not function the next time you get up from bed. Keep an eye on it… At least until Google releases an official API.
This site runs on the Kirby CMS. Included within it is the Smartypants library — it enhances simple typography, like turning don't into don’t. It’s nifty, and it saves me some time and pre-processing. But, like all other “features”, I have to ask myself the money question: Is this feature going to cost my server? Is it worth the extra code effort? After all, it’s not a huge deal for me to do this myself. What should I do?
The answer, of course, is to find solid data.
There’s just one issue with getting said data: other people’s data doesn’t always fit my case, and while there are tons of good benchmarking software out there, they tend to be complicated to install and learn. This is where Siege comes in.
Siege is a simple benchmarking app that simply runs on the terminal. You throw it a URL (and some optional configuration), and it throws you numbers. Like this:
Now, before I get sexy with Siege, first I need to figure out if Smartypants is even an issue in the first place. I’ve talked about Cachegrind before — a part of Xdebug, it allows me to see where PHP spends its time on a script. If Smartypants were an issue, it’d show up as a time-consuming process.
Let’s take a look. I visited my homepage, and passed the results to webgrind, a web front-end, and…
Okay, it’s clearly an issue: it’s taking more time (e.g. has a higher “Cost”) than pretty much everything else in the script. It’s even slower than Kirby’s Markdown processing!
While this tells me that Smartypants needs attention, it doesn’t guarantee that it’s an issue. A lot more happens on a server than PHP parsing. And I need a way to measure and compare whatever improvements I make.
Some people try to measure script execution times, but those vary too much, and don’t simulate a server under pressure.
Installing siege is easy. People on Ubuntu can pretty much just do:
sudo apt-get install siege
If you’re on OS X or just want to install manually, you can also try the instructions here. In a nutshell, get the code, extract it, open the folder in a terminal, and do the usual ./configure && make && make install on it.
Now you can call up Siege straight from the terminal whenever you want!
Time to figure out just how bad Smartypants affects my code.
Launch the Siege!
I’ll start by SSHing into my server to start the test. Yes, the same server where the site is hosted — simply because I don’t want network latency to be an issue. I only want to see how well my code is performing.
From there, it’s a simple call to siege:
siege -i -b -t1M r7.web.id
This will create 15 clients (by default) to bombard my site. It’ll try to get a response and immediately make another request afterwards… Over and over. It will last for one minute. It’ll only hit my homepage, although there are options to give it a list of URLs to hit instead. My site is mostly uniform, and I expect most visitors to stay on my homepage, so this shouldn’t be a problem.
I flip Smartypants to on. One minute later, I get my results.
This is all really nifty data. I’m simulating 15 users constantly refreshing as fast as they can. During the span of one minute, they managed to load the page 2122 times.
The most important number is Response Time. This shows how long, on average, the server took to reply to a user HTTP request (when the server is at load, as this simulates). 420 milliseconds is unacceptably long for me. It means your average user has to wait at least 420ms before getting the first byte from the server, and that sucks. We’ll need to take a look at that.
(Note, however, that this is in stressed conditions. The Shortest transaction is only 90ms, which is just fine.)
Glancing at the other numbers, we look fine. The Throughput looks low, but that’s because our bottleneck lies in code execution, not bandwidth. If I were using Siege from a remote server, then this would be affected by my bandwidth. I also don’t have any Failed transactions, which is a good thing.
Right. Let’s do the comparison. I’ll switch Smartypants off.
Right off the bat, we can see that the server managed to serve 50% more transactions overall. The response time dropped from 420ms to 270ms — a huge difference.
I now know that Smartypants accounts for a lot of my site’s processing. Well, Smartypants is basically just a function that runs on text — there’s no reason for it to run every time someone views a page, is there? It only needs to process text once.
There’s a terrible truth to how we imagine colors in interfaces. Sometimes what you see doesn’t really match what other people see.
Please submit the following form. Options in red are required.
Would you write a user biography? Would you know what format to write your date of birth in? Would you even submit the form, since there’s obviously no red on it?
I was looking over a friend’s latest work when I stumbled upon his idea of error messages: red text, written in small letters above the form. His teacher told him that “any user would immediately recognize and react to the red text”. He even justified it by pointing out how red text is used all over the world for “warning”.
Sadly, that’s not true.
See that form up there? That’s how a good 1% or so of people see red text.
The culprit is Protanopia. It’s a form of color blindness that makes it hard to tell red from green, and yellow to blue.
If that doesn’t sound alarming to you, it should!
This is how the above form would look otherwise:
If you look closely at the first image, you’d notice that some text was in a very dull shade of green; that’s how red looks to people with protanopia. Couple that with a screen not very well lit or calibrated, and it’s clear how making text red is almost invisible to some people.
It’s not rare at all, either; protanopia is one of the most common forms of color blindness. About one to two percent of males have it, while a smaller portion of females have it too. That means there’s a dozen or so affected people at your average rock concert.
So next time, highlight stuff with more than color alone. Put it in a box - use a warning icon. Make it bolder. Write it somewhere distinct.
Tip: You can also test your site, app or graphics with the really cool Color Oracle tool!
It’s December, 2012. While the so-called doomsday advocates take a pounding for their horribly wrong “predictions”, people in Jakarta are taking cover from their own catastrophe: Floods.
And this being 2012 — year of smartphones and tablets — the whole city pokes their government and asks the obvious: why didn’t we know it was gonna flood?
Would it be so hard as to, I don’t know, broadcast it over some nationwide system?
I did my research, so I can answer pretty clearly: Because the system sucks. No, seriously — at least right now.
You see, it does exist — in a sense, at least. The government has this thing called Sijampang. It stands for “Sistem Informasi Hujan dan Genangan Berbasis Keruangan”. Fancy words for “weather info.”
This is the system the Indonesian government developed to make weather data publicly available. It consists of radar data, plus “crowdsourced” data (more on that amusing tidbit in a minute). Scientists being scientists, it looks like this:
I’ll be straightforward here: I spent my childhood’s lonely nights watching weather reports on TV, and I don’t have a clue what this is. I see a few blue spots, so that might be rain… Except Jakarta has no spots, and I’m pretty sure it’s still flooded.
Now, to their credit, there actually is really sexy data if you’re willing to poke at the interface. For instance, here’s water level data at one of the floodgates in Jakarta.
It’s a great service, and it clearly could provide us with the data we need. But it’s in an unusable form. Your average guy out on the streets driving home from work — the same guy who’ll get in trouble when he gets stuck in flooded streets overnight — can’t make any sense out of this.
What we need is a way to actively push these weather warnings out to the public. You can’t expect people to browse the web or watch the news all day long. Where’s my BlackBerry app? My Android app? My iOS app?
Well, also to their credit, there’s an Android app… And a text message service. But that’s a pretty bad way to do things: The Sijampang Android app exists, but it’s not on the Play Store, and you have to register and stuff. Why do I need to register just to get push notifications like “holy banana peels, get home quick, it’s gonna flood in a few minutes”?
There’s also a text message service. You type HUJAN#REG#YourName#Jl. Borobudur no.11#Kota Bogor in a SMS to 0852 8786 7427 and you’ll… No, actually, I won’t try it. These “type REG MONEY send to 9999” TV scams have long made me hate this stuff. Incidentally, this (plus the app) is where they get their crowdsourced data from. You can kinda see why few people bother to pay for text messages to a service like this. (Also, you’re expected to either know a location’s codename, or the latitude/longitude. We all carry GPS units around, right?) Crowdsourcing does not work that way. You seed it, you make it a game, you make it valuable. It’s not “build it, and they will come.”
Now, really, I don’t want to bash these people. The system is there and the guts to make it work are in place — they just need to make it accessible. Or make an API so other developers can build off it.
All I want is to be told if there’s bad weather ahead. I just want a push notification. I want a good app, or—
Wait, a framework for this already exists! It’s called Twitter.
It’s easy! Grab accessible disaster data — surely the police or someone has it — and get a guy to push them to Twitter. Indonesia’s 30 million Twitter users can just follow them, and we get timely updates!
Look, I get the goodwill, but if anyone wants to check the weather, they could visit one of the six billion weather apps on their smartphone, or, you know:
Nobody is going to follow a twitter user that tweets 200 times a day saying “it’s raining in a city you’ve never even visited.”
Or am I picking on the wrong government organization in the first place? Indonesia also has one called “Badan Nasional Penanggulangan Bencana”. It’s the disaster authority in Indonesia. Maybe they can lend a hand?
And even if you do install it, the latest data is from 10 days ago.
Because it’s crowdsourced, too.
Disclosure: This post is directed at the awesome guys behind these technologies. They’re not “bad” — these people are some of our top scientists. They’re just not designers or technologists who make a living understanding the web — they’re the guys doing the science. Here’s hoping this post sheds some light on the problem.
I charge quite a bit for my services. It’s a premium that I’ve pushed ever since I started my career, eight years ago. But prospective clients still ask a lot: “Why are you charging so much? Someone also offered to do it for $50.” Uh oh.
It’s scary whenever a client asks that — but it’s actually a really good sign: It means the client trusts you, and they’re giving you a chance to convince them. Often, that’s exactly how you identify a passionate client. I’ll come clean: I don’t do much work for clients who don’t truly, honestly believe in what they’re doing — and what their role in society is. I believe in making a difference, and I put all my heart into my projects. A client ready — but cautious! — to spend money is a good client.
And yes, I charge a premium. But with a reason! Here’s my answer to that question — and so far, it’s been enough to justify it practically every time.
By charging high…
… I can ensure that I’ll work exclusively for you. I won’t take up other work in the meanwhile — my site will clearly say “Sorry, I’m not available right now.” And this means I work just for you. On-time emails. Quick responses. I won’t be tempted to take other offers — I am loyal.
… I can give space between projects, so there’s room for your schedule to grow. I’ll never say “sorry, time’s up, I’ve got another client now.” No. I don’t walk away until your project is polished. I never throw a product out quickly just to move on to my next client.
… I can afford actual holidays and weekends. A lot of developers don’t have holidays! And this isn’t just great for me — it means less stress, which means better creativity, easier bug-hunting and ultimately getting your project done on time.
… I can afford efficient and powerful tools, like color-accurate screens, high-speed internet and the newest gadgets — which allow me to guarantee compatibility with your audience. I can even buy good-quality chairs because that means less back pain — less time getting back massages, more time making awesome stuff.
… I can get you top-quality stock images, video and music to fit your needs. Because you don’t want those lawyers on your doorstep about that background music, or your audience realizing that you’re using the same free icon set as your competitor!
And, probably the most crucial reason for your project:
… I can call in experts in other fields, like videography, advertising, and server technologies. As much as I love programming and design, I’m careful not to spread my skills too thin. A healthy budget means I can bring in experts from cryptography, usability, design and a lot of other backgrounds. This is a big deal. There are really smart people out there, and getting their input is a huge benefit.
“But Riz,” you ask, “a lot of clients can’t afford that price!”
I’ve got ya covered. And there’s one more, most important reason to me.
We’re developers, designers, and engineers. We’re craftsman in every sense of the word.
But there are people out there — and these aren’t bad people; they just don’t know any better — that think “web development” is like writing a word document. As if it were a procedural, 1-2-3 project that anyone can do after 3 years in college. They don’t know it’s an art form — and, again, it’s not their fault! Our field is brand new, and a lot of people don’t know how we work.
… We developers, designers and engineers are passionate about what we do, and we deserve it. That’s why we ask for a price that fits. It’s not about getting money — it’s about making it clear that we’re craftsman, and we love what we do — so give us room to do our thing. Paying more means better tools and better quality work.
Now, yes, there are some people who can’t afford high commercial rates. That’s why I don’t lower my rates — I simply offer them strong discounts. I make this available for schools, non-profit organizations and other special cases. I still keep my standard prices for small businesses, though, because people will, to no fault of their own, judge something by their price tag. A smart business owner will understand that Rp 20,000,000 budget as a long-lasting investment made by a skilled craftsman.
And “someone else will do it for cheap?”
A website is basically a house — it’s representative of you, and unlike your real house, it’s available to the entire world, 24 hours a day, 7 days a week, 365 days a year.
So why should it cost any less than your actual company home?
Postscript: To be clear, I strongly believe in honest pricing. A developer shouldn’t overcharge, either. And they definitely should not charge more than what they actually do — stuff like extending schedules for no purpose, or doing useless “tests” is very bad form. For anyone seeking a website, remember that most developers are good people: you may (and should!) ask around before accepting that contract.