Following on from my previous post on the fast-food like properties of web-content I thought I would look at the service which embodies the latest acceleration in content consumption, Twitter.

For the uninitiated, a ‘tweet’ (as referred to in this post’s title) is a single message sent via the Twitter service. Twitter is a short-message system which can be accessed by numerous applications and devices; primarily, but not restricted to, web, IM and mobile. Messages are by default public and therefore you could think of it as ‘mini-blogging’ where messages can be posted as easily as sending an SMS or IM.

The rise of Twitter in the early adopting set (lets face it, it hasn’t hit mass market yet) has seen the introduction of a new, even more throw-away type of content. The plethora of states, moods and emotions punctuated by links to sometimes vaguely interesting content really leaves a faint impression. The experience lacks cohesion and any real filter determining significance or relevance of a particular content item. This gives it a sort of fun lightness and I guess the beauty of it is in the aggregate of the impressions you get from someone’s Tweets you follow.

There has been plenty of discussion on blogs about Twitter - all discussing what amounts to the same thing - does this medium have future? Not to be silent on the subject I do think it is a service which will be a place alongside other internet-mediums like blogs and IM. I think it will be in a form evolved from the one we know today - one of the reasons being that many currently heavy users of Twitter in this experimental adoption phase will stop or at least severely par back their usage of the service as they realise its capacity to cause constant distraction, fragmenting their thinking and to generally get in the way of Getting Things Done. I’ll touch more on this in a subsequent post.

Something I haven’t heard much in the current conversations about Twitter and that I think is important is that one of the key strategic strengths of the service is infrastructural - the link between IM and mobile network messaging and the web is a useful one which many applications will build upon. I think one of the players in the industry, whether Twitter or Jaiku or a new player to come (and regardless, likely to be acquired by one of the big companies) will benefit from owning a reliable set of gateways maintaining these links.

The direction the presence products will expand will be in their ability to filter and summarize the content they deliver - experimentation with Twitter and Pipes will be interesting as the service will need to overcome its procrastinatory qualities. With the internet already being the procrastinators achilies heel the last thing we need (and I am assuming I might be representative of at least some of us in this) is a stream of random information flashing on GTalk or our mobile phones constantly to distract us from what we are actually doing.

Where Twitter-like applications could come into their own is if they can combine the users current geo-location, mood or other information to tailor very relevant alerts to them. Currently however its like trying to work with firehose to the side of your face.

My prefered editor for Javascript is Aptana. I put up with the occasional slow performance of the Eclipse Platform which underlies it (it seems to hate dealing with windows network shares and vpns) because the IDE is very well thought out and works with me rather than against me.

That Javascript has an IDE at all shows that it has matured much since the early days of its inception where it primarily validated web forms, generally badly. With maturity in a programming language comes other things such as documentation. The preferred method of documenting API information these days is the *doc family of specifications and Javascript, through the efforts of the people behind Aptana I believe, has ScriptDoc.

ScriptDoc support is integrated into Aptana and helps the IDE make more sense of the very flexible syntax that Javascript supports - I certainly don’t envy the Aptana teams’ task of programmatically wading through the sea of anonymous functions, literals, prototypes in order to facilitate their IDE’s syntax highlighting, autodocumentation and outline capabilities.

Reading through the forums on the ScriptDoc site and through the specification I can see there is room for a lot more growth and development of this specification.

Something that we have found in our own Javascript development at Hitwise that we feel would be a valuable addition to the specification would be the ability to explicitly declare what the value of ‘this’ would be for a given function (or more specifically, method where a function is part of an object prototype). I will explain my rationale.

One of the ‘quirks’ (from an OOP perspective, anyway) of JS which is exploited to (sometimes) good effect by many of the key libraries about these days is the mutable nature of the keyword ‘this’.

For example, events (depending on whether they are native or ones augmented by a framework such as YUI) will define ‘this’ to be something other than the object prototype that you may have attached your handler function to. This means that ‘this’ can have different properties within callbacks to every other function you have defined for an object and can be therefore confusing (particular to those with OOP experience in other languages).

Indeed YUI and likely each other major library even allows you to explicitly define what the scope will be - they do this using some tricky closure syntax - I will often use this functionality to redefine ‘this’ back to the instance of the object where my event handler is housed to give ready access to the objects properties.

