TODO:

1. Google Search
2. Google Reader
3. Google Chrome
4. Google Maps
5. Google Analytics for the blog

In my blog last weekend, I set out to discuss whether I could quit Google’s software and services. To begin, I decided to start just with using Bing instead of Google. This caused no end of amusement to friends on Twitter who mocked be because I wasn’t searching with Google, but worse, I was using their browser all the time. That, exactly, was the reason why I didn’t start with quitting Chrome first – because I was smitten with Chrome (as Google wanted me to be). I had disabled as much sharing, profiling, and tracking as I could within the browser. But, let’s be real. It’s Google’s browser. The company that was tracking Safari users even when tracking was disabled in the browser.

So I started with Google Search, switching to Bing on my iPad and iPhone, and my browsers on Windows at work and OS X at home. Easy. I also reinstalled the Bing app on my iPhone and used it twice during the week to find businesses.

In general, Bing met my expectations. I’ll be curious over the next several weeks and months how well it works – I think there are some sharp edges, but for most cases, It will suffice.

Let me show you an example of a sharp edge. I’ve been reading The End of Food. The author mentions an economic concept, but doesn’t discuss much background around it. So I thought I’d search for more information around it. This concept is called Cochrane’s Treadmill. The truth is that both of them did a pretty bad job with this. But the Bing results were far more littered with exercise treadmill results rather than valid “Cochrane’s treadmill” results. I can sort of see why this is the case. Google’s results work so well due in large part to their large audience. That large audience is what helps to tune the results. On edge cases such as this – I can hardly imagine Cochrane’s treadmill” being a frequent search on Bing – so it falls into Bing’s long tail.

Regardless, in general, I’m pretty happy with the results from Bing. So it’s my default search engine for now. If it returns bad results for a search, I’ll check out Google results to see if it does any better. In particular, for news indexing. It appears Bing severely lags Google in the ability to index news content in rapid form.

Search engine switched out, my next task was Google Reader.

I already had heard some good things about NewsBlur. I think NewsBlur is what Google Reader could have been, if Google hadn’t forgotten about the value of RSS, and didn’t now (errantly) consider Google+ to be their most important product objective. Google Reader has practically stalled out in terms of development.

I use Google Reader every day. I use an app on my iPad that connects to it (Mr. Reader) as well. I use Google Reader to catch news as it becomes available, and would often use Mr. Reader directly, or open the articles in Google Reader and use Buffer to post them to Twitter and sometimes Facebook. I enjoy syndicating news to others, and it helps me to find what Microsoft (or other tech) news is going on.

So until recently, I didn’t think there was a substitute for Google Reader. I think NewsBlur is a more than suitable replacement. So much so that although it’s free, I bought a subscription to it. I don’t like freely available Web services – they’re the kinds of things that can disappear on you, or worse – get acquired by Google, Facebook, Microsoft or the like – and then disappear into services that don’t reflect why you signed up to begin with.

I’ve been using a developer version of NewsBlur for most of last week. It’s got some rough edges (it’s a preview), but in general, it’s amazing. Incredible configuration capability (move different panes around the screen, resize them, and lock them), filtering (which currently requires a fair amount of configuration – but in following the hyper-multi-lingual TechNet and MSDN blogs has proven to be quite capable). The developer preview also has social sharing to Facebook and Twitter – so I haven’t had to use Buffer, either. Finally, there is also an iPhone app, and for premium subscribers, there is an iPad version coming soon.

Here’s what NewsBlur looks like:

So do I miss Google Reader? Not really, no. NewsBlur has completely replaced it.

Next up – browsers. I had thought replacing Chrome would be the hardest, and it was. Chrome is fast, works reliably, and is very, very usable. That’s why I switched years ago.

I decided to move to Safari. Since I have Windows, Macs, and iOS devices, and I think Apple will be moving towards tab synchronization and general harmony between iOS and the Windows/Mac Safari counterparts.

I have moved all of my passwords over to Safari (since it has password completion now), added the Buffer extension, and enabled bookmark synchronization across my Safaris.

My only complaint about Safari so far is that it does tend to become unstable sometimes. Certain extensions (the Bing extension, possibly) seemed to make this worse. So right now, it’s just the Buffer extension I have enabled. Safari definitely doesn’t like to have Pandora running all the time – I really wish Pandora wouldn’t require Flash. I don’t think that helps reliability.

In general, I think Safari will suffice for me now. Though I did note this week that I hit a site that yelled at me for having an unsupported browser (Safari on Windows), even though it didn’t when viewed through Safari on iOS. I have removed Google Chrome from my Windows PC, and will be pulling it off of my Mac today as well.

For Maps, I mentioned that it may take some time to switch – but looks like this summer I can. In the meantime, I’ll  be using the Bing app on my iPhone for directions, to see ho well it works.

Finally, I also decided I had to pull my blog from Google Analytics, since I didn’t want to keep my Google account open at all. Quite easily, I disabled my GA plugin in WordPress. I may miss some of the insight it gives, but I’ll invest a bit of time in my log files to see what I need/want to track better over time. Luckily, my hoster, Bluehost provides decent analytics on their own – good enough for me for now.

Last but not least, I removed permissions from all Google sites for my account, and deleted my Google+ profile, followed by my entire Google account. It’s really surprisingly easy to delete your Google account – hopefully it really was deleted. 

If you asked me a few years ago about Google, odds are I would talk your ear off about privacy, about how Google aggregates your life together in a manner you can’t imagine. Ask any co-worker at my last job before I left Austin – it’s true.

Yet while I’ve still held up my stance as someone concerned about online security and privacy… I’ve lowered my guard. I’ve used Google. I use Google a lot, actually.

But Google has been bugging me a lot too.

I have, as I said, lowered my guard. I use Google search all the time. It’s like a third lobe of my brain. But I have concerns about how little Google actually cares about our privacy as consumers. As a consumer who is also a professional with a focus on security and privacy, it isn’t in my best interest to use services from a company that data-mines every action we take, and is willing to only take a stand on cybersecurity initiatives when it suits their interests and their legal liability concerns (SOPA), not ours as consumers and American citizens (CISPA).

