Web work

On privacy

Blogoscoped quotes Google executives on the issue of privacy.

Eric Schmidt:

“If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.” Eric goes on to say, “But if you really need that kind of privacy, the reality is that search engines – including Google – do retain this information for some time. And it’s important, for example, that we’re all subject in the United States to the Patriot Act… it is possible that that information could be made available to the authorities.”

Marissa Mayer:

“I really feel that the virtual world follows the physical world … There’s very few things you can do anonymously in the physical world. I think that over time, on the internet, there will be less anonymity. And I actually think that’s good; I think it creates, you know, more accountability, people acting more responsibly.”

And here is a quote from law #9 – Absolute anonymity isn’t practical, in real life or on the Web – from Microsoft’s own 10 immutable laws of security:

All human interaction involves exchanging data of some kind. If someone weaves enough of that data together, they can identify you. Think about all the information that a person can glean in just a short conversation with you. In one glance, they can gauge your height, weight, and approximate age. Your accent will probably tell them what country you’re from, and may even tell them what region of the country. If you talk about anything other than the weather, you’ll probably tell them something about your family, your interests, where you live, and what you do for a living. It doesn’t take long for someone to collect enough information to figure out who you are. If you crave absolute anonymity, your best bet is to live in a cave and shun all human contact.

How a web design goes straight to hell

If you were, are, or ever will be involved in the process of creating new design for a site, you absolutely have to see this – Howe a web design goes straight to hell. If you are not a professional (as in trained, with experience, and make your bread and butter with) web designer, you’ll have to believe the slides. Because, that is exactly what happens each and every time. If you are a professional web designer, than you would already know how that happens and what the story is about. This is so true, it’s not even funny.

Build for the mobile

I just had a revelation. An enlightenment, if you will. You know how it happens – you think about a solution to a problem for a really long time. Then you don’t think about it anymore. At least not consciously. But your brain is still crunching. You can feel it. But if the solution is still not found, then get used to that constant crunching and ignore it. And then you even forget it. And then, some time after, there is a Big Bang. A huge flash in your head. And it’s not the solution to the problem yet. But it’s a sign and a reminder that your brain is still working on something you have long forgotten you had to solve. That’s what I just had.

Being involved with a lot of web development, I was trying to figure out how to go about all those mobile devices. Mobile Internet user base is growing fast and even today it is so big that it can’t be ignored anymore. Gladly, most mobile devices run full blown web browsers with CSS and JavaScript support. Some can even do Flash. So it’s not like web development for mobile devices is something completely different from web development for desktops.

And yet, there are differences. For the near future, these are the differences that I can think about:

Mobile devices have smaller screens and that’s not going anywhere. Even if supported resolutions get higher and higher, the physical size of the screen won’t match the desktop screen any time soon.
Mobile devices have handicapped input. Flip-out QWERTY keyboards are quite usable now and handwriting recognition is getting better by the day. But mobile device is not and probably will not be as convenient for input as desktop computers.
Mobile devices have less processing power. They get more power, but while they do so, desktop clients do as well. And so the difference is maintained. With more and more functionality being pushed out into client side, processing power is an important issue.
Mobile devices have unstable connectivity and higher bandwidth costs. Again, with all 3G networks expanding globally and more and more free WiFi hot-spots installed everywhere, the connectivity problem is getting partially solved. But it’s not going to be solved completely any time soon (coverage, higher costs, battery life are just some of the reasons).

While there are probably other things you can put on that list above, even the ones I have there are enough to consider a different approaches when developing for mobiles. And why should we consider them at all? Well, here is an image that actually triggered that big flash in my mind that I spoke about earlier (shamelessly borrowed from Paul Kedrosky blog post).

You (of course I mean “I”, “we”, “they”, and “you”) cannot ignore mobile devices anymore when building web sites and applications. So, how should this problem be approached? And now for that revelation, enlightenment that I mentioned earlier in the post:

Build for the mobile device first, then extend for the rest.

That’s not a new approach. It’s something that has been used and recommend before. It was just phrased differently. It was along the lines of : limit resources in your development environment and you’ll get a much more efficient and resource aware application. If a developer has only 512 MB of RAM on the machine he uses to write and test his code, chances of that application being much more effecient on a 4 GB server are higher than of application written on a 4 GB machine. ([*] citation needed)

If you build your web site or application for the mobile device, you’ll ensure most of these:

It works well with small screen sizes and lower resolutions.
It requires the minimum of input from the user.
It has exactly the right balance between client-side and server-side processing.
It supports a whole lot of browsers, even most of those browsers don’t exist on the desktop.
It has at least some optimization in terms of download size, client-side caching, etc.

And when your web project works on the mobile devices, it will be much easier for you to check for extra resources in the client’s browser (higher resolution, better browser, etc) and enhance behavior with more bells and whistles. You’d probably won’t want to do this yourself anyway.

I think adding additional bells and whistles would be much simpler and faster, then removing and reorganizing things in the application that has been built for the desktop browser and now needs to support, or at least behave nicely with mobile browsers.

I would be very surprised if you actually read the post all the way down to here. And just to thank you, I thought I should surprise you. Most of the above post just came out from the top of my head, has no research, measurements, or supportive data. It’s not even something I have discussed with someone else yet. So, I suggest, you take it with the jar of salt, jar of pepper, and a pint-sized bottle of red hot chili sauce.

Google Public DNS announced

Google announced a Public DNS service, which is extremely easy to configure and which will improve your web browsing speed and security. This service is not revolutionary however. There were a few ones before, and the one that seems most popular these days is OpenDNS. In case you wonder what’s the difference between OpenDNS and Google Public DNS, take a look at this Google Groups discussion.

From the end-user point of view:

Right now the difference is that Google Public DNS does not use any sort of redirection or display any ads. If a host (domain name, web address, etc…) doesn’t resolve, it will just fail. With OpenDNS, they hijack these failures and redirect you to a search page that displays ads and makes them money.

From the administrator or customer point view there are things like stats, control panels, and more – all in OpenDNS. Google Public DNS seems to be focused differently. At least for now.

Update: Jason Kottke explains why Google did it.

Bits and pieces

Once again I’ve noticed that my blogging is getting behind. Busy at work, lazy, and going through the mood change for the upcoming Christmas holidays – that all has a role to play. But that’s not the major issue.

Thinking of what am I doing differently these days, I realized that my blogging activity got spread out all over the web, and therefore became less noticeable on my own blog. I do more of Twitter, which is now integrated with the blog in the form of daily briefs. I favourite more videos on Youtube, which now notifies the Twitter, and later still ends up in the daily briefs on the blog. I do more bookmarks on Delicious, which also end up via Twitter in daily breifs. And there is something else I do, which doesn’t come back to the blog – shared and commented articles in my Google Reader.

Actually, as far as writing goes, Twitter and Google Reader happen to be the only two places where I write at all now. Once I realized that, I wanted to find a way to pull the comments and shared items from Google Reader into my blog. But then I doubt if that’s the right approach. The alternative being blogging and commenting about things not in the Google Reader, but in the blog itself.

I am still undecided on the matter. Google Reader provides a really good interface for commenting and interacting with other people who read about similar topics. On the other hand, my blog has more exposure than my Google Reader shared items list, and has better interface for discussions. Perhaps, I should try and see how it goes.

What’s your take on comments in Google Reader vs. blog posts?