As soon as I read about LinkedIn Mobile today, I had to try it out. Forget everything you hear about Facebook (and its “mobile” application), LinkedIn is the most useful business networking tool out there, and now that it’s mobile optimized, it’s bound to be even more entrenched in my professional life.Here are some quick screenshots of the beta service on my Samsung Blackjack:

Robert Scoble writes that Microsoft and Yahoo’s attempt to merge is good for Google’s mobile ambitions. I have stripped down his very long post to the bare essence:

Google stands to gain HUGE by slowing down this deal. …the real race today [is]…for ownership of your mobile phone. …every month that Microsoft and Yahoo will be stuck in some courtroom arguing out why this is a good deal means money in the bank for Google as they close mobile phone deal after mobile phone deal. … IM is harder to monetize than email is. Do we really think Google is concerned about either email or IM? [No.] Why not? Because they aren’t taking their eye off the mobile ball.

There’s lots of redundancy between Yahoo’s and Microsoft’s global efforts, but it’s not a perfect overlap. For example, I use both Yahoo Go and Live Search Mobile on my Windows Mobile-based Blackjack. The map and business listings and the new voice-recognition “speak” feature are better on Live, but reading the news, weather, and using Flickr is better on Yahoo’s Go. A single combined app with the best of both would be incredible, but I expect that culture clash will keep the Live and Go teams at odds for some time, until the stronger team devours the weaker. Ah, capitalism.

In the meantime, Google will forge ahead with Android (even a delayed Android) and let MSFT+YHOO cannibalize itself and give up the rapidly growing mobile market. It’s feasible but not guaranteed. After all, it’s easy to claim that unreleased software will someday crush other software.

Today a blogger named Philip Lenssen wrote a post on Google Blogoscoped that showed how private but otherwise unprotected SmugMug galleries can be downloaded without the owner’s consent. In the wake of the recent and similar MySpace private pictures hole, this seems like a serious PR problem waiting to happen. How long will it be before someone’s “private” SmugMug pictures get some major unwelcome publicity, and SmugMug along with them? I’m sure someone’s crawling all of SmugMug right now and packaging it up as a Torrent file (and no, not me).

Here’s a quick description of the “hole” as I understand it. All of SmugMug’s galleries use an ID number in the URL. If you want to see someone else’s photos, you just manually change the ID number to something else; it’s as easy as changing a URL from smugmug.com/galleries/1000 to smugmug.com/galleries/1001. As long as the photos are not password protected (which is a separate preference setting), you can view the photos regardless of whether or not the user has marked the gallery itself “private”. Mr. Lenssen goes on to describe that one solution is to change from numeric ID numbers to GUIDs which are non-sequential and almost impossible to guess. DonMacAskill, CEO of SmugMug, has not yet posted about this in his blog (why add to the fire?) posted his thoughts about this already, but an e-mail from him is quoted in the original post, admitting that GUIDs would be preferable:

I’m in completely agreement, that GUIDs would help greatly here, but I’m afraid our system wasn’t built for GUIDs, and retrofitting our code and database to support GUIDs would be an extremely expensive proposition. [...] We’re also very open to change – nearly every feature, bug fix, and enhancement is driven by customer feedback, like yours. If our customers (or potential customers) asked us to adopt GUIDs because this was a bigger issue than we were aware – we would.

I have an alternative and cheap solution for Mr. MacAskill that would solve the guessable URL problem without using GUIDs which would be a minor patch to SmugMug’s web code that doesn’t necessarily require any database change, although it would benefit. It would satisfy one of SmugMug’s design goals for private pictures/galleries, namely that you could send a link to a private item. The suggestion is this: leave the URLs alone, but add a checksum key as a separate parameter based on private hash salt.

Today Yahoo announced that they’re enabling OpenID on 248 million accounts, which unarguably pushes this single sign-on technology into the mainstream. In my opinion, this is also a huge win for mobile web users too, and here’s why:  signing into a mobile website on your mobile is very tedious and painful, and few (if any?) mobile browsers have integrated password management yet. Furthermore, even if you have the patience to tap out your e-mail address and password, some sites won’t take it or throw SSL errors or require JavaScript. For this reason, I have not been able to sign on to mobile Facebook through my Blackjack in, let’s see, ever.

Imagine a web where most sites are now compelled to offer OpenID as an alternate sign-in method (and who will be able to afford ignoring 248 million users?). Suppose that Yahoo makes their OpenID sign-in page incredibly mobile-friendly, a likely scenario. Signing in to web sites through your mobile will become a lot easier, which will in turn make the mobile web that much easier to use and relied upon.

I believe there are three web content related technologies that will help mobile browsing adoption increase dramatically if they become ubiquitous: OpenID (or a standard like it), microformats, and mobile alt links. Let’s see what happens.

You receive a “(Filename) is locked for editing by ‘another user’” message when you try to modify a document in Windows SharePoint Services even though you are the user who previously opened the document

While I was working on a document through our new Sharepoint team site at GWC, Word crashed due to some permission changes. After trying unsuccessfully to open it again many times, I came across this MS support article:

…

CAUSE

When a document is opened by a client program, Windows SharePoint Services puts a write lock on the document on the server. The write lock times out after 10 minutes. Users cannot modify the document during the time when the document is locked.

In a scenario where the program that opens the document unexpectedly quits or crashes and you try to open the document again before the write lock times out, the message that you receive says that the document is locked by another user. This behavior occurs even though you are user who previously opened the document.

WORKAROUND

To work around this behavior, wait 10 minutes before you click Edit in ProgramName to open the document again. (dismayed emphasis mine)

God Bless Microsoft, and bless their arbitrary 10-minute timeout that protects me from myself. I have six minutes and counting. (Hums impatiently to self)