Of course sometimes, if there aren’t many properties you need to access it can be more convenient to access the element where the event occured through ‘this’ or in other circumstances even access some other arbitrary object and it is this reason that you are likely to see variation in what ‘this’ actually is!

When looking at a function and its documentation, you want to readily know what the available variables in the function scope are set to. The parameters can be easily documented and documentation for this across languages is almost universal. You also know that certain globals may be available and of course ‘this’. And most times you even know what ‘this’’s properties will be.

But if you are writing a callback for an XHR call or an event handler then you can’t be sure what it will be. If you are calling an existing callback which may have dependancies it would be great to avoid looking at the code and go to the API documentation to see what the callback would like ‘this’ set to. You could achieve this by defining an additional parameter or a custom ‘@this’ comment definition for your function could save you or your colleagues time in the future and make your Javascript API docs easier to grok. Standardisation of such a property would allow IDE’s such as Aptana to use this information in its code insight functionality to inform you of this requirement as you write your call.

With the general level event-driven programming required in most web development these days this would be a welcome time-saver and reduce the mental switching required to determine what ‘this’ will be.

We seem to rediscover every few months that many users are typing the name of the search engine they are on into the search box. I read many disparaging remarks directed at this very large group of users and I wonder why the remarkers would think this behaviour is ‘clueless’ or ‘dumb’?

Forgetting what the user ’should’ do, lets consider the two options for a moment. Firstly, in terms of physical and functional composition, both methods of navigating the web comprise of a single field and respond to the enter key; so no difference there. Further, one is placed at the top of the screen, the other often nearer to the centre. I’d say thats one factor that the search box has over the navigation bar.

Moving on, the navigation bar will in most cases punish you for mistyping. Google and other engines will offer a link to (most likely) the site you intended. Now thats handy! I’ve started using the search method for those times its handy. Google Desktop makes it easy to get to a search box (just hit ctrl key twice). This is much easier than ctrl-tab a few times combined with another key-combination to open an URL (and then you get to type the URL…). Who wants to be doing what they ’should’ do anyway? That sounds clueless to me!

Not all instances of a search engine name being entered into a search engine is for the above reasons, though. ‘Google’ is entered into the Google search engine because who can remember where all their products are housed. Google, in their effort to deliver a ’simple’ homepage, avoid the portal type page so typing ‘Google’ can be all users can do to find their many great products.

Another point to consider are those keywords put into the navigation bar which aren’t legitimate URLs are often sent to a search engine in browsers such as Firefox. Who wants to spend time repetitively typing the fairly redundant ‘www.’ and ‘.com’ anyway…?

What can we learn from all this anyway? Well next time you consider calling a user stupid, stop yourself and look for the efficiency they are seeking. It can teach you alot about how you could make your application easier. Not everything needs to be reduced to a unthinking action but its worth taking the thinking out of the tasks that don’t require it so that effort is most effectively spent.

Maybe browsers should ditch the navigation bar? Maybe the navigation bar and search box should be one? I’d like to know your thoughts.

Coding Horror covers some general criticism of Javascript libraries reminiscent of a few criticsisms I eluded to in previous posts such as “Javascript: The Quickening” and “Yahoo’s YUI Drag and Drop Module”. I think it could be stretched to other languages as well however as javascript has been a focus of mine recently (and many others) I thought I would explore some frustrations with working with the YUI library (as well as some other libraries) I have had recently.

Firstly, a point in reference to the Coding Horror post. The veneer of documentation can be a trap. The YUI library has more documentation than most, including API documentation, general overview documentation, cheat sheets and many examples. All of that and seasoned OOP javascript developers can still find it quite difficult to use parts of it for work more complicated than the basic examples provided in the documentation. I am interested in exploring why this is.

I find that many examples are often not coded to a standard that would stand up to much scrutiny except somehow examples seem to be exempt from quality control. Procedural code seems to be generally preferred ‘to keep things short’ and they use short cuts such as inlining everything in your HTML which ignores the real issues that go beyond stitching a few API calls one after the other.

The more complex issues in using libraries to solve complex problems are ignored. Trying to get javascript libraries in particular, playing nice with other code can be difficult. Controlling when the code is called and when things occur are complex issues however looking at any Prototype examples you may think that randomly pasting script blocks throughout your code is a sane thing to do.

Another issue I find YUI and most other JS libraries have is not all files clearly state which other files they are dependant on. This appears to be because such documentation is not uniformly enforced across the library (This is a feature of single author libraries as well, I find).

