Steve Ballmer, CEO of Microsoft, announced that he would step down in the next twelve months. Folks have been quick to respond, some cheering and some asking the question: Was he pushed?
The almost-unanimous view of Ballmer's stewardship has been one of dismay if not outright failure. People cite Microsoft's delay into the tablet market, the poor reception of Windows 8, and other products such as the Kin and Zune. (With an occasional reference to "Microsoft Bob".)
I say "almost-unanimous" because I dissent from this view. Yes, Microsoft did enter the tablet market later than Apple and Google. Yes, Windows 8 is quite different from previous versions. But Microsoft has bee giving its customers what they want, and in that they are not to be considered a failure.
Microsoft's customers are mostly businesses, and they are a self-centered lot. I have seen several businesses respond to new versions of Windows, and the responses have been uniform: make this new version work like the old version.
Businesses, for the most part, do not want a new version of Windows. Businesses want to go about their business and not worry about computers or GUIs or databases. Many businesses today run Windows XP, seeing no need to move to later versions.
The complaints about Microsoft seem inconsistent. People criticize Microsoft for delivering the systems that they want, while also complain that Microsoft delivers nothing new. And now that Microsoft has delivered something new, people complain about that.
I think of Windows RT as a suitable operating system for tablets. I consider the Surface RT tablet a competitor in the iPad and Android tablets. A bit pricey perhaps, yet good technology. I consider the Surface Pro a compromise tablet, a transition from the classic Windows environment to Windows RT.
The lack of apps for the Surface RT is a problem, but only for the consumer market, and I view the Surface RT as a device for the office. In the office, it is not consumer apps that are important but the apps used by the business, many of them in-house apps. Businesses will create their own apps, just as they have created their own documents and spreadsheets.
I look on the Surface as a successful product. I see Windows RT as a valid path forward. I see Windows 8 as an interesting mix of the old and new technologies.
Given these accomplishments, I view Steve Ballmer as a success. He moved Microsoft into new directions and introduced new products. Microsoft's products did not take the world by storm, or establish a new monopoly. But they are worthy contenders.
Saturday, August 24, 2013
Thursday, August 22, 2013
Migrating from desktop to cloud is no small deal
The popularity of smart phones and tablets has made mobile (and its server-side colleague cloud) the new darling technology. They are the new buzzwords that garner attention -- and probably funding. They get attention for new apps, and some folks have been migrating existing desktop and web apps.
If you are embarking on such a project, I encourage you to look into three technologies: mobile devices, cloud computing, and functional programming.
Functional programming is a specific way of designing programs, much like structured programming and object-oriented programming. But in contrast to those techniques, functional programming guides one to smaller units of code. Structured programming and object-oriented programming allow one to build small units, but do not encourage it. As a result, most (non-homework) code built with structured and object-oriented techniques contains collections of large modules and objects.
Cloud computing is a specific way of designing systems out of smaller components, many of which are part of the cloud infrastructure. Cloud-based applications use data stores, message queues, and a measured amount of code. (Previous architectures such as desktop and web often saw applications made of whole cloth with little use of pre-made components.)
Mobile devices force a split of code between the server (typically a cloud-based server) and the user interface on the device. The device usually performs some processing with most occurring on the server. (A few apps perform all processing on the device, such as in the game "Angry Birds". But they are exceptions.) Splitting the code between the device and the server forces you to build not a single application but two programs that communicate.
The new technology set encourages us to build systems of smaller programs. Mobile/cloud is for collaborating programs, not monolithic ones. Functional programming techniques reward small programs and penalize large ones.
This "impedance mismatch" between mobile/cloud and desktop applications (and to a somewhat lesser extent, web applications) means that porting to mobile/cloud is difficult. The legacy systems on the earlier platforms were built to take advantage of the strengths of the platform, and small, collaborating programs were not efficient.
The mismatch between object-oriented systems and functional programming is even greater. Object-oriented programming is often about objects holding state -- mutable state, so that objects change over time -- and functional programming is about immutable objects.
A few well-designed (from the mobile/cloud perspective) applications for the desktop and web can be migrated to mobile/cloud. Most, I think, will be difficult. Some may be close to impossible.
My advice: Build some new apps for mobile/cloud, to gain experience with the new design paradigm. Try out the functional programming languages (or at least, your favorite object-oriented language is with immutable objects). Once you have that experience, evaluate your legacy apps and select a small number (perhaps two) of "easy" apps for migration. I'm sure that the exercise will give you greater insight into the effort for the other (more difficult) legacy apps.
Then, armed with experience of the new technologies and a good understanding of your code base, should you migrate from desktop to mobile/cloud.
If you are embarking on such a project, I encourage you to look into three technologies: mobile devices, cloud computing, and functional programming.
Functional programming is a specific way of designing programs, much like structured programming and object-oriented programming. But in contrast to those techniques, functional programming guides one to smaller units of code. Structured programming and object-oriented programming allow one to build small units, but do not encourage it. As a result, most (non-homework) code built with structured and object-oriented techniques contains collections of large modules and objects.
Cloud computing is a specific way of designing systems out of smaller components, many of which are part of the cloud infrastructure. Cloud-based applications use data stores, message queues, and a measured amount of code. (Previous architectures such as desktop and web often saw applications made of whole cloth with little use of pre-made components.)
Mobile devices force a split of code between the server (typically a cloud-based server) and the user interface on the device. The device usually performs some processing with most occurring on the server. (A few apps perform all processing on the device, such as in the game "Angry Birds". But they are exceptions.) Splitting the code between the device and the server forces you to build not a single application but two programs that communicate.
The new technology set encourages us to build systems of smaller programs. Mobile/cloud is for collaborating programs, not monolithic ones. Functional programming techniques reward small programs and penalize large ones.
This "impedance mismatch" between mobile/cloud and desktop applications (and to a somewhat lesser extent, web applications) means that porting to mobile/cloud is difficult. The legacy systems on the earlier platforms were built to take advantage of the strengths of the platform, and small, collaborating programs were not efficient.
The mismatch between object-oriented systems and functional programming is even greater. Object-oriented programming is often about objects holding state -- mutable state, so that objects change over time -- and functional programming is about immutable objects.
A few well-designed (from the mobile/cloud perspective) applications for the desktop and web can be migrated to mobile/cloud. Most, I think, will be difficult. Some may be close to impossible.
My advice: Build some new apps for mobile/cloud, to gain experience with the new design paradigm. Try out the functional programming languages (or at least, your favorite object-oriented language is with immutable objects). Once you have that experience, evaluate your legacy apps and select a small number (perhaps two) of "easy" apps for migration. I'm sure that the exercise will give you greater insight into the effort for the other (more difficult) legacy apps.
Then, armed with experience of the new technologies and a good understanding of your code base, should you migrate from desktop to mobile/cloud.
Sunday, August 18, 2013
The revulsion of old equipment
As a newbie programmer back in the dawn of the PC era, I joined other PC programmers in a general disdain of the IBM mainframes. We were young and arrogant. We were a elitist in our view of hardware: we considered the PC sleek and modern, the mainframe to be antiquated. Most of all, we looked on mainframe hardware as monstrous. Everything about mainframes was a grotesque, oversized ancestor of PC hardware, from the display terminals (the IBM 3270 was a behemoth) to the processor units (refrigerators) to even the cables that connected devices. Yes they worked, and yes people used them but I could not imagine anyone wanting to use such equipment.
We were also elitist in our view of software, but that is not important for this post.
Much of the IBM mainframe was designed in the System/360, the first general-purpose computer from IBM. It was introduced in 1964, seventeen years prior to the IBM PC in 1981. In that time, advances in technology shrank most devices, from processors to disk drives. The IBM PC was very different from the IBM System/360.
Yet the span from that first PC to today is almost twice the seventeen year span from System/360 to PC. Advances in technology have again shrank most devices.
Today's newbie programmers (young and possibly arrogant) must look on the aged PC design with the same revulsion that I felt for mainframe computers.
PC enthusiasts will point out that the PC has not remained static in the past thirty-plus years. Processors are more powerful, memory is significantly larger, disk drives have more capacity while becoming smaller, and the old serial and parallel connectors have been replaced with USB.
All of these are true, but one must still admit that, compared to tablets and smart phones, PCs are large, hulking monstrosities. And while they work and people use them, does anyone really want to?
The PC revolution happened because of four factors: PCs were cheap, PCs were easier to use than mainframes, the "establishment" of mainframe programmers and operators set up a bureaucracy to throttle requests from users, and PCs got the job done (for lots of little tasks).
Since that revolution, the "establishment" bureaucracy has absorbed PCs into the fold.
The tablet revolution sees tablets and smart phones that are: cheap, easier to use that PCs, outside of the establishment bureaucracy, and capable of getting the job done (for lots of little tasks).
Tablets are here to stay. The younger generation will see to that. Businesses will adopt them, just as they adopted PCs. In time, the establishment bureaucracy may absorb them.
PCs will stick around, too, just as mainframes did. They won't be the center of attention, though.
We were also elitist in our view of software, but that is not important for this post.
Much of the IBM mainframe was designed in the System/360, the first general-purpose computer from IBM. It was introduced in 1964, seventeen years prior to the IBM PC in 1981. In that time, advances in technology shrank most devices, from processors to disk drives. The IBM PC was very different from the IBM System/360.
Yet the span from that first PC to today is almost twice the seventeen year span from System/360 to PC. Advances in technology have again shrank most devices.
Today's newbie programmers (young and possibly arrogant) must look on the aged PC design with the same revulsion that I felt for mainframe computers.
PC enthusiasts will point out that the PC has not remained static in the past thirty-plus years. Processors are more powerful, memory is significantly larger, disk drives have more capacity while becoming smaller, and the old serial and parallel connectors have been replaced with USB.
All of these are true, but one must still admit that, compared to tablets and smart phones, PCs are large, hulking monstrosities. And while they work and people use them, does anyone really want to?
The PC revolution happened because of four factors: PCs were cheap, PCs were easier to use than mainframes, the "establishment" of mainframe programmers and operators set up a bureaucracy to throttle requests from users, and PCs got the job done (for lots of little tasks).
Since that revolution, the "establishment" bureaucracy has absorbed PCs into the fold.
The tablet revolution sees tablets and smart phones that are: cheap, easier to use that PCs, outside of the establishment bureaucracy, and capable of getting the job done (for lots of little tasks).
Tablets are here to stay. The younger generation will see to that. Businesses will adopt them, just as they adopted PCs. In time, the establishment bureaucracy may absorb them.
PCs will stick around, too, just as mainframes did. They won't be the center of attention, though.
Labels:
IBM PC,
IBM System/360,
new technology,
tablet computing
Tuesday, August 13, 2013
Leaping to mobile may be better than fixing a web site
When looking at the changes needed to make a web site suitable for mobile devices, it may be better to write native apps.
ADP, the large payroll processor, has a web site. It was designed several years ago, and is a bit dated. Not as old as a 1990's style web page with blink tags, but not as modern as it could be. It uses a plug-in to display data enclosed in a PDF. (I find that a bit odd, given that HTML is all about markup and presentation -- but that's not important right now.) The important bit: that plug-in fails on some configurations.
The web site works on my laptop (IE on Windows 7) and on my Apple MacBook (an old version of Safari on an equally old version of MacOS). The web site fails on Chrome on Ubuntu, but works on FireFox on Ubuntu.
The web site works in Windows 8, when I load it in the "classic desktop" version of IE. It fails when I load it in the "Metro" version of IE.
These failures are due to the plug-in (or lack thereof). Chrome under Ubuntu cannot find the plug-in to handle a PDF file. (Despite my various attempts.)
Now, I realize that the market share for Chrome on Ubuntu is quite small. I'm not seriously thinking that ADP would modify a web site to handle that small slice of the market.
But what about Windows 8?
The "Metro" version of IE does not support plug-ins -- of any kind. This web site will never work on the "Metro" side of Windows 8. (Or, I suspect, any future version of Windows.) While it does work on the "classic desktop" side (Windows 8 has two versions of IE, one for "Metro" and the other for "classic") it does not work on Windows RT. (And Windows RT has only the "Metro" version of IE.)
One would think that ADP would update their web site to handle this problem.
Or maybe not.
They have a mobile app. Two, actually: one for iOS and one for Android. (I suspect that ADP is developing a third for Windows RT.)
Native apps solve the problem of plug-ins. They solve other configuration issues. And they solve the problem of compatibility with old browsers.
Perhaps this is the right approach. If it is, then ADP will probably leave their web site in its current ("broken" as I see it) state. Is that a problem? Well, maybe, for a small number of users. (A Windows RT version of the app will solve the Windows 8 problems.)
I think we may see a shift from web development to mobile development. Web sites won't go away, but they won't be the premiere interface either. They will be a legacy interface, with mobile taking the lead.
ADP, the large payroll processor, has a web site. It was designed several years ago, and is a bit dated. Not as old as a 1990's style web page with blink tags, but not as modern as it could be. It uses a plug-in to display data enclosed in a PDF. (I find that a bit odd, given that HTML is all about markup and presentation -- but that's not important right now.) The important bit: that plug-in fails on some configurations.
The web site works on my laptop (IE on Windows 7) and on my Apple MacBook (an old version of Safari on an equally old version of MacOS). The web site fails on Chrome on Ubuntu, but works on FireFox on Ubuntu.
The web site works in Windows 8, when I load it in the "classic desktop" version of IE. It fails when I load it in the "Metro" version of IE.
These failures are due to the plug-in (or lack thereof). Chrome under Ubuntu cannot find the plug-in to handle a PDF file. (Despite my various attempts.)
Now, I realize that the market share for Chrome on Ubuntu is quite small. I'm not seriously thinking that ADP would modify a web site to handle that small slice of the market.
But what about Windows 8?
The "Metro" version of IE does not support plug-ins -- of any kind. This web site will never work on the "Metro" side of Windows 8. (Or, I suspect, any future version of Windows.) While it does work on the "classic desktop" side (Windows 8 has two versions of IE, one for "Metro" and the other for "classic") it does not work on Windows RT. (And Windows RT has only the "Metro" version of IE.)
One would think that ADP would update their web site to handle this problem.
Or maybe not.
They have a mobile app. Two, actually: one for iOS and one for Android. (I suspect that ADP is developing a third for Windows RT.)
Native apps solve the problem of plug-ins. They solve other configuration issues. And they solve the problem of compatibility with old browsers.
Perhaps this is the right approach. If it is, then ADP will probably leave their web site in its current ("broken" as I see it) state. Is that a problem? Well, maybe, for a small number of users. (A Windows RT version of the app will solve the Windows 8 problems.)
I think we may see a shift from web development to mobile development. Web sites won't go away, but they won't be the premiere interface either. They will be a legacy interface, with mobile taking the lead.
Saturday, August 10, 2013
Software can work, really
Facebook and Twitter have shown us that big customer bases are possible. They have also shown us that the software for big customer bases must be reliable, predictable, and without defects.
A long time ago, I worked on a project for a large company that provided software to customers. That software let the customers do business with the company, and let the company get clean data about transactions. The software was, in effect, a large data entry system (complete with verification).
The software ran on PC-DOS and MS-DOS. We issued updates on floppy disks (and performed some gymnastics to keep the updates to one disk). We had a help desk to provide around-the clock support to customers. Our software was complicated (partly because the business rules were complicated) and not always easy to use. A help desk was necessary, to keep users happy (and using the software).
We provided this software to 5000 customers, and we thought it was a large customer base. (And it was, compared to a lot of other companies at the time.)
One day, our project manager announced a new goal for our customer base: 50,000 customers. We, the development team, were stunned. But despite our amazement, we did expand the customer base. Such an expansion required a number of changes: we delivered updates electronically, not on floppy disk. We added remote diagnostics to the software. We automated our tests. But some things remained unchanged: the business rules remained complicated, the software remained complicated, and the help desk remained in operation. We expanded it to handle the increased number of calls from the larger user base.
That help desk was expensive.
Compared to today's big social media businesses, a customer base of 50,000 is tiny. Facebook is growing towards 1 billion customers. Twitter and LinkedIn have user bases in the multi-hundred-thousand range.
And they do *not* have help desks.
With a user base of one billion, a failure rate of one percent would result in ten million calls. Staffing a help desk to answer and resolve that many calls (even spread over a few days) is not expensive; it is horribly expensive.
In the mobile world, users must be able to use the software without assistance. But going without a help desk has a price: The software must "just work". If the software fails (for any reason, including server outages), customers abandon it and don't come back.
This is what big user-base operations have taught us: That software can "just work". Facebook, Twitter, and other companies with large numbers of users have successfully designed, built, and deployed software that is reliable and simple enough to use without a help desk (or help pages). Part of their success is due to simple business rules. But part of their success is that their software works as it should; they have developed software with high quality.
A long time ago, I worked on a project for a large company that provided software to customers. That software let the customers do business with the company, and let the company get clean data about transactions. The software was, in effect, a large data entry system (complete with verification).
The software ran on PC-DOS and MS-DOS. We issued updates on floppy disks (and performed some gymnastics to keep the updates to one disk). We had a help desk to provide around-the clock support to customers. Our software was complicated (partly because the business rules were complicated) and not always easy to use. A help desk was necessary, to keep users happy (and using the software).
We provided this software to 5000 customers, and we thought it was a large customer base. (And it was, compared to a lot of other companies at the time.)
One day, our project manager announced a new goal for our customer base: 50,000 customers. We, the development team, were stunned. But despite our amazement, we did expand the customer base. Such an expansion required a number of changes: we delivered updates electronically, not on floppy disk. We added remote diagnostics to the software. We automated our tests. But some things remained unchanged: the business rules remained complicated, the software remained complicated, and the help desk remained in operation. We expanded it to handle the increased number of calls from the larger user base.
That help desk was expensive.
Compared to today's big social media businesses, a customer base of 50,000 is tiny. Facebook is growing towards 1 billion customers. Twitter and LinkedIn have user bases in the multi-hundred-thousand range.
And they do *not* have help desks.
With a user base of one billion, a failure rate of one percent would result in ten million calls. Staffing a help desk to answer and resolve that many calls (even spread over a few days) is not expensive; it is horribly expensive.
In the mobile world, users must be able to use the software without assistance. But going without a help desk has a price: The software must "just work". If the software fails (for any reason, including server outages), customers abandon it and don't come back.
This is what big user-base operations have taught us: That software can "just work". Facebook, Twitter, and other companies with large numbers of users have successfully designed, built, and deployed software that is reliable and simple enough to use without a help desk (or help pages). Part of their success is due to simple business rules. But part of their success is that their software works as it should; they have developed software with high quality.
Labels:
Big User,
help desk,
large customer base,
software quality
Wednesday, August 7, 2013
Microsoft adjusts the prices for Surface tablets
A lot has been said about the pricing of the Microsoft Surface tablets. Here's my view:
Microsoft introduced the Surface RT at $500 (well, $499) and the Surface Pro at $1000 (okay, $999).
In June, Microsoft announced a promotion: a free keyboard with the purchase of a Surface RT. The keyboard normally sold for $100, so June saw a discount of $100.
In July, Microsoft dropped the price of the Surface RT by $150 -- and cancelled the promotion for the free keyboard. In effect, Microsoft dropped the price by an additional $50. (For some reason, lots of the media claimed that this was "slashing the price".)
In August, Microsoft reduced the price of the Surface Pro by $100.
Looking at the trend, I would say that Microsoft is testing the market, gradually dropping the price and measuring demand. Economics 101, so to speak.
My guess is that Microsoft will keep measuring and dropping the price. Or perhaps dropping the price and removing features. The cannot change the hardware (assuming they sell the existing units) so they may remove software. The natural selection would be to remove the "no business use" version of Microsoft Office, but with the dearth of apps in the Microsoft app store, it would render the device all but useless. Could they remove something else?
Microsoft seems to be announcing changes every month. Let's see what September brings.
Microsoft introduced the Surface RT at $500 (well, $499) and the Surface Pro at $1000 (okay, $999).
In June, Microsoft announced a promotion: a free keyboard with the purchase of a Surface RT. The keyboard normally sold for $100, so June saw a discount of $100.
In July, Microsoft dropped the price of the Surface RT by $150 -- and cancelled the promotion for the free keyboard. In effect, Microsoft dropped the price by an additional $50. (For some reason, lots of the media claimed that this was "slashing the price".)
In August, Microsoft reduced the price of the Surface Pro by $100.
Looking at the trend, I would say that Microsoft is testing the market, gradually dropping the price and measuring demand. Economics 101, so to speak.
My guess is that Microsoft will keep measuring and dropping the price. Or perhaps dropping the price and removing features. The cannot change the hardware (assuming they sell the existing units) so they may remove software. The natural selection would be to remove the "no business use" version of Microsoft Office, but with the dearth of apps in the Microsoft app store, it would render the device all but useless. Could they remove something else?
Microsoft seems to be announcing changes every month. Let's see what September brings.
Thursday, August 1, 2013
A review of PCs from tablet perspective
I had the opportunity to try several of the PC-type tablets that are now on the market. Wow, they are very different from the standard tablet. Here is my review.
I tried a Lenovo ThinkPad Edge "laptop", a Dell Inspiron "desktop", and an Apple MacBook "laptop". For the ThinkPad and Inspiron, I used Microsoft Windows 7 and Ubuntu Linux. The MacBook ran Apple's MacOS.
I'm not sure where to begin with my review. The "PC experience" is quite different from the normal experience of a tablet.
The first difference is the size. PCs come in two basic styles: desktop and laptop. The laptop is similar to a tablet with a Bluetooth keyboard, except somewhat heavier. The keyboard is physically attached, which I found odd. I initially thought this was for protection (the keyboard is hinged and folds over the screen) and convenience in travelling (you won't lose the keyboard) but later I found that the real reason was quite different - various hardware is built under the keyboard, and wires connect the central circuitry to the screen.
The laptop flavor of a PC should really be called "desktop", since the only practical way to use it is on a desktop. One cannot separate the keyboard, and balancing the keyboard and screen on your lap is awkward at best. Both the Lenovo and the Apple PCs used this design.
The desktop version (the Dell Inspiron, but a quick survey shows that all brands use this design) is also incorrectly named. The screen is large -- too large to be portable. It requires its own stand, which places the screen at a comfortable viewing angle. (Most PC screens allow the use to adjust the height and viewing angle.) The desktop PC also includes a keyboard, one that is connected to the unit with a cable.
The name "desktop" is wrong because in addition to the screen and keyboard there is also a separate, large box that must be attached to the screen. (The keyboard connects to this box, not the screen.) This large box belongs not on a desktop but on the floor, and the users I talked with indicated that they all stored this box on the floor.
The desktop version of the PC is not portable. The combination of the large screen, separate keyboard, and large "processor" box are too cumbersome to carry. In addition, the screen and processor box both require power from 120VAC, and neither have the capability for battery operation.
The laptop versions of the PC are somewhat portable. They can fold for carrying, and they have battery for some use. (The manufacturers claim six to eight hours; users I spoke with indicated three to five hours. My tests fell in line with users.)
The next big differences one notices are the screen, keyboard, and touch interface. The screen is large, with ample real estate for displaying apps. The keyboards are physical keyboards, not on-screen keyboards (in fact there is no support for on-screen keyboards). Physical keyboards took some getting used to, since the keys do travel and provide excellent tactile feedback. But being physical, they cannot change to reflect different modes or languages, with the result being more keys to handle special symbols and indicators to show "caps" mode. (There were some keys with unusual names such as "Print Screen", "Scroll Lock", and "Pause", but I found no use for them. Perhaps they are for future expansions?)
Another noticeable difference is that the screen does not support touch. This was frustrating, as I kept touching the screen and waiting for something to happen. After a few seconds, I realized that I had to use the keyboard or a touchpad (or mouse -- more on that later).
The Lenovo and Apple laptops came with built-in touchpads. These are small (3" by 4") pads below the keyboard that let you control a small "cursor" on the screen. The cursor is normally shaped as an arrow pointing in the north-by-northwest direction (some modes change this shape) and you can move the cursor by touching and swiping on the touchpad. Since the touchpad is relatively far from the screen, this design requires the ability to touch the pad while you look at the screen -- something that I suspect few people will want to learn.
The desktops did not use a touchpad, but instead had an extra device called a "mouse". (Where did they get that names?) It is a small, roughly half-sphere, object that one drags on a flat surface. It too, controls a "cursor" on the screen, and it was harder to use than the touchpad! Proper use requires looking at the screen and holding the mouse off to the side, again using coordinated actions without looking at one of your hands. I found that my desk at home was a bit small for such a computer; I kept dragging the mouse off the edge of the desk.
The PC is not a complete disaster. All units I evaluated had a cable for internet access. I had to physically connect the units to my home router (finally understanding why it had those "extra" ports) and network access was fast and consistent. The Apple and Lenovo PCs (the laptops) also supported the standard wi-fi connections.
PCs have enormous memory, and apps can take advantage of it. My evaluation units all came with 4GB of RAM, which is small for PCs. This leads to apps that are much larger and more complex. More on apps later. RAM is temporary storage and not the usual memory we think of in tablets.
PCs also have enormous storage. which is the equivalent of a tablet's normal memory. My evaluation units came with 300GB to 500GB! The sheer amount boggles me. (Although to be honest, I'm not sure why one needs so much storage. With the fast and reliable network connection, one could easily push data to servers, without using local storage.)
A few more things about hardware, before I move on to operating systems and apps: PCs have lots of ports for accessory devices. Perhaps this is a result of their size; they can afford the space for circuitry and jacks. The PC seems designed for external hardware; the keyboard and "mouse" must be connected through these ports.
The laptop units had built-in forward-facing cameras, the desktop PCs had no cameras. Desktop PCs can have cameras as an extra device (using one of the ports).
None of the units had accelerometers, compasses, or GPS antennae. For the "desktop" units, that makes sense as they are made to be stationary. I'm not sure why they were omitted from the "laptop" PCs which theoretically could move, and certainly have the space for them.
I tried three operating systems: Microsoft Windows, Apple MacOS, and Ubuntu Linux. All are quite similar, and all are significantly different from the typical tablet operating system.
The Lenovo and Dell computers came with Windows 7 pre-installed. The Apple came with Apple MacOS pre-installed. I installed Linux on the Lenovo and Dell, using a technique called "partitioning". This technique lets you allocate the PCs storage between the two operating systems. (With 300GB of storage, there is a lot to go around.)
A "partitioned" system presents a menu when started, letting you select which operating system you want. The menu has a twenty-second timeout, starting Ubuntu if you take no action. (I think that this is configurable.)
All three PC operating systems use a desktop metaphor. The main screen contains icons for apps, and you start an app not by touching the icon (remember, the screen doesn't support touch!) but by dragging the mouse cursor to an icon and double-clicking on it.
With the large screen, apps don't fill the entire screen but take only a portion of it. The app displays a "window" (a term used by all three operating systems, not just Microsoft Windows) and you can run several apps at the same time. This is a nice feature of PCs, as you can see the status of multiple apps at the same time. (Although too many apps at once can be overwhelming.)
The smaller-than-screen size of apps also lets you move app windows on your "desktop". A complicated sequence of moving the mouse, pressing and long-holding a button, moving the mouse while long-holding, and then releasing the button lets you move windows on the screen. This lets you arrange apps you your liking and move important apps to prominent locations.
The different operating systems had different ideas about app purchases. Linux has a store for selecting and purchasing apps, much like a typical tablet. Apple MacOS has an "App Store" but many apps are not available though it and must be purchased separately. For Microsoft's Windows 7, all apps must be purchased separately. I found the Linux arrangement the most friendly, since there is one place to go for apps. [Edit: I later learned that in Linux you can also download apps from other sources.]
The lack of a central store for apps leads to another difference: updates. Without the central store to coordinate versions of apps, each app must check for its own updates. I can't imagine why anyone would want to distribute software without the infrastructure of an app store; doing so requires duplicating code to check versions, download updates, and apply updates in every app! It seems to put a large burden on the app development team (and the testing team).
All three operating systems handled updates for themselves. Windows, MacOS, and Linux all automatically found, downloaded, and applied updates. Ubuntu Linux, with its store, considered the OS update to be "just another update" and bundled it into a list with app updates. Windows and MacOS handled OS updates and did nothing for apps. (I suspect the MacOS app store would handle updates for apps, but I had none during my evaluation.)
PC apps tend to focus on office work, and given the hardware, this is no surprise. The physical keyboard excels at text entry, and the lack of geolocation services removes a number of apps from the PC's repertoire. An app such as FourSquare is not possible without location services, and Facebook is limited without a camera.
In conclusion, I find the idea of the PC misguided: its powerful hardware is torn between local applications (processor and storage) and normal service-based apps (reliable and fast network). The absence of touch support for the screen and the physical keyboard pushes one to text-oriented data, and the clumsy touchpad (or even worse, mouse) pushes one away from UI operations. Forcing users to hunt down apps without a central store places a burden on the users. Forcing apps to update themselves places a burden on developers.
I tried a Lenovo ThinkPad Edge "laptop", a Dell Inspiron "desktop", and an Apple MacBook "laptop". For the ThinkPad and Inspiron, I used Microsoft Windows 7 and Ubuntu Linux. The MacBook ran Apple's MacOS.
I'm not sure where to begin with my review. The "PC experience" is quite different from the normal experience of a tablet.
The first difference is the size. PCs come in two basic styles: desktop and laptop. The laptop is similar to a tablet with a Bluetooth keyboard, except somewhat heavier. The keyboard is physically attached, which I found odd. I initially thought this was for protection (the keyboard is hinged and folds over the screen) and convenience in travelling (you won't lose the keyboard) but later I found that the real reason was quite different - various hardware is built under the keyboard, and wires connect the central circuitry to the screen.
The laptop flavor of a PC should really be called "desktop", since the only practical way to use it is on a desktop. One cannot separate the keyboard, and balancing the keyboard and screen on your lap is awkward at best. Both the Lenovo and the Apple PCs used this design.
The desktop version (the Dell Inspiron, but a quick survey shows that all brands use this design) is also incorrectly named. The screen is large -- too large to be portable. It requires its own stand, which places the screen at a comfortable viewing angle. (Most PC screens allow the use to adjust the height and viewing angle.) The desktop PC also includes a keyboard, one that is connected to the unit with a cable.
The name "desktop" is wrong because in addition to the screen and keyboard there is also a separate, large box that must be attached to the screen. (The keyboard connects to this box, not the screen.) This large box belongs not on a desktop but on the floor, and the users I talked with indicated that they all stored this box on the floor.
The desktop version of the PC is not portable. The combination of the large screen, separate keyboard, and large "processor" box are too cumbersome to carry. In addition, the screen and processor box both require power from 120VAC, and neither have the capability for battery operation.
The laptop versions of the PC are somewhat portable. They can fold for carrying, and they have battery for some use. (The manufacturers claim six to eight hours; users I spoke with indicated three to five hours. My tests fell in line with users.)
The next big differences one notices are the screen, keyboard, and touch interface. The screen is large, with ample real estate for displaying apps. The keyboards are physical keyboards, not on-screen keyboards (in fact there is no support for on-screen keyboards). Physical keyboards took some getting used to, since the keys do travel and provide excellent tactile feedback. But being physical, they cannot change to reflect different modes or languages, with the result being more keys to handle special symbols and indicators to show "caps" mode. (There were some keys with unusual names such as "Print Screen", "Scroll Lock", and "Pause", but I found no use for them. Perhaps they are for future expansions?)
Another noticeable difference is that the screen does not support touch. This was frustrating, as I kept touching the screen and waiting for something to happen. After a few seconds, I realized that I had to use the keyboard or a touchpad (or mouse -- more on that later).
The Lenovo and Apple laptops came with built-in touchpads. These are small (3" by 4") pads below the keyboard that let you control a small "cursor" on the screen. The cursor is normally shaped as an arrow pointing in the north-by-northwest direction (some modes change this shape) and you can move the cursor by touching and swiping on the touchpad. Since the touchpad is relatively far from the screen, this design requires the ability to touch the pad while you look at the screen -- something that I suspect few people will want to learn.
The desktops did not use a touchpad, but instead had an extra device called a "mouse". (Where did they get that names?) It is a small, roughly half-sphere, object that one drags on a flat surface. It too, controls a "cursor" on the screen, and it was harder to use than the touchpad! Proper use requires looking at the screen and holding the mouse off to the side, again using coordinated actions without looking at one of your hands. I found that my desk at home was a bit small for such a computer; I kept dragging the mouse off the edge of the desk.
The PC is not a complete disaster. All units I evaluated had a cable for internet access. I had to physically connect the units to my home router (finally understanding why it had those "extra" ports) and network access was fast and consistent. The Apple and Lenovo PCs (the laptops) also supported the standard wi-fi connections.
PCs have enormous memory, and apps can take advantage of it. My evaluation units all came with 4GB of RAM, which is small for PCs. This leads to apps that are much larger and more complex. More on apps later. RAM is temporary storage and not the usual memory we think of in tablets.
PCs also have enormous storage. which is the equivalent of a tablet's normal memory. My evaluation units came with 300GB to 500GB! The sheer amount boggles me. (Although to be honest, I'm not sure why one needs so much storage. With the fast and reliable network connection, one could easily push data to servers, without using local storage.)
A few more things about hardware, before I move on to operating systems and apps: PCs have lots of ports for accessory devices. Perhaps this is a result of their size; they can afford the space for circuitry and jacks. The PC seems designed for external hardware; the keyboard and "mouse" must be connected through these ports.
The laptop units had built-in forward-facing cameras, the desktop PCs had no cameras. Desktop PCs can have cameras as an extra device (using one of the ports).
None of the units had accelerometers, compasses, or GPS antennae. For the "desktop" units, that makes sense as they are made to be stationary. I'm not sure why they were omitted from the "laptop" PCs which theoretically could move, and certainly have the space for them.
I tried three operating systems: Microsoft Windows, Apple MacOS, and Ubuntu Linux. All are quite similar, and all are significantly different from the typical tablet operating system.
The Lenovo and Dell computers came with Windows 7 pre-installed. The Apple came with Apple MacOS pre-installed. I installed Linux on the Lenovo and Dell, using a technique called "partitioning". This technique lets you allocate the PCs storage between the two operating systems. (With 300GB of storage, there is a lot to go around.)
A "partitioned" system presents a menu when started, letting you select which operating system you want. The menu has a twenty-second timeout, starting Ubuntu if you take no action. (I think that this is configurable.)
All three PC operating systems use a desktop metaphor. The main screen contains icons for apps, and you start an app not by touching the icon (remember, the screen doesn't support touch!) but by dragging the mouse cursor to an icon and double-clicking on it.
With the large screen, apps don't fill the entire screen but take only a portion of it. The app displays a "window" (a term used by all three operating systems, not just Microsoft Windows) and you can run several apps at the same time. This is a nice feature of PCs, as you can see the status of multiple apps at the same time. (Although too many apps at once can be overwhelming.)
The smaller-than-screen size of apps also lets you move app windows on your "desktop". A complicated sequence of moving the mouse, pressing and long-holding a button, moving the mouse while long-holding, and then releasing the button lets you move windows on the screen. This lets you arrange apps you your liking and move important apps to prominent locations.
The different operating systems had different ideas about app purchases. Linux has a store for selecting and purchasing apps, much like a typical tablet. Apple MacOS has an "App Store" but many apps are not available though it and must be purchased separately. For Microsoft's Windows 7, all apps must be purchased separately. I found the Linux arrangement the most friendly, since there is one place to go for apps. [Edit: I later learned that in Linux you can also download apps from other sources.]
The lack of a central store for apps leads to another difference: updates. Without the central store to coordinate versions of apps, each app must check for its own updates. I can't imagine why anyone would want to distribute software without the infrastructure of an app store; doing so requires duplicating code to check versions, download updates, and apply updates in every app! It seems to put a large burden on the app development team (and the testing team).
All three operating systems handled updates for themselves. Windows, MacOS, and Linux all automatically found, downloaded, and applied updates. Ubuntu Linux, with its store, considered the OS update to be "just another update" and bundled it into a list with app updates. Windows and MacOS handled OS updates and did nothing for apps. (I suspect the MacOS app store would handle updates for apps, but I had none during my evaluation.)
PC apps tend to focus on office work, and given the hardware, this is no surprise. The physical keyboard excels at text entry, and the lack of geolocation services removes a number of apps from the PC's repertoire. An app such as FourSquare is not possible without location services, and Facebook is limited without a camera.
In conclusion, I find the idea of the PC misguided: its powerful hardware is torn between local applications (processor and storage) and normal service-based apps (reliable and fast network). The absence of touch support for the screen and the physical keyboard pushes one to text-oriented data, and the clumsy touchpad (or even worse, mouse) pushes one away from UI operations. Forcing users to hunt down apps without a central store places a burden on the users. Forcing apps to update themselves places a burden on developers.
Subscribe to:
Posts (Atom)