Saturday, August 30, 2008

I saw some people suggesting legal action to stop these types of businesses, but let's face it, deep-pocketed giants can't abolish illegal file sharing sites and programs. What makes these people think they can stop these guys?

If you’re a manager, count those legacy projects, and stick them in your portfolio to either finish or kill or park somewhere if you really think you can’t kill them outright. But stop the partial-staffing of legacy projects. That’s nuts. Either staff it or not. Don’t make people leave because you can’t decide what to do with this project.

Friday, August 29, 2008

Great article: widgets are a somewhat recent trend that effectively makes the old mistake of trying to please everyone at the same time.

Bombarding the user may look like a good idea, but we need to remember that they have the ability to ignore clutter and only focus on what is interesting to them (rather than what you or your client want them to be interested in). It's all to easy to fall into the trap of wishful thinking.

A nice way to figure out if your widgets are useful is to add Google analytics tracking to links/buttons/interactive elements and see what people are interacting with and what they aren't (assuming they are not something passive like a tweeter stream).

If you're not getting a whole lot of hits on the widgets, maybe you should reconsider whether they should be there.

Tuesday, August 26, 2008

Every once in a while I come across stuff like this. And for whatever reason people seem to think that it's always ADD or Aspergers or whatever other "disease". Dude, just because someone doesn't conform to some hollywood stereotype of the "mr. sexy guy", it doesn't mean they're mentally sick.

If anyone ever thinks their personality is getting in the way to their path to happiness or whatever, remember that life is what happens while you make plans. There's nothing at the end of the road.

Friday, August 22, 2008

As if responding to the Squirrelfish initiative by the Safari team, Firefox now has its own little baby to show off. We will be seeing performance that is very close to native C speed with Javascript in the very near future.

Combined with stuff like this, and the recent proposals in the HTML5 spec, we could be seeing full blown games being delivered from the browser a few years from now.

I love the direction things are going: we are seeing visible improvements across the board for all the major complaints people have about the web platform: more powerful APIs, lightning fast performance, and standardization :)

Thursday, August 21, 2008

Firefox plugins, Google Gears, Adobe AIR, Opera widgets, Yahoo Konfabulator, did I miss any other ones? Downloadable modules are a great way of delivering specialized software (e.g. Firebug), but they're horrible at integrating with existing networks.

With the web platform, we can easily send a link to a 3D chat app to a friend over instant messenger, hotlink videos on your blog, backup the bookmarks, etc.

Try sharing a Veoh TV video with a friend and you'll quickly find that learning how to use their UI and then convincing your friends to download and learn it as well is a major roadblock. Has anyone seen the demo map app made in AIR? I couldn't figure out how to for a good half an hour. Don't make me think.

A lot of people seem to confuse languages with APIs, and draw wild comparisons with things like OpenGL and Silverlight. Yes, the HTML5 effort as it pertains to standardization of next generation browser functionality (e.g. video, threads, etc) is rather sluggish, but it has nothing to do with the Javascript language spec. We can call "video.play()" or "new Thread()" in javascript today and really, it's up to the programmer to decide how that gets implemented under the hood. Whether Flash or ActiveX are not "open-web-friendly" really doesn't matter; we can create crazy hacks or make great services either way.

As far as "pushing the limits of the language" goes, again, it goes back to APIs, and to infrastructure. We can't blame the javascript specs if your Comet doesn't work realiably over HTTP in all browsers or if you need to use brittle vendor-specific extensions to get storage to work on the client side.

I think it's great that people are questioning the capabilities of the APIs available in javascript, and you're free to go try other technologies. I'll be here when you come back wanting to share all your new discoveries.

Monday, August 18, 2008

At first, I thought this was going to be an article about usability :)

As far as phishing goes, there's no way to differentiate a legitimate UI from a fishy one. All an attacker needs to do is copy the legitimate UI. Even if they could somehow be differentiated, statistically speaking, there will always be a large number of users that will always respond to certain prompts with muscle memory, and there will always be a variety of newly deployed social engineering attacks that don't attempt to spoof any famous vendors in particular.

Profiling is pretty ineffective too: there's no correlation between language proficiency or graphics design skill and the intent to harm for profit. Also, just because you can tell a js popup from a real AV one, doesn't mean everyone else can do it too: keep in mind that Jeff's question pertains to a naive user.

Sandboxing also only does so much. If the user says "yes yes yes password yes uac yes I'm the administrator for this computer, so install and run this already", the whole sandbox goes right out of the window. Proclaiming one-sidedly to be the super admin for your aunt's computer seems kinda awkward too imho: it's like gifting her with a kitchen knife set and saying "i'll keep the keys to the scabbards, just in case". There was even a case in the news recently where a tech support kid hacked a woman's webcam by abusing that meme of "putting trust in the technical expert".

