Funny little Facebook interface oddities are like a butterfly beating its wings.

Facebook has struggled mightily in its short history to evolve, providing a richer & richer interface with each successive push. It seems most code pushes are staged & deployed to selected subsets of the userbase, testing, modifying, and redeploying to set n+1 - sort of like the ripple of a pebble dropped in a lake. Often, these changes help one group of people while causing some ruffling among another, and in a very evolutionary way, the ones that stick are the ones that work for the users. In this sense, Facebook does not steward for a well-developed interface grammar - it is more of a tremendously ephemeral collection of interface adaptations that users can acclimate to and accept, and that can be tooled & re-tooled several times in a single week and selectively deployed and tested on large segments of the fb population, leting test results drive the evolution of implementations. It's like building a castle by tossing rocks and seeing which ones don't roll away...

Unfortunately, that does not make for interface changes that are particularly longevonous or even follow the interface conventions that made the standardized GUI possible in the first place. Today, I noticed while posting up this important news item

that there is an exceedingly odd behavior in the management of the link title when using javascript to share a link on Facebook. Notice how the name of the link in this case appears to be the full URL of the image I am trying to share. So as the mouse passes over the bolded URL, the pointer changes to a hyperlink pointer, but if I click on the hyperlink, it is replaced by an edit-control, and the pointer changes to an i-beam, even when its hot-spot is outside the client-area of the edit-control. This creates a confusing scenario because, strictly speaking, it is a misuse of the classic finger indication that when you click you will be taken to other content referenced by the hyperlink under the pointer. Minus 1.

So suddenly the focus is in this edit-control which has replaced the former representation of the title URL with the entire URL highlighted in an edit control, meaning in the Design Guidelines, that were just flouted, that if you start typing, your type will replace the current selection. This works fine, and with your first keystroke the clunky URL is gone. Except that because of the dimensional change (the edit control is a single line text-box, while the former representation of the URL was muliline) the position of everything below changes and possibly the pointer, which you clicked on a different shaped object than what is there now, is left where you clicked, away from the focused control, though shaped like an ibeam. Minus 2

Now, here's the big problem: If you delete the URL & replace it with nothing, or with white-space, 

you tab out of the control, and the anchor text you could click on to edit the title of your post simply disappears!

...and now, if you move your mouse in that neighborhood, there is no anchor to be able to re-edit the title. As your mouse hovers over the appropriately grayed-out reference to the source hyperlink that used to be below the title of the post, the cursor changes to an i-beam, letting you know that this text, although abbreviated, is selectable. Well - not the contents, as in the actual URL, but the visible abbreviation.

Now, it looks as if the title control for the post is gone forever, but if you keep hovering, you will find an invisible one-space anchor that gets all highlighted, underlined, and happy when the mouse passes over it,

...and there you are - you can edit the title once again, so at least we're not stuck in an irreversible state-change in an edit dialog when we visually lose the title, but the adaptation of leaving it with no border, stuffing it with a space to make it accessible, and rolling it out like that, letting users figure it out, is doing the internet a disservice, because people will learn the kludge and even get used to it, and the next thing you know perfectly clean solutions to interface problems all over the web will get tossed out in design meetings because it's 'easier' to do the way that everyone knows from Facebook, just like it's 'easier' to think that Obama is Muslim, and the next thing you know you have a bunch of frustrated users on an Easter-egg hunt for links on every page they visit, if you catch my drift... Minus 3

Hence the title reference to Butterfly Effect. This is only an example, but it gives an idea of how grammars, including visual ones, can deteriorate as a result of perfectly innocent misapplication like this getting rapidly embedded. Given that Facebook surpassed Google back in March as the single site with the majority of all internet traffic, at 7% back then, these are weighty matters.

Well, that's all-right!

I started this blog because I felt I was going crazy seeing a burgeoning flood of bugs on major social sites, Facebook foremost among them certainly not because of deficient programing, but because they have, perhaps, one of the fattest clients on the interwebs - an interface that has many, many drop-downs and pop-up edit controls that are changing and growing on a daily basis. Hence the ironic title of my first post in this blog,  Finding Bugs on Facebook is Like Shooting Fish from a Bicycle.