With Javascript unable to natively define explicit dependancies it is more likely to fail with an obscure error or worse still run but incorrectly. It is a time-consuming practice to work through finding all files it may need from the library and all assets it may be relying on (CSS, images etc.). And generally nothing works at all intended until you get it just right… Javascript in particular is often dependant on the order of the includes as well.

To my mind, dependancy tracking is a key facility of documentation whether it be derived from package names or calls to ‘include’ type functions (see my earlier post for the blurred line between documentation and code).

The namespacing efforts of YUI and Dojo; and Dojo introducing linkers and the ability to dynamically include required scripts we may see this improve but until more mature solutions exist we are doomed to some very frustrating hacking - contributing to the mug’s game that is web development at the moment (a topic for a separate post).

There have been philanthropists in javascript development since the language was concieved by Brendan Eich. A few that I can point to as having provided tools and inspiration along my path in web development: Mike Foster and his excellent x library (and it predecessor) which just worked and added some bling to projects of a few years ago; Brent Ashley and the jsrs library code and examples which opened my eyes to a new form of optimisation I could use in the web applications I built; PPK for the never-ending resource that is quirksmode… I am sure you all could name others that facilitated your own web application careers - feel free to add to this article in the comments.

In more recent “web 2.0″ times it was the success of Sam Stephenson’s Prototype, defined by its syntactic sugar which reminded the web development community at large of the dual functional and OOP natures of Javascript (invigorating in the face of the millions of custom procedural functions that previously ran the web). This has driven the current increase in client-side scripting interest. Of course Prototype was also helped in part to the libraries which built on it such as Thomas Fuchs’ Scriptaculous and Open Rico and also those influenced by such as MooTools. I would argue that all this activity (and other developments) was itself fueled by the natural return to ascendancy of web development that was always imminent after the tech crash’s over-correction.

With exploration of Prototype (and Javascript in general) we also learned. We learned that messing with the Object.prototype is verboten and that there were better ways to include functionality than inlining everything. Ben Nolan’s Behaviour library demonstrated this best (well then, anyways, these days I now just include separate files which use the various selector functions in combination with the cross-browser Event Handler implementations found in each major library).

Mid-way through last year we were evaluating libraries, namely Prototype, Jquery, Dojo and YUI. YUI won out for a number of reasons. Jquery looked great but it wasn’t at version 1 yet and seemed to be changing on a weekly basis (for the better, but that was too much flux for a project destined for our end users). Prototype I had used in some of my demos but the documentation was sketchy and every example relied on inline script tags scattered through-out our templates. I trialled out Behaviour which was quite handy but some examples were not easily recreated when combined with Behaviour. We were also concerned that Prototype would not play well with others. We wanted to leave the door open to continue using other third-party libraries in the future.

Dojo looked awesome but again was low on useful documentation (They have much improved - in fact all libraries have, in this regard). The Dojo events package looked very cool with its AOP-style approach but I had reservations that it might add too much ramp-up time to our tight schedule.

YUI had a combination of API and example-driven documentation as well as coverage on all the key features we needed. Its namespace implementation was simple, allowing us to get in and comprehend their code quickly. Once undertaking the project we did find that the documentation could still have been much better, but such are the joys of open-source libraries and their documentation, right (php is an exception - the comments on the API pages was a stroke of genius)?

The last twelve months have seen Dean Edwards and John Resig and others team together to provide a cross-browser solution to detecting when the DOM content had completely loaded (at a time before assets such as images have completed downloading).

This month has seen Jack Slocum weigh in with faster DOM search functions, setting a new benchmark in the area that John Resig had previously thrown down the gauntlet. This sort of collective innovation is for the good of the community and is providing an accelerated environment of innovation. I don’t fully subscribe to information singularity as while I do think acceleration can be hyperbolic it will more likely form an ogilve, flattening at some point rather than continuing to approach infinite (there are, afterall, limits to our ability to process information and effeciently distribute it amongst the hive-mind that is the community that forms around any topic of learning).

Philosophic analysis of the phenomena aside I do think it is valuable to recognise the progress that has been made and the factors contributing it and encouraging everyone to continue providing and contributing to the environment that has allowed us all to flourish.

