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. Here’s a simplified explanation of how it would work. Suppose that every user in the system also has a private ID number (which is probably true). When creating a link, SmugMug’s system could calculate a number based on the user ID and the gallery ID and append it on the end of the private gallery URL. For example, the calculation could be the sum of the user ID and gallery ID, divided by an arbitrary number like 29 (this is the private hash salt). If user 123 has gallery 456, then the checksum value would end up being 19 (floor, not rounded). The private URL would be something like smugmug.com/galleries/456?checksum=19. For private galleries only, the page that shows the gallery or image would calculate the checksum each time the page is rendered and show an error message if the checksum is wrong or missing. This is similar to how Scribd allows users to email password-protected documents, without embedding a password in the link itself. For increased security, SmugMug could randomly generate user-specific hash salt in their user table. Either way, this would make auto-crawling private galleries as difficult as transitioning to GUIDs while keeping the existing functionality of private galleries intact.

You’re welcome, SmugMug. This one’s on me. I am an independent technology consultant, so if you would like my help with technology, feel free to contact me.

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.

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:

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

…

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)

Here’s a simple fix to a common ASP.NET development problem. The only code you really need to put on a log out page is “FormsAuthentication.SignOut()”. However, any controls or code that change based on authentication (such as the LoginView control or the LoginStatus control) will not reflect that the user is logged out until the following web page. This is bad for usability because you may be presenting links that are technically un-clickable. I’ve seen forum posts that advocate redirecting to another page, but there’s a simpler fix:

Private Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
	FormsAuthentication.SignOut()
	Context.User = Nothing
End Sub

Setting the Context.User to nothing does the trick.

Today I ran into a problem that required two directories to be synchronized. This is more than just copying all of the files from one directory to another, which XCOPY does very well. I had to ensure that there were no orphaned files in the destination that were not already in the source. The closest thing XCOPY comes to this is to copy only files that already exist in the destination. This can be a problem when deploying ASP.NET projects over and over, because “XCOPY deployment” does not account for deleted or renamed files.

There are many shareware GUI programs that can synchronize two directories like I wanted, but that seemed like overkill. I basically wanted a Windows version of rsync that would work out of the box (if you know of one, please share in the comments). I had already fired up the old source control editor and was about to code up a quick console program to do this when I realized that the same thing could be accomplished with a recursive batch file. Ten minutes later, I had this little script:

@echo off

if "%3"=="" (
echo Syncing %1 with %2
xcopy %1 %2 /d /i /y /s
)

for /D %%d in (%2\*) do (
if not exist "%1\%%~nd" (
echo Deleting directory %%~nd
rd "%%d" /s /q
)
)

for %%f in (%2\*) do (
if not exist "%1\%%~nf%%~xf" (
echo Deleting file %%~nf%%~xf
del "%%f"
)
)

for /D %%d in (%1\*) do call dir_sync.bat "%1\%%~nd" "%2\%%~nd" 0

Save this text as dir_sync.bat and remove the double-backslashes that WordPress adds in. The command syntax is: dir_sync.bat “source directory” “destination directory”. Be sure to enclose the paths in quotation marks if there are any spaces.

If this command saves you ten minutes or spares you a pointless purchase, I’m happy to be able to pay it forward. If I just killed your shareware company, I’m really sorry.

I got a new phone a few weeks ago: the Samsung Blackjack, otherwise known as the SGH-i607. It works great with Skweezer, and since it’s a Windows Mobile device, I’ve also gotten a chance to see it in action with the Yahoo! Go and Live applications, both of which have their pluses (Flickr/Maps & Directions respectively) and minuses. Overall I’m very pleased with the new phone though.

One thing that has been a little odd has been the fact that sometimes my network connection has trouble restarting. After the phone has been idle for a while, and more often when I’ve traveled (perhaps switching cell towers?) my phone’s browser would be unable to make any connections. Navigating to new pages would show “Connecting” in the status bar for a few minutes before returning an error. Network-enabled applications such as Yahoo! Go would also stop working, showing time-out errors or “unable to refresh” messages. I called up Cingular AT&T tech support and they told me it was probably a coverage problem: they claimed you need at least four bars to browse the web, whereas you can send SMS and talk with fewer bars of course. That is only half the story, as this problem sometimes crops up even with great signal. Fortunately, I finally found the cause and solution.

After downloading a utility from Microsoft that tests the network, I concluded that it was probably an IP/DHCP problem. If it were a computer, I could renew my IP address at the command line or use the “repair my network connection” utility in Windows which does the same behind the scenes. How do you renew your IP address on a Windows Mobile phone? You can restart the phone for ten minutes, buy network utility apps for this, or you can use this little trick, which is quick and free.

