Tuesday, February 07, 2012

Google+ bug report: links that get disabled

Starting yesterday, I noticed that links to my blog posts on my Google+ posts page, that I have put there through Blogger's share function, stop being links a second or two after my G+ posts page loads. Even weirder, it only happens when I'm logged into Google. Anybody else have this problem?

Following is the most exciting video evar a screencast that I made, using Screenr, to show the problem. You'll probably want to go full screen. The text that's displayed at the start of the video is reproduced below.

(alt. video links: YouTube | Screenr)

If you really want to scrutinize this video, click the Screenr alt. video link, and click the HD button when you get over there.



Google+ Weirdness

You may want to PAUSE THE VIDEO so you can read this whole page.

I use Blogger's Share function to cause my blog posts to appear on my Google+ posts page. Beginning yesterday, I noticed that the post titles, which are supposed to be permalinks back to blog posts, are no longer links.

More precisely, the titles are links for a moment, as the page is loading, and then they fade to gray and stop being hyperlinks.

This happens with Chrome and Firefox on a machine running WinXP, and with Firefox on WinVista.

But that's not the weird part. The weird part is that it only happens when I'm logged in to my Google account.

First, I'll visit my Google+ posts page while logged in and show that the titles are momentarily links. (I'll middle-click one of them, which will cause it to open in a new tab.)

Second, I'll log out of Google and then revisit my Google+ page, and show how the titles remain links.

My Google+ posts page is at http://gplus.to/bjkeefe.

The full URL: https://plus.google.com/u/0/102552943911220179348/posts.




[Added] A version of the above is also posted on Google Groups, in the Google+ Pages Discussion Forum.

[Update 2012-02-08 14:16] As of this moment, the problem seems to have gone away. Now, I'm not going to take all the credit, but that was some seriously good videography, wasn't it?

6 comments:

Jack said...

Interesting that you are using the date format YYYY-MM-DD. I've been having a running debate with my boss about that date format with my boss for the past week (whether to use it in that application we're building).

The big argument against it, of course, is that's it's unclear. People don't know if 2010-03-05 means May 3 or March 5. On the other hand, it sorts nicely in a list of dates and makes for easier visual comparison of dates to see which are newer/which are older.

Plus, you can convert them to whole numbers by yanking out the delimiters, making programatic date comparison easy.

bjkeefe said...

I sort of buy the argument about the potential for ambiguity, if I think about the American convention versus the European one in the older style (is today 2/9/2012 or 9/2/2012?), but I don't buy it completely. The YYYY-MM-DD[:hh:mm:ss] format has the same most-significant to least-significant ordering as do regular numbers, e.g., thousands, hundreds, tens, ones. As far as I can tell from looking at places where international groups of developers hang out, everyone gets that, and no one thinks 2012-02-09 means the second day of September.

And of course, there is the easy parsing advantage, as you note. And what's more, there's a purely lexical one: even a thoroughly dumb sort gets you what you want, say, if you've got a bunch of filenames of a form such as logfile-2012-02-09, logfile-2012-02-10, …

Jack said...

I sort of buy the argument about the potential for ambiguity...

I've had to think about this a lot over the years, because I manage a lot of web sites for a multi-national company, i.e., a company with employees in North America, South America, Europe, the Middle East, Africa, and Asia. And we need to use date formats that are understood by everyone.

The American favorite -- 02/12/12 -- is instantly recognizable to Americans, but totally baffling to almost everyone else in the world and therefore unsuitable for international usage.

I've seen a lot of people try the YYYY-MM-DD format, but it, too, always causes confusion and misunderstanding. It violates the rule, "don't make me think."

What we finally settled on as a standard was, interestingly enough, the date format you used in point 2.1 in a post at the Tumblr blog: 2 Feb 2012. This format has the benefit that it cannot be misunderstood, no matter what the audience or what the norms are in a particular country; it doesn't require any thinking, and leaves no room for ambiguity or confusion -- if those things are deemed important. (Some people are willing to pay a high price in ambiguity and confusion if it suits their personal preferences and sense of "what's right." Especially in the IT world, it seems, there is a lot of casual disdain for users and their needs.) This format also preserves the least to greatest ordering for those who are bothered by the conventional US date format's MM-DD-YY problem (medium > small > large).

The dumb sort point you make is the best argument for YYYY-MM-DD, especially (or only, perhaps) in those cases where the date cannot be extracted or parsed out -- as in file names, like you said.

My boss is advocating for the YYYY-MM-DD format for dates contained in metadata stored inside text files that we are using with our application because he feels that (a) it will be, programatically, easier to compare dates (which date is older) if they are in that format, and (b) it will be easier to tell at a glance (visually) which dates are older. Point B is true as long as one understands the format - as long as one has already done the thinking to figure out what the 2nd and 3rd nodes represent. In my experience, people viewing YYYY-MM-DD are always getting the MM and DD mixed up.

It's silly, but I do like the fact that I can extract the dashes out of the dates (in YYYY-MM-DD format) using a simple REPLACE function and then subtract one date from another to find out which date is older. (Eg., 20120212-20120130.)

But this is really kind of silly because it's just as easier to run the numbers through a DateDiff function and not only find out which date is older, but get more detailed information about exactly how much older.

Jack said...

It's interesting that you've been using this date format for some time, and I just never noticed until this recent debate with my boss...

This post is a good example of my boss's point that when there are two or more dates side by side in the YYYY-MM-DD format, it's visually quicker to recognize which is older than it would be with other date formats - because the bigger numbers (years, then months) come first.

It's an interesting point...

Jack said...

Whoops, got the wrong link. Was supposed to go here...

bjkeefe said...

I'm pretty surprised that the YYYY-MM-DD format causes confusion. Not to argue from personal incredulity or anything, but I have never encountered anyone who misinterpreted a date written that way. I will grant that some people, especially non-computer types, find it momentarily jarring -- my sister once complained, "What is this stardate stuff???" -- but never has anyone mixed up the month and day.

I agree that for text that is exclusively or at least primarily intended for human readers, the 12 Feb 2012 style is best. It's unambiguous, and as a bonus, tends to suppress the desire to put a comma in. And if you want a day of the week, for extra helpfulness, just throw it at the front, and it still looks good: Sun 12 Feb 2012.

I agree that there are now many ways for computers to handle human-style dates, and so it's probably close to becoming moot. But right now, if I had to decide on a style, and the dates were primarily going to be of use to computer programs and computer programmers, I'd still go with YYYY-MM-DD.

ShareThis