In these days of Google-mania it seems that Google has become the ultimate yardstick. I think this is strange as there is nothing standard about Google - it is the outlier, the edge-case and not definitely not representative of the market at large.

An unreasonable amount of speculation around Google and the companies seen to compete with them has an unnatural effect on people’s interpretation of the state of a business or validity of a strategy.

We’ve seen google become a verb (and yes people are googling on Yahoo as well) but to me the past-tense variation of this verb (’googled’) has another meaning, that of companies affected (positively or negatively) by the overblown nature of the Google-myth at present. To put this word in context I think Yahoo is currently being partially ‘googled’. ‘googled’, to a company undergoing this phenomenon, is probably also a synonym of any number of slang words for coitus.

Google products entering new spaces cause people both inside and outside companies in the same space to make irrational decisions. Strategies change, stock prices drop and, from my experience, often for naught - many companies will report that Google entering their space, despite their initial panic and countless crisis meetings, actually saw an upturn in their own businesses.

A phrase I have always been fond of is ‘the elephant in the room‘. It evokes a brilliantly comic scene in my mind of some very sincere looking people talking whilst carefully ignoring an elephant which is perched in the corner of the room. This image visits me frequently when reading discussion about the state of the Yahoo business. It seems that many posters, enamoured with the creativity of Google’s endless list of products, fail to acknowledge the presence of the most successful publisher on the internet.

I certainly don’t want to downplay the issues at Yahoo, they clearly have structural issues which need to be addressed but I can’t help but just point at that friggin elephant that just sits there quietly blinking in the corner. Its a room with glass windows so the general public can see the elephant and they actually spend quite a bit of their time looking at it. It collects their mail for them, provides them news, helps them shop… sure, it looks like a patchwork quilt because many groups of talented frankenstein-like specialists helped put him together whilst carefully avoiding talking to eachother… but he’s always doing more for the public and his public go to him first when they are in need of information or a tool.

Meanwhile, us, the industry-types, the money-people, the other animals in this room are all looking at the chimpanzee that can poop primary colors and are throwing it peanuts.

With the issues I am having with my Yahoo! account and the innanity of Google’s legal goons attempting to dictate the public’s use of language, I find myself wondering what my options are in regards to a new search provider. Of course, like most other web developers, I use Firefox predominantly (Firebug being a big part of the reason behind that) and therefore want to add a new default engine into the search dropdown it provides.

I wandered over to ask.com (they’ve always done a nifty thing here and there and might be able to provide the quality of searching i require). The URL is also nifty short in case I need to type it. The offer a pox looking toolbar that makes me think ‘Web Browser Helper Object’ (that is not good).

A quick wander through a few links on Ask I find this page…

Its been updated for IE7 to guide you through setting Ask as the default engine but then goes on to give directions for… Netscape Friggin’ Communicator!?! No quick add link for the ‘Ask’ engine? Wikipedia.org, Dictionary.com and even our ticketing system at work has implemented one of these… Why not Ask?

Has anyone switched? Anything worth checking out and potentially switching to?

I have been trying with some frustration and some amusement to regain access to the account I setup with Yahoo! about 10 years ago. I say ‘about’ because I really can’t remember exactly when but I do know that it was early days, well before the boom (and eventual bust). What I do know is I am the only person using the handle ‘wioota’ and I am the only person with a grasp of the full details of my life. I cannot remember what password I used back then (hence the problem) and I am not even sure which of a myriad of work email addresses I may have used.

What I do know is that none of my current email addresses were used as the alternate address for this account.

With all that in mind you would think I could get in contact with Yahoo! and set a new alternate email address (which in turn would allow them to send me my password). What has ensued over the past year (my first response from Yahoo! on the matter was on January 16th) has been 3 separate attempts, each involving about 7-8 exchanges between Yahoo! and myself.

And still with no resolution.

Some of the highlights include:

• Yahoo!’s insistence that I supply both my Secret Question and my Secret Answer - I’d have found it a bit easier if they could supply me with the Question so I could respond with the Answer as I am sure that is how a challenge-response mechanism is supposed to work.
• Yahoo!’s later (much later) admission that my account is so old that it doesn’t have a Secret Question or Answer attached to it.
• Yahoo! then offering to let me add a Secret Question and Answer to my account for extra security and conveniance (no offer to help me identify myself and regain access to my account though).
• Yahoo! requesting me to fax or snail mail California (during an exchange where I thought I was in contact with local - Australian - representatives).