Still, plenty of bugs parade in front of my cross-hairs daily, but fair is fair, and I need to say that bugs are not all I see. Tremendous interface improvements are also happening on a daily basis all over the place. YouTube, after its takeover by Google, underwent a massive and very positive transformation in the space of six weeks. I did not have the foresight to capture some of the more salient examples of clunky interface replaced by little things that make my CPU blip and make my interaction experience far better than before, but they are myriad - I would estimate about 60 substantial interface changes there, most of them completely unobtrusive even when adding substantial functionality, and all for the better. But there are two changes that I've just recently noticed and captured in screen-shots that bear mentioning.

The first is just plain transparency and politeness. I recently reviewed & updated my profile on YouTube, and when I chose to share my voting on YouTube with my Twitter account, I got this message:

Now, that's just plain decent. Having seen the way most pretender video-sites handle their privacy, I have to say that this just gives me the warm & fuzzies - it is so not-slimy that it completely raises my esteem for Google and their properties.

The second is like that holy grail of Facebook, the 'unlike' button. It seems like low-orbit rocket science to be able to de-rate posts from a source, or, better yet, with specific content (contex dimensions like "is it a game, such as "Farmville", would be a good start) and have the level of posting bleed-through to my wall get attenuated, or marshaled to a moderated queue, so that my wall is not flooded with stuff I have no interest in from a source I do have some interest in.

Nevertheless, there's a second, complimentary problem that a month or two ago was a real problem: When there's a post I really want to erase from my wall, measures available were downright Draconian. Hitting the 'X' on a post from Jeremy about his high-score on Bejeweled Blitz gave me two choices - leave the post there, or stop seeing posts from Jeremy altogether. Now, I can see how early-days implementation would have seen this as completely adequate, but, particularly, when I get the same post on my wall, with slightly differing links, from two people, I do not particularly want to see both of them cluttering up my feed, yet until recently, no such choice was available. What I just noticed, and I think it's been there for a week or two, is that Facebook has improved on that mechanism, so that today, when I choose to remove a post on my wall, I see this:

Good work, fb! - Now I can get rid of an occasional post that is not relevant to me without sending the publisher to Siberia. No bug there!

Conspiracy Theory...

Conspiracy theory used to be a neutral legal term describing the supposition of collusion between political, criminal, or civil interests between disparate organizations to cause harm to a person or entity. In modern usage, it is used in a manipulative and propagandist way as part of ad hominem attacks on the credibility of a claim. I see bugs in major websites like Facebook every day, and often these are quite transient and difficult to reproduce during their short life-span. Many would call me a conspiracy-theorist in their Pollyanna effort to avoid ruffling the corporations that might feed them in the future, but I just caught a little fish, and so here it is. I posted a 'status' update on fb, and when I went to my profile to look at it, it was doubled-up, like so:

It's plain to see that there's no funny-business - both updates show roughly the same time: "less than a minute ago", and they are identical. One could chalk it up to bad de-bouncing in the button code, and I'm certain that without some serous organization it would be difficult at best to reproduce. I'm guessing the debouncing code does not account for the particular traits of a broadband connection from Nicaragua - tired relays, and tragic DNS machines, resulting in a fairly stable throughput with exceptionally high jitter in packet-response time. Let's leave that to better propeller-heads than self, but it's hard to feel sorry for engineers who do this wrong after getting, literally, millions of dollars to leave a perfectly cool company like Google to join fb.

It's a bug-du-jour!

A Little Thing - They Never Fail...

OK - this is honestly one I feel bad about because I am a supporter of opensource, and have the greatest respect for the community that, like myself, devotes time & energy insuring there is good free software out there for the public to use without a corporate yoke of licensing fees, giving away your children or your freedom, or any of the other inherently dirty dealings of corporations for profit. The GIMP is an amazing accomplishment - a Graphic Image Manipulation Program written by charitable contributors and maintained by an open community. GIMP rocks - it does a lot of things we have come to know and expect in fancy graphics manipulation really well, and the OSX port is not shabby at all. It is not rewritten in the native mac interface. Rather, it runs under X11 for OSX.
Notwithstanding, here is a little curiosity. The OSX desktop provides an 'Appearance' setting in System Preferences. This amounts to color choices for the basic graphical metaphor. The default is a theme called Aqua, which provides watery aquamarine tones for scroll bars, title-bars, and window-management tool icons (such as minimize, maximize, & close, list-box sliders, & the like). In OSX 10.5, which is what is installed on my workhorse at the moment, I have selected 'graphite' - nice neutral gray everything, but when I run the GIMP, all it's window controls appear in aqua, like this:

Oops! - As you can see, the control buttons on the window right below appear in Graphite, yet the GIMP controls, in the upper half of the image, are stuck in Aqua.

Not a big deal - but it is a 'bug du jour'...

An Old Programming Story

This is not so much a story about bad programming skill, or the inability to code algorithms, but more about short-sighted thinking, cut and paste garbage, and the high cost in readability that others have to pay when one cannot be bothered to think 2 steps ahead - which in my book, is worse than being unable to code an algorithm because it carries heavier downstream consequences.

Back around 1998 I was writing a system in an early J2EE framework called Silverstream for an FAA certification outfit. It was a small contract for the consultancy that I was working with, so when I needed a resource, they gave me a very green programmer - let's call him Yuri.

In this first phase of the project, we needed to implement a framework for data entry & validation in tabs, and wanted a visual clue on each tab to indicate the state of that tab's data, so in a street-light metaphor, I defined it thus:

I placed a small spherical gif next to the name of each tab, and changed the color of the sphere to correspond to the state of data in the tab.

Gray = empty or blank.
Yellow = has data that are not yet validated (against a server).
Red = has data that require correction before saving (failed validation).
Green = has data as saved on the server.

I asked "Yuri" to program the tabs with a validation object that had an instance variable of states mapping to these colors and could receive a message from various places to set itself. The fact that "receive message", "instance variable with access methods", and every other object-oriented term that came out of my mouth fell on completely deaf ears did not even cross my mind at the time. I thought that blank look was just the nervousness of his first real consulting assignment.

A couple of days later, I saw the result:
No objects, no colors, but a switch statement with lots of cut & paste in each case, and the following handy & intuitive abbreviations:
He started with an empty form, which was gray, so he simply used a one-character string (not bounded in any way - just a string that would break code if it was more than one character long), and selected 'g' for gray.
Then he retrieved some data from the server, which I had defined as green, but he had used up the 'g' for gray, so the next letter up, thinking with exasperating pinhole logic, was 'r' - <i>'r' now stood for green...</i> Thanks, "Yuri".
Then he modified some data on the tab, and implemented the 'y' for yellow.
But when he tried to save it & it failed validation, he needed to implement the red flag. Oops! (if you'll pardon the pun, because it was anything but OOP!) 'r' now stood for green, remember? - So he implemented red to be referenced as 'e'.

The end result? A system where:
Yellow='y'
Gray='g'
Red='e'
And... for the big prize in clear programming:
Green='r'

Lol

Facebook Interfaces, Privacy Panels, and Humans

Declarative visualization in internet applications loosely follows a paradigm that was originally established by Xerox PARC in the 70's and made ubquitous by IBM, Apple, and Microsoft, among others. IBM's Common User Access Guidelines, Apple's Human Interface Guidelines, and Microsoft's User Interface Guidelines are veritable bibles to the programmer writing interfaces for these operating systems, and largely follow the same visual grammar: one that over time most every modern computer user has become quite comfortable with. Radio buttons are used for mutually exclusive choices, while check-boxes signify the toggling of mutually independent selections in a list, and check-marks are used in menu items to toggle independent selections just like check-boxes in a list.
The enrichment in web interfaces over the past 5 years has seen many graphic designers invent a slew alternate ways of visualizing information. The fact that the internet is pretty democratic despite the best efforts of governments, so far, means that there is no graphical police, and that some very squirrelly ways of implementing declarative actions often find their way onto popular web-sites and sort of infect choices other designers make, knowing that users are familiar with this or that way of doing x. Ignorance is no doubt to blame for a lot of these declarative slangs, but I'm guessing that concerns of 'look' over a solid visual grammar, and to an even greater degree the unrelenting pressures of time to market are really at the root of a plethora of visual patois that defined the internet until quite recently much like pidgins in remote islands.
Recently, that has changed a great deal - in no small part thanks to the internet shake-out brought about by major sites like Facebook & YouTube. Facebook is pretty big - not just in terms of its popularity & user-base, but the complexity of the site is big and growing every day. Overall, Facebook has done a fantastic job clarifying their visual metaphors with each redesign so they are more self-consistent with each iteration.

That's why it bugs me when I see things like this:

The Facebook Privacy panel must be visited a million times every day. There is a check-mark below the right pane with the legend "This is your current setting." To the savvy user this is such a small problem that it's hardly noticeable, but it is an interface design problem that will confuse the learner and basically train them to ignore information that is poorly presented, or worse, confuse them to the point that they do not understand the information because of the miscommunication. At least in part, this is why we see recurrent comments about people declaring themselves unable to use Facebook.

So let's have a look at why this is a problem. First, the panel has a list or menu in the left pane, with "Custom" currently highlighted, and checked. No visual clue is present to explain that this is misusing the "navigation panel" metaphor, because selecting different elements of that list does not change the right pane, but rather changes values in that pane to specific presets. It's not the same thing.
Then, the Custom selection is checked. Check marks in GUI guidelines are intended to show that a visual selection has been made from a menu item, like this:

It's pretty obvious looking at this menu that I have the Status Bar turned on, and that if I click on it, the check-mark goes away along with the check-mark.

So the check-mark in the selection at the left (in the Facebook case) is actually telling me that I have selected "Custom" presets for my security settings, which means no presets at all, while the highlight is telling me that I am looking at Custom presets on the right, and the legend in the bottom right corner of the panel, in the right pane, is explaining what the check-mark clear on the opposite side of the panel means.

Well, just to see, let's change the selection of presets to a different one to see what happens:

OK - that at once got clearer and messier. If I get off my Human Interface Design Guidelines high-horse, and accept that the check-mark is to the right of the text instead of the left, that is is being used to denote the current selection in a set of mutually exclusive choices, and that I can't make a different selection by clicking on it, but rather have to navigate to it and then click the button in the lower right corner to get the selection to change, then I am a typical Facebook user. It makes its own kind of sense and has definitely been thought through 80% of the way. But notice one thing more: Now, there is no legend, even at the opposite corner, to clue me in to what the check-mark means, exactly.

The truth is, when I first noticed this, I had just landed on this page and thought: "How silly - they have a legend showing a check-mark to indicate what the little gray dots mean. Must have gotten the wrong information from the person that did the right pane to the one that did the legend!" - Silly me - I guess I'm just not enough of a Facebook expert!

The Progress of Progress.

It's interesting that progress bars have not progressed terribly in the last three decades. Of course in 1980 progress bars were ASCII and used mostly on technical utilities and software installations, and by 1985 there were a lot of graphical environments such as the Macintosh and DR's GEM that had nice smooth progress bars that advanced one pixel at a time. Today, these workhorses are all over the place, and we mostly spend time staring at web-based ones telling us how far along an upload or download might be. Interestingly, their resolution has turned out to be of no consequence, so many progress bars out there show stepped output just for stylistic reasons.

I have written a lot of software since 1977, most of it gone forever, so I have made my share of progress indicators. It's always fascinated me that for anything that has more than one part it is quite difficult to get accurate expressions of the proportion of a task that is complete. When you have two files, for instance, and one is 20% larger than the other, is the job 40% complete or 50% complete when you have released the first file's handle and not yet opened the second's, if you're doing them sequentially?

Questions ranging from network latency and cross-traffic collision and resend rates all the way through whether different files process differently all would have to be answered quite exactly to have accurate estimations of the number of operations remaining as a percentage of total, or the number of clock ticks. Time to completion estimates on uploads and downloads can and frequently do go bad with just a little interruption in the throughput rate, and we just sort of take it for granted and mostly don't even pay attention. Here is a very silly prediction from Facebook - and I dare say it was dead wrong:

 

Now, if you take the total size of the remaining portion of the file to upload and divide that by the current transmission rate, which is 0, you should get a divide by zero error, which even mathematically states that there is not enough information to complete the operation.  The answer is not "Infinity", but  "Undefined". Having a simple branch in the program that produces a slightly less unintelligent message, like "There appears to be a problem with your connection. We are not making any progress." would do a lot better than "Infinity hours remaining."

Further, if you look at the fact that 1/10th of a Megabyte has already been uploaded, dividing that 100k by the elapsed time so far should give you an all-inclusive and somewhat more realistic guess as to when the process might finish. In fact, I walked away from this one and when I came back an hour later it was done, and I'm pretty sure that I did not then become transfinite...

Pet Peeve... Sloppy Text-parsing.

The last half-decade (why can't it just be a pentade, neologically speaking; and is neologically also a neologism?) has seen a quantum leap in dynamic text generation. I will, for the moment, table the discussion about internationalization, rosetta, and the phenomenally good work Google is doing with translation by using list-processing and anecdotal data gathering to make transliterations more comprehensible. The point is that there are all these little phrases that are being generated by back-end scripts explaining, for example, that you upload(s) is(are) complete and you can now edit the description(s) by following this(these) link(s), etc, etc.
Obviously this gets into massive case-statements, which, if they are good, are making good use of indexed and correlated database tables to be able to handle not a dozen, but an essentially infinite number of possibilities for the conditions that determine the correct suffix for a word, or the verb-form that applies to the state of an action, among other things. In a word, object-oriented.
However, every programmer in the breech, particularly when it involves working for large organizations where the time to get something done right can be entirely steam-rolled by the necessities of marketing plans and product management, will be sorely tempted to write 'the prototype' - a hand-coded case that handles all the currently known cases but is not exponentially scalable, because come tomorrow morning's agile scrum, she'll be a lot more comfortable saying: "It's gone to QA. Check!"
So, in deference to the programmers that make these faux-pas, and understanding that it's not their inability to do better, but the pressures of programming as a business, here are a couple of examples of the things I'd rather get right first-time-out on a blown schedule and never have to shore-up in a desperate frenzy just before the dog & pony for funders:

eBay, Inc. - They are one of the anchor-stores of the internet, no doubt. They get the job done exceptionally well, but things do slip through the cracks. Here is a little gem I caught a couple of months back:

Note that on the 5th line, it says "that ending on May yadda yadda". Let's just say that I think I could do better, but not every day. Obviously, there is a time-window for things treated in the immediate future, which say "ending", and those evets that are past, or "ended". Obviously as well, the programmer who put the "that" in did not coordinate very well with the programmer that made the break between "ending" and "ended" - it could have been the same person - it was obviously 2 different tasks, and they don't match up correctly because the code is sprayed with imperfectly duplicate logic. Nonetheless, this is highly visible, and just the sort of thing that makes QA people pull their hair out, because, I'm certain, it does not crop up if you just write a short little test-script that runs through just the use-cases QA was handed, yet it has high enough visibility that it got caught, at least here.

On a similar note, here's a little YouTube cuteness - if you wrote this bit of code, I bet it's a case that slipped through your fingers because you were afraid that spending too much time on the problem might cause you a backlog and redistribution of your queue - sort of like a lawyer worrying about whether their client was guilty or not - just no time to wory about such things if you hope to ever make 'partner':

The 23th? Really?

And for those among you who have the privilege of administering hosted accounts on one of the many hosts that use cPanel as their administrative interface, ever log on? What the hell is this:

...if WHAT does not automatically WHAT? - q.e.d.

Finding Bugs in Facebook is Like Shooting Fish From a Bicycle

There is rarely a day when I get on the computer and don't find a bug somewhere on the interwebs. Most days, it's big, huge, glaring Kafkaesque monstrosities. It always amazes me how other people don't seem to care.

But I digress - content will be the proof. Today I spent a couple of hours on the computer, and finally, just now, decided to start blogging the bugs I find. Some of them are very ephemeral - they are caught by alert development teams and dealt with handily. Some are edge-cases that you know result only form a very specific coincidence of state attributes - these are the more fascinating ones to me - like the one last week where when the final set of photo albums for a given facebook user amounted to less than a whole multiple of the 5 thumbnails in the strip, selecting it through the 'last' link would cause the display to be properly truncated to 2 (or whatever the case might be) album thumbnails, and scrolling left from there would not restore 3, 4, and 5 thumbnails. The display would be ratcheted back to 2. For a bazillion-dollar valuation, stuff like that should be kept to a minimum, but it is not. There is, in fact, a little parade of daily bugs in facebook, and a pretty steady stream in the browsing graph of any user.

We become inure, move on, perhaps wonder if we really saw that, and just move on. Well, not anymore - at least sporadically, we'll catalog what we come up on. It might also be good to see how the half-life of some of these is.

So for tonight - what happens when you have an interesting editorial in a newspaper from a 'developing' internet culture? Such is the case over at the Pakistani Daly Times, where I'm guessing an enterprising young staffer decided to overcome a pesky problem. Some old-fashioned, cigar-chomping newspaper editor said: I want the date to look like a proper date." Showing slashes in a date on a friendly URL without a corresponding directory structure would require some parsing and routes.rb or mod_rewrite, but instead, this clever intern decided to use back-slashes, because, though marginally and improperly, they do fly...

So the fascinating article's URL ended up looking like this. OK - bad programming, a small problem. Now, if you go to that article and try to share it on Facebook, you will find that the link does not work - the URL gets cut off by Facebook at the first back-slash, right after "2010".

So there it is - let's see whether Facebook picks it up & works around it, the intern at the Pakistani Daily Times gets a sound thrashing, or both.