I’m also not a fan of Google+. I believe that in the end, history will show that Google made a pretty severe mistake when it decided to prioritize itself as a social network over search. Like many companies that hit middle age, and have an identity crisis, Google has lost focus. It has lost it’s way. For me, I’ve become too dependent upon the services of a company that seldom has my best interests in mind. In the end, Google is an advertising company with a search engine, not a search engine company that has advertising. Everything they do is about maximizing the amount of time we each spend online, and learning what it can about us to help provide more accurate advertising (to make more money).

To that end, I am beginning the process of weaning myself off of Google, one step at a time.

Luckily, I never fell in love with Gmail, Google Voice, or Google Docs. I tried Google+, but never liked the user interface. I tried Google Offers, but found them more useless than Groupon deals (that’s pretty bad).

Fundamentally, then, there are four ways I frequently use Google today:

1. Google Search
2. Google Reader
3. Google Chrome
4. Google Maps

I believe that I can replace all but the last one with relative ease. The last one is troublesome for me primarily because I have an iPhone and iPad. You can’t remove Google as the mapping provider. However, what I will do is start using Bing Maps on my work ThinkPad and my home Mac when I need maps there. For the iOS devices, as I’ve stated on Twitter before, I have a feeling something we might see this summer is a decreasing dependence upon Google for iOS mapping data. Time will tell.

So back to my list. For the first three items, I intend to spend one week changing over each – and by the end of May, with a few exceptions, I hope to have changed out my use of Google properties and Google software. We’ll see what happens.

For now, I’ve switched out the default search engine on my iPad and iPhone, as well as set the default search engine in Google Chrome (my default browser – for now) to be Bing. While I’d actually like to try an alternative engine like DuckDuckGo, it can’t be configured as the default on iOS today – so no go.

Next weekend, I’ll post an update on how my life without Google Search went for the week, and update you with my strategy to replace Google Reader – a tool I use every day for news aggregation. I’ve got my eye on a suitable replacement for Google Reader, though. Without a doubt, the hardest step for me will be the last actionable one in my list – getting rid of Google Chrome. But I have a few ideas about how I will do that too. Stay tuned.

In January of 2011, I wrote my first suppositions about “Windows 8″ and the ARM processor architecture. Though we now know the version of Windows that will land on ARM will be called Windows RT, and the Windows 8 name will be reserved for editions of the operating system that will run on x86/x64 processors.

In that blog post early last year, I stated:

Microsoft has never sustained Windows on any platform besides x86. 
What would make Windows on ARM succeed where others have failed?

This is really, really important. I want to emphasize that Windows RT may do here what other versions of Windows haven’t been able to do before, which is what I refer to as “achieving architectural escape velocity“. It may. Let me explain what I mean by architectural escape velocity.

MS-DOS and Windows originated on, and grew up on, the 16-bit Intel x86 architecture. Windows 95 began the consumer step to 32-bit Intel x86 support, while Windows NT started with 32-bit support natively – but Windows NT didn’t start on the x86 processor.
I mentioned this last year as well. Windows NT was originally developed on the Intel i860 processor (a RISC-based chip) first, with the intention of ensuring platform portability. But the i860 was never supported by a released version of Windows. So it was – Windows NT, with it’s portable architecture, was born with that same x86 birthmark.

The consumer versions of Microsoft’s legacy operating systems – from MS-DOS 1.0 to Windows ME – were never available for any other architecture other than Intel’s x86.

The Windows NT-based operating system has been ported to 8 architectures in its lifetime:

• Intel i860 – Pre Windows NT 3.1 (never released)
• Intel x86 – Windows NT 3.1-Windows 8 (1993-present)
• DEC Alpha - Windows NT 3.5-4.0 (1994-2000)
• MIPS - Windows NT 3.5-4.0 (1994-2000)
• PowerPC – Windows NT 3.51-4.0 (1995-2000)
• Intel Itanium – Windows XP – Windows Server 2008 R2 (2001-2009)
• AMD/Intel x64 processor architecture – Windows Server 2003 SP1-Windows Server 2008 R2 (2005-present)
• ARM SoC Processor Architecture – Windows 8 (not yet released)

Of these 8 platforms, only two (other than x86 itself) ever supported running x86 code on them

• DEC Alpha - Windows NT 3.5-4.0 (1994-2000)
• AMD/Intel x64 processor architecture – Windows Server 2003 SP1-Windows Server 2008 R2

The DEC Alpha, though it was a 64-bit processor, ran 32-bit Windows. It used a layer called FX!32 to run x86 Win32 applications without requiring recompilation or modification. The x64 architecture, though it does not support legacy 16-bit applications or 32-bit drivers, runs 32-bit Windows applications directly without requiring recompilation or any advanced emulation layer. There is a thin virtualization layer that enables this.

So through 7 architectures (not including ARM yet), only two survived. x86 – the first architecture Windows NT shipped for, and the commodity architecture that it has survived on through the death of so many others, and x64 – an architecture that is fundamentally an extension of x86 to support 64-bit computing. Semantically, we could argue that only one survived.

But what about the Mac? What about Apple? Almost every major epoch of Apple has involved a different processor architecture.

