By now, after having been forum’d, twitter’d, and even youtube’d (Thanks, CTitanic!), the UMPCScrollbar has hopefully found a happy home on all your UMPCs. Curious minds have been asking why this wasn’t released earlier. And whether this is a candidate for inclusion in future releases. Rather than give you the standard immediately-unsatisfactory answer, allow me to shed some light on how this utility came to be, which may then provide an insight or two into project picking decisions.

The dialog-scrollbar idea first originated sometime last year (prior to my joining the UMPC team) as part of internal experiments conducted by the talented UMPC project pioneers around addressing UMPC pain points. An early prototype was developed but did not quite catch-on. Between project pressures, priorities, and personnel changes, it was pushed to a backburner and ... well, faded a.w..a...y.... Later, as team composition evolved further, the new boss,  intrigued by the original idea, prodded me to conduct a revaluation. Unfortunately it was clear to me that the prototype needed TLC. But given the constant-balancing-act-constraints we usually work against, the opportunity-cost of refining it seemed high, relative to potential payoff. Unwilling to distract the project team from their more-critical responsibilities, I decided to adopt the scrollbar as a side project. Somewhat like an abandoned puppy. Little by little, over nights & weekends, I refined the original concept in my 'copious' spare time, until, after significant overhaul, the utility finally started feeling useful. At this point emerged a dilemma. Turning the utility into an ‘official project’ (i.e. engineering it well and releasing it responsibly) takes significant time and effort.  Whereas if UMPC native resolutions are expected to eventually go up, how much effort should be spent on a short-term, stop-gap solution? Plus, if the need for the solution is now, the longer it takes to release, the less useful the utility will be. Unable to find a low-cost release mechanism (especially one that did not automatically incur the glorious prize of increased-user-expectations™) I finally decided to treat the utility for exactly what it was: an informal, untested, side-project that users may or may not find useful. And, in the interest of getting it out there quickly, I threw it 'over the wall, as-is. [Thanks for catchingJ].

The astute reader, in reading deeply between the lines, may have already discerned that:

-        We usually have lots of ideas internally than we are ever able to ship, especially around addressing pain points.

-        Unlike a soulless machine churning out code, most of our ideas (and how they are implemented) come from living, breathing people™. The right people make all the difference, and, unfortunately, these people are usually in short supply. 

-        Relative to all the software we want to create (and ship), it never feels like we have enough talent or enough time. As a result, we’re constantly forced to triage our investments.

-        Like all investors, we hope to maximize our ROI. Which can be done by lowering your costs and/or by maximizing your returns (i.e. having a large impact). (Between 'large impact' and 'narrow impact', guess who usually wins...)

-        Responsible, world-ready, engineering incurs a minimum fixed cost for even the smallest of projects. (In other words, there is really no such thing as a small ‘small project').

-        The cost a project incurs is directly proportional to the size of the prospective user base. And the size of the user base automatically multiples the cost of getting things wrong (usability, reliability, security, <pick-your-own-metric>,..). Therefore, traditionally the bigger the project/audience, the more conservative the resulting stance in picking investments…

-         To further raise the bar a bit, not only must each prospective project address customer needs and expectations, but it must also (among other criteria) further business goals, meet partner requirements, be technically affordable/feasible, and have strategic value for the company. 


When you put all the above together, basically you get a system where a lot of ideas may enter, but only a handful emerge in the form of carefully-chosen projects. Hopefully this helps you understand why you will often receive the standard non-committal answer: “Thank you for your feedback. We will take this into consideration as we plan for the future”. Most likely that’s exactly what’s going to happen. Except the bar for turning idea into project usually remains unflinchingly high...

A closing thought: At the end of the day, the UMPC is just a Windows PC. And the UMPC Scrollbar is just an ordinary Windows application. Anyone with an interest in Windows programming can and should write more UMPC utilities and I encourage y'all to try your hand at solving your own pain points. [At the very least, each new utility inspired by the UMPC Scrollbar will help me feel even better about having let the Scrollbar scroll away bits of my otherwise dull life...J]

(PS: Feel free to leave a comment with a link if you know of any UMPC utilities you find useful...).

Some things never change ...