There are way too many attack vectors. If users can't decide on their own when to click on the close button instead of the ok button, no amount of code or UI tweaks ever will.

Sunday, August 17, 2008

This refers to one of the most fundamental questions about the universe: does it move according to an algorithm or is it completely random?

You can think of it as a religious question too: does God interfere with the universe or not? Of course, this won't answer the whole debate about God's existence, but it does seem to make the chances of God existing higher.

Nice explanation. Basically being RESTful means understanding the underlying infrastructure of the web and making use of it when it makes sense, e.g using GET when you want caching, using PUT when you want to avoid posting-twice problems and not throwing C# exception messages with a 200 OK header.

It seems Actionscript 3 will not be a subset of the new ECMAScript 3.1 Harmony proposal, meaning it might end up becoming a language of its own. Maybe Adobe will do something like .NET and allow multiple languages to run on top of the VM.

Advertising games seems to be hard for some reason: there are a lot of MMORPGs that basically parrot how they are free and they have this and that other "system".

Ever started playing Flyff (fly for fun) only to find out you can only really fly after you spend a good part of your week getting to some two digit level? Ironically, in Second Life, where the ability to fly isn't really advertised as a distinctive feature, we can learn how to fly (with pretty much no restrictions) within the first 15 minutes.

When it comes to targetting non-hardcore gamers, I like the concepts in Nexon (of Maplestory fame) ads: invitational tone using words most people can relate to. Who really cares about a "revolutionary party system" and "real PVP"?

Imo, unless you spend your weekends exhaustively trying every single new open beta MMORPG in the net, ads that invite you to "explore" and "chat" sound a lot more attractive than ads that seem desperate to set themselves apart from their competition by claiming to have features that only some hardcore gamers would be interested in.

Advertising campaigns for some other types of games just look plain awkward. If someone's not interested in Madden, I doubt a website with fabricated tips is going to get them interested. "Cutest quarterback"? Come on, whose friend do they think they are?

A nice quote from Scoble from way back in 2006: the next web is the human web. I think that advertisers could use a bit of that "humanization" too.

Tuesday, August 5, 2008

So, everyone seems to be commenting on this piece about why CSS variables are bad. It talks a lot about the learning curve issue. Quite frankly, I personally think that's irrelevant since CSS is far from having a challenging syntax. But, I do think variables have their issues.

The Issue: naming conventions

Assuming we are all sane people who don't name our variables "abc123", there are two naming conventions that we can use for CSS variables and I think they are both horrible.

Look closely at the rules above. How many of them can you honestly call "reusable"? Using the CorporateLogoColor variable to define the font color of footer text or image borders is obviously not a good practice. Likewise, reusing any of the other declarations will just cause a lot of confusion later on. This happens because the variable names are being used to describe the values they reference. We're effectively saying "This 'blue' is not just any blue. It's a Title Color".

I really don't see any reason to create an alias like this. If the class name is descriptive enough, I really don't need to re-describe it. And I could very well use comments if my class name wasn't descriptive.

If the variable name is too generic, it will invariably need to be overwritten by more specific rules (e.g. BGColor vs. ContentAreaBGColor). If the variable name is too specific, it will be bad practice to reuse it when it doesn't describe its purpose (e.g. BGColor being used as a link text color). Perhaps worst still is that I'll effectively need to double the amount of text that I have to type and that users will have to download. Weren't CSS variables meant to accomplish the exact opposite?

This is certainly more reusable, but I can argue that "blue" and "arrow.gif" are more than appropriate for describing things that are supposed to look blue or look like arrows. This approach is prone to the old problem with using values as class names in CSS: with the current spec, if you have a undecided client, you can end up with:

.red {color:blue;}

And likewise, with variables, you could end up with:

@variables {
Arrow : url(circle.gif);
}

The main difference to note here is that semantically descriptive class names are considered good practice, and descriptive variables, as I've shown above, are counter-productive.

The abstraction argument

Ok, we could go and change "Arrow" to something more generic. "Bullet", for example. After all, this graphic will most likely be used to style variants of "ul li".

Well, so variables suck, right?

But let's be thorough. The following is a waste of time, since the alias ends up being longer than the original value:

@variables {
VibrantRed : #f00;
}
/*compare:*/
a {color:#f00;}
a {color:var(VibrantRed);}
/*note that the 2nd line needs the
@variables declaration in addition to
being more verbose
*/

Last thoughts

I find that most people I meet who like the idea of CSS variables have predominantly imperative programming backgrounds, so I'll just say this as a semi-rant: Look, CSS is not Blub, it's a DSL. It will never be the same as your turing-complete language of choice because it serves a different purpose.

If you find that maintaining your CSS is hard, chances are that you're writing it wrong. Learn to use the comma.