• Apple II – 6502 processor (1977-1993)
• IIe card for Mac – 65C02 processor (1991-1995)
• Macintosh – Motorola 680×0 –  (1984-1994)
• Macintosh – PowerPC – (1994-2006)
• Macintosh – x86-64 (2006-present)
• iOS Devices – ARM – (2007-present

However, there are a couple of interesting things here that differ dramatically when we compare how Windows supported different architectures versus how Apple did.

1. When Apple added a new architecture, the old one was completely transitioned out, even if it took some time. The one (perhaps temporary) exception to this is the current world where Apple makes devices/systems using both ARM-based and Intel processors.
2. When a new architecture was added, there was a way to run legacy applications – at least for a time.

• From the IIe to 68K Mac there was the IIe card
• From the 68K Mac to PowerPC Mac there was a complex emulation layer – which actually enabled Apple to keep large bits of the OS in 68K compiled code, without having rebuilt everything immediately.
• From PowerPC Macs running Mac OS 9 to PowerPC Macs running Mac OS X, there was Classic, which enabled both 68K and legacy OS 9 applications to run on the Mac.
• From PowerPC Macs running Mac OS X to x86-64 Macs running Mac OS X, there was Rosetta, which enabled legacy Mac OS X apps only compiled for PowerPC to run (but Classic/68K support was dropped).

NextStep – from which Mac OS X was derived, was written originally for the 680×0 processor architecture, but was also ported to the SPARC, PA-RISC, and most importantly, Intel x86 architecture before Apple acquired it.

So why did I throw Apple into a discussion about Windows? Because I found a few things fascinating as I pondered these two separate courses of events the other day:

1. Apple has made at least 4 “burn the ships” architecture shifts. Microsoft has never burned the x86 ship. In fact, x86/x64 have burned every other potential Windows NT ship that came along, by offering rapidly evolving, “low”-cost systems, with extremely high application compatibility – unmodified.
2. Apple – though maligned for hosing customers, actually provided better application compatibility with each of these platform shifts. The counterpoint is that they needed to, since they burned the old platform.
3. Apple was able to achieve architectural escape velocity by burning the previous architecture, yet supporting it as a cantilever in the new system.

Windows customers never bought systems in other architectures other than x86/x64. This was likely, depending on the architecture, due to:

1. High cost of alternative processor systems vis-à-vis their performance (Itanium and Alpha being great examples here)
2. Lack of 16-bit Windows or 32-bit Win32 application compatibility
3. Lack of native applications.

iOS is the unusual exception here. Born on a device with no application platform (the original iPhone), there was no possible way to (or value to) carry legacy Mac applications over to the iPhone, even once it had an application platform. However, what we can see is Apple playing the same compatibility card when the original iPad shipped. Though they looked atrocious, the iPad could run iPhone apps at native or 2x resolution. In a sense, a nod towards the old model of using the old/established platform to cantilever the new one.

When we look then at Windows RT and Windows 8, they provide an unusual set of design choices. Windows 8 will, again, not burn the x86-x64 ship. In fact, I think that the threat of Windows on ARM processors taking hold due to Windows RT may have Intel showing us some amazingly low-powered x86/x64 tablets later this year that could really limit how broadly Windows RT takes hold, but may mean much broader adoption of Windows 8 tablets that can run legacy Win32 applications as needed. Given that Windows RT won’t support legacy Win32 applications other than the OS fundamentals (Explorer, etc) and the Office applications that are included in it by default (Word, Excel, PowerPoint, and OneNote – note, no Outlook), Windows RT is still seemingly positioned as a “companion” device to a Windows 8 PC. The only cross-platform API set is then WinRT, an entirely new API set built into Windows 8/Windows RT, which enables the creation of cross-platform apps – but won’t run on older versions of Windows – but it is the sole “bridge” that binds these two platforms together.

If Windows RT succeeds, it will be due to the merits of the platform, the cost/power/weight/form factor of the devices, and the successful build-out of the Windows App Store. I don’t believe that Windows RT is intended to supplant Windows 8 on x86/x64. It is intended to complement it.

In 1998, while on vacation, I recall having an idea about a new kind of computer. A computer where you could  use it as a laptop, or flip the display around and use it with your fingers. I let the idea pass, since I figured it was novel, but nobody would pay a premium price for such a device.

Several years later, I recall when Windows Tablet PC was in it’s infancy, seeing a convertible Tablet PC, and thinking, “maybe it wasn’t so stupid”.

If you look deeply into the soul of Microsoft, there are two things that have driven them like an obsession of some sort for decades. The first was IPTV – broadcast television over IP networks. Through tons of research, investment, and inventions, the end result is primarily Mediaroom – the technology behind AT&T U-verse and similar offerings. The second such obsession was pen-based computing. For more than 20 years, Microsoft has pursued a vision of pen-based computing – perhaps to a fault.

Windows for Pen Computing (German Google translation) released in 1991, 11 years before Microsoft’s next big surge in pen computing, Windows XP Tablet PC Edition (2002). Microsoft significantly enhanced how the OS itself interoperated with the pen, but in both operating systems, the pen became an adjunct to the computer. It still felt tacked on.

I worked on Windows during and after Windows XP – and was on the setup team when the Tablet PC (and Media Center) code was being chemically bonded into the OS using a second CD approach. I recall from the very get go thinking that if Tablet PC was real, maybe I should switch my main computer to be one. When I had the chance, I ordered a new Motion Computing M1200. This was, as very few were, a slate-style Tablet PC. In general, Tablet PCs came in two forms. Convertible devices which compromised weight and dedication to being a tablet with being a standard laptop or a tablet, or slate-style devices, which limited their utility by not having a dedicated keyboard – much like the iPad and Android tablets now do.

I originally ordered my Motion without a keyboard – just the device with it’s built in stylus. Within weeks I realized I needed a keyboard, and Motion Computing had a relatively complex fabric case that flipped and unfurled to allow their keyboard (USB) to sit below the device while it was propped at an angle. It was, in some senses, an ungainly early version of the Apple Smart Cover. Only when I used this device, people laughed, since it was so ungainly and since I was needing to attach a keyboard to a device designed primarily to not need one.

I have not tried more recent vintages of Tablet PC since 2005. I believe it has improved dramatically in how it recognizes handwriting – or at a minimum, how it captures it and lets you search it later, even if not recognized and converted to text. But I’m a firm believer that for most of us – unless you’re a horrible typist – you’re better off with a keyboard and a tablet than you are with a pen and a tablet. Tablet PC was, in the end, good for two roles. It was useful for point of service (where Motion Computing focuses today) where simple handwriting input either made sense or was a requirement, and it was useful for some people who needed to take prolific notes but do so faster with a pen than they could with a keyboard.

I’ve known for most of my life that I have awful handwriting. I’ll admit it. It’s horrible. But I think that was only part of the problem.

The two fundamental problems with Tablet PC were – and this was painfully clear when I ordered my M1200 and when I used it later – the devices were obscenely overpriced compared to laptops at the time, and they still required a keyboard. While they tried to be tablet PCs and laptops, they weren’t terribly good at either. They came with smaller screens than most laptops at the time (the Motion, with a 12.1″ screen was one of the larger Tablet PCs of the era), and when it came time to use them as a tablet, the only thing you really got for it was handwriting input where you could use it (OneNote and a handful of other apps tuned for Tablet PC, plus a few games), and a glorified hand-held mouse where you couldn’t.

Unlike iOS, and now Metro-style apps in Windows 8, where touch is intrinsic – and in fact the OS is even seemingly detuned for the mouse, when you got a Tablet PC, you were in this weird middle ground where it was still Windows, and very few apps took advantage of the fact that you had a pen, yet you didn’t always have a keyboard, and usually had a small screen – compromising what Windows could actually do for you.

I wound up hardly ever using the pen on my Motion. When I moved groups not long before I left Microsoft, my Motion stayed behind for clerical reasons – and I got a new ThinkPad that I found much more usable. With a few exceptions here and there until I got my iPad, I’ve hardly ever missed having a Tablet PC. The apps still haven’t arrived for Windows pen computing.

I think Steve Jobs was wrong – there isn’t anything intrinsically wrong with a stylus. I have one for my iPad. For some detail work as you’re drawing, it’s invaluable. I wish that the iPad had a decent stylus option with wrist detection – something Windows can handle today. But for me, handwriting as a primary input is a novelty – a parlor trick. There is a certain romance to handwritten text, and perhaps some writers still work best when putting pen to paper (or stylus to tablet). But for me, with the technology available, it’s illogical to write in a format that doesn’t seamlessly convert to text reliably and rapidly, when I can type with a faster velocity, and iterate on it from there. I don’t think the stylus is dead – but I also don’t think that most consumers will ever switch from typing to handwriting. We’ve left the era when handwriting will be a primary input. The keyboard – it’s oddball QWERTY layout and everything, lends itself to easy, high-velocity text input that is reusable, recognizable, and universal. Even as we move to a world that grows to accept touch and broad gesture manipulation, I don’t see the keyboard (physical or virtual) going away to have pen come back to prominence. Handwriting as an input for digital media is to me similar to the ink and quill of centuries ago, or even the annoyance of standardized testing that required a #2 pencil on a standardized form. More work than it is worth. Maybe the stylus will rise again. For now, I’m just not seeing it happen.

On Friday Morning, Splashtop introduced a new application, the Win8 Metro Testbed – powered by Splashtop. With both of the releases of Windows 8 so far, a key criticism of mine has been how hard it is to fairly evaluate the OS without a device that supports touch properly. Where Windows 7 is a desktop OS that offers little value when used with touch, Windows 8 is so touch-centric that evaluating it with only a keyboard and mouse is, I believe, worse than not evaluating it all. It’s simply hard to sound like you don’t dislike it. Yet I refuse to invest in buying touch-specific hardware today to run Windows 8 because it was all designed to run Windows 7, and brings with it far too many compromises (cost/weight/heat/performance) just to fairly evaluate Windows 8 with touch.

Splashtop offers an interesting, if slightly pricey option to use Windows 8 with touch ($24.99US for a limited time, regular price cited as $50US).

At first when the news hit, I thought that this was similar to the highly contentious OnLive Desktop iOS app, which uses a remote-desktop-style connection to a hosted server. But I was mistaken – Splashtop relies on your own copy of Windows 8 Consumer Preview, running on your own PC (or VM, as I did in my testing). I was not previously familiar with Splashtop, as I use an iOS RDP app to connect to my Windows systems through their native Windows Remote Desktop support. Splashtop appears to use it’s own protocol and server on the client-side for their connectivity.

Disclaimer: Splashtop reached out to Directions on Microsoft on Friday, and was kind enough to offer us a promotional code for the app in order to evaluate it, which I did take them up on. While I was strongly considering buying the app anyway, I did take them up on it since they offered. While it is otherwise “expensive” to purchase (see disclaimer), I know of no other remote desktop iOS app that lets you try Windows 8, in almost all of it’s multitouch, gesture-driven glory, from an iPad.

While I still have concerns about Windows 8′s viability on the desktop, Splashtop enabled me to finally give Windows 8 a fair test drive just using touch. You can try almost all of Windows 8, on an iPad. Gestures (including multitouch, which I tried from within the Pictures app), Charms Bar, App Bar… it all worked quite well. I did have some problems early on with the connection being slow, but it was because I was using the Internet connection initialization method, not a direct connection. Putting it on the same wireless network resulted in a pretty reliable experience, with nominal lag. Since I was running in a VM with GPU acceleration, not a physical machine, it was possible some lag was due to the VM being constrained. But given that the machine itself was responding first, it seemed to be more a condition of the connection.

Overall, if you have an iPad, and want to try giving Windows 8 a fair shake – whether you’re a developer, IT Pro, pundit, etc – I’d have to say that this app does exactly what it says. And given that it means you don’t have to buy “circa Windows 7″ touch hardware only to need to upgrade to hardware truly designed for Windows 8, that’s not bad either – an extra $1000 or so you don’t have to burn while you wait for Windows 8 and Windows 8/WOA systems.

A few recommendations to achieve the best performance with Splashtop Win8 Metro Testbed are below. All of these are recommendations to follow, if possible. I’ve put them in order of importance as I discovered.

1. Keep everything to a local network. No Internet, no NAT. Though Splashtop offers convenient “get back to your PC over the Internet” functionality using a Google account, not using a local connection will result in poor performance, and really make the whole experience not worthwhile.
2. Use a physical system, not a virtual machine, to host your copy of the Consumer Preview. I used VMware Workstation 8 for my tests, and I’m not sure it resulted in the fairest trial (and it did end up resulting in some issues that are, I believe, specific to running in a windowed VM).
3. Use a system with an NVIDIA GPU, for the absolute performance.

A few caveats to using Splashtop are below. As with the recommendations, I’ve put them in my own relative opinion of importance.

1. It doesn’t appear to support portrait, or rotation, at all. As I noted last year, it seems relatively apparent that landscape is the preferred display mode for Windows 8, and all others are… less important. You can see in the gallery below what happens  when you either rotate an iPad in landscape to portrait mode, or if you connect in portrait mode.
2. It’s “expensive”. Like it or not, $25 is a lot for an App on the iOS App Store. Yet, it’s less than many of us would have paid for PCAnywhere/Timbuktu Pro style apps back in the 1990′s. So keep the whining relative. I do think the $50 price they’re expecting to charge is a little too high, personally. That said, using it at any price point might enable people with a decent Windows machine and an iPad to develop apps for Windows 8 today that work properly, without having to invest in throwaway Windows 7 touch-based hardware. Paying $50 to not pay $1000+? Not bad.
3. It’s not the same as being there. There is some lag, no matter how good your network connection is. If you’re building an app that depends on incredibly accurate touch timing? Buy a dedicated tablet now, or wait to develop your app until Windows 8 ships and hardware optimized for it appears.
4. Requires their connection agent to be running. Splashtop uses it’s own agent and protocol. I’m rather hardcore about what I usually run on my Windows boxes, and prefer to use RDP instead of third-party services and protocols. But you can’t do what Splashtop has done if you just use RDP.

I don’t have a Ph.D. in ergonomics. I didn’t even stay at a Holiday Inn Express last night. But still, I have to say, I have to disagree with Jakob Nielsen in his blog post. Jakob states that if you build a mobile site (and he recommends that you do), that you redirect users to it automatically.

This is not that different from the incredibly annoying tendency of sites to offer you their mobile app with the persistence that the talking toaster from Red Dwarf offers you toasted bread products.

Stop. Please. Take a step back, my Web developing, app developing friends. It’s time to educate the executive suite on use cases, before they shove “WE NEED A MOBILE SITE!” or “WE NEED AN APP!” down your throat.

Too many sites today are focusing on building “mobile” versions of themselves, when a large, and growing, percentage of the population is using smartphones that, even with small displays, have incredibly full-featured Web browsers that can render most sites normally, and feature pinch to zoom functionality in the event of site elements being too small to easily “click” on with a fingertip.

Let me explain a bit. There are at least two distinct types of Websites in this world. Probably more, but at least two key categories. Those sites are:

1. Content-based Web sites. Examples include Slate, Salon, Fox News, New York Times, News.com. These are sites you go to to read content. To browse. Think of a library where you’re just wandering the shelves, and perhaps consulting the index.
2. Task-based Web sites. Examples include your bank, Expedia, the Delta or Amtrak Web site, or Urbanspoon. These are sites you go to in order to accomplish a task. Think of the DMV. You’re there to renew your plates or driver’s license, or get new plates or a new driver’s license.

If you’re building a content-based Web site, and you’re not filling it with advertising, or so many link targets that it’s unusable with a full PC or Mac, and you haven’t used obscenely tiny text, then honestly, it’s going to render pretty well on an iPhone, and likely incredibly well on an iPad. It is my belief that if you have a content-based Web site and you build a mobile version of it for your users, you’re doing most of them a disservice. If you shove everyone to the mobile site, you’re doing all of them a disservice. If you do that to an iPad user, you’re just making yourself look incompetent.

The Web browsers on the three predominant smartphone platforms are all pretty capable. The browser on the iPad even more so. As long as you’ve taken the lack of Flash into account and provided h.264 video instead, there’s really not much work you need to do. If you build an entirely new site for mobile users, I believe you’re wasting your time, versus simply driving a concerted effort to make your site more usable and more consumable (and building in a good content search/improving your SEO).

If you’re building a task-based Web site, there is perhaps some logic to building a mobile app, but if (BIG IF) and only if you understand every, single course of action a mobile user might want to make. This is critical. If you’re an airline, and you miss a single “verb” that a user might want to take advantage of, you’ll make their life more painful than if – as above – you had simply focused on site usability, navigation, and SEO. Make your seat change page the first result that a user hits when they search for “Delta change seats”  (which isn’t the case, as best as I can tell).

For task-based Web sites, hitting every potential target is critical. Your user may well be mobile, but more often than not, whether they’re mobile or not, they want to get something, a task, done. I’ve explained this concept of simplified design before.

More importantly than all the above, let me offer you 10 “to-do’s” that I believe to be important when considering your Web site, any “mobile ‘optimized’” versions thereof, as well as an app, should an app actually make sense.

1. Think of how you treat your users when they navigate to your Web site, regardless of site type. Do you take them to the content they wanted to go to? Or do you insist on asking them questions? Do you like it when Windows or your Mac (or a crappy app therein) asks you petulant questions, or keeps you from simply accomplishing the basic task you want to accomplish? No. You don’t. Why do you do that to your users?
2. If the referrer to your site is Google, Bing, or any other search engine, DO NOT ask the user about a mobile site. DO NOT ask the user about your app. DO take them to the page they clicked on, unless you want to learn what “bounce rate” means. Interstitial dialogs as the welcome to your site on search results are user hostile, insulting, and they make you look stupid.
3. Focus on your site usability first, whether your site is content-based or task-based. Simplify your normal site, and make video mobile-viewable.
4. Focus on your SEO next – when a user looks to accomplish a task with your brand, what’s the first result they get on Google or Bing? If it’s an FAQ page or help document, that’s not really very helpful. Take them to a verb. Take them to where they can accomplish a task – whether they’re on a mobile device or a full PC/Mac.
5. If you conclude that you absolutely must make a mobile version of your Web site, provide an easy to see escape hatch to your full site, allow users to permanently opt out of your mobile site, and when you redirect them, take them to the page they originally wanted to go to, unless you also want to learn what “bounce rate” means. The most passive-aggressive thing you can do to a user is the “Mobile site bounce”, where you decide taking them to your mobile site is more important than taking them to the content they wanted to see, or fail to keep the content reference when redirecting back to the full site as they’ve requested.
6. Focus on your site usability first. Simplify your normal site, make video mobile-viewable.
7. Don’t shove users to the mobile experience on content-based Web sites by default – at least not on modern smartphones, and definitely not on the iPad. Make it an option for smartphones.
8. If you run a Task-based Web site, a mobile version of your site may make sense – but only do so if you clearly understand every single task a user may want to accomplish while in the “mobile” version of your site.
9. If you run a Task-based Web site, a platform-specific app may make sense. But again, don’t do it unless you really understand all of the tasks a user may want to accomplish on your site, and you’re willing to provide them all through your app. Building an app that doesn’t let people accomplish the same things your site can do is, frankly, nonsensical – and you’re going to end up ticking off your users. Why do that?
10. If you run a content-based Web site, or you have a discussion forum, for all that is good in the world, please do not insist on always offering up your mobile app. It’s great you paid a developer too much to build it for you. But listen – if a user is on their iPad or smartphone, in Twitter, and you offer them your app instead of the content – it’s beyond useless. Ask once if you must, but don’t ask again. And really – you shouldn’t ask to begin with. Users don’t install apps for every single site they visit. If they did, they’d run out of space on their smartphone, and it would be an incredibly unusable model.

Remember – a poorly engineered “mobile” Web site is no better than not having a Web site at all, and a poorly engineered app is no better than not having any app at all.

As I said in my simplify post: “It’s better to do one thing really well instead of two things half-assed.” Consider your “mobile” site and your app that second thing. If you don’t know exactly what you’re doing, and you’re unwilling to take into account every single user scenario, please keep your finger off the trigger, and just focus on making your normal, good old-fashioned Web site itself simplified, usable, and SEO optimized.

Update: Several readers have pointed out the use of the word “responsive” as a design goal that developers should work towards. Indeed, as I recall working at two previous startups, our biggest pain point – the thing that made us look bad – was that we were the last thing to load on a page (an add-on JS script), and all too many content sites are not optimized for fast download of page content, or for optimal rendering. Making your primary Web site responsive, reducing your page weight (and as a result, your page wait), and making sure that your content renders fast in any browser should all be primary design goals for any good Web developer. Oh, and if you have a slow ad engine, you’re causing bounce too. Ad engines are notorious for being slow to load – and they can easily pin the whole page while the user waits for the thing they care least about.

Don’t make a mobile site because your regular site’s performance sucks or your pages are too heavy. Improve your regular site’s performance instead, so every user gets benefit from it.

For most of my career at Microsoft, I worked as a Program Manager on Windows Setup. No, not the Windows installer. Windows Setup – the tools and technologies that took a computer either from an earlier version of Windows or a bare PC, to an installation of Windows. But in this role, I still had to deal with the ramifications of how Windows applications were installed, and often would see the work of other teams incorporated into Windows setup – often teams that you wouldn’t assume would need to be there during setup (and sometimes, you’d be right).

In our weekly Monday meeting at work today, we got to talking about the Windows 8 App Store, and how the rigid rules for Metro Apps in it will mean certain things we’ve all become used to with Windows applications will be no more. For example, application product keys, duct-taped custom product activation/licensing experiences, customizable installs (install feature “a”, but not feature “b”), installation directories, MSI’s, etc – all will be gone.

Personally, I think that’s great.

Through my travels throughout Microsoft - in particular when I went to other teams and talked with them (as well as when I talked with corporations and ISV partners), there were two common traits about how “setup” (the thing that put a team’s binaries down on the system) was built.

1. It was an afterthought – rarely did a team take two steps back and rethink how their application was installed. Why would you? It’s a cost sink that doesn’t show return (unless frustrated users come into your value equation).
2. It was the thing you put on the “new guy” – rarely was setup held in any high esteem.
3. It was the La Brea Tar Pits of any “to-do” items that the app might ever need – hence, the “sanitation engineers” of Windows.

Windows Setup itself was an extreme example. But even if you take Office into account, it’s painful to look back at how complex setup applications are/were. Recently in most applications, I believe there has been a general tendency to minimize the setup screens, minimize the configuration during or just after setup, etc.

During the exercise to overhaul Windows Longhorn setup (I don’t call what I worked on Vista, FWIW), we caught unbelievable grief from within the Windows organization because we were hard-locking the locations for Program Files and the Windows directory This had, for several versions, been configurable – handy if you’re the kind of masochist who wants to install two versions of Windows in the SAME partition. I should see if I still have some of the flame emails I received. Nothing showed me we were doing the right thing quite like cheesed-off geeks. How much time and effort we had put into supporting this, version after version, as a complete edge case. Nerd porn. It had some utility, but really… how many consumers and enterprises (the people who pay for Windows) ever used that?

Windows itself lost the whole “Add/Remove Windows Components” during setup as well when Vista shipped. Again – killing a feature that very few users used, but that added weight to setup, to the setup experience, and to user complexity.

For me, when I see that Windows 8 Metro-style apps won’t include the custom “glue” they’ve had for many years (including the incredibly complex MSI infrastructure), it makes me excited for the future. Fewer moving parts to cut fingers, less duct-tape code that doesn’t really need to be there. Less garbage to worry about.

This is my office phone.

See the red light? Most people who know me know that the best way to reach me is always my cell phone or email (or Twitter). But that red light marks purgatory for those who didn’t know.

You see, office phones and I just don’t get along. I’ve tried, really I have. But these “designed by an electrical engineer” phones have always driven me nuts. Right up there with fax machines and printers, the needlessly complicated “work phone” has always driven me nuts. The user interface makes me feel stupid. It feels like it lowers my IQ every time I try to use one (and I know it’s not just me) – and no two office phones are ever the same!

I saw the red light today, and thought, “I really should make sure there’s nothing important in there”. So I searched the Internet for directions to the device. Almost everything came back as handsets for sale (hmm…), no documentation. I could, admittedly, ask a peer here how to check it, but then I’d feel even more stupid. I mean, I worked on Windows. I’m not an idiot. I even know this is far from being a really complex office phone, but how the heck do you check voicemail? I just want to check voicemail!

I think my iPhone has broken me to use overly complex user interfaces. I use my iPhone, my iPad, and even my Nest thermostat, and appreciate the elegance and simplicity of what they do – but more importantly, what they don’t do. With this phone, it’s impossible to figure out how to use the “Feature” button or check voicemail without an instruction manual. It’s completely unclear what “HFAI” is (High Fructose Amplification Input? High Fidelity Analog Input?), or if I should be worried that I don’t have an indicator light to tell me if my HFAI is working or plugged in. I have no idea. Voicemail is important enough on this device to include an indicator light. But no one-click access to voicemail through a button labeled, oh, I don’t know… “Voicemail”?

A few weeks ago, I saw a non-technical person using a technical piece of software. They tried something. It didn’t work the way they expected. Their response?

“What did I do?”

Technology that doesn’t work as we expect it to innately makes us feel stupid – like we screwed up. We should try harder, we should just know better.

If you want your end-user to get things done faster and easier, drive your product by understanding their real scenarios – how they’ll use the device. Design it to just work in those scenarios. If you design a device, or a piece of hardware or software to simply bubble up your features to the end user, without anticipating how it will be used over a day, week, month or lifecycle of the device, you’re trivializing the tasks that your end user wants to accomplish – and you’re going to make them feel stupid.

If you’ve read my blog or followed me on Twitter for long, you know that I love to analyze patterns in spam and scams. Over most of 2010 and 2011, spammers (in particular the porn spammers in late 2012) were very prolific. I believe recent controls put in place are helping to regulate the amount of spam on Twitter to a better degree than before.

However, last week, something happened that exposed a weak point in whatever algorithm Twitter is using right now. On March 30, I had three new followers all within a very short period of time. Take a look:

At first glance, they look benign enough. Though all three used names and pictures of women, none of them used gratuitous cleavage (a tactic I’ve mentioned before that spammers often use, but can make them easily smacked down as spam).

But a couple of things still bothered me with all of them. First off, they all had gibberish characters at the tail end of their usernames (arguably, “Lilly” here could be a lawyer). Gibberish characters or common patterns (in this case, first name + 4 characters) are all great warning signs. Second, they all followed me within a matter of a few hours.

Using the tool that I built to check out accounts, I looked their profiles up.

“Armanda”:

“Lilly”:

“Annamarie”:

Now something definitely smelled bad. Created minutes apart, last August, with almost no interactivity in the account? Definite silent spam drones. Often spammers will “age” twitter accounts, so they don’t appear quite as eager as accounts that are created and immediately begin to prolifically spam. These had been created a while ago, laid dormant, and still hardly tweeted at all. Hiding in plain sight.

Looking at their accounts, the few tweets across them all mentioned one of two domains; either usapersonalingurylawyers.com or reminiscingvisions.com, both hosted within the 173.192.0.0 – 173.193.255.255 IP address range owned by hosting provider SoftLayer.

The first URL was simply a blog post talking about personal injury lawyers, and why you should get one. The second was similar, but featured this video:

More intriguingly, I now noticed that at the bottom of each of these pages, the site designer had included a social widget bar, including Facebook (no likes), Twitter (quite a few Tweets), and G+ (no +1′s). Twitter places a lovely hyperlink on theirs, so you can click back to Twitter and see who has tweeted about it.

Sure enough, when I clicked back from the first domain, I saw all of these Twitter accounts that had talked about it (the list went on for quite a while):

Same with the second site:

All following the same approach, all with drone accounts that looked legit if you looked quickly. I decided that someone with this similar MO had to be trying the obvious. I looked up the domain name of the law firm in that video, the Michigan law firm of Schulman and Associates (schulmanandassociates.com), and searched Twitter for that. Same deal:

Every account that had mentioned any one of these three links was a drone. Dozens and dozens of them, all following users, and responding to tweets, based upon the keyword “lawyer”. Simple keyword spamming, but done in such a broad way that the spam doesn’t appear obvious, and might not even get these accounts caught on the first try (normally).

I can’t be certain who did this on behalf of the law firm, but I believe strongly that Twitter should investigate who did this work for the law firm, as well as suspending all of these drone accounts. While I’m not a lawyer, I did speak with one, and he had concerns that depending on how this would be viewed by State Bar of Michigan, this might raise solicitation ethics concerns as well.

In my last blog post, I discussed the different user interface approaches that Apple is currently taking across all of its platforms. Four platforms, four slightly different answers.

There is, I believe, a rational explanation for each of them – and most importantly, a rational reason for all four to at this point at least, not have a completely identical experience.

In a recent meeting at work, we discussed Metro and WinRT as they related to an article that a peer was working on. The problem comes up in the use of “Metro” as an adjective used throughout Microsoft to describe many things now – not all of which are equivalent. That is, Windows Phone 7 “features” Metro, as does the Xbox now, Windows 8 soon, and numerous other apps (including Visual Studio 11?!) have been denoted as featuring Metro. Moreover, “Metro-style” has more precisely been used to describe the new style of applications within Windows 8.

A fundamental problem here is overuse, (and potentially abuse) of the term “Metro”. Metro isn’t a thing. It’s not an API. It is, in many ways, a state of being. It is, like Kanban, a design approach to completing a manufacturing task, pioneered by Toyota. Though Metro may have it’s own unique framework on each platform that it runs upon, the core thrust of Metro is always consistent. Clean layout, a focus on typography and how (and when) information is displayed to the end user.

In the past, Microsoft was criticized for not making Tablet PC optimized for pen input. Truth is, Microsoft did redesign components of Windows for pen – but it completely failed to build a software platform for developers to make the most of, never clearly delineated the value for consumers to buy the devices, or for them to push developers to build pen-enabled apps. I’ll talk about all of this in a future post. But the important thing to understand is, as we went over in  my last post, how designing for touch, multi-touch, and mouse/trackpad, are done at Apple – and I think this is critical. The interface for tablets and the interface for desktops, though ever so slowly converging, are still completely different.

My chief criticism about the new desktop and Metro apps as they are currently implemented on Windows 8 is that neither provides enough mouse affordance. Simply put, they were designed for touch/multitouch – not for mouse/trackpad. I’ve said this several times on Twitter, and I’ve usually had more people agree with me than disagree with me, but I’ve had a few naysayers. Let me explain what I mean.

Consider Windows 1.0-Windows 7.0. As the UX evolved, it became incredibly obvious (especially given almost 30 years of mouse-driven GUIs) what elements on the screen were mouse targets. These affordances innately look like things you can push, scroll, click, or grab, or that, like menus, we had learned to accomodate en masse (see the areas in the image below that I’ve highlighted in a lovely shade of teal).

I can’t find the quote at the moment, but I seem to recall a Windows 8 video or soundbite where one of the Microsoft execs giving a demo said something to the effect that Windows 8 featured a user interface that you simply “want to touch”. On a tablet, and on Windows Phone (7 or  8 when we get there), this is fine and obvious – because intrinsically everyone with one of those devices has touch support built-in. Almost all of the glowing reviews I’ve seen for Windows 8 appeared to be from reviewers who were using tablets – but most of my peers who have, as I have, tried it on a desktop without touch (since it is what most of us have), it didn’t have that same great feeling that those glowing reviewers shared.

Simply put, things become fuzzier when using Windows 8 on a desktop system without touch. Likely you’ve seen it, and perhaps it’s not a fair thing to discuss in some people’s eyes, but the video Chris Pirillo took of his dad trying to use Windows 8 with a mouse, I believe, drives my point home painfully well. The removal of the Start “orb” is a great example of a mouse affordance that has been eliminated. As a result, when touch is not available, it is not apparent how to even go “back” to the Start Page (you’ve removed the one old affordance to even get to the entirely new launch experience). While flicking about with your finger on a touch device will eventually land you back at the Start Page, using a mouse requires far more exploration, and the removal of the key user interface element that users expect in order to even launch apps.

Similarly, when in the Start Page, the user interface does encourage you to touch it – which, again, is fine if you can. But on the typical desktop – any machine upgraded from Windows 7 – the likelihood of touch support being present is incredibly low. As a result of the Metro design of the Start Page, it is apparent that not all of your apps are visible on the screen, but it is not apparent how to scroll over to see them – until you notice the scroll bar on the bottom of the screen. I personally believe that when on the Start Page, mouse movement left or right towards the edges of the screen should induce scrolling that direction – but it does not – at least it does not on any machines I’ve tested. The Charms bar is incredibly hard to coax out of hiding with a mouse, since the mouse targets are so small. I believe that simply bumping the right side of the screen with the mouse should present the Charms bar.

Where we see Apple taking the already minimalist phone experience and upsizing it to work on the tablet, and gently introduce new metaphors and gestures to Mac OS X, Microsoft has left Phone alone (for now, though it may well become a sub-category of Windows 8), but has completely redesigned Windows, and the core user interface elements of it, to be touch-first, and full-screen. In effect, they have redesigned almost the entire OS to suit tablets, and then foisted that same model – almost unmodified, onto the desktop.

Personally, while I’d like it to work, the experience just doesn’t work smoothly for me. Users should not have to learn significant keyboard shortcuts to use Windows 8 on a “touchless” desktop. They won’t. Asking a user to memorize a litany of keyboard shortcuts is not that different from asking a user new to Windows 3.1 to use the GUI with only the keyboard, and not a mouse. Doable, but an exercise in frustration that doesn’t end up with user joy.

Moreover, I believe (and I’m at odds with many here, too) that primary touch for a desktop system doesn’t make a ton of sense. If we’re talking occasional use for some games, or for photo manipulation, perhaps. But to have a knowledge worker’s arm reaching out to a screen all day for most user interactions? It makes my arm muscles hurt just thinking about it.

As I told a peer, the goal of any input device should be making you all but forget that you are using it. This was the case for most of us with the mouse, but is not in Windows 8 for mouse-bound users.

It’s not that dissimilar to the Metro design elements as the Xbox currently uses them (for navigation). When using the controller to navigate the Xbox, it is similar to the Apple TV. When using the Kinect, you can also use the same back/forward, with a “palm up, and hold” motion (which can take a bit of patience). While this may have some viability in the living room, it doesn’t work well at the moment when a user is seated. So the premise of using one’s Kinect to navigate to Hulu Plus or Netflix is foiled by the need to, realistically, stand up and use the Kinect just to navigate menus. While this may change in the future, I contend that the idea of “large gestures” as I call them, where your arms are representing movements that your fingers or a mouse would traditionally do, aren’t perfect – but are useful. However, you still will wind up sometimes using a secondary gesture (like the existing Xbox controller to navigate) or the Windows Phone 7 Xbox Companion for games and apps that aren’t voice or Kinect enabled. Voice is indeed a potential option for some command and control tasks – we’ll come back to voice in that future post I promised – not now. I think in many ways Metro does work on the Xbox, but I’m not as certain that Kinect is the vehicle to drive it across the board – you still have to think about it – give it consideration as you are performing tasks. The gestures can feel “heavy” to perform, since you have to get the UI ready to accept the gesture, then perform the gesture, and wait for it to be accepted. Kinect isn’t yet ready to be a primary input device – but given time and enhancements (Kinect 1.5 for Windows is on it’s way soon!) it could be. Time will tell.

Personally, I don’t think Metro on Windows 8 touch-based devices – tablets – is a bad idea at all. If your head isn’t wrapped around the way iOS works in the way my head is, I think it could work even better than iOS. On tablets, and even sub-sized down to Windows Phone 7/8, the design approach works quite well in a sort of “well duh!” manner. But on the desktop, or mouse/trackpad only devices? I’m not so certain that Metro as it exists is situated for success.

That said, if Windows 8 were my idea, what would I do differently?

1. Detect the presence or non-presence of touch support at setup time.
2. If touch is present, use the existing experience that focuses more on the Metro/WinRT realm, and less on the desktop.
3. If touch is not present, use an approach which melds old and new – legacy Start Menu, but Metro apps running on the desktop in a manner not that different from the  way a full-screen HTML Application (HTA) would have on earlier versions of Windows.