1. Access the Wireless Manager application. You can quickly get to it on the Blackjack by pressing the power button on the top and then selecting #2.
2. Disable the phone. This is “airplane mode”.
3. Enable the phone.
4. Wait until the phone displays the network is available. On my phone at my house, it shows “Home Service” (which is a lie) then “Emergency Service” (which is disturbing) before settling on “AT&T”.
5. Resume network-dependent activities. It is usually not necessary to restart the offending application, just retry whatever it was that failed, such as refreshing content or navigating to a link.

I can not yet figure out how to make YouTube mobile work with the built-in Media Player. However I stopped trying to make it work after I realized that I do not care to watch YouTube on my mobile phone.

We just updated Skweezer again this afternoon with a few minor stability fixes and improvements. Among them:

• Once you log in, you now remain logged in for two weeks.
• For more modern phones Skweezer now allows limited CSS information which should make many pages look nicer and less bare. If you have a nice big color display, you should be able to use it. Of course, this means the page is not as small as before, but we want to push the limits of your phone’s browser.
• We’ve corrected HTML entity decoding errors that prevented some pages with foreign characters to display correctly.
• Device recognition has had an overhaul so that we can match unknown devices much better and we’re more likely to underestimate your device capabilities than overestimate them, if we can’t determine the device make and model.
• For desktop browsers, the images are not as overly compressed as they were. We’ll see how this works with our CPU and bandwidth.

We have done away with ASP.NET forms authentication once again due to its unreliability with mobile devices. ASP.NET second-guesses cookie setting somewhere, and sadly some cookies were being changed from absolute expiration to session cookies. This would require people to log in every time they closed their browser. Since user login is only protecting bookmarks now, we transitioned to a more mobile friendly home-grown solution.

For those devices that support it, CSS is limited to formatting elements only. Rules that influence properties such as margin, top, left, and padding are removed. CSS works for inline formatting, style blocks, and external style sheets. We do not yet handle @import declarations or composite rules such as “border: 1px solid black”. Here is the list of CSS properties that Skweezer currently supports: background-color, border-color, border-style, color, clear, float, display, font-family (generic names only), font-size (non-numeric only), font-style, font-weight, text-align, text-decoration, text-transform, vertical-align, and visibility. We are debating removing “float” because it does tend to make the document flow strange on small screens. Update: float is out; testers confirmed it is not good for small screens.

One major improvement with device recognition was the removal of strings such as “UP.Link/6.3.0.0.0″ from the end of the user agent. OpenWave has gateway software deployed at various carriers which rewrites the user agent with the software’s version. Although we thought that our fuzzy match algorithm took this into account, the removal of the version string makes the recognition engine much more reliable. We are also now trying to capture unknown user agents in an effort to do more research on their limitations.

In his article The Analyst, The iPhone, And The Future Of The Mobile Web, Dan Frommer recaps a discussion regarding the pros/cons of iPhone-style powerful mobile browsers that access anything which “signals the beginning of the end for the mobile Web as we know it today” vs. the utility of mobile-specific websites. After conceding that mobile browsers suck, he goes on (emphasis added):

But even if someday everyone has a browser as powerful as the iPhone’s Safari, that doesn’t fix the screen-size problem [...] even if developers use proper Web coding standards, “normal” Web sites will always be crippled on iPhones and similar mobile devices.

Anyone who has used the iPhone on AT&T’s pokey EDGE data connection also knows that the bandwidth just isn’t there yet to browse hi-fi Web sites and actually enjoy it. And for the foreseeable future, there are things you can do with a computer that you simply can’t do with phones, such as hovering a mouse cursor over part of a Web site, browsing with Java-based navigation, right-clicking on links and elegantly using multiple browser windows.

The near future of the Internet is going to look a lot like it did in the last decade, when content creators made separate sites for broadband and dialup users. The “real” Web will continue to get more and more multimedia-heavy, with Java, Flash, and video offerings designed for broadband connections. And the mobile Web should continue as a separate entity, accounting for smaller displays, and focusing on faster-loading, lo-fi content and simple navigation with fat fingers in mind.

I sadly agree that is what will probably happen for large corporate sites or web-only businesses (like Facebook), but I would like to add that Skweezer will bridge the gap for the rest of the web which I believe will remain in the majority. Anyone who thinks there will be both desktop and mobile versions of every site is deluding themselves. Remember the early days of Firefox when IE-specific sites would warn you to download IE in order to log in? Few sites responded with separate versions (or even separate stylesheets) for each browser, but the standard accepted practice is to make your site work on all major browsers. By using good web standards, XHTML and CSS and graceful fallbacks (like specifying onclick AND href for your A tags), web authors can be sure their sites will live long and prosper.