So to Yahoo! - a company who I have felt were being unfairly ignored in the face of Google’s impressive brand equity - you are driving your loyal customers away! I would suggest taking an axe to your customer support departments (which have clearly become bureaucratic and over-automated) and start investing there. This time don’t turn to your geeks for the answers, don’t offshore it, get someone or some enterprise who know’s customer service and let them take over.

You are doing a great disservice to the excellent efforts of your talented engineers by allowing your customer service to remain this bad for this long.

Is anyone else tempted to put an ID on every freakin HTML element so that they are easy to reference? As I write routines to locate my elements within the div an event fired on I wonder to myself - “Just what would happen if someone whacked some extra DIV tags in this template?”.

Most of our code is PHP and we put some effort into making stuff that wont fall over for our clients. I am not used to writing code which I know will break when inevitable changes are made. But what are the alternatives? Put IDs everywhere? I’d have to generate the IDs because most of my pages are dynamic. Should I attempt to write more forgiving routines that keeping searching until I find that img tag I am looking for? This brings in issues of performance and why the hell am I spending so much time writing routines to find elements on a page that I put there in the first place, just to frickin switch an image or fade some div!?

Awhile back I likened working with Javascript to an addiction. I think that is still apt and I am starting to see that the act is also fairly futile. Maybe I am just weary from a long project but maybe I am seeing the truth of this thing. I think maybe we are all blinded by the pretty moving, pulsating, bevelled corner DIVs and not being realistic about the disproportionate effort required to get a dubious gain in usability.

If you have some suggested reading for me which may ease my pain then drop me a comment and join the illustrious crowd of Dustin Diaz and some guy named John who have commented on my blog.

We’ve been working with YUI recently. There is plenty that is good about it - we were originally drawn to it because of its obvious amounts of documentation, examples, blog and the backing of a big, big company in Yahoo! (and their suite of javascript luminaries).

Its been quietish on the YUI front, recently however, there was a point upgrade, but I do think we over-estimated Yahoo!’s ability to keep the library bubbling along. I think there is a difference between the priority Yahoo! places on YUI when compared to dedicated library development efforts (prototype, jquery, dojo all come to mind).

The documentation in use comes fairly short of acceptable. I will try to elucidate on why because I don’t really want this post to be anything other than constructive. Afterall, YUI did end up achieving what we were after however I felt we probably ended spending too much time trying to learn the library and the quirks of its construction.

As part of the documentation an overview or survey of the library would have been great - many features we found too late and spent time retrofitting onto code we had already written. This process helped fix browser compatibility issues but ideally we would never have come across these if the prefered ways for changing styles and retrieving elements were highlighted. Further browser compatibilty issues could have been prevented with some more defensive programming within the library - there is definitely wrong input that you can put into the API which will yield js errors from within the library.

Other frustrations included examples which appeared to have their own custom additions to the library with little or no explanation eg. the DDPlayer objects in the Drag and Drop modules.

I also found the DD module had a few too many assumptions when it came to its events.

Drag events can work in a simple point mode (ie. the target is wherever the mouse pointer is) and intersect mode (events such as DragEnter, DragOver and DragOut get an array of targets which you can use to determine which you want to interact with). Intersect mode is, I believe, a preferred method because the drag item becomes the mouse cursor. This means users will expect interactions to occur with the item rather than the mouse cursor.

The problem I found was that the library did not pass me the true list of items I was over. It appears that it was caching items already found by earlier events. This was frustrating because now I need to mirror this caching in my objects and am therefore needing to peer behind the curtain to see how the library works.

Early on we found a bizarre class notation which was used in some of the YUI modules. It puzzled as to why use this over the more standard javascript approaches to defining objects (a js strength/weakness is its flexibility). It appeared to be used where you might usually use a static class or the singleton pattern in other languages.

Thankfully, only an hour after a colleague and I puzzled over this Dustin Diaz posted an article which illuminated it fully for us. The exposure of many Yahoo! staff via their blogs continues to be a compelling part of the support network for this library (and our saviour twice now!).

I think that YUI needs the continued support of Yahoo! to continue the good base that has been established. The library has clearly facilitated some great developments for Yahoo! with some very impressive product releases of late. The gains are measureable but the potential future gains from continuing to support and improve the library are also very real. Don’t do it for us - do it for your own developers. And then put it out to us